Columns

Leading software defines Web services

• By David Chappell
• October 1, 2004

Remember the object wars? People fought for years over exactly what an object was, waging battles that were a waste of time. Today, we’re in danger of fighting a similar losing battle. This time the issue is defining exactly what a service is, and the potential for confusion, and wasted time, is just as great.

The best way to define services is obvious: Look at what the dominant technology for services provides. Theoreticians can debate as much as they’d like about what a service should be, but what matters is what the dominant service-oriented software products implement.

We should have learned this from the battles over defining an object. Competing vendors each offered their view of the necessary characteristics of object orientation, with each definition usually reflecting a vendor’s product. In the end, we all agreed the characteristics of an object were those the dominant object-oriented programming language provided. This role was filled first by C++ and then by Java (and its doppelganger C#). Today, there’s not much argument about what an object is.

With services, it’s obvious what the dominant technology will be: Web services. Whatever anyone might wish, a service is going to be whatever the Web services specifications implemented by major vendor products provide. This includes SOAP and WSDL, as well as the WS specs, such as WS-ReliableMessaging and WS-Security, produced jointly by Microsoft, IBM and their fellow travelers. It doesn’t include technologies such as WS-Reliability or the Web Services Composite Application Framework (WS-CAF) -- the dominant products simply won’t implement them.

Whether they were consciously aware of it, the people who defined SOAP, WSDL and the WS specs were also defining what a service is. The process they used wasn’t very open, but then neither was the definition of C++ and Java, the basis for most people’s notion of objects.

Thinking of services in this way addresses some of the big issues that swirl around the service-oriented world. For example, can a service participate in an atomic transaction? From a theoretical perspective, one could make arguments both for and against this idea. Practically, the answer is “yes,” because the WS-AtomicTransaction specification, part of the fundamental set defined by the Microsoft/IBM-led alliance, allows it. Whether a service ought to participate in some atomic transaction is an entirely separate issue, one relegated to the more flexible world of service-oriented design. However, services by definition are allowed to take part in transactions simply because the dominant technologies make this possible.

It’s not clear how this large group of specifications manifest themselves in products. Microsoft’s complete implementation of its service-oriented platform, currently code-named Indigo, has yet to reach its first beta release and not much detail is available. Although IBM will likely add similar support under the WebSphere umbrella, it also hasn’t revealed much. What we do know is that these two vendors, along with competitors such as BEA Systems, will implement the same set of basic Web services specifications for security, reliability and transactions. This means a large share of service-oriented applications will have the same view of what a service is and how it behaves.

Reasonable people could quibble with some details of how the WS specifications define a service. Yet dominant software always wins: Shipping the most code guarantees that your view is heard. Thankfully, there’s no need to replay the definitional wars with services. We already know what a service is -- just read the right specs.