Методология построения корпоративных информационных систем на основе технологии EJB

Контейнер это контейнер. Он предоставляет среду, в которой могут функционировать Ваши компоненты EJB. Получается, у Вас есть контейнер, в который вы можете запихивать свои компоненты.
Каковы функции контейнера? Их много:
1. Разбор XML-описания компонента EJB (deployment descriptor) и поддержка конфигурации, описанной в этом XML-файле.
2. Управление жизненным циклом компонента EJB, т.е. для предоставления услуг компонента прописанных в его интерфейсе и зарегистрированном на JNDI, необходимо создавать, уничтожать и кэшировать реализации (объекты), которые будут отвечать на запросы клиентов.
3. Разбалансировка нагрузки между реализациями (объектами) обслуживающими компонент EJB и управление пулом таких объектов.
4. Управление транзакциями в компонентах EJB. В случае с компонентами, которые работают с СУБД, управление транзакциями сильно связано с механизмом синхронизации состояния компонентов с состоянием СУБД.
5. Управление безопасностью доступа к компонентам. Опционально эта функция может быть отключена и проверку прав доступа к методам Вашего компонента придется реализовывать своими руками в самом компоненте.
Контейнер изображен на рис. 5.

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

Компоненты EJB имеют, вольно выражаясь, два внешних описания (интерфейса). Через них, собственно, клиент и взаимодействует с Вашим компонентом.
Пример этого изображен на рис. 6

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

Remote-интерфейс позволяет взаимодействовать с экземплярами (объектами), которые были созданы через фабрику (Home-интерфейс). Через Remote-интерфейс пользователь вызывает бизнес-методы компонента, которые естественно Вам придется реализовывать, запихивая туда логику Вашего приложения.

Разберем стандартный сценарий взаимодействия клиента с компонентами EJB. Взаимодействие изображено на рис. 7

1: Клиент ищет Home-интерфейс нужного ему компонента по его имени через сервис имен JNDI (клиенту возвращается в результате поиска Home-интерфейс этого найденного компонента).
2: Клиент, через найденный Home-интерфейс, вызывает функцию создания экземпляра компонента на стороне сервера (клиенту возвращается Remote-интерфейс созданного экземпляра компонента).
2.1: Сервер создает этот экземпляр.
3: Клиент вызывает бизнес-метод на созданном компоненте через его Remote-интерфейс этого компонента.
3.1: Сервер вызывает бизнес-метод на конкретном экземпляре компонента.

На стороне клиента Remote-интерфейс и Home-интерфейс оформлены в виде классов, которые скрывают сетевые взаимодействия на основе RMI с сервером приложений. Клиент работает с объектами, думая, что они работают в том же адресном пространстве, что и само приложение, а на самом деле происходят сетевые вызовы и функционал объектов работает совсем на другой вычислительной машине.