Терминология

Спецификация EJB (версия 1.1 на момент написания обзора) определяет несколько понятий, относящихся к ключевым аспектам технологии EJB.

EJB Server

Сервер EJB - это среда времени выполнения, в которой могут функционировать компоненты. Его задача - обеспечить доступ к системным сервисам, необходимым для работы компонентов. Важнейшим из этих сервисов является сервис распределенных транзакций (JTS). Сервер EJB не взаимодействует непосредственно с компонентами - это задача так называемого Контейнера (Container) EJB.

EJB Container

Контейнер EJB лучше всего рассматривать как некий логический уровень управления компонентами. Контейнер взаимодействует с сервером, когда одному или нескольким компонентам, находящимся под управлением Контейнера, необходим доступ к системным ресурсам. Контейнер представляет собой совокупность классов и программных средств, работающих в контексте Сервера EJB. Контейнер, в частности, обеспечивает:

· управление циклом жизни компонента - его созданием, инициализацией, сохранением его состояния в базе данных, если это необходимо;

· возможность поиска клиентом нужных ему объектов;

· гарантию того, что вызов методов происходит в контексте нужной транзакции;

· базовый уровень обеспечения безопасности;

· наличие инструментов разработчика, например, компилятора для генерации стабов.

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

Компонент EJB

Компонент EJB - это класс Java, который, собственно, и реализует всю необходимую функциональность. Необходимо четко понимать, что сам компонент в принципе недоступен для клиента. Клиент обращается к нему косвенно, через специальный интерфейсный объект-посредник (proxy). В литературе по EJB он обычно называется EJBObject. Время существования компонента и его proxy-объекта в общем случае различно. Сам компонент находится под управлением Контейнера, и пользователь в общем случае не может быть уверен, что два последовательных вызова клиента будут обслужены одним и тем же компонентом.

Компонентная модель накладывает определенные ограничения на структуру proxy-объекта; например, существуют жесткие правила соответствия имен компонента и его proxy-объекта. Как и в других технологиях создания распределенных систем, нет необходимости создавать класс (или классы) proxy-объекта «вручную» - они генерируются автоматически с помощью средств, предоставляемых поставщиком программного обеспечения.

Помимо EJBObject, модель EJB требует наличия другого вспомогательного объекта - так называемого HomeObject. Если EJBObject реализует так называемый Remote интерфейс, обеспечивающий доступ к бизнес-методам компонента после его создания, то HomeObject реализует Home интерфейс, который используется для создания компонентов. По сути, HomeObject является фабрикой компонентов. Поскольку EJB компонент - это еще и CORBA-объект, разумно использовать стиль CORBA для создания компонентов. Спецификация CORBA POA предоставляет все необходимые возможности.

Модель EJB предусматривает наличие двух видов компонентов - Session Bean и Entity Bean. При создании нового компонента его разработчик явно указывает тип:

public class MyBean implements javax.ejb.SessionBean { …

или

public class MyBean implements javax.ejb.EntityBean { …

Их поведение настолько различно, что спецификация содержит, по сути, два описания - для каждого из видов компонентов отдельно.

Session Bean

Каждый экземпляр такого компонента создается для обслуживания только создавшего его клиента. Если Session Bean имеет состояние (stateful Bean), то клиент может быть уверен, что при последующем вызове компонент будет находиться в состоянии, оставшемся от вызова предыдущего. Session Bean может и не иметь состояния (stateless Bean). При работе с компонентами c состоянием и без него Контейнер может вести себя по-разному.

Дело в том, что серверные объекты создаются по запросу клиентов, а ресурсы любого сервера (например, размер памяти) ограничены. В связи с этим контейнер может (руководствуясь теми или иными соображениями) временно удалять компонент из памяти, помещая его состояние, например, в объектную или реляционную базу данных. Этот процесс называется Деактивизацией (Passivation). Обратный процесс - размещение объекта в памяти с восстановлением его предыдущего состояния - называется Активизацией (Activation). Естественно, Session Bean, не имеющий состояния, может быть просто уничтожен Контейнером, а затем в нужный момент создан заново - совершенно прозрачным для клиента образом.

Entity Bean

Такие компоненты ориентированы на то, чтобы являться объектным представлением записи в реляционной базе данных. Здесь «ориентированы» не значит, что они не годятся ни для чего другого - просто удобнее всего в настоящее время их использовать именно таким образом. Обычно один такой компонент сопоставлен с одной записью в базе данных (разумеется, он может быть сопоставлен с одной записью не в таблице, а в представлении (view), которое содержит данные из нескольких таблиц). Поскольку данные одной записи должны быть доступны для нескольких клиентов сразу, Entity Bean должен быть доступен для нескольких клиентов и, следовательно, не может иметь состояния, относящегося к конкретному клиенту.

Транзакция

Как уже говорилось, в EJB используется спецификация управления транзакциями CORBA, реализованная на языке Java (JTS). Обычно разработчик не обращается к методам интерфейсов JTS, поскольку компонентная модель обеспечивает вспомогательный программный слой - Java Transaction API (JTA). Это и есть рабочий инструмент программиста при управлении транзакциями.

Поскольку спецификация CORBA OTS четко определяет участников распределенной транзакции и их роли, JTA также поступает подобным образом. Участниками транзакции с точки зрения JTA являются:

· ресурс, под которым понимается соединение с базой данных;

· менеджер ресурсов - драйвер JDBC;

· сервер приложений - Сервер EJB;

· менеджер транзакций и

· транзакционное приложение, т.е. компонент или клиент.

Для каждой из этих ролей в JTA определены соответствующие интерфейсы.

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

Транзакция, управляемая компонетом (Bean Managed Transaction, BMT)

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

Транзакция, управляемая Контейнером (Container Managed Transaction, CMT)

Режим разрешен как для Session-, так и для Entity-компонентов. Компонент не имеет возможности ни начать, ни завершить транзакцию (хотя любой из участников транзакции может потребовать ее отката (rollback) при завершении) - управление транзакцией полностью берет на себя Контейнер. Транзакция начинается при вызове каждого удаленного метода и завершается при возврате из него. Программист может установить один из нескольких разрешенных режимов, определяющих поведение транзакции.

Дескриптор развертывания (Deployment descriptor)

Дескриптор развертывания (иногда используются термины «установки» или «поставки» - в настоящий момент еще нет устоявшегося термина на русском языке)- необходим для настройки созданного компонента на работу в конкретной операционной среде. Необходимость в нем возникает из-за того, что спецификация EJB четко определяет несколько этапов, который проходит компонент от своего создания до доставки конечному пользователю с окончательной настройкой. Об этих этапах уже говорилось ранее. Наличие подобного «конвейера» требует передачи информации от одного этапа к другому. С каждым компонентом сопоставлен свой дескриптор.

Спецификация EJB 1.1 требует, чтобы Дескриптор Развертывания имел XML-формат. Поскольку XML является метаязыком, то для описания каждого конкретного класса документов нужно создать свой язык - в частности, определить набор используемых тегов и правила взаимоотношений между ними. Такой язык называется Document Type Definition (DTD).

Дескриптор Развертывания соответствует DTD, разработанному фирмой Sun Microsystems. Он содержит набор свойств, который описывает, как Контейнер будет выполнять процесс развертывания Компонента или приложения, и включает набор тегов и атрибутов, чьи значения определяют состояние свойств Компонента. В качестве примера приведем несколько тегов:

<session> - говорит о том, что Компонент является session-Компонентом (тег <entity> используется для обозначения Entity-Компонентов).
Внутри области тега <session> могут использоваться другие теги:
<ejb-class> - имя класса реализации.
<home> - имя home-интерфейса.
<remote> - имя remote-интерфейса.
<session-type> - показывает, является ли session-Компонент stateful- или stateless-Компонентом.
<transaction-type> - показывает, используется ли для Компонента CMT или BMT.
<trans-attribute> - задает значение атрибутов транзакции для каждого метода.
<timeout> - значение тайм-аута для session-Компонента.

В качестве примера приведем фрагмент Дескриптора Развертывания для компонента Cart, поставляемого в качестве примера с Inprise Application Server 4.0:

<ejb jar>
<enterprise beans>
<session>
<description>
XML deployment descriptor created from file:
D:\Kodiak\kodiak04\ejb_ea_0_4\examples\cart\cart.ser
</description>
<ejb-name>cart</ejb-name>
<home>CartHome</home>
<remote>Cart</remote>
<ejb-class>CartBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>cart</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>cart</ejb-name>
<method-name>purchase</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

Дата добавления: 2013-12-13