WebServices were supposed to be simple:
- Do an HTTP GET request, pass some query parameters,
- Retrieve XML instead of the regular HTML.
- Process the XML and extract data.
One of the very early implementations of WebService I did, was just that. Send a GET request for news stories for a ticker symbol. Retrieve the RDF document with stories and other data. Massage retrieved data the way you want–cache it, format it, archive it. Straight-forward.
In real world, If the request happens to be more than just query parameters, do an HTTP POST of an XML document. Then SOAP comes into picture–a way to formalize the passing of parameters, generalization of target functions, abstraction of network end-points, transport and marshalling of values. SOAP was good, provided us a means of exposing the remote method calls. Then we had WSDL, a language for describing WebServices.
Then came the boom, much fuelled by rivalries between companies, and the consortium jump started by these companies. SOAP, itself has its own competitors in terms of the XML-RPC protocol.
Here is the reality–For every WS-XXX specification, claiming to enhance the security, reliability of WebServices, there is an equivalent XXX4WS already being proposed by a competing consortia formed by the rivals of the former.
- Messaging and Transaction Coordination BPEL4WS, BTP, WSCI, WS-CAF, WS-CDL, WSCL, WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity, BPML, WSFL, XLANG, ebBPSS.
- Reliable Messaging ebMS, WS-ReliableMessaging, HTTPR, WS-Reliability
- WebServices Addressing WS-Eventing, WS-Addressing, WS-Routing, WS-Discovery
That’s not the definitive list, there are many other specifications, which I don’t know where to bucket, unless I pore through the specifications, use cases and relevance related to the base SOAP & WSDL specifications.
What we want is simplicity–WSDL to expose the service interface and their end-points, SOAP to exchange the payload and a protocol for doing 2-phase commit operations on the services. Bingo–95% of the applications using WebServices for SOA implementations would be covered. Rest of the 5% will customize anyway.
On the similar lines–Adam Bosworth’s latest entry.