Robert Godfrey wrote:
I think we need clarity about whether we are defining a format for
*JMSDestination* or for some other AMQP abstraction of
consumer/producer/link.
As I understood it, the idea was to try to define JMS Destinations over
AMQP in terms of some more general format for configuration of AMQP
senders/receivers.
The JMS definition is quite clear that the destination represents only
the address ("A Destination object encapsulates a provider-specific
address") - therefore properties of queues, etc should not form part
of its definition. In particular consider the case where you use
setReplyTo(JMSDestination) ... the *only* information that is
actually sent over the wire is (correctly) the address.
The JMS definition also states that "Since Destination is an
administered object, it may contain provider-specific configuration
information in addition to its address."
The reply-to is certainly an important case to consider though. In AMQP
0-10 in particular there is a very rigid structure defined for
exchanging that information.
Even where a less restricted format on the wire is used, the question of
what is valid to convey in reply-to is an interesting one. I myself see
the notion of an address to an automatically created entity as less
problematic in this regard than the attachment of producer and/or
consumer specific configuration (which to me is more clearly independent
of the address itself).
In the case above. if you use
dest.D = MyQueue; {auto-create={durable=true, ...}, ...}
as a destination for ReplyTo then the receiver of the message will
have to create the destination as the equivalent of
dest.D = MyQueue
The receiving client will not hear that it is supposed to create the
queue and make it durable.
JMS further mandates that the destination you receive on your incoming
message should have equality with the original address as set. This
means that *only* the address can be examined in .equals() tests...,
hashCode(), etc... Therefore making queue properties part of the
JMSDestination seems to be somewhat misleading.
If we were discussing the configuration for AMQP 1-0 style links then
I would completely agree that having everything on the one line would
make sense...
For JMSDestinations I am more opposed.
What in your view would be the ideal way to allow the JMS API to be used
unaltered and yet (a) support different exchanges such as the headers
and xml exchanges more cleanly, (b) allow a subscription that is
implemented as more than one binding and (c) allow properties of senders
and receivers to be configured?
The Destination abstraction is very tempting as an extension point of
sorts and as a means to provide configuration independent of any code
changes. I accept this is not without its problems.
The current Qpid JMS client does in my view need some urgent attention
here however. The existing 'binding url' notation is restrictive and
confusing and even the behaviour of the standard destination types is in
my view not ideal.
--Gordon.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
