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

["Mark Blair" <markblair@san.rr.com>]

Having differing prefixing schemes across vendors will add complexity to the client, and particularly in cases where an application might connect to two or more different AMQP implementations having different prefix strings or regex expression to manage.   More dirty laundry users won't want to have to deal with and are likely to struggle with to get right.
Obtaining custom prefixes wrapped in a centrally administered connection factory (or possibly provided by the broker implementation during the Open performative exchange?) would at least have the benefit of shielding the app from this complexity.
If we are leaning towards option #3 route I'm with Shawn though about biting the bullet and trying to standardize on a single prefix convention without further complicating the specification and in turn client and broker implementations having to accommodate this variability.

Looking at option #2, annotations could provide a standard, consistent way of indicating destination type ("to" and "reply-to"), irregardless of the address syntax per vendor, and also not have to expose any of this complexity either in app code or in configuration.   Robbie indicated this won't work because existing client and intermediaries wouldn't likely understand these attributes.  Wouldn't we assume since the JMS mapping is not yet finalized that any vendors that went out on the limb and built implementations ahead of the game might have to change to conform to the final specification, and therefore any clients/intermediaries would have to change to support the defined annotations/capabilities ?   . . . Or the above if we standardized on a single prefix scheme?

Another thing to think about is how this will impact the interaction between JMS and non-JMS clients and what would be reflected to non-JMS clients from the interface point of view.   Neither is ideal and fully transparent.   A non-JMS client would be exposed directly to the mangled name and have to deal with parsing that (and would need to be aware the other side is a JMS client to know it needs to do the parse, and, "how do I find the proper regex expression to use?").   Using the option #2 annotations approach would require the client to gain access to the particular field and decipher the dest type.   Again, option #2 might be less ugly by having a consistent attribute to look for that indicates dest type irrespective of what shows up in the address field, and possibly it would make sense having a more generic field name for this (i.e. "x-opt-dest" instead of "x-opt-jms-dest" - that way a non-JMS client could set dest type when it wants to communicate dest-type scope without necessarily assuming a JMS broker).

Mark


-----Original Message-----
From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of Robbie Gemmell
Sent: Wednesday, December 17, 2014 7:03 AM
To: amqp-bindmap@lists.oasis-open.org
Subject: Re: [amqp-bindmap] RE: JMS Destination handling



----- 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.
> 

---------------------------------------------------------------------
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