Web Services Initiative
Web-service Functions that Involve Semantics
In order to develop a broad understanding of the architectureal requirements
of semantic web services, we have developed the following (draft) list of
functions associated with the use of such services. These functions include
those that may be performed by a client of such services, those that may
be performed by the services themselves in order to fulfill their contract
as semantic enabled web services, and those that may be performed
by middle agents or other architectural support layers of the general semantic
web services architecture. We are focused exclusively on functional elements
are substantially changed (or only present) in order to take advantage of
the flexibility and broadened potential for dynamic interoperability provided
by semantically rich communications models.
This list of functions is divided into broad categories as follows:
Note: In the descriptions that follow, we use some terms consistently with
their usage in descriptions of OWL-S and DAML-S, the semantic services description
ontology created by the DAML-S coalition (See papers and materials at http://www.daml.org/services). In
particular, a service description is a set of formula in a formal
semantic description language characterizing the function (effects), processes
(activities) and data flow associated with a service. A grounding
is a mapping between elements of a service process description (in particular,
its inputs and outputs) and transport message formats. An atomic process
is a process that cannot be further decomposed into sub-processes that have
their own groundings.
- Advertising, Matchmaking and Service Selection
- Negotiation and Contracting
- Process Modeling, Interpretation and Enactment
- Community Support (Community Service Middleware)
- Service Lifecycle Support
We have (thus far) identified the following functions that would potentially
need to be performed by some part of the architecture to support semantically
enabled web services:
Advertising, Matchmaking and Service Selection
- Generation and advertising of (semantic) service descriptions -
Services need to be capable of producing (in a semantic web language
such as OWL) characterizations of the processes that they support of sufficient
detail that potential clients or third-party matchmakers acting as proxies
for clients can distinguish services likely to meet a client requirement
from those that are clearly inappropriate. While these service descriptions
may be fixed (pre-specified) for a given service, the services must be capable
of advertising them as either web pages or by sending these descriptions
to middle agent matchmakers.
- Candidate service discovery (matchmaking - by a referral process)
- Clients may formulate descriptions of services they require of sufficient
detail to match a class of potentially suitable candidates, transmit these
descriptions to other agents (matchmakers or peers), accept recommendations
of possible semantically-enabled web services meeting the specified
criteria. (e.g. In ubiquitous computing, find a printer when you walk into
- Candidate service selection (from potential candidates) -
Clients receiving multiple recommendations for services satisfying
(exactly or approximately) the requirements they have previously specified
must be capable of selecting from among those candidates. This may involve
ruling out candidates by applying additional (e.g. more time or context dependent)
criteria. This process may involve additional information discovery from
third parties or by direct communication and negotiation (see next category)
with the candidate services under consideration.
Negotiation and Contracting
- Service contract negotiation - In the process of selecting or
accepting a service to perform a particular function, a client may engage
in direct communications with the service to further identify the scope of
service provided or the compensation to be exchanged for that service.
- Non-repudiation/ Audit tracking and Explanation - "For e-Commerce
and other electronic transactions, all parties to a transaction must be confident
that the transaction is secure; that the parties are who they say they are
(authentication), and that the transaction is verified as final. Systems
must ensure that a party cannot subsequently repudiate (reject) a transaction.
To protect and ensure digital trust, the parties to such systems may employ
Digital Signatures, which will not only validate the sender, but will also
'time stamp' the transaction, so it cannot be claimed subsequently that the
transaction was not authorised or not valid etc." (Quoted from the Information
With semantic web services, non-repudiation may involve logical reasoning
about the fulfillment of contracts, as by the generation of a logical proof
(explanation) that entries in an audit trail, together with non-repudiation
support that the audit trail represents evidence of certain events, implies
a conclusion that the contract was fulfilled (or not).
- Dispute Resolution and Compliance - Third party services may
be involved in conflict resolution, proof verification, and the direction
of settlement compliance.
Process Modeling, Process Model Interpretation, Enactment, Tracking
- Service invocation (message formulation) and response interpretation
- The reasoning involved in identifying the information required for
each parameter of each message required to invoke a service process from
the service's process description. E.g. Identification of required input
values for a P.O. message to SAP, as defined in a semantic service process
description; application of the grounding of that process description
transform the data and insert it into a particular transport representation
(such as WSDL/SOAP). Interpretation of a response message by applying a mapping
(the grounding) back into a semantic description of the response.
- Choreorgraphy & Orchestration - Protocol interpretation
and execution - There seems to be a distinct lack of clarity about what
is distinguishes the terms choreography and orchestration for web services.
The Web Service Choreography Interface
(WSCI) definition document states that choreography "Describes
temporal and/or logical dependencies among Activities" and says the WSCI
language is for describing the temporal and logical dependencies among the
messages the Web Service exchanges with one or more other services in the
context of a given scenario. HP in Web
Services Orchestration states "Orchestration describes how web
services can interact with each other at the message level, including the
business logic and execution order of the interactions. These interactions
may span applications and/or organizations, and result in a longlived, transactional,
multi-step process model. Choreography tracks the sequence of messages
that may involve multiple parties and multiple sources, including customers,
suppliers, and partners. Choreography is typically associated with the public
message exchanges that occur between multiple web services, rather than a
specific business process that is executed by a single party." (from
by Chris Peltz, HP).
Our (SWSA) requirement is that there be a semantically grounded language
for describing the temporal constraint relationships between processes (activities),
and between processes and the messages that initiate them, and which they
initiate. This language needs to be interpretable by clients as they prepare
to interact with a service, and services must describe the constraints
on message sequences and associated activities in this language.
- E.g. Protocol descriptions could be described by UML
- E.g. Temporal relationship between Request, Acknowledgement
of a PO
- Process mediation (control message mediation between different possibly
asynchronous msg patterns) - There are times when two interacting services/clients/agents
use protocols that are incompatible in terms of the number of messages associated
with a semantically compatible activity. Examples include the relationship
between the SAP PO protocol and that of RosettaNet where one requires
messages be explicitly acknowledged and the other does not. To mediate a
process interaction between the two requires an explicit mediation component
that allows the semantic content to be passed through, and hides the choreography
- Automated process composition - It is an explicit goal for semantic
web services that the infrastructure support software agents that can not
only invoke services that are dynamically discovered, but that they can compose
them. A simple useful case is to enable substitution of one service for another
that is perhaps unavailable even if the replacement requires some additional
preprocessing be done before the service can successfully run. More generally,
the use of automated (AI) planning techniques to invoke a collection of services
for a joint purpose.
- Semantic translation (e.g., of message content, process descriptions
or advertisments) - The semantic web will consist of a large number of
services developed at different times and places. Descriptions of these services
and the information that they manipulate may therefore use different but
often semantically related concepts. To support broad semantic interoperability,
it must be possible to define correspondences between terms developed independently
and for servers, clients and middle agents to use those correspondences to
overcome syntactic and terminological differences between representations
in order to accomplish the other functions in this and the other categories
of this document.
- Task management / Task status tracking - As processes are enacted
and their associated activities occur, there needs to be means of tracking
the state of the execution, so that clients can determine when and whether
they will complete. The development of ontologies for describing the state
of processes, and for characterizing partial completion will be important
for execution and compensation management on the semantic service web.
- Ontology management (for communities sharing ontologies) - Middleware
services for collecting and supporting queries related to terminological
definitions and mappings between ontologies.
- Community management (partnering services) - membership servers,
- Authentication services - Identity verification services
- Reputation service - Services that evaluate or act as clearinghouses
for third party evaluations of services.
- Resource Allocation/Provisioning - Computer resource scheduling
- Privacy and Confidentiality - The enforcement of policies regarding
(May be handled by a lower layer of the architecture that we
- Registration & nameservices - Middle servers that track
active and inactive services by name, host...
- Service (operational) status - Is the host running? is
the service process active?
- Instantiation (e.g. service factories) - The execution of new
copies of service instances on demand.
- Service migration (between hosts) - Use of mobile code to transfer
running service threads to new hosts.