[rabbitmq-discuss] Exchanges, Routing, and AMQP

[Ben Hood]

Kirk,

On Mon, Oct 20, 2008 at 4:01 PM, Kirk Wylie <kirk at kirkwylie.com> wrote:
> Personally, I believe that the spec should be changed so that
> exchanges are nothing other than producer-provided namespaces/groups
> of related messages, and consumers should bind to exchanges based on
> the semantics that they want.

I think you may find resonance with some members of the WG on this
issue. However, moving the routing algorithm to the binding does have
a practical implication from an implementation perspective. This would
turn any routing decision into a linear scan of all of the bindings in
order to perform a match on the routing type :-( You would not be able
to exploit any type-based indexes.

> Backwards Compatibility?
> Yes, you can still achieve backwards compatibility here, particularly
> with the "implicit" exchanges, by allowing exchanges to have "default"
> routing rules which are specified by the producer's exchange assertion
> (or the default assertion). This means that existing applications will
> continue to work, and you can develop new applications with consumer
> driven bindings that all work.

This is true, but I think until AMQP goes 1.0, you should, IMHO,
prioritize design over backwards compatibility.

I think it may not necessary be a good idea to de-characterize an
exchange to the extent that it merely represents a logical address. If
you were to do so, you would be automatically precluding semantics
that you could efficiency build into a custom exchange (e.g. an
exchange that delivers to a subset of the matching binding - for
example the shortest queue).

Furthermore, you can bring the consumer driven-ness into the realm of
your app by having a convention that prevents a producer from
declaring exchanges - if the exchange doesn't exist, then the producer
will not be able to send messages to it.

Cheers,

Ben