some thoughts on 'global addressing'

[Gordon Sim <gsim@redhat.com>]

Just to get the discussion going and express my views as I will not be 
able to attend the planned F2F.

My 'proposal' is deliberately very simple. The bulk of the text is 
trying to clarify my thinking on why we do need something (and I think 
we need it soon), but why that can - and should - be kept very simple.

Comments, corrections, criticisms are all welcome!

Global Addressing
-----------------

Context
~~~~~~~

An addressing scheme allows the logical flow of messages in a system
to be defined, i.e. which messages go where. A global addressing
scheme is one that can be relied on across administrative domains and
across diverse implementations of the protocol.

An address identifies a conceptual message source and/or a message
sink; it defines a logical location from which messages can be
received or to which messages can be sent.

A given source or sink is not necessarily confined to a specific
process; sources and sinks may be distributed entities. A given
process may also contain several source and sinks.

The naming of sources and sinks is therefore distinct from the
addressing of a process.

Scope
~~~~~

In AMQP 1.0, addresses are used:

a. in the 'address' field of a source and/or target specified when
attaching a link

b. in the 'to' field of a messages properties

c. in the 'reply-to' field of a messages properties

The syntax and semantics of such addresses should be defined along
with any rules or recommendations associated with their use in
conjunction with the link protocol.

Use Cases
~~~~~~~~~

a. An application may wish to access multiple AMQP based services each
of which is in a different administrative domain. The administrators
of the domain in which the application itself exists may desire all
the AMQP traffic to go through a proxy where it can be logged for
audit or where particular patterns of use can be enforced. The proxy
needs to be able to easily disambiguate addresses that are logically
distinct but may share a name and to easily identify the domain in
which a given address resides. Though a hostname sent with the open
request could be used to infer this, a more direct mechanism may be
beneficial.

b. An area of great interest at present is messaging 'in the
cloud'. Though this could be interpreted in many ways, one image
conjured up is of an application attached to a network at a single
point, and able to communicate with other similarly attached
applications without being forced to establish direct physical
connections or have any detailed knowledge of their
whereabouts. Communicants can be moved around without disrupting
communications. Allowing a hierarchical, domain based naming scheme
provides a simple way to avoid collisions without central coordination
of all names.

c. The typical request-response pattern has the service send any replies
for a given request to the specified reply-to address. In the context
of a single logical broker this poses no problems. However if requests
arrive via other intermediaries, the task of getting the responses
back to the original sender of the request is more involved. A global
addressing scheme would assist with this by providing a clear basis on
which to route responses. (Note that here, the hostname specified by
the client issuing the request is not available to the service).

Requirements
~~~~~~~~~~~~

The addressing scheme should provide a way to disambiguate a name used
in two or more different domains.

A simple name as used by current brokers to identify a queue or a
topic must be a valid (if globally ambiguous) name.

The addressing scheme should not require addresses to be explicitly
tied to particular hosts.

Proposal
~~~~~~~~

A simple, direct way of meeting the requirements is to define the
address as comprising a 'local part' followed by an optional 'domain
identifier', the two being separated by the '@' symbol. I.e. something
like the typical email address.

A container processing a link attachment from its peer can examine the
source or target address and determine based on any supplied domain
how to treat it, or indeed decide whether it can handle it at all.

If a domain exists and it is not the domain of the container, then the
container knows it needs to be routed elsewhere and can determine if
it knows how to do so. If there is no domain, or the domain is that of
the container itself, it would try to resolve the local part to some
node.

This deliberately avoids defining how, given a particular address, a
container should establish the necessary connection and link over
which to transfer the message. The configuration of physical routing
is kept distinct from the logical addressing.

It may use DNS to look up a host to connect to, either assuming the
standard AMQP port or using an SRV record. It may use a routing table,
either statically configured or dynamically updated through some
auxiliary protocol. Different routing strategies may be appropriate
for different contexts and different types of container. Keeping them
entirely distinct from the addressing scheme allows a universally
understood logical name space to be flexibly mapped to a more physical
topology.

There may well be benefit to defining and standardising such routing
strategies. This would seem to be relevant to the pursuit of a
standard approach to management for example. The key point is that it
is distinct from the establishment of a standard address syntax.

A URL based approach is more amenable to 'tweaking', whether through
adding username and password, query string options or even distinct
URL schemes. This level of extensibility is not desirable for the
addressing scheme as it encourages non-standard controls to be encoded
into messages themselves rather than being specified through auxiliary
policies defined for the containers they travel through.

A URL based approach also either requires all addresses to be full
URLs or makes parsing ambiguous and more complicated. The only
retriction placed on the local names in the scheme proposed above is
that they don't conatin the '@' character. That allows for very simple
address parsing.

There are already implementations of AMQP 1.0 that will not recognise
the proposed syntax. For example a broker may not recognise that
'my-queue@my.domain.com' is actually the same as my-queue if the
broker is in the specified domain. To ease transition it would be
ideal if in such a situation, messages intended for that queue would
be sent in the last hop over a link attached with the target being
simply 'my-queue'. This is something that could be left to the
orthogonal routing rules. It could perhaps also be aided by a
recommendation around the container id (e.g. if the container id
matches the domain name, the domain name can be left out of the
address used when attaching a link).