Главная » Java, JavaBeans » Архитектура Enterprise JavaBeans

0

Enterprise JavaBeans – это высокоуровневая, базирующаяся на использовании компонентов технология создания распределенных приложений, которая использует низкоуровневый API для управления транзакциями. EJB существенно упрощает разработку, поставку и настройку систем уровня предприятия, написанных на языке Java. Архитектура EJB определена в спецификации, разработанной Sun Microsystems. Реализации Контейнера EJB фирмой Inprise базируется на версии EJB 1.1.

Технология Enterprise JavaBeans определяет некоторый набор универсальных и предназначенных для многократного использования компонентов, которые называются enterprise beans (в русском переводе Руководства – Компоненты EJB). При создании распределенных системы ее бизнес-логика реализована на уровне этих Компонентов.

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

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

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

•          Обеспечение безопасности – Дескриптор Поставки (deployment descriptor) определяет права доступа клиентов к бизнес-методам Компонентов. Обеспечение защиты данных обеспечивается за счет предоставления доступа только для авторизованных клиентов и только к разрешенным методам.

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

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

•          Управление транзакциями – Все параметры, необходимые для управления транзакциями, помещаются в Дескриптор Поставки. Все вопросы по обеспечению управления распределенными транзакциями в гетерогенных средах и взаимодействия с несколькими базами данных берет на себя Контейнер EJB. Контейнер обеспечивает защиту данных и гарантирует успешное подтверждение внесенных изменений; в противном случае транзакция откатывается.

Компоненты Enterprise bean

Enterprise beans являются элементами распределенных транзакционных приложений уровня предприятия. Следующие характеристики являются общими для всех Компонентов EJB:

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

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

•          Контейнер создает экземпляры Компонентов и управляет ими во время работы приложения. Контейнер также управляет доступом клиентов к Компонентам.

•          Настройка Компонентов осуществляется на этапе их поставки путем изменения их свойств, определяющих поведение компонента в конкретной среде (environment properties).

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

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

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

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

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

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

Session-компонент может также не иметь состояния (stateless- компонент). Он не хранит характеристик своего взаимодействия с клиентом. Когда клиент вызывает один из его методов, разумеется, происходит изменение значений некоторых внутренних переменных, но эти значения имеют смысл только во время обработки этого

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

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

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

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

За сохранность компонента может отвечать сам Компонент (Bean Managed Persistence, BMP) или его Контейнер (Container Managed Persistence, CMP). При использовании CMP все обязанности по сохранению состояния Компонента возлагаются на Контейнер. В случае BMP, вы должны написать для Компонента нужный код, включая обращение к базам данных.

Каждый Entity-компонент характеризуется своим уникальным идентификатором – primary key. Обычно это тот же самый primary key, что и идентификатор данных в БД, например, совокупность ключевых полей записи в твблице. Primary key используется для поиска нужного компонента.

Роли EJB

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

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

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

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

EJB Container Provider: как правило, это эксперт в области технологий создания распределенных систем, управления транзакциями и обеспечения безопасности. Container Provider предоставляет средства для поставки Компонентов EJB и run-time среду для установленных экземпляров Компонентов.

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

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

Enterprise Bean Provider: обычно это специалист в некоторой прикладной области; например, эксперт в области финансов или телекоммуникаций. 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

По теме:

  • Комментарии