On 29 August 2014 16:24, Gordon Sim <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
