What makes a "web service" a Web Service

[wMusers.Com1 (wMusers.Com)]

This blog post from Simon Guest is a bit dated but still useful in my opinion. I can’t tell you how many times I run across vendors or trading partners who assert that they are providing a “web service” who violate one or more of these guidelines.

How can you tell if a “Web Service” really is a Web Service?

     [FONT=Verdana][SIZE=2]I was asked the question "How can you tell if a Web Service really is a Web Service?".  If someone says that they have a Web Service (or more importantly is trying to sell you one!) what are the questions you should ask?  I decided to put together this list of 10 things that point you in the right direction…  and welcome any that I've missed.[/size][/font]

1. Uses WSDL. A Web Service should expose its service contract using WSDL. If it can’t give you a WSDL document, it’s probably just XML over HTTP…
2. Uses SOAP. All messages sent from and received by the Web Service must use SOAP formatting. If it’s not using SOAP it’s probably just XML over HTTP…
3. Uses XSD. All data types in the SOAP payload must be XSD compliant. No platform native types are allowed. If it’s not using XSD it’s probably just XML over HTTP…
4. Uses XML. The underlying messages should of course be formatted using XML.
5. No Arbitrary Binary Data. The message payload should 7 bit ASCII and should contain no embedded binary blobs. Any binary data passed over a Web Service should be sent using either SwA, DIME or MTOM (preferably MTOM).
6. Transport is likely to be HTTP. Although not a requirement, the majority of Web Services today use HTTP as the transport. Compliant Web Services should definitely work over HTTP.
7. Discovery can be through UDDI. Again although not a requirement, it should be possible to host the Web Service endpoint using UDDI.
8. Agreed Versions of Specifications. The versions of the above specifications (WSDL, SOAP, XSD, XML, HTTP, UDDI) should be in line with the latest version of the WS-I Basic Profile (http://www.ws-i.org) – to ensure Web Service compliance between vendors.
9. Operations should be Document Style. Operations to/from a Web Service should be Document/Message Style (e.g. SendOrder(order o)). RPC style should be avoided (e.g. SetOrderLine1(orderId id)).
10. Should be compliant with WS-*. Compliant Web Services should be able to accept WS-* payloads and extensions for Security, Reliability and Transactions (although not all stacks today support these yet).

I would probably add the following:

5A. No Arbitrary CDATA-enclosed blobs of XML or proprietary text. I’ve seen this recently both in questions posted here on wMUsers and at one of my customers whose trading partner provided a “web service” that was not described by a WSDL and contained a large CDATA-enclosed blob of text that had to be parsed separately.

BTW, one of the commentors to Simon’s post suggested that his definitions were too narrow as they would exclude REpresentational State Transfer (REST) web services.

Mark