Enterprise JavaBeans

    Enterprise JavaBeans – спецификация, созданная отделением JavaSoft корпорации Sun Microsystems, определяет интерфейс прикладного программирования (API), который призван упростить разработку, развертывание и управление многозвенными, кроссплатформенными распределенными объектными приложениями.  Первый вариант спецификации Enterprise JavaBeans появился в марте 1998, в настоящий момент актуальна версия 3.0 – технология прошла за это время большой путь и продолжает развиваться. Используя Enterprise JavaBeans API, разработчики могут сконцентрироваться на написании бизнес – логики для серверов среднего звена и уделять меньше времени кодированию и тестированию в аспектах инфраструктуры распределенного приложения. Так как каждый компонент Enterprise JavaBeans инкапсулирует важную бизнес–функцию, разработчику не обязательно знать, как писать специализированные программы системного уровня, которые регулируют функции типа безопасности и управления путем многочисленных транзакций – обычно трудоемкие и сложные задачи.

    Технология Enterprise JavaBeans определяет некоторый набор универсальных и предназначенных для многократного использования компонентов, которые называются Enterprise beans (далее – компоненты EJB). Сам Enterprise Bean является Java классом. Он реализует интерфейс Enterprise Bean и обеспечивает реализацию бизнес – методов, которые выполняет компонент. Класс не реализует никакую авторизацию, многопоточность или код транзакции.

    При создании распределенной системы ее бизнес – логика будет реализована в этих компонентах. Каждый компонент EJB состоит из удаленного интерфейса, собственного интерфейса и реализации EJB – компонента. Удаленный интерфейс (remote – интерфейс) определяет бизнес –методы, которые может вызывать клиент EJB. Собственный (домашний) интерфейс (home–интерфейс) предоставляет методы create для создания новых экземпляров компонентов EJB, методы поиска (finder) для нахождения экземпляров компонентов EJB и методы remove для удаления экземпляров EJB. Реализация EJB – компонента определяет бизнес – методы, объявленные в удаленном интерфейсе, и методы создания, удаления и поиска собственного интерфейса.

    После завершения их кодирования, наборы компонентов EJB помещаются в специальные файлы (архивы, jar) – модуль развертывания, по одному или более компонентов, вместе со специальными параметрами поставки (deployment). Затем они устанавливаются в специальной операционной среде, в которой запускается контейнер EJB. Контейнер EJB предоставляет окружение выполнения и средства управления жизненным циклом EJB – компонентам. Клиент осуществляет поиск компонентов в контейнере с помощью home – интерфейса соответствующего компонента. После того, как компонент создан и/или найден, клиент выполняет обращения к его методам с помощью remote –интерфейса. 

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

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

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

• обеспечение безопасности – дескриптор поставки (deployment descriptor)определяет права доступа клиентов к бизнес – методам компонентов. Обеспечение защиты данных – обеспечивается за счет предоставления доступа только для авторизованных клиентов и только к разрешенным методам;
• обеспечение удаленных вызовов – контейнер берет на себя все низкоуровневые вопросы обеспечения взаимодействия и организации удаленных вызовов, полностью скрывая все детали, как от разработчика компонентов, так и от клиентов, которые пишут код точно так же, как если бы система работала в локальной конфигурации, т.е. вообще без использования удаленных вызовов;
• управление циклом жизни – клиент создает и уничтожает экземпляры компонентов, однако, контейнер для оптимизации ресурсов и повышения производительности системы может самостоятельно выполнять различные действия, например, активизацию и деактивацию этих компонентов, создание их пулов и т.д.;
• управление транзакциями – все параметры, необходимые для управления транзакциями, помещаются в дескриптор поставки. Все вопросы по обеспечению управления распределенными транзакциями в гетерогенных средах и взаимодействия с несколькими базами данных берет на себя контейнер EJB. Контейнер обеспечивает защиту данных и гарантирует успешное подтверждение внесенных изменений; в противном случае транзакция откатывается.

Существуют  два типа компонентов EJB: Session и Entity – компоненты.

Session – компоненты

    Session– компонент представляет собой объект, созданный для обслуживания запросов одного клиента. В ответ на удаленный запрос клиента, контейнер создает экземпляр такого компонента. Session–компонент всегда сопоставлен с одним клиентом и его можно рассматривать, как «представителя» клиента на стороне EJB–сервера. Такие компоненты могут «знать» о наличии транзакций – они могут отвечать за изменение информации в базах данных, но сами они непосредственно не связаны с представлением данных в БД.

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

компонент.

Entity – компоненты 

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

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

Рис. Session Beans и Entity Beans. 

Роли EJB

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

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

Роли  обеспечения инфраструктуры

    Server Provider создает платформу для разработки распределенного приложения и среду для его выполнения (EJB сервер).

    Container Provider предоставляет средства для поставки компонентов EJB и среду выполнения для установленных экземпляров компонентов (EJB контейнер).

Роли  разработки приложений

    Bean Provider собственно разрабатывает компоненты – определяет remote и home – интерфейсы компонента, реализует его бизнес – методы, а также создает дескриптор поставки (Deployment Descriptor) компонента. При разработке он не заботится о таких вещах, как обеспечение удаленного взаимодействия, управление транзакциями и безопасностью и прочими не имеющими к бизнес – логике конкретного компонента аспектами, так как эти проблемы должен решать Container Provider.

    Application Assembler – это эксперт в прикладной области, который выполняет сборку приложения из готовых блоков (компонентов EJB) и добавляет некоторые другие элементы, например, апплеты или сервлеты для создания готового приложения. В процессе своей работы он имеет дело с интерфейсами компонентов EJB (а не с кодом его бизнесм – методов), а

также с дескриптором поставки. Результатом  его работы может быть как готовое приложение, так и более сложный составной компонент EJB. 

Роли  поставки и настройки

    Задача  Deployer – настроить приложение, собранное из компонентов EJB для его выполнения к конкретной операционной среде. Достигается это путем изменения свойств компонента. Например, deployer определяет поведение транзакций или профили безопасности путем установки тех или иных значений для свойств, находящихся в дескрипторе поставки. Его задачей также является интеграция приложения с существующими программными средствами управления корпоративной системой.

    System Administrator работает с уже установленным приложением. Его задача – задание конфигурации и администрирование информационной инфраструктуры EJB – сервера и контейнеров. Administrator отслеживает поведение системы, определяя ее узкие места. Обычно при этом используются корпоративные средства контроля, с которыми (посредством специальных средств на уровне контейнера) интегрировано конкретное приложение.

    В соответствие с такой схемой, традиционный прикладной программист – это, как правило, bean provider и, возможно, application assembler. Эти роли позволяют такому разработчику сфокусировать свое внимание на разработке и реализации бизнес – логики системы. Deployer определяет значения параметров поставки в процессе установки компонента. Сложные вопросы реализации требований поставки берет на себя специально подготовленный поставщик программных средств. Хотя процесс создания распределенных приложений остается достаточно сложным, существенно облегчается работа обычного прикладного программиста – за счет делегирования многих вопросов разработчикам EJB – серверов и контейнеров.

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

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

    Использованные  материалы:

1. Лекции учебного курса «Методы и средства построения распределенных программных систем с использованием технологии Java» – Кафедра МО ЭВМ. Нижегородский государственный университет им Н.И. Лобачевского
2. www.sun.ru
3. www.bytemag.ru