The Web services and HTTP world are still way separate. Without getting into the politics, I wonder what it would take to get to a mixed world: where SOAP clients can "see" Web resources, and Web clients can "see" SOAP resources. We're getting awfully far down the WS-Addressing path, which is doing nothing to contribute WS-Addressing"able" resources to the Web, and the SOAP 1.2 "Web-Method feature" didn't do this, so what else might be needed?
Strawman
I think there are 3 things that would need to be done:
- Binding SOAP to XML over HTTP, taking the soap body child and setting as HTTP body
- Binding of WS-A properties to HTTP properties
- Revamped WSDL to use SOAP for all operations and use Constrained verbs as operations
XML over HTTP "is" SOAP
The first binding is to make it look to "SOAP" like all Web resources are SOAP resources using the raw XML is a soap body trick that Sam Ruby talked about. Let's take that a bit further into WS-A land and say that various HTTP properties, like request-method and request-uri, are "automatically" WS-A properties.
HTTP Binding(s)
This means there needs to be at least 1 and maybe 2 new bindings. There needs to be a binding to HTTP that allows headers and body to be serialized into various places in HTTP. Let's call this the "SOAP HTTP Transfer Binding". The current SOAP HTTP Binding already exposes the Request URI and Web Method as features, so the SOAP HTTP Transfer binding could use that with the addition that all SOAP headers are serialized as HTTP Headers and the SOAP body is serialized as XML in the HTTP Body. I lean towards a mime type of application/xml rather than soap+xml.
WS-A binding to HTTP
The next piece is to provide WS-A specific bindings to this new SOAP HTTP Transfer binding. The obvious things would happen - the wsa:action becomes the web-method property and the wsa:To becomes the ImmediateDestination property. I've mentioned the other tricky parts before in ruminations on WS-Addressing and transfer protocols.
Transfer Verbs
Somewhere the Transfer verbs need to be "identified". My guess would be that the SOAP adjuncts should define the HTTP operations of GET|POST|PUT|DELETE, probably just as simple as defining qnames for the HTTP operations.
Another obvious option would be to use WS-Transfer - or even WS-Get - operations. This makes a lot of sense because the generic operations aren't limited to just HTTP. But... WS-Transfer doesn't solve the problem of how to specify the types that are related to the transfer operations. And WSDL n.n doesn't give a way for a client to take the transfer verbs and then "extend" them with the input and/or output types. Maybe that's a problem with WSDL.... So it doesn't really add the necessary typing to WSDL.
WSDL
WSDL then needs a way of using the new binding(s) and the HTTP properties.
WSDL transfer operations
To really use HTTP within WSDL, we could define an operation that uses the HTTP verbs. How about going as far as baking in HTTP GET right into a special operation, like:
<wsdl:getOperation>
<wsdl:input headers="" />
<wsdl:output element=""/>
</wsdl:getOperation>
Operations without Interfaces
Native HTTP, aka REST, is fundamentally different than Web services because HTTP defines operations and Web services allows arbitary operation definitions. One result is that Web services typically have many operations in an interface at a small number of URIs, whereas Web apps typically have a large number of URIs. Web services = few URIs and Web apps = many URIs. As a result, WSDL's interface centric model is naturally difficult to work with web apps. It would be simpler for Web application developers to define operations *without* collecting them into an interface. They just don't need to collect operations into interfaces because there are very few operations. WSDL that allowed standalone operations that could be directly deployed at locations would dramatically simplify describing web apps.
Assume SOAP + maybe WS-Addressing in WSDL
The final step for WSDLis to assume that SOAP is the format and protocol for all wsdl defined messages. WSDL can be simpler for SOAP messages on the wire (no soap binding!!!!) and the HTTP Native binding can be used to bridge to the HTTP world.
A service could just reference the interface or operations without a binding step (it's just SOAP), or have a flag indicating that the HTTP Native binding is being used.
Other "Simplified" WSDL
I'm certainly not the only one that wants a simplified WSDL.
Some of the other works around simplifying WSDL are at SSDL and Rich Salz's Really Simple Web Service Descriptions
Politics
Obviously lots of politics would have to happen, not the least of which is that some companies want to focus solely on SOAP envelopes being passed around and no use of GET. As well, the WSDL WG has passed it's Last Call period. OTOH, WSDL 2.0 doesn't seem to have a lot of pent up demand, so helping both SOAP users and XML over HTTP users better than it's done currently could increase demand.
Leave a comment