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 Thu, 2013-05-02 at 09:37 +0100, Gordon Sim wrote:
> On 04/30/2013 02:57 PM, Rafael Schloming wrote:
> > I've attached a PDF version in case people don't have access to google
> > docs.
> 
> I am not at all keen on the address syntax proposed in this 
> presentation. I much prefer a basic form of name@domain, where the 
> domain is optional. I believe it is simpler and more intuitive.

I believe I stated on the call that the syntax in the slides was out of
date and had fallen out of favor, so I don't believe there has yet been
any syntax proposed.

> 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.

The problem with requiring the link to be receiver initiated becomes
even more apparent if you imagine extending this scenario even further
by adding additional Service nodes for scale. For each service node you
add you would need to configure the intermediary to pull from that added
node rather than being able to simply deploy extra capacity on the fly.

> I suggest such addresses be identified by having a domain that starts 
> with (or indeed consists solely of) the '!' character, e.g. 
> name@!domain. Since domain will be a common configuration option, I 
> think this will likely give valuable flexibility in deployment.

I think it's not necessarily helpful to jump straight into syntax
proposals without understanding and/or agreeing on the full extent of
what exactly is being encoded by the syntax.

--Rafael




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