My dictionary defines service as the work provided by one that serves. Sometimes it seems that you have to define something by itself, even when you don't want to.

Web services provide the ability for an organization to expose its business processes for consumption, either public or private. And they do so in a vendor-, platform-, and language-neutral format, as opposed to proprietary attempts at similar solutions over the past two decades.

But it should come as no surprise to anyone that the way that Web services get organized is, or should be, based upon an architecture that emphasizes the provisioning of services as the core paradigm. Yes, Web services design is based upon service-oriented architecture.

This concept has been around for decades. As soon as it became possible to split work off from a main computer and perform part of the processing on a separate machine, the concept of a service was born. Because the inevitable question that comes from this ability is "Well, what do I put where, and how do I use it?". Service-oriented architecture attempts to answer that fundamental question. No one seems to ask the more basic question - "Why do I want to do that?", but most of the time the answer appears self evident.

The reality is that certain hardware is more adept at certain tasks. A mainframe, for example, is superlative at I/O, and is often used as the data source of record in multitiered systems. Mainframes are expensive, however, and the past decade has seen a great deal of effort geared toward providing individual processing power to the desktop, in the form of the PC. Of course the problem was, and still is to a certain extent, the fact that the mainframe widely outstrips the capacity of a PC for things like databases and I/O, so the question has become one of "how do I work with the mainframe from my PC" rather than how to replace the frame.

Throughout all of the various shifts in computing paradigms, client/server, the Internet, occasionally connected computing, and so on, one facet has become clear - computing is about providing services. Early on in computing, copy books and operating systems provided a form of services - common routines that people used over and over again to accomplish higher-level tasks. Later, the concepts of distributed computing added the notion that not all services need to be provided by the same machine, and that services could be layered, federated, aggregated into more coarse-grained operations.

For many developers, the concept of a service seemed slightly foreign to the way they were taught to approach computing. One generation thinks in procedures, the next thinks in objects, but they both have the common tendency not to think in differences. The old saying goes "when all you have is a hammer, everything looks like a nail," and it holds true in programming as well, as developers tend to use what they know and ignore the possibilities that they are less familiar with.

Until Web services, it was difficult to make use of such services. Without discounting CORBA or DCE, or even COM, there were serious flaws either in the interface or the implementation of each approach that made them difficult to use.

But no matter how the concept came about, use of services required a fundamental shift in programming - from program to function. User interface became optional, not essential. The focus shifts to creating business logic that can be used by some unknown, arbitrary system, rather than on code that will only be called inside my Visual Basic or PowerBuilder program.

This issue focuses on service-oriented architecture and different aspects of the distributed programming paradigm. SOA is an important facet of application development under the Web services paradigm.

Now, off to more work. Ironically, the word service derives from the Latin servitum, which the dictionary defines as the condition of a slave. Such is life.