The True Meaning of Service
by Kendall Grant Clark
|
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
- The DAML-S site
- W3C's Web Services
list archives -- DAML-S is a frequent topic of conversation here
- The Parts of DAML-S:
- Service.daml
- Profile.daml
- Process.daml
- Time.daml
- Resource.daml
Prev [1] [2]