qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Proton Messenger and the Request/Response pattern
Date Thu, 03 Jan 2013 12:13:29 GMT
Hi Ted,

>From my experience I have to agree with you, that the way the
request/response is handled in the current API is a bit complicated and
caused some troubles to some of our customers connecting to our brokers.

But at the same time I like the flexibility of the current approach, where
you have a high level of control about the queues / exchanges used to
deliver the responses. In our use case, when we have a lot of 3rd party
customers connecting to our broker, it is the security and the operability
what is important for us. For example having the response queues to follow
some naming schema based on the user name gives you a quick overview about
which queues belong to which customers and at the same time makes it really
easy to ensure the security using ACLs. Also, when you have a broker where
multiple different clients are connecting, you have to validate the
reply_to address to avoid sending the response(s) to a different customer
(either by mistake or by intention).

Of course the best would be if we can have both - the simplicity as well as
the flexibility. But I'm not sure whether it is possible to add the
flexibility to your proposal without making it too complicated again.
Having some default behavior and some configuration options to affect the
default behavior might be one of the possibilities.


On Wed, Jan 2, 2013 at 8:14 PM, Ted Ross <tross@redhat.com> wrote:

> 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)
> (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.
> Thoughts?
> -Ted
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<users-unsubscribe@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message