The new messaging client API is designed to hide the details of specific
AMQP versions. This causes a certain impedance mismatch with the
maangement tools and the existing APIs, which are centered around the
AMQP 0-10 model, with exchanges, bindings, queues, etc. To use the new
API, a programmer need not think of exchanges at all, but anyone who
uses the management tools sees these exchanges and needs to understand
the mappings.
This made me think about the way we use Java JMS with AMQP 0-10, even
though the models are quite different.
Should the new API be used in the same way as the Java JMS client? We
could provide a way to use an existing Java JMS properties file in the
client for each language (I assume other languages would ignore the
java.naming.factory.initial ).
Or should we provide a separate configuration API for each version of
AMQP that we support, since the semantics used for configuration are
significantly different, at least between 0-10 and 1.0? The new API
could provide a set of messaging semantics that covers everything except
for configuration and is independent of the AMQP version, and there
could be a separate API for configuring the plumbing in each version of
AMQP.
Obviously, we could do both. And of course, people will also use the
management tools to configure their brokers.
If we separate configuration from messaging per se, the high level API
can be nicely independent of the bumps and wrinkles of a given AMQP
version, and the configuration APIs can give full control. I think
that's what we should want.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
