Статья: Сервер приложений & JavaBeans
6. JDBC — предлагает драйверы для подключения к базам данных, ведь именно серверу приложений придется общаться с БД и ему нужно уметь подключаться к используемой в вашей компании базе;
7. Java Mail — предоставляет сервис к SMTP;
8. JMS (Java Messaging Service) — обработка синхронных и асинхронных сообщений;
9. RMI (Remote Method Invocation) — вызов удаленных процедур.
Это основные блоки, которые может предоставлять тот или иной сервер приложений. Кроме того, каждый из них должен реализовывать саму спецификацию J2EE, дабы он мог работать с компонентами Enterprise JavaBeans. Для этого в сервере приложений необходим EJB-контейнер, который и отвечает за выполнение компонентов.
Компоненты EJB
Нередко те, кто малознаком с Enterprise JavaBeans, неверно понимают смысл этих компонентов. Дело в том, что классические JavaBeans-компоненты используются для визуального построения в клиентских приложениях. Enterprise JavaBeans вызываются клиентом, но работают на сервере приложений, где нет визуального интерфейса, а значит, такие компоненты не визуальны. Существует 2 типа EJB компонентов — session и entity. Первый не рассчитан на долговременное хранение состояния JavaBeans. Состояние сбрасывается при создании каждой новой сессии. Второй тип (entity) может сохранять состояние между запусками. Сессионные компоненты удобны при создании таких механизмов, как корзина заказа или управление контентом, и при этом очень редко используются изолированно. Чаще всего session-компоненты работают совместно с entity.
Для работы EJB-компонента необходимо создать три класса:
1. Класс, реализующий работу самого компонента;
2. HomeObject—используется для поиска и при необходимости создания/удаления компонентов$;
3. EJBObject—объект, через который клиент получает информацию о доступных в компоненте EJB методах.
Создание EJB
Чтобы закрепить на практике вышесказанное, давайте напишем небольшой сессионный EJB компонент. Для этого нам нужно будет написать три класса:
1. Сам компонент, назовем его класс EJBExampleBean;
2. HomeObject, назовем его EJBExampleHome;
3. EJBObject, назовем его EJBExample.
Каждый класс будет реализовываться в отдельном файле, и я думаю, что не нужно сообщать имена файлов. Как и в J2SE, имя должно соответствовать имени основного класса плюс расширение .Java. Все три класса поместим в пакет ru.itspec.ejbexamp, потому что классы без пакетов—плохой тон в программировании. Помимо этого все три файла будут импортировать следующие пакеты:
import javax.ejb.*; import java.util.*; import java.rmi.*;
Это и все, что есть идентичного во всех трех файлах. Теперь перейдем к рассмотрению особенностей каждого класса.
Код компонента
Начнем с самого большого класса, его код вы можете увидеть во врезке. Класс для EJB-компонента должен реализовывать интерфейс SessionBean. Этот интерфейс определяет следующие методы: ejbRemove, ejbActivate, ejbPassivate и setSessionContext, a значит, они должны быть реализованы нашим классом.
Метод setSessionContext вызывается одним из первых при создании компонента сессии. Как минимум, здесь необходимо сохранить в качестве параметра контекст сессии (он имеет тип SessionContext), он обязательно понадобится в более сложных компонентах. Сейчас же мы рассматриваем пустышку, которая может стать шаблоном для ваших более сложных компонентов. Для хранения контекста в самой первой строке объявления класса объявляется переменная sessionContext:
SessionContext sessionContext;
Коммуникации
Реализация Enterprise JavaBeans на все 100% соответствует концепции ООП, а компонент этот является самым настоящим черным ящиком. Программист, который будет применять его в своем клиентском приложении, не обязан и даже не должен иметь при себе исходный код используемого EJB. Он даже не будет знать, как там все устроено и реализовано, главное, чтобы клиентская программа получала нужный результат. Если вы работали с ActiveX от MS, то знаете, что там используется примерно такой же подход из трех уровней: СОМ клиент->интерфейс->СОМ-сервер. Разработчик клиента видит только интерфейс, в котором описываются доступные ему методы, и абсолютно не знает, как реализован СОМ-сервер. Всю сложность серверного компонента прячут классы HomeObject и EJBObject. Первый из них вы предоставляете для того, чтобы клиентское приложение могло найти и создать ваш EJB. Его код выглядит следующим образом:
package com.itspec.ejbexamp;
import javax.ejb.*; import java.util.*; import java.rmi.*;
public interface EJBExampleHome extends javax.ejb.EJBHome {
public EJBExampleHome createO throws CreateException, RemoteException;
Класс происходит от EJBObject и объявляет один единственный конструктор. Для простого компонента этого вполне достаточно. В более сложных компонентах вы можете реализовать несколько вариантов конструкторов с различным количеством передаваемых параметров.
И последний класс EJBObject для нашего примера будет выглядеть так:
package com.itspec.ejbexamp;
import javax.ejb.*; import java.util.*; import java.rmi.*;