IBM WebSphere Developer Technical Journal: Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 4

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

Уровень сложности: простой

Рэйчел Рейниц, старший специалист-консультант по информационным технологиям, IBM
Андре Тост, старший сотрудник технической службы, IBM

11.05.2005

Разработайте и установите простой объект-посредник, обращающийся к сообщениям по мере их прохождения по шине, с использованием нового механизма обмена сообщениями в IBM® WebSphere® Application Server V6 для построения Enterprise Service Bus.

Введение

Теперь, когда мы выяснили как установить шину и как использовать JMS в качестве протокола проходящих по шине сообщений, мы, наконец, готовы ввести другой ключевой компонент в наше решение: Объекты-посредники!

В четвертой статье серии по использованию нового механизма обмена сообщениями IBM WebSphere Application Server для построения Enterprise Service Bus (ESB) мы рассмотрим, как добавить в наше решение простой объект-посредник, обращающийся к сообщениям по мере их прохождения по шине.

Наше решение развилось из следующих статей:

• Часть 1: Введение в WebSphere V6 Messaging Resources
• Часть 2: Постановка задачи и шина
• Часть 3: Простой пример обмена JMS-сообщениями

В начало

Пересмотр объектов-посредников

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

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

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

Хороший пример объекта-посредника можно найти в статье Практическое введение в объекты-посредники для сообщений.

В начало

Программная модель объекта-посредника

Объекты-посредники могут быть написаны таким образом, чтобы не зависеть от протокола; хорошей практикой является разделение обработки любого протокола (то есть, SOAP, JMS или MQ) в разных посредниках-обработчиках. Другими словами, объект-посредник может быть независим от протокола, который используется для передачи сообщения связанному с ним адресату. Это требует нейтрального способа доступа к данным сообщения. Вот где нужен Service Data Object (SDO). Мы не будем детально рассматривать SDO (см. раздел Ресурсы для получения дополнительных материалов), но отметим, что когда бы вы ни разрабатывали объекты-посредники в целях расширения возможностей, делайте это с использованием SDO API.

В основе программирования объектов-посредников лежит реализация в них общего интерфейса с названием MediationHandler, дающего возможность их активизации при поступлении сообщения адресату. Единственный метод этого интерфейса называется handle(). Он принимает аргумент типа MessageContext. Этот контекст, кроме других вещей, содержит ссылку на реальное сообщение. Метод handle() вызывается при приходе сообщения, и это сообщение передается в объект-посредник в параметре MessageContext.

Кстати, если вы знакомы с концепцией обработчиков JAX-RPC, объекты-посредники имеют похожую (но не такую же!) программную модель. Фактически, используемый ими класс MessageContext взят из спецификации JAX-RPC.

Так как же разработать и установить объект-посредник? Не беспокойтесь, мы в пошаговом режиме рассмотрим простой пример прямо сейчас.

В начало

Разработка простого объекта-посредника для ведения журнала

Для нашего примера мы разработаем объект-посредник, который регистрирует каждое сообщение, передаваемое адресату. Сообщение просто будет выводиться в System.out. В реальной ситуации вероятнее всего мы бы воспользовались преимуществом стандартного механизма java.util.logging. Здесь мы не будем менять содержимое сообщения; оставим это для следующей статьи.

Для разработки кода и создания установочного пакета, содержащего объекты-посредники для сервера приложений WebSphere, можно использовать программы WebSphere Application Server Toolkit (AST) или IBM Rational® Application Developer for WebSphere Software V6 (далее называемой Application Developer). Единственная важная деталь – объекты-посредники, даже если они разрабатывались как простые Java-классы, развертываются в форме не сохраняющих состояния сессионных EJB-компонентов. AST или Application Developer будут генерировать эти EJB во время развертывания объектов-посредников. Подробнее об этом будет сказано ниже.

Для разработки нашего объекта-посредника:

1. Создайте новый EJB-проект в выбранном вами средстве разработки и назовите его LoggingMediation;
2. По умолчанию программа предложит также создать новый EAR-проект. Воспользуйтесь этим предложением;
3. Создайте пакет, называемый logging в папке ejbModule EJB-проекта (предполагается, что вы работаете в "J2EE perspective" программы);
4. Наконец, создайте новый Java-класс в этом пакете под названием LoggingMediation, реализующий интерфейс com.ibm.websphere.sib.mediation.handler.MediationHandler. На рисунке 1 показан вид этой структуры.
   Рисунок 1. Структура EJB Project
   
   Программа также создаст пустой класс реализации, содержащий следующий код в пустом методе с сигнатурой:
   
   

   public boolean handle(MessageContext arg0) throws MessageContextException {

   
   
   
5. Добавьте следующий код в метод handle(), который будет регистрировать прием сообщения
   
   

   public boolean handle(MessageContext arg0) throws MessageContextException { // Преобразование MessageContext в SIMessageContext SIMessageContext sim = (SIMessageContext)arg0; // Прием сообщения из контекста SIMessage message = sim.getSIMessage(); try { if (message.getFormat().equals("JMS:text")) { // получение SDO DataGraph из сообщения DataGraph dataGraph = message.getDataGraph(); //SIBus SDO-представление JMS-сообщения, имеет свойство с именем 'data' DataObject jmsMessage = root.getDataObject("data"); //DataObject для JMS-сообщения имеет свойство, содержащее //значение сообщения. Мы обращаемся к этому значению как к строке. SDO //преобразует сообщение в требуемый формат наилучшим способом. String payLoad = jmsMessage.getString("value"); System.out.println("Message logged. The payload of the message is "+payLoad); } else { System.out.println("The received message is not a JMS text message!"); } } catch (SIException ex) { System.out.println(ex.getLocalizedMessage()); } return true; }

   
   
   
6. Добавьте в класс следующие операторы import:
   
   

   import com.ibm.websphere.sib.mediation.handler.MediationHandler; import com.ibm.websphere.sib.mediation.handler.MessageContextException; import com.ibm.websphere.sib.mediation.messagecontext.SIMessageContext; import commonj.sdo.DataGraph;

   
   
   

Обратите внимание, как извлекается из сообщения полезная информация. Системная интегрированная шина (SIBus) использует динамический интерфейс для Service Data Objects (SDO). Сообщение представляется как SDO DataGraph, поэтому мы вызываем метод getDataGraph(). DataGraph всегда содержит по крайней мере один экземпляр DataObject – это реальные данные. После получения корневого DataObject мы можем получить его свойства при помощи метода getRootObject().

SIBus-представление JMS-сообщения определяет свойство корневого DataObject с названием data, которое возвращает другой DataObject. Свойство data DataObject имеет свойство с названием value, которое является реальным содержимым сообщения.

Метод getString("value") является частью динамического интерфейса SDO и требует небольших пояснений. Мы можем извлечь свойство в любом подходящем для нас типе; SDO-вызов DataObject выполнит преобразование типа свойства наилучшим способом, если оно не хранится в DataObject в таком же типе. В нашем примере мы используем метод getString(), который указывает, что мы хотим извлечь содержимое свойства в виде String. Существую также и другие методы DataObject (...), которые пытаются возвратить содержимое свойства с соответствующим типом.

Навигация по SDO DataObject Свойства в DataObject имеют названия. Кроме того, DataObject могут содержать другие DataObject. SDO API предоставляет сокращения, которые можно применять для навигации по иерархии DataObject, используя запрос в стиле XPath. В нашем примере вместо кода: DataObject jmsMessage = root.getDataObject("data"); String payLoad = jmsMessage.getString("value"); мы могли бы использовать: String payLoad = root.getString("data/value"); где строка "data/value" является запросом типа XPath, означающим, что мы извлекаем свойство "value", содержащееся в свойстве корневого объекта "data".

Предложенного нами объяснения работы SDO явно не достаточно для серьезного программирования объектов-посредников. Более детальное рассмотрение SDO и его применение в WebSphere Messaging Resources вы можете найти по представленным в разделе Ресурсы ссылкам.

Откуда мы узнали, что существуют такие свойства, как data и value, и что они на самом деле находились там, где мы искали? Это описано в WebSphere Application Server V6 Information Center; найдите раздел SDO Datagraph information => JMS Formats и взгляните на любой из форматов.

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

В начало

Развертывание нового объекта-посредника

Теперь мы готовы приступить к развертыванию нашего объекта-посредника. Это означает, что нужно добавить запись в EJB-дескриптор развертывания EJB-проекта с названием LoggingMediation. Программа автоматически сгенерирует не сохраняющий состояния сессионный компонент, который заключит в себя созданный нами объект-посредник. Эта новая запись в дескрипторе развертывания не является частью стандартного дескриптора развертывания EJB 2.1, поэтому она хранится в файле расширения - ws-handler.xmi. Однако программа дает возможность редактировать стандартные поля и все расширения в одном окне редактора.

Для развертывания нового объекта-посредника:

1. Выполните двойной щелчок на записи Deployment Descriptor: LoggingMediation в виде Project Explorer. При этом откроется (пока пустой) дескриптор развертывания в окне редактора.
2. Перейдите на закладку Mediation Handlers внизу для определения объекта-посредника (рисунок 2).
   Рисунок 2. Параметры обработчика объекта-посредника
   
   
3. Для добавления нового объекта-посредника нажмите кнопку Add...
4. В окне "Define Mediation Handler" нажмите кнопку Browse для выбора нашего класса объекта-посредника (рисунок 3).
   Рисунок 3. Определение нового объекта-посредника
   
   
5. Нажмите OK.
6. Введите LoggingMediation в поле Name и нажмите Finish.
7. После этого вы должны увидеть, что в модуле существует новый сессионный EJB-компонент, который представляет объект-посредник (рисунок 4).
   Рисунок 4. Объект-посредник, определенный в проекте
   
   

Теперь мы можем установить EAR-проект, содержащий объект-посредник, на сервере приложений.

В начало

Установка объекта-посредника

Для установки нового объекта-посредника:

1. Экспортируйте проект LoggingMediationEAR в EAR-файл, используя пункт меню Export инструментальной программы (ссылка на полный файл loggingmediation.ear находится в разделе Загрузка).
2. Запустите ваш сервер приложений и откройте консоль администратора в вашем браузере.
3. Установите новое корпоративное приложение из файла loggingmediation.ear. Не забудьте отметить параметры Generate default bindings и Deploy enterprise beans, если они еще не отмечены. Для всех остальных полей оставьте значения по умолчанию.
4. Для завершения установки перейдите на закладку "Enterprise Applications" консоли администратора и запустите новое приложение LoggingMediationEAR.

В начало

Настройка шины для объекта-посредника

Далее, мы определим объект-посредник в шине:

1. Откройте в консоли администратора окно для шины TheBus и выберите Mediations (рисунок 5).
   Рисунок 5. Свойства конфигурации шины
   
   
2. Нажмите New.
3. В полях "Mediation name" и "Handler list" name введите значение LoggingMediation, как показано на рисунке 6.
   Рисунок 6. Настройка объекта-посредника шины
   
   
4. Нажмите OK и сохраните ваши изменения. Теперь стал доступен объект-посредник, который может быть связан с любым адресатом.

Теперь, поскольку мы можем протестировать наш новый объект-посредник, свяжем его с адресатом PackageReceivedDestination, который мы использовали ранее в нашем JMS-примере:

1. Откройте список адресатов в консоли администратора и выберите PackageReceivedDestination.
2. Нажмите кнопку Mediate, как показано на рисунке 7.
   Рисунок 7. Связывание адресата с объектом-посредником
   
   
3. В диалоговом окне, показанном на рисунке 8, проверьте, что выбран объект-посредник LoggingMediation (он должен быть единственным определенным объектом-посредником), нажмите Next.
4. Повторно нажмите Next, затем Finish.
5. Сохраните ваши изменения. В списке адресатов теперь показано, что LoggingMediation связан с PackageReceivedDestination (рисунок 8).
   Рисунок 8. Связывание адресата с объектом-посредником
   
   

В начало

Тестирование объекта-посредника

Вы можете просто запустить клиентское JMS-приложение для тестирования объекта-посредника, как было рассмотрено в третьей части этой серии статей. Предполагается, что вы установили и запустили корпоративное приложение PackageReceived (см. в разделе Ресурсы ссылку на статью, содержащую этот EAR-файл). Запустите клиентское приложение при помощи программы launchclient. Файл System.out в каталоге logs\server1 теперь содержит дополнительную информацию, полученную из объекта-посредника (рисунок 9).

На рисунке 9 видно, что информация дублируется. Причина этого в том, что содержимое сообщения сначала записывается объектом-посредником, а затем принимающим MDB.

В начало

Заключение

В четвертой части серии статей по построению Enterprise Service Bus с WebSphere Application Server V6 мы узнали, как разработать, развернуть и установить объект-посредник, а также как настроить ESB на использование объектов-посредников – ключевой концепции WebSphere Messaging Resources. Разработанный в виде простого компонента JavaBeans объект-посредник заключается в не сохраняющий состояния сессионный EJB-компонент, установленный на сервере приложений как корпоративное приложение и, после связывания его с адресатом, активизируется при каждом приходе сообщения адресату. Гибкие по природе, объекты-посредники могут трансформировать и перенаправлять сообщения, или просто использоваться в целях ведения журналов регистрации, как показано в данной статье.

В начало

Загрузка

Имя	Размер	Метод загрузки
LoggingMediationEAR.ZIP	5 KB	FTP|HTTP

	Информация о методах загрузки

Ресурсы

• Оригинал статьи Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 4.
  
  
• Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 1. Введение в WebSphere V6 Messaging Resources.
  
  
• Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 2. Постановка задачи и шина.
  
  
• Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 3. Простой пример обмена JMS-сообщениями.
  
  
• Практическое введение в объекты-посредники для сообщений.
  
  
• Шаблоны: Сервис-ориентированная архитектура и Web-службы.
  
  
• Шаблоны: Реализация SOA с использованием Enterprise Service Bus.
  
  
• Знакомство с Service Data Objects.
  
  
• Записанное представление по объектам-посредникам.
  
  
• Подключайтесь к сообществу developerWorks, участвуя в форумах developerWorks.

Об авторах

		Рэйчел Рейниц (Rachel Reinitz) является старшим специалистом-консультантом по информационным технологиям и программным службам IBM для WebSphere, специализируюясь на Web-службах. Рэйчел консультирует пользователей и ISV по вопросам использования сервис-ориентированной архитектуры и Web-служб для решения их технических и бизнес-задач. Она разработала курс обучения расширенным Web-службам IBM и часто выступает на конференциях. Рэйчел также опытный инструктор по экстремальному программированию (eXtreme Programming – XP) и использует принципы XP четыре года. Она живет в Bay Area, Калифорния, любит туризм, общение и международные путешествия.

		Андре Тост (Andre Tost) работает старшим сотрудником технической службы в подразделении WebSphere Business Development, где помогает стратегическим партнерам IBM интегрировать их приложения с WebSphere. Уделяет особое внимание технологии Web-служб семейства продуктов WebSphere. До этого он десять лет занимался различными вопросами разработки и архитектуры программного обеспечения IBM, в частности программой WebSphere Business Components. Приехав из Германии, он поселился в в Рочестере, Миннесота. В свободное время любит заниматься своей семьей и, когда есть возможность, играет и смотрит футбол.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало