Лабораторные работы по EJB

Содержание

1. Общая теория к лабораторным работам по EJB (J2EE, EJB-архитектура, сервер приложений JBoss)

2. Лабораторная работа по EJB #1. Создание сессионного EJB-компонента без сохранения состояния

3. Лабораторная работа по EJB #2. Создание сессионного EJB-компонента с сохранением состояния

4. Лабораторная работа по EJB #3. Использование JBoss Eclipse IDE для создание EJB-компонентов

Литература и дополнительные источники информации

1. Общая теория к лабораторным работам по EJB (J2EE, EJB-архитектура, сервер приложений JBoss)

Платформа J2EE использует модель многоуровневых распределенных приложений.

Рисунок 1. Многоуровневые приложения

Хотя J2EE-приложение состоит из трех или четырех уровней (рис. 1), многоуровневые J2EE-приложения обычно принято называть трехуровневыми (трехзвенными):

· клиентский компьютер - клиентский уровень/уровень представления (GUI)

· сервер J2EE - бизнес уровень

· сервер базы данных или корпоративный сервер (EIS - Enterprise Information Server) - уровень данных

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

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

· Клиентские приложения и апплеты - это компоненты, работающие на клиентской машине.

· Компоненты технологии Java-сервлеты и JavaServer Pages (JSP) - Web-компоненты, работающие на сервере.

· Корпоративные компоненты EJB - это бизнес-компоненты, работающие на сервере.

EJB-компоненты

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

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

Рисунок 2. Бизнес- и EIS-уровень

EJB-компоненты исполняются в контейнерах. Контейнер - среда, окружающая компонент, находящийся на сервере. Контейнеры являются интерфейсом между компонентом и низкоуровневыми платформо-зависимыми функциональными возможностями, поддерживающими компонент (управление состоянием EJB и др.). На рис. 3 показано расположение EJB компонентов на J2EE-сервере.

Рисунок 3. J2EE-сервер и контейнеры

Типы EJB

Существует три типа компонентов EJB:

1. Сессионные (сеансовые) компоненты - session bean.

2. Объектные компоненты - entity bean.

3. Компоненты, управляемые сообщениями - message-driven bean.

Сессионные компоненты (session bean) представляют кратковременное общение с конкретным клиентом. Клиент изменяет состояние сессионного компонента. Когда клиент заканчивает работу, сессионный компонент и его данные исчезают.

Объектные компоненты (entity bean) представляют постоянные данные, хранимые в одной строке таблицы базы данных. С каждым entity bean взаимодействуют множество клиентов - мультипоточность, транзакционность. Если клиент завершает работу, гарантируется, что данные такого компонента будут сохранены.

На рис. 3 представлено взаимодействие клиентов с сессионными и объектными компонентами-EJB.

Рисунок 3. Session/Entity EJB

Управляемые сообщениями компоненты (message-driven bean) комбинируют особенности сессионного компонента и JMS (Java Messaging Service) приемника сообщений, позволяя бизнес-компоненту получать сообщения JMS асинхронно и выполнять некие действия как реакцию на сообщения.

Архитектура EJB-компонентов

Чтобы понять механизм создания компонентов EJB, рассмотрим реализацию их подробней. Компоненты EJB имеют два важных внешних интерфейса (рис. 4.).

Рисунок 4. Интерфейсы EJB.

Remote interface	Расширяет интерфейс javax.ejb.EJBObject. Определяет прикладные методы компонента, доступные для выполнения из вне. По сути, это бизнес-методы компонента.
Remote home interface	Расширяет интерфейс javax.ejb.EJBHome. Home-интерфейс определяет методы жизненного цикла, применяемые для создания, удаления и поиска компонентов.
Local interface/ Local home interface	Аналогичны Remote-интерфейсам, с той лишь разницей, что ориентированы на использование другими компонентами из того же контейнера EJB.
Bean class	Классы сеансовых и объектных компонентов реализуют прикладные методы и методы жизненного цикла компонента. Объектные компоненты должны реализовывать javax.ejb.EntityBean Сеансовые компоненты - javax.ejb.SessionBean

На стороне клиента Remote-интерфейс и Home-интерфейс оформлены в виде классов, которые скрывают сетевые взаимодействия на основе RMI с сервером приложений. Клиент работает с объектами, думая, что они работают в том же адресном пространстве, что и само приложение, а на самом деле происходят сетевые вызовы и функционал объектов работает совсем на другой вычислительной машине.

Теперь рассмотрим типичное взаимодействие клиента с компонентом EJB (рис. 5).



Рисунок 5. Взаимодействие с компонентом EJB.

Последовательность действий:

1. Клиент использует сервис имен JNDI для поиска Home-интерфейса компонента.

2. Java Naming and Directory Interface (JNDI) - стандартный API Java для доступа к различным типам сервисов.

3. Сервис JNDI запрашивает у сервера приложений ссылку на Home-интерфейс для EJB-компонента.

4. Полученная ссылка возвращается клиенту

5. Клиент через найденный Home-интерфейс вызывает функцию создания экземпляра компонента на стороне сервера.

6. Соответствующая Home-factory для EJB-компонента создает или находит ранее созданный EJB компонент из пула EJB-объектов.

7. Клиенту возвращается Remote-интерфейс созданного компонента

8. Клиент вызывает бизнес-метод на созданном компоненте через его Remote-интерфейс.

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

11. Результаты выполнения бизнес-метода возвращаются клиенту.

Развертывание EJB

Прежде чем разместить EJB-компонент на сервере приложений, необходимо поместить его элементы вместе с дескриптором развертывания в единый jar-файл. Файлы, которые помещаются в JAR-файл EJB-компонента показаны на рис. 6.

Рисунок 6. Состав EJB JAR файла.

Дескриптор развертывания (deployment descriptor) - XML-файл, включенный вместе с файлами EJB в JAR, позволяет настроить определенное поведение компонентов без модификации класса компонента и его интерфейсов. Дескриптор развертывания указывает серверу приложений, каким образом применять службы безопасности, транзакций и т.д. к компоненту. Дескрипторы помогают на сервере инструментам развертывания размещать компоненты в контейнер компонентов. После развертывания, свойства из дескриптора продолжают использоваться контейнером для управления компонентами во время выполнения.

Примеры дескрипторов развертывания будут рассмотрены отдельно при создании сессионных/объектных EJB-компонентов.

Преимущества EJB

Преимущества для разработчиков:

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

2. Переносимость приложений - приложение с использованием EJB может быть запущено на любом J2EE-совместимом сервере приложений.

3. Повторное использование компонентов - каждый EJB-компонент может быть использован повторно в дальнейших проектах.

4. Разделение бизнес логики и клиентского представления

5. Упрощенная разработкаWeb-сервисов - контейнеры EJB позволяют определять методы EJB-компонента как доступные в виде Web-сервиса.

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

Преимущества для пользователей корпоративных систем:

1. Выбор J2EE сервера - широкий выбор среди разнообразных серверов J2EE.

2. Интеграция с существующими приложениями и данными - архитектура EJB и ряд других J2EE API стандартизуют и упрощают интеграцию EJB с другими приложениям и системами заказчика. Например, EJB может быть настроен на существующую БД при развертывании.

3. Интеграция с другими корпоративными системами - использование Web-сервисов.

4. Безопасность приложения - архитектура EJB имеет развитые сервисы безопасности на J2EE сервере, которые настраивает системный администратор.

Сервер приложений JBoss

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

Прежде чем приступить к лабораторным работам необходимо установить сервер приложений.

Будет использоваться сервер приложений JBoss. JBoss - open-source сервер приложений. Поддерживает следующие технологии:

· EJB (Enterprise JavaBeans)

· JMS (Java Message Service)

· JTS/JTA (Java Transaction Service/Java Transaction API)

· Servlets and JSP (JavaServer Pages)

· JNDI (Java Naming and Directory Interface)

Скачать сервер JBoss можно с

http://www.jboss.com/products/jbossas/downloads.

Использовалась версия jboss-4.0.1sp1.

Установка и настройка

1. Скачанный архив JBoss распаковывается в какую-либо директорию, например C:\Java\jboss-4.0.1sp1\

2. Убедится, что установлены переменные окружения: JAVA_HOME = директория, где установлен JDK JBOSS_HOME = директория, где установлен JBoss

Запуск сервера

Для запуска сервера достаточно запустить файл JBOSS_HOME\bin\run.bat. В консоле сервера можно наблюдать информационные сообщения, такие как результат запуска, информация о развертывании EJB-компонентов.

2. Лабораторная работа по EJB #1. Создание сессионного EJB-компонента без сохранения состояния

Сессионный компонент (session bean) - EJB-компонент, который создается клиентом и обычно существует только в течение одной клиент-серверной сессии. Сессионный компонент выполняет для клиента вычислительные операции и организует доступ к базе данных. В случае сбоя системы сессионный компонент не восстанавливается.

Сессионные компоненты могут использоваться как в Web-приложениях, так и в традиционных 3х уровневых приложениях.

На рис. 1. показано использование сессионных компонентов в web-приложении.

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

Рисунок 1. Использование сессионных компонентов в Web-приложениях.

На рис. 2. показано использование сессионных компонентов в классических 3х уровневых приложениях.

Клиентское приложение реализует GUI для бизнес процессов. Вся бизнес логика выполняется в сессионном компоненте на сервере.

Рисунок 2. Использование сессионных компонентов в 3х уровневых приложениях.

Сессионные компоненты могут быть двух видов:

1. Сессионный компонент с состоянием (stateful session bean)

2. Сессионный компонент без состояния(stateless session bean)

Для сессионного компонента с состоянием характерно поддержание состояния связанного с клиентом. EJB-контейнер гарантирует работу клиента с одним и тем же экземпляром EJB-компонента (рис. 3.). Такое состояние называют состоянием диалога (conversational state).

Рисунок 3. Использование экземпляров сессионных компонентов с состоянием

Какая информация обычно хранится в состоянии диалога?

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

2. Информация, введенная пользователем - может хранится информация, введенная пользователем на предыдущем шаге бизнес процесса.

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

Рисунок 4. Использование экземпляров сессионных компонентов без состояния

Жизненный цикл сессионного компонента без сохранения состояния приведен на рис 5.



Рисунок 5. Жизненный цикл сессионных компонентов без состояния

Он состоит лишь из двух состояний:

1. Не сущестует (Does Not Exist) - не создан экземпляр.

2. Пул готовых методов (Method-Ready Pool) - экземпляры компонента перемещаются в пул, как только они становятся нужны контейнеру. На рис. 5. показан последовательное выполнение трех действий. Когда контейнер решает удалить экземпляр из пула, он вызывает метод ejbRemove().

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

Простой сессионный EJB-компонент будет реализовать простые бизнес функции на основе пакета java.math и будет состоять из следующих частей:

§ Класс EJB-компонента

§ Remote-интерфейс

§ Home-интерфейс

Также дополнительно будут созданы

§ Дескрипторе развертывания (deployment descriptor)

§ Клиент, использующий EJB-компонент

§ Build-скрипт для ANT, который будет ответственен за сборку EJB JAR + за запуск развертывание EJB и запуск клиента

Теперь создадим EJB-компонент, используя интегрированную среду разработки Eclipse и сервер приложений JBoss.

Создание проекта и классов EJB-компонента

1. Создаем новый Java проект в рабочем пространстве по умолчанию.

2. В настройках проекта необходимо указать, что он будет использовать библиотеки JBoss. Для этого идем во вкладку Libraries -> Add Library -> User Library. В пользовательских библиотеках создаем новую, называем ее JBoss, подключаем все jar-файлы из JBOSS_HOME\client. Получается библиотека как на рис. 6

Рисунок 6. Пользовательская библиотека JBoss.

3. В проекте создаем два package.

§ ejbs - для создаваемого EJB-компонент

§ clients - для клиентов, которые будут использовать EJB-компонент

4. Создаем Remote Home-интерфейс MathUtilsHomeRemote:

package ejbs;

import javax.ejb.EJBHome;

import java.rmi.RemoteException;

import javax.ejb.CreateException;

/**

* Remote Home интерфейс для MathUtilsEJB

*/

public interface MathUtilsHomeRemote extends EJBHome

{

public MathUtilsRemote create() throws RemoteException, CreateException;

}

В данном случае, Remote Home-интерфейс определяет единственный метод без параметров для создания EJB-компонента удаленными клиентами.

5. Создаем Remote-интерфейс MathUtilsRemote:

/**

* Remote-интерфейс для MathUtilsEJB

*/

public interface MathUtilsRemote extends EJBObject

{

public long add_X_to_Y(long x, long y) throws RemoteException;

public long subtract_X_from_Y(long x, long y) throws RemoteException;

// ... остальные бизнес методы

}

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

В случае какой-либо ошибки выполнения, метод бросает исключение RemoteException.

6. Класс EJB-компонента MathUtilsEJB:

/**

* Stateless session bean MathUtilsEJB

*

*/

public class MathUtilsEJB implements SessionBean

{

// конструктор EJB

public MathUtilsEJB() {}

// метод создания EJB-компонента, инициалия не требуется

public void ejbCreate() {}

// методы javax.ejb.SessionBean

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

public void ejbRemove() throws EJBException, RemoteException {}

public void ejbActivate() { /* не вызывается */ }

public void ejbPassivate() { /* не вызывается */ }

// бизнес-методы компонента

public long add_X_to_Y(long x, long y)

{

return x + y;

}

public long subtract_X_from_Y(long x, long y)

{

return x - y;

}

// остальные бизнес-методы

// ...

}

Класс MathUtilsEJB является основным классом реализации сессионного EJB-компонента, реализует интерфейс javax.ejb.SessionBean. Класс MathUtilsEJB может содержать методы 4х типов:

a. Бизнес методы, которые были определены в Remote-интерфейсе. Сигнатура методов должна полностью совпадать с заявленной в интерфейсе (имя метода, число и типы параметров).

b. Различные варианты метода ejbCreate, которые соотносятся с create методами, определенными в Home-интерфейсе.

c. Методы ejbCreate<Method> соответствуют методам create<Method> в Home-интерфейсе. Сигнатуры методов должны совпадать. Возвращаемое значение может быть только void.

d. В данных методах необходимо произвести всю требуемую инициализацию внутренних объектов, которые требуются бизнес методам компонента.

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

e. Реализация методов интерфейса javax.ejb.SessionBean public interface SessionBean extends EnterpriseBean

{

void setSessionContext(SessionContext sessionContext) throws

EJBException, RemoteException;

void ejbRemove() throws EJBException, RemoteException;

void ejbActivate() throws EJBException, RemoteException;

void ejbPassivate() throws EJBException, RemoteException;

}

Рассмотрим их подробней (в простом stateless EJB они не используются).\

setSessionContext	Контейнер вызывает данный метод перед тем, как вызывать какие-либо другие методы компонента, передавая экземпляру компонента ссылку на объект SessionContext. Компонент может сохранить ссылку, чтобы использовать в дальнейшем.
ejbRemove	Вызывается контейнером.
ejbActivate ejbPassivate	Не вызываются в stateless EJB

f. Вспомогательные методы, используемые только внутри EJB-компонента - являются private-методами.

Создание дескрипторов развертывания EJB-компонента

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

Все XML дескрипторы развертывания помещаются в специальную папку META-INF в jar-файле.

1. Создадим в папке исходных кодов подпапку resources, а в ней еще одну подпапку META-INF.

2. Создаем файл ejb-jar.xml:

<?xml version="1.0"?>

<ejb-jar

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">

<enterprise-beans>

<session>

<ejb-name>MathUtils</ejb-name>

<home>ejbs.MathUtilsHomeRemote</home>

<remote>ejbs.MathUtilsRemote</remote>

<ejb-class>ejbs.MathUtilsEJB</ejb-class>

<session-type>Stateless</session-type>

<transaction-type>Container</transaction-type>

</session>

</enterprise-beans>

</ejb-jar>

Рассмотрим его элементы подробней.

<ejb-jar>	Корневой элемент, определяет также XML namespace и XML schema для валидации дескриптора.
<enterprise-beans>	Список всех EJB в контейнере
<session> / <entity> / <message-driven>	Корневые элементы для session/entity/message-driven EJB-компонентов.
<ejb-name>	Название EJB-компонента
<home>	Полное название Remote Home-интерфейса EJB-компонента
<remote>	Полное название Remote-интерфейса EJB-компонента
<ejb-class>	Полное название класса EJB-компонента
<session-type>	Тип session EJB-компонента: Stateful или Stateless.
<transaction-type>	Тип управления транзакциями: Bean или Container.

3. Там же создаем специфичный для сервера JBoss файл jboss.xml:

<?xml version="1.0"?>

<jboss>

<enterprise-beans>

<session>

<ejb-name>MathUtils</ejb-name>

<jndi-name>MathUtilsHomeRemote</jndi-name>

</session>

</enterprise-beans>

</jboss>

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

Теперь необходимо создать клиента для тестирования EJB-компонента, а также build-файл.

Создание клиента EJB-компонента

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

1. Инициализация JNDI контекста

2. Запрос ссылки на Remote Home-интерфейс по JNDI-имени EJB-компонента.

3. Создание экземпляра компонента

4. Выполнение бизнес методов

Исходный текст клиента:

package clients;

import ejbs.MathUtilsHomeRemote;

import ejbs.MathUtilsRemote;

import javax.naming.InitialContext;

import javax.naming.Context;

import javax.naming.NamingException;

import java.rmi.RemoteException;

import javax.ejb.CreateException;

import javax.rmi.PortableRemoteObject;

/**

* Клиент для MathUtilsEJB

*/

public class MathUtilsClient

{

public static void main(String [] args)

{

try

{

// JNDI контекст

Context jndiContext = getInitialContext();

// Получение ссылки на Remote Home-интерфейс EJB-компонент

Object ref = jndiContext.lookup("MathUtilsHomeRemote");

MathUtilsHomeRemote home = (MathUtilsHomeRemote)

PortableRemoteObject.narrow(ref, MathUtilsHomeRemote.class);

// Создание EJB-компонента

MathUtilsRemote mathUtils = home.create();

// Выполнение бизнес методов

System.out.println("5 + 7 = " + mathUtils.add_X_to_Y(5, 7));

System.out.println("5 ^ 7 = " + mathUtils.raise_X_to_the_Y(5, 7));

}

catch(CreateException ce)

{

ce.printStackTrace();

}

catch(RemoteException re)

{

re.printStackTrace();

}

catch(NamingException ne)

{

ne.printStackTrace();

}

catch(Throwable t)

{

t.printStackTrace();

}

}

static public Context getInitialContext() throws Exception

{

return new InitialContext();

}

}

Для инициализации JNDI контекста следует также создать специальный файл JNDI свойств. Создаем в корне проекта папку jndi, в ней файл jndi.properties следующего содержания:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

java.naming.provider.url=localhost

Создание ANT build файла

Для компиляции, создания EJB-JAR файла и развертывания EJB-контейнера воспользуемся утилитой ANT. ANT поставляется в составе среды Eclipse, таким образом достаточно создать build-файл для него. Создаем в корне проекта файл build.xml. Рассмотрим его по частям, за каждой из которых будет следовать комментарий.

<?xml version="1.0"?>

<project name="ejb_lab01" default="ejbjar" basedir=".">

Корневой элемент содержит имя проекта, цель (target) по умолчанию - это ejbjar, которая определяет создание итогового jar файла. Корневая директория проекта - без изменений.

<property environment="env"/>

<property name="src.dir" value="${basedir}/src/"/>

<property name="src.resources" value="${basedir}/src/resources"/>

<property name="jboss.home" value="${env.JBOSS_HOME}"/>

<property name="build.dir" value="${basedir}/bin"/>

<property name="build.classes.dir" value="${build.dir}/"/>

<property name="jar.name" value="mathutils.jar"/>

Следующая часть файла определяет свойства. Первой строчкой включаются все системные переменные окружения, такие как JBOSS_HOME. Далее определяются директории и имя итогового JAR файла.

<path id="classpath">

<fileset dir="${jboss.home}/client">

<include name="**/*.jar"/>

</fileset>

<pathelement location="${build.classes.dir}"/>

<!-- jndi.properties for InitialContext -->

<pathelement location="${basedir}/jndi"/>

</path>

Здесь прописываются пути к внешним библиотекам (JBoss), классам проекта и файлу свойств JNDI.

<target name="prepare" >

<mkdir dir="${build.dir}"/>

<mkdir dir="${build.classes.dir}"/>

</target>

Подготовка к компиляции - создание директорий.

<target name="compile" depends="prepare">

<javac srcdir="${src.dir}"

destdir="${build.classes.dir}"

debug="on"

deprecation="on"

optimize="off"

includes="**">

<classpath refid="classpath"/>

</javac>

</target>

Компиляция проекта, обратите внимание, что данный target зависит от prepare.

<target name="ejbjar" depends="compile">

<jar jarfile="${build.dir}/${jar.name}">

<fileset dir="${build.classes.dir}">

<include name="ejbs/*.class"/>

</fileset>

<fileset dir="${src.resources}/">

<include name="**/*.xml"/>

</fileset>

</jar>

<copy file="${build.dir}/${jar.name}" todir="${jboss.home}/server/default/deploy"/>

</target>

Основной target файла. Создание JAR-файла, включающего скомпилированные классы, ресурс (дескрипторы развертывания). Развертывание (deploy) на сервере происходит путем простого копирования в папку deploy. Естественно, сервер JBoss при этом должен быть запущен.

<target name="run.client" depends="ejbjar">

<java classname="clients.MathUtilsClient" fork="yes" dir=".">

<classpath refid="classpath"/>

</java>

</target>

Запуск клиента в отдельном потоке.

<target name="clean">

<delete dir="${build.dir}"/>

</target>

Вспомогательный target - удаляет директорию с классами.

Итак, итоговая структура файлов проекта представлена на рис. 7.

Рисунок 7. Структура файлов проекта.

Запуск, отладка и тестирование EJB-компонента

Перед запуском build-файла сервер JBoss должен быть запущен.

Для запуска build-файла, в перспективе Resource выбираем build файл -> 1. Run Ant Build. Происходит выполнение target по умолчанию: компиляция и развертывание. В случае успешного развертывания в консоли JBoss будет сообщение:

[EJBDeployer] Deployed: file:/C:/Java/jboss-

4.0.1sp1/server/default/deploy/mathutils.jar

Для запуска клиента необходимо выбрать дополнительный target: 2. Run Ant Build. Там выбрать run_client.

В случае успешного запуска клиента, в консоли Eclipse увидим:

run.client:

[java] 5 + 7 = 12

[java] 5 ^ 7 = 78125.0

В целях вывода информации для отладки можно создать в EJB-компонента log-функцию, которая будет писать в stdout. Выводимые сообщения будут отображаться в консоли JBoss:

INFO [STDOUT] <текст сообщения>

Теперь настроим удаленную отладку в Eclipse для сервера JBoss. Удаленная отладка основана на JPDA - Java Platform Debugger Architecture.

1. В скрипте запуска JBoss run.bat добавляем строчку

set JAVA_OPTS=-Xdebug -Xnoagent -

Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS%

2. Запускаем сервер

3. В Eclipse создаем новую конфигурацию Debug-Remote Java Application, порт 8787 - рис. 8


Рисунок 8. Настройка удаленной отладки JBoss.

Задание

1. Создать сессионный EJB-компонента без сохранения состояния

2. Реализовать некий набор бизнес методов на основе EJB-компонента

3. Реализовать клиент, тестирующий функциональность EJB-компонента.

4. Создать дескрипторы развертывания, build-файл.

5. Отладить EJB-компонент используя remote debug.

3. Лабораторная работа по EJB #2. Создание сессионного EJB-компонента с сохранением состояния

Предметная область

Создание EJB-компонента, способного оперировать сессией работы на рынке ценных бумаг. Бизнес методы:

§ Покупка акций (параметры - имя покупателя, код акции (“TNKOG”), число акций)

§ Продажа акций (параметры - те же)

§ Получение цены акции (параметры - код акции)

§ Получение баланса для текущей торговой сессии

Результат операции - объект TradeResult:

§ Представляет тип операции: покупка/продажа

§ Число проданных/купленных акций

§ Цена акции

Особенности реализации

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

Структура EJB-компонента остается такой же, как и в лабораторной работе #1:

§ Класс EJB-компонента

§ Remote-интерфейс

§ Home-интерфейс

Т.к. тип EJB-компонента такой же, как в лабораторной работе #1, - сессионный, то многое в реализации совпадает. Отметим отличия.

Жизненный цикл сессионного компонента с сохранения состояния приведен на рис 1.



Рисунок 1. Жизненный цикл сессионных компонентов c состоянием

Он состоит из трех состояний:

1. Не сущестует (Does Not Exist) - не создан экземпляр.

2. Пул готовых методов (Method-Ready Pool) - экземпляры компонента перемещаются в пул, когда клиент вызывает метод create(). На рис. 1. показано последовательное выполнение трех действий. Когда клиент вызывает метод ejbRemove(), экземпляр компонента удаляется. Также он удаляется по таймайту, причем контейнер может, но не обязан вызывать метод ejbRemove(). За время существования, экземпляр несколько раз может пассивироваться (метод ejbPassivate()) и активироваться (ejbActivate()) контейнером.

3. Пассивный (Passive) - компонент перемещается в это состояние контейнером во время неактивности для сохранения ресурсов. При этом сохраняется состояние диалога. Контейнер перед пассивацией вызывает метод ejbPassivate() компонента. Компонент обязан освободить все свои используемые ресурсы, установить несериализуемые поля в null.

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

Классы EJB-компонента

Класс компонента TraderEJB будет содержать следующие члены:

private SessionContext ctx;

private Context environment;

private double tradingBalance;

На вызов методов setSessionContext и ejbCreate, необходимо инициализировать переменные SessionContext и Context:

public void setSessionContext(SessionContext ctx)

{

log("setSessionContext called");

this.ctx = ctx;

}

public void ejbCreate() throws CreateException

{

log("ejbCreate called");

try

{

InitialContext ic = new InitialContext();

environment = (Context) ic.lookup("java:comp/env");

}

catch (NamingException ne)

{

throw new CreateException("Could not look up context");

}

this.tradingBalance = 0.0;

}

Дескрипторы развертывания

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

В данной лабораторной работе будем хранить значения в файле ejb-jar.xml.

<session>

…..

<env-entry>

<env-entry-name>LKOHG</env-entry-name>

<env-entry-type>java.lang.Double</env-entry-type>

<env-entry-value>100.0</env-entry-value>

</env-entry>

<env-entry>

<env-entry-name>TNKOG</env-entry-name>

<env-entry-type>java.lang.Double </env-entry-type>

<env-entry-value>150.0</env-entry-value>

</env-entry>

</session>

<env-entry> описывает свойство окружения, доступное из EJB-компонента следующим образом:

String stockSymbol = “LKOHG”

Double value = (Double)

nvironment.lookup(stockSymbol)).doubleValue();

Также требуется отметить, что EJB-компонент - с сохранением состояния:

<session-type>Stateful</session-type>

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

<assembly-descriptor>

<container-transaction>

<method>

<ejb-name>Trader</ejb-name>

<method-name>*</method-name>

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

Задание

1. Создать сессионный EJB-компонента с сохранением состояния

2. Реализовать набор бизнес методов на основе EJB-компонента

3. Реализовать клиент, тестирующий функциональность EJB-компонента.

4. Создать дескрипторы развертывания, build-файл.

5. Отладить EJB-компонент используя remote debug.

4. Лабораторная работа по EJB #3. Использование JBoss Eclipse IDE для создание EJB-компонентов

В данной лабораторной работе будет показано, как можно использовать специальные средства интеграции сервера JBoss в Eclipse - Jboss Eclipse IDE.

Установка JBoss Eclipse IDE

Возможны два вариант установки в Eclipse:

1. В окне обновлении Eclipse добавляем сайт http://jboss.sourceforge.net/jbosside/updates, выбираем JBoss-IDE 1.0/Eclipse 3.0., стабильную версию (на данный момент 1.4.1). Подробней информация - на сайте JBoss Eclipse IDE.

2. Скачать последнюю стабильную версию с http://www.jboss.com/products/jbosside/downloads. Установка - распаковать и поместить в ECLIPSE_HOME\plugins и ECLIPSE_HOME\features

Использование JBoss Eclipse IDE для создания EJB-компонетов

Теперь новый проект создается: JBoss-IDE > J2EE 1.3 Project. При этом основные библиотеки уже добавляются к проекту, правда они берутся из JBoss Eclipse IDE, а не из директории самого сервера.

Воспользовавшись результатами предыдущей лабораторной работы, создадим такой же проект, только с использованием JBoss Eclipse IDE.

Создаем EJB: File > New > Other > JBoss-IDE > EJB > SessionBean. При создании EJB-компонента сразу указывается его тип: Stateless/Statefull, а также используемые интерфейсы -удаленные и/или локальные - рис. 1.



Рисунок 1. Создание сессионного EJB-компонента.

Для созданного класса, обратите внимание на особый синтаксис JavaDoc перед классом EJB-компонента:

/**

* @ejb.bean name="Trader"

* display-name="Name for Trader"

* description="Description for Trader"

* jndi-name="ejb/Trader"

* type="Stateful"

* view-type="remote"

*/

Данный синтаксис используется утилитой, входящей в состав JBossIDE: XDocklet. XDocklet позволяет упростить написание EJB-компонентов, автоматизируя создание вспомогательных интерфейсов EJB-компонента и дескрипторов развертывания.

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

Для добавления элементов <env-entry>, применяется синтаксис:

@ejb.env-entry name="LKOHG" type="java.lang.Double" value="100.0"

Для добавления бизнес методов можно выбрав в иерархии классов класс EJB-компонента и использовать из контекстного меню J2EE > Add Business Method. Возможно сразу указать все параметры метода, исключения и возвращаемый результат - рис. 2.



Рисунок 2. Добавление бизнес-метода EJB-компонента.

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

Теперь сгенерируем сопутствующие EJB интерфейсы и дескрипторы. Для этого настроим конфигурации XDocklet.

В свойствах проекта добавляем новую конфигурацию XDocklet, добавляем ejbdoclet,

§ destDir = src

§ ejbSpec = 2.0

К ejbdoclet добавляем fileset

§ dir = src

§ include = **/*.java

К ejbdoclet добавляем deploymentdescriptor

§ destDir = src/META-INF.

К ejbdoclet добавляем jboss

§ destDir = src/META-INF.

§ Version = 4.0

К ejbdoclet добавляем packageSubstitution. Сгенерированные интерфейсы будут помещены в package interfaces.

§ packages = ejbs

§ substituteWith = interfaces

К ejbdoclet добавляем homeinterface, remoteinterface.

В итоге получаем следующую конфигурацию - рис. 3.

Рисунок 3. Конфигурация XDoclet.

Проверка конфигурации: Run XDoclet. Результаты запуска - в консоли. Сгенерированные файлы появятся в структуре файлов проекта.

Используя средства JBossIDE для упаковки различных архивов. Нас интересуют два типа:

§ EJB JAR - EJB-классы и интерфейсы

§ EJB Client JAR - EJB-интерфейсы, для использования клиентами.

EJB JAR

В свойствах проекта: Packaging > Add archive. Потом для созданного архива - Add Folder, выбираем bin папку проекта, однако указывая includes rsoi/ejbs/*.class и rsoi/interfaces/*.class, чтобы включить только классы ejbs. Добавляем в архив файлы проекта ejb-jar.xml, jboss.xml с префиксом META-INF.

EJB ClientJAR

Аналогично, включая в архив только классы из rsoi.interfaces.

После создания всех конфигураций, можно вызываеть Run XDoclet, Run packaging.

В итоге получаем следующую структуру файлов проекта - рис. 4.

Рисунок 4. Структура файлов проекта.

Использование JBoss Eclipse IDE для развертывания и отладки EJB-компонетов

Добавляем новую Debug конфигурацию для JBoss 4.0.x, указывая корневую директорию для сервера JBoss. Во вкладке source добавляем Java project текущей лабораторной работы.

Успешный запуск сервера в режиме Debug показывает, что настройки сервера верны.

После запуска сервера можно сделать deploy EJB-компонента на сервер JBoss. Настройки Deployment: Window > Preferences > JBoss-IDE > Deployer. Однако, по умолчанию не требуется изменений.

Выбрав файл TraderEJB.jar, Deployment > Deploy To. Выбрав сервер, результат операции отображается в консоли JBoss в Eclipse.

Литература и дополнительные источники информации

1. Richard Monson-Haefel. Enterprise JavaBeans (4^th edition., 2004, O'Reilly).

2. Ричард Монсон-Хейфел. Enterpris Java Beans. (3^rd edition, С.-Пб., «Символ», 2002)

3. Vlada Matena and oth. Applying Enterprise JavaBeans. (1^st edition, 2003, Addison Wesley).

4. Benjamin G. Sullins - EJBCookBook (2003, Manning).

5. http://www.jboss.com/

6. http://jakarta.apache.org/ant/index.html

7. http://www.jboss.com/products/jbosside/downloads