A short Presentation

OW2 CXF ReliableJMS is a new transport for Apache CXF that is allowing reliable asynchronous WebServices using the Apache CXF stack and JMS transport.
 

Why ?

Context

SOAP over HTTP has several drawbacks :

• Tightly-coupled transport
• Services inaccessible when the provider is inactive
• Difficulty to analyze failures (404-type errors)
• Long-lasting back office operations unadapted to real-time front-end interactions: we need asynchronism!

Limitations of the asynchronous CXF proposal

Apache CXF is implementing a JMS transport that is allowing to perform SOAP over JMS. However the current proposal seems to present some limitations which are including:

• One thread per request: The problem with that is the scalability. Because, for 100 requests, there will have 100 waiting threads.
• Memory-based mechanism: The mechanism used is not allowing a recovery after a crash of the JVM
• No transaction support: When a message is sent or received there are no transactions started.

A new approach / proposal

Global view of SOAP over JMS proposal

The objective: define an alternative solution:

• respecting our objectives and Java EE context
• to be integrated smoothly in CXF

There are some great benefits of using SOAP over JMS. First, it provides a real asynchronous client-server exchange. The JMS provider is in charge of the transport of the SOAP message. JMS provider guarantee as well the reliability of message delivery. It expects that there is no message loss and no duplicates for all messages that are handled. Moreover there are some JTA Transactional features available by using JMS.

This is based on JTA Transactional features available by using JMS:

• client-side: between its resources and the message sent
• server-side: between message reading and its resources
• similarly for responses

This solution is based on the Apache CXF Web Services stack. Instead of reinventing the wheel for JMS Message Listeners, the idea is to use EJB Message Driven objects that are enhanced Message Listeners. Several implementations of such Message Driven objects are available and two of them can be used by our reliable JMS transport.

• Java EE Message Driven Beans (MDB)
• Spring Message Driven Pojo (MDP)

These two Message Driven frameworks provide 

• JTA Transaction support. This is provided by default when using Java EE MDB. When using Spring MDP, one can use JTATransactionManager to support global transactions.
• Pool of objects that are handling requests. Pool is provided by the Java EE EJB or the Spring MDP container.

This new transport named ReliableJMS will have a new URL which starts with reliablejms://## allowing to identify this new transport protocol. This transport is using most of the code used in the CXF JMS transport. Thus, all bug fixes/enhancement done in the JMS transport benefits to the ReliableJMS transport. For example, the code for building a JMS Message from a CXF message is provided by the JMS transport. ReliableJMS Transport is divided in 3 parts that are located on the client side
or the server side.

• On the client side, there are the "sending" and "receiving" part
• On the server side, there is the "endpoint" part.

Achitecture view

 

 
On the above schema, it is shown that 3 transactions are handled.

• The first one is managed by the client that is calling a Web Service Endpoint. It ensures that the call is done and that the JMS message has been sent to the JMS MOM.
• The next transaction occurs when the JMS message is handled by the Message Driven object on the endpoint side. It ensures that the endpoint is called and that if there is a system problem when calling the endpoint, all resources that are part of the transaction will rollback
• The last transaction is occurring on the client that is handling the answer. It ensures that the Async Handler callback is called.

Handling errors

 
Errors can occur at different layer on this transport architecture. The idea is that any failure on the delivery system won't be a problem as recovery will be managed by the JMS persistent mechanisms.

On the following schema, there are 3 test failures that are located in the 3 subpart of the ReliableJMS transport. For each part, if the system is restarted, all messages that are still in a queue will be processed and then the call on the endpoint or the answer of the endpoint will be delivered as if there was no failure.

If there is a failure when a Message Driven object is handling a JMS message, new attempts to redeliver the message will occur (one retry for each failure as per JMS specification).

For each failure, there is a transaction rollback. All database operations (or involving other XA resources) are canceled. When we reach an amount of failures, the JMS message that is not delivered will be routed to a « Dead Message Queue »
 

Prerequisites

• This Java EE solution is requiring a Java EE environement that is providing JMS and JTA capabilities.
• An EJB container is required when using Message Driven Beans.
• No additional dependency is required when using Message Driven Pojo because Spring is already an Apache CXF dependency
• This transport may be compliant with any Java EE 6 application servers.
• Tests have been done by using JOnAS 5.2.0 
• The JMS server used for the tests is JORAM MOM which is provided by default in JOnAS but any other JMS MOM should work.
• Some configuration is done through Spring as any other Apache CXF transport

Availability

The code of this transport is hosted on the OW2 JOnAS forge on the SVN repository

This ensures a life-cycle that is independent and allows to follow each Apache CXF releases.

The module is also available through OW2 maven repository (which is mirrored on the Central repository). OW2 Maven Snapshot repository
 

User guide

• Download TGZ documentation
• Download ZIP documentation
   

Downloads

• Download from Maven Repository