Показаны сообщения с ярлыком Oracle. Показать все сообщения
Показаны сообщения с ярлыком Oracle. Показать все сообщения

пятница, 9 июня 2017 г.

Валидация 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 ...

среда, 31 мая 2017 г.

Безопасность транзакций между доменами Oracle WebLogic Server

Управляя распределенной (XA) транзакцией, менеджер транзакций должен иметь возможность связываться со всеми участниками транзакции. Т.е. со всеми серверами и ресурсами в ней участвующими. Коммуникационные каналы настраиваются в зависимости от того, куда направляется транзакция:

  • Inter-domain - коммуникация между серверами, участвующими в транзакции и расположенными не в одном и том же домене

  • Intra-domain - коммуникация между серверами, участвующими в транзакции и расположенными в одном и том же домене.

Каналы коммуникации для транзакций должны быть защищенными, чтобы предотвращать от атак вида человек посредине. Сервер приложений Oracle WebLogic предоставляет следующие опции для защиты коммуникационных каналов:

  • Cross Domain Security - используется отображение учетных данных пользователей для настройки совместимого коммуникационного канала между серверами в транзакциях между доменами. Хотя это требует более сложной конфигурации, Cross Domain Security позволяет настроить доверие между отдельными доменами.

  • Security Interoperability Mode - устанавливает доверие между всеми доменами, которые участвуют в транзакции, путем
    установки для учетных данных всех доменов (domain credentials) совпадающих значений, т.е. principal из одного домена разрешен и в других. Этот режим проще для настройки чем Cross Domain Security, однако некоторые настройки Security Interoperability Mode полагаются на доверие домена и менее безопасны.

Рассмотрим преимущества и недостатки данных режимов.

четверг, 16 марта 2017 г.

Oracle BPM Suite 12.2.1.2 Quick Start: установка, настройка, развертывание и тестирование бизнес-процесса на языке BPMN 2.0

Oracle BPM Suite - решение от корпорации Oracle для моделирования и исполнения бизнес-процессов предприятия с использованием нотации BPMN 2.0. Для моделирования бизнес-процессов используется интегрированная среда разработки JDeveloper. Корпорация Oracle распространяет специальный дистрибутив продукта, предназначенный для разработчиков, который включает в себя сервер приложений Oracle WebLogic, на котором работает BPM Suite, сам BPM Suite и интегрированную среду разработки JDeveloper - Quick Start.


В данной статье мне хочется поделиться с читателями информацией о том, как получить пакет Oracle BPM Suite 12.2.1.2 Quick Start с сайта edelivery.oracle.com, установить его на машину разработчика, создать первый бизнес-процесс в JDeveloper, настроить встроенный в среду разработки домен сервера приложений, включающий в себя BPM Suite, SOA Suite, Oracle Service Bus и использующий Apache Derby в качестве СУБД, развернуть созданный процесс в данном домене и запустить его тестовый экземпляр.


вторник, 3 марта 2015 г.

Правильная платформа для Java EE приложения или как Линукс оказался в 3 раза медленее z/OS

Ваш покорный слуга написал еще одну статью на Хабрахабр - Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle.

Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".

Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".

P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.

UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.

UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.

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

вторник, 20 января 2015 г.

Кластер серверов приложений Oracle WebLogic Server забивает сеть при возникновении проблем

Не все администраторы знают, что по-умолчанию экземпляры сервера приложений Oracle WebLogic Server ведут логи не только в своих каталогах DOMAIN_HOME/server/SERVER/logs, но и пересылают их по сети на сервер администрирования домена. Это сделано для облегчения работы людей: если у вас домен из нескольких десятков экземпляров сервера приложений, то очевидно, что иметь все логи доступными в одном месте очень удобно. Но за данное удобство приходится платить.

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

На небольших доменах (4 - 8 экземпляров) я отключал/отключаю пересылку логов на сервер администрирования. В консоли администратора необходимо в настройках каждого управляемого сервера выставить свойство Domain log broadcaster:, Severity level на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced в значение Critical или даже более жесткое.


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

Для включения фильтрации необходимо создать один или несколько фильтров логов. Фильтры создаются для всего домена на странице DOMAIN -> Configuration -> Log Filters.


При создании нового фильтра достаточно задать его имя.


Если затем перейти в новый созданный фильтр, то с помощью кнопок на панели Expression можно сформировать условие фильтрации.


После редактирования условия нужно не забыть нажать кнопку Save. Отредактированный фильтр вместе с условием станет доступен на таблице Log Filters.


Теперь его можно назначить для свойства Domain log broadcaster:, Filter на странице Environment -> Servers -> SERVER -> Logging -> General, Advanced.


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

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

четверг, 11 декабря 2014 г.

Зачем нужны EJB

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

Прежде всего отмечу, что EJB - это часть стандарта Java EE, отвечающая за организацию бизнес-логики и предоставляющая декларативное управление безопасностью, долговременным хранением данных, глобальными транзакциями, распределенными объектами, кластеризацией и подпиской на сообщения. Основная задача данного стандарта: освободить программиста от реализации низкоуровневых вещей.

Основной альтеративой EJB долгие годы является Spring Framework, который, однако, ни одну из вышеперечисленных задач не решает самостоятельно. Есть отвевления в проекте Spring Framework, отвечающие за модульность (Spring DM), безопасность (Spring Security), и т.д. но при этом нет реализации Single Sign-On (SSO), нет менеджера глобальных и распределенных транзакций, Spring Framework умеет только подключаться к существующим, предоставляемым как правило полноценными серверами приложений. Что касается кластеризации, то она в Spring Framework как таковая отсутствует, т.е. можно развернуть две копии приложения на каком-нибудь Tomcat, но за репликацию сессий, если таковые используются, будет отвечать сам контейнер сервлетов, а за вызов обеих копий по протоколу HTTP - какой-нибудь внешний балансировщик нагрузки, сам фреймворк при этом не причем. При использовании же EJB мы, во-первых, не привязаны к протоколу HTTP и внешнему балансировщику нагрузки: EJB-клиент является сам себе балансировщиком, да к тому же работает по более быстрому протоколу; во-вторых же, обеспечивается прозрачное для клиента восстановление после сбоев: если вы отметили метод сессионного компонента как идемпотентный, то в случае сбоя вызов от клиета (сервлета или RMI/IIOP-клиента) автоматически будет перенаправлен на экземпляр компонента, расположенный на другом сервере. Клиент тем самым даже не заметит проблемы.

Т.е. Spring Framework выступает топором в одноименной каше: он очень крут, но для решения задачи нужно сыпануть в варево порцию библиотек, перемешать и молиться, чтобы ничего не сбоило и не конфликтовало друг с другом. JAR-Hell. Так же носить с собой ворох библиотек в WEB-INF/lib - удовольствие ниже среднего.

Основными недостатками EJB считают многословность, трудоемкость для разработчика, большие XML-дескрипторы и т.д. Но это все давно в прошлом. Начиная с EJB 3.0, это уже практически новая технология, лаконичная, активно использующая аннотации как средство описания метаданных. Появившиеся в EJB 3.1 и Java EE 6 нововведения делают альтернативные средства, такие как Spring Framework, Google Guice, Tapestry IoC и т.д. ненужными. Да, когда-то они решали свою задачу: облегчать программисту доступ к низкоуровневым сервисам, минуя EJB, но теперь данная задача не актуальна. У нас в сервере приложений из коробки доступны: IoC-контейнер, менеджер глобальных и распределенных транзакций, декларативные настройки безопасности, огромное количество различных провайдеров безопасности (хранение данных пользователей хоть в LDAP, хоть в БД, хоть в специализированных решениях, авторизация хоть по паролю, хоть по сертификату, контроль сертификатов, цепочки отзыва, Single Sign-On (SSO), сквозная по всем приложениям авторизация и аутентификация, когда сервер приложений определяет, имеет ли право пользователь, вошедший по сертификату, писать в очередь A и читать данные из БД под пользователем B, гибкая система прав доступа, когда ровно в 18:00 администратор превращается в тыкву и т.д.), полноценная кластеризация, работа с очередями сообщений и внешними информационными системами. И EJB - самый простой с точки зрения программиста способ воспользоваться данным богатством, при этом ваш код будет по прежнему состоять из старых-добрых POJO, использовать JPA или JDBC и вызываться из любого веб-фреймворка, который вам нравится.

Вот мое мнение о том, зачем нужны EJB в современном мире разработки корпоративных приложений.

UPD: по мотивам статьи разгорелась интересная дискуссия.

UPD2: Сделал небольшой бенчмарк: EJB показывает на 10 - 15% лучшую производительность нежели Spring Framework.


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

пятница, 27 июня 2014 г.

Долгожданный релиз 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 и только потом читать, мартышка к старости слаба глазами стала...

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

среда, 20 ноября 2013 г.

Новый механизм экспорта OSB проектов - OSB Offline Configuration Export или configjar

Начиная с версии 11.1.1.7 в состав Oracle Service Bus добавлена утилита для экспорта конфигурации без использования Eclipse. Данная утилита расположена в каталоге OSB_HOME/tools/configjar и позволяет экспортировать настройки шины из исходников в jar-файл для последующего развертывания.

Полная документация по утилите представлена в приложении B. Exporting an Oracle Service Bus Configuration Offline официального руководства Oracle Fusion Middleware Developer's Guide for Oracle Service Bus 11g Release 1 (11.1.1.7). Не вижу смысла пересказывать данное руководство, напишу только об опыте использования утилиты.

Экспортировать конфигурацию с использованием configjar можно из командной строки, Apache Ant и WebLogic Scripting Tool (WLST). В качестве аргумента во всех случаях необходимо передать путь к конфигурационному файлу, содержащему настройки экспорта. Подразумевается, что перед использованием утилиты пользователь выполнит скрипт OSB_HOME/tools/configjar/setenv.bat и тем самым установит нужные переменные окружения, настроит CLASSPATH и подготовит среду к работе. Я же стараюсь писать скрипты сборки таким образом, чтобы они работали без необходимости настраивать окружение. Только build.xml и конфигурационные файлы. Такой перфекционизм создает ряд проблем.

Во-первых, мне не удалось заставить работать команду для Apache Ant - com.bea.alsb.tools.configjar.ant.ConfigJarTask. Данная команда требует установленной переменной окружения weblogic.home. Разобраться как передать значение данной переменной окружения команде не удалось. Однако выход есть - запускать экспорт с помощью команды java, используя класс com.bea.alsb.tools.configjar.ConfigJar:


<java fork="true" 
      dir="${deploy.dir}"
      classname="com.bea.alsb.tools.configjar.ConfigJar"            
      failonerror="true" 
      maxmemory="${osb.export.maxmem}">
    <jvmarg line="-XX:MaxPermSize=256m"/>
    <arg line="-settingsfile ${export.config.file}"/>
    <sysproperty key="weblogic.home" value="${wl.home}"/>
    <sysproperty key="osb.home" value="${osb.home}"/>   
    <sysproperty key="user.language" value="en"/>
    <sysproperty key="user.country" value="US"/>
    <classpath refid="osb_classpath"/>
</java>

Во-вторых, для работы класса com.bea.alsb.tools.configjar.ConfigJar нужно подобрать CLASSPATH. Экспорт удалось настроить, используя следующие классы:


<property name="weblogic.classpath" value="${wl.home}/server/lib"/>
<property name="osb.lib.classpath" value="${osb.home}/lib"/>
<property name="osb.tools.classpath" value="${osb.home}/tools/configjar"/>
<property name="osb.modules.classpath" value="${osb.home}/modules"/>
<property name="osb.soa.modules.classpath" value="${osb.home}/soa/modules"/>
<property name="common.modules.classpath" value="${mw.home}/oracle_common/modules"/>

<path id="osb_classpath">
    <fileset dir="${weblogic.classpath}">
        <include name="weblogic.jar"/>     
    </fileset>
    <fileset dir="${osb.lib.classpath}">
 <include name="alsb.jar"/>   
 <include name="external/log4j_1.2.8.jar"/>
    </fileset>  
    <fileset dir="${osb.modules.classpath}">
 <include name="features/osb.server.modules_11.1.1.7.jar"/>      
    </fileset>  
    <fileset dir="${osb.soa.modules.classpath}">
 <include name="oracle.soa.common.adapters_11.1.1/oracle.soa.common.adapters.jar"/>
    </fileset>  
    <fileset dir="${common.modules.classpath}">
 <include name="oracle.jrf_11.1.1\jrf-api.jar"/>
        <include name="oracle.http_client_11.1.1.jar"/>
 <include name="oracle.xdk_11.1.0\xmlparserv2.jar"/>
 <include name="oracle.webservices_11.1.1\orawsdl.jar"/>
 <include name="oracle.wsm.common_11.1.1\wsm-dependencies.jar"/>   
    </fileset>
    <fileset dir="${osb.tools.classpath}">
 <include name="configjar.jar"/>
 <include name="L10N"/>
    </fileset>
</path>

В-третьих, утилита экспорта может работать в двух режимах: экспорт на уровне проектов и экспорт на уровне отдельных ресурсов. В любом из режимов соответствующие сущности - проекты и ресурсы - требуется явно перечислить. В моей разработке необходимо организовать взаимодействие со многими (более сорока) экземплярами одной и той же информационной системы, при этом используется подход "один проект для взаимодействия с одним экземпляром системы". Получается, что нужно каким-то образом динамически сформировать список проектов для экспорта. Так как файл с настройками экспорта представляет собой XML, то для его формирования идеально подходит технология XSLT, тем более, что Apache Ant ее поддерживает из коробки. Нужно лишь сформировать XML-файл с перечислением проектов и прогнать его через преобразование. За одно можно так же в зависимости от среды (продуктив, разработка, тестирование), для которой осуществляется сборка, указать наименование jar-файла, который будет содержать результаты экспорта.

Исходными данными для формирования списка проектов является свойство projects из файла настроек сборки (например, build.properties). Значением данного свойства являются собираемые проекты, перечисленные через запятую. Наша задача обойти данное перечисление и сформировать XML со списком проектов. Для формирования XML можно использовать команду echo:


<echo message="&lt;projects&gt;" file="${deploy.dir}/projects.xml"/>
<for list="${osb.projects}"
     delimiter=","
     param="project.name">
    <sequential>
        <echo message="&lt;project&gt;@{project.name}&lt;/project&gt;"
       file="${deploy.dir}/projects.xml"
       append="true"/>
    </sequential>
</for>
<echo message="&lt;/projects&gt;" file="${deploy.dir}/projects.xml"
      append="true"/>

Теперь полученный файл со списком проектов можно отправить на XSLT-преобразование. Так же в качестве параметра передадим требуемое имя выходного файла с кодом для шины:


<xslt in="${deploy.dir}/projects.xml"
      out="${export.config.file}"
      style="${deploy.dir}/export.settings.xsl">          
    <param name="exportfile" expression="${osb.export.jar}"/>
</xslt>

Само XSLT-преобразование выглядит следующим образом:


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    version="2.0">
    <xsl:param name="exportfile" required="yes" as="xs:string"/>
    <xsl:output method="xml" omit-xml-declaration="yes" indent="yes"/>
    
    <xsl:template match="/">
        <configjarSettings xmlns="http://www.bea.com/alsb/tools/configjar/config">
            <source>
                <xsl:for-each select="projects/project">
                    <project>
                        <xsl:attribute name="dir">build/<xsl:value-of select="."/></xsl:attribute>
                    </project>
                </xsl:for-each>    
                <system dir="build/_OSB Integration"/>
            </source>
            <configjar>
                <xsl:attribute name="jar">
                    <xsl:value-of select="$exportfile"/>
                </xsl:attribute>
                <projectLevel includeSystem="true"/>
            </configjar>
        </configjarSettings>
    </xsl:template>
</xsl:stylesheet>

Других проблем при использовании configjar не было.

Субъективные впечатления от новой утилиты исключительно положительные. Описанные выше проблемы тем или иным образом решаются, а кода теперь требует значительно меньше, чем для вызова Eclipse из Apache Ant. Памяти новый процесс сборки потребляет гораздо меньше, а работает быстрее. Экспорт шины, состоящей из 48 проектов и содержащей 954 прокси-, 28 бизнес-сервисов и 2300 XQuery-преобразований осуществляется за две минуты.

Концептуально конечно же завязывать сборку проектов на среду исполнения неверно. Представим себе, что компиляция Java EE-приложения не работала бы без установленного сервера приложений. Гораздо логичнее, когда сборка выполняется с помощью только средства разработки, без привлечения среды исполнения, как в том же IBM WebSphere Message Broker'е. Однако в Oracle Service Bus нельзя установить Eclipse и соответствующие плагины без самой OSB. Тяжелое наследие BEA. В итоге, если раньше человеку, ответственному за сборку, нужно было устанавливать и Eclipse, и OSB, то сейчас достаточно только установить OSB, что дает некоторый выигрыш во времени и числе подготовительных действий. В конце концов можно вообще ничего не устанавливать, а сборку производить на сервере разработки, сгружая туда исходники из SVN.

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

среда, 6 ноября 2013 г.

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 - диспетчером событий.

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

понедельник, 16 сентября 2013 г.

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

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

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

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

вторник, 20 августа 2013 г.

Как мы обеспечили передачу с гарантированной доставкой 5 000 000 сообщений в сутки с помощью Oracle Service Bus

Сейчас работаю над проектом интеграции вновь внедряемой централизованной бизнес-системы с другими системами, установленными в филиалах заказчика. При этом основная задача заключается в том, чтобы синхронизировать данные в филиалах и центре с помощью сервисной шины предприятия (ESB), реализованной на платформе Oracle Service Bus. Мы смогли обеспечить передачу с гарантированной доставкой боле 5 000 000 сообщений в сутки. В данной статье хочу рассказать о том, как это было сделано.


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


Нам необходимо передавать изменения данных из одной системы (системы-источника) в другую - систему-приемник. Данные должны передаваться сразу, а не с помощью пакетной обработки. Соответственно, нужно каким-то образом захватывать события об изменении данных и публиковать их для сервисной шины. Хорошо зарекомендовал себя следующий паттерн: при изменении данных пользователем с помощью триггера в БД системы-источника формируется событие, которое записывается в специальную таблицу. У события есть идентификатор, признак типа - какая именно сущность была создана или изменена, тип операции: создание, изменение или удаление, статус: новое, на обработке, обработанное успешно или обработанное с ошибкой. По идентификатору события мы с помощью соответствующего типу сущности представлению можем получить актуальные на момент обработки события данные. Сервисная шина последовательным опросом таблицы событий (по-другому это называется "полинг") считывает порцию измененных данных, затем для каждого считанного события обращается к соответствующему представлению и получает данные. Данные трансформируются в канонический формат шины, при этом на одну считанную запись может быть сформировано от нуля до пяти сообщений. Сообщения записываются в JMS-очередь, а записям в таблице событий проставляется статус "на обработке". Другой компонент адаптера - прокси-сервис, использующий транспорт JMS, считывает сообщения в каноническом формате из очереди, преобразует их в формат системы-приемника и вызывает веб-сервис, предоставляемый данной системой. Адаптер ждет окончания работы сервиса, после чего получает статус обработки сообщения и записывает его в специальную очередь ответов. Статус считывается шиной из очереди ответов и обновляется в таблице событий системы-источника.

На диаграмме UML данный процесс будет выглядеть следующим образом:


Стоит заметить, что с одной стороны события считываются из базы порциями, по 120 событий за один раз. Таким образом 5 000 000 событий в сутки это 41 600 транзакций. С другой стороны каждая запись раскладывается на от нуля до пяти сообщений, в среднем примем два. Каждое такое сообщение должно быть передано в систему-приемник, получается 10 000 000 транзакций. После этого для каждого события необходимо обновить статус - 5 000 000 транзакций. При этом все транзакции распределенные, т.к. в них участвует по меньшей мере два ресурса: база - очередь или очередь - очередь. Итого получается, что производительность системы должна быть не меньше 180 транзакций в секунду. Это конечно не то, что пафосно называют словом HighLoad, но уже возможно всего в одном - двух порядках от него.

понедельник, 10 июня 2013 г.

Коммуникация в кластере серверов приложений Oracle WebLogic

В данной заметке мы рассмотрим довольно важный для понимания настройки и поддержки серверов приложений Oracle WebLogic вопрос - вопрос коммуникации в кластере.

Общие положения


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

  • IP-сокеты - для коммуникации вида точка-точка между участниками кластера;

  • IP unicast и multicast для распространения информации о доступности серверов и их состоянии, а так же для построения кластерного JNDI-дерева.

При создании кластера с помощью Configuration Wizard по умолчанию устанавливается режим обмена unicast, а при создании кластера с помощью WLST - multicast. Если есть проблемы с распространением JNDI-дерева на кластер с помощью unicast, то может помочь использование нового свойства - ClusterMBean.MessageOrderingEnabled. По умолчанию данное свойство не включено. Чтобы его включить нужно добавить следующую строчку в config.xml:

<message-ordering-enabled>true</message-ordering-enabled>.

Если данная настройка не решает проблему, то нужно перейти на использование multicast режима.

среда, 29 мая 2013 г.

Интересное про сервер администрирования домена WebLogic

Как ведет себя домен сервера приложений WebLogic, если сервер администрирования аварийно завершает свою работу или по каким-то другим причинам становится недоступным?

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

среда, 15 мая 2013 г.

Удаление Oracle Fusion Middleware

Иногда нам нужно удалить из MIDDLEWARE_HOME какой-либо компонент, а может быть и MIDDLEWARE_HOME целиком. Сделать это можно следующим способом:

1. Удалить ненужный вам более компонент, например SOA Suite:
MIDDLEWARE_HOME/Oracle_SOA1/oui/bin/setup.exe -deinstall -jreLoc jre

здесь jre - путь к JRE на вашей машине. При необходимости можно удалить остальные компоненты Oracle Fusion Middleware, например OSB.

2. После удаления компонентов необходимо удалить oracle_common:
MIDDLEWARE_HOME/oracle_common/oui/bin/setup.exe -deinstall -jreLoc jre

3. После удаления Oracle Fusion Middleware можно удалить сервер приложений WebLogic:
MIDDLEWARE_HOME\wlserver_10.3\uninstall\uninstall.cmd

Если вы устанавливали WebLogic под одной JDK, а потом ее обновили или удалили и сейчас используете другую, то данная команда может не выполниться. Необходимо прописать правильный путь к JDK в переменной окружения JAVA_HOME в файле MIDDLEWARE_HOME\utils\uninstall\uninstall.cmd, после чего можно запустить данный файл.

4. Аналогичным образом удалить JDeveloper.

5. Удалить каталог MIDDLEWARE_HOME.

6. Удалить запись о MIDDLEWARE_HOME из файла C:\bea\beahomelist.

7. На ОС Windows необходимо удалить соответствующую группу программ из главного меню.

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

среда, 24 апреля 2013 г.

Соображения по использованию WorkManager'ов на сервере приложений Oracle WebLogic

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

Показания для вмешательства в работу пула потоков


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

  • Приоритеты потоков по-умолчанию - все потоки имеют равный приоритет - нас не устраивают (Fair Share).

  • Необходимо задать время ответа, к которому сервер приложений должен стремиться (Response Time).

  • Возможны взаимоблокировки при взаимодействии сервер-сервер, в данном случае необходимо настроить WorkManager с явно заданным ограничением числа потоков снизу (Minimum Threads Constraint).

  • При работе приложения используется общий для нескольких потоков пул соединений JDBC, тогда необходимо ограничить число этих потоков сверху (Maximum Threads Constraint).

Отдельно стоит заметить, что если на сервере приложений Oracle WebLogic развернута Oracle Service Bus, то для избежания взаимоблокировок при использовании Service Callout'ов необходимо, чтобы вызываемые таким образом сервисы имели отдельные WorkManager'ы. Подробнее про модель потоков OSB можно прочитать в одноименной статье.

понедельник, 22 апреля 2013 г.

О производительности: 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

вторник, 2 апреля 2013 г.

Локальная оптимизация вызовов сервисов в 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

суббота, 23 марта 2013 г.

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

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

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

вторник, 26 февраля 2013 г.

Включение административного канала на сервере приложений WebLogic

Сервер приложений Oracle WebLogic позволяет включить специальный защищенный сетевой канал для доступа администратора к запущенным экземплярам. Трафик по данному каналу имеет приоритет перед обычными запросами, обрабатываемыми сервером, поэтому даже, если все сервера домена будут находиться под высокой нагрузкой, администратор сможет выполнять свои задачи. Помимо этого административный канал можно применять для тестирования приложений. Так же следует отметить, что взаимодействие управляемых серверов и сервера администрирования так же осуществляется по административному каналу.

Перед включением административного канала необходимо настроить SSL для всех серверов домена. Рассмотрим настройку SSL с использованием сгенерированного самоподписанного сертификата.

пятница, 22 февраля 2013 г.

Правильное тестирование и обновление приложения на сервере приложений WebLogic

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