A Semantic Web Services Architecture

Version 1.0 (1 October 2004)

This version:

http://www.daml.org/services/swsa/swsa-note.html

Latest version:

http://www.daml.org/services/swsa/swsa-note.html

Editors:

Mark Burstein (BBN Technologies)

Christoph Bussler (Digital Enterprise Research Institute (DERI), Galway, Ireland)

Contributors:

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), Galway, Ireland)

Abstract

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 is based on a review of requirements gathered from a number of different environments to identify the scope and potential requirements for this Semantic Web Services architecture.

Status of this document

Table of contents

• 1. Introduction
• 2. Supporting Multiple Distributed Environments
• 3. Underlying Assumptions and Development Stages
• 4. Stages of Semantic Web Service Interaction
• 5. Service Discovery
• 6. Service Engagement - Negotiation and Contracting
• 7. Service Process Enactment and Management
• 8. Community Support Services
• 9. Service Lifecycle Support Services
• 10. Cross-cutting Issues
• References
• Acknowledgments

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, 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 Semantic Web Architecture as proposed by Tim Berniers-Lee [TBL00]. Further significant input is taken from the OWL-S Coalition [OWL-S] as well as the WSMO Working Group [WSMO].

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 SWSI Language Committee.

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 released 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 functions.

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 covers 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 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, a capability to interpret and enact associated cancelation, failure recovery and compensation mechanisms. Service process enactment also includes the capability to follow extended protocols and interaction plans that may 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 represent 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 topics.

The architecture described below is based on abstract protocols and functional descriptions of capabilities, not in terms of specific software modules or components. The rationale for this 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 compliant to the proposed protocols, the components will interoperate as defined by the protocols. This allows freedom in building software components while ensuring architectural interoperability. This approach follows the approach of the World Wide Web where protocols like HTTP and SOAP are defined without constraining the software components that implement those protocols.

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 addressing the need for interoperability in the face of heterogeneous standards for representating content communicated between distributed components. 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. A key problem with current-generation enterprise integration software is the need for regular updating of software to new versions of 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 had revised their interaction protocols since last utilized.
• 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 incompatibilities information models and mismatches in exchange protocols utilized by different communities of service providers. One big reason for these differences are 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 overcoming 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.

3. Underlying Assumptions and Stages of Development

Architectural 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 in terms of dynamically linked and shared published 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 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 require full translations.

As a result of these considerations and assumptions, our architecture will assume the following general capabilities of agents (both clients and services):

• 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 or translation mapping that the message to be interpreted semantically.
• Requester agents (clients or web services themselves) must be able to formulate the internal objectives to be delegated to external agents as requests to servers in terms of their published, semantically described service interfaces.
• Services must publish semantic descriptions of their capabilities and interaction protocols that can be interpreted by and used by prospective service consumers (clients or other web services) to select appropriate services for their needs, and to 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 Web.

A Staged Roadmap to Semantic Web Service Development and Adoption

Based on our requirements collection, we expect that some aspects of our proposed architecture will be seen as more central to classes of applications than others. In particular, we anticipate that many of the high payoff near-term applications developed will de-emphasize fully automated discovery and focus more on addressing interoperability between clients and services selected by users, or services that are among small collections of candidates. As a result, we believe that semantic mediation and translation will be key near-term issues. Overall, we see the following stages of development and exploitation of semantic web service technologies.

• Stage 1: Simple service invocation and response handling
  
  • User directed manual discovery,
  • User directed composition,
  • Ensuring semantic interoperability during invocation and responses exception handling
  • Predefined and lossless mapping (through simple translation engines)
• 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 service requirements

4. Stages of Semantic Web Service Interaction

The process of interacting with a semantic web service (Figure 1) will in general include the stages of:

• Candidate Service Discovery - the distributed search for available services that can accomplish the client's internal goal or objective. Protocols supporting this stage will be utilized by clients interacting with agents that are typically not the service that will ultimately be utilized.
• Service Engagement - the process of interpreting candidate service enactment constraints, and potentially negotiating directly with services to reach agreement with a service on a specific service contract, such as the determination of the particular price to be paid for a service or product that the service provider confirms is available (and the service agrees to deliver).
• Service Enactment - the interactive process between client and services that accomplishes their mutual objectives as specified by a Service Contract (SC). If the primary objective is not accomplished, then a compensation procedure may be initiated. During execution, the client may monitor the status of the service process.

Figure 1: Service Interaction Process Overview

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] [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.

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 for a client to describe its goals and for a web service to describe its capabilities in order to facilitate matchmaking.
• The ability to locate and query peers or matchmakers can answer queries for services meeting client requirements and constraints.
• 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 mapping rules.

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. If clients have an explicit representations of gaols these should be included in the discovery and matchmaking task.
• 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.
• Matchmaking and Brokering Services: 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]. lternatively, in the case of brokers, responses may be based on the result of selected and executed service(s).
• Representational Tranformation Processes during Matchmaking: During matchmaking, ontology translation may be necessary if web services described their interfaces, capabilities, etc. in different ontologies. The client or service requester that searches for matching web services might also use a different ontology to describe its needs.

Abstract Protocols

Advertisement Protocol

Figure 2: Service Advertisement Protocol

Discovery Query Protocol

Figure 3: Service Advertisement Protocol

---

6. Service 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 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.

Abstract Protocols

Simple Query Protocol

Figure 4: Engagement: Query-Reply Protocol

Simple Request Protocol

Figure 5: Engagement: Request Protocol

Negotiate-Commitment Protocol

Figure 6: Engagement: Negotiate-Commitment Protocol

---

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 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.

Abstract Enactment Protocols

Synchronousl

Figure 7: Enactment: Synchronous Protocol

Asynchronous - One Way Protocol

Figure 8: Enactment: Asynchronous - One Way Protocol

Simple Query Protocol

Figure 9: Enactment: Asynchronous - Two Way Protocol

---

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

• [TBL00] Tim Berniers-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.
• [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.
• [SWS-CA] 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. 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
• [WSML] Web Service Modeling Language (WSML) Working Group
• [WSMO] Web Service Modeling Ontology (WSMO) Working Group
• [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.