Interoperability Solutions for JMS

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Understanding Message ID and Correlation ID Patterns for JMS Request/Response

JMS is a standard API for accessing enterprise messaging systems. WebLogic JMS:

For an overview and features of JMS, see JMS Interoperability and Configuring and Managing WebLogic JMS.

This section describes the Message ID and Correlation ID patterns supported in Oracle Service Bus for JMS request-response and describe how Oracle Service Bus uses these patterns to interoperate with Java API for Remote Procedure Call (JAX-RPC) web services. Examples are also provided.

The following topics are included:

 


Overview of JMS Request-Response and Design Patterns

Messaging provides high-speed, asynchronous, program-to-program communication with guaranteed delivery and is often implemented as a layer of software called Message Oriented Middleware (MOM).

In enterprise computing, messaging makes communication between processes reliable, even when the processes and the connection between them are not so reliable. Processes may need to communicate for the following reasons:

Asynchronous request-response messages are the best approach to interacting with some mainframes, if you are using IBM WebSphere MQ.

Patterns for Messaging

Messaging patterns describe the format of messages that flow between parts of a system built with a MOM. There are several types of messages as follows:

In the case of Oracle Service Bus, each reply message should contain a unique identifier called the correlation ID, which correlates the request message and its reply.

When the caller creates a request message, it assigns a unique identifier to the request that is different from those for all other currently outstanding requests (for example, requests that do not yet have replies). When the receiver processes the request, it saves the identifier and adds the request’s identifier to the reply.

When the caller processes the reply, it uses the request identifier to correlate the request with the reply. This is called a correlation identifier because of the way the caller uses the identifier to correlate each reply with the request.

A correlation ID is usually put in the header of a message. The ID is not a part of the command or data the caller is trying to communicate to the receiver.

The receiver saves the ID from the request and adds it to the reply for the caller’s benefit. Since the message body is the content being transmitted between the two systems and the ID is not a part of that, the ID is added to the header.

In the request message, the ID can be stored as a correlation ID property or simply a message ID property. When used as a correlation ID, this can cause confusion about which message is the request and which is the reply. If a request has a message ID but no correlation ID, then a reply has a correlation ID that is the same as the request’s message ID.

The correlation ID format used internally by Oracle Service Bus is compatible with WebSphere MQ and works with target services that are using MQ native interfaces.

The outbound transport handles asynchronous request-response messages. That is, the message flow, except for the $outbound transport specific data, does not distinguish between JMS request-response and HTTP request-response.

When you define a JMS request-response business or proxy service, you must first choose a design pattern. To do this, select the Is Response Required check box in Oracle Service Bus Console when you design a JMS proxy or business service, then select one of the following correlation patterns on the JMS Transport Configuration page:

Note: JMS request/response messaging does not have reliable responses because the mapping of the correlation ID to the proxy service is stored in memory. If there is a failure/restart in between sending the request and receiving the response, the response will be discarded. One possibility for some situations is to not use JMS request/response, but to use two JMS 1-way proxies. Use a 1-way JMS proxy for delivering the message and a second 1-way JMS proxy in the reverse direction for delivering the response.

For information about creating JMS proxy and business services, see Proxy Services: Creating and Managing and Business Services: Creating and Managing in Using the Oracle Service Bus Console.

The following sections discuss these patterns. To compare the two patterns, see Comparison of Message ID and Correlation ID Patterns.

 


JMS Message ID Pattern

When you create a business service using the JMS Message ID pattern, instead of defining the Response URI, specify the queue to be used for responses for each Managed Server in the Oracle Service Bus cluster. These queues must be collocated with the request queue for the service. The proxy service uses this information to set the JMSReplyTo property when invoking the business service so that the response is processed by the Managed Server that issued the request.

When you define a proxy service using the JMS Message ID pattern, you need not define the ResponseURI because the proxy service replies to the queue specified in the JMSReplyTo property. However, you can enter the JNDI name of the JMS connection factory for the response message.

Note: By default, the connection factory of the request message is used. This is useful when you use a non-XA connection factory for JMS responses, but have an XA connection factory for the request.
Note: For the deployment descriptors to be set appropriately for XA capable resources (JMS, TUXEDO, EJB), you must set the XA attribute on the referenced connection factory before creating a proxy service.

The invoked service must copy the message ID from the request (the value of the JMS header field JMSMessageID) to the correlation ID of the response (setting the JMS header field JMSCorrelationID). In addition, the invoked service must reply to the queue specified in the JMSReplyTo header field.

If you choose the JMS Message ID Pattern, the response arrives at the appropriate managed node.

A JMS proxy service using this pattern can be used in a cluster without further configuration. A JMS business service is available in a cluster. However, when a Managed Server is added to the cluster, all the business services become invalid. To correct this, ensure that the number of response queues equals the number of Managed Servers that specify the JMS Message ID correlation pattern in the Oracle Service Bus cluster.

Note: The JMS Message ID correlation pattern is not supported when a proxy service invokes another proxy service.

 


JMS Correlation ID Pattern

When you design a business service in Java, make sure that you set the value of JMS Correlation ID on the response to the value of JMS Correlation ID on the request before sending the JMS response to a queue. For information about creating JMS proxy and business services, see proxy Services: Creating and Managing and Business Services: Creating and Managing in Using the Oracle Service Bus Console.

You can obtain the JMS Correlation ID when you receive a message using:

String getJMSCorrelationID()

The above method returns correlation ID values that provide specific message IDs or application specific string values.

To set the JMS Correlation ID() when you send a message:

void setJMSCorrelationID(String correlationID) 

 


Comparison of Message ID and Correlation ID Patterns

The JMS request-response patterns differ in the following ways:

The differences between these two patterns are summarized in Table 2-1

Table 2-1 Differences Between Message ID and Correlation ID Patterns
JMS Pattern Name
Response Queue
CorrelationID
Correlation ID Pattern
All responses go to the same fixed queue.
The server copies the request Correlation ID to the response Correlation ID.
Message ID Pattern
The responses dynamically go to the queue indicated by the JMSReplyTo property.
The server copies the request Message ID to the response Correlation ID.

When the Correlation ID pattern is used, the service that is invoked responds to a fixed queue. The response always arrives on the same queue and the client has no control over the queue to which the response arrives. For example, if 10 clients send a message, they all get the response to the same queue. Therefore, clients must filter the messages in the response queue to select the ones that pertain to them. Filtering criteria are configured in the request message Correlation ID property, and the server is configured to echo this to the response Correlation ID property.

In the case of Message ID pattern, the client’s JMSReplyTo property tells the server where the response should be sent. This queue is specific to the client’s server and hence responses to different clients will go to different queues. The server sets the JMS Correlation ID of the response to the JMS ID of the request.

Correlation by MessageID is commonly used by many IBM MQ applications as well as JMS applications and is the standard method to correlate request and response.

If you have multiple WebLogic client domains invoking a target WebLogic domain using JMS request-response, with the Message ID pattern, you can set up both the request and response queues as SAF queues. However, this is not possible with the Correlation ID pattern that uses a single queue for all the responses.

The Correlation ID pattern has two major advantages:

 


Interoperating with JAX-RPC over JMS

Workshop for WebLogic allows you to create JAX-RPC web services that use JMS transport, in addition to HTTP-HTTPS. These JMS transport JAX-RPC web services use a JMS queue as the mechanism for retrieving and returning values associated with operations. You can use the JMS Message ID pattern to invoke a JMS transport JAX-RPC web service.

You can also invoke a JMS Request-Response Oracle Service Bus proxy service from a JAX-RPC static stub, which the WebLogic clientgen Ant task generates.

This section includes the following topics:

Invoking a JAX-RPC Web Service Using the JMS Message ID Pattern

To invoke a JMS transport JAX-RPC web service using the JMS Message ID pattern, complete the following steps:

  1. Create a JMS Request-Response Oracle Service Bus business service that uses the JMS Message ID pattern to invoke the JMS transport JAX-RPC web service. For more information, see “JMS Transport Configuration page” in Business Services: Creating and Managing in Using the Oracle Service Bus Console.
  2. This business service uses JMS transport. The JMS queue JNDI name portion of the end point URI must be the same as the queue attribute specified in the @WLJmsTransport annotation of the JMS transport JAX-RPC web service. For example:

    jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue

    The JNDI name of the JMS queue (or queues) assigned to the Destination field, in the Response JNDI Names area, must be associated with a JMS server targeted at the WebLogic Server name that is displayed in the Target field.

  3. Create an Oracle Service Bus proxy service that contains a Routing (or Service Callout) action to the JMS Request/Response business service that you created in step 1.
  4. The Request Actions area of the Routing action must contain a Set Transport Headers for the Outbound Request action. When you configure the Transport Headers action, you must add two JMS headers for the Outbound Request action. For detailed instructions about how to configure a Transport Headers action, see “Transport Headers” in Proxy Services Actions in Using the Oracle Service Bus Console.

    In brief:

    1. Configure a Transport Headers Action by selecting Other in the Add Header field and entering a URI in the field provided.
    2. Select Set Header to <Expression> and create the expression by entering a concatenation of the values specified for the contextPath and serviceUri attributes (in the @WLJmsTransport annotation of the JMS transport JAX-RPC Web Service), preceded by a forward-slash. For example, you have the following @WLJmsTransport annotation:
    3. @WLJmsTransport(

      contextPath="transports",

      serviceUri="JmsTransportService",

      portName="JmsTransportPort",

      queue="JmsTransportServiceRequestQueue"
      )

      You would enter the following expression in the XQuery Text input area when you configure the Transport Headers:

      /transports/JmsTransportService

    4. To specify the second JMS Header, select Other in the Add Header field again, and enter _wls_mimehdrContent_Type in the associated field.
    5. Select Set Header to <Expression> and enter text/xml; charset=UTF-8 in the XQuery Text input area.

Invoking a JMS Request-Response Proxy Service from a JAX-RPC Client

For a scenario in which a JAX-RPC WebLogic Server client invokes a proxy service, you must set the _wls_mimehdrContent_Type JMS header for the proxy service’s inbound response.

You must specify the header when you issue the response to the incoming JMS Message ID Pattern request.

For example, for the scenario in which you have a JAX-RPC client calling an Oracle Service Bus proxy service, which subsequently calls a WebLogic Server web service, the route node configuration is as follows:

For the Request Pipeline:

  1. Set the transport header for Web service context 'URI' (for example: interop/AllocJmsDocLit).
  2. Set the transport header for _wls_mimehdrContent_Type with text/xml; charset=UTF-8.
  3. Select Outbound request from the Set Transport headers menu items.
  4. Enable Pass all Headers through Pipeline.

For the Response Pipeline:

  1. Add an empty transport header and select Inbound response from the Set Transport headers menu.
  2. Enable Pass all Headers through Pipeline.
Note: For detailed instructions about how to configure a Transport Headers action, see “Transport Headers” in Proxy Services Actions in Using the Oracle Service Bus Console.

 


JMS Message ID Pattern Examples

The following examples describe the different methods by which the JMS Message ID pattern can be used.

Example 1: An MQ Service Uses a JMS Message ID as a Correlator of the Request-Response Message

In Figure 2-1, the server that hosts the MQ service in the request-response communication echoes the request message ID to the response correlation ID, and sends the response to the replyTo queue. The response travels back and is correlated using the JMS MessageID. The Oracle Service Bus replyTo destination is set, one per Oracle Service Bus node in a cluster, when the business service is configured. A JMS or MQ native client can also invoke a JMS request-reply proxy service using the JMS Message ID pattern. The client needs to set the replyTo property to the queue where it expects the response.

The key to supporting this use case is that JMS Message ID is the expected correlator of the request-response message. You also need to create as many MQ series outbound response queues as there are cluster servers.

Figure 2-1 MQ Service Uses a JMS Message ID as a Correlator of the Request/Response Message

MQ Service Uses a JMS Message ID as a Correlator of the Request/Response Message

Example 2: A JAX-RPC Client with Oracle Service Bus Proxy Service

Figure 2-2 represents a JAX-RPC client sending a message to an Oracle Service Bus proxy service, that is, the JAX-RPC inbound case. The JAX-RPC stack employs a temporary queue to receive the response. The Oracle Service Bus JMS transport honors this temporary queue during run time.

Figure 2-2 JAX-RPC Client with Oracle Service Bus Proxy Service

JAX-RPC Client with Oracle Service Bus Proxy Service

Example 3: Oracle Service Bus as a Client of a WebLogic Server JAX-RPC Request/Response Service

Figure 2-3 represents the JAX—RPC outbound case or the interoperability of a WebLogic Server JAX—RPC request/response service with an Oracle Service Bus proxy service.

Figure 2-3 Oracle Service Bus as a Client of a WebLogic Server JAX-RPC Request/Response Service

Oracle Service Bus as a Client of a WebLogic Server JAX-RPC Request/Response Service

Note: When a proxy service in one WebLogic Server domain needs to send a message to a proxy service in a second domain, the message must first be routed to a pass-through business service in domain 1. JMS Store and Forward between domain 1 and domain 2 forwards the inbound request message to the proxy service in domain 2. When you use JMS request/response, you can choose to forward the inbound response message from domain 2 to domain 1 using JMS Store and Forward as well. In the latter case, exported inbound request and imported inbound response queues must be configured in domain 2 for the proxy service in domain 2. Pay close attention to the JMS Store and Forward configuration.

  Back to Top       Previous  Next