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: AW: [amqp] Addressing Model Blog Post


We canât just use the path because we really have three addressing realms:

  • IP network space
  • Inter-Container overlay network
  • Intra-Container node space

 

The node space (the path) is something we canât futz with for backcompat reasons if nothing else.

 

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 17:29
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post

 

 

On Thu, Nov 8, 2018 at 10:56 AM Clemens Vasters <clemensv@microsoft.com> wrote:

While the authority does not have to have a DNS mapping, thatâs the general assumption.

 

If you want reach a place on an overlay network, you first need to be able to connect the edge of that overlay network and then route within that overlay network. Those are two address spaces. 

The goal of the URI construct is to be able to express both the edge address and address inside the overlay network in one address. If you just want the overlay network address, you use amqp:(scope)/foo

 

OK I buy that, but I'm starting to feel that inventing something we can't name is a Hint from the Universe. 

The URI framework already has a way to specify hierarchical scopes that are not part of the authority - the path.

 

Why is "amqp://foo.net/(a.b)/c/d" preferable to "amqp://foo.net/a/b/c/d? The former does not provide any information that clients can use, it is harder to construct/parse and it seems to imply knowledge of the internal routing of messages that clients really should not have. If (scope) is not an authority, a host name, or a container ID, then it is simply part of a hierarchical string to be interpreted by AMQP entities, it has no special meaning that deserves special syntax. If you restructure your application something that was (a.b)/c might end up more like (a)/b/c or (a.b.c) - better to expose an unchanging "a/b/c" to clients.

 

 

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 16:51
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post

 

I feel that the distinction between domain name and scope identifier is a hack. Why not follow internet tradition and make an AMQP address is a classic URI

 

     [amqp:][//authority][/path][?query]

 

The authority (aka host) *is* the scope identifier. In an AMQP context (link or message to:/reply-to: address) we mandate dropping the redundant amqp[s]: prefix, which is pretty close to the last addressing draft I read.

 

Introducing a new scope-id adds some flexibility, but also more complexity. Re-using the URI authority (aka DNS domain name, aka virtual host name) means we can re-use a lot more existing DNS, virtual host and URL technology that is already mature and well  understood.

 

A URI authority does not *have* to have a DNS IP mapping. If it does it is a connectable URL, if not it can still be used by apps that have a pre-existing connection to an AMQP router. Whether connectable or not, it can be used for AMQP-smart routing just like a separate scope-id could be.  Virtual host names can be associated many-to-many with IP addresses, and once messages hit an AMQP router they can further be associated many-to-many with AMQP containers, on the same or different IP hosts. HTTP already does this.

 

To bootstrap an application with amqp://myhost.net/foo, the client connects to myhost.net and links to //myhost.net/foo for possible further routing, or to the relative address /foo if it is a direct connection to the final container (many existing AMQP apps will do this) For a non-connectable //myscope.net/foo, the client needs a pre-existing connection but the routing information is the same.

 

I can't imagine any routing scenario where you don't have virtual host names to map your AMQP scope-ids flexibly to the proper IP "on-ramps". Also re-use of virtual host plays well with existing router apps (like Qpid Dispatch) which already use virtual host to effectively "fill in" missing scope/authority from "relative" addresses used by existing clients. In fact using a combination of AMQP  URI authority and virtual host (if different) gives essentially your amqp://vhost/(authority)/ but without the awkward 2-stage UIR.

 

On Thu, Nov 8, 2018 at 1:15 AM Clemens Vasters <clemensv@microsoft.com> wrote:

This morning I donât like âareaâ anymore, either. Scope is good. 

 

(Oh how I hate naming things)

 


Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, November 8, 2018 12:36 AM
An: Clemens Vasters
Cc: Rob Godfrey; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post

 

 

On Wed, Nov 7, 2018 at 6:59 AM Clemens Vasters <clemensv@microsoft.com> wrote:

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.

 

 

How about  "scope identifier"? "area" doesn't really give me the idea of a namespace or name domain, and you used "scope" 5 times while explaining what "area" means.



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