[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [amqp-bindmap] Groups - Advanced Message Queuing Protocol (AMQP) JMS Mapping Version 1.0 WD07 uploaded
----- Original Message -----
> From: "Rob Godfrey" <rgodfrey@redhat.com>
> To: "Robbie Gemmell" <rgemmell@redhat.com>
> Cc: "Keith Wall" <keith.wall@jpmorgan.com>, amqp-bindmap@lists.oasis-open.org
> Sent: Monday, 13 February, 2017 2:48:53 PM
> Subject: Re: [amqp-bindmap] Groups - Advanced Message Queuing Protocol (AMQP) JMS Mapping Version 1.0 WD07 uploaded
>
> On 13 February 2017 at 15:20, Robbie Gemmell <rgemmell@redhat.com> wrote:
>
> >
> > > Looks good. A couple of comments from me:
> > >
> > > 3.2.1 JMS Headers: JMSMessageID / 3.2.1.1 JMSMessageID and
> > JMSCorrelationID
> > > Handling
> > >
> > > For a request/response pattern where the response queue is fixed, I
> > expect to
> > > able to send a message a request queue, then create a consumer on the
> > > response queue with a selector that filters for my response e.g.
> > >
> > > createConsumer(responseQueue, String.format("JMSCorrelationID = '%s'",
> > > requestMessage.get JMSMessageID()).
> > >
> > > If I, as a JMS client library vendor, were to implement the JMS mapping
> > and
> > > elect to use message-ids of type message-id-uuid, then I think the
> > > application calling get JMSMessageID() would see "ID:AMQP_UUID:<string
> > > representation of UUID>". This would mean the JMS selector produced by
> > the
> > > application executing the line above would include the type encoding
> > prefix
> > > "ID:AMQP_UUID". As I assume the type encoding prefixes are private, the
> > > selector would then fail to match on the server peer.
> > >
> >
> > One to discuss, though I'd probably put it with the selectors work item.
> > They are private currently in the sense the client is using them for its
> > own purpose to ensure what it receives for one ID is what it sends for the
> > other. We could however leverage them in the selector work if we wanted
> > (for example, its not clear how people would select on a binary ID
> > currently, or distinguish a string and uuid, or string and ulong, should
> > they want to) or require the client to strip them again.
> >
> >
> So I think it is required that the selector would work... but for this we
> need to properly define the filter that is used on the server side. I
> *think* that it will be necessary to define a filter syntax in terms of
> AMQP fields/types and that the client will need to parse/compile a filter
> from the JMS selector syntax. Solving this problem will be a task for this
> (as yet unwritten) section I think.
>
>
> > > What is the rationale in 3.2.1 reading "SHOULD use message-id-string"?
> > >
> >
> > Strings are what JMS uses, are arguably the simplest, avoid most of the
> > issues just covered, and so I think its fair to say people implementing the
> > mapping SHOULD use the string message ID type by default. I refrained from
> > MUST, as someone might want to do otherwise, e.g. as you suggested above,
> > though it is qualified with 'by default' so I guess it allows for that
> > either way.
> >
> >
> > > 3.3.2 Properties Section: User Id
> > >
> > > What is behaviour is required if the user-id is not legal UTF-8?
> > >
> >
> > Undefined. Happy to add that, though I think the SHOULD in there
> > essentially already means it is.
> >
> >
> Per the JMS spec, the user id is set by the "provider", i.e. the JMS
> implementation. I think we can say that the user-id MUST be UTF-8 since
> the client will be the one setting the property field.
>
This bit covers the receiving case so I think Keith is asking what happens when we can't do that with what we received, which might not be from a JMS client.
>
> > > 5.3 Temporary Destinations
> > >
> > > The text ought to mention the use of terminus capabilities
> > > temporary-queue/temporary topic.
> > >
> >
> > They are mentioned in the general section 5.2 covering all of the
> > capabilities, which is referenced from section 5.3.
> >
> > Per the TODOs, the presentation of those bits isn't necessarily complete,
> > mostly the sections were for getting the details in there somewhere at all.
> >
> > > General
> > >
> > > There are a number of places where we talk about the need to throw an
> > > exception, but don't actually define what it should be.
> > >
> >
> > Yep, taking inspiration from JMS itself there, I don't think they need to
> > be overly specific for the most part. Happy to add 'appropriate
> > JMS[Runtime]Exception' or such like given the affected bits will use those
> > already.
> >
>
> I think this points up the need for us to fill in the abstract / scope of
> the document. I *think* we've agreed that what is necessary to document is
> purely the things that MUST be implemented by a client writer or server
> implementer such that any two people independently writing a client and
> server could use the client and server together to build a compliant JMS
> system operating over AMQP 1.0. The precise nature of errors thrown by a
> particular client implementation do not fall into that scope, I think. If
> they are to be documented they should be documented in the client
> implementation rather than the mapping doc.
>
> -- Rob
>
>
>
> >
> > >
> > >
> > > From: amqp-bindmap@lists.oasis-open.org
> > > [mailto:amqp-bindmap@lists.oasis-open.org] On Behalf Of Robert Gemmell
> > > Sent: Wednesday, February 08, 2017 5:50 PM
> > > To: amqp-bindmap@lists.oasis-open.org
> > > Subject: [amqp-bindmap] Groups - Advanced Message Queuing Protocol
> > (AMQP) JMS
> > > Mapping Version 1.0 WD07 uploaded
> > >
> > > Document Name: Advanced Message Queuing Protocol (AMQP) JMS Mapping
> > Version
> > > 1.0
> > > WD07<https://www.oasis-open.org/apps/org/workgroup/amqp-
> > bindmap/document.php?document_id=59981>
> > > ________________________________
> > > Description
> > > WD7. The changes since WD6 are around:
> > > # AMQPBINDMAP-15: JMSMessageID and JMSCorrelationID handling
> > > # AMQPBINDMAP-33: spelling
> > > # Updating some TODOs to reflect targeting JMS 2.0
> > > # Fixing copyright year (AMQPBINDMAP-32) and other XSL changes.
> > >
> > > The SVN diff since WD6 is available at:
> > > https://tools.oasis-open.org/version-control/browse/wsvn/
> > amqp-bindmap/?op=comp&compare[]=%2F@59&compare[]=%2F@72&manualorder=1<
> > https://tools.oasis-open.org/version-control/browse/wsvn/amqp-
> > bindmap/?op=comp&compare%5b%5d=%2F@59&compare%5b%5d=%2F@72&manualorder=1>
> > > Download Latest
> > > Revision<https://www.oasis-open.org/apps/org/workgroup/
> > amqp-bindmap/download.php/59981/latest/amqp-bindmap-jms-v1.0-wd07.pdf>
> > > Public Download
> > > Link<https://www.oasis-open.org/committees/document.php?
> > document_id=59981&wg_abbrev=amqp-bindmap>
> > > ________________________________
> > > Submitter: Mr. Robert Gemmell
> > > Group: OASIS Advanced Message Queuing Protocol (AMQP) Bindings and
> > Mappings
> > > (AMQP-BINDMAP) TC
> > > Folder: Working Drafts
> > > Date submitted: 2017-02-08 09:49:11
> > >
> > >
> > >
> > > 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
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]