What is a Web Service?

Share the article!

The new catch-all word “Services” is making its rounds in the industry of late. But, just like the term “Component” it’s a word that is easily overloaded with different kinds of meanings.

I’ve been pretty satisfied with the definition of Components the I had done earlier, so I was thinking, just to keep the it straight for me, I wanted to at least come up with a moderately precise definition of the term “Service”.

The term Service is used in a few other industry buzwords, namely Web Services, Service Oriented Architecture (SOA), Enterprise Service Bus (ESB) and Application Service Provider (ASP). It’s an extremely overloaded term. However, Service in my definition is that software entity that is designed in isolation however provides near frictionless interoperability. It’s a strange almost mythical combination of competing requirements, that is it is both isolated and interoperable.

Just to be clear, Services are a not Objects nor are they the same as Components, however that doesn’t mean you can’t implement Services using Objects or Components. This fact actually causes a lot of confusion, just because you can implement something with X does not imply that same thing is an X. That X is just the implementation strategy, the actual thing that’s implemented which we call Services has certain well defined characteristics.

Services have the following characteristics:

  1. A mechanism to allow invocation in a distributed manner. This definition doesn’t prevent a Service from being invoked locally, however some kind of distributed invocation is an essential requirement. In general a Service cannot assume that the invoking client is in a shared environment. Also, notice that I don’t mandate a transport protocol. Much to the surprise of Web Service proponents, protocol and payload is irrelevant, what is relevant is that it can be discovered (see below).
  2. A mechanism to dynamically introspect the interface. In otherwords, all Services have a way of describing and advertising its capabilities to the entities that will use its services. This characteristic is what it shares in common with Components. However it differs from components that it includes information like Quality of Service guarantees and interoperability information. A client service should be able to dynamically invoke the service solely based on introspecting the interface.
  3. No implicit state sharing between Services. Unlike Objects or Components, the Semantics of an invocation will be derived from information available in the incoming invocation and its internal state. The idea is to support complete isolation between services, there should be no intergalactic wormhole type signaling. This also implies the need to use more granular invocation strategies like message passing.
  4. Asynchronous Invocation. Clients to a service cannot demand that a Service respond synchronously. The problem with the sychronous RPC style messaging is that it couples in time the parties involved. In otherwords, the parties have to be both present and active to get the communication across. It’s okay for realtime processes, however ubiquotous interoperability cannot assume this luxury.
  5. A Standardized Protocol Envelope providing a meta information about a document’s payload. This mechanism supports interception based strategies for implementation of crosscutting functionality that can span multiple Services. See my earlier piece on layer 6.

How does the above definition differ from Werner Vogels’ definition and Clemens Vasters d definition?

My definition differs from Vogels’ in that his defintion requires the use of XML and SOAP. My definition is actually even more lenient in the transport protocol. However, Vogels’ definition only implicitly alludes to the distributed and introspective natures of services. Shared state and asychronicity isn’t even discussed.

My definition has a lot in common with Vaster’s definition. It differs however in that I explicitly emphasize the distributed, introspective and asychronous nature of the beast.

This all sounds nice and dandy, but how does one glue it all together? Well that I suspect is what the Pi-Calculus is for.

My overall feeling about this entire exercise is that it feels like fitting a round peg into a square hole. Many of these ideas are directly derived from Loosely Coupled principles. I could just as arbitrarily have defined any variant system, all I did was simply match the ones that are commonly associated with Services. But maybe that’s the answer to the riddle, Services is just one of those indistinct concepts just like a quantum particle, it’s decoupled at the same time coupled. Go figure!

Share the article!