We have all heard of Web Services. In fact as architects, we very likely use the term almost every day. But what are Web Services really? The term is in and of itself very misleading. Web Services in fact do not necessarily have anything to do with the Web.
Based on the SOAP protocol, Web Services were designed primarily to be a means for invoking methods on remote objects (i.e. for doing RPC) in a platform neutral way over a transport (HTTP) that could easily traverse firewalls. As such, at the time the name made a lot of sense.
Unlike previous incarnations of the SOAP protocol, SOAP 1.2 is actually transport neutral, no longer tied to the HTTP protocol. As such, we now have Web Services accessible over proprietary transports such as MSMQ.
So if we no longer must use HTTP to access Web Services, why do we still call them Web Services? Good question, the name just stuck. So how do we define a Web Service today? The answer is a Web Service is any service that communicates based on the SOAP protocol and as such can be described with a WSDL (Web Service Description Language) document.
Although we may access a Web Service over a non-Web protocol such as MSMQ, it is still considered a Web Service.
Sunday, March 16, 2008
Web Services Defined
Subscribe to:
Post Comments (Atom)
2 comments:
I think you mean: "[SOAP] Web Services do not necessairly have anything to do with the Web."
SOAP is not the only way!
Indeed SOAP is not the only means by which to implement a service as part of a service oriented architecture.
But the use of SOAP is prescribed in order to have a Web service.
REST for instance is another way to go, but that gives us RESTful services, rather than Web services.
Post a Comment