amqp — archive

AW: [amqp] Addressing Model Blog Post

From: Clemens Vasters
To: [email protected]
Date: Wed, 07 Nov 2018 11:59:00 -0000

AMQP nodes and containers are introduced in the core AMQP specification. This specification introduces a further concept: areas. An area identifier is a string that follows DNS naming conventions. Area expressions are matching conditions that can be evaluated against area identifiers for routing or filtering. Area identifiers are used for routing messages or links across AMQP container boundaries, potentially with one or more containers acting as routing intermediaries. Instead of having to handle container-ids for all potential routing targets, routing intermediaries can evaluate area expressions to determine which container to direct the message to. An area identifier is a structured name that represents a logical routing target or source scope. The term area reflects that the addressed scope has further internal structure in form of nodes, and therefore an area never identifies a singular, specific target or source. While area identifiers follow DNS naming conventions, but they do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical scopes in a system, and the DNS-like structure helps expressing hierarchical relationships, structuring routing scopes from very broad to more scoped areas. While the identifier of a container MUST be unique and stable within an AMQP network, areas are more flexible. A container MAY have any number of associated area aliases. Reversely, an area alias MAY be associated with several containers. Von: [email protected] <[email protected]> Im Auftrag von Clemens Vasters Gesendet: Mittwoch, 7. November 2018 12:41 An: Rob Godfrey <[email protected]> Cc: Alan Conway <[email protected]>; oasis-amqp-list <[email protected]> Betreff: AW: [amqp] Addressing Model Blog Post You may just have convinced me of area (or realm , which is a synonym) We address areas (which may be realized by one or more containers) and then dispatch to nodes inside those areas. Von: Rob Godfrey < [email protected] > Gesendet: Mittwoch, 7. November 2018 12:15 An: Clemens Vasters < [email protected] > Cc: Alan Conway < [email protected] >; oasis-amqp-list < [email protected] > Betreff: Re: [amqp] Addressing Model Blog Post I think of it as more of an area or (address) space than a point or spot (terms which I don't think give the sense that they contain addresses within them). Place is.. . fine... I guess -- Rob On Wed, 7 Nov 2018 at 11:42, Clemens Vasters < [email protected] > wrote: Given that destination has too much of a from here to there directional implication, let s try terms that are only about where you want to messages to go or come from: Place? Spot? Point? A place identifier is a structured name that represents a logical routing source or target. Place identifiers are strings that follow the DNS naming conventions, but places do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. A spot identifier is a structured name that represents a logical routing source or target. Spot identifiers are strings that follow the DNS naming conventions, but spots do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. A point identifier is a structured name that represents a logical routing source or target. Point identifiers are strings that follow the DNS naming conventions, but points do not have to be registered in DNS and they don t have an associated IP address. They are just names describing logical entities in a system, and the DNS-like structure helps expressing hierarchical relationships. Von: Clemens Vasters Gesendet: Montag, 5. November 2018 19:52 An: Alan Conway < [email protected] > Cc: oasis-amqp-list < [email protected] > Betreff: AW: [amqp] Addressing Model Blog Post Container so strongly associated with docker/kubernetes/etc that I consider it a burned term for the time being. Von: Alan Conway < [email protected] > Gesendet: Montag, 5. November 2018 19:49 An: Clemens Vasters < [email protected] > Cc: oasis-amqp-list < [email protected] > Betreff: Re: [amqp] Addressing Model Blog Post On Mon, Nov 5, 2018 at 1:23 PM Clemens Vasters < [email protected] > wrote: The rule is that you can t say no without constructively offering a better alternative :) Rules, rules. I like "container-name" - by analogy with "domain-name" - it is a hierarchical name for a collection of things that might themselves be containers, and may also be name that maps to concrete protocol info (on-ramp info rather than direct IP addresses). I wouldn't mandate that container-name == container-id but that would probably be sensible in some systems. Container is pretty heavily overused but it doesn't feel like it would cause confusion and it is suitably vague. I know destination isn t ideal for the exact reason you point out. I think of it as a working term until we find something better that doesn t clash with address or host . Von: [email protected] im Auftrag von Alan Conway < [email protected] > Gesendet: Montag, November 5, 2018 6:09 PM An: Clemens Vasters Cc: oasis-amqp-list Betreff: Re: [amqp] Addressing Model Blog Post Interesting read! I'm in general agreement with the proposed syntax and rationale. But I have a Nit to Pick: "In the OASIS AMQP Technical Committee, we will add the abstract notion of destination into the addressing specification". NOOOooooo! It can't be called a "destination"!! to:( fred.com )/x - sending stuff to a thing in fred - very destination-like source:( fred.com )/y - getting stuff from a thing in fred - NOT A DESTINATION ( fred.com ) could contain targets, sources, request-response servers, named or anonymous relays, who knows what else. It might be reached by opening a TCP connection, accepting a TCP connection, routed intermediaries, sidecars, fabrics, clouds, fogs, bogs or homing pigeons. It is in no sense limited to being a "destination" of anything. (I'm senstive from efforts to bridge bi-directional AMQP to HTTP technologies steeped in unidirectional-client-server assumptions. I really don't want assumptions of directionality in the language of the AMQP addressing spec itself!!!) Not sure what to call this protocol-independent name/identifier/address, but it can't imply one-directional communication: container, node, host, endpoint, thing, object, place, name, moniker, handle, doohicky ... the English language doesn't have enough vague nouns for our industry. On Thu, Nov 1, 2018 at 5:28 PM Clemens Vasters < [email protected] > wrote: I put together a blog post on the considerations behind the proposed addressing model that we discussed on the last call and looking ahead to what a complementing routing spec might cover https://vasters.com/blog/a-new-network/ -- _____________________________________________________________________________ Red Hat GmbH, www.de.redhat.com , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill