Интернет-технологии и распределенная обработка данных (стр. 36 )

 

17.4 EJB контейнер и сервер

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

EJB Сервер определяется как Сервер Приложений, который содержит и запускает один или несколько EJB Контейнеров. Поставщик EJB Сервера отвечает за предоставление EJB Сервера. Вы можете полагать, что EJB Контейнер и EJB Сервер это одно и то же.

Java Naming и Directory Interface (JNDI)

Java Naming and Directory Interface (JNDI) используется в Enterprise JavaBeans в качестве службы указания имен для EJB компонент в сети и других службах контейнера, таких как транзакции. JNDI работает очень похоже с другими стандартами, такими как CORBA CosNaming, и может на самом деле быть реализован в виде надстройки над ним.

Java Transaction API/Java Transaction Service (JTA/JTS)

JTA/JTS используются в Enterprise JavaBeans в качестве API транзакции. Поставщик Enterprise Bean может использовать JTS для создания кода транзакции, хотя EJB Контейнер чаще всего реализует транзакцию в EJB на полезных EJB компонентах. Установщик может определить атрбуты транзакции EJB компонента во время развертывания. EJB Контейнер отвечает за обработку тразакции не зависимо от того, является ли она локальной или распределенной. Спецификация JTS является Java отображением на CORBA OTS (Object Transaction Service).

CORBA и RMI/IIOP

Спецификация EJB определяет взаимодействие с CORBA через совместимость с CORBA протоколами. Это достигнуто путем совмещения EJB служб, таких как JTS и JNDI, с соотвествующими службами CORBA и реализацией RMI поверх IIOP протокола CORBA.

Использование CORBA и RMI/IIOP в Enterprise JavaBeans реализовано в EJB Контейнере и за это отвечает поставщик EJB Котейнера. Использование CORBA и RMI/IIOP в EJB Контейнере спрятано от самого EJB Контейнера. Это означает, что Поставщик Enterprise Bean может написать свой EJB Компонент и развернуть его в любом EJB Контейнере не заботясь о том, какие коммуникационные прооколы он использует.

17.5 Составные части EJB компонента

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

Enterprise Bean

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

Домашний интерфейс

Каждый содающийся Enterprise Bean должен иметь ассоциированный домашний интерфейс. Домашний интерфейс используется как фабрика для вашего EJB. Клиент использует Домашний интерфейс для нахождения экземпляра вашего EJB или создания нового экземпляра вашего EJB.

Удаленный интерфейс

Удаленный интерфейс является Java Интерфейсом, который отображает через рефлексию те методы вашего Enterprise Bean, которые вы хотите показывать внешнему миру. Удаленный интрфейс играет ту же роль, что и IDL интерфейс в CORBA.

Описатель развертывания

Описатель развертываия является XML файлом, который содержит информацию относительно вашего EJB. Исползование XML позволяет установщику легко менять атрибуты вашего EJB. Конфигурационные атрибуты, определеные в описателе развертывания, включают:

Имена Домашнего и Удаленного интерфейса, которые требуются для вашего EJB Имя для публикации в JNDI для вашего Домашнего интерфейса EJB Транзакционные атрибуты для каждого метода вашего EJB Контрольный Список Доступа для авторизации

EJB-Jar файл

EJB-Jar файл - это обычный java jar файл, который содержит ваш EJB, Домашний и Удаленный интерфейсы наряду с описателем развертывания.

17.6 EJB операции

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

EJB Контейнер реализует Домашний и Удаленный интерфейсы, которые есть в EJB-Jar файле. Как упоминалось ранее, Домашний интерфейс обеспечивает методы для создания и нахождения вашего EJB. Это означает, что EJB Контейнер отвечает за уравление жизненным циклом вашего EJB. Этот уровень ненаправленности позволяет учитывать происходящую оптимизацию. Например, 5 клиентов могут одновременно запросить определенный EJB через Домашний интерфейс, а EJB Контейнер должен ответить созданием только одого EJB и распределением его между 5 клиентами. Это достигается через Удаленный интерфейс, который так же реализуется через EJB Контейнер. Реализованный Удаленный объект играет роль довертельного объекта для EJB.

Все вызовы EJB ‘проксирубтся(proxied)’ через EJB Контейнер посредством Домашнего и Удаленного интерфейса. Этот обходной путь является причиной того, что EJB контейнер может управлять безопасностью и поведением транзакций.

17.7 Типы EJB

Спецификация Enterprise JavaBeans определяет различные типы EJB, которые имеют разичные характеристики и поведение. В спецификации определены две категории EJB: Сессионный Компонент и Сущностный Компонент. Каждая категория имеет свои варианты.

17.8 Сессионный компонент

Сессионный компонент используется для представления случаев использования или порядока выполняеых действий с поьзой для клиента. Они представляют операции с постоянными данными, но не сами постоянные данные. Есть два типа Сессионных Компонентов: Без Состояния(Stateless) и Полного Состояния(Stateful). Все Сессионные Компоненты должны реализовывать интерфейс javax. ejb. SessionBean. EJB Контейнер управляет жизнью Сессионного Компонента.

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

Сессионный Компонент Полного Состояния содержит состояние между вызовами. Они имеют логику один к одному для клиентов и могут содержать состояния в себе. EJB Клнтейнер ответственен за объединение и кэширование Сессионных Компонентов Полного Состояния, что достигается через Неактивность и Активность. Если EJB Контейнер рушиться, данные всех EJB Сессионных Компонентов Полного Состояния могут быть потеряны. Некоторые высокоуровневые EJB Контейнеры обеспечивают восстановление Сессионных Компонентов Полного Состояния.

17.9 Сущностные компоненты

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

Есть два типа Сущностных Компонент: существующие с Управлением Контейнера (Container Managed persistence) и существующие с Управлением Компонентами (Bean-Managed persistence).

Container Managed Persistence (CMP). CMP Сущностные Компоненты реализованы с выгодой для EJB Контейнера. Через указанные в описании развертывания спецификации, EJB Контейнер связывает атрибуты Сущностных Компонент с некоторым постоянным хранилищем (обычно — но не всегда — это база данных). CMP снижает время разработки для EJB, так же, как и значительно снижает число требуемого кода.

Bean Managed Persistence (BMP). BMP Сущностные Компоненты реализовываются Поставщиком Enterprise Bean. Поставщик Enterprise Bean отвечает за реализацию логики, требуемой для создания новых EJB, изменения некоторых атрибутов EJB, удаление EJB и нахождение EJB в постоянном хранилище. Обычно для этого требуется написание JDBC кода для взаимодействия с базой данных или другим постоянным хранилищем. С помощью BMP разработчик имеет полный контроль над управлением существования Сущностного Объекта.

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

17.10 Разработка EJB

В качестве примера будет реализован EJB компонент “Perfect Time” из предыдущего раздела, посвященного RMI. Пример будет выполнен как Сессионный Компонент без Состояния.

Как упоминалось ранее, EJB компоненты содержат не менее одного класса (EJB) и двух интерфейсов: Удаленный и Домашний интерфейсы. Когда вы создаете Удаленный интерфейс для EJB, вы должны следовать следующим принципам:

1.  Удаленный интерфейс должен быть публичным (public).

2.  Удаленный интерфейс должен расширять интерфейс javax. ejb. EJBObject.

3.  Каждый метод удаленного интерфейса должен декларировать java. rmi. RemoteException в предложении throws помимо всех исключений, спецефичных для приложения.

4.  Лбой объект, передаваемый в качестве аргумента или возвращаемого значения (встроенный, либо содержащийся внутри локального объекта) должен быть действительным с точки зрения RMI-IIOP типом данных (это относится и к другим EJB объектам).

Вот простой удаленный интерфейс для PerfectTime EJB:

Листинг 39. PerfectTime. java