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: [email protected]
For additional commands, e-mail: [email protected]
