Hi Tom,
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>
The reasons why I think that most people will only use one transport protocol when they come to implement a service are as follows: 1) Most people only use one transport at the minute - HTTP. 2) The extra effort to support more than one tranpsort protocol - debugging etc 3) The interoperability issues - only now with WS-I Basic Profile do we understand how to use HTTP + SOAP. 4) I think when people design systems they will choose protocols that best match the requirements of their application. Each of the different transport protocols have different properties, for example if I use SMTP I can do multicast eg. <wsa:EndpointReference> <wsa:Address>mailto:ogsa-wg@ggf.org</wsa:Address> </wsa:EndpointReference> Replacing SMTP with HTTP for this application would probably break it. 5) The "transport" protocols are leaking into the WS-* layer - you can now have Web Services that support the HTTP GET operation. (If your WSRF implementation doesn't use ReferenceParameters you might be able to use a HTTP GET to retrieve the ResourceProperties document using the HTTP caching support for optimization) I think it is basically an "end-to-end" issue[1], when building a distributed application the developer needs to have an understanding of properties of all layers of his system. For example when signing a SOAP message you should put a ttl value into the message - this value depends on how long you think it will take the message to arrive, a function of the underlying transport protocol. I think SOAP and WS-* has all the ingredients to build "end-to-end" systems (eg if your transport layer doesn't encrypt messages turn on WS-Security, if your tranpsort layer does do reliable message delivery turn on WS-ReliableMessaging etc) but I still think that a developer needs to understand his transport protocol and choose the best one for the job.
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>
I guess should be a question for the WS-Addressing working group... cheers Mark [1] http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf