----- Original Message -----
> Hi All,
> 
> I wanted to re-raise Ted's suggestion regarding the need for a better
> Messenger API for handling reply-to's.
> 
> I've could've used this recently while designing a "echo" stress test
> for Messenger.  For my client, I have two requirements:
> 
> 1) I don't want to have to assign a publicly visible address to the
> client in order to receive replies.
> 
> 2) I only want a reply for particular messages.
> 
> I think these two requirements are common enough to merit some
> Messenger API lovin'.
> 
> In that context, Ted's API recommendation makes my life as the client
> writer easier:  It doesn't require me to obtain a reply-to value
> up-front (ie. before calling pn_messenger_put()), and it doesn't
> cause every message to be sent with a reply-to (which, I believe is
> the current case - messenger always adds a reply-to if not set).
> 
> I think there's value in Ted's proposal, but I'd recommend a slight
> modification to it: rather than mark the message directly, instead
> indicate to Messenger that a particular message needs its reply-to
> set correctly prior to transmitting it.  For example, we could add a
> flag to pn_messenger_put():
> 
>    msg = pn_message();
>    pn_message_set_address( msg, "peer's remote address" );
>    .... set message contents, cid, etc ...
>    pn_messenger_put( messenger, msg, PN_SET_REPLY_TO );
> 


I think this requires little or no change to the user's mental model, 
which is a _good thing_.

But wouldn't the following be more natural?  :
    
   pn_message_set_address( msg, peer_addr, PN_SET_REPLY_TO );

The address setting is done when your code is thinking about addresses,
and put() only puts.





> 
> Setting the PN_SET_REPLY_TO would cause Messenger to set the reply-to
> properly prior to sending, or signal an error if unable to do so
> (reported via a tracker, as usual).
> 
> This API change would satisfy my two requirements, while keeping the
> whole address management stuff out of my client.
> 
> Thoughts?
> 
> -K
> 
> 
> ----- Original Message -----
> > From: "Rafael Schloming" <r...@alum.mit.edu>
> > To: proton@qpid.apache.org
> > Sent: Friday, January 18, 2013 9:13:34 AM
> > Subject: Re: Proton Messenger and the Request/Response pattern
> > 
> > Gordon makes some good points. I'd like to add that I think
> > historically a
> > big part of the hassle isn't actually necessarily solely the API
> > but
> > also
> > having to configure and manage the intermediary, and I think we
> > need
> > to
> > look there as well if we want to simplify the overall pattern.
> > 
> > It's also worth remembering that there are significant performance
> > benefits
> > to keeping Message as a pure value object (i.e. a content holder)
> > that can
> > be reused many times even across multiple Messengers. Some of the
> > suggestions really stray from this pattern. If I recall correctly,
> > I
> > think
> > we said in prior threads that we wanted to maintain the notion of
> > Message
> > being a reusable content holder as an architectural invariant.
> > Perhaps it's
> > worth re-examining what we could do for request/response while
> > keeping this
> > invariant in mind.
> > 
> > --Rafael
> > 
> > On Fri, Jan 18, 2013 at 6:24 AM, Gordon Sim <g...@redhat.com>
> > wrote:
> > 
> > > On 01/02/2013 07:14 PM, Ted Ross 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)
> > >>
> > >
> > > A message has no association with a messenger (until it is put
> > > onto
> > > the
> > > messengers outgoing queue at least). It is not clear how a method
> > > on
> > > message would therefore be in any better position to determine
> > > the
> > > reply-address to use.
> > >
> > > At present, if a message on the outgoing queue has no reply-to
> > > set,
> > > then
> > > the messenger will automatically set the reply-to to be an
> > > address
> > > corresponding to itself.
> > >
> > > You can also use the (in my view slightly clumsy) syntax ~/xyz,
> > > which will
> > > be 'munged' into a form that prepends the messengers name to form
> > > a
> > > full
> > > address. This form I presume would be used if you want to
> > > distinguish
> > > different categories of replies.
> > >
> > > I'm not exactly enamoured with this, but it does seem at least to
> > > address
> > > the key concern expressed here, namely what to put in the
> > > reply-to
> > > for the
> > > simple case. (The answer being, nothing!)
> > >
> > >
> > >  (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.
> > >>
> > >
> > > This is really just a short hand for:
> > >
> > >   response.address = request.reply_to
> > >   response.correlation_id = request.correlation_id
> > >
> > > plus some code or exception indicating whether the address has
> > > been
> > > set. I
> > > have no objection to such a utility, though I'm not entirely
> > > convinced that
> > > a method on message is the best place. It also seems of fairly
> > > marginal
> > > benefit rather than removing a 'significant barrier to adoption'.
> > >
> > > Have you seen the JMS solution to simplifying the
> > > request-response
> > > pattern? There it is done by specifying a distinct class that
> > > uses
> > > a
> > > supplied session and destination and provides a request() method
> > > that takes
> > > a request message as input and blocks until it can return the
> > > response
> > > message. (See
> > > http://docs.oracle.com/javaee/**1.4/api/javax/jms/**
> > > QueueRequestor.html<http://docs.oracle.com/javaee/1.4/api/javax/jms/QueueRequestor.html>).
> > > Details of creating temporary response queues etc are hidden
> > > behind
> > > this. I
> > > like that general approach as it layers the functionality cleanly
> > > on top of
> > > the more flexible base, and would also allow different
> > > configurations or
> > > conventions to be used.
> > >
> > > --Gordon.
> > >
> > >
> > 
> 
> --
> -K
> 

Reply via email to