Что такое ejb java
Перейти к содержимому

Что такое ejb java

  • автор:

Что такое ejb java

Основная идея, лежавшая в разработке технологии Enterprise JavaBeans — создать такую инфраструктуру для компонент, чтобы они могли бы легко «вставляться» («plug in») и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера. Технология Enterprise JavaBeans похожа на технологию JavaBeans в том смысле, что она использует ту же самую идею (а именно, создание новой компоненты из уже существующих, готовых и настраиваемых компонент, аналогиично RAD-системам), но во всем остальном Enterprise JavaBeans — совершенно иная технология.

Отличие от JavaBeans

Технология Enterprise JavaBeans описывается не спецификацией JavaBeans Component Specification, а совсем другим документом — Enterprise JavaBeans Specification. Если JavaBeans имеют дело лишь с клиентскими компонентами (как правило, это GUI-компоненты, или компоненты, с ними связанные), то EJB описывает каким образом внутри EJB-системы взаимодействуют между собой клиенты и серверы, как EJB-системы взаимодействуют с другими системами и какова роль различных компонент этой системы.

Цели, лежащие в основе технологии EJB

  • облегчить разработчикам создание приложений, избавив их от необходимости реализовывать с нуля такие сервисы, как транзакции (transactions), нити (threads), загрузка (load balancing) и другие. Разработчики могут сконцентрироваться на описании логики своих приложений, оставляя заботы о хранении, передаче и безопасности данных на EJB-систему. При этом все равно имеется возможность самому контролировать и описывать порученные системе процессы.
  • описать основные структуры EJB-системы, описав при этом интерфейсы взаимодйествия (contracts) между ее компонентами.
  • EJB преследует цель стать стандартом для разработки клиент/сервер приложений на Java. Таким же образом, как исходные JavaBeans (Delphi, или другие) компоненты от различных производителей можно было составлять вместе с помощью соответствующих RAD-систем, получая в результате работоспособные клиенты, таким же образом серверные компоненты EJB от различных производителей также могут быть использованы вместе. EJB-компоненты, будучи Java-классами, должны без сомнения работать на любом EJB-совместимом сервере даже без перекомпиляции, что практически нереально для других систем.
  • EJB совместима с Java API, может взаимодействовать с другими (не обязательно Java) приложениями, а также совместима с CORBA.
Основы технологии EJB

Для того чтобы понять, как работает и как устроена EJB-система, сначала необходимо рассмотреть ее основные части: EJB-компоненту (component), EJB-контейнер (container) и EJB-объект (object).

EJB-компонента (The Enterprise JavaBeans component)

Отдельная EJB-компонента представляет цобой компоненту в том же смысле что и традиоционный JavaBeans «bean» («зерно»). Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Любой сервер, который в состоянии поддерживать EJB-контейнеры и предоставлять им необходимые сервисы, может быть EJB-сервером (то есть многие из существующих серверов могут быть просто расширены до поддержки Enterprise JavaBeans).

EJB-компонента представляет из себя Java-класс, который реализует некоторую бизнес-логику. Все остальные классы в EJB-системе либо реализуют поддержку клиент/сервер взаимодйествий между компонентами, либо реализуют некоторые сервисы для компонент.

EJB-контейнер (The Enterprise JavaBeans container)

EJB-контейнер — это то место, где «живет» EJB-компонент. EJB-контейнер реализует для находящихся в нем компонент такие сервисы как транзакции (transaction), управление ресурсами, управление версиями компонент, их мобильностью, настраиваемостью, мобильностью, жизненным циклом. Так как EJB-контейнер реализует все эти функции, то разработчик EJB-компонент может не реализовывать их самостоятельно, а просто вызывать соответсвующие методы у контейнера (правила вызова методов у контейнера описываются в спецификации). Как правило, в одном EJB-контейнере живет несколько однотипных EJB-компонент.

EJB-объект (EJB-object) и удаленный интерфейс (remote interface)

Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object). EJB-объект реализует «удаленный интерфейс» EJB-компоненты на сервере. Суть в том, что находящаяся на сервере EJB-компонента, помимо бизнес-функций, ради которых она была разработана, должна реализовывать также некоторые функции, определяемые спецификацией, которые служат для «управления» EJB-компонентой со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компоненты, являясь, в некотором смысле, «промежуточным» звеном между клиентом и EJB-компонентой.

EJB-объекты и EJB-компоненты представляют собой разные классы, хотя «снаружи» (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс (а именно, интерфейс, описанный для EJB-компоненты). Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно вызывает методы у EJB-компоненты.

В качестве поясняющего примера рассмотрим видеомагнитофон. Предположим, что он является EJB-компонентой. EJB-объект, в таком случае, является аналогом пульта управления (remote control) этого магнитофона. У пульта управления есть все те же кнопки, что и на передней панели видеомагнитофона. Нажатие кнопки на пульте управления приведет к такому же эффекту, что и нажатие кнопки, расположенной на самом магнитофоне, но в результате только магнитофон, а не пульт управления, начнет выполнять функции.

Как работает система

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

Session и Entity beans

Существует два различных типа «бинов»: session и entity. Рассмотрим их более подробно.

Session bean

Session bean представляет собой EJB-компоненту, связанную с одним клиентом. «Бины» этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять «бин», который живет в веб-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает вэб-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с «вечными объектами», а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.

Entity bean

Entity bean, наоборот, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, «выживая», тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить «бин» из базы данных).

Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его атрибутами и связями.

Клиент создает на EJB-сервере объекты и работает с ними так же, как если бы это были локальные объекты. Это до предела упрощает разработку клиентов — практически нет разницы между написанием клиента для локальной машины и для клиента EJB-сервера. Разработчик может легко создавать, использовать и уничтожать объекты, а эти объекты, в свою очередь, выполняются на сервере. Итак, session beans в большинстве своем работают с информацией, относящейся к «диалогу» между клиентом и сервером, в то время как entity beans представляют собой экземпляры данных и работают с «постоянными» данными из баз данных.

Каждый экземпляр «бина» имеет свой уникальный идентификатор. Для entity объектов уникальный идентификатор, как правило, совпадает с (или каким-либо образом получается из) уникального идентификатора данных, которые он представляет. То есть в данном случае существует нечто вроде первичного ключа для всех entity beans. Идентификатор же session beans может быть практически любым — например он может состоять из имени сервера и порта удаленного соединения, а может создаваться случайным образом.

Создание серверных объектов

Итак, приложение-клиент соединяется с EJB-сервером и посылает ему запрос на создание «бина» (Enterprise JavaBean) для обработки своих запросов. Сервер отвечает на такой запрос созданием объекта на стороне сервера (экземпляр EJB-компоненты) и возвращает клиенту прокси-объект (EJB-объект), чей итерфейс совпадает с интерфейсом созданной EJB-компоненты и чьи методы перенаправляют вызовы собственно экземпляру компоненты. После этого приложение-клиент работает с EJB-объектом как с локальным объектом, даже и не подозревая, что всю работу выполняет не EJB-объект, а удаленная компонента на сервере. Необходимо заметить, что созданием и удалением EJB-компонент на сервере занимается EJB-контейнер.

Home interface

У каждой EJB-компоненты есть то, что называют «родной интерфейс» (home interface), который опеределяет методы создания, инициализации, удаления и (в случае entity beans) поиска экземпляров EJB-компонент на стороне сервера. «Родной интерфейс», по сути, описывает возможные взаимодействия между компонентой и контейнером, а конкретно — описанные выше.

«Родной интерфейс» для EJB-компоненты наследуется от интерфейса javax.ejb.EJBHome, который представляет базовую функциональность для взаимодйествия между контейнером и компонентой. Все методы этого интерфейса должны быть RMI-совместимы. Интерфейс также описывает один или более create() методов, которые все называются ключевым словом create, но тело которых различно. Все create методы возвращают объект с «внешним» (remote) для данной компоненты интерфейсом.

Когда приложение-клиент хочет создать «бин» на сервере, оно вначале использует Java naming and Directory Interface (JNDI) для нахождения объекта с искомым интерфейсом. JNDI представляет собой стандартное расширение Java-пакета и предоставляет глобальный сервис для любого Java-окружения, позволяя Java-программам находить и использовать существующие ресурсы просто по имени, а также позволяя просто извлекать информацию о ресурсах. Использование EJB сервисов, аналогичных JNDI, еще раз подчеркивает тот факт, что цель EJB-систем — полная совместимость с Java API.

Когда клиент получил ссылку на объект с «родным» интерфейсом, он вызывет у этого объекта любой из методов create для создания экземпляра компоненты на сервере. При получении вызова create локальный (находящийся у клиента) объект с «родным» интерфейсом удаленно вызывает метод у EJB-контейнера, который и создает экземпляр «бина», возвращая клиенту EJB-объект. После этого приложение-клиент вызывает у EJB-объекта методы, исполнение которых перенаправляется на сервер (сначала контейнеру, а потом уже компоненте). Контейнер, при получении вызова к компоненте, просто вызывает у нее соответствующий метод. Единственное, за что ответственен при этом контейнер — обработка некоторых ошибок (таких, например, как отсутствие искомого экземпляра класса) и соответственное возбуждение исключительных ситуаций.

Entity «бины», помимо упоминавшихся, имеют дополнительный интерфейс finder, который используется для поиска по уникальному ключу экземпляра «бина».

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

Литература
  1. Mark Johnson, A beginner’s guide to Enterprise JavaBeans, JavaWorld, October 1998.
  2. Sun Microsystems, Enterprise JavaBeans Specification version 1.0, 1998.
  3. Sun Microsystems, JavaBeans Component Specification.
  4. Anne Thomas, Enterprise JavaBeans Server Component Model for Java (Whitepaper), 1997.

Enterprise JavaBeans

Что такое EJB (Enterprise JavaBeans) и для чего она нужна? Можно ли обойтись без EJB при разработке WEB-приложений? Что даёт EJB программистам?

В java WEB-приложении можно использовать JSP (JavaServer Pages), JavaServer Faces (JSF), Struts, GWT. Для работы с базой данных можно использовать JDBC (Java Database Connectivity) или JPA (JBoss Hibernate). Применение в WEB-приложении servlet’a позволяет перехватить обращение к серверу и выполнить определенные действия, т.е. выполнить фильтрацию сообщений. Где и как в WEB-приложении можно использовать EJB?

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

Сервер приложений Java EE (Enterprise Edition) включает два основных компонента : WEB-container (для использования JSP, JSF, Struts и т.д.) и EJB-container. Первый компонент используется для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики WEB-приложения. Для этого используется EJB-container.

Enterprise JavaBeans имеет спецификацию написания и поддержки серверных компонентов, содержащих бизнес-логику. Данная технология применяется, как правило, в том случае, если бизнес-логика требует один или несколько следующих сервисов :

  • сервис распределённых транзакций;
  • сервис сохранности данных (persistence);
  • сервис управления данными;
  • сервис событий;
  • сервис именования и каталогов (JNDI);
  • сервис безопасности и ограничения доступа к данным.

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

Основные типы компонентов EJB

В языке EJB под компонентом подразумевается зерно (Bean), а под Enterprise подразумевают «корпоративный». EJB делит компоненты (зерна) на несколько типов, исходя из их предназначения :

  • сессионные (Session Beans), которые могут быть
    • stateful — с сохранением текущего состояния;
    • stateless — без сохранения состояния;
    • singleton — один объект для всех приложений (начиная с EJB версии 3.1).

    Сессионный компонент Session Beans, иначе называемый сеансовый, вызывается клиентом (браузером) для выполнения вполне определенных операций, таких как, к примеру, проверка кредитной истории клиента. Слово «сессионный» предполагает, что экземпляр компонента доступен только на время выполнения определенной задачи сервером, и безвозвратно уничтожается в случае аварии или остановки сервера. Для доступа к серверной части приложения, клиент вызывает методы сессионного компонента, выполняющего определенные бизнес-задачи внутри сервера.

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

    Сеансовые компоненты без сохранения состояния EJB stateless не хранят никакой информации о своем состоянии и являются прикладными службами, которые выполняют все необходимые действия в рамках запроса. EJB stateless можно использовать для реализации таких операций, как перевод средств на кредитную карту или проверку кредитной истории клиента. На основе stateless-бинов проектируются WEB-сервисы.

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

    Сеансовые компоненты могут вызываться локально или удаленно, посредством Java RMI. Компоненты-одиночки и компоненты без сохранения состояния могут также экспортироваться в виде веб-служб SOAP (Simple Object Access Protocol) или REST (Representational State Transfer).

    Компоненты управляемые сообщениями MDB (Message-Driven Bean) подобно сеансовым компонентам реализуют некоторую прикладную логику и имеют одно важное отличие: клиенты никогда не вызывают методы MDB напрямую. Вместо этого компоненты MDB вызываются для обработки отправленных на сервер сообщений, что позволяет организовать асинхронный обмен сообщениями между частями системы. Типичными примерами подобных серверов сообщений могут служить IBM WebSphere MQ, Oracle Advanced Queueing и TIBCO. Компоненты MDB, как правило, применяются для повышения надежности интеграции систем и асинхронной обработки данных. Примером MDB сообщения может быть запрос на доставку товарных запасов от автоматизированной системы розничной торговли к системе управления поставками.

    Entity Bean и Java Persistence API

    EJB тесно связан с двумя спецификациями : с JPA, которая является стандартом хранения данных для Java EE и с CDI (Contexts and Dependency Injection) которая обеспечивает возможность внедрения зависимостей и предоставляет службы управления контекстом для всех компонентов Java EE, включая EJB.

    Возможность автоматического сохранения объектов в реляционной БД с использованием технологии объектно-реляционного маппинга (ORM) — так называемый механизм работы с persistence объектами, является одним из главных достоинств EJB. В контексте EJB persistence провайдер — это ORM-фреймворк, который поддерживает JPA, определяющий стандарт для :

    • конфигурации маппинга Entity Bean и его отображения в БД;
    • EntityManager API — стандартный API для CRUD (Create, Read, Update, Delete) операций над сущностями;
    • Java Persistence Query Language (JPQL) — для поиска и получения данных приложения.

    EntityManager API — это интерфейс, который связывает класс сущности приложения (Entity Bean) и её представления в БД. EntityManager знает как нужно добавлять сущности в БД, обновлять и удалять их, а также предоставляет механизмы для настройки производительности, кэширования, транзакций и т.д. Для этого используется язык запросов JPQL, очень похожий на SQL.

    Контейнеры EJB-container

    Java-приложениям для работы нужна виртуальная машина JVM (Java Virtual Machine). Сеансовым компонентам и компонентам MDB для работы точно также необходим контейнер EJB. Можно считать EJB-container развитием базовой идеи JVM. Так же, как JVM прозрачно управляет памятью, EJB-container обеспечивает компоненты EJB такими службами, как обработка транзакций, поддержка безопасности, удаленные взаимодействия и веб-службы.

    Согласно спецификации EJB3 контейнер предоставляет службы, применимые только к сеансовым компонентам и MDB. Операция добавления компонента EJB3 в контейнер называется развертыванием (deployment). После того, как EJB-компонент благополучно развернут в контейнере, он готов к использованию приложениями.

    В Java технологиях контейнеры не ограничены только EJB3. Контейнер Java EE – это сервер приложений с поддержкой EJB3, веб-контейнеров (сервлеты, JSP, JSF, Struts, GWT) и других Java EE API и служб. Примерами реализаций контейнеров Java EE могут служить следующие серверы приложений : Oracle WebLogic, GlassFish, IBM WebSphere, JBoss и Caucho Resin.

    Определение наименования компонентов EJB

    Формат именования компонентов EJB имеет следующий вид :

    • workspace — пространство имен;
    • app-name — наименование приложения;
    • module-name — наименование модуля;
    • ejb-name — наименование компонента;
    • object-name — полное наименование объекта.

    В представленном формате именования компонентов EJB ряд элементов (workspace, module-name, ejb-name) присутствуют в имени всегда и являются обязательными. А элементы [app-name] и [!object-name] могут отсутствовать и считаются необязательными.

    workspace

    Сервер Java EE может включать четыре пространства имен workspace, каждое из которых представляет свою область видимости.

    java:comp Область видимости компонента. Все компоненты EJB из WAR-файла попадают в одно общее пространство имен java:comp. Скорее всего Вам редко придется пользоваться этим пространством имен, поскольку основное его предназначение – сохранение обратной совместимости с версиями Java EE 6 и ниже, где java:comp было единственным стандартным пространством имен.
    java:module Область видимости модуля. Все компоненты модуля попадут в одно пространство имен java:module. Для обратной совместимости java:comp и java:module интерпретируются в веб-модулях как одно пространство имен. Когда это возможно, вместо java:comp следует использовать java:module.
    java:app Область видимости приложения. Компоненты из всех модулей одного приложения размещаются в общем пространстве имен java:app. Примером приложения может служить архив EAR. Все WAR- и EJB-компоненты, развертываемые из EAR-архива попадают в это пространство имен.
    java:global Глобальное пространство имен. В java:global размещаются все компоненты из всех модулей и всех приложений.
    app-name

    Значение наименования приложения [app-name] не является обязательным и присутствует только в именах тех компонентов EJB, которые развертываются на сервере приложений из EAR-архива. Если архив EAR не использовался, тогда [app-name] отсутствует в переносимых именах JNDI компонентов EJB. По умолчанию в качестве значения [app-name] выбирается имя EAR-файла без расширения .ear. Переопределить это умолчание можно в файле application.xml.

    module-name

    Значение module-name всегда присутствует в наименовании ресурса и является обязательным. Оно зависит от того, как развертываются модули, содержащие компоненты EJB. Если компоненты развертываются из отдельных файлов EJB-JAR (JAR-файлы развертываются непосредственно), в качестве значения module-name выбирается имя EJB-JAR файла без расширения .jar. Это умолчание можно переопределить с помощью элемента module-name в конфигурационном файле META-INF/ejb-jar.xml.

    Если развертываются компоненты, являющиеся частью веб-модуля (WAR-файл), по умолчанию в качестве значения module-name выбирается имя WAR-файла без расширения .war. Это умолчание можно переопределить с помощью элемента module-name в конфигурационном файле WEB-INF/web.xml. Если развертываются компоненты, являющиеся частью приложения (EAR-файл), по умолчанию значение module-name определяется в зависимости от того, являются ли компоненты EJB частью EJB-JAR или WAR в EAR. При развертывании компонентов из WAR-файла, выбор значения module-name выполняется в соответствии с правилом для WEB-модулей, которое можно переопределить в дескрипторе WEB-INF/web.xml. При развертывании компонентов из файлов EJB-JAR, значением module-name становится полный путь к каталогу, где находится файл EJB-JAR внутри EAR, плюс имя файла EJB-JAR без расширения .jar, которое можно переопределить в файле META-INF/ejb-jar.xml.

    ejb-name

    Значение наименования компонента ejb-name является обязательным и всегда присутствует в наименовании ресурса. Для компонентов EJB, помеченных аннотациями @Stateless, @Stateful или @Singleton, в качестве значения ejb-name по умолчанию выбирается имя класса компонента. Это значение можно переопределить с помощью атрибута name() аннотации. Для компонентов EJB, объявленных в файле ejb-jar.xml, значение ejb-name определяется с помощью элемента bean-name.

    object-name

    Значение полного наименования объекта [!object-name] является обязательным, и переносимые имена компонентов EJB с этим элементом всегда будут присутствовать в JNDI. Но сервер EE также требует, чтобы в JNDI присутствовало имя без этого значения. Такое «усеченное» наименование может пригодиться, когда доступ к компоненту осуществляется через единственный интерфейс (или если компонент вообще не имеет интерфейса).

    Что такое ejb java

    Enterprise Java Beans — EJB

    EJB — корпоративный java-компонент.

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

    Все технологии, рассмотренные до этого не позволяли распределять бизнес-логику (кроме вебсервисов). EJB предназначено для Java и делает распределение бизнес-логики легче.

    EJB предоставляет фреймворк, упрощающий разработку распределенных приложений.

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

    1. sessions beans — сеансовые
    2. message-driven beans (MDB) — компоненты управляемые сообщениями
    3. entity beans — компоненты сущностей

    sessions beans

    sessions beans могут быть 3 видов:

    • stateless — без сохранения состояния, при обращении к методам которых состояние не сохраняется. Это позволяет использовать один и тот же экземпляр для обработки зарпосов от разных клиентов.
    • stateful — с состоянием. Это сеансовые компоненты, которые сохраняют диаологове состояние (состояние, которое должно быть сохранено между обращениями клиента). По сути можно считать такой компонент аналогом сессии в jsp
    • singleton. Создается единственный экземпляр в конейнере и все запросы обрабатываются им, при чем он должен обеспечить параллельный доступ.

    stateless

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

    Важно, еще раз, все компоненты stateless должны быть идентичны и обращение клиента может быть направлено к любому из этих компонент.

    Вообще, контейнер управляет всеми видами компонентов EJB.

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

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

    Компоненты stateless не должны реализовывать javax.ejb.SessionSynchronization. Также на основе stateless компоненты можно реализовать веб-сервис.

    stateful

    Сеансовые компоненты stateful предназначены для кеширования информации между запросами клиента в течении клиентского сеанса. Для каждого клиента создается свой собственных экземпляр компонента stateful. Экзпмляр stateful уничтожается либо по запросу клиента, либо после определенного периода неактивности. Возможны ситуации, когда некоторые экземпляры простаивают и расходуют ресурсы, что неэффективно. Чтобы с этой ситуацией бороться, существует рабочий набор — компоненты, используемые в данный момент. Если компонент не используется некоторое время, то он может быть исключен из рабочего процесса (сериализован, сохранен в специальное хранилище и выгружен из ОЗУ). С этим могут быть проблемы, если компонент держит внутри себя соединения или открытые сокеты, поэтому, желательно, прежде чем компонент будет выгружен из рабочего набора, чтобы он эти ресурсы освободил.

    Перевод из рабочего процесса называют passication (instance passivation), а обратный перевод называется активацией (activation).

    Чтобы дать компоненту освободить ресурсы, перед переводом в пассивное состояние, контейнер вызывает метод, помеченный аннотацией @PrePassivate и реализовать этот функционал должен программист.

    При переводе из пассивного состояния в активное, конейтенр вызовет метод @PostActivate, который должен восстановить компонент.

    На перевод компонентов в пассивное состояние накладываются ограничения, например:

    • нельзя перевести компонент в пассивное состояние, если выполняется транзакция
    • если один из сущностных компонентов, принадлежащих сеансовуму компоненту, не сериализуем

    В этих случаях контейнер просто не может перевести в пассивное состояние. Сеансовые компоненты без сохранения состояния не переводятся, а просто уничтожаются.

    singleton

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

    Экземпляр singleton разделяется между всеми клиентами, в отличии от двух предыдущих типов сеансовых компонентов.

    JMS

    Компоненты управляемыми сообщениями были введенеы в спецификацию EJB2. Они позволяют получать и обрабатывать jms-сообщения (Java Messaging Services). JMS, в отличие от сокетов, обеспечивает надежную передачу сообщения. Например, если клиент, для которого предназначено сообщение, не работает, то сообщение будет сохранено на сервере и будет передано клиенту когда он заработает. JMS поддерживает два типа сообщений:

    Очередь — каждое сообщение обрабатывается только одним получателем.

    Тема — каждое сообщение отправляется всем подпищикам данной темы.

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

    Также компоненты могут поддерживать транзакцию и не предоставляют напрямую работу с БД (работа с БД осуществляется с помощью entity-компонент).

    Контейнер может поддерживать пул MDB-компонентов.

    Любой MJB-компонент может быть удаленным или локальным. Удаленный расположен за пределами текущего EJB-контейнера (на другой машине). Локальный расположен в том-же контейнере, где и обращающийся к нему компонент. Такое разделение сделано, чтобы можно было экономить ресурсы при обращении к локальным компонентам.

    Для того, чтобы объявить удаленный компонент, можно поступить 2 способами.

    Способ 1: объявить Java-интерфейс и пометить его аннотацией @Remote из javax.ejb.Remote

    Класс, реализующий этот интерфейс будет удаленным компонентом.

    Способ 2: пометить сам класс аннотацией @Remote и в качестве параметра передать название интерфейса

    @Remote(InterfaceName) public calss . 

    Интерфейсы часто называют еще бизнес-интерфейсами, т.к. они используются для реализации бизнес-логики.

    Объявление локального интерфейса осуществляется аналогично, только используется аннотация @Local, а не @Remote.

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

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

    В принципе, ejb-компонент без сохранения состояния может являться веб-сервисом, и обращаться к нему можно как к обычному веб-сервису, но для этого он должен быть помечен javax.jws.WebService.

    Сеансовые компоненты могут быть трех разным типов и помечаются аннотациями из javax.ejb.Stateless javax.ejb.Statefull, javax.ejb.Singleton

    В случае с компонентами управляемыми сообщениями, новый интерфейс реализовывать не обязательно. Сам класс должен быть помечен аннотацией javax.ejb.MessageDriven, но он должен реализовать существующий интерфейс javax.jms.MessageListener (это интерфейс должен реализовывать события, чаще всего это onMessage).

    Требования, предъявляемые к компонентам

    Класс, описывающий сеансовый компонент:

    1. должен быть public
    2. не может быть final
    3. должен быть public-конструктор без параметров
    4. не должен определяться метод finalize()

    При этом надо иметь в виду, что поддержка аннотаций появилась только с EJB 3 версии. В более ранних версиях требовалось, чтобы компонент наследовался от EJBObject или EJBLocalObject.

    Клиенты

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

    Клиент не знает конкретную реализацию EJB компонента и можно даже поменять тип компонента с stateless на stateful без изменения кода переменных.

    Как клиенты могут работать с объектами? (в качестве клиента могут быть и сервлеты, и jsp-страницы и javaSE и другой EJB-компонент).

    В случае с stateless компонентом: он может быть представлен как веб-сервис и, тогда, работа с ним будет аналогично вебсервисам:

    @WebServiceRef public StockQuesteService stockServie . .. получается port, работаем с port как обычно. 

    Со всеми остальными типами компонентов используется два способа для работы клиентов с этими компонентами (нужно получить ссылку на компонент).

    Впрыскивание ресурсов (DI):

    @EJB Cart cart; 

    При этом можно передавать имя компонента, но, если имя не передано, то конейнет выполнит поиск EJB-компонента соответствующему типа, перед которым стоит аннтация (у нас Cart) и ссылка будет присвоена переменной.

    @Resource SessionContext ctx; Cart cart = (Cart) ctx.lookup("cart"); 

    После того, как получена ссылка, с ней можно обращаться как с POJO-объектом.

     @EJB Cart cart; cart.startShopping(); card.addItem(633); 

    Возможно еще получать ссылку не на интерфейс EJB-объекта, а на класс EJB-объекта. (В предыдущем примере Cart определяло интерфейс, который реализован пусть будет CartBean).

    Это можно сделать так:

    @EJB CartBean cart; 

    Это называют безинтерфейсным представлением объекта.

    @Remote public interface MathOperationRemote 
    @Stateless public class MathOperatonBean implements MathOperationRemote 

    К бизнес-методам есть тоже ограничения

    1. не рекомендуется начинать название метода с ejb
    2. метод должен быть public
    3. не может быть final или static

    Получение ссылки на EJB-объекты

    Несколько подробнее про получение ссылок на EJB-объекты: DI можно использовать не всегда, эти зависимости должен кто-то инжектить. Как правило это делает контейнер (сервер приложений). Т.о. если клиентом является сервлет или другой EJB-объект, то DI использовать можно, т.к. он будет выполняться контейнером и он произведет впрыскивание. Если же клиентом является обычное JavaSE-приложение, то DI не сработает и, в этом случае, необходимо использовать JNDI. Кроме того, существует так называемый клиентский контейнер (ACC application client container). Этот клиентский контейнер может провести впрыскивание зависимостей в обычное JavaSE приложение. Вместо с glassfish поставляется клиентский контейнер appplitn и чтобы ее использовать можно использовать appclient -client EJBMathOperClient.jar, где в jar-файле находится сам клиент.

    Не рекомендуется в одном архиве компоновать и клиентскую часть и разворачивание ее на сервере. Т.е не должно быть клиентской части и класса main от JavaSE.

    В случае использования JNDI тоже не все так просто. Если приложение работает в конейнере, то никаких проблем.

    Contex ctn = new InitialContext() mops = (MathOperationRemote) ctx.lookup(jngiName); 

    Но если программа работает вне контейнера, нужно создать JNDI-контекст. Нужно сформировать параметры получения контекста, но они зависят от конкретного контейнера, предоставляющего JNDI.

    Пример для JBOSS:

    properties p new Properties(); p.put (Cntext.INITIAL_CONText_FACTORY, "org.jnp.interface.NamingContextFactory"); p.put( context.URL. . 
    Context ctx = getInitialContext() jndiName = MathOperationRemote.class.getName(); MathOperationRemote mops = (Math. ) ctx.lookup(jndiName); 

    Об именовании EJB-объектов:

    К каджому EJB-объекту можно получить ссылку по нескольким именам. (через интерфейс и через название класса, реализующего интерфейс). Но есть еще способы:

    1) Через глобальный контекст

    где испоьзуется если приложение было упакован в ear -архив (

    поиск при этом проводится в контексте текущего приложения

    это если ищем внутри текущего сервера

    Пример: пусть есть fooejb.jar без дескрипотора как stan-alone модуль

    java:global/fooejb/FooBean java:global/fooejb/FooBean!com.acme.Foo java:app/fooejb/FooBean java:module/FooBean java:module/FooBean!com.acme.Foo

    В случае если fooejb.jar внутри fooapp.ear, то обращение

    java:global/fooapp/fooejb/FooBean java:app/fooejb/FooBean java:module/FooBean

    Что такое ejb java

    EJB (Enterprise JavaBeans) – это технология построения распределенных систем на базе платформы J2EE. J2EE – полноценная спецификация, которая описывает дизайн серверной инфраструктуры для распределенных систем масштаба предприятия. Помимо EJB, J2EE включает и другие технологии, например: небезызвестные вам Servlets и JSP, технологию доступа к базам данных JDBС, реализацию Message Oriented Middleware – JMS и много другое.

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

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

    Ключами к пониманию того, как работает Enterprise Java Beans, являются понятия EJB-компонент (component), EJB-контейнер (container) и EJB-объект (object). Отношения между тремя этими составляющими можно увидеть на рисунке.

    Иерархия элементов EJB

    EJB-сервер управляет жизненным циклом EJB-контейнеров, а EJB-контейнеры, в свою очередь, управляют жизненным циклом EJB-компонента.

    EJB-сервер суть инфраструктура для всей распределенной системы. Именно он обеспечивает системное окружение для поддержки транзакционности, сохраняемости, параллелизма, безопасности.

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

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

    EJB, как и любой другой CTM, похож на огромное офисное здание (EJB-сервер), которое обеспечивает такие сервисы, как электричество, отопление, водоснабжение, охрана, Интернет и т.д. Каждая компания, арендующая офисы в этом здании, – аналог EJB-контейнера. Работники компании – EJB-компоненты. Именно работники выполняют нужные бизнесу действия, а компания, в свою очередь, пользуясь услугами всего офисного здания, обеспечивает своих работников охраной и доступом в Интернет. Конечно, приведенная аналогия не является на сто процентов адекватной моделью EJB-системы, но некоторые аналогии имеются.

    Рассмотрим теперь вопрос, каким образом происходит работа клиентского приложения с компонентами EJB. Как нетрудно предположить, на клиентской стороне присутствует специальный класс, называемый EJB-объектом, через который осуществляется взаимодействие клиентской бизнес-логики с EJB-компонентов. Несмотря на оригинальное название, EJB-объект – это обычный клиентский стаб, в задачи которого входит маршалинг, демаршалинг и другие системные операции, необходимые для функционирования приложения в рамках EJB . Учитывая также тот факт, что EJB полностью опирается на Java, нетрудно предположить, что принцип построения клиентского (и серверного тоже) стабов в рамках EJB в целом аналогичен принципам построения стабов в RMI (вот уж действительно, ничего нового).

    Общая схема EJB

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

    RMI скорее можно отнести к средству интеграции распределенных объектов, тогда как EJB – это полноценный монитор компонентных транзакций.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *