Mark McKeown wrote:
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.
WS-I BP doesnt actually fix interop at the SOAP level, because they completely dodged the whole question of which subset of XSD to recommend, so java can still happily reject xsd:unsignedLong, .NET can handle nillables differently, and end users suffer. Maybe, just maybe, the new XSD best practises WG will fix this.
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)
My WSRF impl rejects any incoming message without a WS-Address, which I believe is a requirement, so implicitly all GET soap reqs fail.
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.
I'd actually consider the option of sending notifications back over alternate transports than HTTP. That is, you may send a message over HTTP(S), but you subscribe with an address that uses XMPP. That way your messages will route through firewalls using the existing jabber relay infrastructure, and make it to you, wherever your laptop happens to be at the time. That is the special case of notificiations, which have two extra needs -sent from a server to a recipient that may be behind a firewall -the delay between subscription and message means that a mobile recipient cannot know what its network address will be in the future, even if the firewall is not an issue (ignoring dynamic dns registries)
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...
Its the thing at the far end that doesnt recognise your XSD, as opposed to the things in the middle :)