Browse Prior Art Database

A Method for synchronous request response message processing.

IP.com Disclosure Number: IPCOM000032443D
Original Publication Date: 2004-Nov-05
Included in the Prior Art Database: 2004-Nov-05
Document File: 3 page(s) / 61K

Publishing Venue

IBM

Abstract

A method for simplifying the mechanism for processing a request message and responding.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

A Method for synchronous request response message processing .

Disclosed is a method which simplifies the mechanism used by application programmers to process a request message that has been received, and sending a message in response.

    Traditional messaging systems have been written to provide very good One Way Messaging (OWM), but provide little or no support for Request Response Messaging (RRM) and where they do it is limited to simplifying the task of the client, rather that the Request Processor (RP).

    There are several standard patterns used to correlate request messages and response messages in an RRM model, however the requirement to follow these is placed on the programmer. In some systems, such as Java* Message Service (JMS), direct client support is provided, but still requires the RP to know the mechanism used by the client API. It is undesirable for a programmer to need to know how an interface has been implemented.

    Existing asynchronous support for RP is deficient as it provides mechanisms to process request messages, but does not provide support for sending a response message; synchronous support is also deficient as it does not provide a simple mechanism to send a response. There are several known ways that could be used to extend the current support. These include:

Give the request message a reply verb which takes a response message and will


1.


2.


3.

send it as a response to itself.

Have a reply verb where you pass in both the request and response message.

Extend the existing asynchronous support so a message can be returned.

    This disclosure documents a fourth solution to this problem. This solution is most applicable in the following scenario:

    A Server Side Component (SSC) has been invoked. The business logic of the SSC requires that some logic be performed then a request message must be processed before the logic being executed returns. Ideally SSC's should only implement business logic and not have to be concerned with how the request and response messages are correlated.

    This solution extends the synchronous support to add a mechanism to register a message handler that will be driven once, when a message becomes available. The registration mechanism blocks until such time as a request message is discovered at which point it will call the SSC's message handler. This is all performed on the thread the SSC was initially called on. The SSC then executes the logic related to servicing the request and builds a response message. The SSC's message handler returns a response message and the infrastructure sends it to the client before returning control to the SSC again.

    When combined with existing client models which send messages and get responses, hiding the mechanisms to correlate the two, this mechanism extends the existing RRM support without requiring the programmer to need to know how requests and responses are correlated.

Glossary OWM:One Way Messaging, a system where a single message is sent and no response is e...