On 01/24/2011 08:30 AM, Gordon Sim wrote:
On 01/21/2011 07:18 PM, Jonathan Robie wrote:
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".
The request to create a direct exchange would be something like:
create (type:"exchange", name:"abc", properties: {"sub-type":"direct",
"durable":True})
If the sub-type property is omitted, the default is a topic exchange. E.g.
create (type:"exchange", name:"abc", properties: {"durable":True})
I'm not sure whether 'sub-type' should be the *actual* name for the property
here. Perhaps something a little more explicit and specific would be clearer,
e.g. x-amqp010-exchange-type. The counter-argument perhaps is that sub-type
could be more generally useful e.g. in allowing one to specify a ring queue or a
last-value queue and uniformity might be helpful. TBD in updated draft.
So it seems like we have an open ended collection of concrete type systems here:
amqp0-10
amqp1-0
amqpx-y
(stomp or whatever future protocols we support)
And we have a "generic" type system with 2 types (so far): topic(=exchage) and
queue. These are implemented in terms of whatever concrete types are available.
We want it to be easy to create objects using the generic system, while at the
same time providing "escapes" to let the user directly create objects and tweak
properties for the underlying system if they want to. Since the set is open
ended it seems like namespaces would be appropriate here.
If we follow the classic "constructor" pattern, then we should separate
identifying the type from the arguments to create an instance of that type. The
type defines the meaning of the properties so it seems a bit murky to use a
properties to determine the type.
So how about:
create(type:"topic", name:"abc", properties:{...}) - create a generic topic
using whatever underlying protocol
create(type:"amqp0-10/exchange", ...) - specify a 0-10 exchange
create(type:"stomp/foobar", ...) - specify some other protocol's object
etc.
That leaves us open as to future type systems and gives us enough information in
the type name to determine the meaning of properties - allowing each concrete
type to define whatever set of properties with whatever names it desires.
This also means the generic types can take a "clean" set of properties - i.e. no
"x-binding" or other protocol escapes. The generic types have a well defined set
of properties that always apply regardless of the underlying type system - so
you can write portable code.
The concrete types *also* can have clean property lists - i.e. just "binding"
rather than "x-binding", since the fact that you're tweaking the underlying type
is already stated in the type name and need not be re-stated in the property names.
Do we need to allow the user to declare Messaging API topic?
Yes, I believe that is desirable. If I want to send to a queue, I could have a
setup script that issued a create request for an object of type queue. If I want
to do the same for a 'topic' (as in JMS or in the messaging API) then it would
be nice to be able to simply issue a create request for the appropriately named
topic.
I would guess we want to align the address string format with the generic types.
Do we want to be able to support other messaging models other than AMQP?
Do you have anything specific in mind here?
What happens if two different systems use the same name for different
things?
namespaces resolve this problem and leave things open to extension.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
