Что такое ejb java

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 имеет спецификацию написания и поддержки серверных компонентов, содержащих бизнес-логику. Данная технология применяется, как правило, в том случае, если бизнес-логика требует один или несколько следующих сервисов :

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

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

Сессионный компонент 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.

Контейнеры 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 имеет следующий вид :

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

workspace

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

app-name

module-name

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 присутствовало имя без этого значения. Такое «усеченное» наименование может пригодиться, когда доступ к компоненту осуществляется через единственный интерфейс (или если компонент вообще не имеет интерфейса).

Источник

Введение в основы EJB3

Так как я уже затрагивал тему EJB3 в уроках, то решил рассмотреть его более детальней.

Немного о EJB

EJB (Enterprise Java Beans) – это фреймворк для построение бизнес-логики приложения.

Сервер приложений J2EE состоит из двух основных элементов:

WEB-Container – (JSP, JSF и т.д.) все что дает конечный вид пользователю, а точней пользовательский интерфейс.

EJB-Container – используется для написания бизнес-логики.

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

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

1. Session beans – используется для построения бизнес-логики, которая может быть вызвана программным клиентом через локальный, удаленный или веб-интерфейс обслуживания клиентов.

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

Существует 2 типа session-beans: stateless и stateful.

Stateful – автоматически сохраняют свое состояние между разными клиентскими вызовами.

Stateless – используются для реализации бизнесс-процессов, которые могут быть завершены за одну операцию.

2. Message-Driven beans – компонент является корпоративным компонентом, который позволяет Java EE приложениям обрабатывать сообщения асинхронно.

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

Message-Driven beans может обрабатывать не только JMS сообщения но и других видов сообщений.

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

3. Entities – это сущности каких то объектов и в EJB оно является хранилищем данных на период жизненного цикла Entity.

Entities является свое-родным отображением таблиц в БД.

Одним из главным достоинством EJB3 стал новый механизм работы с persistence, он дает возможность автоматически сохранять объекты в реляционной БД используя технологию ORM.

Для работы с entity был создан JPA (Java Persistence API).

JPA определяет стандарт для:

1) конфигурации маппинга сущностей приложения и их отображения в таблицах БД;

2) EntityManager API – позволяет выполнять CRUD (create, read, update, delete) операции над сущностями;

3) Java Persistence Query Language (JPQL) – для поиска и получения данных приложения;

Основные аннотации EJB3

@EJB – помечается bean, который мы собираемся использовать.

@Stateless – говорит контейнеру, что класс будет stateless session bean. Для него контейнер обеспечит безопасность потоков и менеджмент транзакций.

@Local – относится к интерфейсу и говорит, что bean реализующий интерфейс доступен локально.

@Remote – относится к интерфейсу и говорит, что bean доступен через RMI (Remote Method Invocation).

@Stateful – говорит контейнеру, что класс будет stateful session bean.

@Remove – метод, помеченный как Remove говорит контейнеру, что после его исполнения нет больше смысла хранить bean, т.е. его состояние сбрасывается. Это бывает критично для производительности.

@Entity – говорит контейнеру, что класс будет сущностью БД.

@Table(name=” ”) – указывает таблицу для маппинга БД.

@Id – указывает уникальный идентификатор сущности который будет ключом в БД.

@Column – указывает параметры колонки в БД включая имя колонки в БД.

@WebService – говорит, что интерфейс или класс будет представлять web-сервис.

Правила создания session bean

В качестве session bean может выступать обычный класс Java, но он должен удовлетворять следующим условиям:

1. Он должен иметь как минимум один метод;

2. Он не должен быть абстрактным;

3. Он должен иметь конструктор по-умолчанию;

4. Методы не должны начинаться с “ejb” (например ejbBean, ejbGoAtHome)

5. Свойства класса должны быть объявлены примитивами или реализовывать интерфейс Serializable.

Жизненный цикл EJB3

У stateless и MDB бинов существует 2 события жизненного цикла, которые мы можем перехватить. Это создание и удаление бина.

Метод, который будет вызываться сразу после создании бина помечается аннотацией @PostConstruct, а перед его удалением – @PreDestroy.

Stateful бины обладают помимо рассмотреных выше еще 2 событиями:

1) При активации @PostActivate;

2) При деактивации @PrePassivate.

Источник

Что такое ejb java

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

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

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

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

Содержание

sessions beans

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

stateless

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

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

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

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

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

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

stateful

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

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

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

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

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

singleton

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиенты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Enterprise JavaBeans

Итак, начнем наш тур по Enterprise JavaBeans путем исследования значения этих слов.

«Сторона сервера» означает, что объект EJB размещается в процессе на том же сервере, а не на клиентской машине. EBJ может предлагать удаленный просмотр, локальный просмотр или оба. Термин «просмотр» не относится к графическому просмотру; здесь мы говорим о способе, которым EJB предоставляет свой интерфейс. Если EJB представляет удаленный просмотр, все вызовы методов между клиентским кодом и удаленным экземпляром происходят через протокол удаленного вызова процедур, такого как RMI-IIOP. Если EJB представляет локальный просмотр, клиентский код должен быть в том же процессе, что и EJB объект, а все вызовы являются прямыми вызовами методов.

И последнее, и наиболее важное, EJB могут управляться. Это означает, что когда объект EJB активен в памяти, ведущий его процесс делает с ним немого больше, чем то, что обычно делает JVM. Процесс, обслуживающий EJB, вызывается EJB контейнером и является стандартизированной средой времени выполнения, которая предоставляет управляющую функциональность. Так как спецификация EJB стандартизирует службы, предоставляемые EJB контейнером, мы имеем поставщика, реализующего эту функциональность в коммерческих продуктах, таких как WebSphere и WebLogic, два наиболее известных коммерческих EJB контейнера от IBM и BEA Systems, соответственно. В EJB контейнере службы, такие как удаленные объекты и нейтралитет клиентского протокола, неявно используют JAVA RMI; другие службы (перечисленные ниже) являются стандартными. Такие службы, как кластеризация и поддержка при поломках, являются дополнительными и предлагаются определенными поставщиками.

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

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

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

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

Управлению масштабируемостью адресуется проблема увеличения выделяемых ресурсов, которая возникает при увеличении количества одновременно работающих клиентов. Ресурсы выделяются для клиента, а не для EJB объектов, есть такие поддерживаемые ресурсы, как соединения с базой данных, нити (threads), сокеты, очередь сообщений и так далее. Например, если число одновременно работающих клиентов увеличивается от 100 до 1000, вы можете получить 1000 EJB объектов в памяти, которые могут открыть 1000 соединения с базой данных; это может быть слишком много для количества имеющейся у вас памяти, и это определенно слишком тяжелая нагрузка на ваш сервер базы данных. EJB Контейнер может решить заняться этой проблемой, предоставив объединенные (pooling) экземпляры EJB и объединенные (pooling) соединения с базой данных. Таким образом, Контейнер будет хранить только ограниченное количество экземпляров или соединений, живущих в памяти, и будет присваивать им различных клиентов только во время, когда клиент действительно будет нуждаться в этом.

Красота Enterprise JavaBean

Платформа J2EE, с другой стороны, предоставляет вам более точную архитектуру рабочей среды, в которой вы создаете и используете компоненты. Это особенно верно для EJB, для которых спецификация определяет три разных EJB типа, с разными характеристиками отклика и разными областями применения. Вот эти три EJB типа:

Entity beans представляет объекты в том смысле, что Контейнер прозрачно хранит их состояния синхронно с данными в некотором другом постоянном хранилище, обычно это реляционная база данных. По этой причине entity beans используются для представления бизнес-сущностей, таких как клиент, корзина покупок и так далее. Entity beans не реализуют бизнес-логику, за исключением самосодержащейся логики напрямую связанной с внутренними данными. Хотя все entity beans открыты для клиентского кода одинаковым образом, они могут быть реализованы при использовании двух разных живучих стратегий. Разработчик имеет два варианты: 1) позволить Контейнеру заботиться о перемещении состояний между EJB объектом и базой данных, или 2) позаботиться об этом механизме и реализовать код, который перемещает состояние EJB от и к постоянному хранилищу. В первом случае мы говорим, что мы применяем Живучесть Управляемая Контейнером [Container Managed Persistence] (CMP), так что entity beans является CMP bean; во втором случае мы используем Живучесть Управляемая Компонентом [Bean Managed Persistence] (BMP), и мы получаем BMP bean. Опять таки, хотя есть существенное практическое отличие между CMP и BMP в стратегиях реализации, это не влияет на способ использования клиентом entity bean.

Обсуждения всех хитросплетений при предпочтении CMP перед BMP выходит за пределы этой главы. Однако важно объяснить, что большинство полезных свойств CMP не в том, как вы можете подумать, что вам не нужен код логики самосохранения. Реальная выгода от CMP состоит в том, что компонент может портироваться под любую систему постоянного хранения. Если вы думали об этом, CMP работает потому, что Контейнер генерирует весь код, необходимый для переноса состояния между EJB объектом и постоянным хранилищем. Это означает, что Контейнер знает, как взаимодействовать с таким специальным хранилищем. Реализация EJB Контейнера поддерживает различные хранилища, обычно все основные RDBMS, такие как Oracle, DB2, MySQL и т.п. Так как логика сохранения не закодирована жестко в CMP entity bean, а она предоставляется Контейнером, вы можете использовать тот же самый бинарный компонент в разных рабочих средах и все еще пользоваться поддержкой хранения объекта, предоставляемой Контейнером. Если вы используете BMP, логика хранения (например SQL выражения, если вы программируете для специфической RDBMS) будет встроена в ваш компонент, что затруднит использования другого хранилища.

Таким образом, вы используете CMP для того, чтобы повысить уровень портируемости; и вы используете BMP, если ваш entity bean связан с некоторой системой, не поддерживаемой платформой J2EE (например, это CICS приложение в IBM майнфрейме) или по другим особым причинам, которые мы не может предположить здесь.

Например, вам нужен session beans, реализующий логику резервирования и покупки билетов в кино по сети. Клиенты должны подключиться и использовать один из экземпляров такого компонента; экземпляр должен предоставить два метода, reserveSeats(& ) и purchase(& ). Первый метод принимает количество мест, которые нужны покупателю для покупки, и резервирует их в системе; второй метод принимает информацию о кредитной карте покупателя, проверяет сумму на ней и выполняет процесс покупки. Если Компонент является session beans с поддержкой состояний, то когда будет вызван метод reserveSeats(& ), экземпляр session bean «запомнит» количество мест, и вам не нужно будет опять передавать эту информацию в метода purchase(& ). Если session beans не поддерживает состояния, Компонент не будет хранить в памяти информацию, переданную в предыдущем вызове метода, так что клиенту нужно будет передавать ее при каждом вызове метода. Существует несколько стратегий для реализации и оптимизации передачи состояний, но состояния все равно должно передаваться при каждом вызове метода.

Причина существования этих двух типов session beans достаточно проста: неотъемлемой частью некоторых бизнес-процессов является отсутствие состояний (особенно это относится к тем процессам, которые вплотную привязаны к HTTP), а для других процессов неотъемлемо наличие состояний; архитектура призвана отразить это различие.

Есть технический подтекст в использовании одного типа session bean или другого, но так же, как и в случае сравнения CMP и BMP, детальное обсуждение выходит за рамки этой главы. Одна вещь, которую вы должны запомнить, состоит в том, что session bean без состояний ведут себя лучше при работе с экземпляром механизма пулинга (объединения) Контейнера, по сравнения с session bean с поддержкой состояний. Так как экземпляр session bean без поддержки состояний не предназначен для запоминания любой информации о состоянии, передаваемой клиентом, при завершении работы метода, этот же самый экземпляр может легко быть переназначен другому клиенту для вызовов других методов. Если экземпляр session bean поддерживает состояния, Контейнер не может переназначить его другому клиенту до тех пор, пока он не переместит информацию о состояниях в какое-то временное хранилище для последующего использования (в EJB этот процесс называется активация и пассивация). В этом заключено общее непонимание того, что при объединении (pooling) экземпляров, session beans без состояний улучшают масштабируемость, но это не при любых условиях. Ваш Контейнер должен быть очень хорошо оптимизирован относительно механизма активизации и пассивации, так чтобы перемещение состояния session bean с поддержкой состояний в некоторое вторичное хранилище и извлечение из него оказывало очень малое воздействие на производительность. Во-вторых, если вы используете session bean без поддержки состояний, вы должны передать состояние клиента в session bean при каждом вызове, и если клиент и session bean находятся на двух различных распределенных уровнях, то процесс постоянной передачи состояния, а также сериализация и десериализация параметров метода, как этого требует RMI, может стать критическим местом.

Интересно замечание относительно объединения (pools) экземпляров. Дело в том, что ваш Контейнер может их вообще не понимать. Если принять во внимание недавнюю оптимизацию, введенную в компиляторы Java и JVM, современные Контейнеры могут решить, что выделение блока памяти и сборка мусора более эффективное занятие, чем управление объединением.

И наконец, третий тип Enterprise JavaBean: Message-Driven Beans (MDB). MDB работает в кооперации с системой сообщений JAVA [Java Messaging System](JMS), которая является абстрактным API для системы Message-Oriented Middleware (MOM), более-менее похожую на то, как JDBC является абстрактным API поверх SQL базы данных.

MBD являются приемниками MOM сообщений, приходящих через JMS API. MDB обычно реализуются для выполнения некоторых действий при получении сообщений и выступают в роли объектно-ориентированных точек соединения между подсистемами, взаимодействующих посредством JMS. Например, MDB может реализовать посылку электронной почты администратору (используя JavaMail API), когда будет получено сообщение об определенном событии.

Отличие MDB от session beans и entity beans состоит в том, что они не предоставляют никаких удаленных или локальных представлений. Другими словами, клиентский код не может получить доступ к MDB, но MDB может использовать другие EJB и другие службы.

EJB Роли

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

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

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

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

Основное API

Все службы именования и директорий позволяют вам заполнять и искать репозитории некоторого рода. Более подробно, они позволяют вам ассоциировать (или связывает, если хотите) имя с объектом, а затем искать этот объект (или рассматривать его), используя это имя. По аналогии, он может использоваться как директорий белых страниц, когда физический телефон, на который вы хотите перевести звонки (уникально идентифицируемый номером), ассоциируется с именем клиента. В качестве более приближенного к Java примера можно привести RMI: вы можете зарегистрировать объект с именем (строка) в RMI Naming Service, так что другие приложения могут производить поиск этого имени в службе. Это в точности совпадает с тем, что вы можете делать с COS Naming Service. Таким образом, почему JNDI является достаточно удобной абстракцией: он предоставляет вам однообразный интерфейс к различным службам именования и директорий, точно так же, как вы используете JDBC для доступа к различным базам данных.

JDK1.4 поставляется с четырьмя стандартными Поставщиками Служб JNDI, которые предоставляют доступ к RMI, DNS, COS Naming Service и LDAP. Существует также дополнительный Поставщик Службы JNDI, который вы можете получить с вебсайта Sun, который предоставляет JNDI просмотр вашей локальной файловой системы (так что вы можете искать файлы и директории, используя JNDI).

В JNDI пространство имен представлено интерфейсом Context, наиболее часто используемым элементом API. Существуют разные классы, реализующие интерфейс Context, в зависимости от реальной службы, к которой вы обращаетесь посредством JNDI. Интерфейс Context имеет методы для связывания имени и объекта, для удаления связывания, для переименования, для создания и удаления подконтекста, для поиска имен, для получения списка имен и так далее. Вы также должны заметить что, так как контекст в Java является объектом, он может быть зарегистрирован в другом контексте под своим собственным именем. Другими словами, мы можем получить вложенный субконтекст, начав с родительского контекста, и создав связывание между именем субконтекста и вложенным объектом Context.

Хотя определенные операции в JNDI применимы только к определенному Поставщику Службы, концепция распространяется так далеко, что становится общей и широко применимой. Рассмотрим пример. Приведенный ниже код показывает, как получить список всех имен, зарегистрированных в корне используемой вами службы. Обратите внимание, что конструктор InitialContext получает в качестве аргумента тип Property. Я объясню это немного позже. Сейчас же просто взглянем на приведенный ниже код.

Вы видите, что это достаточно просто. Мы создаем объект Context, который представляет корень вашей службы именования или директории, получаете перечисление всех элементов этого контекста (пустая строка в вызове метода list( ) означает, что вы не ищете определенное имя), затем перебираете и печатаете все элементы из перечисления.

Ниже приведен законченный пример, который использует JNDI для просмотра содержимого корня контекста в DNS сервере (возможно, вам понадобиться использовать другие IP адреса для вашего DNS, в зависимости от конфигурации вашей сети).

//: c18:jndi:SimpleJNDI.java
import javax.naming.*;

public class SimpleJNDI <
public static void main ( String [] args ) throws Exception <
Properties props = new Properties () ;
props.put ( Context.INITIAL_CONTEXT_FACTORY,
«com.sun.jndi.dns.DnsContextFactory» ) ;
props.put ( Context.PROVIDER_URL, «dns://207.155.183.72» ) ;
Context context = new InitialContext ( props ) ;
Enumeration names = context.list ( «» ) ;
while ( names.hasMoreElements ())
System.out.println ( names.nextElement ()) ;
>
>
// /:

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

Существует другой способ предоставления значений параметров JNDI. Вы можете использовать внешний файл параметров, который является текстовым файлом, который ассоциирует названия параметров с их значениями. Этот файл должен называться jndi.properties, и он должен быть расположен в CLASSPATH вашего JNDI приложения. Отличие состоит в том, что вы не можете использовать константы названия параметров, определенных в интерфейсе Context, а вместо этого вы должны использовать их «строковые» значения (которые вы можете найти в стандартной документации по JDK). Содержимое нашего файла jndi.properties будет следующим:

Если вы выберете этот подход, вам больше ненужно будет передавать контейнер параметров в конструктор InitialContext. Другими словами, то, что вы поместите в файл jndi.properties, то вы и установите для JNDI в качестве значений по умолчанию.

Последнее, и наиболее важное, что я хотел бы рассказать о JNDI, это как ищутся имена. Как я упоминал, существует метод lookup( ) в интерфейсе Context. В следующем примере мы предполагаем, что существует внешний файл jndi.properties, в котором определено, какую службу мы просматриваем.

//: c18:jndi:SimpleJNDI2.java
import javax.naming.*;

Мы создали новый InitialContext и вызвали метод lookup( ) для него, передав Строку в качестве аргумента имени. Так как метод lookup( ) предназначен для работы с различными службами, он возвращает общий класс Object. Однако, реальный тип времени выполнения, возвращаемый из lookup( ) определяется специфичной службой, которую вы используете. Ради этого примера мы игнорируем тип и просто печатаем результат.

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

Таким образом, если мы используем JNDI с EJB, что такое Поставщик Услуг JNDI? Ответ состоит в том, что EJB Контейнер работает и выставляет свою собственную службу JNDI, специализированную для работы с ресурсами, управляемыми Контейнером. Другими словами, эта служба EJB JNDI предназначена, чтобы позволить клиентам и Enterprise JavaBean’ам находить ресурсы по JNDI именам. Помните, когда вы запускаете ваш EJB Контейнер, вы также неявно запускаете EJB JNDI службу, которая доступна вам через стандартный JNDI API.

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

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

Как вы можете видеть, есть две главных категории: исключения, наследуемые от java.lang.Exception напрямую, и другие исключения, наследуемые от java.lang.RuntimeException. Или, в терминах Java, проверяемые и не проверяемые исключения, соответственно.

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

Фактически, использование проверяемых исключений EJB указано в определениях EJB интерфейсов, используемых клиентом, что предопределяется спецификацией. Например, CreateException должно быть указано в спецификации метода, который клиент использует для создания экземпляра EJB. Аналогично, FinderException должно быть указано в спецификации метода, который клиент использует для нахождения существующего, постоянного объекта EJB. А RemoveException должно указываться в спецификации метода, который удаляет EJB объект.

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

Все исключения, которые поступают наружу из вашего EJB объекта, перехватываются Контейнером. Действия, предпринимаемые в этом случае Контейнером, могут сильно зависеть от условий, но в общем Контейнер автоматически откатит текущую транзакцию (если она есть) и передаст исключение клиенту. Если исключение, сгенерированое внутри вашего EJB, было типа EJBException, клиент получит общее RMI RemoteException, что проинформирует его, что метод окончился неудачей. Если исключение, сгенерированое в EJB, было исключением уровня приложения, таким как FinderException, Контейнер передаст это исключение клиенту.

EJB Контейнер изнутри

Основная идея достаточно проста. Когда бы клиентское приложение ни запросило ссылку на EJB объект, Контейнер реально возвращает ссылку на сгенерированный Контейнером прокси, который принимает все клиентские запросы, выполняет некоторые вспомогательные действия и, в конечном итоге, делегирует их объекту, реализованному BeanProvider’ом. Мы вызываем формирователь EJB Объекта, а затем EJB Экземпляра. Пожалуйста, не путайте их: EJB Объект генерируется Контейнером, в то время как EJB экземпляр реализуется Bean Provider’ом.

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

И наконец, сгенерированный контейнером прокси (EJB Объект) не нужно путать с RMI прокси, который также представлен. Приведенная ниже диаграмма разъясняет эту архитектуру.

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

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

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

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

Программное обеспечение

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

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

Другие программные продукты, которые вам понадобятся: Java SDK1.4 или более позднюю версию; Ant и JUnit (которые вероятно уже установлены у вас, если вы запускали другие примеры из этой книги); и XDoclet, другая утилита с открытыми исходниками, которая поможет нам в разработке ваших EJB.

Инструкция по установке, которую вы найдете в директории кода c18, предоставит вам все дополнительные детали.

Пример приложения

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

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

Прежде чем посмотрим на реальный код, я хочу упомянуть некоторые вещи относительно структуры исходных текстов. Все примеры находятся в директории c18 исходного кода для этой книги. Каждый поддиректорий является отдельным, самодостаточным примером, который собирается в корне поддиректория. На верхнем уровне директории каждого примера есть Ant скрипт для сборки. На этом же уровне есть директорий src, который содержит все файлы исходного кода для этого примера. Директорий src содержит поддиректории ejb-tier и rmiclient, в которых содержится код для реализации EJB и для клиентского приложения (включая JUnit тест), соответственно. Также, обратите внимание, когда вы будете собирать пример, что Ant скрипт будет создавать рабочий директорий для компиляции и сборки (смотрите комментарии в скрипте Ant более подробно), но ничего не создает и не изменяет в src директории. И, наконец, все наши классы определены в пакете javatheater, содержащем вложенные пакеты, которые тоже стоит упомянуть: javatheater.client содержит клиентское приложение; javatheater.test содержит классы JUnit тест; javatheater.ejb содержит наши EJB интерфейсы и связанные классы, а javatheater.ejb.implementation содержит классы реализации EJB.

//: c18:example01:src:javatheater:Movie.java
//
package javatheater;

public class Movie <
int id;
String title;

public int getId () <
return id;
>

public String getTitle () <
return title;
>

public String toString () <
return «[» + id + «] » + title;
>
>
// /:

Здесь определен класс Movie, который содержит два поля: id (типа int) и title (типа String). Класс также определяет конструктор плюс сеттеры и геттеры (setters и getters) для доступа к значениям полей. Конечно, более реалистичный объект фильма должен содержать много больше информации, такой как актеры, директор, рейтинг, краткий обзор; но реализация всего этого добавит ненужную сложность в пример.

//: c18:example01:src:javatheater:Show.java
//
package javatheater;

public class Show <
int id;
Movie movie;
String showtime;
int availableSeats;

public int getId () <
return id;
>

public Movie getMovie () <
return movie;
>

public String getShowtime () <
return showtime;
>

public int getAvailableSeats () <
return availableSeats;
>

public String toString () <
return «[» + id + «] » + movie + «, » + showtime + «, »
+ availableSeats;
>
>
// /:

Так как example01 это простейшее Java приложение, оно не употребляет многие службы, предоставляемые архитектурой EJB. Определенно, мы не имеет поддержки постоянства. Я не использовал JDBC для хранения и получения объектов из базы данных (что должно означать отображения объект/отношения, нечто более сложное для нашего первого примера), также в примере есть класс, называемый Storage, который эмулирует наличие постоянного хранилища данных.

//: c18:example01:src:javatheater:Storage.java
//
package javatheater;

public class Storage <
private static Storage ourInstance;
private Movie [] movies;
private Show [] shows;

public synchronized static Storage getInstance () <
if ( ourInstance == null ) <
ourInstance = new Storage () ;
>
return ourInstance;
>

public synchronized Movie findMovieById ( int id ) <
for ( int i = 0 ; i ) <
Movie movie = movies [ i ] ;
if ( movie.id == id )
return movie;
>
return null ;
>

public synchronized Movie findMovieByTitle ( String title ) <
for ( int i = 0 ; i ) <
Movie movie = movies [ i ] ;
if ( movie.title == title )
return movie;
>
return null ;
>

public synchronized Movie [] findAllMovies () <
return movies;
>

public synchronized Show findShowById ( int id ) <
for ( int i = 0 ; i ) <
Show show = shows [ i ] ;
if ( show.id == id )
return show;
>
return null ;
>

public synchronized Show findShowByMovie ( Movie movie ) <
for ( int i = 0 ; i ) <
Show show = shows [ i ] ;
if ( show.movie.id == movie.id )
return show;
>
return null ;
>

public synchronized Show [] findAllShows () <
return shows;
>
>
// /:

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

//: c18:example01:src:javatheater:ShowListing.java
//
package javatheater;

public class ShowListing <
static Storage storage = Storage.getInstance () ;

public static void main ( String [] args ) <
Show [] shows = storage.findAllShows () ;
for ( int i = 0 ; i ) <
Show show = shows [ i ] ;
System.out.println ( show ) ;
>
>
>
// /:

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

Источник