[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]