Производитель MDB должен предоставить класс реализации компонента, управляемого сообщениями. Этот класс должен реализовывать, прямо или косвенно, интерфейс javax.ejb.MessageDrivenBean и интерфейс получателя запросов. Эти аспекты реализации MDB рассматриваются в следующих разделах.
Интерфейс MessageDrivenBean
Интерфейс javax.ejb.MessageDrivenBean определяет несколько методов обратного вызова, которые позволяют EJB-контейнеру управлять жизненным циклом каждого экземпляра компонента, управляемого сообщениями. Поскольку MDB-компоненты не раскрывают домашних или компонентных интерфейсов, в интерфейсе javax.ejb. MessageDrivenBean определено меньшее количество методов обратного вызова, чем в соответствующих интерфейсах javax.ejb.SessionBean и java.ejb.EntityBean. Определение интерфейса javax.ejb.MessageDrivenBean показано в примере 8.15.
Пример 8.15. Интерфейс javax.ejb.MessageDrivenBean
public interface MessageDrivenBean extends javax.ejb.EnterpriseBean {
public void setMessageDrivenContext(MessageDrivenContext ctx); public void ejbRemove();
}
Назначение каждого из методов обратного вызова описывается ниже.
• SetMessageDrivenContext.
Данный метод вызывается EJB-контейнером для связывания контекста с экземпляром компонента, управляемого сообщениями. Экземпляр MDB хранит ссылку на этот контекст в составе информации о своем состоянии.
• EjbRemove.
Данный метод вызывается EJB-контейнером для уведомления экземпляра MDB о том, что выполняется его удаление. Это дает MDB возможность освободить ресурсы, которые он может использовать.
Интерфейс (обработчика) слушателя сообщений
Как говорилось в разделе 8.4.1, «Типы компонентов, управляемых сообщениями», версия 2.1 спецификации EJB более не требует, чтобы MDB-компонент реализовывал интерфейс javax.jms.MessageListener. В спецификации просто говорится, что компонент, управляемый сообщениями, должен реализовывать интерфейс получателя запросов, соответствующий типу обмена сообщениями, который поддерживает MDB.
Спецификация также позволяет определить в интерфейсе получателя запросов несколько методов, и указать для этих методов возвращаемые типы. Если провайдер системы обмена сообщениями определяет интерфейс, содержащий несколько методов получателя запросов, то адаптер ресурсов определяет, какой из этих методов нужно вызывать при получении сообщения.
Интерфейс получателя запросов для компонентов, управляемых JMS-сообщениями, называется javax.jms.MessageListener, и он показан в примере 8.7.
В качестве примера другого типа интерфейса получателя запросов, который может использоваться провайдерами систем обмена сообщениями, рассмотрим теоретический провайдер JAXM. JAXM-провайдер системы обмена сообщениями может решить использовать в качестве интерфейса получателя запросов интерфейс javax. xml.messaging.ReqRespListener. Этот интерфейс показан в примере 8.16.
Пример 8.16. Интерфейс javax.xml.messa ging.ReqRes pListene r
package javax.xml.messaging;
import javax.xml.soap.SOAPMessage;
public interface ReqRespListener {
public SOAPMessage onMessage(SOAPMessage message);
}
Обратите внимание, что этот интерфейс сходен с интерфейсом javax.jms. MessageListener тем, что в нем определен метод onMessage. Однако при определении методов интерфейса получателя запросов можно использовать любые имена.
Также обратите внимание, что в методе onMessage указывается возвращаемый тип SOAPMessage. Можно рассматривать это сообщение SOAPMessage как ответное сообщение. Однако поскольку метод onMessage вызывал EJB-контейнер, то значение SOAPMessage будет возвращено EJB-контейнеру. В спецификации EJB говорится, что если интерфейс получателя запросов поддерживает такую схему запрос-ответ, то за доставку сообщения-ответа адаптеру ресурсов отвечает EJB-контейнер.
Метод ejbCreate
Еще одно требование, предъявляемое к классу, реализующему компонент, управляемый сообщениями, заключается в реализации метода ejbCreate. И снова, реализация может быть определена в самом классе MDB-компонента или же в любом из его родительских классов. EJB-контейнер вызывает метод ejbCreate на последнем этапе создания нового экземпляра MDB. Это дает возможность выделить для MDB необходимые ему ресурсы.
