25. Message Driven Beans (mdb), жизненный цикл компонентов. Особенности разработки, применения и функционирования mdb, реализующие методы (примеры разработки клиента и серверной части). Настя

Бин, управляемый сообщениями (MDB), - это бин, который позволяет приложениям J2EE асинхронно обрабатывать сообщения. Он действует, как слушатель сообщений JMS, который подобен слушателю событий, за исключением того, что вместо событий, он принимает сообщения. MDB может обрабатывать JMS сообщения или другие виды сообщений.

Отличия mdb:

· MDB не сохраняют состояния клиента;

· Все MDB равноправны, т.е. EJB контейнер может присвоить сообщение любому бину, управляемому сообщениями;

· Один MDB может обрабатывать сообщения от множества клиентов;

Сообщения могут отправляться любым компонентом J2EE - клиентским приложением, другим корпоративным бином или Web-компонентом - или при помощи приложения JMS или системы, которая не использует технологию J2EE.

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

MDB – это просто MessageListener: класс реализует javax.ejb.MessageDrivenBean и javax.jms.MessageListener.

Первый интерфейс имеет два метода: setMessageDrivenContext и ejbRemove.

Второй интерфейс имеет один метод onMessage. Именно в методе onMessage() выполняется вся прикладная логика. Спецификация требует также создания метода ejbCreate без параметров.

Клиент не создает объектов MDB. Контейнер сам решит, когда и сколько ему требуется MDB для обработки сообщений из данного destination (в данном случае это: либо queue, либо topic – в зависимости от используемой модели: javax.jms.Queue или javax.jms.Topic).

Метод setMessageDrivenContext() класса ReservationProcessorBean устанавливает поле экземпляра ejbContext в значение MessageDrivenContext, которое было передано в метод. Кроме этого он получает ссылку на JNDI ENC, которую сохраняет в jndiContext. MDB может иметь поля экземпляра, похожие на поля экземпляра сеансового компонента без состояния. Значения этих полей сохраняются в экземпляре MDB в течение всей его жизни и могут многократно использоваться каждый раз, когда он обрабатывает новое сообщение. В отличие от сеансовых компонентов с состоянием, у MDB нет состояния диалога, и они не предназначаются для одного клиента JMS. Экземпляры MDB применяются для обработки сообщений от нескольких разных клиентов JMS и связаны не с клиентом, а с определенной темой или очередью, от которых они принимают сообщения.

Жизненный цикл экземпляра MDB имеет два состояния: «не существует» и «пул готовых методов». Пул готовых методов похож на пул экземпляров, используемый для сеансовых компонентов без состояния. Некоторые производители могут не использовать пул для MDB экземпляров, а вместо этого создавать и уничтожать экземпляры для каждого нового сообщения. Когда сообщение направлено экземпляру контейнером, MessageDrivenContext экземпляра MDB изменяется, чтобы отразить новый контекст транзакции. Экземпляр, закончивший обработку, сразу же становится доступным для обработки нового сообщения. Экземпляры компонентов переводятся из пула готовых методов в состояние «не существует», когда они становятся ненужными серверу. Это происходит, когда сервер принимает решение уменьшить общий размер пула готовых методов, удаляя из памяти один или несколько экземпляров. Этот процесс начинается с вызова метода ejbRemove() экземпляра.

@MessageDriven(

//имя topic, на который подписан бин

mappedName="jms/TutorialTopic",

name = "ExampleMDB")

public class MDBExample implements MessageListener{

//метод, вызываемый при получении нового сообщения

@Override

public void onMessage(Message msg) {

try {

TextMessage message = (TextMessage)msg;

//считываем свойство из соответствующего поля, заданное вручную в consumer

System.out.println("FROM MDB - client type IS " + message.getStringProperty("clientType"));

//считываем само сообщение

System.out.println("FROM MDB - payload IS" + message.getText());

} catch (JMSException ex) {

ex.printStackTrace();

}

}

26. EJB-сервер и EJB-контейнер. Роль и использование в приложениях интерфейсов EJBHome и EJBObject. Упрощения модели программирования EJB 3Х. Особенности реализации EJB версии 3Х. ПОЛИНА

Существуют также интерфейсы EJBHome и EJBObject, который вы используете как базовый интерфейс, когда определяете собственное представление компонента (если оно вам нужно) - по этой причине EJBHome и EJBObject наследуются от интерфейса Remote RMI. Оставшиеся два интерфейса, EJBLocalHome и EJBLocalObject, вы используете для предоставления локального представления вашего компонента (опять таки, предполагается, что вам нужно это локальное представление)

Home-интерфейс и Home-объект

Когда у клиента EJB возникает потребность воспользоваться услугами EJB, он с помощью home-интерфейса создаёт EJB. Клиент использует один из методов create(), которые определяет home-интерфейс. Реализация home-интерфейса осуществляется с помощью объекта, называющегося home-объектом. Экземпляр такого home-объекта создаётся на сервере и в качестве factory (построителя) предоставляется клиенту для создания бина.

Интерфейс Time Home (реализация интерфейса Home)

public interface TimeHome extends EJBHome

{ //поля:

public static final String COMP_NAME= «java:comp/env/ejb/Time»;

public static final String JNDI_NAME= «Time»;

// create - методы

public Time create () throws CreateException,RemoteException;}

Home interface

У каждой EJB-компоненты есть то, что называют ``родной интерфейс'' (home interface), который определяет методы создания, инициализации, удаления и (в случае entity beans) поиска экземпляров EJB-компонент на стороне сервера. ``Родной интерфейс'', по сути, описывает возможные взаимодействия между компонентой и контейнером, а конкретно -- описанные выше.

``Родной интерфейс'' для EJB-компоненты наследуется от интерфейса javax.ejb.EJBHome, который представляет базовую функциональность для взаимодействия между контейнером и компонентой. Все методы этого интерфейса должны быть RMI-совместимы. Интерфейс также описывает один или более create() методов, которые все называются ключевым словом create, но тело которых различно. Все create методы возвращают объект с ``внешним'' (remote) для данной компоненты интерфейсом.

EJBObject

EJBObject - это видимый в сети объект с собственной структурой и наполнением, действующий как proxy бина. Имеющийся у бина remote-интерфейс расширяет интерфейс javax.ejb.EJBObject, делая таким образом класс EJBObject специфическим для данного класса бина. Для каждого бина EJB существует стандартный класс EJBObject.

Корпоративные компоненты, записанные EJB 3.0 и более поздним API, не требуют удаленного интерфейса, который расширяет интерфейс EJBObject. Удаленный деловой интерфейс может использоваться вместо этого.

Единственное требование такое: этот интерфейс наследуется от javax.ejb.EJBObject и все его методы выбрасывают RemoteException.

public interface Movie extends EJBObject {

public Integer getId () throws RemoteException;

}