JMS features

Several features of JMS bindings and how SCA artifacts work with them are discussed.

This section examines these JMS features in relation to SCA artifacts:

Callback destination

SCA services that access messages asynchronously require callback methods and correlation objects, which are explained in this section.

Any SCA service can be accessed in a synchronous or asynchronous manner, independent of whether the service itself is synchronous or asynchronous.

An SCA service interface is always defined in the synchronous form. Additional interfaces are created to support the asynchronous model. These interfaces pass a callback object with the asynchronous request. Once the called service finishes processing the request, it returns the results to the callback object. A correlation object, known as a ticket, is used to correlate the response with the original request.

Both the JMS import and export use a destination, the callback destination, to store callback information. This is an internal SCA JMS service mechanism used to support SCA asynchronous invocations, which has been exposed to allow performance customization.

When a JMS import is invoked in a synchronous manner, it will put the JMS message onto the send destination and store the callback information in the callback destination using the correlation scheme of the request JMS message. The JMS import then uses a Message Driven Bean (MDB) to listen for the reply message. When the reply message arrives, the MDB uses its correlation ID to retrieve the callback information. It then uses the callback information to invoke the callback object with the response.

A JMS export uses a MDB to listen on the receive destination. When a message is received it will dispatch the request to the SCA runtime and will store JMS response information in the callback destination using the ID of the ticket. When the callback is invoked it will retrieve the JMS response information from the callback destination using the ID of the ticket such as the 'send' destination, the correlation ID and its output data binding. Then the callback’s response argument and the JMS response information is used to create the response JMS message and send it to the reply destination.

Fault handling

JMS fault handling is used to handle exceptions at run time.

JMS SCA fault handling depends on these factors:

When set to true, the boolean property in the JMS message and the boolean property in the JMS data binding indicate that the payload of the message is a fault. The boolean property in the JMS message is set and retrieved by the data binding. The boolean property in the data binding is set and retrieved by the SCA JMS run time.

When the response from the target service, for an inbound JMS service, is a ServiceBusinessException, the handler will do the following:

  1. Invoke setBusinessException(true) on the response data binding
  2. Set the exception data on the DataBinding
  3. Use the DataBinding to create the response message. When the data binding writes the response message, it will set the boolean message property IsBusinessException to true.

When a response message to an outbound JMS service is a ServiceBusinessException, the handler will do the following:

  1. Use the data binding to read the response message. When the data binding reads the response message, it will check for the boolean message property IsBusinessException. If it exists it will use it will use it to set the state of its businessException property. If the property doesn’t exist then it should assume a value of false.
  2. Use the data binding to create the response argument.
  3. Use the data binding to check if a fault has been passed. If it has then the handler will create a ServiceBusinessException with the response argument and send that to the calling service.

The response message will come from an SCA module. Note that the ServiceBusinessException is an SCA term so you will need to map it to the exception in the JMS client.

Quality of service

An attribute, asyncReliability, is available on a JMS export binding's performance attributes tab. This attribute specifies the reliability that the SCA runtime uses during asynchronous invocation of the export's target component. When it is set to assured, delivery of the message is guaranteed. The message will be persisted if necessary. When the attribute is set to bestEffort, the delivery of the message may fail in the event of system failure. Message persistence requires performance overhead. If your application does not need guaranteed message delivery you should set the attribute to bestEffort. The default value for this attribute is assured.

JMS header properties

JMS header properties can be set from the JMS import method binding. One special user property is TargetFunctionName. This property can be used in conjunction with the supplied default FunctionSelector, in a JMS export, to control how a message is mapped to a service method. JMS header properties can be dynamically accessed and set using an XSL transformation in a mediation flow. A mediation flow can take an incoming message header property and transform it using an XML map.

Correlation schemes

For request-response or two-way operations, the JMSCorrelationID of the response message must contain the request message's JMSMessageID. This JMSMessageID is used to retrieve the callback information, to return the response to the calling service. When an SCA JMS import is used to invoke a JMS client, the JMS client must take the JMSMessageID from the request message and set it into the JMSCorrelationID of the response message.

Feedback
(C) Copyright IBM Corporation 2005, 2007. All Rights Reserved.