OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [amqp] Addressing Presentation


On 05/06/2013 03:36 PM, Rafael Schloming wrote:
On Thu, 2013-05-02 at 09:37 +0100, Gordon Sim wrote:
I accept the three 'categories' of address though I don't think 'dns v.
non-dns' is the right distinction between the first two. I see the
second category as a special case where the address is only reachable
when the receiver establishes the necessary link(s) itself.

I can see why you might be tempted to describe it that way, however I
think that description is overly restriction and in fact violates one of
the basic design principals we are trying to adhere to, namely that the
physical topology should be invisible to the logical addressing scheme.
The initiator of a given link is really an artifact of the underlying
physical topology and really shouldn't play into the semantics of the
logical address.

To illustrate what I mean, let's consider the basic scenario of a
service accessed via request/response. In this scenario the clients
would use the non dns form of the address to access the response. The
service would then hold the responses until the clients come back to
access them:

                to: //service.com/do-something
          reply-to: /<client-id-1234>/responses
   Client --------------------------------------------> Service
          <--------------------------------------------
                to: /<client-id-1234>/responses

In the simple peer to peer case involving only two AMQP containers, then
your description of the address applies. It only ever gets sent across a
receiver initiated link. But imagine that the load on this service
increases and there are a lot of responses enqueued at the service.
Suppose we want to offload the overhead of handling these responses into
a separate queuing intermediary. This is changing the physical topology,
but according to our principal, we don't want the addressing to have to
change as that will impact all of our endpoints:

                to: //service.com/do-something
          reply-to: /<client-id-1234>/responses
   Client ------------------> Intermediary ------------> Service
          <------------------              <------------
                to: /<client-id-1234>/responses

Now with the topology depicted above, the Service would want to offload
responses to the intermediary as quickly as possible, and it would
therefore be reasonable that the Service would be initiating the link to
the intermediary rather than waiting for the intermediary to initiate a
link to the service, however this would violate your definition as you
would have the Service actively sending messages to a non-dns address
rather than waiting for something else to initiate the link.

I'm not sure this does violate my 'definition'[1] but in any case, my intention was not to provide a formal definition but merely to indicate that I do not agree with the categorisation of addresses into 'dns based' v 'non dns (opaque)'.

--Gordon.

[1] The address is only reachable when the Client has established its link to the intermediary, the service is in this case merely configured to forward such messages to the intermediary, establishing the link if needed. However I would readily agree that my description was not sufficiently precise.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]