qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Henry <whe...@redhat.com>
Subject Re: Proton Messenger and the Request/Response pattern
Date Wed, 02 Jan 2013 19:39:13 GMT

----- Original Message -----
> 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
>      request_msg.reply_expected(cid)

Could you even block here with:

       reply_msg = request_msg.reply_expected(cid)

You can have a default parameter that indicates blocking. And you could 

       request_msg.reply_expected(cid, FALSE)

and then do the usual check for incoming messages etc.

> (I added the correlation_id argument because it's almost always going
> to
> be needed).  Further, the server could use
>      reply_msg.in_reply_to(request_msg)
> 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.

Yeah, that's nice too. I see your point. I'm not sure if all messaging purists will agree.
But it makes sense to me that we need something to handle this common use case more effectively.


> Thoughts?
> -Ted

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

View raw message