Как работают EJB-запросы в WebSphere Application Server V6.1

Во многих приложениях применяются компоненты Enterprise JavaBeans™ (EJB), развернутые в EJB-контейнере IBM® WebSphere ® Application Server. Для связи с этими EJB-компонентами применяются такие средства, как протокол взаимодействия ORB в сетях TCP/IP (IIOP), JNDI-поиск и управление рабочей нагрузкой. Это взаимодействие устроено достаточно сложно и для большинства пользователей WebSphere является просто черным ящиком. В статье дается общее представление о принципах обмена информацией с EJB применительно к WebSphere Application Server. Рассмотрены передача информации к ORB и от него, а также основные схемы вызовов и компонентов, используемых в обращениях к EJB-компонентам, развернутых в EJB-контейнере. Предполагается, что читатель в целом понимает принципы J2EE™ и имеет общее представление об администрировании WebSphere Application Server. Из журнала IBM WebSphere Developer Technical Journal.

Джон Пейп, группа оперативной поддержки WebSphere Application Server, IBM

Джон Пейп (John Pape) в настоящее время работает в группе оперативной поддержки WebSphere и занимается поддержкой пользователей, работающих с WebSphere Application Server, WebSphere Portal Server и WebSphere Extended Deployment. Чтобы предоставлять пользователям IBM качественную поддержку, человеку на этой должности необходимо обладать нестандартным и новаторским мышлением, а также быть внимательным к деталям.



Доктор Махеш Ратхи, группа оперативной поддержки WebSphere Application Server, IBM

Д-р Махеш Ратхи (Mahesh Rathi) занимается ПО WebSphere Application Server с самого начала его разработки. Он возглавлял группу разработки средств безопасности, затем перешел в группу поддержки 2-го уровня, а с 2005 года поступил в группу оперативной поддержки. Ему нравится работать с требовательными клиентами, решать неотложные проблемы и работать в условиях жестких сроков. Махеш Ратхи имеет степень PhD по компьютерным наукам университета Пардью; до поступления на работу в IBM он преподавал разработку программного обеспечения в университете Уичита (штат Канзас).



28.08.2009

Вступление

Для большинства пользователей WebSphere взаимодействие с EJB представляет собой черный ящик. А именно, мы понимаем, что при вызове метода 'X' бизнес-логика EJB возвратит необходимый результат. При нормальной работе такой информации может быть вполне достаточно, и разбираться во внутреннем устройстве ORB обычно нет необходимости. Однако при возникновении проблем с производительностью или распределением нагрузки более глубокое понимание ORB может существенно облегчить поиск проблемы и ускорить ее решение. Как и для любых других составляющих WebSphere, понимание механизма работы ORB и относящихся к нему протоколов передачи данных может оказаться очень полезным при поиске и устранении проблем.


ORB

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

CORBA – открытая, независимая от поставщиков платформ архитектура для распределенных вычислений, созданная рабочей группой OMG (консорциум из более 600 поставщиков программного обеспечения и других компаний, занимающихся продвижением открытых стандартизованных интерфейсов). CORBA и ее язык описания интерфейсов (IDL) предоставляют общий формат для представления объектов для приложений, написанных на Java™, C, C++ или других языках и работающих на различных операционных системах и компьютерах.

ORB (брокер объектных запросов) является неотъемлемой частью рабочей среды сервера приложений. ORB реализован как часть виртуальной машины Java (JVM). IBM WebSphere Application Server содержит дополнительный программный код (т.н. расширение ORB), который не только управляет представителем класса ORB, но и предоставляет среду для подключения модульных сервисов объектов (например, служб безопасности). Эта реализация ORB, представленная IBM, отличается от ORB-решения Sun™ и написана на базе другого кода. Она фактически является средством, которое использует EJB-контейнер для организации обмена данными с брокером при RMI-взаимодействиях. RMI – это традиционный для Java метод организации удаленного обмена информацией между Java-объектами, использующий нестандартизованный протокол Java Remote Method Protocol (JRMP). На базовом уровне RMI является всего лишь объектно-ориентированной Java-версией Remote Procedure Calls (RPC). WebSphere Application Server использует ORB для обеспечения взаимодействия между клиентом и сервером RMI и для обеспечения передачи данных между компонентами.

ORB управляет входящими и исходящими запросами удаленных Java-объектов, например, EJB-компонентов. Клиентам ORB он предоставляет среду для нахождения компонентов EJB на сервере и выполнения операций над ними таким же образом, как если бы они были локальными. (Этот принцип называют локально-удаленной прозрачностью.) Взаимодействие между ORB и EJB-контейнером показано на рисунке 1.

Рисунок 1. ORB и EJB-контейнер
Рисунок 1. ORB и EJB-контейнер

Коммуникация между ORB

Коммуникация между брокерами объектных запросов (ORB) реализована с помощью протокола взаимодействия ORB в сетях TCP/IP (IIOP), который представляет собой частную реализацию абстрактной эталонной спецификации протокола General Inter-Orb Protocol (GIOP). Интероперабельная ссылка на объект (IOR) – это просто строковое представление ссылки на объект CORBA или RMI-IIOP в формате, понятном брокерам объектных запросов. С ней можно обращаться как с простой Java-ссылкой на объект в обычном программировании. IIOP отображает GIOP в стек TCP/IP.

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

  • Запрос на поиск используется для того, чтобы удостовериться в том, что ORB понимает и определяет местонахождение запрошенного отдаленного объекта. Если объект, указанный в запросе на поиск, не известен ORB, то будет сделана попытка получить дополнительную информацию (например, OBJECT_FORWARD с указанием на сервер, где находится запрашиваемый объект).
  • Фрагментированное сообщение представляет собой продолжение предыдущего сообщения, которое уже было доставлено ORB.

Обработка больших GIOP-сообщений может вызывать проблемы в ORB. Чтобы сократить время и упростить процесс обработки, GIOP-сообщения можно разбить на удобные для обработки фрагменты. Пользовательские настройки, определяющие точный размер фрагментов, на которые следует разбивать сообщение (и нужно ли вообще разбивать сообщение) можно задать в WebSphere Application Server. По умолчанию WebSphere Application Server разбивает GIOP-сообщения на куски по 1024 байта.

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

В любом сервере приложений есть брокер ORB, который отслеживает входящие запросы. C ORB связано не менее трех портов: прослушивающий порт ORB, порт для загрузки и защищенные порты. Прослушивающий порт ORB - это реальный порт, который ORB прослушивает на предмет входящих IIOP-запросов, если не включена защита ORB. Порт для загрузки - это широко известный и постоянно активный порт, который всегда возвращает непрямой IOR, содержащий защищенные и незащищенные прослушивающие порты. Правильно построенный клиент всегда должен привязываться к тому серверу, на котором хранится удаленный ресурс (или к URL-адресу провайдера нескольких хостов (multiple host provider), который указывает на кластер, если в нем хранится нужный ресурс). Еще три порта связаны с ORB и с защитой: CSIv2 Client Authentication (проверка прав доступа клиента) SSL-порт, CSIv2 SSL-порт и SAS SSL-порт. Подробное описание этих портов находится за рамками данной статьи. По умолчанию прослушивающие порты ORB во время работы выбираются динамически из диапазона портов среды операционной системы. Однако по разным причинам эти порты можно привязывать к конкретным статическим портам, например, в связи с правилами межсетевого экрана, сложившейся бизнес-практикой и т.п.

Когда ORB-клиент запрашивает ссылку на удаленный объект, удаленный ORB отвечает интероперабельной ссылкой на объект (IOR), которая представляет собой строковое представление ссылки на объект RMI-IIOP в формате, понятном ORB. Как минимум она содержит информацию о хосте и порте сервера, на котором хранится этот объект. IOR можно сравнить с обычной ссылкой на объект Java, которая используется в традиционном программировании.


Какова роль NodeAgent?

Прежде всего скажем, что процесс NodeAgent участвует в ORB-транзакции только в ПО WebSphere Application Server Network Deployment. Его нет в базовом предложении сервера приложений. В процессе NodeAgent есть сервис - демон службы адресации, - который позволяет серверам приложений регистрировать свои службы и удаленные объекты и предоставляет демону прямые интероперабельные ссылки на объекты, указывающие на указанный сервер приложений. Затем, когда к демону службы адресации поступает запрос на поиск, он на основе регистрационной информации предоставляет клиенту прямую IOR, которая указывает на зарегистрированные прослушивающие порты сервера приложений ORB. Эту информацию о регистрации/IOR можно рассматривать как таблицу маршрутизации, которую демон использует для определения местонахождения объектов EJB и других ресурсов, размещенных на различных серверах приложений, которыми управляет конкретный NodeAgent.

Чтобы управляемый сервер приложений мог начать работать, на этом же узле сети должен работать NodeAgent. Можно сконфигурировать серверы приложений таким образом, чтобы устранить зависимость от процесса NodeAgent (фактически от расположения демона службы адресации). Однако такая настройка требует выполнения статической маршрутизации IIOP-запросов и, таким образом, сводит на нет службы управления рабочей нагрузкой WebSphere Application Server. Такой настройки статической маршрутизации необходимо избегать, если без нее можно обойтись. (Прежде чем принимать решение, проконсультируйтесь в службе поддержки IBM.)

Если процесс NodeAgent дает сбой или если требуется его остановка или перезапуск, когда на том же узле работает сервер приложений с развернутыми на нем объектами EJB, в файле журнала сервера при недоступности NodeAgent могут быть зарегистрированы исключения. Эти сообщения появляются вследствие того, что как только NodeAgent перестает принимать участие в процессе, процесс передачи данных IIOP изменяется таким образом, что брокеры объектных запросов (клиенту и сервер) не могут корректно обмениваться информацией. Но если у клиентов уже есть прямые IOR на необходимые им серверы и они уже создали свои EJBHome-объекты и передают запросы к этим EJB, маловероятно, что после этого NodeAgent будет вовлечен в обмен данными IIOP.

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


Схема работы ORB-вызова

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

  • Отдельный сервер приложений (WebSphere Application Server, без сетевого развертывания (Network Deployment)
  • Кластеризованный сервер приложений в среде WebSphere Application Server Network Deployment.

Эти сценарии описаны в последующих разделах.

Простой экземпляр WebSphere Application Server

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

Листинг 1
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming
.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL,"corbaloc::isador:2810");
Context ctx = new InitialContext(env);
TestEJBHome home = (TestEJBHome)
PortableRemoteObject.narrow(ctx.lookup("ejb/ejbs/TestEJBHome"),
	TestEJBHome.class);
TestEJB bean = home.create();

Жирным шрифтом выделены строчки кода, результатом работы которых являются запросы к удаленному ORB. Ход событий можно проследить на рисунке 2 – последовательность событий показана сверху вниз.

Рисунок 2. ORB-событие запрашивает доступ к простому экземпляру
Рисунок 2. ORB-событие запрашивает доступ к простому представителю класса объектов

На рисунке 2 выделено три блока, каждый из которых соответствует определенной части кода, приведенного в листинге 1:

  • В верхнем блоке содержатся события, которые являются результатом создания InitialContext у клиента.
  • В среднем блоке показаны события, которые являются результатом работы метода InitialContext.lookup().
  • В нижнем блоке отражены события, которые являются результатом создания экземпляра EJB.

Из данной схемы видно, что процесс получения первоначального контекста от сервера включает в себя отправку ORB-запроса на поиск (в данном случае у клиента и сервера - один и тот же ORB) на ORB-порт для загрузки. В ответном сообщении содержится прямая интероперабельная ссылка на объект (содержащая информацию о портах SSL, TCP/IP и хоста), которая указывает на тот сервер, на котором хранится запрашиваемый объект. Затем клиент отправляет еще один запрос на поиск, но теперь уже на прослушивающий порт ORB. После этого для установления первоначального контекста клиент запрашивает у ORB дополнительную информацию.

Получив значение InitialContext, программа клиента просматривает область имен JNDI, чтобы определить, каким образом можно получить ссылку на нужный удаленный объект (WLMTestEJB). Для этого клиент отправляет на прослушивающий порт ORB еще один запрос на поиск. ORB отвечает клиенту сообщением о результате поиска, констатирующим, что объект действительно хранится локально. В ответ на это сообщение клиент указывает ORB, что необходимо разрешить объект и сообщить клиенту ссылку. Такая последовательность неявно заставляет ORB использовать специальный класс для установления связи между реальным Java-объектом и запросом, поступившим к ORB. Получив ссылку, клиент приводит полученный от ORB исходный объект к необходимому объектному типу, используя вызов «narrow».

Затем наш код создает экземпляр удаленного EJB. Для завершения процесса клиент отправляет удаленному ORB запрос на поиск, на который ORB отвечает сообщением о результате поиска, подтверждающим, что объект есть в наличии. В заключение клиент вызывает метод create() для удаленного объекта. По завершении процесса в ORB брокер объектных запросов отправляет клиенту ответ. Все данные, поступающие на ORB и возвращаемые от него (например, параметры метода и возвращаемые методом значения) сериализуются и десериализуются с использованием формата, который называется «стандартное представление данных» (CDR). В связи с этим все значения, передаваемые ORB, должны реализовать интерфейс serializable.

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

Кластеризованный экземпляр WebSphere Application Server Network Deployment

В этом сценарии основное отличие состоит в том, что ORB-клиент и ORB-сервер практически всегда являются двумя разными экземплярами JVM, зачастую расположенными на разных хостах. Сам процесс может показаться очень похожим, но обратите внимание на участие сервера демона службы адресации, входящего в NodeAgent. В листинге 2 показан код для реализации вызова.

Листинг 2
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming
.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL,"corbaloc::boris:9811,:natasha
:9812");
Context ctx = new InitialContext(env);
TestEJBHome home = (TestEJBHome)
PortableRemoteObject.narrow(ctx.lookup("ejb/ejbs/TestEJBHome"),
	TestEJBHome.class);
TestEJB bean = home.create();

По сравнению с предыдущим примером код изменен только в одном месте: в значениях ключа PROVIDER_URL объекта среды Hashtable. В данном случае разработчик добавил несколько URL corbaloc, каждый из которых указывает на отдельный порт для загрузки на сервере. Такое изменение делает процесс более устойчивым к ошибкам и улучшает аварийное переключение, так как теперь в коде предусмотрено два пути получения объекта InitialContext. Как и в предыдущем сценарии, выделенный жирным шрифтом код отвечает за генерирование запросов к удаленному ORB. На рисунке 3 показана последовательность событий для данного сценария, оформленная аналогично предыдущему примеру.

Рисунок 3. ORB-событие запрашивает доступ к кластеризованному экземпляру
Рисунок 3. ORB-событие запрашивает доступ к кластеризованному экземпляру

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

Во-первых, при создании InitialContext (верхний блок) создается список интероперабельных ссылок на объект, указывающих на каждый кластер демона службы адресации ячеек, который отправляется клиенту ORB посредством getProperties(). Когда ORB-клиент отправляет ORB-серверу следующие запросы, на стороне клиента плагин по управлению рабочей нагрузкой повторно проходит по списку и формирует запрос resolve_complete_info. Этот первый запрос отправляется демону службы адресации в NodeAgent (показан как первый запрос в среднем блоке), откуда необходимые данные кластера отправляются обратно клиенту в виде прямой IOR, указывающей на целевой сервер.

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


Заключение

Из данной статьи вы узнали, что такое ORB и каким образом он предоставляет среде исполнения сервера приложений функциональность, необходимую для обслуживания клиентов, отправляющих EJB-серверу удаленные запросы. Мы также рассказали о том, какая последовательность событий происходит при коммуникации между брокерами ORB и какую роль в ORB-взаимодействии между клиентами и серверами играет NodeAgent.

По этим вопросам есть много более подробной информации. Если есть желание продолжить изучение, можно посмотреть материалы по следующим темам:

  • Протокол GIOP
  • Выявление неполадок в ORB/EJB-контейнере
  • RMI поверх IIOP
  • Интерфейс Java Naming and Directory Interface (JNDI)
  • EJB-кластеризация
  • Управление рабочей нагрузкой WebSphere (WLM)
  • CORBA и OMG.

Благодарности

Авторы выражают свою благодарность Полу Буллису (Paul Bullis) и Клаудии Баррет (Claudia Barrett) за советы и разъяснения по темам, затронутым в данной статье.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, SOA и web-сервисы
ArticleID=424102
ArticleTitle=Как работают EJB-запросы в WebSphere Application Server V6.1
publish-date=08282009