В своем последнем сообщении в этом блоге я рассмотрел интеграцию ESB-jBPM в платформу SOA. На этот раз мы рассмотрим один аспект интеграции с правилами JBoss.
Введение
Маршрутизация данных из одного места в другое является одной из самых основных и распространенных проблем, с которыми сталкивается любое сетевое программное приложение. Эта маршрутизация может принимать различные формы, такие как отправка электронной почты нужному получателю или сетевой трафик, направляемый по всему миру на основе имен систем, определенных в DNS.
В контексте корпоративной сервисной шины, такой как JBoss ESB в платформе SOA, где все является либо сообщением, либо службой, маршрутизация означает получение сообщений, доставляемых нужным службам. Есть несколько способов направить данные в сервис. Эти статические маршруты можно определить статически, что может иметь смысл для приложения, в котором данные определенного типа всегда направлены на заданную конечную точку. Но этот подход потерпит неудачу, если служба назначения недоступна или перемещена. Вы можете контролировать маршрут, по которому сообщения проходят через ESB, несколькими способами. В этом посте мы рассмотрим сообщения маршрутизации на основе содержимого сообщения с шаблоном маршрутизации на основе содержимого, как показано в одной из примеров программ быстрого запуска SOA Platform.
Правила JBoss
Одной из серьезных проблем при разработке программного обеспечения для бизнес-приложений является разделение между бизнес-логикой или «правилами», которыми вы хотите управлять приложением, и задачами технического программирования, необходимыми для фактической сборки приложения. Более того, поддерживать код приложения может быть дорого и сложно, и поддерживать его синхронизированным с постоянно меняющимися бизнес-условиями и при этом не разрушать первоначальный дизайн и не превращать код в набор все более сложных операторов if-then-else. Необходим механизм определения бизнес-правил, а затем их выполнения без необходимости жесткого кодирования правил в код приложения.
Что нужно, это механизм правил. JRS-94 [1] определяет стандарт для API механизма правил Java. Стандарт определяет API для регистрации, извлечения и выполнения правил. JBoss Drools [2] (называемый JBoss Rules в платформе SOA) основан на этом стандарте, но не только API правил и язык программирования правил, Drools является полной корпоративной платформой для разработки приложений, рабочих процессов и администрирования на основе правил. и обработка событий. Он также обеспечивает интеграцию с JBossESB для поддержки маршрутизации на основе контента.
Давайте начнем с изучения термина «маршрутизация на основе контента». [3] Часть термина «маршрутизация» проста; мы говорим о том, чтобы сообщения направлялись на правильный сервис. Когда мы говорим о «основанной на контенте» маршрутизации, мы хотим, чтобы ESB исследовал сообщение и, основываясь на его содержимом, выбрал правильный путь маршрутизации. Но мы не хотим иметь код для принятия решений о маршрутизации, встроенный в сервисы или сам ESB. Мы хотим использовать подход, основанный на правилах, где мы можем воспользоваться мощью и гибкостью языка определения правил для построения маршрутизации принятия решений. Мы также хотим воспользоваться эффективностью механизма правил для выполнения этой маршрутизации, вместо того, чтобы кодировать сложные и сложные для поддержки операторов if-then-else в приложении.
ОК. Пришло время взглянуть на рабочий пример.
Одной из замечательных особенностей платформы SOA является ее обширный набор программ быстрого запуска. Эти программы иллюстрируют различные функции, поддерживаемые ESB. Для нашего примера мы рассмотрим быстрый запуск fun_cbr.
Как и многие из быстрых стартов, fun_cbr начинается с помещения сообщения в очередь. Служба, прослушивающая эту очередь, затем принимает это сообщение и отправляет его в службу назначения. В этом кратком обзоре нам интересно посмотреть, как содержимое этого сообщения определяет маршрут, по которому сообщение попадает в одну из трех определенных служб назначения.
Давайте начнем с изучения сообщения и его содержания. При запуске быстрого запуска файл «SampleOrder.xml» (для мифического хранилища DVD) — это файл, который читается в отправляемом сообщении. Файл выглядит так:
В SampleOrder.xml:
<Order xmlns="http://org.jboss.soa.esb/Order" orderId="1" statusCode="0"
netAmount="59.97" totalAmount="64.92" tax="4.95">
<Customer userName="user1" firstName="Harry" lastName="Fletcher" state="SD"/>
<OrderLines>
<OrderLine position="1" quantity="1">
<Product productId="364" title="The 40-Year-Old Virgin " price="29.98"/>
</OrderLine>
<OrderLine position="2" quantity="1">
<Product productId="299" title="Pulp Fiction" price="29.99"/>
</OrderLine>
</OrderLines>
</Order>
В этом контенте нет ничего необычного (за исключением, возможно, вкуса Гарри в кино). Запомните элемент statusCode в строке # 1. Мы вернемся к этому немного позже.
Итак, мы создали сообщение, содержащее это содержимое, и поместили это сообщение в очередь, чтобы служба могла получить его и выполнить с ним действие. Что теперь?
Давайте посмотрим на это действие в файле «jboss-esb.xml». (Этот файл определяет конфигурацию и действия, выполняемые при
быстром запуске .) В jboss-esb.xml:
44 <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
45 <property name="ruleSet" value="FunCBRRules-XPath.drl"/>
46 <property name="ruleLanguage" value="XPathLanguage.dsl"/>
47 <property name="ruleReload" value="true"/>
48 <property name="destinations">
49 <route-to destination-name="blue" service-category="BlueTeam" service-name="GoBlue" />
50 <route-to destination-name="red" service-category="RedTeam" service-name="GoRed" />
51 <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
52 </property>
53 </action>
Давайте посмотрим на этот раздел файла построчно:
Строка 44: Класс org.jboss.soa.esb.actions.ContentBasedRouter является одним из предопределенных «готовых действий» платформы SOA. Платформа SOA предоставляет набор этих действий, которые вы всегда можете дополнить, написав свои собственные пользовательские действия [4]. Прежде чем писать свои собственные, вы должны взглянуть на готовые действия, поскольку вы можете найти те, которые соответствуют потребностям вашего приложения.
Строка 45: Здесь мы определяем набор правил, которые управляют маршрутизацией на основе контента. Помните, что в этом контексте правила определяются как правила JBoss. Мы рассмотрим эти правила всего за минуту.
Строка 46: чтобы иметь возможность анализировать информацию из данных XML в сообщении, платформа SOA включает в себя реализацию на языке домена (DSL) для использования XPath для обхода XML. Это определено в файле jboss-as / server / production / deploy / jbrules.esb / XPathLanguage.dsl. Если вы не знакомы с XPath [5], его действительно стоит изучить, поскольку в нем много полезных приложений. Например, некоторые инструменты автоматизации графического интерфейса, такие как Selenium, поддерживают использование XPath для определения местоположения элементов пользовательского интерфейса, если вы не можете полагаться на элементы пользовательского интерфейса, имеющие статические идентификаторы. Также обратите внимание, что XPathLanguage.dsl поддерживает как синтаксисы, специфичные для пространства имен, так и не относящиеся к пространству имен. В этом кратком обзоре используется специальный синтаксис пространства имен.
Строка 47: это свойство позволяет указать, должны ли правила перезагружаться при каждом их использовании. Это не влияет на небольшой набор правил, используемых в быстром запуске, но может привести к снижению производительности большого набора правил. Таким образом, установив для этого параметра значение «true», вы можете изменять правила, определенные в копии FunCBRRules-XPath.drl, развернутой на сервере, без необходимости повторного развертывания быстрого запуска на сервере SOA-P. Изменение локальной копии файла правил не приведет к перезагрузке правил. Вы должны обновить файл drl, который развернут с помощью быстрого запуска.
Строки 49-51: это маршруты к услугам назначения.
Теперь пришло время взглянуть на правила, которые определены в FunCBRRules-XPath.drl
В FunCBRRules-XPath.drl:
package com.jboss.soa.esb.routing.cbr
#list any import classes here.
import org.jboss.soa.esb.message.Message;
import org.jboss.soa.esb.message.format.MessageType;
expander XPathLanguage.dsl
#declare any global variables here
global java.util.List destinations;
rule "Blue Routing Rule using XPATH"
when
xpathEquals expr "/order:Order/@statusCode", "0" use namespaces "order=http://org.jboss.soa.esb/Order"
then
Log : "Blue Team";
Destination : "blue";
end
rule "Red Routing Rule using XPATH"
when
xpathEquals expr "/order:Order/@statusCode", "1" use namespaces "order=http://org.jboss.soa.esb/Order"
then
Log : "Red Team";
Destination : "red";
end
rule "Green Routing Rule using XPATH"
when
xpathEquals expr "/order:Order/@statusCode", "2" use namespaces "order=http://org.jboss.soa.esb/Order"
then
Log : "Green Team";
Destination : "green";
end
Строка 7: Вот ссылка на определения XPath.
Строка 10: глобальная переменная адресатов — это точка интеграции с адресатами, определенными в файле jboss-esb.xml.
Все правила одинаковы, за исключением значения кода состояния, поэтому мы рассмотрим только одно из них. (В процессе мы пройдем небольшой урок по написанию правила.)
Строка 12: начало определения правила.
Строка 13: начало конструкции правила «когда». Каждое определение правила включает конструкцию «когда» (критерии, которые должны быть выполнены) и конструкцию «тогда» (действие, которое необходимо выполнить, если соблюдается конструкция «когда»).
Строка 14: синтаксис XPath переводится как «начиная с корня документа, найдите элемент Order с атрибутом statusCode, равным 0.»
Строка 15: здесь начинается конструкция then.
Строка 16: создание сообщения журнала.
Строка 17: добавление имени места назначения в глобальный список, называемый «места назначения», который затем оценивается org.jboss.soa.esb.actions.ContentBasedRouter, который вызвал правило.
Если вы немного растерялись сейчас, эта диаграмма может показать, как все связано. 
Так что же происходит, когда быстрый запуск развернут и запущен?
- Входящее сообщение помещается в очередь, которую отслеживает прослушиватель, настроенный с помощью действия ContentBasedRouter.
- Это действие настраивается с помощью набора правил, определенного в FunCBRRules-XPath.drl.
- Класс действия помещает сообщение в рабочую память Правил и запускает правила
- На основании результатов правил создается список направлений
- И сообщение отправляется службам по этим направлениям — в случае этого теста сообщение отправляется синей команде
(На самом деле есть немного больше для входящего сообщения. JBoss ESB фактически маршрутизирует сообщения, отформатированные в ESB, в сервисы. ESB поддерживает адаптеры для включения других форматов для входящих сообщений. Эти адаптеры работают со службами «шлюза», чтобы позволить вам подключать существующие сервисы к платформе SOA. [6])
Заключительные мысли
Как мы уже говорили во введении, одной из сильных сторон платформы SOA является набор интеграций, которые она поддерживает. Благодаря интеграции с правилами JBoss вы можете развертывать службы на основе правил на сервере платформы SOA и использовать правила JBoss для маршрутизации на основе контента. При маршрутизации на основе содержимого информация в самих сообщениях определяет адресатов сообщений.
Ссылки
[1]
http://jcp.org/en/jsr/detail?id=94
[2]
http://www.jboss.org/drools
[3]
http://www.jboss.org/jbossesb/docs/4.3.GA/manuals/html/services/ContentBasedRouting.html
[4]
http: / /www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html/Programmers_Guide/ch11s05.html
[5]
http://www.w3schools.com/XPath/default.asp
[6]
http: / /magazine.redhat.com/2008/05/22/adapters-for-an-esb
Благодарности
Как всегда, я хотел бы поблагодарить членов JBossESB (см. Http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/Contributors.txt), проекты JBoss Rules, проект платформы SOA — особенно Burr Sutter. , Марк Литтл, Марк Проктор и Ярек Кияновски — за помощь и своевременное комментирование! Кроме того, эта статья в значительной степени опирается на обширные пользовательские документы JBossESB и JBoss Rules и краткие руководства.