Одной из сильных сторон платформы JBoss SOA является то, как она позволяет вам соединять устаревшие приложения вместе. Как эти связи сделаны? Чтобы ответить на этот вопрос, мы должны подумать об осведомленности.
В этом контексте «осведомленность» относится к тому, являются ли ваши клиенты и службы приложений «ESB-осведомленными» или, другими словами, могут ли они понимать форматы сообщений и транспортные протоколы, используемые JBossESB в платформе SOA. Если вы (как программист) знакомы с ESB, то вы можете просто кодировать любые новые клиенты и сервисы, которые вы пишете, также с учетом ESB. ESB-клиенты и сервисы взаимодействуют друг с другом с помощью сообщений. Службы, поддерживающие ESB, идентифицируются с использованием ссылок на конечные точки (EPR). Эти ESB-совместимые сообщения имеют форму, определенную в org.jboss.soa.esb.
интерфейс сообщения.
ESB-совместимое сообщение [1] состоит из следующих компонентов:
- Заголовок: информация заголовка содержит такую информацию, как EPR получателя, EPR отправителя и, куда идет ответ, — общая функциональная информация уровня сообщения.
- Контекст: дополнительная информация, которая дополнительно объясняет сообщение; например, данные транзакции или безопасности, личность конечного получателя или HTTP-cookie-подобная информация.
- Тело: фактическая полезная нагрузка сообщения.
- Ошибка: любая информация об ошибке, связанная с сообщением.
- Вложение: любые вложения (дополнительные файлы), связанные с сообщением.
- Свойства: любые специфичные для сообщения свойства (например, свойство jbossesb.message.id является уникальным значением для каждого сообщения).
Но …
Как насчет случаев, когда устаревшие клиенты и сервисы не поддерживают ESB? Это внезапно становится сложным. Похоже, вам нужно будет создать множество нестандартных адаптеров, чтобы все эти комбинации клиентов и служб могли общаться друг с другом. Но не паникуйте и не начинайте строить собственную инфраструктуру. Поддержка взаимодействия между различными клиентами и сервисами является одной из целей платформы SOA.
Совместимость через адаптеры ESB
Один из способов, с помощью которого платформа SOA делает возможным это взаимодействие, — это использование шлюзовых адаптеров. Шлюз (org.jboss.soa.esb.listeners.gateway) — это служба, которая действует как мост между ESB-ориентированным и ESB-неосведомленным клиентом и службой. Шлюзы транслируют информацию между форматами сообщений ESB и не-ESB и EPR. (EPR обозначает ссылку на конечную точку.) Шлюзы являются процессами прослушивателя в том смысле, что они «прослушивают» входящие сообщения. Они отличаются от слушателей, поддерживающих ESB, тем, что принимают данные в разных форматах, например, объекты в файлах или таблицы SQL. Слушатели, поддерживающие ESB, могут принимать сообщения только в формате org.jboss.soa.esb.message.
Платформа SOA поддерживает следующие шлюзы:
- файловые шлюзы: локальная файловая система, ftp, sftp и ftps
- JMS
- HTTP / HTTPS
- электронная почта (POP3)
- Таблица SQL
- Hibernate
Когда слушатель шлюза что-то слышит (входящие данные), он преобразует полученные сообщения, отличные от ESB, в формат org.jboss.soa.esb.message. Как это преобразование происходит, зависит от типа шлюза. Например, файловый шлюз берет содержимое файла и помещает его в папку с именем «BytesBody.BYTES_LOCATION» внутри тела сообщения.
Давайте посмотрим на пример.
Быстрый старт (с быстрым стартом)
Одной из полезных функций, включенных в платформу SOA, является набор примеров «быстрого старта» приложений. Быстрый старт демонстрирует функции и интеграцию платформы SOA. Цели быстрого старта — служить инструментами обучения и отправной точкой для написания собственных приложений. Мы рассмотрим один из этих быстрых стартов, чтобы увидеть работу шлюза.
Предположим, у вас есть устаревшее приложение, которое хранит данные в текстовых файлах. То, что вы хотите сделать, — это создать службу с поддержкой ESB, которая будет читать эти файлы и обрабатывать их по мере их создания. Вы можете написать инфраструктурный код, который периодически опрашивает целевой каталог, чтобы определить, когда новый файл помещается туда. Однако с платформой SOA вы можете просто использовать файловый шлюз.
Быстрые старты распространяются в каталоге samples / quickstarts. Давайте посмотрим на helloworld_file_action.
cd samples/quickstarts/helloworld_file_action
Разверните тест на сервере и запустите его с помощью следующих простых команд:
ant deploy
ant runtest
Журнал сервера должен выглядеть примерно так:
16:42:22,744 INFO [STDOUT] Message structure:
16:42:22,744 INFO [STDOUT] [Hello World In A File].
16:42:22,746 INFO [STDOUT]
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:42:22,746 INFO [STDOUT] Body: Hello World In A File
16:42:22,746 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:42:22,747 INFO [STDOUT] Message structure:
16:42:22,747 INFO [STDOUT] [ message: [ JBOSS_XML ]
Что только что произошло здесь? Давайте взглянем. «Муравьиная цель runtest» вызывает программу CreateTestFile.java. Как следует из названия, эта программа создает тестовый файл. Файл содержит этот текст: «Hello World In A File»
Что будет дальше, нам нужно посмотреть, как настроено тестовое приложение. Основной файл конфигурации приложения SOA Platform называется jboss-esb.xml. В случае этого быстрого запуска этот файл создается во время выполнения, чтобы можно было определить каталог установки платформы SOA. Итак, нам нужно посмотреть на источник сгенерированного файла, а именно этот файл: jboss-esb-unfiltered.xml
Первая часть интересующего нас файла выглядит следующим образом:
<fs-provider name="FSprovider1">
<fs-bus busid="helloFileChannel" >
<fs-message-filter
directory="@INPUTDIR@"
input-suffix=".dat"
work-suffix=".esbWorking"
post-delete="false"
post-directory="@OUTPUTDIR@"
post-suffix=".sentToEsb"
error-delete="false"
error-directory="@ERRORDIR@"
error-suffix=".IN_ERROR"
/>
</fs-bus>
</fs-provider>
Линии, которые нас больше всего интересуют:
- Строка 4,5: это определение каталога и расширения входного файла, которое слушатель «слушает».
- Строка 6: когда сообщение в файле обрабатывается, слушатель создает рабочий файл с этим расширением.
- Строки 7-9: И когда эта обработка завершена, сообщение записывается в файл в выходном каталоге. Файл сохраняется после завершения прослушивания.
- Строки 10-12: если что-то идет не так, сообщение записывается в файл ошибок.
Это определение файлового шлюза, которое мы будем использовать. Обратите внимание на имена каталогов. В этом примере они заполняются во время выполнения из значений, определенных каталогом, в который вы установили платформу SOA.
Теперь помните, как мы говорили, что все это либо сообщение, либо услуга? Прокрутите файл вниз, и мы увидим наш сервис.
<service
category="myCategory"
name="myFileListener"
description="Hello World File Action (esb listener)" >
<listeners>
<fs-listener name="FileGateway"
busidref="helloFileChannel"
maxThreads="1"
is-gateway="true"
poll-frequency-seconds="10"
/>
<jms-listener name="helloWorldFileAction"
busidref="quickstartEsbChannel"
maxThreads="1"
/>
</listeners>
<actions mep="OneWay">
<action name="testAction" class="org.jboss.soa.esb.actions.SystemPrintln" />
<action name="action1"
class="org.jboss.soa.esb.samples.quickstart.helloworldfileaction.MyAction"
process="displayMessage,playWithMessage"
/>
<action name="dump" class="org.jboss.soa.esb.actions.SystemPrintln">
<property name="printfull" value="true"/>
</actions>
</service>
Давайте посмотрим на это описание сервиса.
- Строки 7-12: во-первых, слушатели. Обратите внимание на определение слушателя файловой системы (fs). Это наши ворота. Поле «busidref» ссылается на «fs-provider», который мы обсуждали минуту назад. Вы заметили второго слушателя? Это ESB-слушатель JMS. Это происходит потому, что для платформы SOA требуется, чтобы для каждого шлюза был определен соответствующий прослушиватель ESB.
- Строки 19: давайте посмотрим на действия. Определение «mep» «OneWay» относится к конвейеру действий (последовательности действий), явно не отправляющему ответ. (Вы можете найти более подробную информацию об этих определениях в Руководстве программиста платформы SOA [2].)
- Строки 20, 25-26: действия с именами «testAction» и «dump» записывают сообщение в журнал сервера.
- Строки 21-23: действие, которое нас больше всего интересует, это «действие1». Методы (displayMessage, playWithMessage) в классе, на который ссылается это действие (org.jboss.soa.esb.samples.quickstart.helloworldfileaction.MyAction), получают данные во входном файле в виде сообщения ESB-Aware, извлекают эту информацию, и обработать это. В случае вашего приложения вы должны заменить «MyAction» своим собственным кодом бизнес-логики.
Итак, в итоге, что происходит при запуске этого быстрого запуска?
- Шлюз файловой системы инициализирован.
- Файл создается во входном каталоге, определенном в его определении fs-провайдера.
- Шлюз считывает файл, преобразует его в сообщение с поддержкой ESB и передает сообщение методам в классе действия, определенном в определении действия.
- Эти методы обрабатывают сообщение (в случае быстрого старта они записывают содержимое сообщения в журнал сервера) .5. Шлюз перемещает файл в выходной каталог, определенный в его определении fs-провайдера.
Важно отметить, что единственным новым кодом, который нужно было написать, является класс действия. Код инфраструктуры для прослушивания и преобразования файла в сообщение в формате, который может обрабатывать платформа SOA, является частью шлюза.
С точки зрения разработчика приложения, это плюс, так как вы можете сосредоточиться на написании кода для удовлетворения требований бизнес-процессов вашего приложения.
С точки зрения инженера QE, это реальный плюс, так как это означает, что нужно писать меньше кода. И чем меньше кода, тем меньше возможностей для ошибок!
Данные находятся на платформе SOA, что теперь?
Слушатели шлюза позволяют вашим прежним приложениям получать данные в ESB платформы SOA и преобразовывать эти данные в сообщения с поддержкой ESB, чтобы ESB мог направить данные в нужную службу назначения. Однако, это будет иметь место только в том случае, если служба назначения — это другое устаревшее приложение, которое также не поддерживает ESB. Как вы можете легко преобразовать сообщения в форму, которую может обрабатывать старое приложение?
Ответ заключается в использовании одного из уведомителей платформы SOA. Подобно тому, как прослушиватель шлюза позволяет перемещать сообщения, не относящиеся к ESB, на ESB платформы SOA, уведомители позволяют перемещать сообщения, поддерживающие ESB, из ESB в службы, не поддерживающие ESB. Уведомители преобразуют сообщения с поддержкой ESB в данные в различных формах, понятных вашим службам. Платформа SOA поддерживает следующие уведомители:
- NotifyConsole
- NotifyFiles
- NotifySQLTable
- NotifyFTP
- NotifyQueues
- NotifyTopics
- NotifyEmail
Давайте добавим некоторые из этих уведомителей в быстрый запуск helloworld_file_action. Обратите внимание, что, хотя существуют другие краткие руководства, посвященные иллюстрированию уведомителей, наше расширение быстрого запуска helloworld_file_action соответствует одной из целей быстрых запусков; чтобы дать вам отправную точку для разработки собственных пользовательских приложений.
Следует иметь в виду, что конвейер действий состоит из двух этапов: сначала обычная обработка, а затем обработка результатов. Уведомители не выполняют никакой обработки сообщений на этом первом этапе. Они отправляют уведомления на втором этапе. Уведомление происходит после обработки конвейера действий. Это означает, что вы не можете использовать уведомители для изменения результатов какой-либо обработки действий. Данные, отправляемые уведомителем, являются сообщением ESB, которое обрабатывается конвейером действий. [3]
Давайте вставим следующие операторы (без номеров строк) в сервис, определенный в файле быстрого запуска jboss-esb-unfiltered.xml:
<action name="notificationAction" class="org.jboss.soa.esb.actions.Notifier">
<property name="okMethod" value="notifyOK" />
<property name="notification-details">
<NotificationList type="ok">
<target class="NotifyConsole"/>
<target class="NotifyFiles">
<file append="false" URI="@OUTPUTDIR@/notify.txt"/>
<file append="true" URI="@OUTPUTDIR@/results.log"/>
</target>
<target class="NotifyEmail"
from="[email protected]"
sendTo="[email protected]"
ccTo="[email protected]"
subject="Test was successful"
message="See attached file">
<attachment>@OUTPUTDIR@/notify.txt</attachment>
</target>
</NotificationList>
<NotificationList type="err">
<target class="NotifyConsole"/>
<target class="NotifyFiles">
<file append="true" URI="@ERRORDIR@/error.log"/>
</target>
</NotificationList>
</property>
</action>
Прежде чем мы повторно развернем и повторно запустим быстрый запуск, мы пройдемся по этим новым утверждениям:
- Строка 1: обратите внимание на ссылку на класс Notifier
- Строка 2: okMethod позволяет серверу уведомлять об успехе или неудаче при каждом действии в конвейере действий.
- Строка 4: эти уведомления будут появляться, если обработка конвейера действий будет успешной
- Строка 5: самый простой уведомитель — сообщение ESB отправляется в журнал консоли сервера.
- Строка 6: так как мы начали быстрый запуск с создания файла, мы создадим другой файл с уведомителем NotifyFiles.
- Строка 7: сообщение ESB записывается в файл с именем «notify.txt» в выходном каталоге. Обратите внимание, что если файл с таким именем уже существует, он перезаписывается.
- Строка 8: мы также добавим сообщение ESB в файл журнала.
- Строка 10: И мы отправим то же самое сообщение ESB в электронном письме — сообщение ESB будет в электронном письме
- Строка 11: Но, чтобы быть уверенным, мы также отправим файл notify.txt в качестве вложения в электронное письмо
- Строка 19. Наконец, если при обработке конвейера действий возникнет ошибка, эти уведомители будут выполнены
На этом этапе заново разверните быстрый запуск и снова выполните «ant runtest».
Журнал сервера должен выглядеть примерно так:
2009-07-18 22:45:33,291 INFO [STDOUT] ConsoleNotifier 2009/07/18 10:45:33.291<
BEFORE
Hello World In A File
AFTER
>
2009-07-18 22:45:33,292 INFO [org.jboss.soa.esb.helpers.Email] Initialising mail server session. Properties: {mail.smtp.port=25, mail.smtp.auth=true, mail.smtp.host=localhost}
Для консоли и почтового уведомителя. Электронное письмо будет отправлено на указанные вами адреса, и вы также должны увидеть файл с именем notify.txt и results.log в выходном каталоге. Если вы запустите тест еще раз, вы увидите, что файл results.log дважды содержит сообщение ESB.
Заключительные мысли
С помощью шлюзов и уведомлений платформы SOA можно повторно использовать существующие приложения в качестве служб, не поддерживающих ESB, без необходимости переписывать код приложений. Приложения могут продолжать общаться через файлы или FTP или записи базы данных или другие форматы данных. Шлюзы и уведомители заботятся о получении данных на платформе SOA (где вы можете направить их к намеченному сервису — см. Предыдущий пост о маршрутизации на основе контента), а затем вернуться обратно. И это намного проще, чем переписывать устаревшие приложения. Кобол кто-нибудь? ?
Ресурсы
[1] Посмотрите этот файл в javadocs, установленном на вашем сервере SOA Platform: jboss / soa / esb / message / Message.html
[2] http://www.redhat.com/docs/en-US /JBoss_SOA_Platform/4.3.GA/html/Programmers_Guide
[3]http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html/Programmers_Guide/ch11s06.html
Благодарности
Как всегда, я хотел бы поблагодарить участников проекта платформы SOA за их помощь и своевременный обзор комментариев! Кроме того, этот пост в значительной степени опирается на обширные документы по платформе SOA и краткие обзоры. Информация о слушателях в этом посте была первоначально опубликована в журнале Red Hat ( http://magazine.redhat.com/2008/05/22/adapters-for-an-esb ). Я хотел бы поблагодарить всех в журнале за их помощь в течение последних нескольких лет, особенно редактора журнала Баша Харрис.