Patterns: Implementing Self-Service in an SOA Environment

Chapter 6. Technology options 133

򐂰 Outbound adapters

Outbound adapters are used by application initiated requests to an EIS.

򐂰 Inbound adapters

Inbound adapters are used by the EIS making calls to a message-driven

bean.

The J2EE Connector Architecture provides a Common Client Interface API (CCI)

with both common, and resource adapter specific, interfaces. Application

programmers code to this single API rather than needing to use different

interfaces for each proprietary system. However it is common for a resource

adapter to make use of its own, or an existing API, such as JDBC or JMS.

The J2EE Connector Architecture specification provides support for transactions,

security and sharing of connections between different clients.

Advantages of the J2EE Connector Architecture

Some reasons to use J2EE Connector Architecture resource adapters are:

򐂰 The CCI simplifies application integration with diverse EISs. This common

interface makes it easy to plug third-party or home-grown resource adapters

into your applications.

򐂰 Inbound adapters provide a way to get a message-driven bean invoked when

an event occurs in the EIS. For example, a message arrives at a JMS

destination.

򐂰 Outbound adapters that are XA capable automatically participate in any

transactions in effect without requiring action by an application.

򐂰 Outbound adapters can pick up security credentials from the container in

which they execute.

򐂰 Connections to the EIS can be shared to reduce resource overhead.

Disadvantages of the J2EE Connector Architecture

Although the CCI provides a common interface definition, some resource adapter

specific interfaces still need to be used and the usage of these interfaces varies

depending on the EIS the resource adapter used.

6.4.3 Java Message Service

Messaging middleware is a popular choice for accessing existing enterprise

systems in an asynchronous manner. It is one of the options if you are

implementing a solution based on the Directly Integrated Single Channel

application pattern.

134 Patterns: Implementing Self-Service in an SOA Environment

A standard way for using messaging middleware from a Java application is using

the Java Message Service (JMS) interface. JMS offers Java programmers a

common way to create, send, receive and read enterprise messages. The JMS

specification was developed by Sun Microsystems with the active involvement of

IBM, other enterprise messaging vendors, transaction processing vendors, and

RDBMS vendors.

In IBM WebSphere Application Server V6.0, the J2EE 1.4 specification is

implemented, which includes JMS 1.1 and EJB 2.1.

According to the JMS 1.1 specification, a message provider is integrated in an

application server. As shown in Figure 6-5, the integrated message provider

makes it possible to communicate asynchronously with other WebSphere

applications, without installing separate messaging software such as IBM

WebSphere MQ. WebSphere’s integrated JMS server is based on IBM

WebSphere MQ.

Figure 6-5 Integrated JMS provider

An important feature of EJB 2.1 is message-driven beans (MDB). As described in

6.3.9, “Enterprise JavaBeans” on page 124, message-driven beans are designed

specifically to handle incoming JMS messages.

What is messaging?

Messaging is a form of communication between two or more software

applications or components. One strength of messaging is application

integration. Messaging communication is

loosely coupled, as compared to tightly

coupled technologies such as Remote Method Invocation (RMI) or Remote

Procedure Calls (RPC). The sender does not need to know anything about the

J2EE ServerJ2EE Server

Message

PUT

Message

GET

J2EE Application

Web

Message

GET

Message

PUT

J2EE Application

Web