The Three Faces of Web Services

I love Tim Ewal’s piece on “3 faces of Web services”. In the company I work for, most people would consider XML over HTTP not to be a web service because of the two missing elements “Envelope” and “Body”. This is unfortunate, but understandable. Most vendors have the same self-interest that we all have… looking out for number one (and in some case, the stock holders :-)). As such, most vendors will push the idea that if you are not using their toolkit (SOAP, SO< etc.), then you are not using web services. But, as other have pointed out (Tim Ewal and Sam Ruby), this is not the case in the real world. In the real world developers have done what they needed to do to get the product out. If you are big enough (read eBay) you can get away with a lot if the benefits of your service are worth the cost of getting in. But what about the internal corporate developer who have to integrate with more than one internal system to get her job done? For such a person, the eBay model usually works in the beginning, but once you begin to grow and would like the benefits of say Single Secure Sign-On, standards and conformance become very important. Tim Ewal said the overlap between SOAP and “XML over HTTP” is about 98%. Put another way, the differences between SOAP and “XML over HTTP” is 2% (read Envelope and Body element). Why not just put your XML in a SOAP envelope? Think of the great benefits you can gain down the road with WS-* (the ones you care about that is). For this reason, and knowing what we know today) I think XML over HTTP is just wrong… “Give SOAP a Chance”. Some might say that adding something to the XML (i.e., Envelope and Body elements) goes against principles such as TDD, but I would say that applies to code not data.