RE: [SOAP-JMS] last call comment : LC04

Hi Roland, Hi Phil,
    Thanks for discussion about our (Yongping and I) comments. For convenience, allow me list comments here and clarify our ideas for the discussion.

**comment1
Point: chapter 1.6
Comment: I see that JMS specification 1.1 in reference list. Not sure if it makes sense to mention JMS 1.1 explicitly, anyway, there are some notable difference between JMS 1.0. 2 and JMS 1.1

Thanks Roland for answer.

**Comment2
Point:  chapter 2.2.1 [Definition: soapjms:lookupVariant ](xsd:string)
Comment: "Does there any default value or predefined value for this property? From definition of destinationName, “jndi” seems such a value.
I got an impression one must look up  JMS destination and connection factory JNDI (specified in JMS spec?)

**Comment3
Point: chapter 2.2.1 definition of destinationName and jndiConnectionFactoryName
Comment: jndiConnectionFactoryName,destinationName,why first item with prefix “jndi”, but second one without it?

Essentially, Comment2 and Comment3 are talking about the relationship between JMS, JNDI, and generic lookup mechanism. I have put some clarification below.

**Comment4
Point: chapter 2.2.1 [Definition: soapjms:jndiURL ] (xsd:anyURI) ".. Which is mapped to the java.naming.provider.url
Comment: It is javax.naming.Context.PROVIDER_URL.
in definition of jndiInitialContextFactory, we use javax.naming.Context.INITIAL_CONTEXT_FACTORY  refer to java.naming.factory.initial. Now we better keep the style, that is, use javax.naming.Context.PROVIDER_URL to refer to java.naming.provider.url "

This comment is just an editorial. not technical.

**comment5
Point: chapter 2.2.1 [Definition: soapjms:jndiContextParameter] '.. Specifies an additional property, …'
Comment: All other properties defined in javax.naming.Context are in this category, right?
This comment want to confirm that the parameters already defined in JMS spec 1.1 are inherited in SOAP JMS spec.


Now, we give some clarificatin about (our understanding about) the relationship between JMS, JNDI and how the relationship would influence (the lookup part of) SOAP JMS spec.
1. Our understanding is, JMS depends on JNDI to lookup resources (including connection factory, destination: queue and topic). That is, the JNDI way is the default/mandatory mechanism required by JMS spec. as far as we know, existing JMS providers (Sun AppServer, SonicMQ, MQSeries, Weblogic, etc) all support this mechanism.

    At the end of this mail, we have copied related material from Sun JMS spec 1.1 (jms-1_1-fr-spec.pdf, Version 1.1 April 12, 2002).

2. Definitely, SOAP/JMS implementation will build on these products, so JNDI has close relationship with SOAP/JMS spec.

3. In current SOAP/JMS spec, especially from section 2 Properties Affecting Binding<file:///C:/KM/Specifications/SOA/SOAP%20over%20JMS/SOAP%20over%20Java%20Message%20Service%201.0.htm#binding-properties> and Appendices C SOAP/JMS Underlying Protocol Binding Examples<file:///C:/KM/Specifications/SOA/SOAP%20over%20JMS/SOAP%20over%20Java%20Message%20Service%201.0.htm#binding-examples>, we can see that  JNDI is in fact the default lookup mechanism required by SOAP/JMS spec. but we have found no words in the spec to "explictly" give JNDI such a position (default and mandatory, if not the only mechanism among many possible ways to keep SOAP/JMS open).

What we would suggest, is that to explicitly position JNDI as the default (if not the only) mechanism to lookup JMS resources in SOAP/JMS spec if editors already implicitly do this.

4. clarify comment about "jndi" prefix. our points are:
a. To compliant with JMS spec, the "soapjms:destinationName" will in fact be JNDI name.
b. To keep SOAP/JMS spec open, the "soapjms:destinationName" can be variant of JNDI name. the spec implementators can have a DestinationResolver to resolver the name.
c. don't need to add "jndi" prefix in [Definition: soapjms:destinationName].

In section 2.2.1 "Connection to a destination", one can find following definition:
[Definition: soapjms:lookupVariant ](xsd:string)

[Definition: soapjms:destinationName ] (xsd:string)

[Definition: soapjms:jndiConnectionFactoryName ] (xsd:string)

[Definition: soapjms:jndiInitialContextFactory ] (xsd:string)
[Definition: soapjms:jndiURL ] (xsd:anyURI)
Definition: soapjms:jndiContextParameter ] (soapjms:jndiContextParameterType)

4.1   The 1st definition (lookupVariant), according to spec, "Specifies the technique to use for looking up the given destination name. "  What we want to say, is that we should "explicitly" put "jndi" as default value or at least a value of lookupVariant (now the spec has no given ANY value except implicitly use 'jndi' !).

4.2   Last 3 is about JNDI provider itself, so it is O.K. to put "jndi" prefix.

4.3.  About middle 2 definition (destinationName, and jndiConnectionFactoryName)
The focus is "desinationName". The SOAP/JMS spec has not specified it as jndi name. this is understandable to keep the spec open to other lookup mechanism. but the question is, what does "soapjms:jndiConnectionFactoryName" do?  we use it to get JMS connection factory, then the only things we can do is creating JMS connection, constructing JMS message producer and consumer (that is, the JMS client in JMS spec), then send message to (or receive message from) JMS destinations. According to the JMS spec, these JMS destinations must be lookuped from JNDI, so if "soapjms:jndiConnectionFactoryName" is here then the "soapjms:destinationName" must be JNDI name or its variant.

4.4. I have studied JMS URI spec (http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-05.txt) mensioned by Roland, my impression is that the desitinationName is in fact JNDI name or its variant.

so we reach our conclustion.

Best regards,
Jinzhai

Apendix: excerpts from Sun JMS specification 1.1, about JMS and JNDI.

JMS spec 1.1  section 1.4 talks about the "relationship to other JMS APIs". Section 1.4.6 is about JNDI API:

    "1.4.6 Java Naming and Directory InterfaceTM (JNDI) API
        JMS clients look up configured JMS objects using the JNDI API. JMS
        administrators use provider-specific facilities for creating and configuring
        these objects.
        This division of work maximizes the portability of clients by delegating
        provider-specific work to the administrator. It also leads to more administrable
        applications because clients do not need to embed administrative values in
        their code."

In JMS spec 1.1, section 2.3 (page 22),

"Administration It is expected that JMS providers will differ significantly in their underlying
messaging technology. It is also expected there will be major differences in how
a provider’s system is installed and administered.

If JMS clients are to be portable, they must be isolated from these proprietary
aspects of a provider. This is done by defining JMS administered objects that
are created and customized by a provider ’s administrator and later used by
clients. The client uses them through JMS interfaces that are portable. The
administrator creates them using provider-specific facilities.
There are two types of JMS administered objects:
* ConnectionFactory - This is the object a client uses to create a connection
with a provider.
* Destination - This is the object a client uses to specify the destination of
messages it is sending and the source of messages it receives.

Administered objects are placed in a JNDI namespace by an administrator. A
JMS client typically notes in its documentation the JMS administered objects it
requires and how the JNDI names of these objects should be provided to it."



张 晋寨, Zhang Jinzhai
Global Delivery Application Services
+86  21 6081 3327
+86 139 1731 0846
la structure cachée dans les choses mathématiques



________________________________
From: public-soap-jms-request@w3.org [mailto:public-soap-jms-request@w3.org] On Behalf Of Phil Adams
Sent: 2009年1月22日 3:11
To: Roland Merrick
Cc: public-soap-jms@w3.org; public-soap-jms-request@w3.org
Subject: Re: [SOAP-JMS] last call comment : LC04


Hi Roland,
Unless I'm misunderstanding this, "destinationName" is not an actual property that appears in the JMS URI (in the property=value form).  Instead, "destinationName" represents the value that follows the "jms:jndi:" prefix (scheme and variant values).   So, I'm not sure what would be gained by calling it "jndiDestinationName".   That would have no affect on the JMS URI per se.

Phil
__________________________________________________________________________________________________________
Phil Adams      phil_adams@us.ibm.com<mailto:phil_adams@us.ibm.com>
WebSphere Application Server    Office: (512) 286-5041 (t/l 363)
Web Services Development        Mobile: (512) 750-6599
IBM - Austin, TX




From:   Roland Merrick <roland_merrick@uk.ibm.com>
To:     public-soap-jms@w3.org
Date:   01/21/2009 05:27 AM
Subject:        [SOAP-JMS] last call comment : LC04

________________________________




Greetings, I have taken a look at comment LC04 (**comment3 from Tang, Yong-Ping). In this he asks why jndiConnectionFactoryName is prefixed by jndi, but destinationName is not.

The simple answer is that destinationName is used with any lookup variant not just for jndi. Perhaps we need to make this clearer. I think we should also consider one or more FAQs to deal with looking up connection details for a destination. We do have some material on this in the JMS URI spec.

Regards, Roland


________________________________


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU