Enterprise JavaBeans: реализация идей компонентной модели

Антон Тульчинский

antontul@rambler.ru

Технология EJB для построения распределенных систем – концепция, достоинства и недостатки, базовая структура.

Создание крупных распределенных приложений без использования мощной стандартизованной архитектуры и поддерживающего ее готового ПО сегодня не может быть эффективным – такой подход можно уподобить изобретению велосипеда. И разработка, и отладка в таких проектах требует слишком много сил и времени, что не позволяет реализовать формулу успеха компании, разрабатывающей ПО: заданные сроки + качество + стоимость. К счастью, существуют удачные модели, предоставляющие разработчику как программную платформу, так и готовые компоненты, с помощью которых можно уменьшить сроки и затраты и обеспечить нужное качество разработки. Одна из таких моделей – Enterprise JavaBeans (EJB).

Технология EJB представляет собой один из подходов к построению распределенных систем. Многие крупные компании поддерживают эту модель и выпускают продукты, соответствующие спецификации EJB. Важно отметить, что с помощью этой технологии разработчику достаточно программировать только бизнес-логику приложения и можно не заниматься стандартными вещами, такими, как обработка транзакций. Данная архитектура предполагает, что подобные стандартные функции – проблема производителя сервера.

Enterprise JavaBeans – не единственная и не первая архитектура для построения серверных приложений. К ее конкурентам можно отнести RMI (remote method invocation – вызов удаленных методов), CORBA (common object request broker architecture – обобщенная архитектура брокера объектных запросов), DCOM (distributed component object model – распределенная модель компонентных объектов) и некоторые другие. Надо сказать, что многие принципы CORBA были сознательно положены в основу EJB. Более того, существует стандарт отображения EJB на CORBA, касающийся службы имен и управления транзакциями и безопасностью. Тем не менее между EJB и CORBA остаются фундаментальные различия.

Модель DCOM представляет собой стандарт де-факто. Что же обеспечило ей такую значимость? Ответ – влиятельность Microsoft. Модель DCOM лежит в основе всех разработок корпорации, хотя в последнее время фокус переносится на технологии.NET.

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

EJB – достоинства и недостатки

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

Поговорим вначале о достоинствах. Как уже было сказано, EJB предполагает, что некоторые типичные блоки кода реализовываются поставщиками серверов, в то время как разработчик EJB-системы сосредотачивается на бизнес-логике. Что же делают эти типичные блоки кода?

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

Во-вторых, EJB легко интегрируется с CORBA; как было сказано выше, эти две технологии дополняют друг друга. Как компоненты EJB могут взаимодействовать с CORBA, так и клиенты CORBA могут обращаться к компонентам EJB.

В-третьих, EJB позволяет производителю сервера/контейнера делать изменения в части этого ПО, никак не влияя на работу имеющихся у пользователя приложений.

Наконец, EJB обеспечивает переносимость, предоставляя универсальные компоненты. В основу EJB положена технология Java, следовательно, разработчик и пользователь могут быть уверены в том, что написанные однажды компоненты будут работать везде. Компоненты EJB, подчиняющиеся требованиям EJB API, устанавливаются и выполняются на любом сервере EJB.

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

На наш взгляд, недостатки данной технологии в основном связаны с ее спецификацией. Прежде всего она велика по объему и довольно сложна. Правда, следует признать, что любая распределенная система требует объемной спецификации – это относится и к CORBA, и к .NET. Тем не менее хотелось бы, чтобы спецификация предоставляла несколько вариантов прочтения в зависимости от предъявляемых запросов. Кроме того, эта спецификация постоянно изменяется. Поскольку EJB развивается быстро, возможны случаи, когда написанный еще недавно код устаревает из-за различия в версиях спецификаций. Чаще всего преемственность все же обеспечивается, однако написанный ранее EJB-код приходится пересматривать на соответствие с последней версией спецификации.

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

Компонентная модель

Теперь мы немного отвлечемся от технологии EJB и скажем несколько слов о концепции компонентной модели. Эта концепция предполагает использование программных компонентов – строительных блоков, имеющих стандартный интерфейс для их взаимной стыковки. Другими словами, при работе с такой моделью главное – строго придерживаться стандартов, описывающих внешний вид компонентов.

Компонентные объектные среды – это наиболее современный и естественный фундамент для накопления и использования программистских знаний. Такие среды обладают всеми достоинствами, присущими объектно-ориентированному подходу. Так, поддержка инкапсуляции в объектных компонентах скрывает сложность реализации функций, делая видимым только предоставляемый вовне интерфейс. Механизм наследования позволяет развивать созданные ранее компоненты, не нарушая целостности объектной оболочки, а полиморфизм позволяет использовать одно имя для работы с объектами (экземплярами компонентов) различных классов, т. е. по сути дает возможность группировать объекты, характеристики которых с определенной точки зрения можно считать сходными.

Жизненный цикл EJB

Проблема многих моделей заключается в том, что они определяют некоторые соглашения, ограничения и т. п. – и оставляют разработчика один на один со всем остальным. Спецификация EJB построена не так: в ней четко определены роли, ответственности, а также жизненный цикл компонентов в системе.

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

Рис. 1. Жизненный цикл EJB.

Что должен делать каждый из участников жизненного цикла EJB? Непосредственно разработчиков компонентов EJB касаются роли, обозначенные цифрами 3, 4 и 5. А роли 1 и 2 соответствуют поставщикам, или провайдерам серверов.

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

Разработчик EJB отвечает за кодирование бизнес-логики в серверных компонентах. Он реализует классы EJB, используя "стандартные" классы и интерфейсы, определенные спецификацией EJB.

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

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

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

Базовая модель EJB

Чтобы понять, как использовать модель EJB для построения распределенных приложений, следует изучить в общих чертах ее базовую структуру – это поможет разобраться в составных частях модели, а также во взаимодействиях между ними. Желательно разобраться в этом до создания собственных компонентов – в противном случае проект может окончиться неудачей или же вы будете изобретать велосипед.

Базовая структура EJB (рис. 2) состоит из пяти частей:

• серверы EJB;
• контейнеры EJB, которые работают внутри сервера;
• объекты типа home, remote, EJBObjects и EJB, которые работают в контейнерах;
• клиенты EJB;
• вспомогательные системы, например, JNDI, JTS, системы безопасности и т. д.

Рис. 2. Базовая структура EJB.

Сервер EJB обеспечивает среду для выполнения – в ней могут работать контейнеры EJB. Сервер делает EJB-контейнеры видимыми для внешнего мира. Он дополнительно может предоставлять функции, зависящие от поставщика, скажем, интерфейс оптимального доступа к данным, SSL-поддержку, JNDI-доступную службу имен и службу управления транзакциями.

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

Клиент EJB никогда не имеет прямого доступа к "бину" (bean в аббревиатуре EJB – "боб", или компонент). Любой доступ к bean выполняется посредством методов контейнерно-генерируемых классов, которые в свою очередь вызывают методы этого компонента.

Методы для нахождения, создания и удаления экземпляров классов EJB определяются в home-интерфейсе, реализацией которого выступает home-объект. Разработчик EJB сначала должен определить home-интерфейс для своего bean-компонента. Производитель контейнера EJB предоставляет средства, которые автоматически генерируют код-реализацию для home-интерфейса, определенного разработчиком EJB.

Remote-интерфейс перечисляет бизнес-методы, доступные для EJB. EJBObject – это клиентское представление объекта EJB, реализующее remote-интерфейс. В то время как разработчик EJB определяет remote-интерфейс, производитель контейнера предоставляет средства, позволяющие сгенерировать код для соответствующего объекта EJBObject.

Настоящий объект EJB содержится в контейнере EJB и никогда не должен быть напрямую доступен никому, кроме контейнера. Хотя прямой доступ в принципе возможен, применять его не рекомендуется, так как это разрывает связь ("контракт") между bean и контейнером. Контейнер EJB должен служить связующим звеном между всеми обращениями к EJB. По этой причине разработчик EJB не реализует remote-интерфейс в самом EJB.

Клиенты EJB находят определенный контейнер EJB, который содержит объект EJB, через протокол JNDI (Java Naming and Directory Interface, Java-интерфейс именования и каталогов). Затем они используют контейнер EJB для вызовов методов bean-компонента. Клиент EJB получает ссылку только на экземпляр EJBObject – он никогда в действительности не получает ссылку на текущий экземпляр собственно EJB. Когда клиент вызывает метод, экземпляр EJBObject принимает запрос и перенаправляет его соответствующему экземпляру bean, предоставляя всю необходимую дополнительную функциональность. Клиент использует home-объект для нахождения, создания или разрушения экземпляров EJB. Затем он использует экземпляр EJBObject для вызова бизнес-методов экземпляра bean.

Enterprise beans

Понятно, что одно из основных понятий в Enterprise JavaBeans – компонент EJB, который по сути представляет собой отрезок кода, имеющий поля и методы для реализации каждого модуля бизнес-логики. Они могут быть постоянными или непостоянными. Мы можем говорить о наличии в модели двух видов компонентов: Entity – компоненты, предназначенные для моделирования бизнес-объектов, и Session – компоненты общего назначения для работы на серверной стороне.

После того как мы разберем эти два понятия, можно будет считать, что ядро технологии EJB мы освоили, – тогда можно будет принимать обоснованное решение относительно использования данной технологии.

Entity beans

Компонент Еntity представляет собой данные, хранящиеся в структуре домена, а также методы для обработки этих данных. В контексте реляционных баз данных для каждой строки таблицы существует свой отдельный bean. Эта концепция не нова, так построены все объектные базы данных. Каждый entity bean определяется своим первичным ключом. Entity bean можно создать с помощью построителя объектов – метода create.

Для Entity всегда характерно какое-либо состояние, которое может быть зафиксировано и сохранено (функция персистентности). При этом одним entity bean могут пользоваться сразу несколько клиентов EJB, срок действия его ничем не ограничен. Сбой виртуальной машины может только стать сигналом начала процедуры возврата текущей транзакции в исходное состояние, но не сможет ни уничтожить сам bean, ни изменить ссылку, по которой к нему обращаются клиенты. Более того, клиент сможет обратиться к bean позднее, пользуясь той же ссылкой, так как она содержит уникальный для bean первичный ключ, позволяющий enterprise bean или его контейнеру перезагружать его состояние. Таким образом, entity-компонентам не страшны системные сбои или отключения.

Персистентность Entity может быть двух видов. В первом случае она управляется контейнером (за сохранение состояния entity bean отвечает контейнер EJB), во втором – самим этим компонентом, который отвечает за сохранность своего состояния (контейнеру при этом не нужно генерировать никакие обращения к базе данных).

Итак, entity bean представляет данные в структуре домена и существует до тех пор, пока существуют данные в структуре этого домена. Entity bean не подвергается влиянию системных сбоев, клиент не теряет данные в результате сбоя или отключения сервера EJB.

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

Session beans

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

Каждый session bean обычно связан с одним клиентом EJB, отвечающим за его создание и удаление. Таким образом, session-компоненты "смертны" и не могут пережить виртуальную машину, в которой они создаются.

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

Характеристики session bean можно сформулировать следующим образом:

• не представляют данных, которые должны сохраняться в базе данных;
• работают от лица отдельных клиентов, экземпляр такого бина является расширением клиента, который его создает;
• могут хранить информацию о транзакциях;
• могут обновлять данные в соответствующей базе данных.
• относительно недолговечны, жизненный цикл не имеющего состояния bean ограничен циклом его клиента;
• могут погибать в результате сбоев сервера EJB – чтобы продолжить вычисления, клиент должен устанавливать связь с новым объектом session bean.

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

Средства защиты EJB

Модель Enterprise JavaBeans использует сервисы средств защиты на Java, предусмотренные в Java Development Kit. Средства защиты Java-платформы поддерживают сервисы аутентификации и авторизации, ограничивающие доступ к защищенным объектам и методам.

Кроме того, технология EJB автоматизирует процесс использования средств защиты Java-платформы. Правила защиты для каждого bean определены декларативно в пакете объектов AccessControlEntry в объекте deployment descriptor.

Транзакции

Технология EJB требует распределенной системы управления транзакциями, которая поддерживает протоколы двухфазовой фиксации распределенных транзакций. Спецификация Enterprise JavaBeans предусматривает, но не требует осуществления транзакций, основанных на интерфейсе Java Transaction Service (JTS) API.

JTS представляет собой Java-технологию, связанную с механизмом CORBA Object Transaction Service (OTS). Эта технология поддерживает распределенные транзакции, которые могут охватывать множество баз данных на многочисленных системах, координируемых многочисленными менеджерами транзакций. При использовании JTS сервер Enterprise JavaBeans гарантирует, что его транзакции способны охватить многие серверы Enterprise JavaBeans.

Хотя разграничение транзакций в централизованном приложении – это довольно простой процесс, он усложняется, когда приложение состоит из переменного числа автономных компонентов приложений, ссылающихся друг на друга. Технология Enterprise JavaBeans значительно упрощает процесс разработки приложений, автоматизируя использование распределенных транзакций. Все функции транзакций могут выполняться непосредственно EJB-контейнером и EJB-сервером. Отдельным beans не обязательно создавать операторы разграничения транзакций, включая их в код. И поскольку код транзакций требуется для логики приложений, beans проще писать и переносить посредством различных менеджеров транзакций.

Заключение

Итак, мы "пробежались по верхам" архитектуры Enterprise JavaBeans. Даже невооруженным взглядом видно, что она тщательно продумана, весьма разумно устроена и предоставляет разработчикам распределенных систем множество удобств. Эта технология не лишена недостатков, главные из которых – относительная сложность самой спецификации технологии и тот факт, что она (спецификация) постоянно изменяется. Тем не менее на сегодняшний день Enterprise JavaBeans можно считать хорошим (в некоторых случаях наилучшим) выбором для компаний, заинтересованных в быстром создании качественных, масштабируемых серверов приложений, функционирующих под управлением различных операционных систем.

Данная статья не претендует на полноту изложения модели EJB – для этого есть спецификации, которые можно найти на серверах Sun. Автор только хотел дать пищу для размышления…