Semantic Web Services Architecture Requirements
Version 1.0 (1 June 2004)
- This version:
- http://www.daml.org/services/swsa/swsa-requirements.html
- Latest version:
- http://www.daml.org/services/swsa/swsa-requirements.html
- Editor:
- Mark Burstein (BBN Technologies)
- Contributors:
- Christoph Bussler (DERI, Galway, Ireland)
- 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 (DERI, Galway, Ireland)
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.
This document utilizes a review of a number of different environments to
identify the scope and potential requirements for this
architecture.
Status of this document
Version 1.0 is now available for public comment.
1. Introduction
The Semantic Web Services Initiative
(SWSI) is an ad hoc initiative of academic and industrial
researchers,
many of whom are involved in DARPA and EU funded research projects.
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. In part, the architectural
framework we develop will build on and extend the Web Services
Architecture [WS-ARCH]
developed by the Web
Services Architecture Working Group of W3C.
This document describes the scope of and requirements for this
architecture. It is desired that this architecture provide
a foundation that will support semantically enabled service deployment
in a
variety of current and future distributed environments. We anticipate
that
the architecture will also indicate requirements for semantic web
service
description languages which are being designed by our sister committee,
the
SWSI Language Committee.
Our approach to developing an architectural framework for Semantic
Web
Services is to first identify specific roles for machine interpreted
semantic descriptions in the deployment of semantic web services to
different distributed environments, and then to describe the necessary
supports for interpreting and reasoning with these descriptions to
achieve
those functions. As these support functions may be distributed,
inter-agent
protocols and ontologies for communications about those functions will
be
identified.
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 environments.
The SWSA interoperability architecture will cover the following
classes of
support functions to be accomplished by semantic web agents (service
providers, requesters, 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
particular objectives.
- Service Process Enactment and Management: The capability to
dynamically select and, if necessary, compose services to achieve some
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, a
capability to interpret and enact associated cancelation, failure
recovery and compensation mechanisms.
- 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. Also included here are the capabilities to monitor and enforce
contract performance, resolve disputes, and supervise compensation for
failures arising from the performance of semantically described
contracts.
- 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 qualities that can influence client acceptance will also be
important. The first is quality of service performance, the speed,
timeliness, result completeness and effectiveness attributes that can
make particular services more or less effective or appropriate for use in
certain contexts. The second area is the set of policy issues
surrounding security, privacy and trust. We describe how these two
aspects of services interact with and cut across our other major
architectural support topics.
2. Multiple Distributed Environments Motivate Requirements
Semantic Web Services are viewed as a way to extend the capabilities of web
services in the direction of dynamic interoperability. The underlying theme
is the overcoming of interoperability limitations arising from the need for
service and client developers and to agree in advance on the syntax and
semantics of interactions, thereby making it possible for clients to
successfully utilize web services without prior arrangements between people
that are realized in rigid software protocols, and immutable ontologies or
meta-data.
There are a number of communities for which these goals are
important:
- 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.
- Grid computing applies
distributed computational resources to large scientific problems. Users
will be able to compose and substitute services 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 had revised interaction
protocols.
- Ubiquitous computing using
wireless portable devices carried by people to different environments to
access services. Here, there is a strong requirement for dynamic
discovery of locally accessible services, 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 the incompatibilities of data and information
models and the mismatches in exchange protocols utilized by different
communities of service providers. One reason for these differences is
that they were
developed by different groups. The other is that models,
syntactic encodings and protocols can change over time as services
evolve. Dynamically accessible semantic descriptions of service
capabilities and utilization protocols can contribute to overcoming
these
barriers, but only in a distributed environment which fundamentally
supports individual
software agents' ability and need to interpret (perhaps after
translation)
unfamiliar ontologies and declaratively described process constraints.
Lastly, given
the open ended nature of such distributed environments, effective means
for
controling (semantically interpretable and transmitable) security
authorizations and ensuring the privacy of information must also be
addressed.
3. Functional
Areas
In the following sections, we address requirements within our
major
functional areas, which contain functions which we believe to be of
varying
importance in different distributed operating environments, as
suggested by
the following table:
Functional Area |
Business to Business |
Business to Consumer |
Ubiquitous Computing |
Grid Services |
Web/Info
Services |
Dynamic Service Discovery |
B2B |
B2C |
Ubiq |
Grid |
Info |
Advertising of Service Descriptions |
|
|
|
|
|
Candidate Service Query Formulation |
|
|
|
|
|
Candidate Service Matchmaking |
|
|
|
|
|
Service Process Enactment and Management |
B2B |
B2C |
Ubiq |
Grid |
Info |
Candidate Service Selection |
|
|
|
|
|
Service request formation and response interpretation |
|
|
|
|
|
Request and Response Translation |
|
|
|
|
|
Choreography interpretation and execution |
|
|
|
|
|
Process mediation and delegation |
|
|
|
|
|
Dynamic Service Composition |
|
|
|
|
|
Process status monitoring and event notification |
|
|
|
|
|
Service failure handling and compensation |
|
|
|
|
|
Negotiation and Contracting |
B2B |
B2C |
Ubiq |
Grid |
Info |
Service contract negotiation |
|
|
|
|
|
Dispute Resolution and Compliance |
|
|
|
|
|
Non-Repudiation/Audit Tracking/Explanation |
|
|
|
|
|
Semantic Web Community Support Services |
B2B |
B2C |
Ubiq |
Grid |
Info |
Ontology Management and Mapping Services |
|
|
|
|
|
Service catalog and Information brokering Services |
|
|
|
|
|
Membership and Authority Services |
|
|
|
|
|
Security (identification/authentication, authorization, delegation) |
|
|
|
|
|
Privacy Services |
|
|
|
|
|
Reputation Services |
|
|
|
|
|
Policy and Protocol Management Services |
|
|
|
|
|
Service Lifecycle Support |
B2B |
B2C |
Ubiq |
Grid |
Info |
Executable process management services |
|
|
|
|
|
Resource Allocation and Provisioning services |
|
|
|
|
|
4. General Requirements
The architecture we describe will stand 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, or 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 ontologies and descriptions in terms of these
dynamically linked and shared ontologies. However, we must recognize that
different communities may not always share ontologies directly, but
instead will, in many cases, have different and only partially comparable
ontologies covering 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. As a result of these considerations and
assumptions, our architecture will have the following general requirements:
- 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], but if it is not, then there should be a published description or
set of mapping rules that specifies how to interpret the message
semantically.
- Requester agents (clients) must be able to formulate at least some
internal objectives as requests to (potentially, newly discovered) server
agents based on their semantically described service interfaces.
We divide the sections below into functional capability and
architectural requirements. The former will be used primarily to
refer to capabilities of the primary participants (requester, service
provider) in a web service interaction, while the latter will refer to the
capabilities provided by semantic web service support middle agents which utilize
widely shared protocols and ontologies.
In addition to describing functional capabilities, services may
describe, and clients may request, specific levels of quality of
service. In service descriptions, these are generally referred to as
non-functional service attributes. Issues here may include timing and
duration of service, accuracy of result, likelihood of failure, geographic
region of service, privacy of information, security of communications, etc.
These issues impact both descriptions used during discovery and service
selection, and also processing during enactment. We touch further on these issues in
Section 10, Crosscutting Requirements.
5. Service Discovery
Service discovery is the process by which a client, interacting with peers
or special purpose middle agents (matchmakers), identifies candidate
services to achieve the client's objectives. For web services, this is
currently a heavily manual process, in that registries like UDDI [UDDI] are
designed to be searched by developers of client systems. In contrast,
semantic matchmakers use semantic relations to find services described
using semantic web languages [Dec97][Sy99][DAML-S][OWL-S][Pa03][Ve04]. 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.
Functional Requirements
- The ability to describe the characteristics of and constraints on
services that could be used to fulfill an agent's requirements.
- The ability to locate and query peers or matchmakers can answer queries for services
meeting client requirements and constraints.
Architectural Requirements
Protocols to support peer to peer and
middle-agent enabled service discovery will include the following.
- 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.
- Candidate Service Query 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.
- Candidate Service Matchmaking and Brokering: Services (peers) or
middle agents that can respond to service discovery query protocols must be
able to compare service requirement descriptions to a variety of service
advertisements. Responses to these queries may be (possibly multiple)
descriptions or references to identified candidate services, possibly with
a characterization of degree of match or mismatch. Registries may be
federated and organized for matchmaking along community or semantic
functional categories [Si04]. Alternatively, in the case of brokers,
responses may be based on the result of selected and executed service(s).
6. 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 failure. [DA01][Mc02][Eb04]
Functional Requirements
- Specifying objectives: The client
(service consumer) needs to be able to specify the goals or objectives it is to
achieve. 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 traveller
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 service requests.
- 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. [WS-CHOR]
- 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 choreography differences.
- 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.
Architectural Requirements
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 characteristics.
- 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 quering
a logging service may be widely standardized.
7. Negotiation and Contracting
Negotiation and contracting involve 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 that arise.
Functionality Requirements
- 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
experience.
- 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 authorised 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).
Architectural Requirements
- 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.
8. Community Support Services
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:
Functional Requirements
- 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.
Architectural Requirements
- 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 recommendations.
- 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.
9. Service 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 applications.
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 commands.)
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).
Functional Requirements
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 setting.
- 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.
Architectural Requirements
- 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 services.
10. Cross-cutting Requirements
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 occurence.
- Cost: Cost of the service to the requester, and measures of resources consumed.
- Reliability: Measures of likelihoods of success/failure and fail-safe outcomes
- Operational Metrics: Other domain specific quality measures.
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.
- 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 capabilities.
[To03][Ka04][Su04]
- 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.
Functional Requirements
- 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 understand
the privacy policy of the services they are accessing, and 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.
Architectural 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
available. [Den03]
- 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.
References
- [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.
- [CIM]
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, Katia Sycara,
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.
- [Fo02] Ian Foster, Carl Kesselman, Jeffrey M. Nick, and Steven Tuecke.
The 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 Security Glossary
- [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 2004.
- [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.
- [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. DAML-based 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
- [WSPF] Web
Services Policy Framework (WSPolicy)
- [WSRF] 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.