On 01/26/2011 02:34 PM, Alan Conway wrote:
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.
I agree.
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.
I like this. No need to use namespaces for the generic type system, only
for the concrete ones.
And yes: the type determines the meaning of the properties, and the
properties should have the same names they have in the underlying protocol.
For instance:
create(type:"amqp0-10/exchange", name:"d", properties:{type:"direct"})
In this case, we're using the name 'type' twice, but that's OK.
As an argument to create, type:"amqp0-10/exchange" means what our
generic type system says it means. This type is used to interpret the
properties map.
In the properties map, 'type' means whatever an amqp0-10/exchange thinks
it means. That means I can refer to the AMQP 0-10 documentation to
interpret it.
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.
I agree.
I think that makes both the generic types and the concrete types simple
and clean. And the user doesn't have to learn how to map between them.
You can use declarations in either type system. The generic type system
is flexible enough to allow links between nodes declared in various
concrete systems or in the generic one.
Do we want to be able to support other messaging models other than AMQP?
Do you have anything specific in mind here?
Stomp is one example, or any other protocol we decide to support in the
future.
What happens if two different systems use the same name for different
things?
namespaces resolve this problem and leave things open to extension.
I agree. And we really need the namespaces only in the type attribute
for declarations that use the concrete type systems.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
