Re: [amqp-bindmap] RE: JMS Destination handling

[Robbie Gemmell <rgemmell@redhat.com>]

----- Original Message -----
> From: "Shawn McAllister" <Shawn.Mcallister@SolaceSystems.com>
> To: "Robert X Godfrey" <robert.godfrey@jpmorgan.com>, "Robbie Gemmell" <rgemmell@redhat.com>,
> amqp-bindmap@lists.oasis-open.org
> Sent: Wednesday, 17 December, 2014 1:45:38 PM
> Subject: [amqp-bindmap] RE: JMS Destination handling
> 
> +1 on option 3 for sure.
> 
> 
> 
> >> 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".
> 
> 
> 
> Fair enough on the wire, but since JMS supports only topics/queues for
> addressing today, why not define such fixed prefixes for use by JMS and all
> other topic/queue based MoMs and then avoid the complex broker/client
> interaction of making these configurable/vendor-specific?   Ie. why would we
> want them to be different?
> 

We might not want them to be different.

The main issue is likely to be that they already do differ in existing systems because the address string doesn't have a defined syntax, and changing them to a particular fixed value might not be feasible in all cases.

> 
> 
> Allowing them to be different by implementation, imo, adds yet more
> complexity to the client/broker interaction and will only further complicate
> any kind of broker-to-broker addressing of topic/queues required for
> federation.
> 
> 
> 
> Shawn
> 
> 
> 
> -----Original Message-----
> From: amqp-bindmap@lists.oasis-open.org
> [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of Godfrey, Robert X
> Sent: December-17-14 8:19 AM
> To: Robbie Gemmell; amqp-bindmap@lists.oasis-open.org
> Subject: [amqp-bindmap] RE: JMS Destination handling
> 
> 
> 
> As per the TC call yesterday, I think option 3 is the only truly viable
> solution here.
> 
> 
> 
> > 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".
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> Legally required information for business correspondence/Gesetzliche
> Pflichtangaben für Geschäftskorrespondenz:
> 
> http://www.jpmorgan.com/pages/international/germany/email
> 
> 
> 
> -----Original Message-----
> 
> From:
> amqp-bindmap@lists.oasis-open.org<mailto:amqp-bindmap@lists.oasis-open.org>
> [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of Robbie Gemmell
> 
> Sent: 17 December 2014 12:32
> 
> To:
> amqp-bindmap@lists.oasis-open.org<mailto:amqp-bindmap@lists.oasis-open.org>
> 
> Subject: [amqp-bindmap] JMS Destination handling
> 
> 
> 
> Hi everyone,
> 
> 
> 
> 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. I didn't
> use JIRA for this as mentioned on the call yesterday, as I noticed a problem
> with my account.
> 
> 
> 
> 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.
> 
> 
> 
> 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 from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> 
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of securities,
> accuracy and completeness of information, viruses, confidentiality, legal
> privilege, and legal entity disclaimers, available at
> http://www.jpmorgan.com/pages/disclosures/email.
>