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