Enterprise JavaBeans. Часть 2

Базовая структура EJB показана на рисунке 2 и состоит из:

Cервера EJB
Контейнеров EJB, которые работают внутри сервера
Home-объектов, remote-объектов EJBObjects, и EJB, которые работают в контейнерах
Клиентов EJB
Вспомогательных систем, таких как JNDI, JTS, систем безопасности и так далее.

Рисунок 2: Базовая структура EJB

EJB Server - сервер EJB                                            Data Bases - базы данных

EJB Container - контейнер EJB                               EJB Client - клиент EJB

Home Interface - Home-интерфейс                          Home Object - Home-oбъект

Remote Interface - Remote-интерфейс                     EJB Object - объект EJB

Locate, create and remove instance of EJB - разместить, создать и переместить экземплар EJB

Invoke business methods of EJB - вызывать бизнес-методы EJB

Enterprise Services and API - службы и API   

Naming Service (JNDI) - служба имен

Transaction Service (JTG) - служба транзакции

Security - безопасность

Messaging - передача сообщений    

Сейчас, давайте исследуем основные компоненты архитектуры EJB более подробно:

Сервер EJB

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

В некотором отношении, сервер EJB является аналогом CORBA's Object Transaction Monitor (OTM). OTM также обеспечивает среду для выполнения действий серверных компонентов CORBA.

Контейенеры EJB

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

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

Существуют 2 типа контейнеров: session-контейнеры, которые могут содержать кратковременные несохраняющиеся EJB, чьи состояния не сохраняются, и entity-контейнеры, которые содержат постоянные EJB, чьи состояния сохраняются между запусками.

Home-интерфейс и Home-объект

Factory-методы для нахождения, создания и удаления экземпляров классов EJB определяются в home-интерфейсе. Home-объект является реализацией home-интерфейса. Разработчик EJB сначала должен определить home-интерфейс для своего бина. Производитель контейнера EJB предоставляет средства, которые автоматически генерируют код-реализацию для home-интерфейса, определенного разработчиком EJB.

Remote-интерфейс и EJBObject

Remote-интерфейс перечисляет бизнес-методы, доступные для EJB. EJBObject является клиентским представлением EJB и реализовывает remote-интерфейс. В то время как разработчик EJB определяет remote-интерфейс, производитель контейнера предоставляет средства, необходимые для генерации кода для соответствующего EJBObject. Каждый раз, когда клиент вызывает методы EJBObject, контейнер EJB сначала обрабатывает запрос перед тем, как  отправить его EJB.

EJB

Настоящий EJB содержится сам по себе в контейнере EJB и никогда не должен быть напрямую доступен никому кроме контейнера. Хотя прямой доступ может быть возможен, это не рекомендуется, так как разрывает связь (контракт) между бином и контейнером.

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

Клиенты EJB

Клиенты EJB находят определенный контейнер EJB, который содержит EJB через Java Naming  and Directory Interface (JNDI) (Java-интерфейс именования и каталогов). Затем они используют контейнер EJB для вызовов методов бина. Клиент EJB только получает ссылку на  экземпляр EJBObject и никогда в действительности не получает ссылку на текущий экземпляр собственно EJB. Когда клиент вызвает метод, экземпляр EJBObject принимает запрос и перенаправляет его соответствующему экземпляру бина, педоставляя всю необходимую дополнительную функциональность.

Клиент использует home-объект для нахождения, создания, или разрушения экземпляров EJB. Затем он использует экземпляр EJBObject для вызова бизнес-методов экземпляра бина.

Жизненый цикл EJB

В любом сценарии разработки обычно содержатся многочисленные сложные программные проблемы, которые требуют вовлечения многочисленных специалистов в определенной области знаний. Без рассмотрения всех этих проблем и связанных командно-ориентированных подходов, невозможно создать успешные приложения масштаба предприятия. Для облегчения промышленной разработки спецификация EJB  определяет обязательства или роли. Спецификация EJB также определяет, кто ответственен за доставку того, что eсть в приложении, которое использует EJB, как показано на рис.3. Обратите внимание, что спецификация EJB не обязательно препятствует одному и тому же человеку в исполнении более чем одной роли.

Рисунок 3: Жизненный цикл типичного EJB

EJB Server Provider - провайдер сервера EJB

EJB Server - сервер EJB

EJB Container Provider - провайдер контейнера EJB

EJB Container - контейнер EJB

EJB Developer - разработчик EJB

Enterprise JavaBean

EJB Deployer - специалист по внедрению EJB

EJB Application - приложение EJB

EJB Application Developer/EJB User - разработчик приложения EJB/пользоыватель EJB

Давайте ближе рассмотрим разные роли спецификации EJB, которые она подробно определяет:

Провайдер сервера EJB

Провайдер сервера EJB обеспечивает организованную среду выполнения, в которой действуют контейнеры EJB. Производитель сервера EJB выполняет и обеспечивает доступ к службе имен, совместимой с JNDI и службе транзакций, которая совместима с CORBA-OTS. Обратите внимание, что производитель сервера EJB может также выступать в качестве производителя контейнера EJB.

Провайдер контейнера EJB

Провайдер контейнера EJB предоставляет программное обеспечение для инсталляции EJB с поддерживающими классами на сервере EJB. Производитель контейнера также отвечает за предоставление классов времени выполнения, которые обеспечивают необходимые сервисы для экземпляров EJB. Они включают генерацию stub- и skeleton-классов для предоставления доступа  к home-объекту требования EJB и EJBObject, установление ссылок к home-объекту в пространстве имен доступном JNDI. Дополнительно, он также должен делать доступным подходящую реализацию EJBObject, которая может обеспечить правильный proxy-сервис для классов EJB.

Разработчик EJB

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

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

Специалист по внедрению/установке EJB

Хотя специалист по внедрению EJB может и не быть разработчиком Java или понимать бизнес-правила, которые реализует класс EJB, он или она должен понимать среду приложения, в которой запускается экземпляр EJB. Дополнительно, специалист по внедрению должен всестороннее понимать характеристики оперативных средств сервера, таких как типы базы данных, ее расположение и так далее. Специалист по внедрению ответственен за определение EJB и всех их поддерживающих классов и их правильную инсталляцию на сервере EJB. 

Специалист по внедрению получает требования класса EJB от разработчика EJB, такие как потребности транзакций, имена, и описание необходимых параметров среды, и так далее. Специалист по внедрению ответственнен за обеспечение доступности таких параметров (вместе с их корректными значениями) классу EJB во время исполнения. Специалист по внедрению также должен обеспечивать доступность home-объекта для класса EJB в пространстве имен и посредством JNDI. Специалист по внедрению и разработчик должны четко общаться, чтобы быть уверенными в том, что класс EJB внедряется с правильными атрибутами установки.

Разработчик Приложения

Разработчик приложения пишет клиентские приложения, используя заготовки компонентов EJB. Здесь, определяется клиент в общих чертах и может быть приложением Java,  апплетом, сервлетом, приложением CORBA, или даже элемент управления ActiveX, соединяющийся посредством моста COM-CORBA.

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

TOC | Часть 3