To the connector-based Message-Driven Bean

Jul 28 posted in Java (RSS), comments.

Although JMS-based MDB have proved very useful, it also has limitations. Perhaps the biggest constraint on the
EJB provider is to support only one or a small number of JMS providers (usually only one). EJB2.1 in front of
Most manufacturers only support their own JMS provider, and no other. It is clear that such restrictions
Is your choice: If your company or part of the company's use of a JMS provider, it will not be provided by EJB
Business support, you will not be able to deal with JMS providers of information transfer over.

Bypassing the JMS channel routing messages from one JMS provider to another, this is a EJB specification

Outside of a customary solution.
The nature of the problem is complex and requires management of the affairs of an in-depth understanding. In short, for the MDB,
JMS provider message was delivered to the MDB, and the work of all MDB implementation (for example, the use of JDBC, call their
Bean on his way, and so on), must be part of the same matter, the EJB container to initialize. This requires
EJB containers prior to coming to know the information transmitted in the information in fact be delivered before the beginning of it
Rationale. Unfortunately, JMS API does not support this function. Therefore, in the EJB in the early, JMS, who must provide
Each EJB to be implementation and integration of custom manufacturers. Integration is the high cost of (business), all the old
Generally select a few EJB2.0 integration of JMS providers.
Another JMS-based MDB model restrictions are restrictions on JMS; no other information systems support.
Although JMS is very useful, but it is not the only information system available. SOAP, Email, CORBA news
ERP system for all information systems (SAP, PeopleSoft, etc.) left over from the news system,
Such as other non-JMS messaging system.
EJB 3.0 (and 2.1) support the expansion of more open definition of message-driven Bean, allowing them to service any
Types of information systems from any vendor. The only requirement is that new types of message-driven Bean drive attached message
Bean's life cycle activities. EJB vendors to build code to support new information systems (some other JMS),
However, they will certainly need to support any JCA 1.5-based Message-Driven Bean.
JCA provides a standard server interface (SPI) to allow any of the IES system inserted into the J2EE container.
Connector structure is only applied to version 1.0 request / response resources, J2EE components (EJB or servlet / Jsp)
Initialization request. The current version is 1.5, the requirements j2EE1.4 or higher, more comprehensive and can be opened for any
The asynchronous messaging system. In this tired systems, J2EE components awaiting the arrival of news, instead of cross-initialization
Each other with the EIS; EIS initialization will be separated from each other through messages.
A clear definition of a message JCA1.5 contract with the Message-Driven Bean connection. It is the definition of an EJB container and
An asynchronous connection, so message-driven Bean can automatically deal with information from the EIS's. MDB to an asynchronous
Connection based on the achievement of a specified interface definition of news through its own connector. Instead of the realization of
javax.jms.MessageListener interface. MDB to achieve a number of other types of interfaces assigned to EIS. For example,
Chapter III described a hypothetical e-mail connection, to allow a similar deal to MDB-based JMS consumer JMS
Income. E-mail connector X to buy from manufacturers and pass a JAR file is called a resource file
(RAR). RAR contains all the connection code and the necessary deployment descriptors to EJB container system implantation.
It also defines the use of developers used to create an e-mail the MDB interface requirements. This is a fake
E-mail message based interface, he must achieve an e-mail the MDB:
package com.vendorx.email;
public interface EmailListener
(
public void onMessage (javax.mail.Message message);
)
Bean class implements this interface, the connector is responsible for handling e-mail message delivery. The following code shows
The realization of a MDB interface and processing EmailListener E-mail:
package com.titan.email;
@ MessageDriven (activationConfig = (
@ ActivationConfigProperty (
propertyName = "mailServer",
propertyValue = "mail.ispx.com"),
@ ActivationConfigProperty (
propertyName = "serverType",
propertyValue = "POP3"),
@ ActivationConfigProperty (
propertyName = "messageFilter",
propertyValue = "to = 'submit@titan.com'")})
public class EmailBean implements com.vendorx.email.EmailListener (
public void onMessage (javax.mail.Message message) (
javax.mail.internet.MimeMessage msg =
(javax.mail.internet.MimeMessage) message;
Address [] addresses = msg.getFrom ();
/ / Continue processing Email message
)
)
In this example, the container calls onMessage () send a JavaMail Message object, the representatives of
Email message contains a MIME annex. However, the message interface connector through the use of the MDB-based not
The use of onMessage (). Methods and method signatures can be an appropriate EIS; It can even have a return type.
For example, a connector for the development of processing SOAP request / response form of message. This connector can
ReqRespListener with the definition of XML messages through the message API from Java API.SOAP formulated sun, it does not
J2EE platform is part of:
package javax.xml.messaging;
import javax.xml.soap.SOAPMessage;
public interface ReqRespListener (
public SOAPMessage onMessage (SOAPMessage message);
)
In this interface, onMessage () there is a type of return values SOAPMessage. This means EJB container
And connectors is responsible for the coordination of response information back to the sender. (Or some defined in the deployment descriptor of the head
Land). In addition to supporting the signals in different ways, the message then there may be a number of methods to deal with different types of
Information using the same MDB. New Message-Driven Bean unlimited support by EJB container system. Really good
The connector is based leap MDB completed a number of EJB vendors, as the provider of all necessary support
Them. If the connector is based on the use of the MDB with the provider A and after the provider you want to change to B, you can
To continue to use the same connector-based MDB, no problem.
The activities of configuration properties using non-MDB-based JMS connector types and rely on these requests. Let us look at a
Examples:
@ MessageDriven (activationConfig = (
@ ActivationConfigProperty (
propertyName = "mailServer",
propertyValue = "mail.ispx.com"),
@ ActivationConfigProperty (
propertyName = "serverType",
propertyValue = "POP3"),
@ ActivationConfigProperty (
propertyName = "messageFilter",
propertyValue = "to = 'submit@titan.com'")})
We talked about in front of the @ ActivationConfigProperty. As you see in front of the case, he was appointed
He name / value on this meta-data support, therefore, it can be easily configured to support the designated e-mail
For this connector type.