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] Groups - AMQP Addressing Working Draft 6 uploaded


Here's a short write-up of my thoughts on merging "authority" and "scope". Essentially a non-DNS Clemens scope corresponds to a "private global address" as outlined below. This is very abbreviated, not counter-proposal just thoughts for discussion.

# AMQP URIs and addresses

An AMQP URI is a [hierarchical URI](https://tools.ietf.org/html/rfc3986#section-3) with one of the following schemes: amqp, amqps, ... (others from draft 6)

An AMQP *address* is a [relative URI reference](https://tools.ietf.org/html/rfc3986#section-4.2) that MUST NOT have a scheme part. The RFC defines 3 kinds of reference:

1. "Network-path": //authority/path[?query]
2. "Absolute-path": /path[?query]
3. "Relative-path": path[?query] (no leading /)

AMQP addresses are used in message `to` and `reply-to` fields, link source and target `address` fields, and any other place where the AMQP spec requires an "address". Addresses MUST NOT start with a scheme prefix like "amqp:" or "amqps:".

Network-path addresses (//authority/path[?query]) are termed "global" addresses". Absolute-path and relative-path addresses are termed "local addresses".

An AMQP URL is an AMQP URI where the authority part can be resolved to an IP address for example a DNS name or IP literal, with or without a :port.

## Local addresses

A local address is of the form `/path[?query]` or `path[?query]`

AMQP applications within a single organization typically will use local addresses. Local addresses can be routed by AMQP routers for flexible deployment, load balancing and so on.

An AMQP URL can be decomposed into connection information and a local AMQP address. The local address is simply the "/path" part of the URL.

Local addresses do not by themselves allow you to make a connection, you need to connect to a route or broker that can process the address. Typically this will be to a co-located "sidecar" or a locally-configured default router URL.

## Internet-global addresses

An internet-global address is of the form `//authority/path[?query]" where the authority can be resolved as an IP address. Such an address can be converted to or from a URL by adding or removing an "amqps:", "amqp:" or other suitable scheme.

An internet-global address can be used to route messages within an AMPQ network, since the authority is available to the AMQP routers to make routing decisions. It can also be converted to URL, passed to non-AMQP applications, and used to re-create a connection to the AMQP network later.

Internet-global addresses can be used for public internet-scale applications, but also for private applications that use internet tools like DNS or IP load-balancing, virtual host routing and so on.

## Private global addresses

A private global address is of the form `//scope/path[?query]` where the authority part does not correspond to a DNS or IP address, but to some privately-controlled unique "scope".

In this case, all endpoints must be configured with suitable "on-ramp" DNS or IP addresses, or co-located with a suitable sidecar to make an initial connection.

Once a connection is made, AMQP routers can use the authority information to route messages. There's no need to convert private global addresses to URLs since all participants in the system know how to connect to an "on-ramp".

# JustificatioMy claim is that there are 3 cases to consider:

1. Existing AMQP systems manage fine with just a free-form path-style address, including routed systems like dispatch router. They should be able to continue using URLs of the form amqp://connection-info/amqp-address, with free-form paths for routing, and using virtual-host for orthogonal scoping/tenancy etc.

2. Global addresses that are both connectable AND routable have obvious appeal. In this case scope==authority==DNS/IP. This fits with virtual-host based routers since a router can qualify a local addresses by using the virtual host as the authority in a global address, thus a client that connects to vhost foo.net and uses addres /x and a client that connects to //foo.net and uses address //foo.net/x can both be routed to the same global address. (This is for link addresses, immutable message addresses have to be global from the get-go if they need to be, as they can't be modified however read coming rant on the proper use of link and message addresses :)

3. Global addresses that are routable but NOT connectable have obvious appeal for systems that don't use DNS/IP/virtual-host approaches to identify an "authority" as part of their routing strategy. For them the authority (aka scope) can mean anything they want.

This proposal covers all 3.



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