Integration and Messaging


Integration Approaches

Hohpe and Woolf’s Enterprise Integration Patterns describes four methods of integrating applications:

File Transfer Have each application produce files of shared data for others to consume. Communication might be done using shared volumes or file transfer protocol.
Shared Database Have applications store the data they wish to share in a common database.
Remote Procedure Invocation Have each application expose some of its procedures so that they can be invoked remotely. Approaches may be object oriented (RMI or CORBA) or not (SOAP, xml-rpc, or REST).
Messaging Have each application connect to a common messaging system and exchange message objects. Messaging may be synchronous or asynchronous.

For remote procedures and messaging, there are different protocols available:


Communication for web pages. Each request contains a method (GET, POST, HEAD, etc) and a URI address. Response may be multi-part MIME data.

This protocol is typically stateless, but state can be simulated using cookies or URL rewriting.

Web communications often have fewer firewall restrictions than other protocols, so HTTP sometimes provides an end-run around oppressive security policies.


HTTP but running over an SSL transport, which prevents eavesdropping between client and server. Also supports authentication of server, and sometimes client.

SSL connections are stateful, so HTTPS can support sessions without cookies or URL rewriting.


Communication protocol used by CORBA to call methods on remote objects.

CORBA services support security and transactions.

IIOP supports tunneling over HTTP/port 80.


Native transport protocol of RMI. Used to invoke methods on remote objects. RMI is the default communication mode for Enterprise JavaBeans, but it is recommended to use RMI over IIOP instead.

JRMP supports tunneling over HTTP/port 80.


Web services

Web services via SOAP or XML-RPC support remote procedure call integrations. The most common transport protocols are HTTP or HTTPS, but most toolkits support other transports, such as mail, JMS, jabber, or in-memory communication.

SOAP interfaces are defined by WSDL documents. Communicating systems do not need to share class files, as with RMI. Web services are good for communicating between totally different technologies. Java can easily communicate with perl, PHP, C, C#, etc.

Web services are typically slower than other mechanisms, so the recommended practice is to use course-grained calls. Web services are not as object-oriented as RMI or CORBA. There is no built-in support for transactions or sessions.

The JEE standard for SOAP web services is JAX-WS. Web services can be defined in code first (using standard annotations) or WSDL first (with annotated code generated during the build). Any stateless session bean can be deployed as a JAX-WS web service. JAX-WS supports both SOAP 1.1 and SOAP 1.2.


Java Connector Architecture (JCA)

The JCA is a standard for integrating between JEE application servers and 3rd party applications. Most commonly, JCA is used to support Java Messaging to external message queuing systems, so messages can flow transparently between JEE and non-java MQ systems. JCA adapters can connect to other systems, such as SAP or CICS.

JCA adapters are packaged in RAR files. If a vendor provides a JCA adapter, then that adapter can be used with any JEE application server.

The adapter interfaces directly to the application server to support minimal standards for connection management, transaction management, and security.

Applications within the application server interface with the adapter using a client API. Typically, the API will conform to the Common Client Interface (CCI). Using the CCI is similar to using stored procedures within JDBC.


Java Messaging Service (JMS)

JMS is a standard for doing enterprise messaging. Messaging may be synchronous or asynchronous. It can be transactional or non-transactional. Messages may be persistent or not. Messaging patterns are either point-to-point or publish and subscribe.

With point-to-point messaging, one or more message producers send messages to a named Queue. Then, one or more message consumers take messages off the Queue to process them.

In the publish and subscribe pattern, message producers send messages to a named Topic. The queuing system then transports copies of the message to all running subscribers. Message consumers may register themselves as having a “durable subscription”, meaning that they want the message even if they are not currently on line. The queuing system will hold a copy of the message until the durable subscriber connects.

Object Description
ConnectionFactory Encapsulates the creation of Connection objects, either for Queues or Topics. The ConnectionFactory is typically retrieved using JNDI. Factories retrieved will be either QueueConnectionFactory or TopicConnectionFactory. ConnectionFactories are thread-safe.
Destination Encapsulates an address where messages are sent or retrieved. Destinations are named, but are typically retrieved using JNDI. Destinations will be either a Queue or a Topic. Destinations are thread-safe.
Connection Represents an open connection from a client to the JMS provider. A Connection is a heavyweight object, and may be expensive to create and destroy, so a client will usually use just one Connection for its whole lifespan. A Connection can start and stop receipt of messages, and is used to create new Session objects. A Connection will be either a QueueConnection or a TopicConnection. Connections are thread-safe objects.
Session A single-threaded context for producing and receiving messages. Sessions are used to create messages, consumers, producers, temporary Queues and Topics. They are used to commit or rollback transactions. There are QueueSessions and TopicSessions. Sessions are not thread-safe.
Message The primary object for communication. Subtypes are TextMessage, ObjectMessage, StreamMessage, BytesMessage, and MapMessage. A Message may be persistent, or non-persistent.
MessageProducer Objects for sending Messages to a specific Destination. Producers are created using a Session object. MessageProducers are not thread-safe.
MessageConsumer Objects for retrieving Messages from a specific Destination. Consumers are created using a Session object. MessageConsumers are not thread-safe.
MessageListener An interface for client objects that receive Messages asynchronously. One MessageListener may be attached to a MessageConsumer. Message Driven Beans will usually implement MessageListener.
ExceptionListener An interface for client objects that handle errors during asynchronous message processing. The ExceptionListener is attached to a Connection object.
%d bloggers like this: