Re: JMS Destination handling

[Robbie Gemmell <rgemmell@redhat.com>]

----- Original Message -----
> From: "Shawn McAllister" <Shawn.Mcallister@SolaceSystems.com>
> To: "Robbie Gemmell" <rgemmell@redhat.com>, amqp-bindmap@lists.oasis-open.org
> Sent: Wednesday, 17 December, 2014 6:47:29 PM
> Subject: RE: JMS Destination handling
> 
> 
> 
> 
> 
> >> 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.
> 
> 
> 
> right - and that can be a problem for systems developed before a spec is
> completed – and it is a hassle.
> 

The annoyance here are those systems which were developed against the core AMQP 1.0 spec, after it was completed. As I understand it, thought I may be wrong, the core spec deliberately left the address opaque in part so that existing systems could utilise addresses that suited/mapped to their existing non-AMQP behaviour, aiding adoption.

One of the goals for the JMS mapping was to interoperate to the extent possible with other 'non-JMS' AMQP 1.0 implementations. Requiring all AMQP 1.0 systems to use a particular [non-global] address naming convention seems a little harsh, particularly if it clashes with whatever they have in place now, over 3 years after the core spec came out (from the old Working Group).

> 
> 
> However, there are presumably going to be other incompatibilities in addition
> to this issue between any existing systems (where the incompatibilities are
> different for each existing system) and what the final mappings
> specification says and I would hate to set a precedence for needing a
> negotiation/dynamic mechanism of handling each of those that we find – and
> then maybe still not enough since we don’t know the ones we don’t know.
> 



At the moment, the main thing in this area would be potentially optional or JMS specific functionality, where a broker/peer doesnt implement everything needed to support a certain JMS feature, which is OK since we aren't looking to say all AMQP systems must. I think mechanisms already exist for conveying the types of thing we would want to here, i.e capabilities, properties etc. As mentioned, we could even use those to solve this problem a different way, just one which can break reply-to interop with all existing clients/brokers/others.

For the most part, given both sides are implementing AMQP 1.0, most further compatibility issues should be AMQP spec violations or lack of support for non-mandatory functionality. Those would seem more to either get fixed or be vendor specific 'we dont support X' notes rather than something I would be thinking the JMS mapping accommodating specifically.


> 
> 
> I don’t think we should let pre-standards work impose complexity that we will
> need to live with forever.  Ie. more configuration or negotiation, needing
> to do mappings both for published messages and subscriptions and then
> imposing these issues on administrators – it will not help encourage
> adoption.
> 

The idea was to require less configuration for things that are already doing this, not more. Things not requiring/doing this would continue not to require/do it.

> 
> 
> If existing systems/products did something different, I would prefer that
> they use the typical solution of them using system-specific ways to go from
> their own on pre-standard version to the standard – and do this as they see
> fit vs burdening the standard with (dynamic) mechanisms to adapt to
> pre-standard versions whose characteristics we likely don’t fully
> understand.
> 
> 
> 
> That’s why I’d prefer to just define a specific prefix for the identifier of
> a topic or queue to differentiate them from each other (and others in the
> Addressing spec) and leave it at that.
> 

As above I think it is difficult for us to define a specific node prefix/naming convention at this point. When the core spec came out, perhaps, or ideally the core spec could have handled node type directly. I think I would rather leave this out of the mapping as an implementation detail (like JMS destination names themselves are considered) than have it define a fixed convention.

> 
> 
> Shawn
> 
> 
> 
> -----Original Message-----
> From: amqp-bindmap@lists.oasis-open.org
> [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of Robbie Gemmell
> Sent: December-17-14 10: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
> 
> 
>