qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: Proton Messenger and the Request/Response pattern
Date Wed, 02 Jan 2013 21:58:46 GMT

On 01/02/2013 02:39 PM, William Henry wrote:
> ----- 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 really like this suggestion.  The blocking variant is dirt simple and 
you don't even need to supply a correlation_id.  It can be hidden 
beneath the API.

I do think there may be a cleaner syntax/naming for this though.

An alternate syntax for the client side might be to provide an 
alternative to "put" like "put_request" that annotates the message 
appropriately for request/response and returns the correlation_id. 
"send_request" could be the blocking variant.

>> (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.
> William
>> Thoughts?
>> -Ted

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

View raw message