Menu

The True Meaning of Service

July 17, 2002

Kendall Grant Clark

The Conventional Wisdom...

At some point over the past 18 months the future direction of the Web began to be seen widely as a struggle between "Web Services" and the "Semantic Web". The latter was thought to be rooted in the W3C and academia, the former in IBM-Microsoft-Sun and industry. Since the significance of any debate of the form, "the future of x", depends almost entirely on the present value of x, debates about the future of the Web are often heated, primarily because the present Web is so valuable. There is too much at stake for half measures.

Part of the debate between services and semantics is a replay of the debate about what makes the Web an interesting place: commerce or content? In the conventional wisdom, services represent the commerce part of the Web, while semantics represent its content.

For the most part these lines of allegiance and interest have been unspoken. But they are usually revealed -- Freud would be unsurprised to learn -- in oblique ways: in, for example, canonical examples. For the services crowd, the canonical example is a complex, yet seamless commercial transaction; for some reason, airline reservations and stock market quotations show up most often. For the semantics crowd, the canonical example is some kind of agent or autonomous process seamlessly handling an otherwise onerous task: a popular example is automatic reconciliation of the schedules of a group of very busy (and, we're left to assume, very important) people who want to have a meeting.

...is Often Wrong

It's been clear for some time that the conventional wisdom is wrong. But I didn't really understand just how wrong the "Services versus Semantics" picture is until I started to acquaint myself with DAML-S. DAML-S -- presently at version 0.6 -- is an upper ontology of web services being built on top of DAML+OIL (which is morphing into WebOnt, a W3C project). The idea is that high-level ontologies of web resources can be very useful things and, here's the kicker, web services are just a kind of web resource. Web services are resources that, as The DAML Services Coalition puts it, "allow one to effect some action or change in the world, such as the sale of a product or the control of a physical device" ("DAML-S: Semantic Markup For Web Services").

So DAML-S refutes the conventional wisdom in its own modest way by suggesting that "versus" is not the only way to connect "semantics" and "services". If DAML-S were merely a thought experiment, it would already have provided an interesting, alternative way to look at the future of the Web. But DAML-S is much more than a thought experiment.

Why DAML-S?

The first bit about DAML-S to grasp is that it's a high-level ontology, one that sits at the application level and is meant to answer the what- and why-questions about a web service, as opposed to the how-questions, which are the domain of WSDL (see Rich Salz's excellent "Examining WSDL for details), about which more below. The value of having machine-digestible answers to the how-questions of a web service should be clear by now to XML.com readers. But what could you do with machine-digestible answers to the what- and why-questions?

The motivations for creating DAML-S include discovery, invocation, interoperation, composition, verification, and monitoring. A part of the practical cash value of any web technology labeled "semantic" is that the Web ought to provide something relatively useful in response to vague or even cryptic input from the end-user. If the end-user inputs "airline reservation" to her autonomous web agent, among the outputs ought to be, for example, the starting point of a web service which will guide her into making a flight reservation.

To support that and other kinds of end-user effect, we need smart service discovery. We need to be able to program agents to locate web services which satisfy a set of constraints. But smart discovery is useless without equally smart invocation; the end-user will be very disappointed if, after her agent discovers a way to make reservations, it cannot invoke the process. The end-user will be equally disappointed if, after it has discovered and invoked an airline reservation service, her agent cannot monitor the process, providing her with helpful feedback of the steps and graceful recovery from failures or problems. This requires equally smart execution monitoring to go along with discovery and invocation.

Developers and end-users alike, though in different ways and for different reasons, may want to build up complex web services from simpler ones, which is not possible unless or until one has machine-digestible descriptions of, among other things, the inputs, outputs, preconditions, and effects of the simpler services. Intelligent composition of services presupposes their interoperation, particularly automatic translations or mappings between clients and services. Last, for discovery to work, the properties of a service must be machine verifiable; whether or not a service satisfies the set of relevant constraints is a function of its properties.

Of course some of the preceding paragraph sounds like science fiction, but it is backed by solid research in agent theory and other areas of computer science. A mundane way of understanding DAML-S is to think of it as a marriage of autonomous agent theory and XML-RDF, WSDL-SOAP.

What Does DAML-S Include?

There is a lot to DAML-S already and there is more to come. I can't describe it all, much less go into much detail. In what remains, I want to point out the big chunks of DAML-S and point to sources for additional information.

Service Profiles, Models, and Groundings

The top level of the service ontology revolves around the Service class. A Service is a kind of web resource. One needs to know at least three things about a Service: what it does, how it works, and how one might access it. Corresponding to these questions, DAML-S offers three classes: ServiceProfile, ServiceModel, and ServiceGrounding. DAML-S declares three properties, presents, describedBy, supports, which have as their range these three classes. So, abstractly considered, DAML-S allows one to declare, in a machine-digestible form, that a Service presents a ServiceProfile, is describedBy a ServiceModel, and supports a ServiceGrounding. In practice, child classes of Service will have corresponding child classes of ServiceProfile, ServiceModel, and ServiceGrounding.

Process Models

In order to declare or describe how a service works, one must have a way to talk about processes, actions, and modes of execution. So DAML-S provides an ontology of processes, modeled by a child class of ServiceModel, the ProcessModel class, which is composed by the process ontology and the process control ontology. The former allows one to describe the inputs, outputs, preconditions, and effects of a service. The latter allows one to describe the state of a process, including how it is invoked, the paths of its execution, and the conditions of its completion. DAML-S also includes simple ontologies of resources and of time.

The Process class is the basic element of DAML-S's process ontology. A Process can have inputs, outputs, preconditions, and effects -- of any cardinality. DAML-S divides Process into three kinds: AtomicProcess, a process that takes all of its inputs at invocation time, executes, returns all of its upon completion, and which has a mandatory instance of ServiceGrounding; CompositeProcess, a process that is composed of atomic or other composite processes, and which can be decomposed into its constitutive parts using one or more of DAML-S's control constructs (Sequence, Concurrent, Split, Split+Join, Unordered, Choice, If-Then-Else, Repeat-Until, Repeat-While); and SimpleProcess, an abstract process that provides an alternative view of an AtomicProcess or an abstraction of a CompositeProcess, and which is either realizedBy an AtomicProcess or expands to a CompositeProcess.

DAML-S, WSDL, and the "Real World"

Eventually, of course, all this ontological declaration and high-level classification has to bottom out in real, working code. DAML-S calls this a "grounding", represented in DAML-S by the ServiceGrounding class. The ServiceModel and ServiceProfile parts of DAML-S are abstract representations of concrete services, and it is the ServiceGrounding which ties these two together. What is especially interesting is the relation between DAML-S's ServiceGrounding and WSDL. The DAML-S architects have discovered several important pathways of continuity between DAML-S and WSDL. First, what DAML-S conceptualizes as a grounding corresponds neatly with WSDL's notion of binding. Second, there is multipart correspondence of AtomicProcess to a WSDL operation (that is, variants of AtomicResponse correspond to the request-response, one-way, notification, and solicit-response variants of WSDL operation). Third, WSDL's abstract types, specified in XML Schema, overlap with the DAML-S declaration of service inputs and outputs, which can be specified by description-logic DAML+OIL classes.

Servicing the Future

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

By my lights it is the idea of grounding in DAML-S, and the likelihood of that idea being widely realized by WSDL, which propels DAML-S from the category of "interesting academic curiosity" to "something which may become part of my toolkit". Curiously, however, there is not too much that is Web-specific in DAML-S, which I count as another of its virtues. So even while the WSDL grounding will likely prove to be the most important, I haven't yet found any reason to think there could not be groundings based on high-level programming languages like Perl, Python, Lisp, Smalltalk, and so on. And if that's the case, it may well be possible to apply the advantages of DAML-S for web services to component programming in these languages. For example, it appears to be possible to use DAML-S to describe web server plugins such that, with the right infrastructure, one could do discovery, invocation, verification, composition, monitoring, and interoperation of these plugins. In a world where XML-RPC is being used as an intra-component server protocol to good effect, it's interesting to think about CPAN or an Apache module repository smoking DAML-S crack.

One thing DAML-S proves is that, as with nearly all comforting fictions, the "Services versus Semantics" debate turns out to be a big lie. Well, okay, maybe not a lie, but it's neither very accurate nor very enlightening. We would do well to cease believing in and fighting over and about it. Though we don't yet have any another story as stark or dramatic to replace it with, we as developers should do our best to learn to live without such stories. I suspect the future of the Web will be much like it is today, only different. Insofar as things like DAML-S succeed, that difference will be a pleasant and a happy one.

DAML-S Resources