Концепция EJB-компонентов

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

· компоненты, ориентированные на взаимодействие сервера и конкретного пользователя. Такая ориентированность означает, что компонент создается клиентом в начале сеанса работы с сервером и прекращает свое существование при завершении этого сеанса - отсюда и их название - session-компоненты. Поскольку session-компонент обслуживает только конкретного клиента, технология не предусматривает для него команды «поиска» - вполне достаточно команды «создания». Эти компоненты, в свою очередь, также можно разделить на две группы - компоненты с состоянием, которые отслеживают историю своих вызовов клиентом, и компоненты без состояния. Такие два подвида введены для оптимизации управления их циклом жизни, и их отличия не так уж важны для прикладного программиста. Заметим, что session-компоненты без состояния являются основой для создания COM+ -приложений.

· компоненты, являющиеся объектным представлением данных в БД - реляционных или объектных. Они называются Entity-компонентами. Создание entity-компонента связано с добавлением данных в базу данных, его уничтожение - с удалением, например, записи их таблицы реляционной базы данных. В принципе, интерфейс пользователя entity-компонентов может даже не содержать команды «создать» - компоненты создаются автоматически, например, в результате выполнения SQL-команды INSERT, зато обязательно должна присутствовать команда (или команды) «найти». Поскольку entity-компонент предназначен для доступа к информации, доступной многим клиентам, он не может содержать информацию, специфическую для одного клиента. Его состояние - просто кешированная копия информации из (записи) базы данных.

Обычно в EJB-приложении клиент «общается» с информацией в базе данных по цепочке «клиент - session-компонент - entity-компонент(ы)».

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