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 Meeting

+1 on Rob's observations.

Also, it seems like the addressing discussion is drawing out desires and assumptions in the area of routing (of whatever kind).

I think routing should be kept a separate topic, and the addressing scheme tested against the various routing scenarios needed by various users. Addressing should not be designed with a particular scheme in mind.

Regarding dynamic routing, in passing, I think this may be problematic in AMQP+SSL networks, or I may have missed something in the reading.

Hope you have a good call.

Kind regards,

On Apr 4, 2014 12:43 PM, "Godfrey, Robert X" <robert.godfrey@jpmorgan.com> wrote:

In advance of the Addressing meeting today, some comments on what I would like to see as the outcome of that meeting, and on the current document.


Today’s Meeting:


I think we should


·         Document a shared understanding of the scope of the work (sign off on the requirements section?)

·         Document a shared understanding of the requirements of a conforming container (in particular wrt DNS resolution)

·         Agree document structure


If we can get through the above then I would like to continue our discussion on the dynamic routes / request-response work.





Comments on the document:


Section 2: Requirements


It seems to me that the most important requirement in “Global” addressing is the ability to distinguish between addresses which are “global” in scope and those which can only be resolved within the context of the current container. Moreover that in identifying a “global” address a container can (with the aid of configuration data) parse the address such that it can route the message either within the container or to another container.


While the above could clearly do with rephrasing it seems to me to be something we would want to highlight before some of the other requirements listed. The bullet point on global transcription sort of speaks to this though I think the terse formulation and reference to a discursive section in design considerations in an RFC is not really sufficient.


I also think that we should make the non DNS form of addresses look less like an afterthought.  To me we have two schemes, one with a known global authority for registering domains, and one which essentially defines the authority as being the “AMQP network”.  I think this second form may prove initially more popular/useful as people deploy AMQP networks which are not global in the sense of being open to anyone on the internet, but are “global” within the context of a large organization or business domain.


The requirements also seem to suggest that the reason for using DNS names is so that IP lookup/resolution can be done.  I tend to view this in the opposite way – using DNS / SRV allows for IP lookup, but using DNS as the naming authority is beneficial in itself even in a network where connections are always pre-configured and IP resolution need not take place.


IP / Transport resolution adds complexity to the allowed syntax for addresses, I’m fine with allowing these more complex forms, but I think we currently give the misleading impression that these might be the norm – rather than an exception seen mostly before such networks become widespread, or only used in dev/testing etc.


Section 3: Addresses


Following on from my comments on section 2, I think we should split the definition of addresses from the process of resolution of “registered” names to IP addresses / ports / transports.  That is I think sections 3.2.1 and 3.2.2 should be moved to a separate chapter.  In its place I think we should add some examples of the use of registered/unregistered/legacy names in a “traditional” messaging network with clients/intermediaries/queues etc.  Some of this may be able to be imported/rephrased from the “Scenarios” section.


Section 4: Routing


This section still seems somewhat of a grab bag of various address related stuff that we think might be useful. Maybe it would make more sense to define more, shorter sections each defining a self-standing concept.  For instance I could see that we could split out the anonymous-relay / relay node definition into a separate section with an example.  Or else we characterize a section as a set of container capabilities and include the anonymous terminus and address equivalence.


Dynamic routes / request-response seems to be where we have spent most time recently… given the amount of time we have spent on it I think it probably deserves its own section.


-- Rob


Legally required information for business correspondence/Gesetzliche Pflichtangaben für Geschäftskorrespondenz:


This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

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