Web Services Defined

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.

SaaS service vs. SOA service

"Service" is a horribly overloaded term that means many different things to many different people in many different contexts. No wonder there is so much confusion over the term Service Oriented Architecture!

One instance of this confusion manifested itself in a discussion I had with a collegue regarding whether there was any specific interplay and bleeding of the lines between SaaS and SOA. Both terms include our favorite word... service. And in fact, many SaaS providers expose Web service (there's that word again) interfaces as integration points, which has led some people to believe that using a SaaS application delivers you an SOA.

To clarify, "service" in the context of SaaS refers to a software delivery model, as opposed to an architectural entity. In the context of SOA, a SaaS application is architecturally identical to any third party application that is hosted in house. The integration capabilities are often similar. Most third party business applications expose Web service interfaces, as do most SaaS applications.

Such an application (SaaS or otherwise) could potentially behave as all or part of a service in the context of an SOA. Even so, you would want to wrap the application's Web service interface with an integration layer that provided richer messaging capabilities (such as guaranteed once-only message delivery and publish/subscribe) to the rest of your enterprise.

So in conclusion, you can utilise SaaS applications in your enterprise and have no SOA, you can have an SOA with no SaaS applications, or you can have both. They really are orthogonal concerns, with SOA being an architectural style, and SaaS being a software delivery model.