76 Enabling SOA Using WebSphere Messaging
Figure 4-9 Resubmit and exception handling after a timeout
When resubmitting a request, consider the following:
򐂰 Ensure that the original request and the resubmits do not influence each
In cases where requests lead to persistent data manipulation, ensure that
only one of the requests is executed, either the original request or one of the
resubmits. A way of achieving this is by maintaining a request log containing
message ID, request, and reply message. For further information see
“Request-reply logging” on page 78.
򐂰 Ensure that neither request nor reply messages reside on the queue for an
indefinite amount of time.
Consider a resubmit that leads to two reply messages with the same
correlation ID because of a delayed reply. The pseudo-synchronous
consumer expects just one, and is therefore never going to read the second
message. For this reason messaging systems provide expiration functionality
for messages, meaning that after a defined time a message is discarded and
removed from the queue. For further information see “Message expiration” on
page 78.
4.4.3 Selecting a messaging pattern
None of these options is incorrect if implemented correctly. The user’s
requirements and experience will dictate which decision is the correct one. A
fire-and-forget communication pattern is applied if a consumer does not need to
get a reply. A request-reply communication pattern needs to be applied if a
consumer needs to get a reply based on the request.

Get Enabling SOA Using WebSphere Messaging now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.