W3C home > Mailing lists > Public > public-soap-jms@w3.org > March 2009

Re: Review of draft-merrick-jms-uri-05

From: Eric Johnson <eric@tibco.com>
Date: Mon, 16 Mar 2009 09:58:44 -0700
Message-ID: <49BE8544.2080007@tibco.com>
To: "SOAP/JMS (list)" <public-soap-jms@w3.org>
SOAP/JMS WG...

This is the email I'm thinking to send in response to Harald's comments
from a month or so back.

Comments?

-Eric.

Hi Harald,

Thank you very much for your feedback on the URI scheme.  Sorry for the
slow response - altogether too much to do on everyone's part, I suspect.

Harald Alvestrand wrote:
> Document: draft-merrick-jms-uri-05
> Reviewer: Harald Tveit Alvestrand
> Type of review: Apps area review
> Date: February 5, 2009
>
> Summary: This document is strange, but just about ready.
>
> This specification is highly unusual in that it really doesn't
> document an URL for a protocol that can be resolved across the
> Internet - it documents a way to describe the parameters that one
> should send across a Java API.
>
> I think it a pity that the examples given give the impression that
> these mechanisms are strictly local in scope - a "jndi name" of
> REQ_QUEUE, and a "jndiURL" of file:/C:/JMSadmin both give the
> impression that these URLs won't ever be resolvable outside of a quite
> local context.
> I suspect that it is possible to construct JMS URLs that can be shared
> globally with an expectation of uniform interpretation - if such
> exist, it would be better for the document if they had been used in
> examples.
The answer is slightly more subtle - JMS URIs can span the globe, but
that implies a shared context that also spans the globe.  I'm thinking
that the following additional paragraph in the introduction might help
to clarify:

As a consequence of building upon an API, rather than a protocol, the
utility of a "jms" URI depends on the context in which it is used. 
Critical details affecting utility include agreement on the same JMS
provider or underlying protocol, agreement on the context for looking up
endpoints, and when using serialized Java object messages, sufficiently
similiar Java Class environments that the object can be appropriately
read and written.  Uses of this scheme must establish the necessary
shared context - a context which can span the globe, or merely a small
local network.  With that shared context, this URI scheme enables
endpoint identification in a uniform way, and the means to connect to
those endpoints.

>
> On the other hand, if this possibility does not exist, the document
> should be very clear that these URIs are *not* possible to use in
> Internet interchange without a prenegotiated context for
> interpretation, and that they have no more global semantics than the
> "file:" URL scheme.
>
> Apart from that, the document seems to do its job of describing how to
> pick apart one of these URLs and push the pieces through a Java API.
> Some nits:
>
> - in section 4.1, some "shared" parameters are defined, but in section
> 4, it says that new variants can be defined, whose parameters should
> begin with the variant name as prefix (without specifying a separator
> character). Is there an expectation that there will never be a variant
> called "delivery", "time" or "priority"? If so, should this
> expectation be documented? (what about the "del" variant? possible or
> not?)
I've been torn on this point since we introduced the variants.  I see
variants as so rare that this is essentially a moot issue.  In practice,
I think there is at most one additional variant per vendor, and the
market pressures are such that there will not be many implementations.
>
> - in section 4.2.1, it seems somewhat bizarre that the JNDI-specific
> parameters all start with "jndi", while section 4.2.1.4 states that
> additional JNDI-specific parameters should start wiht "jndi-" (note
> the additional dash). Why not be uniform?
There are at least two classes of information here, information needed
to establish a JNDI context (initial context factory, URL, additional
parameters), and information needed once you've got that context
(connection factory name).  An alternate form of uniformity would
highlight the distinction between these two classes more uniformly,
rather than special-casing the three well-known parameters, and then
using the "jndi-" for the open-ended extension of additional
parameters.  This URI:

jms:jndi:REQ_QUEUE?
  jndiURL=file:/C:/JMSAdmin
  &jndiInitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory
  &jndiConnectionFactoryName=CONNFACT
  &jndi-com.sun.jndi.someParameter=someValue

might be stated as:

jms:jndi:REQ_QUEUE?
  jndi-java.naming.provider.url=file:/C:/JMSAdmin
 
&jndi-java.naming.provider.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
  &jndiConnectionFactoryName=CONNFACT
  &jndi-com.sun.jndi.someParameter=someValue

(Note how jndiConnectionFactoryName doesn't get the "-")

While this is more consistently separating out the means to identify the
JNDI lookup, and the item you look up, I think it suffers from two problems:

    * It makes the URI longer for no semantic benefit
    * JMS develeopers probably think of the property
      "java.naming.provider.url" as the JNDI URL, so this seems to be
      the more natural symbolic way to refer to it.  Likewise with the
      initial context factory.

   
>
> - the fact that the URI needs to be in UTF-8 only surfaces in section
> 5, long after the definition of the URI, and long after I'd started
> wondering about it. I think it would be better if this section was
> moved up  after section 3, just after the URI syntax is defined.
There's a trade-off here.  We could move the entire section here up to
be a sub-section of #3.  I think there's some value to having an top
level-"encoding considerations" section called out in the TOC, and I
don't see how we move that closer to the front.
>
> The security section seems reasonably comprehensive - if one wants
> additional review of this, it should be by someone who understands the
> JMS and JNDI security models and can tell how they relate to this
> scheme - this reviewer doesn't.
Indeed!

-Eric.
Received on Monday, 16 March 2009 16:59:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:20 GMT