Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 4. Распределенные компненты EJB 201
не предназначены для считывания данных с клавиатуры и использования AWT-библиотеки для отображения информации. На сетевом уровне
Enterprise bean запрещено работать с сокетами. На системном уровне
проектирования EJB отсутствует возможность использования библиотек, созданных на других языках программирования.
Различные Application Server имеют встроенные контейнеры для
различных типов EJB. В большинстве случаев количество контейнеров
не является столь важным, как возможность работы контейнера различными способами. Фирма SUN в своей спецификации указывает один
общий контейнер для всех Enterprise Bean. Именно это решение и присутствует в распространяемом сервере приложений J2EE. Компания
IBM поставляет свои WEBSphere Application Server в различных конфигурациях, как с одним, так и с двумя контейнерами. Различий в создании EJB для одно- и многоконтейнерных версий не существует. Другие компании наделяют свои контейнеры способностью к клонированию
по вызову или при установке. Любой подход имеет право на жизнь, и
преимущества каждого подхода видны только при конкретном использовании в правильно спроектированном приложении.
Среда выполнения организует программные возможности исполнения EJB. Кроме самих EJB, в этой среде могут размещаться другие Java EJB, такие, как servlet и JSP.
30.2. Источник данных
Источником данных необязательно является СУБД, он может быть
плоским файлом или любым другим приложением. Спецификация EJB
не требует, чтобы источником данных обязательно была СУБД. Enterprise bean для организации доступа к различным источникам должны
использовать различные методы. Поскольку EJB представляют бизнеслогику приложения, использование источника данных в виде СУБД
имеет ряд преимуществ. Во-первых, создание приложения, использующего базу данных, достаточно простой процесс. Во-вторых, применение
SQL в программе облегчает работу с СУБД, данные не надо хранить в
самом приложении, ответственность за целостность данных полностью
лежит на СУБД. В-третьих, данные, хранимые в СУБД, могут одновременно использовать несколько клиентов. Каждый контейнер использует
собственные источники данных. Каждый производитель сервера приложений, соответствующего стандарту J2EE, предлагает для своих контейнеров различные источники данных. Фирма SUN поставляет свой
пакет с базой данных фирмы Cloudscape, а компания IBM интегрирует
свой WEBSphere Application Server с DB2, Oracle и Sybase. Кроме этого, двухконтейнерная версия WEBSphere Application Server поддерживает стандартные средства компании IBM — IBM CICS, IBM IMS и IBM
MQSeries. Другие производители могут использовать другие источники
данных, поддерживающие стандарт ODBC.
Если возможностей СУБД не хватает или необходимо использовать
другой источник, EJB должны разрабатываться с помощью контейнернезависимого способа BMP.
202 Часть 4. Распределенные компненты EJB
В спецификации 1.1 точно не определено, какой тип базы данных
должно использовать EJB-приложение. Два основных типа enterprise
bean имеют доступ к базе данных, но если Entity bean сам по себе является отражением данных, хранящихся в СУБД, то session bean является
отражением клиентской сессии, однако это обстоятельство не запрещает использовать SQL-операторы в теле session bean:
1. Если приложение достаточно простое и не производит значитель-
ных транзакций.
2. Если возвращаемые SQL-оператором данные не используются в
многоклиентской сессии.
3. Если данные не представляют деловой объект.
Доступ к базе данных из Entity bean возможен при следующих условиях:
1. Более чем один клиент использует данные.
2. Данные описывают бизнес-логику приложения.
3. Для скрытия информации об используемой базе данных в session
bean прописываются все параметры доступа (что не есть хорошо, в entity bean данные берутся из самой базы).
Стандартным интерфейсом доступа к базе данных является JDBCверсии 1.0 или 2.0, в зависимости от типа драйвера доступа к базе данных. Новые версии контейнеров EJB реализуют интерфейс DataSource
JDBC 2.0. Это означает, что EJB может использовать интерфейс
javax.sql.DataSource, а не javax.sql.DriverManager, хотя интерфейс DriverManager все еще поддерживается для совместимости с предыдущими версиями. Рекомендуется использовать интерфейс DataSource
вследствие более высокой его производительности. Работа с этим интерфейсом не требует наличия драйверов JDBC 2.x; приложение может использовать существующие драйвера JDBC 1.x. Кроме того, при замене
драйверов JDBC 1.x на JDBC 2.x в приложение не требуется вносить
никаких изменений.
Новая спецификация доступа SQLJ применяется достаточно редко в
связи с неопределенностью некоторых основных производителей СУБД
о поддержке данной технологи, а также реализацией доступа различными серверами приложений. Пулы доступа к базам данных могут находиться в адресном пространстве того же процесса, в котором исполняется контейнер EJB или, с целью повышения производительности,
выполняется как отдельный поток.
30.3. Типы клиентов
В спецификации EJB описаны два вида клиентов, способных работать с методами, предоставляемыми EJB:
— HTTP-клиент взаимодействует с EJB-сервером, используя HTTPпротокол и другие Java EJB, servlets или JavaServer Pages (JSP), пару
applet-servlet;
— RMI-клиент описывает взаимодействие Java-приложений с EJBсервером при посредничестве протокола Java вызова удаленных ме-
Часть 4. Распределенные компненты EJB 203
тодов (RMI)-используемого поверх Internet Inter-ORB Protocol
(RMI/IIOP).
К счастью, различия между использованием этих двух протоколов
минимальны с точки зрения программирования EJB.
Оба типа клиентов используют сервис транзакций, основанный на
JTA-спецификации.
Клиентом EJB является независимое (stand-alone) приложение —
servlet или апплет — или другой EJB. В любом случае для использования EJB клиент должен выполнить следующие действия:
1. Получить доступ к home-интерфейсу EJB. Спецификация EJB говорит, что для получения ссылки на интерфейс клиенту следует использовать JNDI (Java Naming and Directory Interface) API.
2. Получить ссылку на remote-интерфейс EJB. Для этого используются методы home-интерфейса. Можно либо создать Session-bean, либо
создать или найти Entity bean.
3. Вызвать те или иные методы, доступные методы EJB. Клиент не
может обращаться непосредственно к методам собственно EJB. Вместо
этого он вызывает методы его remote-интерфейса. Это те методы, которые EJB объявляет доступными для клиента.
Каждый EJB-клиент, использующий http-протокол для доступа к
enterprise bean, использует два уровня безопасности:
а. Первый предоставляется Web-сервером, например, при использовании https-протокола.
б. Другой обеспечивается EJB-контейнером.
Клиенты EJB, представляющие Java-приложения, использующие
протокол RMI, используют только второй уровень, предоставляемый
EJB-контейнером.
Оба типа EJB-клиентов используют стандартный JTA-интерфейс
для обеспечения транзакций.
Кроме стандартных типов клиентов, EJB-сервер поддерживает работу с Microsoft ActiveX EJBми, CORBA объектами написанных на Java,
CORBA-объектами, написанными на C++.
30.4. Интерфейс управления
Интерфейс управления предназначен для возможности манипулирования системным окружением EJB-сервера. Обычно под интерфейсом
управления понимается системная консоль администратора. Больше об
интерфейсе управления конкретного EJB-сервера можно узнать из документации, поставляемой на Application Server.
Большинство коммерческих продуктов, основанных на EJB-технологии, предлагают графические средства управления EJB-контейнером.
Вместе с тем полного отказа от использования командной строки не
произошло, и еще можно встретить EJB-серверы, управляемые рукотворным вводом.
Независимо от используемого интерфейса управления, графического
интерфейса или командной строки, основными характеристиками сервера можно считать все сервисы, предоставляемые EJB-сервером.
204 Часть 4. Распределенные компненты EJB
Используемая база данных, тип менеджера транзакции, способы реализации транзакций, способы обеспечения безопасности — внешние
сервисы, настраиваемые с помощью интерфейса управления. Именно
через интерфейс управления определяется количество используемых
EJB-контейнеров, а также ряд важных характеристик, присущих EJBконтейнерам.
Основными параметрами EJB-контейнеров являются параметры,
описывающие работу с памятью, точнее, работу с системным кэшем.
Для каждой конкретной версии EJB-контейнера описываются собственные параметры настройки.
Если предполагается использование средства разработки сторонних
разработчиков относительно сервера приложений, для предотвращения
различного рода ошибок используйте при работе с EJB только те средства взаимодействия с EJB-контейнерами, которые входят в состав этого средства. Следует также убедиться в том, что инструмент поддерживает правильные версии спецификации EJB и API EJB. Также необходимо убедиться, что установлена верная версия JDK.
30.5. Общие принципы работы EJB-технологии
Все описанные выше EJB-архитектуры предназначены для одной
цели, — создания распределенного приложения, используемого в ecommerсe.
На первом этапе HTML-страница, показанная в Web-браузере клиента, организует доступ к Web-контейнеру, содержащему servlet или
JSP. После формирования объекта request Web-компонент servlet или
JSP перенаправляет объект request в EJB-контейнер. Контейнер EJB
создает экземпляр session bean home-интерфейса, вызывая методы create() или findByPrimaryKey(). Созданный session bean ассоциируется с
пользовательским запросом, объектом request. Метод create() возвращает значение remote-интерфейса созданного bean. Клиентский запрос
осуществляет размещение или поиск уже существующего EJB с помощью home-интерфейса. Использование поисковых и отправляемых данных Web-клиентом вызывает бизнес-методы, описанные в remote-ин-
Ðèñ. 4.2.
Часть 4. Распределенные компненты EJB 205
терфейсе session bean. Прежде чем вызвать бизнес-методы, описанные
в EJB-remote-интерфейсе, клиент должен создать или найти необходимый объект. Использование JNDI помогает системе найти нужный объект. EJB-клиент вызывает session bean и ассоциированный с ним Entity
bean (рис. 4.2).
Глава 31. Основные Enterprise Java Bean, Entity bean и Session bean
При разработке EJB создаются два типа компонентов, методы бизнес-логики и системные методы самого EJB. Сам EJB представляет собой несколько классов, особенных для каждого EJB и два интерфейса — remote и home. Основной Bеаn — Entity bean — является объектом, свойства которого описаны в базе данных. Доступ к Entity bean
могут осуществлять через методы, описанные в интерфейсе, несколько
клиентов, одновременно работающих с данными, предоставляемыми
Entity bean. Session bean, в отличие от Entity bean, ассоциирован только
с одиночной, пользовательской сессией. Все рабочие данные session bean, удаляются после окончания пользовательской сессии.
Для всех размещаемых в контейнере Enterprise Bean соблюдаются
определенные правила. Во-первых, каждый EJB обязательно содержит
описание двух интерфейсов — home и remote и одного основного класса. Во-вторых, каждый создаваемый EJB должен наследоваться от конкретного интерфейса. Основной класс entity bean наследует интерфейс
javax.ejb.EntityBean, а session bean — javax.ejb. SessionBean.
Каждый домашний интерфейс — home и remote — основного EJB
наследуется от специфических интерфейсов, javax.ejb.EJBHome и javax.ejb.EJBObject соответственно (рис. 4.3).
Ðèñ. 4.3.
31.1. Home-интерфейс
Интерфейс home содержит методы для создания, поиска и уничтожения EJB. Для различных типов EJB home-интерфейс описывается поразному. Home-интерфейс для Session bean (stateless) значительно проще, поскольку содержит только один метод create() без аргументов. У En-
206 Часть 4. Распределенные компненты EJB
tity bean, кроме основных методов установки, create() и remove(), описывается дополнительный метод поиска существующего экземпляра findByPrimaryKey(). В теле home-интерфейса session bean (statefull) может
содержаться несколько методов create(), с различными аргументами:
import javax.ejb.*;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.*;
public interface SampleHome extends javax.ejb.EJBHome {;
Remote_object create() throws java.rmi.RemoteException, javax.ejb.CreateEx-
ception;}
Циклы жизни Session- и Entity-компонентов отличаются друг от
друга. Жизненные циклы каждого EJB описаны ниже в этой главе. Следовательно, их home-интерфейсы содержат различные методы. Разработчик обязан объявить home-интерфейс, но за его реализацию отвечает контейнер EJB. Как и в случае с remote-интерфейсом, все аргументы
и типы результата методов, объявленных в home-интерфейсе, должны
соответствовать требованиям RMI-IIOP. Все методы должны содержать
исключение java.rmi.RemoteException в своем throw-списке исключений. В home-интерфейсе должны быть объявлены один или несколько
методов create(). Имя такого метода должно быть именно create, а его
аргументы — как их число, так и типы — должны быть такими же, как
аргументы метода ejbCreate() класса реализации EJB. Родительский интерфейс javax.ejb.EJBHome содержит описание трех методов жизненного цикла EJB. Предусмотрены два варианта метода удаления remove()
экземпляра EJB из контейнера. Первый из них удаляет экземпляр EJB
по его идентификатору (handle), второй — по значению primary key Entity bean. Handle EJB представляет собой его уникальный идентификатор; для него может быть выполнена операция сериализации Java. Времена существования handle и сопоставленного с ним объекта совпадают.
При работе с Entity bean клиент может сохранять (с помощью Java-сериализации) значение этого идентификатора с последующим восстановлением в нужный момент. Этот идентификатор может корректно ссылаться даже на различные экземпляры EJB ; он остается корректным даже после сбоя на сервере с последующим перезапуском, а также в
случае перемещения объектов на другие серверы или компьютеры.
Второй вариант remove() для определения подлежащего удалению экземпляра EJB использует значение его primary key. Его типом может
быть любой тип Java, который наследует класс Object и реализует интерфейс Serializable. Primary key — главное средство для идентификации Entity bean. Как правило, он совпадает с первичным ключом в таблице базы данных, используемым для уникальной идентификации записи,
объектным представлением которой является данный bean. Метод getEJBMetaData() возвращает metadata-интерфейс для EJB. Этот интерфейс
предоставляет клиенту возможность получить информацию о структуре
EJB (его метаданные). Обычно его используют инструментальные программные средства, создающие приложения из поставленных EJB.
Часть 4. Распределенные компненты EJB 207
31.2. Remote-интерфейс
Все бизнес-методы, описанные в основном классе EJB, доступны
клиенту через remote-интерфейс. Каждый метод, объявленный в интерфейсе Remote_object, должен иметь соответствующий метод в
основном классе; методы должны иметь одинаковые имя и сигнатуры:
import javax.ejb.*;
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.Vector;
public interface Remote_object extends javax.ejb.EJBObject {;
Vector some_method()
java.rmi.RemoteException;}
Remote-интерфейс EJB является public-интерфейсом, который наследуется от другого интерфейса javax.ejb.EJBObject. Родительский интерфейс имеет ряд замечательных методов, предназначенных для определения внешних данных, таких как ссылка на home-интерфейс, указание primary key и пр. Метод getEJBHome() позволяет вам получить
соответствующий home-интерфейс. При работе с Entity bean, можно
воспользоваться методом getPrimaryKey() для получения Primary Key
Entity bean. Метод remove() уничтожает экземпляр из временного пула
контейнера. Метод getHandle() возвращает ссылку на экземпляр EJB.
Эта ссылка имеет смысл до тех пор, пока существует экземпляр EJB.
Метод isIdentical () позволяет сравнивать EJB на идентичность.
По требованиям спецификации EJB 1.1 все методы remote-интерфейса должны иметь уровень доступа к public и возбуждать исключение java.rmi.RemoteException. Кроме того, аргументы этих методов и
возвращаемые ими результаты должны иметь типы, соответствующие
требованиям RMI-IIOP. Должно быть обеспечено соответствие между
методами основного класса и методами его remote-интерфейса. Каждая
пара методов класа и интерфейса должна иметь одно и то же имя, число и тип аргументов, тип результата и список возможных исключений.
Основной класс EJB
Независимо от создаваемого типа EJB, будь то Entity или session,
кроме домашних интерфейсов каждый EJB должен содержать основной
класс. Bean. Основной класс определяет бизнес-методы, к которым может обращаться клиент. Класс SampleBean содержит реализации метода some_method(). Именно использование этого метода делает приложение доступным для клиента. Также в основном классе описывается метод ejbCreate(), который соответствует методу create() homeинтерфейса. Home-интерфейс SampleHome определяет единственный
метод create() без аргументов, возбуждает исключение java.rmi.RemoteException. Класс SampleBean реализует метод ejbCreate() без аргументов и также возбуждающий исключение java.rmi.RemoteException. Метод ejbCreate() ничего не возвращает, т. е. void.
208 Часть 4. Распределенные компненты EJB
Класс SampleBean не имеет public-конструктора, хотя это и разрешено. SamleBean объявляет четыре метода, помимо бизнес-методов и
методов создания (create). Вот эти методы: ejbRemove(), ejbPassivate(),
ejbActivate() и ejbSessionContext(). За реализацию этих методов отвечает EJB-контейнер. Класс SampleBean должен просто их объявить как
public-методы, возвращающие тип void.
public class SampleBean implements javax.ejb. SessionBean {
public void setSessionContext(javax.ejb.SessionContext
sessionContext) {}
public void ejbCreate() throws java.rmi.RemoteException {}
public void ejbRemove() throws java.rmi.RemoteException {}
public void ejbActivate() throws java.rmi.RemoteException {}
public void ejbPassivate() throws java.rmi.RemoteException {}
public Vector some_method() throws
java.rmi.RemoteException {
try (...
return result;}
catch(javax.ejb.CreateException e) {
throw new java.rmi .serverException(«Could not create ejb», e);}
catch(javax.ejb. RemoveException e) {
throw new java.rmi .serverException(«Could not remove sort instance», e);}}
Между home- и remote-интерфейсами и основным классом EJB не
существует никаких формальных отношений, подобных отношению наследования. Тем не менее спецификация определяет правила, которым
должны подчиняться, например, имена методов, объявленных в этих
двух интерфейсах и классе. Например, если объявить некоторый метод
основного класса EJB, реализующий часть его функциональности (бизнес-логики), то точно такой же метод — с тем же именем и такой же
сигнатурой — должен быть объявлен в remote-интерфейсе. Каждый экземпляр имеет как минимум один метод с именем ejbCreate(); при этом
он может иметь несколько методов с таким именем, но различными аргументами. Каждому из таких методов должен быть поставлен в соответствие метод с таким же списком аргументов, но с именем create().
Еще одно отличие состоит в том, что метод ejbCreate() класса возвращает другой тип результата по сравнению с методом create() home-интерфейса: create() возвращает тип remote-интерфейса, а ejbCreate()либо void (в случае использования сохранения, управляемого контейнером, CMP), либо тип Primary Key Entity bean (при использовании
сохранения, управляемого EJB, BMP).
31.4. Entity beans
Entity bean содержит постоянные данные, которые хранятся во
внешних источниках, таких, как базы данных или файловые системы, и
имеет методы для манипулирования этими данными. В большинстве
случаев entity bean должен использовать транзакционный механизм
Часть 4. Распределенные компненты EJB 209
для синхронизации изменяемых данных. Entity bean включает в себя
бизнес-логику приложений. Для предотвращения потери данных, entity
bean размещает свои данные в базе данных. В спецификации EJB определены два вида Entity bean: первый использует свойства контейнера
для организации своей работы. Свойства, заданные по умолчанию, используются контейнером при работе с EJB. Называется данный способ
Container Managed Persistence (CMP). Контейнер полностью несет ответственность за данные, используемые Entity bean, другой, более гибкийивтожевремя более сложный способ называется Bean Managed
Persistence (BMP). При данном методе сам разработчик переопределяет
необходимые методы, в том числе самостоятельно организует доступ к
базе данных, хранящей EJB-переменные. В этом случае сам bean отвечает за сохранность данных, представленных Entity bean. Чаще всего
этот способ используется для организации доступа к базе данных, не
поддерживаемой EJB-сервером. Entity bean представляют собой объектное представление данных из СУБД. Несколько клиентов могут одновременно обращаться к одному экземпляру Entity bean. При изменении
содержимого таблицы базы данных соответствующие Entity bean также
меняют свои данные. Состояние Entity bean в общем случае нужно сохранять, и «живут» они столько, сколько существуют в базе данных те
данные, которые они представляют, (а не столько, сколько существуют
клиентский или серверный процессы). Остановка или «падение» сервера
не приводит к уничтожению содержащихся в EJB-контейнере Entity
bean. Каждый Entity-компонент характеризуется своим уникальным
идентификатором — primary key. Обычно это тот же самый primary
key, что и идентификатор данных в БД, Primary key используется для
поиска нужного EJB в исполняемом окружении.
31.5. Session beans
Другой enterprise bean — session bean содержит временные значения, необходимые для работы клиента с EJB. В противоположность entity bean, session bean не хранит данные во внешних источниках, а хранит таковые во временных. Однако session bean может изменять данные, которые хранятся в базе данных и используются entity bean, но
session bean непосредственно не связан с представлением данных в базе
данных. Объект session bean создается контейнером как ответ на поступивший от клиента запрос. Session bean представляет собой объекты,
созданные для обслуживания запросов только одного клиента. Каждый
session bean ассоциирован с одним клиентским запросом, жизнь session
bean продолжается до тех пор, пока продолжается клиентская сессия,
после окончания сессии экземпляр session bean удаляется из временного пула самим контейнером.
Вызов несколькими клиентами одного ssesion bean вызывает исключительную ситуацию, потому что session bean ассоциирован только с
одним клиентом. Если клиент или сервер прервали работу, то данные
session bean теряются.
210 Часть 4. Распределенные компненты EJB
Существуют две версии session bean по работе с пользовательской
сессией: stateless — «короткоживущие» и stateful — «долгоиграющие»
версии, данные в них обрабатываются различными session bean. Обычно
Session bean содержит параметры, которые характеризуют состояние
его взаимодействия с клиентом, т. е. он сохраняет некоторое состояние
между вызовами удаленных методов в процессе сеанса связи с клиентом. Session-EJB, которые поддерживают состояние, называются stateful. В таком состоянии session bean пребывает, пока существует сеанс
взаимодействия с клиентом, т. е. session bean создается в контексте сессии (или сеанса связи), и в продолжение всего сеанса экземпляр session
bean обслуживает запросы только одного клиента, создавшего непосредственно данный bean.
Session bean может также не иметь состояния stateless. Он не хранит
характеристик своего взаимодействия с клиентом. Когда клиент вызывает один из его методов, разумеется, происходит изменение значений
некоторых внутренних переменных, но эти значения имеют смысл только во время обработки этого единственного клиентского вызова — до его
окончания. Таким образом, все экземпляры одного stateless bean являются идентичными. Вследствие этого ничто не мешает одному и тому
же экземпляру session bean обслуживать вызовы различных клиентов.
Контейнер EJB может создать пул экземпляров таких bean и выбирать
любой из них для обслуживания клиентских запросов.
«Короткоживущая» версия не предполагает использование специфических данных, «долгоиграющая» наоборот, чаще всего она и используется. Находясь в состоянии stateless, она не управляет пользовательской сессией. Клиент может вызывать методы stateless session bean. Выбор конкретного типа session bean зависит от многих факторов:
•
типа клиента:
Web-клиент ( из Web-браузера вызывается servlet по HTTP-протоколу);
Java-приложение (доступ организуется посредством RMI/IIOP-протокола);
•
затребованных системных ресурсов:
доступности;
выполнения различных функций.
Stateless Session Beans более динамичны по сравнению с Stateful Session Beans используют значительно меньше системных ресурсов и легче
управляются.
Программно Entity и Session beans очень похожи между собой, но
первый содержит дополнительный класс — primary key, о котором будет сказано ниже.
31.6. Основные EJB Entity bean
Каждый entity bean должен иметь следующий EJB:
Bean class. Этот класс содержит данные для entity bean и бизнес-методы, описанные разработчиком для доступа к этим данным. Здесь также описываются методы, используемые контейнером для управления
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]