Sam talks about WS-HTTP, and where we could be with Web services and HTTP. Thanks for the mention of WS-Get Sam! I'm stoked that some folks were talking about this at sells-con. I shoulda been there...
Sam mentions the use of WSDL Binding to handle SOAP messages that are XML sans SOAP envelopes. Remember I want WS-Get to have a binding to HTTP Get...
I tried really really hard in WSDL 2.0 to make it easy for the developer to describe an operation and the binding it to SOAP/HTTP or XML/HTTP. The idea is that a WSDL operation is what the contract is. While this is better in WSDL 2.0, it's still arguably too broken. :-( There's a number of central problems that we can't/couldn't resolve.
1. SOAP 1.2 shoulda never done the soap-response mep. It should have allowed an HTTP GET to be a legal binding of a soap envelope, remember it's "all about the infoset". I'm not bitter... However, if we can say that WS-GET has a binding to HTTP GET (as I proposed), then we can describe all the HTTP GET services as WS GET services. So I don't think it's too late but we would need WS-Get which includes a binding to HTTP Get.
2. WS-Addressing EPRs cannot be bound to just URI or URI+http header or URI + cookie. Which means that all the WS- toolkits that publish CORBA IORS whoops I mean WS EPRs can't use HTTP GET or SOAP/HTTP interchangeably. Maybe the W3C WS-A group will solve this problem AND maybe the WS-A toolkits will use the solution.... One could argue that use EPRs that have no ref properties and use just Address is a solution, but I think most of the WSA EPR users will use ref properties. Our software does.... I did try to get the WS-RF folks to provide something on this (what I called WS-REST), but they said no way.
3. WS-Addressing EPRs cannot be constructed at the client, unlike URIs that are HTML form encoded, as we don't have a WSDL/Policy annotation. HTML does this using <form>. We did this in WSDL 2.0 for URIs for HTTP and SOAP-response MEP. I still think it's a bad subset of xml (like missing namespaces and attributes!!) but it's at least there. WS-RF has a bit of a leg up because it has a WSDL annotation that provides a binding between properties and EPR construction. But of course there's no integration/commonality between WSDL 2.0 URI construction, WS-RF Property EPR construction, and completely missing WS-Transfer/WS-Get EPR annotation.
4. Creating a WSDL operation that can be bound to both HTTP and SOAP/HTTP (say using WS-Transfer) is hard, as I found out in my Atom SOAP and HTTP WSDL 2.0. Like:
- how is an application HTTP header and a SOAP header expressed the interface operation? (and damn I've had to argue a lot in WSDL 2.0 for the "application data feature"). An example in Atom is the use of the HTTP Content-Location for the POST result.
- Supporting "Wrapped" elements, as Atom does, results in duplicating all the data structures
- Large numbers of URIs (as occurs with HTTP) results in roughly in a binding element for each endpoint (URI), which is too complicated compared with the slickness of the SOAP binding. For example, GetEntry takes Service + Endpoint + Binding + Operation + Input elements. One would think it could be *a little* simpler.
- Different infrastructure policies(aka security) that is binding specific is complicated.
WSDL 2.0 + WS-Get + WS-Addressing comes close to a good enough job of mixing the two bindings from an abstract interface to actually deliver WS-HTTP, but there's a couple of things missing. Oh, did I mention WSDL 2.0 still might accept Last Call comments, WS-Get doesn't yet exist, and WS-Addressing *just* got started? There's still some time if we want to make WS-REST (my term) or WS-HTTP (Sam's term) a reality.
