I think we really need this, and I like the basic solution quite a bit.
I propose initially to support creation and deletion of three basic
object types through this mechanism: queue, exchange and
binding. Exchanges will have 'topic' as a type alias and will also
recognise a sub-type property, corresponding to the AMQP 0-10 exchange
type. The default will be topic exchanges. This matches the current
usage in the addressing syntax for the messaging API.
I'd prefer to keep a single declaration in one semantic world. I know
what a "direct exchange" is. I don't know what a "direct topic" is.
In the near term, I think we're dealing with three separate semantic
domains:
AMQP 0-10 (+ Qpid extensions)
Qpid Messaging API
AMQP 1.0
I think I'd like to be able to declare the objects we currently support
directly. That includes AMQP 0-10 and the Qpid extensions.
I'd rather not have a declaration mix constructs from two different
semantic domains unless there's a clear advantage to doing so. So I'd
like to be able to say "create direct exchange", not "create direct topic".
Do we need to allow the user to declare Messaging API topic? If so,
adding 'create topic' is easy, I'd like to avoid support for x-declare,
x-bindings, and x-subscriptions at this level.
I would expect AMQP 0-10 objects to be mapped to their equivalents in
AMQP 1.0 and the Messaging API. In the future, will we want to have
support for directly declaring AMQP 1.0 nodes and links?
Likewise there are alternative ontologies for the objects thus created
(or deleted). While 'queue' is probably obvious and uncontroversial,
exposing exchanges and bindings are possibly less so. The rationale
here is to find a simple solution that adequately (and intuitively)
supports the AMQP 0-8 to 0-10 model for those familiar with it (which
is after all the only model currently supported), while alluding to a
transition to one where the pub-sub topic concept is more completely
and explicitly supported.
I agree that we should do this.
The set of types will be easily extensible (e.g. could even be extended
to cover the links and bridges used in the current inter-broker routing
solution).
Do we want to be able to support other messaging models other than AMQP?
What happens if two different systems use the same name for different
things?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
