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.
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.
Thoughts?
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
