Вероотступник Geronimo: Что нового в OpenEJB 3.0

Майкл Галпин, инженер по программному обеспечению, Vitria Technology

Спецификация Java 2 Platform, Enterprise Edition (J2EE) сделала технологию Java главенствующей в области разработки корпоративных приложений. Долгие годы данная технология пыталась занять это положение и до сих пор успешно сохраняет его, что в очередной раз подтвердилось в редакции спецификации Java Platform, Enterprise Edition 5 (Java EE 5). OpenEJB с самого начала был составной частью Geronimo. Его версия 3.0 является ключевым компонентом в реализации Geronimo спецификации Java EE 5. В данной статье рассказывается о принципах, лежащих в основе Enterprise JavaBeans (EJB) 3, а также о новых возможностях OpenEJB, благодаря которым обеспечиваются новые важные функции Geronimo.

История EJB

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

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

Версии спецификаций EJB 1.0 и 1.1 были разработаны и выпущены компанией Sun Microsystems. Все последующие спецификации создавались с использованием Java Specification Requests (JSR) и проходили сертификацию через Java Community Process (JCP). Участие сообщества в разработке - ключевой элемент в эволюции Java-технологий. Трудности, с которыми сталкивались разработчики EJB, были учтены в JCP. Результатом этого явилась спецификация EJB 3.0, законченная в мае 2006 г.

Теперь компоненты EJB уже не были направлены только на решение сложных проблем, они также стали развиваться в направлении упрощения разработки. Цель EJB 3.0 - сделать начальную стадию разработки легче, а приложения - более удобными в сопровождении. Мы расскажем, насколько проще стала EJB версии 3.0 по сравнению с EJB 2.1. Во-первых, давайте посмотрим на OpenEJB, которая является реализацией EJB и одной из основ Geronimo.

OpenEJB - EJB 1.1

OpenEJB существует приблизительно с 2000 г. Ее основателями были Дэйвид Блевинс (David Blevins) и Ричард Монсон-Хейфел (Richard Monson-Haefel). Блевинс также стоял у истоков Geronimo, поскольку OpenEJB был самым приемлемым выбором для реализации EJB в Geronimo. OpenEJB была одной из первых реализаций спецификации EJB 1.1. Она обеспечивала прямую реализацию компонентов (beans) для сеансов удаленного доступа и использовала Castor для реализации компонентов персистентности entity bean, управляемой контейнером (container-managed persistence - CMP). С самого начала OpenEJB был направлен на облегчение труда разработчиков. Например, OpenEJB допускал использование встроенных контейнеров (и даже встроенных баз данных), чтобы легче было писать тесты для создаваемых EJB-компонентов. В большинстве реализаций EJB-компоненты было настолько трудно тестировать, что для этого приходилось разрабатывать сложные инфраструктуры (самый яркий пример - JUnitEE). OpenEJB стал очень качественной реализацией для EJB 1.1 - по скорости и удобству для пользователя. Однако для состыковки с потребностями Geronimo потребовалась определенная эволюция OpenEJB.

OpenEJB и Geronimo - EJB 2.1

Geronimo был задуман как реализация (с открытым кодом) спецификации J2EE 1.4. Эта спецификация включала спецификацию EJB 2.1. OpenEJB был реализацией EJB 1.1. Версия EJB 2.1 была значительно расширена по сравнению с версией 1.1, в том числе были добавлены локальные интерфейсы для сессионных компонентов (session beans) и компонентов, управляемых сообщениями (MDB), язык запросов для методов поиска компонентов entity bean и поддержка представления сессионных компонентов в виде Web-сервисов.

К счастью, в команде разработчиков Geronimo (а тогда в нее вошло много специалистов, внесших свой вклад в создание OpenEJB) оказалась много талантов, и они постарались реализовать все свойства EJB 2.1 в OpenEJB, таким образом содействуя тому, чтобы в дальнейшем Geronimo стала реализацией J2EE 1.4. В процессе разработки OpenEJB кое в чем приобрела сложность, характерную для спецификации EJB. Например, встраиваемый контейнер, столь полезный при тестировании элементов, явился побочным эффектом борьбы за совместимость с EJB 2.1. Но Java-разработчикам повезло: не за горами было появление EJB 3.

EJB 3.0

Так что же так впечатляет в EJB 3.0? Легче всего будет понять EJB 3.0, сравнивая его с EJB 2.1. Давайте построим простой EJB-компонент в каждой из версий. В следующих разделах мы создадим простой сессионный компонент, не меняющий состояния в процессе исполнения (stateless), который будет выдавать текущее время. Посмотрим сначала, как это делается в EJB 2.1.

EJB-компонент Time - среда EJB 2.1

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

Листинг 1. Простой интерфейс Time

                package org.developerworks.time;

import java.util.Date;

public interface Time {
     public Date currentTime(); 
}

Теперь преобразуем его в EJB. Сначала надо переопределить интерфейс, как показано в листинге 2.

Листинг 2. Интерфейс Time в EJB

                package org.developerworks.time;

import java.rmi.RemoteException;
import java.util.Date;

import javax.ejb.EJBObject;

public interface Time extends EJBObject{
     public Date currentTime() throws RemoteException; 
}

Весьма похоже, но все таки неприятно то, что интерфейс пришлось изменять. В расширении EJBObject, кажется, нет ничего плохого, потому что это обычный интерфейс-маркер (marker interface). Хуже всего то, что приходится менять сигнатуру метода для объявления того, что он генерирует исключение RemoteException. В EJB 2.0 эта проблема решается за счет добавления альтернативного локального интерфейса, как показано в листинге 3.

Листинг 3. Локальный интерфейс для Time

                package org.developerworks.time;

import java.util.Date;

import javax.ejb.EJBLocalObject;

public interface TimeLocal extends EJBLocalObject{
     public Date currentTime();
}

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

Можно представить простую реализацию для исходного интерфейса, например, как в листинге 4.

Листинг 4. Реализация исходного интерфейса

                package org.developerworks.time;

import java.util.Date;

public class TimeBean implements Time {

     public Date currentTime() {
             return new Date();
     }

     public TimeBean() {
     }
}

Это чересчур просто для EJB 2.1. В листинге 5 - еще одна версия того же самого.

Листинг 5. TimeBean Реализация EJB

                package org.developerworks.time;

import java.rmi.RemoteException;
import java.util.Date;

import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class TimeBean implements SessionBean {

     public void ejbCreate() {
     }

     public Date currentTime() {
          return new Date();
     }

     public void ejbActivate() throws EJBException, RemoteException {
     }

     public void ejbPassivate() throws EJBException, RemoteException {
     }

     public void ejbRemove() throws EJBException, RemoteException {
     }

     public void setSessionContext(SessionContext sessionContext) throws EJBException,
               RemoteException {
     }

     public TimeBean() {
     }
}

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

Но мы еще не закончили работу с версиией EJB 2.1. Нужно создать интерфейсы Home и LocalHome. Их использует контейнер, но обеспечивает разработчик. Например, в листинге 6 показан интерфейс Home.

Листинг 6. Интерфейс Time Home

                package org.developerworks.time;

import java.rmi.RemoteException;

import javax.ejb.CreateException;
import javax.ejb.EJBHome;


public interface TimeHome extends EJBHome{
   public static final String COMP_NAME="java:comp/env/ejb/Time";
   public static final String JNDI_NAME="Time";

   public Time create() throws CreateException,RemoteException;

}

Интерфейс LocalHome - почти такой же. Он расширяет код EJBLocalHome, а не EJBHome, и тогда его метод Create не будет генерировать исключение RemoteException.

В довершение всех неудобств нам еще придется написать дескриптор размещения для нашего EJB. Этот дескриптор размещения свяжет все воедино и даст контейнеру дальнейшие инструкции о том, как ему управлять EJB. В листинге 7 показан возможный дескриптор размещения для нашего компонента.

Листинг 7. Дескриптор размещения

                <?xml version="1.0" encoding="UTF-8"?>

<ejb-jar id="ejb-jar_1" xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/
j2ee/ejb-jar_2_1.xsd" version="2.1">

   <display-name>Time</display-name>

   <enterprise-beans>

      <!-- Session Beans -->
      <session id="Session_Time">
         <display-name>Time</display-name>
         <ejb-name>Time</ejb-name>
         <home>org.developerworks.time.TimeHome</home>
         <remote>org.developerworks.time.Time</remote>
         <local-home>org.developerworks.time.TimeLocalHome</local-home>
         <local>org.developerworks.time.TimeLocal</local>
         <ejb-class>org.developerworks.time.TimeSession</ejb-class>
         <session-type>Stateless</session-type>
         <transaction-type>Container</transaction-type>
      </session>
</ejb-jar>

Надеюсь, теперь вы поняли, насколько трудно стало работать, когда появился EJB. Как же EJB 3.0 решает эту проблему? Посмотрим.

EJB-компонент Time - среда EJB 3.0

Давайте заново напишем EJB-компонент Time при помощи EJB 3.0. Как и раньше, начнем с интерфейса, описывающего сервис. Только на этот раз работы по превращению его в интерфейс EJB будет меньше. Посмотрите на листинг 8.

Листинг 8. Интерфейс TimeBean

                package org.developerworks.time;

import java.util.Date;

import javax.ejb.Remote;

@Remote
public interface Time {
     public Date currentTime();
}

Обратите внимание, насколько это похоже на листинг 1. Все, что мы добавили, - аннотацию, которая объявляет, что этот интерфейс - удаленный. Нам не пришлось расширять интерфейс и генерировать исключение RemoteException. Спецификация EJB 3.0 позволяет вообще не включать аннотацию, если класс реализации правильно аннотирован и реализует только один интерфейс. Но для тренировки полезно будет вставить сюда аннотацию, ведь с ней кодом станет легче управлять. Теперь можно перейти к реализации, представленной в листинге 9.

Листинг 9. Реализация EJB TimeBean

                package org.developerworks.time;

import java.util.Date;

import javax.ejb.Stateless;

@Stateless
public class TimeBean implements Time{

     public Date currentTime(){
          return new Date();
     }
}

Такие EJB-компоненты часто называют простыми старыми Java-объектами (plain old Java objects - POJO), потому что единственное указание на то, что это EJB - аннотация @Stateless. Не нужно реализовывать никакие возвраты в составе интерфейса. Если вам потребуется реализовать такой возврат, вы сможете просто добавить метод и добавить аннотацию с объявлением возврата. Этому методу можно дать любое название, потому что реализуется не интерфейс.

Перейдем к дескриптору размещения. Постойте, да ведь он не один! Если вы еще раньше не убедились в важности EJB 3.0 (а соответственно, и Java EE 5), надеемся, теперь вам все понятно. Это огромный прорыв в обеспечении легкости разработки. Конечно, это всего лишь спецификация. Для того чтобы использовать все эти замечательные идеи, потребуется реализация. И тут появляются Geronimo 2.0 и OpenEJB 3.0.

Geronimo 2 - Java EE 5

Вы разобрались лишь в самых базовых вещах, но наверняка уже поняли, что Java EE 5 далеко ушла от J2EE 1.4. В ней сохранились многие из старых понятий. Сервер приложений предоставляет те же сервисы, что и раньше (например, распределенные вычисления, управление транзакциями и персистентность). Однако API-интерфейсы для этих сервисов разительно отличаются. Теперь разрабатывать EJB значительно проще, но это значит, что серверы приложений Java EE 5 должны обеспечивать большую функциональность, чем ранее. Поэтому разработчикам Geronimo было чем заняться, когда пришла пора реализовывать спецификацию Java EE 5. Особенно это касалось OpenEJB, потому что, как я уже говорил, ее рассчитывали сделать основой для Geronimo, а в нем реализована революционно новая спецификация EJB 3.0.

На момент написания данной статьи Apache Geronimo прошел сертификацию Java EE 5.0 TCK. Все разработчики довольны возможностью использования нового API EJB 3 и развертывания более простого и понятного кода в Geronimo.

Статус Инкубатора

Интересно отметить, что проект OpenEJB теперь является одним из проектов в инкубаторе Apache Incubator. Группа разработчиков Apache Geronimo очень содействовала реализации OpenEJB в EJB 2.1, потому что это было ключевым вопросом для реализации Geronimo в J2EE 1.4. Однако OpenEJB еще не был полностью готов присоединиться к Apache. Потребовалось проделать массу бумажной работы, но сейчас OpenEJB - часть Инкубатора. EJB 3.0 реализовывается как проект Apache, и его успешное завершение очень поможет OpenEJB получить статус Apache-проекта высшего уровня.

Заключение

В этой статье много говорилось об эволюции спецификаций J2EE и EJB. Вы увидели, насколько мощна эта спецификация, но также поняли, что это привело к сложности программной модели, в результате чего Java-разработчикам приходилось нелегко. Вы понимаете, что спецификации Java EE 5 и EJB 3.0 созданы для того, чтобы решить эти больные вопросы и повысить эффективность разработки на Java. Это значительно более простая программная модель, благодаря которой возрастает не только непосредственно производительность труда разработчика, - результатом должны стать приложения, которые будет намного легче поддерживать и обслуживать.

В первом релизе Geronimo была реализована спецификация J2EE 1.4. OpenEJB сделало ее составной частью реализацию EJB 2.1. Сейчас в Geronimo реализуется спецификация Java EE 5, а дело OpenEJB - реализовать спецификацию EJB 3.0. Уже многое сделано, поэтому советую вам скачать последний, значительно обновленный релиз Geronimo - тогда вы почувствуете все преимущества Java EE 5 и EJB 3.0. Когда вы в следующий раз сделаете аннотацию для POJO, чтобы превратить его в EJB, не забудьте сказать спасибо группе разработчиков OpenEJB.

Вероотступник Geronimo: Что нового в OpenEJB 3.0 (исходники)