Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of rob.j.godfrey@gmail.com
 designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54008D1D.3000609@redhat.com>
References: <5400865A.4040309@blueyonder.co.uk>
	<CACsaS96u+SbWHz7mCGAwyQ1W5mjmykUK7hSQ8h+4mY7uV3kRsg@mail.gmail.com>
	<54008D1D.3000609@redhat.com>
Date: Fri, 29 Aug 2014 16:42:27 +0200
Message-ID: 
 <CACsaS95HGkLCAOF2UJSEW1SjpvoJSCjjSn-ZoEhwJkwdQVrVfQ@mail.gmail.com>
Subject: Re: Use of subject for routing - moved thread to user list from
 earlier private discussion.
From: Rob Godfrey <rob.j.godfrey@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=001a11c120148645900501c5a962

--001a11c120148645900501c5a962
Content-Type: text/plain; charset=UTF-8

On 29 August 2014 16:24, Gordon Sim <gsim@redhat.com> wrote:

> On 08/29/2014 03:12 PM, Rob Godfrey wrote:
>
>> In general, however, I think the subject is not the best fit for a mapping
>> of the semantics of the 0.x "routing-key".  The AMQP 1.0 spec defines
>> subject as "A common field for summary information about the message
>> content and purpose", rather than giving it and explicit or implicit
>> routing semantics.
>>
>
> In my view, the 'routing key' in the old exchanges model is intended to be
> exactly such a logical categorisation of the messages content or purpose.
>
>
>
But the definition is "summary"... such as "Use of subject for routing -
moved thread to user list from earlier private discussion." is a summary
for this thread.  It does not in any way imply structured.


>   The "to" field is defined as "identifies the node that
>> is the intended destination of the message" which definitely implies some
>> routing semantics but does not make them explicit.
>>
>
> As you state, the to field identifies the destination. That is not what
> the old exchange types are about in my view. In the typical use cases for
> that old model, the sender doesn't want to describe who gets the queue,
> they merely want to indicate the type or purpose of the messages. It is
> then through the bindings that this type is mapped to the appropriate
> recipient(s).


The to field indicates the destination in terms of what the sender wants to
send it to.  It says nothing about where it actually arrives.  How an
address is translated to an ultimate recipient of the message is a property
of the network, that the sender can be unaware of.  Note that I think here
that the Messenger use of explicit hostnames/ports in "addresses" is
confusing. This might be a particular use case for addresses, but I think
in general the tying of addresses to physical locations is a very bad
thing.  Addresses are logical.

I think the issue here is how many fields you expect the sender of a
message to have to populate to route a message.  In 0.x the model generally
implied  two fields "exchange" and "routing-key" that taken together would
allow the intermediary to route the message.  My take on the mapping to
AMQP 1.0 is that one should consider this as a compound address
"exchange/routing-key".  As such the AMQP 1.0 address is actually more
opaque and allows more indirection than the 0.x form where the sender of
the message was made aware of a distinction between exchange and
routing-key (and in fact the method of routing was de facto also being made
explicit).


>
>
>  If an application is designed around using AMQP 1.0, I would not normally
>> expect them to be putting routing information in the subject field.
>>
>
> That depends on what you define to be routing information. I think it is a
> perfectly sensible approach to use the subject to indicate some sort of
> logical category and then have the broker be configured to 'route' messages
> according to that logical category.
>

I think that's one choice you could make, certainly.  I just think it's a
bad choice for the general case.  I think using a single field to provide
the information you wish the message to be routed on is, in general,
superior.  In practice if one wants to add supplemental fields for routing
I think it would be better to use application properties.  By using an
application property it is easier for messages coming from other APIs (such
as JMS) or messages being translated from other protocols (where the notion
of application structured data is common) to also use the same routing
semantics.

-- Rob


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

--001a11c120148645900501c5a962--