Several features of JMS bindings and how SCA artifacts work with them are discussed.
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.
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:
When a response message to an outbound JMS service is a ServiceBusinessException, the handler will do the following:
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.
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 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.
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.