This excerpt from Developing
Semantic Web Services
explains the convergence of semantics with web services by
complementing SOAP and WSDL with specifications such as OWL, SWRL, and
WSMO.
While the capabilities
of today's Web are impressive, its continued evolution into a resource with
intelligent features presents many challenges. Currently, the problem with performing
intelligent tasks, such as Web Services, is that they often rely on interoperation
of the two major proprietary server frameworks to successfully communicate complex
business logic.
The World Wide
Web Consortium (W3C) is currently developing architecture and markup languages
to support both Web Services and the Semantic Web. Tim Berners-Lee has suggested
that both of these technologies would benefit from integration. Integration
would combine Web Services' business logic with the Semantic Web's meaningful
content. There are several areas where the two could work well together. For
example, the current discovery (UDDI), binding (WSDL), and messaging (SOAP)
technologies could use Web Ontology Language (called OWL) to interact with Web
business rules; engines, thereby laying the ontology for Web Services.
H. Peter Alesso
In this article,
we discuss the markup language standards which form the building blocks
for
the next generation of Web Services; Semantic Web Services. These new standards,
Web Ontology Language, and its offspring, OWL DL for Services (OWL-S)
create
logic statements for inference engines utilizing Semantic Web Rule Language (SWRL). As a result, they form a basis for thinking about thinking on the
Web.
We will present
the state of development of Web Ontology Language for Services (OWL-S) and make
some comparisons to Web Service Modeling Ontology (WSMO) - a recent European
competitor. In addition, we will discuss related Web architectures and grounding
OWL-S services with WSDL and SOAP.
XML-based
Web Services
In a Web Service,
the agent sends and receives messages based upon their architectural roles as
shown in Figure 1. A requester is an entity that wishes to make use of a provider's
Web Service. It will use a requester agent to exchange messages with the provider
agent. In order for this message exchange to be successful, the requester and
the provider must first agree on both the semantics and the mechanics of the
message exchange.
The mechanics of the message exchange are documented in a Web Service Description
(WSD). The service description is a machine process-able specification of the
message formats, data types, and protocols that are used between the requester
and provider. It also specifies the network location of the provider, and may
include some information about the MEP that is expected.
Web Service's technologies
aim to enable a Service Oriented Architecture (SOA) on the Internet. In this
system discrete software agents must work together to implement some intended
functionality. Furthermore, the agents do not all operate in the same processing
environment so they must communicate by hardware/software protocol stacks that
are less reliable than direct code invocation. This has important implications
because distributed systems require developers to consider the unpredictable
latency of remote access, and taking into account issues of partial failure
and concurrency.
Web Service
Architecture (WSA)
Web Services provide
a standard means of interoperating between different software applications,
running on a variety of platforms. The Web Service Architecture (WSA), as defined
by the W3C, is intended to provide a common definition of a Web Service.
XML provides the
extensibility and language neutrality that is key for standards-based interoperability
of Web Services. Furthermore, XML helps combine the payload and protocol data.
Thus, the base technology of WSA consists of key XML specifications.
Services are invoked
and provide results through messages that must be exchanged over some communications
medium. WSA encompasses a wide variety of communications mechanisms including
HTTP, SMTP, FTP, JMS, and IIOP.
Today, WSDL is
an obvious choice as the means for the precise description of Web Service messages,
while SOAP is the key messaging technology in WSA. SOAP's envelope structure
has proven to be a very robust and powerful framework.
SOAP, WSDL,
and UDDI Limitations
Since a critical
mass of knowledge and technology has formed around SOAP and
WSDL, they will
likely continue at the center of the Web Service Architecture. However, these
technologies have limitations including:
Integration
with the Web; While SOAP Web Services use the HTTP infrastructure, they are
not able to hyperlink SOAP Web Service through HTML links or XSLT functions.
Extension mechanism;
SOAP provides an extension mechanism only through headers.
Overall understanding
of modules and layering; SOAP provides a framework within which additional
features can be added via headers, but there is little agreement on the specific
categories of functionality.
Automation;
the future of Web Services greatly depends on their ability to automate as
much of the Web Service process as possible under interoperable standards.
Matchmaking, or service discovery, is one important aspect of Web Services;
e-commerce interactions, and advanced matchmaking services require rich and
flexible metadata that are not currently supported by UDDI.
Next Generation
Web Services
To make use of
a Web Service, a software agent needs a computer-interpretable description of
the service and the means for access. An important goal for Semantic Web markup
languages is to establish a framework for making and sharing these descriptions.
Web sites should be able to employ a set of basic classes and properties for
declaring and describing services, and the ontology structuring mechanisms of
OWL provides the appropriate framework to do this.
OWL-S is a high-level
ontology, at the application level that is meant to answer the what- and why-questions
about a Web Service, while the how-questions are addressed as part of WSDL.
We can express an Ontology as:
Ontology = <taxonomy,
inference rules>
And we can express
a taxonomy as:
Taxonomy = <{classes},
{relations}>
As a result, an
ontology for Web Services would make Web Services machine understandable and
support automated Web Service composition and interoperability.
Therefore, the motivations for creating OWL-S include an ontology for Web Services
that provides several automated functions:
service discovery
service execution
service composition
service monitoring
Discovery:
A program must first be able to automatically find, or discover, an appropriate
Web service. Neither Web Service Description Language (WSDL) nor Universal Discovery
and Description language (UDDI) allows for software to determine what a Web
service offers to the client. A Semantic Web service describes its properties
and capabilities so that software can automatically determine its purpose.
Invocation:
Software must be able to automatically determine how to invoke or execute the
service. For example, if executing the service is a multi-step procedure, the
software needs to know how to interact with the service to complete the necessary
sequence. A Semantic Web service provides a descriptive list of what an agent
needs to be able to do to execute and fulfill the service. This includes what
the inputs and outputs of the service are.
Composition: Software must be able to select and combine a
number of Web services to complete a certain objective. The services have to
interoperate with each other seamlessly so that the combined results are a valid
solution. In this way, agent software can create entirely new solutions.
Monitoring: Agent software needs to be able to verify and monitor
the service properties while in operation.
We need to be able to program agents to locate Web Services which satisfy a
set of constraints. The end-user will be equally disappointed if, after it has
discovered and invoked an airline reservation service, but his agent cannot
monitor the process. This requires equally smart execution monitoring to go
along with discovery and invocation.
Developers may
want to build up complex Web Services from simpler ones using 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.
The ontology of
services provides three essential types of knowledge about a service:
The class Service
presents a ServiceProfile: What does the service provide for and
require of agents?
The class Service
is describedBy a ServiceModel: How does it work?
The class Service
supports a ServiceGrounding: How to access the service?
The ServiceProfile
provides information about a service that can be used by an agent to determine
if the service meets its rough needs, and if it satisfies constraints such as
security, locality, and quality requirements.
The ServiceModel
enables an agent to: (1) perform an in-depth analysis of whether the service
meets its needs, (2) compose service description from multiple services to perform
a specific task, (3) coordinate the activities of different agents, and (4)
monitor the execution of the service.
The ServiceGrounding
specifies the details of how to access the service such as protocol and message
formats, serialization, transport, and addressing. A grounding is a mapping
from an abstract to a concrete specification of those service description elements
that are required for interacting with the service; basically, the inputs and
outputs of atomic processes.
Building upon SOAP
and WSDL technologies, the OWL-S ontology-based Web services can be dynamically
invoked by other services on the Web.
The following listing
illustrates a Process.
<owl:Class
rdf:ID=Process>
<rdfs:comment> The most general class of processes</rdfs:comment>
<owl:disjointUnionOf rdf:parseType= owl:collection>
<owl:Class rdf:about="#AtomicProcess"/>
<owl:Class rdf:about="#SimpleProcess"/>
<owl:Class rdf:about="#CompositeProcess"/>
</owl:disjointUnionOf>
</owl:Class>
The atomic processes can be invoked directly and are executed in a single
step. For each atomic process, there is a grounding that enables a service
requester to construct messages. Listing 2 identifies an AtomicProcess as
a subclass of a Process.
The following
listing illustrates the Atomic Process.
Simple processes
are not associated with a grounding. They are single-step executions. Simple
processes are used as elements of abstraction; a simple process may be used
either to provide a view of some atomic process, or a simplified representation
of some composite process.
Relationship
between OWL-S and WSDL and SOAP
An OWL-S/WSDL grounding
involves complementary use of the two languages. Both languages are required
for the full specification of grounding even though there is some overlap (see
Figure 5). WSDL specifies abstract types using XML Schema (XSD), but OWL-S allows
for the definition of logic-based OWL classes.
WSDL/XSD is unable to express the semantics of an OWL class. Similarly, OWL-S
has no means to express the binding information that WSDL captures. Therefore,
an OWL-S/WSDL grounding uses OWL classes as the abstract types of message parts
declared in WSDL. The job of an OWL-S/WSDL grounding is to define the messages
and operations for the atomic processes that are accessed and then specify correspondences.
Because OWL-S is an XML-based language, and its atomic process declarations
and input/output types already fit with WSDL, it is useful to extend existing
WSDL bindings for OWL-S, such as the SOAP binding.
Grounding OWL-S
with WSDL and SOAP involves the construction of a WSDL service description with
the message, operation, port type, binding, and service constructs.
OWL-S atomic processes
specify the basic actions for larger processes and can also communicate the
primitives of a process specification.
The central function
of the OWL-S grounding is to show how the inputs and outputs of an atomic process
are realized as messages in transmittable format. WSDL has been used in developing
the initial grounding mechanism for OWL-S.
The OWL-S concept
of grounding is generally consistent with WSDL's concept of binding. WSDL is
used as the ground of an OWL-S atomic process.
OWL-S WSDL
Correspondences
OWL-S / WSDL groundings
are based upon the following three correspondences:
1/. An OWL-S
atomic process corresponds to a WSDL operation. Different types of operations
relate as follows (see Figure 6):
An atomic
process with both inputs and outputs corresponds to a WSDL request-response
operation.
An atomic
process with inputs, but no outputs, corresponds to a WSDL one-way operation.
An atomic
process with outputs, but no inputs, corresponds to a WSDL notification
operation.
A composite
process with both outputs and inputs, and with the sending of outputs specified
as coming before the reception of inputs, corresponds to WSDL's solicit-response
operation.
2/. The set of
inputs and set of outputs of an OWL-S atomic process correspond to WSDL's
concept of message.
3/. The types
(OWL-S classes) of inputs and outputs of an OWL-S atomic process correspond
to WSDL's extensible notion of abstract types.
Grounding
OWL-S Services with WSDL and SOAP
Because OWL-S is
an XML-based language and its atomic process declarations and input/output types
already fit with WSDL, we can extend existing WSDL bindings for use with OWL-S,
such as the SOAP binding.
Grounding OWL-S
with WSDL and SOAP involves the construction of a WSDL service description with
all the usual parts (message, operation, port type, binding, and service constructs,
except that the type element can be omitted.
The OWL-S extensions
are:
The owl-property
attribute is used in each part of the WSDL message definition to indicate
the fully-qualified name of the OWL-S input or output property. The property
name yields the appropriate OWL range class.
The owl-s-process
attribute is used in each WSDL operation element, to indicate the corresponding
name of the OWL-S atomic process.
The encodingStyle
attribute is given a value within the WSDL binding element to indicate that
the message parts will be serialized for class instances of the given types.
Once the WSDL service
description is completed, a WsdlGrounding object is constructed. The WsdlGrounding
object refers to specific WSDL specification elements using the properties listed
in Table 1.
Table 1
Properties for WsdlGrounding Objects
WsdlGrounding
Object
Properties
wsdlReference
URI indicating
the version of WSDL.
otherReferences
A list
of URIs for standards used by WSDL (e.g., SOAP, HTTP).
wsdlDocuments
A list
of the URIs of the WSDL documents that give the grounding.
wsdlOperation
The URI
of the WSDL operation corresponding to the given atomic process.
wsdlInputMessage
An object
containing the URI of the WSDL message definition that carries the
inputs of the given atomic process, and a list of mapping pairs, for
the correspondence between OWL-S
input properties and WSDL message parts.
wsdlOutputMessage
Similar
to wsdlInputMessage, but for outputs.
Creating an OWL-S
based Ontology for a Web Service requires five steps:
Creating an OWL-S
based Ontology for a Web Service requires five steps:
Describe individual
programs; describe the individual programs that comprise the service. The
process model provides a declarative description of a program's properties.
Describe the
grounding for each atomic process; relate each atomic process to its grounding.
Describe compositions
of the atomic processes; describe the composite process which is a composition
of its atomic processes.
Describe a simple
process describe a simple process for the service (optional).
Profile description
provides a declarative advertisement for the service. It is partially populated
by the process model.
There's no collaboration between the OWL-S and WSMO teams, but the OWL-S coalition
should be wrapping up at some point, while WSMO is just getting started. That
being said, there are of course points of contact. Indeed, at ISWC, there was
a joint tutorial on WSMO and OWL-S that included a comparison session. There
are intentions that the community pull it altogether at some point, but right
now there's some healthy diversifying.
H. Peter Alesso is an Internet
innovator with twenty years research experience at Lawrence Livermore National
Laboratory (LLNL). As Engineering Group Leader at LLNL he has led a team of
computer scientists and engineers in a wide range of successful multimillion-dollar
software development research projects. Peter has extensive experience with
innovative applications across a wide range of supercomputers, workstations
and networks. He has an M.S. and an advanced Engineering Degree from M.I.T.
He has published several software titles and numerous scientific journal and
conference articles. H. Peter Alesso is the author of three books: e-Video:
Producing Internet Video as Broadband Technologies Converge, (Addison-Wesley,
July 2000), The Intelligent Wireless Web
(Addison Wesley, 2001), and Developing
Semantic Web Services (A. K. Peters, Ltd., 2004).
