A Semantic Web Services Architecture
Version 1.0 (April, 2005)
- This version:
- Latest version:
- Mark Burstein (BBN Technologies)
- Christoph Bussler (Digital Enterprise Research Institute (DERI),
- Mike Dean (BBN Technologies)
- Andreas Eberhart (AIFB, University of Karlsruhe)
- Carole Goble (University of Manchester)
- Michael Huhns (University of South Carolina)
- Tim Finin (University of Maryland, Baltimore County)
- Frank McCabe (Fujitsu Laboratories, Sunnyvale, California)
- Juan Miguel (DERI, Innsbruck, Austria)
- John Mylopoulos (University of Toronto)
- Norman Sadeh (Carnegie Mellon University)
- Amit Sheth (University of Georgia)
- Massimo Paolucci (Carnegie Mellon University)
- Stuart Williams (HP Labs, Bristol, UK)
- Michal Zaremba (Digital Enterprise Research Institute (DERI),
The Semantic Web Services
Initiative Architecture Committee (SWSA) proposes the following
architectural and protocol abstractions as a foundation for supporting
Semantic Web Service technologies on the World Wide Web. This document
based on a review of
gathered from a number of different environments to identify the
and potential requirements for this Semantic Web Services architecture.
Status of this document
Version 1.0 is now available for public comment.
The Semantic Web Services Initiative
(SWSI) is an 'ad hoc' initiative of academic and industrial
researchers, many of whom are involved in DARPA, EU funded and nationally
funded research projects. SWSI started in the autumn of 2002 based on
common interest of the researchers involved.
The mission of the Semantic
Web Services Initiative Architecture committee (SWSA) is to develop
architectural and protocol abstractions forming a reference architecture to
support Semantic Web Service technologies on the World Wide Web. In part,
this proposed architectural framework builds on and extends the Web Services Architecture
[WS-ARCH] developed by the Web
Services Architecture Working Group of W3C. We will also make use of
terms and concepts in a
conceptual architecture for semantic web services [SWS-CA] that extends
the Web Services WG Architecture. It also is based in part on the layered
Web Architecture as proposed by Tim Berners-Lee [TBL00]. Further
significant input is taken from the
OWL-S Coalition [OWL-S],
the WSMO Working Group [WSMO], the open grid services architecture
[Fo02] and the METEOR-S project [METEOR-S].
This document describes abstract protocols for interactions between
clients and Semantic Web Services and proposes other support services that
may be needed in some contexts to fulfill the basic requirements of the
proposed architecture. Our goal is that this architecture provides a
foundation that will support a variety of semantically enabled service
deployments in a variety of current and future distributed environments,
especially those building on the World Wide Web. We anticipate that the
architecture will also indicate requirements for Semantic Web service
description languages which are being designed by our sister committee, the
Our approach to developing an architectural framework for Semantic Web
Services is based on an identified set of roles and requirements for
machine interpreted semantic descriptions in the deployment of Semantic Web
Services to different distributed environments, addressed in our previously
Requirements Document. This document summarizes and builds on the prior
one by describing protocols between interacting entities or agents that can
interpret and reason with these descriptions to achieve those required
We are focused specifically on capabilities that extend the potential
range of web services in the direction of dynamic interoperability over
extended life cycles, while at the same time addressing concerns about
security, reliability, and flexible means of recovery from interpretation
and execution problems that can occur in such open and evolving
The SWSA interoperability architecture covers the following classes of
support functions to be accomplished by Semantic Web agents (service
providers, requestors, and middle agents). While not all operational
environments will find it necessary to support all functions to the same
degree, we anticipate that the distributed functions to be addressed by
this architecture will include:
- Dynamic Service Discovery: The capability of a software agent,
through interaction with other agents, to identify candidate services for
- Service Engagement - Negotiation and Contracting: The
capability of two agents to mutually formulate, by offline or online
interaction, a shared agreement on the terms of performance of a service
to be provided by one agent for the other. This includes publication of
service models that services commit to follow, and more dynamic
interactions leading to contracts between clients and services.
- Service Process Enactment and Management: The capability to
dynamically select and invoke or interact with services to achieve some
defined objective. This includes formulating service requests satisfying
all semantically described criteria for acceptance, interpreting all
messages from service providers, and monitoring the status of service
execution and completion criteria contractually agreed upon. Where
defined, it also includes a capability to interpret and enact associated cancellation,
failure recovery and compensation mechanisms. Service process enactment
may require following extended protocols and interaction
plans that involve multiple services. Plans may be self-generated or
published in a semantic process language and interpreted.
- Semantic Web Community Support Services: Capabilities
associated with sharing semantic descriptions, ontologies and ontology
mappings, and service catalogs within and across communities. Support for
managing community membership, privacy and authority relationships, and
shared informational resources.
- Semantic Web Service Lifecycle and Resource Management
Services: The capability to spawn, allocate, manage and report on the
life status of services, computational host platforms and storage
facilities for Semantic Web Services.
- Cross-cutting Issues: Semantic representations of two kinds of
service quality meta-properties may be important during discovery of
appropriate services, may appear in service agreements, and may be
monitored during execution. The first set of properties relate to quality
of service performance, the speed, timeliness, result completeness and
effectiveness attributes that can make particular services more or less
appropriate for use by certain clients or in certain contexts. The second
class of properties represents policies of services regarding security,
privacy and trust. We will touch on how these two aspects of services
interact with and cut across our other major architectural support
The architecture described below is based on abstract protocols and
functional descriptions of capabilities, rather than specific software
modules or components. Our objective is to define a model of
interoperability that can underpin a variety of architectures without
prescribing specific system design decisions. Eventually, concrete software
components have to be built. If these are designed to be consistent with
the proposed abstract protocols, the components will interoperate as
defined by the protocols. This allows prospective developers maximal
freedom in building software components while ensuring architectural
interoperability. This approach is intended to be consistent with the
approach of the World Wide Web Consortium, where protocols like HTTP and SOAP are
defined without constraining the software components that implement those
2. Supporting Multiple Distributed Environments
Semantic Web Services are viewed as a way to extend the capabilities of
web services in the direction of dynamic interoperability, and in
particular address the need for interoperability in the face of
heterogeneous standards for representing content communicated between
distributed components. There are many situations where systems developed using
web services will need to overcome
interoperability limitations arising from their inability
to agree in advance on the syntax and semantics of
interactions. Semantically transparent web services make
it possible for clients to successfully
utilize them without prior arrangements negotiated by people and
realized in rigid software protocols and uninterpretable meta-data models.
There are a number of communities for which these goals are
- Commercial web services, in
both B2B and B2C applications, will benefit from the increased dynamism
offered by Semantic Web Services that can be identified, selected and
utilized 'on the fly' to do such tasks as comparing costs and options for
acquiring and selling goods and services. A key problem with
current-generation enterprise integration software is their need for
regular software updates to accomodate rapidly changing standards for
representing goods, services and protocols for transactions. Semantic web
services will provide mechanisms to make these representations
self-describing and eliminate much of the cost of software reengineering
to make such updates.
- Grid computing applies
distributed computational resources to large scientific problems. Users
seek to dynamically describe compositions of remote resources to solve
large problems. To manage computational resources effectively, they need
to be able to substitute comparable, but not necessarily identical
services seamlessly based directly on semantic descriptions of their
functional capabilities, quality of service and timeliness of
availability, without regard for whether those services were known in
advance to the client, or have revised their interaction protocols since
- Ubiquitous computing efforts
utilize wireless portable devices carried by people to different
environments to access locally services. Here, there is a strong
requirement for dynamic discovery of locally available services meeting
user needs, and for means to address the privacy and security issues
associated with access to such services in different contexts.
- Information Services.
Everyday, users of the web access the enormous and constantly changing
world of information it makes available. They will have an increasing
need to utilize semantic web services to access and combine the results
of searches across heterogeneous data repositories whose contents are
displayed in dynamically generated pages and hence cannot be indexed by
web search engines.
In all of these environments, two major barriers to inter-community
interoperability are incompatibile information models and mismatches in
exchange protocols utilized by different communities of service
providers. One big reason for these differences is that they were
developed by different groups. Another is that models, syntactic encodings
and protocols change over time as services evolve to meet changing
needs. Dynamically accessible semantic descriptions of service capabilities
and utilization protocols can help to overcome these barriers, but only
in a distributed environment which fundamentally supports individual
software agents' ability to interpret (perhaps after translation)
unfamiliar ontologies and declaratively described process
constraints. Lastly, given the open ended nature of such distributed
environments, the architecture must support effective means for managing
semantically interpretable security authorizations and ensuring the privacy
of transmitted information.
Expected Stages of Semantic Web Service Development and Adoption
Based on our requirements collection for these different target
environments, we expect that some aspects of our proposed architecture will
be seen as more central to some classes of applications than others, and
that some other aspects will take longer to be adopted. In particular, we
anticipate that many of the high payoff near-term applications developed
will de-emphasize fully automated discovery and focus on the use of
semantic mediation for interoperability between clients and services
selected by users or services that are automatically chosen from small
collections of pre-identified candidates. For example, such collections
could be formed by companies that have contracts that gain them entry to a
particular community of service providers. These kinds of application
scenarios can avoid the use of automated negotiation between clients and
services that would come in later stages of semantic web service
development. Nonetheless, they might still require support for semantic
interoperability to address issues such as regular changes to their
interaction protocols, message formats and semantics.
Overall, we see something like the following
stages of development and exploitation of semantic web service technologies
occurring over the next few years.
- Stage 1: Simple service invocation and response handling
- User directed manual discovery,
- User directed composition,
- Ensuring semantic interoperability during invocation and
response exception handling
- Predefined and lossless mapping (through simple translation
- Stage 2: SWS with Automated Discovery and Mapping
- Goal and capability characterization for matchmaker querying
and service selection reasoning
- Partial mapping of Semantic Web Services based on registries
- Stage 3: Complex Discovery Models and Negotiation/Contracting
- Proxy/Broker based interaction protocols, including forwarding
of QoS and Privacy requirements
- Negotiation dialogs for refining discovery, establishing
In the near term, we expect that situations requiring dynamic service
discovery and utilization will be predominantly ones where humans will
continue to be involved in the selection process, either because the
selection criteria are not sufficiently formalized or because the number of
available services is not large enough to require complex semantic
matching. In such situations, the key technological advance will be in
utilizing semantics for service enactment, the process of mediating service
requests and responses so that a client does not need to have hard coded
knowledge of the syntax of invocation messages.
As the technology matures, or perhaps in tandem with this first stage,
we anticipate the development of mechanisms for supporting automated
service discovery and matchmaking. A key element of this phase of
development will be the development of shared, extensible
community-wide ontologies for describing capabilities, services and goods,
and moving these ontologies into the public domain as semantic web
The third stage of semantic web service development will address more
complex and extended service interactions, as necessary for on-line
negotiation of service contracts, and for multi-party interactions such as
the utilization of proxies or brokers that present interfaces to composite
services. Brokers may fully or partially mediate other services while hiding some
of their complexity. For example, they might allow a user to plan a whole trip,
while semantically mediating the identification of and interaction with
a number of back-end
services, but require the client work directly with the back-end service agents
when things go wrong it becomes necessary to request compensation
for service contract failures.
3. Underlying Assumptions
The architectural framework we describe stands on the shoulders of two
emerging technological concepts: Web Services and the Semantic Web. From
web services we bring the notion that service interfaces can be published
on the web using XML, and more specifically, WSDL, and can be invoked using
web protocols like HTTP and SOAP. From the Semantic Web we bring the notion
of web published and accessible semantic descriptions using
dynamically linked and shared ontologies. In addition, work in
semantic web services contributes the notions of orchestration,
choreography and mediation. We recognize that different communities may
not always share ontologies directly, but instead will, in many
cases, have different and only partially comparable ontologies and
protocols, covering some of the same or related concepts. Complete semantic
interoperability may not always be possible, although substantial
improvement can be achieved when ontology mappings enable semantic
translation between different representations of concepts based on
different ontologies, and the tasks being addressed do not necessarily require full
As a result of these considerations and assumptions, our architecture
will assume the following general capabilities of agents (both clients and
In other words, for dynamic web services to function, clients must be able
to semantically interpret the published descriptions of unfamiliar service
interfaces and make use of them to decide which service to use and to
formlate requests to those selected services. As these service interfaces
continuously evolve, this will enable the interactions to continue to occur
smoothly. If the changes make a service inappropriate for a particular
client's need, then it will allow that client to discover new services that
meet its needs better.
- All agents can interpret web-published ontologies and send and
interpret messages whose content can be represented or interpreted in
terms of published ontologies. This is not to say that the serialized
form of these messages must be in a Semantic Web description language
like OWL [OWL] or the Web Service Modeling Language [WSML], but if it is
not, then there should be a published description of the message format
in such a language, or a translation mapping that allows the message to
be interpreted semantically.
- Service providers must publish semantic descriptions of their service
capabilities and interaction protocols that can be interpreted by and
used by prospective service consumers to (1) select appropriate services for
their needs, and to (2) successfully interact with those services. These
descriptions must utilize widely shared Semantic Web description
languages and ontologies that are accessible and shared via the Semantic
- Requestor agents (clients or other web services) must be able to
reformulate those internal objectives that they seek to have delegated to
external agents as well formed requests to service providers, by using
the published, semantically described service interfaces of those providers.
4. Phases of Semantic Web Service Interaction
The process of discovering and interacting with a semantic web service
(Figure 1) will, in general, include the following phases:
- Candidate Service Discovery - the distributed search for
available services that can accomplish the client's internal goal or
objective. A number of alternative protocols for this phase of
interaction may be developed, but they will all be utilized by
prospective clients as they interact with agents other than the
service providers from which they will ultimately request services.
Instead, these clients will typically be interacting with a matchmaker or
peer who makes recommendations about potentially useful services.
- Service Engagement - this second phase includes the process of
interpreting candidate service enactment constraints, partly or fully
described by each candidate web service in it's published
self-description, and then requesting or possibly negotiating
with each prospective service to reach agreement on the terms of the
service to be provided.
Engagement concludes with both service and
client knowing and agreeing to the terms of service provision in an
explicit or implicit Service Contract (SC). If explicit
negotiation occurs, it may address such things as the determination of
the particular price to be paid for a service, agreement about the
attributes of the product that the service provider will provide, or the
quality of the service provided. Enactment protocols may also address
issues of authentication and authorization for either or both the service
requestor and provider to engage in the service enactment protocols that
- Service Enactment - the interactive process coordinated by
messages between clients and services that accomplishes their mutual
objectives as specified by a Service Contract developed during
engagement. If the primary objectives of the contract are not
accomplished, then a compensation protocol may be utilized. During
execution, if the transport model allows for asynchronous interactions,
the client may use protocols that allow for the monitoring of the status
of the service process.
Figure 1 gives an overview of the relationships between these phases of
interaction as a kind of workflow model. A client starts with an internal
goal that it intends to accomplish by utilizing an external
service. Correspondingly, service providers have the general goal of
providing the services they were designed to provide, often in exchange for
some form of compensation. These agent goals are reiterated in various
forms in semantic descriptions of used in exchanges during interaction
processes. Client goals are represented in the semantic descriptions
created to query semantic service registries as requirements on potential
service providers. They are also represented, typically in a different
form, in the requests to potential providers of services.
In the overall service utilization process, service requests (messages
from clients to propective services) are part of the second or Engagement
stage. These requests to services may simply be honored by a provider (in
which case we move directly to the Enactment stage), or serve as the
prelude to a multi-step negotiation protocol culminating in a "handshake"
indicating mutual acknowledgement of a joint contract. The third stage,
that of service enactment, consists of alternative protocols to initiate
service activity, monitor service processes, and confirm service
completion. If the service terminates abnormally after a contract has been
formed, there may be a final set of protocol interactions to address
Figure 1: Service Interaction Process Overview
In the following sections, we describe the requirements and architectural
supports for each of these stages of service interaction. The architecture
for each stage will be described primarily in terms of abstract protocols
for accomplishing the stage's requirements. The protocols will consist of
exchanges of messages of various semantic types, and identifying the state
changes in the role players resulting from these messages. Our message
types are assumed to be represented in an ontology of communcations acts.
utilize the set of communications performatives developed by the FIPA
community [FIPA-ACL] as an initial set of abstractions on which to build our
ontology of the message types referenced in these abstract
protocols. The FIPA performatives we will refer to are the following:
- Inform - The sender informs the receiver that a given
proposition is true. This is used, for example, in advertising a
service. The content of such messages is a proposition. In more specialized
Inform message types, the content could be a part of the full
proposition, with the message type conveying some contextual part of the
description. For example, an Advertise message would be a special
kind of Inform that communicated to the receiver (generally, a
matchmaker) that the content of the Advertise was a description of
an available service. Its use would be limited to contexts where the
recipient had (by publishing a service model) agreed to communicate that
information to other agents when queried appropriately. Inform
messages are also used for such things as to reply to queries, and to
convey service process status.
- QueryRef - The sender asks the receiver for the object(s)
referred to by a referential expression. This is used to query a matchmaker
during discovery. The content of a QueryRef is a descriptor or referential
expression that can be used as a query pattern.
- Request - The sender requests the receiver to perform some
action. Variants include RequestWhen, which also specifies a
proposition which, when true, will trigger doing the action. Simple
service requests use this performative.
- Agree - The act of agreeing to perform some action (at some time).
- Refuse - The act of refusing to perform a given action requested
by another agent (typically the message recipient), and explaining the
reason for the refusal.
- Cancel - The act of one agent informing another that the first
agent no longer has the intention that the second agent perform some
- Propose - The act of submitting a proposal to perform an action,
given certain preconditions.
- AcceptProposal - The act of accepting a previously submitted
proposal to perform an action.
- RejectProposal - The act of rejecting a proposal to perform some
action (during a negotiation).
Semantic Protocol Overlays
There are multiple aspects to the semantics of a service request that
can each cause a service to respond with a message addressing issues or
problems with the request. This will particularly be true as messages
themselves are formulated using semantic description languages. Missing
information, unmet constraints, and invalid authorizations are just a few
of these issues. For example, a request may not specify all of the optional
values for service constraints that the service provider needs to determine
how or when it performs the service, such as the shipping method to be
used. Similarly, a request may not include sufficient information about the
sender's authority to make the request.
Often such issues are addressed in the engagement stage of service
interaction. Strictly speaking, service provider replies that ask for
clarifications of various kinds could all be considered types of error
responses, but we will treat them as semantically characterizable
sub-dialogs, as they lead to semantically similar message exchanges that
can occur in a number of different parts of our protocols. We will
represent these generically as a kind of 'overlay' or subdialog so that we
do not have to repeat them many times in the protocols representing our
three main stages of service interaction.
Specific service implementations may only allow these dialogs to occur
at particular points in their more detailed service interaction
specifications, and their service description models will have to describe
these restrictions. Our primary objective here is to identify what is
common about these protocols and characterize their semantic message
In the following sections, where we describe a set of abstract
protocols for the three main stages of service interaction, we have
simplified the diagrams of these protocols by not including the many
different ways that these sub-dialogs might be interleaved. Instead, we
introduce them once here, and then mention where they will occur.
In some of the abstract protocols shown below, a service may refuse to
process a Query, Request or Inform because the request is semantically
ill-formed for some reason, or certain pieces of information required to
make the request executable were not provided. For example, there might be
a two-day advance notice reqired on a request for a funds transfer from a
bank. Specifying today's date on the request would be considered a semantic
error that results in a refusal with a reason. This reason could be used by
the client to reformulate the request. This kind of clarification
sub-dialog has the form shown in Figure 2. When the service can provide a
semantic description stating a reason for the failure, then the agent
making the request may reformulate the request and try agein. When a
refusal is not accompanied by a reason for the refusal, then no
continuation is possible. In subsequent figures, we will indicate it by a
simple CLARIFY branch where this dialog might occur.
Figure 2: Abstract Clarification Dialog Protocol Fragment
The trigger to this general pattern of response is that the
the message sent by the service provider be interpretable as having semantics
to be consistent with the FIPA performative REFUSE. so that the client is aware both that
the request as previously made will not be honored, and that the cause was the particular
stated inadequacy of the request. If present, the latter enables the request to be reformulated
in such a way that the protocol can continue as indicated.
Generic Authorization/Permission Sub-dialog
Another aspect of requesting a service is the supplying of appropriate
credentials of the requestor to demonstrate permission for the request to
be honored. The communication of credentials information is often not tied
to the particular request, and so may be done once for an extended set of
requests (e.g., a log-in). Therefore, for any particular request, the
credential information could be optional, and the service might ask for
credentials after any request where it did not know the sender's
authorization. When credentials are required, they are generally supplied
before the completion of the engagement stage of interaction. Note, though,
that permission may also be required to interact with a matchmaker during
the discovery stage, for advertising and/or for querying the
Figure 3 captures the general case for this protocol
sub-dialog, including both the condition when the client proactively provides credentials as
part of a request, and the condition when the service requests credentials after a query
or request is made.
Figure 3: Abstract Authorization Protocol Fragment
This protocol fragment utilizes some additional semantic classes of message types
formulated as specializations of FIPA message types, as shown in the following table.
The point here is that even though the protocol is specified abstractly, and does not reflect what a particular service might implement,
protocols of this kind will be characterized by an exchange of messages that fall within these types.
||May be included as part of original request message
||A request for the name of authorization source or authorization token of the client.
||Acknowledge that authorization is accepted by server.
||Report that authorization is NOT accepted by server.
This kind of abstract characterization of a class of protocols and their semantics elements can thus be used to
guide the interpretation of and the formulation of responses to a variety of services. In the sections that follow, where we
detail the three main phases of service interaction, we will repeat this pattern of describing abstract protocols and
their semantic message elements.
5. Service Discovery
Service discovery is the process by which a client (service requestor),
identifies candidate services to achieve the client's objectives, by
interacting with peers or special purpose middle agents (matchmakers). From
an architectural point of view, the discovery process involves three types
- service providers have the goal of providing particular types
of services (possibly for compensation), and publish or advertise their
services to enable potential clients to discover and utilize them,
- service requestors have the goal of finding services that can
accomplish some internal objective, and
- matchmakers are middle agents that can be used to find
(descriptions of) the service providers that match the stated
requirements of a requestor. Matchmakers that both find and invoke
services as proxies for the requestor are called brokers.
Following the Service oriented architecture (SOA), service providers
advertise with middle agents by sending descriptions of the services that
they provide through publish protocols; and service requestors use query
protocols to ask the middle agent to find the services that more closely
satisfy their needs. The role of these middle agent matchmakers is to
recognize which provider has the capabilities that most closely satisfy the
needs of the requestor.
For current generation web services, this is predominantly a manual
process, in the sense that registries like UDDI [UDDI] are designed to be
searched by developers of client systems, rather than middle agents
or users of client systems during execution. In the Web services architecture,
web services correspond to service providers, services clients are the
requestor, and UDDI registries are the middle agents.
In contrast, semantic matchmakers use semantic relations to find
services described using Semantic Web languages [Dec97] [Sy99] [DAML-S]
[OWL-S] [Pa03] [Ve04] [WSML] [WSMO]. The language the SWSI Architecture
committee will use to specify protocols for advertising service
capabilities and for agents to discover useful services will be described
by the SWSI Language Committee.
In general there are design tradeoffs to be made in selecting level of
abstraction of the capability description used in a query to a
matchmaker. Typically, a requestor has a specific goal, while service
providers publish generalized descriptions of their capabilities intended
to capture the range of specific activities they support, such as selling a
general class of items. To be effective for matching against published
service descriptions, capability descriptions should more abstract than
specific goals, but may need to include information about how the
goal should be achieved, and under what constraints. For example, if the
client's goal is to fly from Pittsburgh to Boston on July 3 for less than
$300, the client might query for capabilities of individual service
providers, that included services such as quoting prices for and selling
airline tickets. A more detailed match might check that the provider
supported particular cities, or allowed pricing constraints to be included
in its queries. Abstract capability expressions for airline ticket vendors
would most likely not include details such as the times, routes and costs
of particular flights that they offered for sale. These details would need
to be resolved during negotiations or interactions directly with a selected
The use of abstract capability descriptions must be reflected in the
power of the description languages used for Web Service discovery. The use
of abstract capability descriptions where attributes may be described as
allowing ranges or classes of values requires less transfer and storage of
data, since the capability description abstracts much of the information
required to represent particular goals. It also means that matches between
the descriptions generated from requestor goals and those published by
service providers may be imprecise, leading to a need for a post-match
negotiation. To appreciate this, consider the advertisement of Amazon.com's
Web service. The described capability of the service is to locate and sell
books, but this specification does not show what books are available,
whether they are in stock etc. These details are typically negotiated
between individual requestors and services after they are
discovered, although there is clearly a continuum of possible divisions of
these third-party matching/brokering and direct negotiation processes.
The use of abstract capability descriptions thus implies an
architectural division between discovery and negotiation, based on the
premise that discovery can be performed as an interaction between a
requestor and one or a set of middle agents that are aware of a set of
general service capabilities provided by other agents. Negotiation, in
contrast, is part of the engagement process, by which a requestor
and service provider finalize an agreement on the precise service to be
delivered. In effect, a client or requestor simultaneously finalizes its
selection of which services are to be utilized only when it has negotiated
out the details of the precise service to be provided to a particular
client. While one might view the discovery process as not completing until
a service has been selected, our view is that discovery only involves the
requestor's acquisition of information about some candidate services.
The requirements for service discovery can be divided into the
language requirements supporting a provider's ability to express its
capabilities and a requestor's ability to describe abstractly classes of
relevant services that might be used to achieve its goals; functional
requirements specifying the tasks that need to be collectively
performed; and architectural requirements describing classes of
interaction protocols supporting the functional requirements, and
specifying how the role players will interact during the discovery
The stakeholders involved in the discovery process must be able to
communicate their requirements and their capabilities to other role players
in choreographed interactions. The semantic language requirements for
discovery are based on the need to describe and communicate the following
using a semantic description language:
- The characteristics and constraints (preconditions, fulfillment
limitations) of the services that are available
- The requirements of service requestors, namely
The abstract message types utilized in the protocols specifying
interactions between the role players, as described in the protocols
- The goals that it wants to achieve
- The capabilities that it expects from the provider
- Additional constraints such as quality of service, security and
The discovery process has these overarching requirements:
- The ability to describe in a general manner the capabilities of and
constraints on services that could be used to fulfill other agent's
future goals or requirements.
- The ability of a client to describe its own internal goals and
create abstract descriptions of methods by which other web services might
support or achieve those goals in order to facilitate matching of its
goals to published service capabilities.
- The ability of clients to locate and interact with peers or
matchmakers that can respond to requests to match capability queries
against advertised service descriptions, potentially including meeting
client specified constraints on quality of service and degree of
- The ability to compare descriptions of web service requirements
(queries) and descriptions of web service capabilities (advertisements)
when those descriptions are represented using different ontologies
by use of translation, mediation, or matching integrated with ontology
- The ability of a client to decide if it can satisfy the
pre-conditions specified in a prospective service's self-description.
Protocols to support these functional requirements in a peer to peer
and middle-agent enabled service discovery environment will include the
- Service Description Advertising Protocols: Protocols by which
a service announces its capabilities, limitations, interaction
requirements, and protocols to peers or middle agents that can be queried
for this information. A Semantic Web language should be used to formulate
these descriptions. Advertising may also be passive, similar to the
posting of web pages, in conjunction with search engine collection
mechanisms. If clients have explicit representations of goals, these
should be included in the discovery and matchmaking task.
- Candidate Service Discovery Protocols: Clients requiring
services to satisfy their objectives must be able to formulate as queries
descriptions of requirements for services that could meet these
objectives. These descriptions should include any limitations on how or
where or when the objectives should be met, or on the form or content of
the information that might be provided in order to initiate the
service. These service requirements may be provided in a single query or
by an extended interaction protocol that elicits additional
discriminatory requirements based on the available candidates. The
protocols should enable responses to queries to include descriptions of
multiple services (either in a single response or streamed), and to
include or enable requests for characterization of the degree and quality
of match or mismatch.
These protocols assume capabilities of the middle agents:
Agents responding to such queries must be able
to compare service requirement descriptions to a variety of service
Matchmakers, like other kinds of registries, may be
federated and organized for matchmaking along community or semantic
functional categories [Si04].
- If the middle agents are brokers rather than matchmakers, responses
may be based on the result of selected and executed service(s), and
negotiation with services may be mediated by the broker. We will assume
in the rest of this document that the middle agents are matchmakers
rather than brokers.
The abstract protocols shown in figures 4 and 5 below represent the set of
interactions between service providers, matchmakers or registries, and
clients in search of particular services. In each of these diagrams, the
links are labeled (as in UML) with a condition shown in square brackets,
typically a message received, and an action that results in entering a new
Note that interactions with a matchmaker may potentially be as complex
as interaction with any other service. In specifying protocols for
discovery, we have not therefore described in full detail all of the
potential elaborations that we describe later for general services,
including the possibility of authentication requirements, and revisions to
ads or their cancelation after publication.
Figure 4 represents the class of protocols by which a provider provides
a service to a registry or peer that makes recommendations. The registry
may, on evaluating the proposed advertisement, respond with a variety of
critiques of the proposed advertisement, or refuse to accept it at
Figure 4: Service Advertisement Protocol
||Although also an Inform, the request is to record and publish the
description, which means it can be Refused and the service may fail to
||Reasons can include ill-formedness, lack of authorization, wrong type of service for this broker.
||(Shown as 'OK') Acknowledges that posting is accepted by server.
||(Not shown.) After installation, a Request to update an advertisement previously accepted by the server.
||(Not shown.) After installation, a Request to terminate the publishing of an Ad.
Discovery Query Protocol
Figure 5 represents the protocol by which a client interacts with a
registry or peer to discover a service that could potentially satisfy it's
requirement. After evaluating whether the returned descriptions are
consistent with the client's goals and it's ability to meet the service's
applicability (pre) conditions, the client may generate a revised
query. Note that the registry may ask for clarification of the query, or for authorization to use the service.
These potential subdialogs are as shown above.
Figure 5: Service Advertisement Protocol
||Request information about relevant services. Must include an abstract characterization of the services sought.
||A reply reporting the results of a successful query.
Engagement - Negotiation and Contracting
Service Engagement is the negotiation and contracting process consisting
of a sequence of exchanges between parties to establish a formal agreement
among them, whereby one or more parties will provide services to one or
more other parties. The agreement typically involves QoS issues. There are
generally three phases to negotiation: (1) through negotiation with brokers
and directory services, potential partners are located, contacted, and
engaged, (2) the specifics of services, such as their quality, are
negotiated and decided, with the resulting agreement then captured in a
formal contract, and (3) negotiation may also be needed during the delivery
of a service, to ensure compliance with agreements and resolve any disputes
- Service Contract Pre-Negotiation: Potential partners, that is,
consumers and providers need a means to exchange information about their
respective goals and capabilities. This may involve the use of additional
information sources, e.g., third-party registries, recommendations from
other partners, direct inquiries to other parties and previous
- Service Contract Negotiation: Potential partners (consumers
and providers) need a means by which they can reach agreement regarding
the requirements for and constraints on provisioning of a service.
Agreement among partners may extend to include the technical means of
interaction to action and monitor the provisioning. This latter may be
provided in the form of a web service interface.
- Dispute Resolution and Compliance: Third party services may be
involved in conflict resolution, proof verification, claim adjudication,
and the direction of settlement compliance.
- Non-Repudiation, Audit Tracking and Explanation: Paraphrasing
from the Information Security Glossary [ISG]:
For electronic commerce and other on-line transactions, all parties
to a transaction must be confident that it 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 authorized or not valid etc.
With Semantic Web Services, non-repudiation may involve logical reasoning
about the fulfillment of contracts, as by the generation of a logical
proof or formal explanation that makes use of 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).
- Negotiation Protocol: A standard protocol for negotiation must
be provided and available. The protocol would be generic and appropriate
for negotiation in any domain.
- Negotiation Service: A negotiation service is a stand-alone
provider of expertise in negotiation, similar to an authentication
service, which could be contracted by a client. Providers of this
service would be free to determine the particular strategy that they
would employ during a negotiation. Providers would engage in negotiations
on behalf of clients that were either incapable of negotiating, unaware
of appropriate negotiation protocols, or too busy to negotiate.
- Mediation Service: Neutral experts or specialists in
negotiation might be used to help the parties reach an agreement, resolve
disputes, determine compliance or breaches, adjudicate claims, determine
and impose penalties, or terminate an agreement.
- Auditing Service: In order for compliance with a negotiated
agreement to be measured, an audit of the activities of the parties to
the agreement might be needed. This would be provided by a Web service
with an auditing capability.
- Negotiation-Enabled Web Service: A Web service with a
negotiation capability could have a portType described in the WSDL
document for the service. Like WSCI, the description could be included
within the documentation section of the WSDL document.
Protocols for service engagement describe message exchanges between
service providers and requestors that result in formal or informal
agreements for services to be provided. There are three fundamental
protocols, reflecting a range of sophistication among the parties to an
agreement. The simplest protocol, which is equivalent to the FIPA
query-reply protocol [FIPA-ACL], is used to establish the provision of a
service without any negotiation or formal contract. The second protocol,
which is equivalent to the FIPA request protocol, requires the provider to
agree to or refuse a request, and results in a non-negotiated commitment to
provide a service. The third, and most complex, protocol is used to
establish a formal negotiated contract for the provision of a service. The
parties can iterate over the terms of the contract until agreement is
reached or the negotiation is abandoned. The result is a set of commitments
that bind the parties to each other until the contract is fulfilled.
The abstract protocols for engagement have been motivated by
representative use case examples, accompanying each figure shown below.
The set of additional abstract message types used are collected at the end of this section.
Simple Query Protocol
"Please provide your service for me."
This use case requires no agreement from the provider, just an attempt
to enact its service, as shown in Figure 6. A failure to provide the
service would be undistinguishable from a denial of service.
Figure 6: Engagement: Query Protocol
Simple Request-Reply Protocol
"Will you provide your service for me?"
Provider: "OK." | "NO."
Figure 7: Engagement: Request-Reply Protocol
As shown in Figure 7, the Request-Reply protocol requires the service to
either agree or refuse to provide the service before enactment begins.
Requestor: "Will you provide your service for me?"
Provider: "Only if you pay me ten dollars".
Requestor: "I will
pay you five dollars if you provide your service by 5:00 pm."
"OK." | "NO."
Result if OK: an explicit contract for the service, and implicit
commitments by the parties to satisfy the terms of the contract.
Requestor: "Will you provide your service for me?"
Provider: "Only if you pay me ten dollars".
Requestor: "I will
pay you five dollars if you provide your service by 5:00 pm."
about three dollars? I will provide my service by 7:00 pm."
"OK." | "NO."
Result if OK: an explicit contract for the service, and implicit
commitments by the parties to satisfy the terms of the contract.
Figure 8: Engagement: Negotiate-Commitment Protocol
These use cases illustrate the kinds of negotiations that can take place
between a requestor and a provider. Note that these are all two-party
negotiations. The negotiations typically involve the two parties exchanging
proposals and counterproposals until an agreement or a refusal is
reached. Also note that both parties are required to notify the other when
a negotiation is abandoned. Time-outs are used so that no party is left
hanging when another party misbehaves or fails. The result of a successful
negotiation is an explicit contract that can be modeled as a
commitment between the parties.
The table below shows informally the semantics of the messages used in the engagement protocol figures above, and the
FIPA performatives that each is an elaboration of.
||Content is the description of the service desired, potentially along with anciliary information to identify the
requestor, provide authorization, or convey non-functional preferences and conditions. Also used for revised requests.
||Acknowledge receipt of request and inform of intent to perform the service.
||Inform that the client no longer has the intention that the server perform the service previously requested.
||Inform a client of a description of a service that the server will intend if client agrees. Typically used to make a counter offer or
to elaborate on the details of the action the server will do in responding to the request.
||Inform server that client agrees to offered service.
||Inform server that client does not agree to the offered service. This is an alternative to R' (Figure 8)
where no new request is made, so that the service may make a new offer.
7. Service Process
Enactment and Management
Once a service has been identified that can satisfy a client
goal or requirement, it must be invoked and monitored, by
determining the information needed to request the service be performed, and
determining how to react when the service responds with either success or
- Representing and specifying objectives (e.g., as requests):
The client (service
consumer) needs to be able to specify the goals or objectives it is
trying to achieve by requesting a service. This might be in the form of
a goal ontology or by formally specifying the important aspects of the
desired state. A goal ontology might contain a concept such as "perform
travel reservation" representing a shared understanding. A desired state
might be specified as the traveler owning a ticket with certain
properties. Objectives are used to formulate queries for service
discovery by third parties, to select among candidate services identified
in that process, and to identify specific information to include in
- Candidate Service Selection - Relating objectives and preferences
to service capabilities: The client or service consumer needs to be
able to relate objectives and additional preference criteria to the
advertised capabilities of service providers in order to select which
services to make requests of. This selection process will identify one or
a subset of a pool of candidates known to the client or identified by
other agents during discovery.
- Service request formation and response interpretation: The
client must be able to identify the information required to compose
service requests or participate in service invocation protocols with the
services selected to satisfy its objectives. The formulation of these
requests should be based on the published service process description
provided by the service provider, in part on the client's reasoning about
the relationship of that description to the semantic description of its
objective, and in part on the relationship of the service description to
other information accessible by the agent. The client must also be able
to interpret responses to generated service requests, as described in the
service process description.
- Request and Response Translation: When a client and service
provider use different ontologies for describing their domain models and
communications content, interoperability requires that there be means of
translating the semantic content of their communications. This kind of
semantic translation may be done by client, server, or middle agents,
under suitable conditions.
- Choreography interpretation and execution: There needs to
be a semantically grounded language for describing the temporal
constraint relationships among 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 or process sequences and associated activities in this language
- Process mediation and delegation: 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
- Dynamic service 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 planning techniques to invoke a collection of services for a
joint purpose [Na02][Mc02].
- Process status monitoring and event notification: 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 [Na02].
- Service failure handling and compensation: Services that
are dynamically discovered and invoked must also provide declarative
descriptions of their failure modes and associated means of recovery
and their types of and protocols for compensation.
While many of the functional capabilities above must be resident
within clients and servers, some may be provided by middle agents. In
these cases, standardized protocols may be defined, which would utilize
widely shared ontologies.
- Ontology translation services: Alternative protocols for
interacting with translation services include request-response models
where the translation is provided to the requesting agent vs. translate
and forward models.
- Process mediation services are typically conceived of as
middle agents that can be interposed between agents for whom
semantically compatible interactions are possible, but whose
choreographies do not align in terms of the number and types of
messages to be exchanged.
- Process scheduling and composition services: Agents that
provide planning and scheduling services require effective ontologies
for describing temporal and domain constraints, and for describing
objectives and preferences. Their products must utilize ontologies for
choreography primitives and for describing process invocation
- Process execution and status logging services can be
utilized for failure recovery and compensation authorization services.
Protocols for controlling logging services must interact with several
layers of an agent's communications infrastructure. Protocols and
ontologies for querying a logging service may be widely standardized.
- Interaction monitoring services are those that will be resonsible
for ensuring that interaction protocols are observed.
- Policy monitoring services make sure that all services that are invoked maintain the contractually guaranteed QoS aggreements are maintained.
Abstract Enactment Protocols
Service enactment is the process of service invocation and monitoring by
determining the information needed to request the service to be performed, monitoring it,
and determining how to react when the service responds with either success
or failure. Abstract enactment protocols, presented in this section, model
three possible interaction scenarios. In the first scenario, we consider a
synchronous communication, where the service requestor sends a message and then
waits for a return message. In two other scenarios, we consider
asynchronous communication, where the service requestor talks to the
service provider, but after sending a message it does not expect a
synchronous message back. In the first case of asynchronous communication,
a one-way message is sent from the requestor to the provider and the
service requestor does not expect any message back. In the second case of
asynchronous communication, a reply message is expected by the service
requestor at some point in time. The UML diagrams below model these
protocols taking into consideration the failure and exception
situations which might happen during a conversation between service
requestor and provider.
Each of the scenarios described below has the same set of preconditions, namely, the discovery and engagement
to an explicit or implicit service contract. The engagement phase must be executed before
enactment to establish a service contract. In each of these abstract
protocols, enactment communication is initiated by a service requestor when
sending the first invocation message.
Synchronous Enactment Protocol
The synchronous enactment protocol describes the case in which a service
requestor issues a message to a service provider and waits in synchronous
mode for the reply message. The service requestor either receives a message
or a time-out happens. Both the provider and requestor make a distinction
between sending a reply and sending a failure message. The timeout of
either party is visible to the other party as well. In case of requestor
timeout, the provider does not have to send a reply any more. The protocol
also includes a compensation state once the failure situation takes place.
Figure 9: Enactment: Synchronous Protocol
Asynchronous One Way Protocol
The asynchronous one way protocol, the simplest from these three
protocols, describes the case where a one-way message is sent from a
service requestor to a service provider. In this scenario only one failure
situation is considered, when the service provider is not able to
understand or to process the received message so the failure notification
is issued to the requestor. There is no output message for this scenario if
execution is successful.
Figure 10: Enactment: Asynchronous - One Way Protocol
Asynchronous Two-Way Protocol
In an asynchronous two way communication protocol, the service requestor,
after sending an initial message, does not lock the channel but moves into a
wait state while, at the same time, being capable of sending
subsequent messages. Once the service provider finishes processing a
message from the service requestor, it is capable to issue a reply message
in an asynchronous fashion. Although the communication remains
asynchronous, both parties must be able to relate any messages exchanged as
being part of the same conversation. The service requestor can query for a
status of previously sent messages to check their current status at the
provider side. Both timeout and failure situations can happen at the
service requestor and the service provider sides. Similar to synchronous
protocol, the asynchronous protocol includes compensation state for the
situations when failure happens.
Figure 11: Enactment: Asynchronous - Two Way Protocol
The following table shows the types of messages that were involved in the various enactment protocols above.
||Message content is a reference to the agreed upon service contract, developed during the engagement phase. If the preceding
engagement protocol consisted only of a request (the Engagement Query-Reply Protocol) or Enactment followed directly after the client
agreeing to an offer in the Negotiate-Committment protocol, then this message is skipped.
||Communicate the informational result of a service, along with its status.
||Communicate the failure of a service enactment, possibly with an accompanying reason.
||Request update on the status of a service in progress.
||Communicate the status of a service enactment, possibly with an accompanying reason.
||Signal that client no longer intends Server to perform service contract.
||Client timeout results in it no longer intending Server to perform service contract.
||Acknowledge that server has received Cancel or Error and stopped performing service.
||Request the initiation of a compensation process after a ServiceFailed message is received. Compensation would
be based on an (implicit or explicit) Service Contract.
||Inform client of the completed execution of and result of a compensation process.
||(not shown) Inform client that server does not agree to the provide compensation for stated reason
This class of middleware services (architectural requirements)
support various aspects of distributed activity that can be supported
with semantic web architectures. They represent the following
desiderata of Semantic Web services and web services generally:
- Shared and interoperable ontologies Communities that
develop partly or potentially interoperable ontologies need mechanisms
to share definitions and mappings between concepts [Us03].
- Information and access security, privacy and confidentiality
are ubiquitous concerns in web services that are to be deployed
commercially or otherwise accessible widely.
- Control of and access to shared information about group
membership and privileges.
- Community-based preference and reliability measures for
service discovery and selection are common on the web, and in human
communities. Recommendation services on the Semantic Web will assist in
prioritization among potentially useful discovered services.
- Ontology management and mapping services. There are
environments in which middleware services will be used to collect
ontological information and support queries related to terminological
definitions and mappings between ontologies. In particular, ontological
mappings cannot be discovered without such services because they are
not directly referenced by the original ontologies that each agent uses
itself. Protocols for accessing and extending these mappings, and other
kinds of commentary about ontologies will be required for translation
by translation services and by agents that are doing their own
translation in order to interoperate directly with services using
different ontologies than they use [Us02][Bu04].
- Security support services include those providing the
policies governing semantic information security, and their
relationship to agents communication layers implementing such policies.
Protocols are required to disseminate and apply broadly these
semantically described policies for security control.
- Privacy and Confidentiality Support Services utilize
related ontologies and protocols for ensuring that classes of
information related to other agents is protected by the enforcement of
policies regarding information distribution.
- Reputation support services: Services that evaluate or act
as clearinghouses for third party evaluations of services require
protocols for incorporating new fault evidence and service
- Membership and Authority services require protocols for
defining classes of membership which authorize services to perform
activities for particular clients, and to authenticate clients for
membership in these classes.
- Policy and protocol management services: Similar to
ontology management services, there may be middleware services that
aggregate community policies and protocols for domain-specific
operations other than those called out above. These services will be
critical for such things as choreography interoperation (process
mediation) among communities with sets of services that share protocols
for implementing such things as failure and compensation policies.
- Provenance information management services: These are middleware services that are responsible for the delivery of data probenance related information. These services play an important role in ensuring that the data provided to clients is of appropriate quality. Examples of domains requiring these
services include bioinformatics and medical information suppliers, content delivery services such as news services, and security management services.
Lifecycle Support Services
In distributed environments, including web services and the Grid,
resources are shared among partners and across communities. The Grid
community has begun adapting their approach to resource sharing to
align it with and benefit from the increased interoperability provided
by web services and to anticipate the additional benefits of Semantic
Web services technology [Fo02]. The issues that they have addressed are
also important for many other kinds of Semantic Web Services
The lifecycle of a resource is a set of states and transitions
between those states. During their lifetime resources can be in a set
of stages (e.g., down, starting, up, failed, stopping etc.), and
substages (e.g., idle, busy, degraded etc.) during which they may or
may not be managed via manageability interfaces of their associated
services. (e.g., a failed resource may not respond to some management
The types of resources that can be shared range from CPU cycles to
storage facilities, from databases to software components. This
diversity in the types of resources has led to development of "Resource
Models" [WSRF][GCRM][CIM] that are the basis for the recently developed
ontologies for resources which will provide a common vocabulary for
interchanges about controling and managing them [Ta03].
Semantic descriptions of resources will not be sufficient by
themselves to support a sustainable resource sharing environment.
Resources and the services utilizing them have a lifecycle relationship
that also needs to be modeled and taken in to account to achieve
dynamic resource sharing. In general, we must model the dependencies
and relationships among services that reflect resource sharing, the
resource management policies and manageability capabilities that
services and resources provide, and the lifecycles (state models) of
both resources the web services they interact with.
These ontologies can be used to ask and answer questions or make resource
management or resource provisioning decisions such as:
- Ask the question: Is the resource (e.g., a remote instrument)
still (stuck) in a starting state? If yes, find me a similar resource
that is restartable.
- (After a notification has been received stating that the
interface of a Web Service used previously has been "upgraded".) Ask
the question: Does this upgrade affect the service interface?
- Describe the policy that after a task has fully utilized host H's
CPU for 2 hours, the task should be suspended and a new task should be
assigned for the next 2 hour slot.
- Describe the request to find a service that is capable of creating
instances of process X, with support for reporting status
using the terminology in ontology Y.
- Describe the policy that all the subscribers of a service should
be notified when a service on which it depends has been deprecated or
upgraded (or otherwise changed lifecycle state).
Resource management agents acting on behalf of service requestors
need to have three types of information to make provisioning decisions:
resource and service status information, resource manageability
capabilities, and resource provisioning policies. With Semantic Web
Services, each of these types of information may be represented and
acquired dynamically, and used to control and manage resource sharing
among communities of many service users.
- Creation and monitoring of resources. Web services can be
used to create instances of resources (especially software services)
and manage them through their lifecycle, including stopping, resuming
or restarting them.
- Represent the lifecycle of resources: Extensible
ontologies will be needed to define the generic lifecycle states and
state transitions in a class of resource's lifecycle. This ontology can
be used to establish a basic shared understanding of communications
relating to resource lifecycle. Different types of resources can have
lifecycle models that are created by extending the base ontology.
- Represent the lifecycle of Semantic Web Services that
utilize or provide access to resources. The service lifecycle may be
unified with the resource lifecycle model to provide a single model.
- Represent dependency relationships among services and
resources, including service management of resources, and the kinds and
scope of service dependencies on resources. Services provided on the
Web or the Grid can be composite services. These composite services
make use of other services thus have dependencies on them. Changes in
lifecycle of one service can have an affect on its dependants. This
dependency information should be incorporated in service descriptions,
and reflected in a composite lifecycle model for those composite
services so that decisions about service utilization can reflect
expected resource demands and availability.
- Represent Resource Management/Provisioning policies. We
need ontologies for a policy language that can be used to represent
provisioning policies of all parties in a service oriented distributed
- Represent Resource Manageability Descriptions Like service
descriptions themselves, resources have a certain capability to be
managed, reflected only partly in the protocols or interfaces that they
can respond to. 'Manageability' descriptions provide the resource
managers with the means to plan how they administer discovered
resources as they become available.
- Represent Lifecycle Changes Another lifecycle issue is the
representation and management of changes in a distributed environment.
If the change is planned (i.e. version upgrades, operational changes,
service decommissioning, service deprecation) then it should be
recorded, and described (semantically) to allow the dependent parties
to adjust their processing. Keeping records of lifecycle state
transitions, and change is not only important for resource management
and provisioning but also to avoid dangling references to services that
no longer exist in the form they have been used. If change is
unexpected (e.g., failures, malfunctions) the control of disruption
requires providing ontological descriptions of these unexpected changes
via exception handling mechanisms and independent resource managers.
- Protocols for semantic control of resources. Resources
will be remotely managed using protocols that convey semantic
descriptions establishing service (and client) task relationships,
providing constraints on the time and scope of resource provision, and
transitions between resource lifecycle states.
- Resource allocation/management services are middle agents
that interact with services to obtain resources.
- Resource lifecycle change detection and notification
requires architectural support at the infrastructure level, on which
web services are built.
- Resource and service lifecycle protocols. perhaps defined
using a service protocol or orchestration language, will govern the
interactions between controlled resources and management/allocation
Two areas other requirement areas that impact the architecture of
semantic web services generally are the overarching needs for security
and information privacy, and means of expressing and ultimately
controlling or monitoring the quality of the services provided. We
address these issues here.
Quality of Service
In Web processes for e-commerce and other kinds of GRID and Web
service applications, suppliers and customers define a binding
agreement or contract between the two parties, by specifying Quality of
Service (QoS) metrics [Ca04][Ze03]. Examples of QoS metrics include
deadlines, quality of products, and cost of services. The management of
QoS metrics is critical to the success of organizations participating
in e-commerce. It affects how services are advertised, is a major topic
in negotiation processes that precede contract formation and service
provision, and can impact how enactment occurs and the type and level
of compensation when it does not occur successfully. Therefore, when
services or products are created or managed using workflows or Web
processes, the underlying discovery, coordination and execution engine
must accept the specifications and be able to estimate, monitor, and
control the QoS rendered to customers.
Metrics and means of monitoring and adjusting for QoS may,
depending on domain and performance requirements, be actively managed
for any of the following:
- Time: Execution time and duration of service occurrence.
- Cost: Cost of the service to the requestor, and measures
of resources consumed.
- Reliability: Measures of likelihoods of success/failure
and fail-safe outcomes
- Operational Metrics: Other domain specific quality
Issues that must be addressed include:
- QoS Aggregation in Processes: Workflow process level quality
of service may need to be calculated as an aggregate measure of the QoS
of the set of services enacted. Aggregation may be done on each type of
QoS individually, with different aggregation operators.
- QoS Representation and Reasoning: Whereas industry initiatives
like WSPolicy [WSPF] and WSLA [WSLA] have proposed XML mechanisms to
provide policies for web services, these efforts assume pre-defined
vocabularies for creating policies, rather than extensible semantic
representations. There is a need for an extensible ontology of QoS
parameters and aggregation operators for more flexible discovery,
negotiation and enactment. This must be accompanied by a policy language
and reasoning engines that can express and reason simultaneously about
QoS and business logic.
- QoS Driven Discovery: Functionality of a service is arguably
the most important factor for discovery. In real world business
scenarios, partnerships are typically more important and it is probable
that the companies will have preferred partners for various tasks. In
such cases, it is possible that service discovery is relegated to a cost
benefit analysis of the various QoS metrics.
- QoS based Optimization: There is often a need to optimize
business processes based on various quality of Service criteria. Various
optimization techniques like Integer Linear Programming or genetic
algorithms can be used to optimize processes [Ag04] [Ze03] based on QoS
- Monitoring and Enforcement There is a need to create
mechanisms to monitor the performance of services and ensure that they do
not violate their promised QoS levels. Reactive planning can be used in
case of failure or breach of QoS by a service.
Security, Privacy and Trust
In open, heterogeneous information systems, information assurance,
security, trust and privacy are issues of central concern [WSS]. In an
architecture promoting dynamic service discovery and semantic
interoperability, these issues become more critical and more technically
challenging. The richer communications model supported on the Semantic Web
also provides opportunities for new kinds of solutions to these
problems. We see requirements arising from three kinds of policies.
- Security policies control the access to services or service
- Privacy policies control the use of information provided by
service clients. [Ga04]
- Trust-based policies for security or privacy may be provided
when control of service capabilities can be based on reasoning about
factors such as reputation or verifiable semantic relationships between
agents, rather than explicit authority relationships.
- Semantically described security policies. Explicit
representations of constraints and rules governing agent or system
behaviors. Policies can define permissions, obligations, norms and
preferences for an agent's actions and interactions with other agents and
programs. Explicit policies, especially those expressed in high level
declarative languages, can be adjusted or disseminated by communications,
used as the basis for electronic contracts and addressed in negotiations
for service agreements and commitments.
- Semantically described privacy policies. Individuals accessing
a service online, are concerned about the subsequent use of data they
disclose to the service, in addition to considering whether the service
can provide the product and quality they demand. Service users must
trust that the policy will be enforced. Privacy issues do not concern
individual consumers only. These concerns also permeate organizational
interactions, such as medical supply chains, where an increasing amount
of regulatory legislation governs the conditions of patient data and
other relevant disclosures. Programming this complicated web of policies
into software systems is an increasingly expensive and time-consuming
task that could benefit from increased automation.
- Honoring individual client requirements. Service users may
publish or provide to services their own security or privacy requirements
and preferences. They may require or negotiate with service providers to
adapt to them. Services will need to state whether they can dynamically
accept and manage such individual policy requirements.
- Protocols for publication of service security policies and
authentication requirements. Service providers will have to
semantically describe and publish their security, privacy and trust
practices and policies in conjunction with their service models. These
descriptions will be available as additional criteria that can be used by
service seekers (or their proxies) to choose among or rank the services
- Semantic policy evaluation mechanisms. Inference or proof
checking mechanisms may be used to determine policy applicability. For
broadly described policies, inferences may be used to evaluate group
membership questions and deconflict among overlapping policy
requirements. Proof checking may be used when access authority or
permission proofs are provided by potential clients. These policy
evaluation mechanisms will require protocols to enlist architectural
assistance to enforce the policies and to collect data needed to
recognize existing or potential security and privacy violations. They
will need the means to adapt to dynamically communicated policy
revisions, and stated exceptions to policies. [Su03].
- Semantically controlled policy enforcement. Flexible
enforcement mechanisms for semantically described policies must interpret
more flexible descriptions of enforcement criteria and efficiently
determine case-by-case policy applicability using their local means of
enforcing those policies at the underlying services architecture
level. Enforcement mechanisms will also need means to adapt to
dynamically changed policies [Su03].
- Trust-based authentication and authorization. Security and
privacy policies can be based on verifiable relationships among agents.
To base policy enforcement decisions on this kind of information requires
additional reasoning about these trust relationships, in part based on
evidence that an authentication authority can provide. For example, proof
of key attributes, signed statements from a trusted source delegating a
permission, or an agreement to undertake an obligation in return for
access could be considered. As in human societies, authorization can be
shared based on these verifiable relationships, rather than explicit
delegation or group membership.
- Communication and logging of security evaluation results is
needed in order to support remediation services and enable the
functioning of reputation services.
- [Ag04] Rohit Aggarwal, Kunal Verma, John A. Miller and William Milnor,
"Constraint Driven Web Service Composition in METEOR-S," Proceedings of the
2004 IEEE International Conference on Services Computing (SCC 2004),
Shanghai, China, September 2004 , pp. 23-30
- [TBL00] Tim Berners-Lee "Semantic Web Architecture"
Slide from presentation , 2000.
- [Bu04] Mark Burstein
Ontology Mapping for Dynamic Service Invocation On the Semantic Web
Proceedings of the AAAI Spring Symposium on Semantic Web Services
Palo Alto, March, 2004.
- [Ca04] Jorge Cardoso, Amit Sheth, John Miller, Jonathan Arnold,
and Krys Kochut,
Quality of Service for Workflows and Web Service Processes, Journal
of Web Semantics, 2004.
Distributed Management Task Force Common Information Model
- [DAML-S] DAML Services Coalition (alphabetically A. Ankolekar,
M. Burstein, J. Hobbs, O. Lassila, D. Martin, S. McIlraith, S.
Narayanan, M. Paolucci, T. Payne, K. Sycara, H. Zeng), DAML-S: Semantic Markup for
Web Services. Proceedings of the International Semantic Web
Working Symposium (SWWS), July, 2001.
- [GCRM] Global
Grid Forum Common Resource Model (draft document)
- [OWL] Mike Dean, Guus Schreiber, Sean Bechhofer, Frank van
Harmelen, Jim Hendler, Ian Horrocks, Deborah L. McGuinness, Peter
Patel-Schneider, and Lynn Andrea Stein, OWL Web Ontology Language
Reference, W3C Recommendation, 10 February 2004.
- [Dec97]Keith Decker, Katia Sycara and Mike Williamson, Middle-agents
for the Internet, Proceedings of IJCAI-97, 1997.
- [Den03] Grit Denker, Lalana Kagal, Tim Finin, Massimo Paoucci,
Security for DAML Web Services: Annotation and Matchmaking, Proceedings
of the Second International Semantic Web Conference (ISWC2003),
Sanibel Island FL, October 2003.
- [Eb04] Andreas Eberhart,
Ad-hoc Invocation of Semantic Web Services, Proceedings of the
IEEE International Conference on Web Services. San Diego,
California, USA, July 2004.
- [FIPA-ACL] Foundation for Physical Agents,
FIPA Communicative Act Specification,
Document SC00037J, 2002.
- [Fo02] Ian Foster, Carl Kesselman, Jeffrey M. Nick, and Steven
physiology of the grid: An open grid services architecture for
distributed systems integration. Technical report, Open Grid
Service Infrastructure WG, Global Grid Forum, June 2002.
- [ISG] Information
- [Ka04] Lalana Kagal, Massimo Paolucci, Naveen Srinivasan, Grit
Denker, Tim Finin and Katia Sycara, Authorization
and Privacy for Semantic Web Services, Proceedings of the AAAI
2004 Spring Symposium on Semantic Web Services, Stanford, March
- [Mc02] Drew McDermott, Mark Burstein, and Douglas Smith,
Overcoming ontology mismatches in transactions with self-describing
agents. In The Emerging Semantic Web: Selected Papers from the
First Semantic Web Working Symposium, pp.228- 244. 2002.
- [Na02] S. Narayanan, S. McIlraith, Simulation,
Verification and Automated Composition of Web Services, Proceedings
of the Eleventh International World Wide Web Conference (WWW-11),
Honolulu, Hawaii, May, 2002.
- [Ga04]Fabien Gandon and Norman Sadeh, Semantic Web Technologies
to Reconcile Privacy and Context Awareness. Web Semantics, Vol.
1, No. 3, April 2004
- [Si04] Kaarthik Sivashanmugam, Kunal Verma, Amit Sheth, Discovery
of Web Services in a Federated Registry Environment, Proceedings of
IEEE International Conference on Web Services 2004.
- [Si05] Kaarthik Sivashanmugam, John A. Miller, Amit Sheth, Kunal Verma,
Framework for semantic web service composition, International Journal of Electronic Commerce Vol. 9 No. 2, pp. 71-106, Winter 2004-2005.
Preist, Chris, A
Conceptual Architecture for Semantic Web Services" International
Semantic Web Conference, Hiroshima, Japan, 2004.
- [Su03] N. Suri, J. M. Bradshaw, M. H. Burstein, A. Uszok, B.
Benyo, M. R. Breedy, M. Carvalho, D. Diller, P. T. Groth, R. Jeffers,
M. Johnson, S. Kulkarni & J. Lott.
policy enforcement for semantic data transformation and filtering in
multi-agent systems. Proceedings of the Autonomous Agents and
Multi-Agent Systems Conference (AAMAS 2003). Melbourne, Australia,
New York, NY: ACM Press, 2003.
- [Sy99] K. Sycara, J. Lu, M. Klusch, and S. Widoff,
Dynamic Service Matchmaking among Agents in Open Information
Environments, Journal ACM SIGMOD Record, Special Issue on
Semantic Interoperability in Global Information Systems, A. Ouksel,
A. Sheth (Eds.), 1999.
- [Ta03] H. Tangmunarunkit, S. Decker, C. Kesselman, Ontology-based
Resource Matching in the Grid---The Grid meets the Semantic Web, In
Proceedings of the Second International Semantic Web Conference.
Sanibel-Captiva Islands, Florida, USA. October 2003.
- [To03] Gianluca Tonti, Jeffrey M. Bradshaw, Renia Jeffers,
Rebecca Montanari, Niranjan Suri and Andrzej Uszok,
Semantic Web Languages for Policy Representation and Reasoning: A
Comparison of KAoS, Rei, and Ponder Proceedings of Second
International Semantic Web Conference (ISWC2003), Sanibel Island,
Florida, USA, October 2003.
- [OWL-S] OWL
Services (OWL-S) Ontology
- [Us02] Michael Uschold, Michael Gruninger,
Creating Semantically Integrated Communitities on the World Wide Web.
Invited talk at the Semantic Web Workshop, Honolulu, May 2002.
- [Ve04] Kunal Verma, Kaarthik Sivashanmugam, Amit Sheth, Abhijit
Patil, Swapna Oundhakar and John Miller,
METEOR-S WSDI: A Scalable Infrastructure of Registries for Semantic
Publication and Discovery of Web Services, Journal of
Information Technology and Management, Forthcoming, 2004.
- [WS-ARCH] Web Services
Architecture (Working Group Note) February, 2004.
- [WS-CHOR] Web
Services Choreography Model Overview. March 2004
- [WSLA] Web Service
Level Agreements (WSLA) Project
- [WSML] Web Service Modeling
Language (WSML) Working Group
- [WSMO] Web Service Modeling
Ontology (WSMO) Working Group
- [WSPF] Web
Services Policy Framework (WSPolicy)
The Web Service Resource Framework
- [WSS] Web
Services Security Specification (WS-Security)
- [Ze03] Liangzhao Zeng, Boualem Benatallah, Marlon Dumas, Jayant
Kalagnanam, Quan Z. Sheng. Quality driven web services composition. Proceedings
of the 2003 WWW Conference. pp.411-421. 2003.