Extending the Coordinated Request Reply JMS sample

When the ReplyToQ and Correlation ID values of the original request message are saved in a JMS message for later retrieval, the whole of the JMSHeader is saved, rather than just the ReplyToQ and Correlation ID details. The whole JMSHeader is saved because there is a requirement to store and retrieve two values (ReplyToQ and Correlation ID), and the JMSReceive node can store or retrieve only a single value. Therefore, you must save the structure containing the values that are required instead of saving the individual values. When you change the sample to store different values, you must consider the behavior of the JMSReceive node.

You can use your own implementations of the subflows that are used in the Request and Reply flows to replace those provided in the sample. For example, you might want to use a database to store the ReplyToQ detail from the initial request message. Alternatively, you might want to use the subflows that are used to store and retrieve the ReplyToQ and Correlation ID in a JMS message in other message flows.

Reusing the StoreOriginalJMSHeader_Sub subflow

You can use the StoreOriginalJMSHeader_Sub subflow in your message flows; this subflow acts in the same way as saving the JMSHeader in a JMS message. To save the JMSHeader of the request message, you must include the subflow at the appropriate point in the message flow in which it is to be used. You can include the subflow without modification but you must take into account the following considerations:

Although the key parameters that you can change are identified in the preceding text, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.

Using an alternative implementation of the StoreOriginalJMSHeader_Sub subflow

You can modify the subflow to use an alternative storage facility for the data; for example, if you choose to use a database, instead of writing a JMS message the subflow must insert data into a database.

Changing the storage facility changes the performance characteristics of the subflow. It is important to ensure that the characteristics of the implementation that you choose are consistent with the performance requirements for the message flow. Using a database to hold the information makes the performance more likely to be I/O-bound because each insert to the database requires a write to the database manager log.

Using an alternative storage facility can also change the transactional properties of the subflow. When data is stored by using a JMS message, it uses the same resource manager as the JMS messages that are read elsewhere in the message flow. If the JMS messages are processed only in the message flow, a single resource manager is involved. Using a database, or other recoverable resource manager, requires a two-phase-commit recovery protocol between the WebSphere Message Broker queue manager and the database manager of the database in which data is stored to ensure data integrity.

When you are making changes, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.

Reusing the RestoreOriginalJMSHeader_Sub subflow

You can use the RestoreOriginalJMSHeader_Sub subflow in other message flows to retrieve the JMSHeader of the initial request message from a JMS message. To retrieve the JMSHeader you must include the subflow at the appropriate point in the message flow in which it is to be used. You can include the subflow without modification but you must take into account the following considerations:

Although the key parameters that you might want to change are identified in the preceding text, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.

Using an alternative implementation of the RestoreOriginalJMSHeader_Sub subflow

You can modify the subflow to use an alternative storage facility for the data; for example, if you choose to use a database, instead of using the JMSReceive node to read a JMS message, the subflow can read data from a database.

Changing the storage facility changes the performance characteristics of the subflow. It is important to ensure that the characteristics of the implementation you choose are consistent with the performance requirements for the message flow. The use of a database to hold the information might add different overheads depending on the implementation. If data is retrieved by using a read, and is not updated or deleted, the overhead is at its lowest for a database implementation. However, if data is not deleted from the database, the database continues to grow in size and becomes progressively slower to use unless some housekeeping is put in place. If the retrieval process involves updating a row to indicate that the data has been retrieved, or the deleting of a row, this action involves a write to the database manager log, resulting in a significantly larger processing overhead than for the read-only case.

Use of an alternative storage facility can also change the transactional properties of the subflow. When data is stored by using a JMS message, it uses the same resource manager as the JMS messages that are read elsewhere in the message flow. If JMS messages are processed only in the message flow, only a single resource manager is involved. Using a database or other recoverable resource manager requires the use of a two-phase-commit recovery protocol between the WebSphere Message Broker queue manager and the database manager of the database in which data is stored to ensure data integrity.

You must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.

Back to sample home