qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Proton Messenger and the Request/Response pattern
Date Wed, 02 Jan 2013 19:14:37 GMT
I'd like to start a discussion on how, from an API perspective, 
applications can use the request/response pattern.  If we get this 
right, we will remove a significant barrier to adoption of AMQP.

Middleware messaging systems typically do a poor job of supporting this 
pattern.  The Qpid APIs are quite lacking in this regard (requester 
creates and subscribes to a temporary queue with a _unique_ name and 
places this name in the reply-to field).

Proton Messenger supports request/reply (see 
examples/messenger/$LANG/{client,server}) as follows:

The requester (client) has to put _something_ into the request message's 
reply_to field.  It also sets the correlation_id field if it needs to 
dispatch multiple responses.  The responder (server) must copy the 
request message's reply_to field to the response message's address field 
and also copy the correlation_id.

This API is good for the case where the client wants the response to go 
to a third party.  In this case the reply_to is well understood to be 
the address of the third party receiver.  However in the more common 
case where the response is intended to come back to the client, it's not 
clear at all what to put in the reply_to field.

I propose that we allow the client to simply say


(I added the correlation_id argument because it's almost always going to 
be needed).  Further, the server could use


which would take care of the addresses and the correlation_id.  It also 
provides a place to report an error if a request cannot be replied to 
(absent or invalid reply_to address) rather than force each server 
implementer to code this check.



To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message