Віровідступник Geronimo: Що нового в OpenEJB 3.0 (вихідні коди), Різне, Програмування, статті

Специфікація 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.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*