This article discusses an implementation strategy that illustrates how organizations can use JMS and J2EE Connector technologies to reuse their infrastructure and lay a foundation that will let them reap the business and agility benefits of SOA.

For a Service Oriented Architecture (SOA) to be truly resilient, asynchrony must be built into its fabric. Most large organizations, however, have already invested in a back-end messaging infrastructure using products such as MQ Series, Tibco JMS, Oracle Advanced Queuing, Sonic JMS, or SwiftMQ. They don't want to replace that infrastructure to get to SOA; they want to reuse it. Enter J2EE 1.4 with two key technologies to enable Web Services and messaging infrastructure reuse: JAX-RPC, the built-in interoperability-tested J2EE API for building SOAP-based Web Services; and the J2EE Connector Architecture, now designed to support both inbound and outbound communications from Enterprise Information Systems.

Let's start with an overview of the related technologies, such as J2EE Connector Architecture (JCA), Java Messaging Service (JMS), Web Services, and Java API for XML Remote Procedure Calls (JAX-RPC). Then I'll present our implementation strategy and use a sample application to show how it works in detail.

J2EE Connector Architecture

JCA is a required J2EE 1.4 API. It defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (EISs) such as ERP systems, mainframe transaction processing systems, relational database systems, or JMS providers.

JCA defines system-level contracts that encapsulate important requirements for effective, scalable integration with EISs, such as connection pooling and transaction management.

The EIS side of these system-level contracts is implemented in a resource adapter, a system-level software driver that's used by an application server or a client to communicate and operate with an EIS. While a resource adapter is specific to the EIS it represents, it's not specific to a particular application server and can therefore be reused across any J2EE application server.

Java Messaging Service

JMS is a J2EE API for Java messaging clients. It provides two programming models: point-to-point and publish-subscribe. In the point-to-point model, one sender puts a message in a queue and it's delivered only to one receiver. The publish-subscribe model adds a broadcast mode in which any number of publishers can add messages to a topic, and any number of subscribers gets all the messages posted to the topics they subscribe to. JMS queues and topics are bound to a JNDI environment and made available to J2EE applications.

Web Services and JAX-RPC

Web Services are a set of Internet-standard messaging protocols, programming standards, and network registration and discovery facilities that expose business applications to other services and clients over the Internet in an interoperable fashion using XML messaging standards.

An important development in the J2EE community has been the standardization of the Web Services API in the J2EE platform with J2EE 1.4. The primary design intent of this standardization has been the natural adoption of the supported Web Services so that SOAs can take full advantage of the foundation provided by J2EE 1.4.

Web Services in J2EE 1.4 build on the underlying J2EE platform by adding the core standards SOAP and Web Service Description Language (WSDL) as first-class citizens. For J2EE developers, Web Services aren't a new concept but an effortless extension to the programming model they've been using for years.

The Web Services support in J2EE 1.4 encompasses the following major standards: JAX-RPC 1.1, SAAJ (SOAP Attachments API for Java) 1.2, Enterprise Web services for J2EE 1.1 (JSR-109), JAXP (Java API for XML Parsing) 1.2, and JAXR 1.0 (Java API for XML Registries). Of these, only JAXP was supported in J2EE 1.3.

With JAX-RPC, any Java class or stateless session EJB can be exposed as a Web Service. The specification defines how to use JAX-RPC to create and consume SOAP messages in Java, including issues such as serializing and de-serializing Java types with XML, dealing with SOAP attachments, and managing SOAP faults and headers.

JAX-RPC provides a client runtime that lets Java clients send and receive SOAP messages, and a server runtime for server-side Java implementations providing a Web Services API using SOAP. A JAX-RPC server implementation doesn't rely on a JAX-RPC client; rather, the client can be .NET, PL/SQL, or any other language capable of sending and receiving SOAP messages. Likewise, the JAX-RPC client can be used independently of a JAX-RPC server and can interoperate with other SOAP server-side implementations.

Implementation Strategy

Our implementation strategy involves three steps:

1. Configure a JMS resource adapter to work with your specific JMS provider or back-end.
2. Build a JMS application that accesses the JMS provider via the configured JMS resource adapter.
3. Publish your JMS application as a JAX-RPC-based Web Service and start enjoying the benefits of SOA.

Figure 1 illustrates a typical application architectural diagram following this implementation strategy. I will build the application from the right-bottom up in the diagram starting with Step 1. Then I'll move from right to left, bottom up, to complete the entire application, which will be accessible as a Web Service.

How It Works

Next, I will use an example application to show you in detail how this implementation strategy works. For demonstration purpose, I'll use the J2EE 1.4-compliant server Oracle Containers for J2EE (OC4J) and Oracle JDeveloper as the basis for the code and configuration file listings. I'll assume that the JMS provider is WebSphere MQSeries.

Application Scenario Example

Our example application consists of a session bean and a message-driven bean (MDB). The session bean provides an interface for sending a message (that contains a business service request) to an MQSeries queue that the MDB is listening to. When the MDB gets the message, it sends a reply message (that reflects updated business information or a simple acknowledgement) back to this queue, linking the received and reply messages using JMSCorrelationID.

The session bean's interface call is synchronously blocked until it verifies that all replies are correctly received. The synchronous call here is not a requirement - the MDB can also trigger a separate bean to process the reply messages. It's optional that the message receipt and reply be included in the same transaction.