Архитектурная методика EJB

Оставшаяся часть главы посвящена архитектуре корпоративных JavaBeans (Enter­prise JavaBeans, EJB), которая определяет стандартную модель программирова­ния, направленную на построение распределенных объектно-ориентированных серверных Java-приложений. В силу стандартного статуса этой модели существует (и эксплуатируется) возможность написания beans с заранее «пакетированной» полезной функциональностью. Задача программиста EJB, таким образом, заклю­чается в том, чтобы связать эти пакеты с прикладной функциональностью и тем самым сформировать законченное приложение.

Подобно J2EE, архитектура EJB ориентирована на реализацию одного из ос­новных принципов проектирования на Java — пресловутого девиза «пишется од­нажды, исполняется везде». JVM позволяет запускать Java-приложение на лю­бой операционной системе. Впрочем, серверные компоненты выставляют ряд требований по дополнительному обслуживанию (например, по предоставлению служб транзакций и безопасности), предоставить которые непосредственно JVM не в состоянии. Как в J2EE, так и в EJB эти службы предоставляются посред­ством набора стандартных, независимых от конкретного производителя интер­фейсов, обеспечивающих доступ к вспомогательной инфраструктуре, — совмест­ными усилиями они организуют обслуживание, предусматриваемое любым сер­вером приложений.

В каждом J2EE-c0BMecTHM0M сервере приложений предусматривается EJB- контейнер (EJB container), координирующий исполнение компонентов прило­жения. Выражаясь более приземленно, контейнер предоставляет процесс опера­ционной системы, в котором размещается один или (в большинстве случаев) несколько EJB-компонентов.

На рис. 16.3 изображено отношение между сервером приложений, контейне­ром и предоставляемыми службами. Вкратце, сразу после запуска клиентом сер­верного компонента контейнер автоматически назначает ему поток и запускает экземпляр вызванного компонента. От имени компонента контейнер управляет всеми ресурсами, а также взаимодействием компонента и внешних систем.

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

Рис. 16.3. Пример представления размещения архитектуры EJB

В спецификации EJB версии 1.1 выделяют два типа компонентов: сеансовые beans (session beans) и beans-сущиости (entity beans).

♦ Сеансовые beans обычно содержат бизнес-логику и обслуживают клиентов.

Сеансовый bean делится на два подтипа: без состояния (stateless) и с запо­минанием состояния (stateful).

· Сеансовый bean без состояния (stateless session bean) не вступает в диа­лог с вызывающим процессом. Таким образом, информация о состоя­нии от имени клиентов не сохраняется. Клиент, получающий ссылку на сеансовый bean без состояния в контейнере, неоднократно вызывает через него экземпляр bean. В период между последовательными вызовами службы никаких гарантий относительно связывания любого конкретно­го экземпляра сеансового bean без состояния клиенту не предоставляет­ся. EJB-контейнер делегирует клиентские вызовы сеансовым beans без состояния лишь по мере необходимости; таким образом, у клиента нет сведений о том, с каким bean ему придется общаться. Отсюда следует, что хранить клиентское состояние в сеансовом bean без состояния бес­смысленно.

· Сеансовый bean с запоминанием состояния должен вступать в диалог с вызывающим процессом и сохранять информацию о состоянии этого диалога. С того момента как клиент получает ссылку на сеансовый bean с запоминанием состояния, все последующие вызовы по этой ссылке проходят через один и тот же экземпляр bean. Для каждого клиента, создающего экземпляр bean, контейнер формирует новый, специализи­рованный сеансовый bean с запоминанием состояния. Следовательно, в таком bean клиенты вольны сохранять любую информацию о состоя- пип, которая гарантированно сохраняется в нем до следующего обраще­ния. Обязанность по управлению жизненным циклом сеансовых beans с запоминанием состояния берут на себя EJB-контейнеры. Если состояние bean в течение определенного периода времени остается без употребле­ния, EJB-контейнер записывает его состояние на диск, а при последу­ющем клиентском вызове bean осуществляет автоматическое восстанов­ление. Этот механизм называется пассивацией/активацией (passivation and actication) bean с запоминанием состояния. Пассивацию мы чуть позже разберем более подробно.

♦ Beans-сущности, как правило, представляют бизнес-объекты данных. Чле­ны данных bean-сущности напрямую отображаются на отдельные элемен­ты данных, хранящиеся в связанной базе данных. Обращаются к beans- сущностям чаще всего сеансовые beans, предоставляющие клиентские службы бизнес-уровня. Beans-сущности подразделяются на два типа: с кон­тейнерным управлением устойчивостью (container-managed persistence) и с самоуправлением устойчивостью (bean-managed persistence). Устойчи­вость в данном контексте означает способ записи и считывания данных bean (как правило, они хранятся в строках таблиц реляционных баз данных).

♦ Beans-сущности с контейнерным управлением устойчивостью предпо­лагают автоматическое отображение данных, представляемых bean, на связанное постоянное хранилище данных (например, на базу данных), осуществляемое средствами контейнера. Контейнер ответствен за загруз­ку данных в экземпляр bean и последующую (происходящую в опреде­ленные моменты — например, в начале и в конце транзакции) запись изменений в постоянное хранилище данных. Устойчивость с контейнер­ным управлением базируется на службах контейнера и не требует при­кладного кода — благодаря тому, что контейнер генерирует код доступа к данным, реализация упрощается.

♦ Beans-сущности с самоуправлением устойчивостью предполагают ответ­ственность bean за обращения к представляемым постоянным данным, которые обычно осуществляются посредством ручных вызовов по JDBC. Устойчивость под управлением beans предоставляет разработчику до­полнительную гибкость, необходимую для выполнения слишком слож­ных для контейнера операций, а также для обращения к не поддержива­емым контейнером источникам данных — в частности, к специальным или унаследованным базам данных. Реализация устойчивости под уп­равлением beans требует от программиста более серьезных усилий, од­нако в определенных ситуациях труды компенсируются возможностью дополнительной оптимизации доступа к данным, а значит, и более высо­кой (по сравнению с устойчивостью с контейнерным управлением) про­изводительностью.

В табл. 16.4 расписывается реализация архитектурой EJB основных требова­ний по атрибутам качества, предъявляемых Sun к архитектуре J2EE в целом. Пример представления размещения архитектуры J2EE/EJB приводится на рис. 1G.4.

Таблица 16.4.Реализация в EJB требований по атрибутам качества, предъявляемых компанией Sun к J2EE

Рис. 16.4. Пример J2ЕЕ/EJВ – совместимой реализации

Дата добавления: 2015-04-25