Thursday, September 30, 2004

When is a web service not a web service?

I've long had a bit of an issue with the definition of the term "web service". An old colleague of mine and I wrote a fantastic mobile Windows CE application a few years ago that had to have MSMQ surgically removed at the 11th hour owing to a bug in the TCP stack on CE (or something like that.) We replaced it with XML over HTTP, and as far as I'm aware it's still going strong.

I've always described the project as using web services, but we didn't use SOAP, and we were really just posting text to an old-fashioned ASP page. Web services do now seem to predicate the need for SOAP, which I don't really agree with, but the official definition (or the nearest thing I could find) is rather less precise on the protocol. This is what W3C has to say on the subject:

"There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

The interesting bit here (for me) is the last sentence, and the use of the word "typically" and "other web-related standards".
Does this mean that SOAP messages exchanged over FTP or SMTP could be defined as web services (though I'm not sure how WSDL would fit into this)?
Does a web service have to be request-response, or can it be simply push / pull?

No comments: