EJB-контейнер - это то место, где "живет'' EJB-компонент. EJB-контейнер реализует для
находящихся в нем компонент такие сервисы как транзакции (transaction), управление ресурсами, управление версиями компонент, их мобильностью, настраиваемостью, мобильностью, жизненным циклом. Так как EJB-контейнер реализует все эти функции, то разработчик EJB-компонент может не реализовывать их самостоятельно, а просто вызывать соответсвующие методы у контейнера (правила вызова методов у контейнера описываются в спецификации). Как правило, в одном EJB-контейнере живет несколько однотипных EJB-компонент.
EJB-объект. Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object). EJB-объект реализует "удаленный интерфейс'' EJB-компоненты на сервере. Суть в том, что находящаяся на сервере EJB-компонента, помимо бизнес-функций, ради которых она была разработана, должна реализовывать также некоторые функции, определяемые спецификацией, которые служат для "управления'' EJB-компонентой со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компоненты, являясь, в некотором смысле, "промежуточным'' звеном между клиентом и EJB-компонентой.
EJB-объекты и EJB-компоненты представляют собой разные классы, хотя "снаружи'' (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс (а именно, интерфейс, описанный для EJB-компоненты). Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно вызывает методы у EJB-компоненты.
Entity Bean. Жизненный цикл.
Entity-бины представляют собой бизнес-правила, оперирующие с перманентными (хранящиеся постоянно) данными в базе данных, причем к этим данным в условиях решаемой задачи должны иметь доступ многие пользователи. Каждому Entity-бину соответствует свой первичный ключ, по которому он может быть однозначно определен клиентом. Также Entity-бин имеет всегда какое-либо состояние (набор величин атрибутов, определяющих данный Entity-бин), которое может быть зафиксировано и сохранено, а затем и восстановлено.
Разделяют персистентность, управляемую контейнером (Container-managed persistence) и персистентность, управляемую самим бином (Bean-managed persistence). Отличие состоит в том, кто ответственен за сохранение состояния бина: в первом случае это контейнер EJB, во втором - сам бин. Первое более универсально и требует меньших затрат от разработчика EJB, второе требует написания отдельного кода в бине и используется, очевидно, когда первый способ по каким-либо причинам (скорость, необходимость специальной функциональности при сохранении состояния бина, etc.) разработчика не устраивает.
Жизненный цикл Entity-бина состоит из трех состояний:
А) Бин не существует;
б) Бин находится в "обобщенном" (pooled) режиме, куда сервер приложений по спецификации переводит набор бинов, задавая им метод setEntityContext(). Таким образом, в этом состоянии бин получил кое-какие признаки своего класса, но ещё не идентифицирован с определенным полем в СУБД;
в) Бин находится в "готовом" (ready) режиме, он идентифицирован с конкретными данными в базе данных.
Заметим, что Entity-бинам не страшны такие приятные неожиданности, как сбои в системе или виртуальной Java-машине (JVM). Такие ситуации приведут только к откатутекущей транзакции и не уничтожат сам бин, который восстановится позднее при включении системы и JVM,и тем более не изменят ссылку,по которой клиент обращается к бину через JNDI.
