qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: JMS Destination handling for AMQP 1.0
Date Wed, 17 Dec 2014 13:43:35 GMT
On 17 December 2014 at 13:37, Robbie Gemmell <robbie.gemmell@gmail.com>
> Hi everyone (please use reply-all to keep both lists on the trail),
> I would like to have a discussion around JMS destination handling in
> the JMS Mapping for AMQP 1.0, in particular around how to handle JMS
> Destination names via the AMQP "address" field of a link
> (producer/consumer) source/target and the "to", and "reply-to" field
> of messages.
> Apologies for the length of the mail, there is a fair bit to outline.
> I moved some information for full context to the end to help a tiny
> bit.
> JMS defines multiple Destination types that each have their own
> inherent name space, so it is possible for example to have a Queue and
> a Topic with the same name (e.g "foo"). AMQP defines an "address"
> field on the source/target of links (producers/consumers), and a "to"
> and "reply-to" field are available on messages, to indicate the
> destination node (e.g queue/topic) address. These are typically string
> values, and they form a single space since as there is no additional
> node type information only the address name itself.
> This is is mostly an issue for non-temporary Queues and Topics since
> TemporaryQueue and TemporaryTopic destinations will be given generated
> addresses by the 'broker' peer through use of dynamic nodes, and so
> can naturally be prevented from having the same addresses as each
> other, and be made unlikely or unable to clash with non-temporary
> nodes.
> To handle this mapping between JMS and AMQP it would seem we must either:
> 1. Not support JMS Queues and Topics with the same name existing at all, OR
> 2. Allow multiple nodes to have the same address string but use type
> metadata (via capabilities + annotations, see additional context) to
> discriminate between them, OR
> 3. Utilise address string naming conventions (e.g prefixes) for them
> to separate the types into subspaces.
As per the OASIS TC call yesterday, I think option 3 is the only truly
viable solution here.

> The first option is an issue for implementations that already do, and
> wish to continue to, allow Queues and Topics with the same name via
> other protocols while also supporting AMQP, and would be a limitation
> in terms of full JMS support. The second option would break reply-to
> usage for any clients or intermediaries that don't understand the
> message annotations and/or source+target capabilities carrying type
> metadata (see additional context). The third option either requires
> clients to always utilise the full address strings in
> session.createQueue("<queue-prefix>foo") etc calls, or providing a
> means to configure the prefixes within the client so that they are
> added/removed behind the scenes and the application just uses
> session.createQueue("foo"), but the resulting AMQP address string
> would be "<queue-prefix>foo". The main issue with requiring clients
> always use the full address as the session.createQueue(..) value would
> be for bridging between different systems using different conventions,
> though the values for those methods are noted as being
> provider-specific.
> Both the old Qpid AMQP 1.0 JMS client, and the new JMS client we are
> creating that implements the JMS Mapping for AMQP being worked on,
> currently do some form of the third option, providing a way to
> configure a 'queue prefix' and 'topic prefix' that are used to prefix
> the application provided strings in session.createQueue(..) etc for
> outgoing addresses used for links and messages and be stripped from
> incoming addresses on messages to give the names used for the
> JMSDestination and JMSReplyTo objects. Temporary destinations are
> named by the 'broker' peer and their addresses are used as provided.
> The main issue with this approach is that such configuration makes it
> more difficult to use the client against a number of different
> brokers, which is a goal, since this configuration is likely to differ
> between them meaning even the simplest HelloWorld type example may be
> unable to work against them without additional configuration. Between
> ActiveMQ and Qpid we currently appear to have 3 different options for
> our brokers (two different prefixes being required, or it being
> optional [at the cost of being unable to support Queues and Topics
> with the same name]), and considering others would likely expand this.
> An idea to handle this was to have the brokers use connection
> properties to inform the client of the prefixes (if any) they require
> it to use, allowing different brokers to supply their own specific
> value (if any) to meet their requirements, and allowing clients/simple
> applications to work against many of them without further
> configuration change.
> An alternative suggestion was to have the JMS Mapping define a set of
> standard name prefixes the client would use by default, such that the
> issue of Topics and Queues with the same name is addressed by the
> mapping, while also allowing brokers to specify their own values via
> connection properties so that their specific needs can still be met if
> different (e.g they have existing naming conventions they wish/need to
> retain).
> There was also a suggestion that something beyond a simple prefix may
> be needed, I will let the person behind those thoughts expand further
> to stop this getting any longer for now.
That'd be me, I guess :-)

My comment on prefixes is mainly that the work on the "global"
addressing would potentially impact on "valid" address names, and that
a simple prefix such as "queue:" might prevent the use of such
addresses in a global context.  As such I would probably favour a more
flexible (e.g. regex) mechanism for name "mangling".

> Thoughts?

A quick thought on Destination equivalence - I'm guessing that in JMS
terms two Destinations are equal iff they are of the same type
(Topic/Queue/etc - derived from meta-data) and use the same *mangled*
AMQP address?

-- Rob

> Robbie
> Additional Context:
> We also need to transmit the destination type information during link
> (e.g producer/consumer) attachment and on sent messages to ensure we
> can support the required JMS behaviours (e.g. to indicate we are
> attaching to a particular type of node, say a queue, and for carrying
> JMSDestination and JMSReplyTo type on messages to indicate/discover
> where a message was sent).
> For handling these points we are defining the following behaviour:
> # During link attachment for producers/consumers:
> - Node name carried in source/target "address" field string.
> - JMS Destination type represented by capabilities on the
> source/target (e.g "queue", "topic", "temporary-queue",
> "temporary-topic").
> - Clients can optionally assert on the attach response that the
> required capabilities exist in the source/target to ensure they have
> attached to a node that meets their requirements.
> - 'Broker' peers can use the capabilities to determine the type of
> node to create if it is a dynamic node being requested (or if they
> support auto-creation of non-temporary nodes).
> # When sending messages:
> - Node names carried in "to" and "reply-to" fields as appropriate.
> - JMS Destination type carried in "x-opt-jms-dest" and
> "x-opt-jms-reply-to" message annotations as a byte.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message