Платформа J2EE. Когда следует применять EJB. Типы EJB. Общая структура Beans.

Компоненты EJB выполняются внутри EJB-контейнера, который в свою очередь выполняется внутри EJB-сервера.

EJB-компонента представляет из себя Java-класс, который реализует некоторую бизнес-логику.

EJB-контейнер -- это то место, где ``живет'' EJB-компонент.

EJB-объекты и EJB-компоненты представляют собой разные классы, хотя ``снаружи'' (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс. Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно (через remote interface) вызывает методы у EJB-компоненты.

Существует два различных типа ``бинов'': session и entity.

Sessionbean представляет собой EJB-компоненту, связанную с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. Несмотря на то, что в процессе своей работы, sessionbean может сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.

Entitybean, наоборот, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entitybeans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entitybeans живут постоянно. Клиент создает на EJB-сервере объекты и работает с ними так же, как если бы это были локальные объекты. Это до предела упрощает разработку. Разработчик может легко создавать, использовать и уничтожать объекты, а эти объекты, в свою очередь, выполняются на сервере. Итак, sessionbeans в большинстве своем работают с информацией, относящейся к ``диалогу'' между клиентом и сервером, в то время как entitybeans представляют собой экземпляры данных и работают с ``постоянными'' данными из баз данных.

Каждый экземпляр ``бина'' имеет свой уникальный идентификатор. Для entity объектов уникальный идентификатор, как правило, совпадает с (или каким-либо образом получается из) уникального идентификатора данных (обычно, как первичный ключ сущности БД), которые он представляет. То есть в данном случае существует нечто вроде первичного ключа для всех entitybeans. Идентификатор же sessionbeans может быть практически любым -- например он может состоять из имени сервера и порта удаленного соединения, а может создаваться случайным образом.

29Понятие, определение и использование удаленного (Remote) и локального интерфейсов. Их применение и программная реализация (примеры).

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

Удаленный доступ

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

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

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

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

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

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

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

//: Sample.java

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

import java.rmi.*;

import javax.ejb.*;

 

public interface Sample extends EJBObject {

publiclonggetSample() //метод реализации бизнес-логики

throwsRemoteException;

} ///:~

Локальный доступ

Чтобы построить корпоративный бин, допускающий локальный доступ, вы должны закодировать локальный интерфейс и локальный домашний интерфейс. Локальный интерфейс определяет бизнес-методыбина, а локальный домашний интерфейс определяет его жизненный цикл и методы поиска. Если бин сущности является целью в отношениях, управляемых контейнером, то он должен иметь локальные интерфейсы. Бины сущностей, участвующие в отношениях, управляемых контейнером, должны размещаться в одном и том же EJB JAR-файле, так как они требуют локального доступа. Главная выгода этой локальности - увеличение производительности: локальные вызовы обычно выполняются быстрее, чем удаленные.

Локальный клиент имеет такие характеристики:

Он должен выполняться на той же JVM, что и корпоративный бин, к которому он обращается.

Он может быть Web-компонентом или другим корпоративным бином.

Для локального клиента местонахождение корпоративного бина, к которому он обращается не прозрачно.

Часто это - бин сущности, который имеет отношения, управляемые контейнером, с другим бином сущности.

Вот простой локальный интерфейс для LocalCustomer EJB:

 

import java.rmi.*;

import javax.ejb.*;

 

public interface LocalCustomer extends EJBLocalObject {

String getCustomerName();

void setCustomerName(String customerName);

LocalAddressgetAddress();

void setAddress(LocalAddress address);

}

 

30 Понятие, определение и использование собственного (HOME) интерфейса. Их программная реализация (примеры).

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

Для каждого создающегося класса EnterpriseBean необходимо разработать ассоциированный с ним домашний интерфейс. Домашний интерфейс используется как фабрика объектов (т.е., основная задача домашнего интерфейса создать реальный объект EnterpriseBean для решения задачи). При этом используется JNDI, в контексте которого известно место расположения домашнего интерфейса, на который возвращается ссылка. Клиентское приложение использует Home интерфейс для нахождения экземпляра EJB или создания нового экземпляра вашего EJB.

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

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

Домашний интерфейс должен расширять интерфейс javax.ejb.EJBHome.

Каждый метод create Home-интерфейса должен декларировать java.rmi.RemoteException в преложенииthrows наряду с javax.ejb.CreateException.

Возвращаемое значение метода create должно иметь тип Удаленного интерфейса.

Возвращаемое значение метода finder (только для Сущностных Компонент) должно иметь тип удаленного интерфейса или java.util.Enumeration, или java.util.Collection.

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

Принятое стандартное соглашение об именах Домашних интерфейсов состоит в прибавлении слова “Home” в конец имени Удаленного интерфейса. Вот Домашний интерфейс для Sample EJB:

// Для удаленного интерфейса Sample

// Домашний интерфейс бина: SampleBean.

importjava.rmi.*;

importjavax.ejb.*;

 

publicinterfaceSampleHomeextendsEJBHome {

public Sample create()

throwsCreateException, RemoteException;

} ///:~