Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACsaS95vSfmSaCFmROBB6nnSfaonqhdt8F-ycGCdLanmfk1wNA@mail.gmail.com>
References: 
 <CAFitrpReQiKoZZWXJ5i0rKocEDwgLrpL8_0fr6R5A-Yzmimt=Q@mail.gmail.com>
	<CACsaS97Lku4apq+SMeD5Xv2L13D116y0hwgC1BPFAOGs83J+uA@mail.gmail.com>
	<CAFitrpRzLFw8q7a0Caq=Di55Vw-AhtVvWcRg-oc=uY-fwUSPHw@mail.gmail.com>
	<CACsaS95vSfmSaCFmROBB6nnSfaonqhdt8F-ycGCdLanmfk1wNA@mail.gmail.com>
Date: Wed, 17 Dec 2014 16:25:08 +0000
Message-ID: 
 <CAFitrpRsSxoJsT9H0rLvCuNn1Mo+sOfVnAowb6Rk_BBa=Muz9Q@mail.gmail.com>
Subject: Re: JMS Destination handling for AMQP 1.0
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Cc: dev@activemq.apache.org
Content-Type: text/plain; charset=UTF-8

On 17 December 2014 at 15:00, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 17 December 2014 at 15:45, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>>
>> On 17 December 2014 at 13:43, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>> > On 17 December 2014 at 13:37, Robbie Gemmell <robbie.gemmell@gmail.com>
>> > wrote:
>> >>
>> >> 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.
>> >
>>
>> In case my expansions below dont make it clear enough, so do I.
>>
>> >
>> >
>> >> 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 :-)
>>
>> Good 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.
>>
>> Yes, certain prefixes, some of which may already be in use as they do
>> form 'valid' addresses, might not play well in a future global
>> addressing context, certainly something to consider.
>>
>> > As such I would probably favour a more
>> > flexible (e.g. regex) mechanism for name "mangling".
>> >
>>
>> Any more concrete thoughts/examples?
>>
>>
> Nothing concrete... more just wanting to avoid premature "standardisation"
> on something we later find to be inadequate for the eventual requirement.

Ok. I'm trying to figure out if I am on the same page. Are you
thinking of something that would simply be used to decide whether a
given fixed/supplied prefix was used or not (e.g apply this
fixed/given prefix if this regex matched anything in the given JMS
'name' string), or something more complicated that might decide what
to apply based on what matched?

> Another consideration might be special addresses, like "$management" which
> the server would not want to be mangled but which we would still want to
> make easily accessible through session.createQueue().
>

Good point.

>
>> >
>> >
>> >
>> >> 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
>> >
>>
>> If the name mangling is conducted on the way out of the client to form
>> an AMQP address from the initial 'JMS name', and reversed on the way
>> in to the client to give the 'JMS name' used for
>> getJMSDestination/getJMSReplyTo, then I guess two Destination objects
>> would be considered equal if they had the same type and same 'JMS
>> Name'.
>>
>>
> I was thinking that we would potentially want to avoid having to have a
> "reversible" mangling algorithm.  IIRC you can't extract the name from a
> Destination object after it has been created.

I dont think we can get away without reversability.

All the concrete Destination objects JMS specifies let you retrieve
the name, via getQueueName() or getTopicName(). Thats how you figure
out where the message was sent or should be returned to if you use
getJMSDestination()/getJMSReplyTo().

>  the AMQP address is the
> "real" identity as far as AMQP is concerned.  Moreover there may be some
> addresses (even within systems which have distinct queue and topic domains)
> which exist within other domains, or which live outside the domains
> ("$management" for example)

Sure, but the JMS objects wont necessarily know about the exact AMQP
address unless we always make the application provide the full AMQP
address or decide on a single fixed prefix that can be applied/removed
within the destination objects themselves.

Special addresses like $management might really live outside the
domains, but the client is ultimately going to access them via the
domains, e.g session.createQueue("$management") from your example
earlier, which will give a JMS object that gets compared like any
other unless the client is made specifically aware of those special
addresses in some way.

>
> -- 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
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org