Валидация DVM после обновления потребляет весь CPU, или как мы заставили Oracle выпустить patch

Постановка задачи

Пришли как-то к Суровому коллеги с интересным вопросом. Суть в следующем: каждый раз после обновления MDS производительность промышленного контура одной немаленькой системы, написанной на Oracle SOA Suite, критически падает, при этом загрузка центральных процессоров серверов, на которых развернута система, очень сильно возрастает.

Особенностью системы является активное использование такого механизма Oracle SOA Suite как Domain Value Maps (DVM), предназначенного для перекодировки значений из ограниченного набора одной предметной области (при интеграции - одной информационной системы) в значения, характерные для другой предметной области (информационной системы). Например наши любимые российские рубли в одной системе могут кодироваться как RUR, а в другой - 810. Механизм DVM удобен для работы со справочниками конвертации, которые изменяются нечасто, однако, если все же справочник требуется изменить, то в состав Oracle SOA Suite входит инструмент с развитым веб-интерфейсом - SOA Composer, - позволяющий сделать это бизнес-пользователю без привлечения разработчиков.

Как оказалось, все работает идеально пока такие справочники небольшие, однако если их размер увеличивается до сотен килобайт, то пользователей и администраторов Oracle SOA Suite ждут сюрпризы.

Посмотрим на дамп потоков, собранный во время, когда наблюдалась проблема.

"[ACTIVE] ExecuteThread: '57' for queue: 'weblogic.kernel.Default (self-tuning)'" #159 daemon prio=9 os_prio=2 tid=0x0000000066bbd800 nid=0x28ac runnable [0x0000000079188000]
java.lang.Thread.State: RUNNABLE
at oracle.xml.xpath.XPathChildAxis.getNodeList(XPathAxis.java:600)
at oracle.xml.xpath.XPathStep.evaluate(XPathStep.java:1102)
at oracle.xml.xpath.PathExpr.evaluate(PathExpr.java:808)
at oracle.xml.xpath.ComparisonExpr.evaluate(XSLExpr.java:1743)
at oracle.xml.xpath.XSLExprBase.testBooleanExpr(XSLExprBase.java:514)
at oracle.xml.xpath.AndExpr.evaluate(XSLExpr.java:524)
at oracle.xml.xpath.XSLExprBase.testBooleanExpr(XSLExprBase.java:514)
at oracle.xml.xpath.AndExpr.evaluate(XSLExpr.java:524)
at oracle.xml.xpath.XSLExprBase.testBooleanExpr(XSLExprBase.java:514)
at oracle.xml.xpath.AndExpr.evaluate(XSLExpr.java:524)
at oracle.xml.xpath.XPathPredicate.filter(XPathPredicate.java:349)
at oracle.xml.xpath.XPathChildAxis.getNodeList(XPathAxis.java:627)
at oracle.xml.xpath.XPathStep.evaluate(XPathStep.java:1102)
at oracle.xml.xpath.PathExpr.evaluate(PathExpr.java:808)
at oracle.xml.parser.v2.XMLNode.selectNodes(XMLNode.java:2762)
at oracle.xml.parser.v2.XMLNode.selectNodes(XMLNode.java:2722)
at oracle.tip.dvm.sdk.util.XMLUtil.isDVMDocumentValid(XMLUtil.java:211)
at oracle.tip.dvm.entity.DVMRTObject.validateDVM(DVMRTObject.java:202)
at oracle.tip.dvm.entity.DVMRTObject.(DVMRTObject.java:130)
at oracle.tip.dvm.DVMManagerImpl.getDVMRTObject(DVMManagerImpl.java:217)
at oracle.tip.dvm.DVMManagerImpl.lookupValue(DVMManagerImpl.java:133)
at oracle.tip.dvm.LookupValue.lookupValue(LookupValue.java:95)
at oracle.tip.dvm.LookupValue.lookupValue(LookupValue.java:252)
at sun.reflect.GeneratedMethodAccessor1815.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at oracle.xml.xpath.XSLExtFunctions.callStaticMethod(XSLExtFunctions.java:115)
at oracle.xml.xpath.XPathExtFunction.evaluateMethod(XPathExtFunction.java:422)
at oracle.xml.xpath.XPathExtFunction.evaluate(XPathExtFunction.java:347)
at oracle.xml.xslt.XSLValueOf.processAction(XSLValueOf.java:152)
at oracle.xml.xslt.XSLNode.processChildren(XSLNode.java:559)
at oracle.xml.xslt.XSLTemplate.processAction(XSLTemplate.java:278)
at oracle.xml.xslt.XSLStylesheet.execute(XSLStylesheet.java:706)
at oracle.xml.xslt.XSLStylesheet.execute(XSLStylesheet.java:665)
at oracle.xml.xslt.XSLProcessor.processXSL(XSLProcessor.java:401)
at oracle.xml.jaxp.JXTransformer.transform(JXTransformer.java:578)
at ...

Микросервисы, SOA и API: друзья или враги?

Оригинал: Microservices, SOA, and APIs: Friends or enemies? by Kim Clark, опубликован 21 января 2016.

Сравнение ключевых концепций архитектуры приложений и интеграции для развивающегося предприятия.

• Введение
  
  
• Чрезмерно упрощенный взгляд
  
  
• Дихотомия SOA-инициатив
  
  
• Как API соотносятся с сервисами SOA
  
  
• Микросервисы: альтернативная архитектура
  
  
• Преимущества микросервисов
  
  
• Ключевые факторы, влияющие на принятие решения об использовании микросервисов
  
  
• Место микросервисов на картине SOA и проблем интеграции
  
  
• Объединение микросервисов, SOA и API в будущем
  
  
• Выводы
  
  
• Благодарности
  
  
• Ресурсы

Введение

При сравнении микросервисной и сервисно-ориентированной (SOA) архитектуры практически невозможно прийти к согласию о том, как же все-таки они соотносятся друг с другом. Добавление в список еще и application programming interfaces (APIs) картину очевидно не проясняет. Некоторые могут сказать, что это вообще абсолютно изолированные друг от друга понятия, не имеющие ничего общего и предназначенные для решения разных задач. Другие заметят, что данные концепции разделяют общие принципы и созданы для достижения неких общих целей. Микросервисная архитектура может казаться этакой "тонкоструктурной (fine-grained) SOA" или "правильно внедренной SOA".

Данная статья вводит определение выше обозначенных концепций, дает понимание, откуда есть пошла русская земля идут столь разные мнения и позволяет прийти к какому-то общему знаменателю. Так же будет рассмотрено, как следует комбинировать данные концепции с целью дальнейшего развития.

Визуализация и тестирование REST API с помощью Swagger на WebSphere Liberty

В последние годы все большую популярность набирает стандарт описания интерфейсов RESTful веб-сервисов Swagger. Фактически Swagger становится для RESTful-сервисов тем же, чем является WSDL для SOAP-сервисов. При этом разработчики серверов приложений активно добавляют поддержку данного стандарта в свои продукты. Вот и флагманский сервер приложений WebSphere Liberty корпорации IBM обзавелся новой возможностью apiDiscovery, позволяющей найти все доступные на сервере REST API и динамически создать Swagger-подобный интерфейс пользователя для тестирования найденных конечных точек.

В данной статье мы рассмотрим процесс реализации некоего REST API с помощью сервлетов, его документирования на Swagger и тестирования с помощью пользовательского интерфейса apiDiscovery. Дополнительно я расскажу о достаточно богатом механизме обнаружения сервером приложений доступных Swagger-документов и генерации таковых по аннотациям JAX-RS и Swagger.

Первое знакомство с Red Hat JBoss Fuse

Здравствуйте, коллеги.

Сегодня проводил семинар в Accenture Riga Delivery Center по поводу интересной для меня темы Red Hat JBoss Fuse и решил поделиться своими впечатлениями от этой сервисной шины с вами.

Что такое Red Hat JBoss Fuse? По сути это - среда исполнения для реализации набора паттернов интеграции корпоративных приложений (Enterprise Application Integration Patterns (EIP)) Apache Camel.

Данная среда исполнения поставляется в двух вариантах:

• Apache Karaf - готовая к промышленному использованию реализация стандарта OSGi.
  
  
• Red Hat JBoss Enterprise Application Platform - широко известный Java EE-совместимый сервер приложений с коммерческой поддержкой. К сожалению, Red Hat JBoss Fuse устанавливается только на версию 6.4.0 данного сервера приложений, реализующую лишь стандарт Java EE 6, что приводит к проблемам, некоторые из которых описаны ниже.
  

Не очередями сообщений едиными или что такое федерализация данных

Крупные предприятия независимо от сферы деятельности имеют десятки, а иногда и сотни внедренных приложений. Данные порождаются в одних информационных системах, но используются повсеместно, а не только в точках порождения. Ручной ввод данных в каждое приложение, в котором они нужны, это довольно трудоемкое, дорогое, а главное - чреватое ошибками и снижающее качество данных решение. Требуется интеграция данных.

Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.

• Недостатки распространения данных
  
  
• Федерализация данных
  
  
• Применимость шаблона "федерализация данных"
  
  
• Ограничения при внедрении шаблона "федерализация данных"
  
  
• Выводы
  
  
• Материалы

"Универсальный сервис", почему заказчики так часто его хотят и почему его делать не нужно

В очередной раз столкнувшись с предложением заказчика "а сделайте мне универсальный транспорт, в котором сообщения будут представлять собой обычные строки, содержащие XML, и который не будет осуществлять никакой валидации/обогащения/мониторинга, но зато я должен иметь возможность включать новые маршруты/преобразования правкой строчек в некоторой конфигурационной базе данных, а да, еще очень хочу чтобы это все было на Oracle Service Bus/IBM WebSphere ESB/IBM WebSphere Message Broker", Суровый решил написать вам о своем отношении к подобным решениям. Статья из серии "не могу молчать".

Так получилось, что за четыре года опыта занятия системной интеграцией, практически каждый раз или в начале проекта, или в процессе его развития заказчиков озаряет идея. Нет, даже так: Идея! Идея универсальной шины, которая ничего не будет делать, кроме маршрутизации и трансформации сообщений. Зато заказчик сможет сам настраивать эти процессы (в основном маршрутизацию), причем обязательно с помощью только лишь правки конфигурации в базе данных. По сути от нас как исполнителей требуется некоторая универсальная реализация паттернов интеграции корпоративных приложений и каноническая модель данных. Каждый такой заказчик считает, что получив подобное решение, он сможет оперативно подключать к нему новые информационные системы, просто разработав соответствующий адаптер и добавив несколько строк в базу данных конфигурации.

Долгожданный релиз Oracle Fusion Middleware 12c!

Прямо неделя релизов какая-то. Сначала Eclipse Luna, теперь долгожданный релиз Oracle Fusion Middleware 12c. Скажем дружно: "Наконец-то!".

Итак, чем же нас порадовала корпорация Oracle в этот раз.

Во-первых, это конечно же новый Oracle WebLogic 12.1.3 с частичной поддержкой Java EE 7.

Во-вторых, вышло обновление основных компонентов:
- Oracle SOA Suite;
- Oracle BPM Suite;
- Oracle Service Bus;
- Oracle Event Processing.

Oracle SOA Suite, BPM Suite и OSB можно установить из одного архива. Oracle Data Integrator можно скачать по ссылке. Oracle Event Processing в свою очередь доступен по данному адресу.

Так же обновилась наша любимая среда разработки Oracle JDeveloper. Важно! Разработка для Oracle Service Bus и Oracle Event Processing теперь тоже ведется в данной среде.

Итак, что же стало лучше?

Общие изменения

1. Упростилась установка среды разработки. WebLogic, JDeveloper и компоненты Fusion Middleware устанавливаются из одного архива. Разработанные композиты могут запускаться на встроенном в JDeveloper экземпляре WebLogic'а аналогично старым-добрым сервлетам и EJB. В качестве СУБД для хранения схемы SOAINFRA используется JavaDB.

2. Добавлен отладчик композитов (и, вероятно, OSB-сервисов).

3. Добавлен встроенный тестер для SOA, теперь для запуска тестов не нужно обращаться к EM. Так же поддерживается CI (Maven/Hudson).

4. Добавлена поддержка REST.

5. Добавлены шаблоны компонентов при редактировании SOA-композитов. Можно разрабатывать свои компоненты.

6. Доработана оптимизация исполнения на Exalogic.

7. Переделана система авторизации в сторону большей гибкости.

8. Добавлен новый компонент - Enterprise Scheduler (ESS).

9. Улучшена консоль управления EM.

10. Улучшена обработка ошибок, т.н. Error Hospital.

11. Увеличена производительность платформы. Добавлена ленивая загрузка композитов и оптимизирована схема БД.

12. Улучшен SOA Composer.

13. Добавлен новый компонент - Managed File Transfer (MFT).

14. Добавлена поддержка мобильных каналов (Mobile Channel Enablement).

15. Добавлена поддержка облачных приложений.

16. Добавлены новые JCA-адаптеры (в частности LDAP-, Coherence-, MSMQ-адаптеры).

17. Улучшен компонент B2B.

BPEL

1. Добавлена поддержка встраиваемых и исполняемых отдельно (standalone) подпроцессов.

2. Добавлена поддержка шаблонов и разрабатываемых пользователем активностей.

Oracle Service Bus

1. Разработка для OSB теперь осуществляется в JDeveloper.

2. Добавлена поддержка переупорядочивания сообщений аналогично имеющейся в компоненте Mediator.

3. В EM добавлена консоль управления OSB.

4. Динамическая валидация содержимого сообщений во время исполнения, основанная на выражениях.

EDN

1. Переписан на использование JMS в качестве базовой реализации (раньше использовалась Oracle AQ). По-идее, теперь должна появиться возможность включать гарантированную доставку событий.

Так же существенно улучшен продукт Oracle Event Processing, но т.к. я не имею опыта его использования, то мне трудно разобраться в данных изменениях.

Много материала, описывающего нововведения, есть в блоге Niall Commiskey.

Long Live Oracle!

P.S. Конечно новая верстка сайта документации реальный вырвиглаз! Приходится скачивать в PDF и только потом читать, мартышка к старости слаба глазами стала...

Понравилось сообщение - подпишитесь на блог

SOAP vs RESTful

Поучаствовал в бурных дебатах с коллегами на тему отличий SOAP- и REST-подходов. Вопрос довольно общий, возникает часто, поэтому я решил поделиться своим мнением в блоге.

Обычно при сравнении SOAP- и RESTful-сервисов заводят разговор о том, что мол "ну SOAP же тяжелый протокол, а REST-легкий, это всем известно". Но что тяжелого в SOAP-запросе? Пустой SOAP-запрос с заголовком выглядит следующим образом:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
   </soapenv:Body>
</soapenv:Envelope>

Данный запрос занимает всего 158 байт. Говорить о том, что что-то тяжелое только потому что оно на 158 байт длиннее чего-то "легкого" несерьезно. Естественно, что различия между данными подходами гораздо глубже.

Event-Driven Architecture на Oracle SOA Suite 11g - компонент Event Delivery Network (EDN)

Термин "управляемая событиями архитектура" (Event Driven Architecture, EDA) предложил Roy W. Schulte, аналитик Gartner в работе The Growing Role of Events in Enterprise Applications, опубликованной в 2003-м году. Одно время подход с архитектурой, управляемой событиями, рассматривали чуть ли не как замену сервисно-ориентированной архитектуре (Service-Oriented Architecture, SOA), существовал даже термин SOA 2.0. В последнее время интерес к EDA поутих, но на мой взгляд у данной концепции есть будущее. В своей заметке четырехлетней давности - Событийная модель построения приложения - Суровый пытался рассказать что такое EDA и какие компоненты необходимы для построения архитектуры, управляемой событиями, в данной же заметке рассмотрим средства, предоставляемые для этого программным продуктом Oracle SOA Suite 11g.

Сначала давайте рассмотрим зачем вообще могут быть нужны события в вашей реализации сервисно-ориентированной архитектуры. Что дает внедрение EDA простому разработчику? Прежде всего это полное разделение между системой-источником событий и системами-приемниками, что по-английски называется Super Decoupling. Что это значит? В классической SOA клиент сервиса должен знать конечную точку, предоставляемую или провайдером сервиса, или сервисной шиной предприятия. Таким образом и при смене конечной точки, и при подключении новой системы-приемника сообщений клиента необходимо изменить, как минимум перенастроить. В случае же управляемой событиями архитектуры, единственное, что должен сделать клиент - опубликовать событие. Он не должен даже знать, есть ли вообще сервисы-обработчики данного события и сколько их.

Можно провести следующую аналогию. В современных компаниях часто существует такая должность, как специалист по внутренним коммуникациям. Задача данного специалиста знать все новости компании и оповещать о них сотрудников. При этом одному сотруднику интересны новости о зарплате, другому - о каких-то кадровых изменениях, третьему - дни рождения коллег. При этом одни сотрудники работают, например, в Москве, а другие - в Челябинске. Специалист по внутренним коммуникациям заводит списки рассылки для каждого типа оповещения, а так же рассылки в разрезе городов и добавляет в них желающих получать ту или иную информацию. Затем заносит новых желающих. Затем убирает уволенных и нежелающих более получать информацию. В итоге специалист начинает что-то подозревать. В частности то, что он занимается какой-то непонятной работой. После этого он заводит корпоративный Twitter, в который начинает добавлять все новости компании, снабжая их различными хэштегами. Желающие получать определенные новости подписываются на этот Twitter, возможно с фильтром по тегам. Специалист по внутренним коммуникациям в данной метафоре является публикатором событий, желающие получать новости - подписчиками или приемниками событий, а Twitter - диспетчером событий.

При использовании шаблона проектирования "многоуровневая архитектура" необходимо обеспечить реализацию следующего правила: вызовы между слоями передаются только сверху вниз. Т.е. только верхний уровень вызывает нижний, ни в коем случае не наоборот. Нижние уровни ничего не знают о том, кто к ним обращаются. В теории все выглядит замечательно, на практике же зачастую необходимо передавать какую-то информацию от нижних уровней к верхним. Например, информацию о каких-то сервисных действиях, к примеру о выключении оборудования или о разрыве сети. Зачем передавать? К примеру, для информирования пользователя. Здесь как нельзя кстати на помощь приходит механизм событий. В стройной многоуровневой архитектуре нижний слой не знает, кто его вызывает и кого именно информировать о проблемах. Это и не нужно. Достаточно только опубликовать событие. А уже компоненты верхнего слоя подписываются на нужные им события. В итоге и канал связи между нижними и верхними слоями установлен, и стройность многоуровневой архитектуры не нарушена.

Возможности Oracle SOA Suite для интеграции унаследованных приложений

В данной заметке мы рассмотрим возможности, которые предоставляет Oracle SOA Suite для подключения унаследованных приложений к сервисно-ориентированной инфраструктуре предприятия.

Прежде всего стоит оговориться, что под унаследованными приложениями мы будем понимать приложения, которые не предоставляют возможности подключения с помощью стандартного механизма интеграции - Web Service'ов и в то же время не являются хорошо известными и широко используемыми корпоративными приложениями, т.е. к ним не существует стандартных адаптеров. Таким образом такие лидеры рынка как SAP, OeBS, JDEdwards и Siebel не попадают под наше определение унаследованных приложений.

Теперь можно рассмотреть конкретные механизмы интеграции, предлагаемые стеком продуктов Oracle Fusion Middleware. Для Oracle SOA Suite данными механизмами являются технологические адаптеры.

Подготовка релиза сервисной шины предприятия на нашем проекте

На своем текущем месте работы Суровый занимается интеграцией внедряемой CRM с другими информационными системами телеком-оператора: биллингами, техническим учетом, ERP, активацией, Ordering Management System (OMS) и т.д. Сейчас у нас подключено к сервисной шине четыре макрорегиональных филиала, при этом стоит отметить, что в каждом макрорегиональном филиале свой IT-ландшафт, что делает проект еще более интересным.

О чем хочется рассказать в данной заметке. Нам на проекте необходимо обеспечить работоспособность конкретного подмножества сервисов на шине для одного основного клиента (CRM), при этом у нас есть временной лаг между разработкой клиента (CRM), разработкой сервисной шины и разработкой (внедрением) внешних систем - поставщиков сервисов. При этом нам нужно иметь гарантированно стабильный и готовый для развертывания код шины.

Ситуация в целом характерная для большинства интеграционных проектов. Проблема в том, что данная ситуация требует разработки подхода к подготовке релизов шины, чтобы при установке очередного релиза в продуктив не сломалось ни взаимодействие клиента с шиной, ни взаимодействие шины с внешними системами.

При этом у нашего проекта есть следующие особенности.

1. Небольшая команда разработки сервисной шины - порядка 5-ти человек.

2. Несмотря на скромный размер команды за год разработано и внедрено 13 сервисов и 46 экземпляров адаптеров к информационным системам. Сложность логики сервисов весьма разнообразна - от простого оборачивания вызова хранимой процедуры в SOAP, до сложной оркестровки с использованием компонента Split-Join.

3. В качестве системы контроля версий исходного кода используется SVN.

4. Технологическая платформа - Oracle Service Bus - не поддерживает "из коробки" версионирование сервисов, т.е. мы не можем иметь в продуктиве несколько версий одного и того же сервиса одновременно. С учетом того, что у нас всего один основной клиент и с его разработчиками всегда можно договориться, то мы вполне можем обойтись без данной возможности.

5. Разработка ведется по гибкой методологии. К сожалению это иногда приводит к непродуманности технических решений и несогласованности изменений, особенно с поставщиками внешних систем.

О производительности: RouterRuntimeCache в Oracle Service Bus

В настройках Oracle Service Bus присутствует интересный параметр: com.bea.wli.sb.pipeline.RouterRuntimeCache.size. Данный параметр отвечает за то, сколько скомпилированных прокси-сервисов будет храниться в кэше. По-умолчанию его значение равно 100.

OSB реализует следующую логику - прокси-сервис компилируется при первом использовании и помещается в кэш. Если кэш переполнен (т.е. прокси-сервисов более 100), то сервисы удаляются из кэша, а затем, при последующих обращениях, повторно компилируются. Соответственно, если на шине развернуто много прокси-сервисов, что характерно для больших SOA-окружений, развернутых в крупных предприятиях со множеством филиалов, то ее производительность падает. Нужно увеличивать значение данного параметра.

Сделать это можно с помощью аргумента командной строки:

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000

Данный параметр можно добавить в определение переменной окружения EXTRA_JAVA_PROPERTIES в файле setDomainEnv.sh/cmd.

Понравилось сообщение - подпишитесь на блог и Twitter

Локальная оптимизация вызовов сервисов в Oracle SOA Suite

В Oracle SOA Suite реализован механизм локальной оптимизации вызовов сервисов, реализованных так же на Oracle SOA Suite. Т.е. если мы из одного композита вызываем с помощью Web Service Adapter сервис, реализованный в другом композите, то в реальности Oracle SOA Suite не будет формировать SOAP-сообщение и делать вызов по протоколу HTTP. Вместо этого он просто выполнит соответствующий код на JVM, на которой запущен Oracle SOA Suite, а значит и клиент сервиса, и его реализация.

Соответствующая оптимизация обладает как преимуществами, так и недостатками.

Преимущества:

• Повышение быстродействия: не тратится время на сериализацию параметров вызова в SOAP-сообщение, передачу данных по сети, а так же обратную десериализацию SOAP-сообщения с ответом.
  
  
• Распространение контекста транзакции: т.к. в реальности вместо сетевого взаимодействия вызывается код, работающий на той же JVM, то и инициатор вызова, и вызываемый сервис работают в рамках одной транзакции - если после изменения данных сервисом на клиенте произошел сбой, то транзакция откатывается и изменения не будут сохранены.
  

Недостатки:

• Отсутствие возможности балансировки нагрузки: при локальной оптимизации всегда будет вызван экземпляр сервиса, расположенный на том же узле кластера, на котором расположен клиент сервиса.
  
  
• Проблемы при работе механизма политик OWSM, в частности, связанных с безопасностью. Не все политики OWSM работают в режиме локальной оптимизации вызовов, соответственно, разработчик может ожидать, что для вызова из композита сервиса, реализованного в другом композите, будет требоваться авторизация, а в реальности, т.к. политика не сработала, то никакой авторизации не потребуется, сервис будет доступен любому пользователю.
  

Локальная оптимизация вызовов включена по-умолчанию, но ее можно отключить. Делается это путем выставления значения свойства oracle.webservices.local.optimization в false. Выставить данное свойство в false можно как в композите-провайдере сервиса, тогда локальная оптимизация будет отключена для всех вызовов сервиса, так и в композите-клиенте, тогда локальная оптимизация будет отключена только для этого клиента.

<binding.ws
    port="http://xmlns.oracle.com/CalledBPELProcessApp_
    jws/CalledBPELProcess/CalledBPELProcess#wsdl.endpoint(calledbpelprocess_client_
    ep/CalledBPELProcess_pt)"
    location="http://localhost:8001/soa-infra/services/default/CalledBPEL
    Process!1.0/calledbpelprocess_client_ep?WSDL">
      <wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
                           orawsp:category="security"
                           orawsp:status="enabled"/>
      <wsp:PolicyReference URI="oracle/log_policy"
                           orawsp:category="management"
                           orawsp:status="enabled"/>
      <property name="oracle.webservices.local.optimization">false</property>
</binding.ws>

Понравилось сообщение - подпишитесь на блог и Twitter

Практический пример построения сервиса на Oracle Service Bus

В данной заметке мы рассмотрим практический пример построения веб-сервиса, работающего по протоколу HTTP с использованием сообщений в формате SOAP (SOAP over HTTP), функциональность которого заключается в предоставлении доступа к бизнес-логике существующего приложения. Приложением является биллинговая система, реализованная на основе двухзвенной архитектуры. Связь сервисной шины предприятия и приложения будет осуществляться с помощью JDBC путем вызова хранимых процедур в базе данных биллинга. Разрабатываемый сервис будет предоставлять доступ к управлению счетами: получение данных о счете, создание счета и отмена счета.

Предполагается, что мы пройдем по всем этапам разработки интеграционного решения от создания адаптеров и проекта OSB, до настройки среды исполнения и развертывания разработанного сервиса. Так же рассмотрим процесс тестирования с помощью SOAP UI. Будет интересно!

Пример разработки веб-сервиса по контракту с использованием Oracle SOA Suite и Spring Framework

В прошлых заметках мы рассмотрели теоретические вопросы проектирования контракта сервиса и валидации сообщений с помощью XShema и Schematron. В данной статье продемонстрируем использование этих знаний на практике: создадим веб-сервис, основываясь на его контракте. В качестве технологической платформы будем использовать Oracle SOA Suite и Spring Framework.

Разработка контракта сервиса

Для простоты и наглядности возьмем какую-нибудь несложную задачу, например разработку сервиса-калькулятора, выполняющего основные арифметические действия. Данный пример очень хороший, так как позволяет продемонстрировать применение как синтаксической (выполнять арифметические операции можно только над числами), так и семантической (делить на нуль нельзя) валидации поступающих на вход сервиса сообщений.

Валидация XML-сообщений

В статье Проектирование контракта сервиса мы отметили, что действительно самодокументируемый контракт подразумевает возможность автоматической валидации сообщений, которыми данный сервис общается с внешним миром. Пришло время рассмотреть данный процесс подробнее.

Прежде всего давайте разберемся в каких случаях необходима валидация сообщений.

1. Мы можем ничего не знать о клиенте нашего сервиса, соответственно нам необходимо проверить запросы, поступающие от данного клиента, перед тем как их обрабатывать.
   
   
2. Сообщения, поступающие от внешних сервисов, т.е. сервисов, которые мы не контролируем, должны подвергаться валидации.
   

Лучшей практикой считается вызов внешних сервисов через ESB. Данное решение позволяет вынести валидацию на шину и реализовать ее один раз, вместо того, чтобы реализовывать ее везде, где используется конкретный сервис.

Не обязательно осуществлять валидацию сообщений в следующих случаях:

1. Если сообщение передается от одного компонента к другому внутри композитного приложения, то необходимости валидации нет: это наше приложение, мы его полностью контролируем.
   
   
2. Во внутренних сервисах или других контролируемых нами приложениях валидация обычно не требуется, но может быть реализована. В случае, если внутренний сервис осуществляет обработку данных, вводимых пользователями, то валидация необходима.
   

В данной заметке мы рассмотрим некоторые приемы валидации сообщений, а так же способы обработки ошибок, возникающих при проверке некорректных сообщений.

Паттерны проектирования XML-схем

В данной заметке мы продолжим тему разработки контрактов сервисов. В предыдущей статье мы отметили, что стандартом де-факто в настоящее время для представления контрактов сервисов является WSDL. Предполагается, что общение с сервисом осуществляется посредством сообщений, представленных в формате XML. Структура данных сообщений описывается с помощью языка XML Schema.

Существует несколько паттернов проектирования XML-схем. Использование данных паттернов позволяет описать одну и ту же структуру XML-документа разными способами, каждый из которых имеет свои преимущества и недостатки. Рассмотрим данные способы подробнее.

Проектирование контракта сервиса

Основным компонентом сервисно-ориентированной архитектуры является, как это видно из названия, сервис. Соответственно, основной задачей архитектора является разбиение функциональности на сервисы. При этом каждый сервис определяется своим контрактом.

Контракт сервиса должен однозначно описывать его интерфейс и семантику. В идеальном случае контракт должен быть самодокументируемым, т.е. по контракту должно быть понятно что это за сервис, какие у него есть методы, какие параметры принимают данные методы и какие результаты они возвращают. Если контракт по настоящему самодокументируемый, то по нему возможна автоматическая генерация кода. Другим преимуществом самодокументируемого контракта является возможность автоматической валидации запросов к сервису. Причем помимо валидации синтаксиса запроса (пример - валидация XML-документа по XSchema) возможна валидация семантики запроса (пример - использование Schematron). В настоящее время стандартом для представления контрактов сервисов является язык Web Services Description Language (WSDL). В данной заметке мы рассмотрим основные решения, которые должен принять архитектор при разработке WSDL-описания контракта сервиса, а так же приведем некоторые практические советы.

Пример использования Spring Framework совместно с SCA-контейнером Oracle WebLogic

В одной из предыдущих заметок я привел теоретическое описание компонентной архитектуры сервисов (SCA). Однако любая теория требует практического подкрепления, поэтому в данной заметке мы рассмотрим использование SCA-контейнера сервера приложений Oracle WebLogic и Spring Framework для реализации некоторых из довольно часто используемых паттернов интеграции корпоративных приложений (EIP) - Обогатитель данных (Data Enricher) и основанный на нем паттерн Квитанция (Claim Check).

Паттерн Обогатитель данных

Если есть две интегрируемые системы, одна из которых возвращает меньше данных, нежели нужно другой, то такие данные требуется обогащать - добавлять недостающие, получая их из некоторого хранилища. Например, по почтовому индексу, передаваемому системой-источником, можно получить во внешнем хранилище, например в БД КЛАДР, населенный пункт абонента и передать его в систему-приемник. В данном случае Обогатитель данных выступает специальным трансформатором преобразующим сообщение с неполным набором данных в итоговое сообщение. Важным компонентом данного паттерна является внешнее хранилище данных, которое может представлять собой СУБД, некоторое предустановленное корпоративное приложение или публичную службу.

Паттерн Квитанция

Данный паттерн решает следующую проблему: передаваемое через интеграционный слой, например через очередь, сообщение слишком большое, а его обработка осуществляется в несколько шагов. Чтобы не передавать большое сообщение на каждый шаг обработки, что может повлечь снижение производительности системы, можно поступить следующим образом: сохранить сообщение во внешнем хранилище, например в СУБД, а передавать некоторую квитанцию - сообщение, содержащее лишь указатель на сохраненные данные. При этом в том узле, в котором необходимо получить доступ к содержимому сообщения, оно извлекается из хранилища с помощью паттерна Обогатитель данных.

Асинхронный веб-сервис на Oracle Service Bus

Обеспечить асинхронное взаимодействие с веб-сервисом по протоколу HTTP можно не только с помощью Oracle SOA Suite, но и с помощью Oracle Service Bus. Основная сложность при этом заключается в том, что Oracle Service Bus не содержит встроенных средств сохранения состояния, поэтому необходимо будет каким-то образом сохранить во внешней памяти URL сервиса обратного вызова и идентификатор сообщения, на которое мы отвечаем. Так же нам нужно будет самостоятельно сформировать заголовок ответного SOAP-сообщения, соответствующий спецификации WS-Addressing. Давайте посмотрим как это можно сделать.