[ogsa-wg] RE: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)

Tue Nov 22 11:58:10 CST 2005

<trm>Comments inline</trm> 

-----Original Message-----
From: owner-ogsa-naming-wg at ggf.org [mailto:owner-ogsa-naming-wg at ggf.org] On
Behalf Of Mark McKeown
Sent: Tuesday, November 22, 2005 9:58 AM
To: Frank Siebenlist
Cc: ogsa-naming-wg at ggf.org; ogsa-wg at ggf.org
Subject: Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)

Hi Frank,
         I have made some comments inline...

First to remove some confusion about IRIs that have appeared in previous
mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of
URIs to support extra charactors. A URI may or may not map to a real
physical address. The WS-Addressing specification[3] defines a number of
URIs that do not map to real network locations (eg
http://www.w3.org/2005/08/addressing/anonymous).
WS-Addressing mandates that the wsa:Address element is an absolute IRI.

>
> * include a profile for the use of the Address and ReferenceParameters 
> that ensure the proper uniqueness property in time and space of the 
> reference. Tom Maguire suggested to use the wsdl binding of the 
> address which sounded very promising.

I am not sure I have understood Tom's argument correctly so I will try and
repeat it here in order to be corrected...

TomM suggested using the wsa::Address as the name, I understand his argument
as being that with the WSDL binding for WS-Addressing you can include the
service part of the WSDL into the wsa:Metadata of the EPR, the service part
may contain a number of network endpoints indicating that the WS-Resource is
available at a number of locations.
>From 'Web Services Addressing 1.0 - WSDL Binding' [4]:

"In particular, embedding a WSDL service component description MAY be used
by EPR issuers to indicate the presence of alternative addresses and
protocol bindings to access the referenced endpoint."

In this case the wsa:Address could be a URN (or URI that is not an actual
network location) and the client could look to the wsa:Metadata to find the
actual network location of the WS-Resource. Quoting Tom[5]:

"Let me be very clear about this an EPR does not have a 1 to 1
correspondence with a protocol and binding address.  It MUST be true that an
EPR can support multiple protocols and their associated addresses."

I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when
discussing including WSDL components in the EPR, there is no obligation.  
<trm>probably should not have capitalized MUST.  The important aspect of
that statement is 'can support'</trm>

I think most services will only use one transport protocol so I think this
feature will not be used often - even if a service does use more than one
transport/port there is no requirement to advertise this in the EPR. 
<trm>yes, that is what the 'MAY' means wrt requirement to advertise.  I am
puzzled why you think that most services will use only one transport
protocol.  Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS,
SOAP/BEEP and clearly the separation of protocol handlers from service
implementation is a good thing.</trm>

Also there is no transport bindings available for WS-Addressing - for
example the SOAP bindings tells us to take the wsa:Address element and put
it into the wsa:To element in the SOAP header but does not tell us what to
do with it with regards to the transport protocol (eg most people use the
wsa:Address element to create a RequestURI which they set as the POST HTTP
Header when using HTTP - this issue has been raised with the W3C TAG[6]).
<trm>I wonder what their solution will be.....</trm>

Quoting WS-Addressing:

"A Web service endpoint is a (referenceable) entity, processor, or resource
to which Web service messages can be addressed. Endpoint references convey
the information needed to address a Web service endpoint."

To me there is a strong emphasis on singlar.

<trm>Do me a favor; Define endpoint.  That argument has been raging
forever.... </trm>

>
> * include a recipe for generation of a single IRI from the Address and 
> ReferenceParameters that can function as an identifier of the resource.
> Mark Mc Keown pointed at the W3C Web Architecture description of the 
> use of URIs which we could borrow from.

I am not sure about creating an IRI from the wsa:Address and the
wsa:ReferenceParameters. Consider the following EPRs

<wsa:EndPointReference>
  <wsa:Address>http://grid.org/jobs/4654</wsa:Address>
  <wsa:ReferenceParameters>
       <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated>
  </wsa:ReferenceParameters>
</wsa:EndPointReference>

and

<wsa:EndPointReference>
  <wsa:Address>http://grid.org/jobs/4654</wsa:Address>
  <wsa:ReferenceParameters>
       <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated>
  </wsa:ReferenceParameters>
</wsa:EndPointReference>

If DateCreated is just to inform the service when the EPR was created and is
not used by the service for anything else then the two EPRs are for the same
WS-Resource. However if I create a name based on a combination of the
wsa:Address and wsa:ReferenceParameters I will get two different names, ie I
have created URI aliases and divided the network losing some of the goodness
of Metcalfes law [7].

cheers
Mark

[1] http://www.ietf.org/rfc/rfc2396.txt
[2] http://www.ietf.org/rfc/rfc3987.txt
[3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
[4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/
[5]
http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.h
tml
[6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47
[7] http://www.w3.org/TR/webarch/