<trm>Comments inline</trm> -----Original Message----- From: owner-ogsa-naming-wg@ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Mark McKeown Sent: Tuesday, November 22, 2005 9:58 AM To: Frank Siebenlist Cc: ogsa-naming-wg@ggf.org; ogsa-wg@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/