Semantic Web Services Architecture Requirements

Version 1.0 (1 June 2004)

This version:
Latest version:
Mark Burstein (BBN Technologies)

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.

Table of contents

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:

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:

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:

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

Architectural Requirements

Protocols to support peer to peer and middle-agent enabled service discovery will include the following.

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

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.

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

Architectural Requirements

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

Architectural Requirements

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:

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.

Architectural Requirements

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:

Issues that must be addressed include: