For the last few years there has been a lot of buzz about services of one sort or another: “software as a service”, “Web services”, and “service oriented architectures (SOA)” come most quickly to mind.
But, you might ask, just what is meant by the word “service” anyway? It is actually rather difficult to define it except by using that same word or a very close cognate.
For example one often sees definitions along the lines of “software as a service means software that is loaded on demand from a server” or “SOA is an approach to building software systems made up of a collection of autonomous services.”
Such definitions beg the question (or, as geeks might say, offers an infinitely recursive definition): can we do better than this, or is “service” just an axiomatic term whose meaning is assumed to be understood?
Maybe we can’t do better in terms of a logical definition but what we can do is pursue some analogies that shed light on what “service” means by comparing with what the word means in the larger business sense.
Defining “Service”
In the real world, we use services all the time — getting money from banks, ordering food from a restaurant, getting clothes dry cleaned, and so on. What makes these “services” is that we don’t need to know anything about banking, cooking, cleaning, etc. in order to use them, we simply request them.
This analogy between the service sector in the real world and the service orientation to software architecture may prove fruitful in analyzing the costs and benefits of SOA for a specific scenario.
In the real world, services provide something of value to those who know how to request and consume them, without having to know how to produce that value. How does all this relate to Web services, SOA, etc.?
In a nutshell, service orientation is an approach to designing systems in which each component knows only how to request and consume the services provided by other components, and little about their internal algorithms, data structures, stored data formats, query languages, etc.
This is basically the value that web services add to service orientation. SOAP, WSDL, and the others are a set of specifications and technologies that describe in detail how to request software services using Web and XML tools.
The most important feature of these technologies is that they define only the interface to a software component or process, and are independent of the language it is implemented in or the platform it runs on. In that sense, Web services technologies are like the pictorial menu of a Chinese restaurant by which one orders a meal by a simple “interface” that allows you to know nothing of the language, raw materials, spices, and techniques that must be employed to deliver it.
Pros and Cons of Services
Just as it is more expensive to eat at a restaurant than to buy food and cook it at home, there are various costs associated a service orientation to software.
First, of course, someone must make an up-front investment in building specialized services and this investment is risky because you seldom know for certain whether there is a real demand for those services at a profitable price point.
Another cost is the overhead of communicating between components with messages rather than shared memory or direct function calls. Similarly, XML is vendor and platform neutral, but imposes a processing overhead for parsing, character conversion, object building, and so on.
Nevertheless, these costs enable some very substantial benefits. Most important is simply that consumers have a choice of service suppliers in a service economy, and flexibility to choose the right service in a service architecture.
The efficiencies one gets by growing one’s own food or building one’s own components can be negated if specialized suppliers that can do this better come into being. Likewise, enterprise systems that communicate using shared data structures and specialized APIs can turn into liabilities if they impede the ability to initiate or accommodate change.
Customer needs are certain to change, existing suppliers may fail to provide good service, new suppliers who can provide better services at a lower price will come into existence — economies and software architectures that can respond to theses and other changes may well deliver value that outweighs the costs.
Service architectures also create opportunities for suppliers. First, the barriers to entry are lower if they can focus on providing one particular service extremely well and using other suppliers to flesh out offerings.
Likewise the odds of success for a high-value supplier are greater in a world where consumers have the ability to make choices and have an incentive to choose the best rather than the biggest or cheapest supplier.
Service economies took a long time to evolve, and continue to create considerable disruption. The same is likely to occur with service architectures.
It will take some time to restructure existing systems to share only interface information among components, and some time to demonstrate that the benefits outweigh the costs. The analogy presented here between services in the economic sense and services in the technological sense suggests that this evolution will take place.
Michael Champion is a senior technologist at Software AG, Europe’s largest and most established systems software provider. He has been a software developer for 20 years, including co-chairing the W3C’s Web Services Architecture Working Group. Champion is an author of numerous articles and a frequent speaker at industry events.