A Semantic Web Services Architecture

Version 1.0 (April, 2005)

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
• 4. Phases 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 Berners-Lee [TBL00]. Further significant input is taken from the OWL-S Coalition [OWL-S], the WSMO Working Group [WSMO], the open grid services architecture [Fo02] and the METEOR-S project [METEOR-S].

This document describes abstract protocols for interactions between clients and Semantic Web Services and proposes other support services that may be needed in some contexts to fulfill the basic requirements of the proposed architecture. Our goal is that this architecture provides a foundation that will support a variety of semantically enabled service deployments in a variety of current and future distributed environments, especially those building on the World Wide Web. We anticipate that the architecture will also indicate requirements for Semantic Web service description languages which are being designed by our sister committee, the 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, requestors, and middle agents). While not all operational environments will find it necessary to support all functions to the same degree, we anticipate that the distributed functions to be addressed by this architecture will include:

• Dynamic Service Discovery: The capability of a software agent, through interaction with other agents, to identify candidate services for 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, it also includes a capability to interpret and enact associated cancellation, failure recovery and compensation mechanisms. Service process enactment may require following extended protocols and interaction plans that involve multiple services. Plans may be self-generated or published in a semantic process language and interpreted.
• Semantic Web Community Support Services: Capabilities associated with sharing semantic descriptions, ontologies and ontology mappings, and service catalogs within and across communities. Support for managing community membership, privacy and authority relationships, and shared informational resources.
• Semantic Web Service Lifecycle and Resource Management Services: The capability to spawn, allocate, manage and report on the life status of services, computational host platforms and storage facilities for Semantic Web Services.
• Cross-cutting Issues: Semantic representations of two kinds of service quality meta-properties may be important during discovery of appropriate services, may appear in service agreements, and may be monitored during execution. The first set of properties relate to quality of service performance, the speed, timeliness, result completeness and effectiveness attributes that can make particular services more or less appropriate for use by certain clients or in certain contexts. The second class of properties represents policies of services regarding security, privacy and trust. We will touch on how these two aspects of services interact with and cut across our other major architectural support topics.

The architecture described below is based on abstract protocols and functional descriptions of capabilities, rather than specific software modules or components. Our objective is to define a model of interoperability that can underpin a variety of architectures without prescribing specific system design decisions. Eventually, concrete software components have to be built. If these are designed to be consistent with the proposed abstract protocols, the components will interoperate as defined by the protocols. This allows prospective developers maximal freedom in building software components while ensuring architectural interoperability. This approach is intended to be consistent with the approach of the World Wide Web Consortium, where protocols like HTTP and SOAP are defined without constraining the software components that implement those 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 address the need for interoperability in the face of heterogeneous standards for representing content communicated between distributed components. There are many situations where systems developed using web services will need to overcome interoperability limitations arising from their inability to agree in advance on the syntax and semantics of interactions. Semantically transparent web services make it possible for clients to successfully utilize them without prior arrangements negotiated by people and realized in rigid software protocols and uninterpretable meta-data models.

There are a number of communities for which these goals are 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 their need for regular software updates to accomodate rapidly changing standards for representing goods, services and protocols for transactions. Semantic web services will provide mechanisms to make these representations self-describing and eliminate much of the cost of software reengineering to make such updates.
• Grid computing applies distributed computational resources to large scientific problems. Users seek to dynamically describe compositions of remote resources to solve large problems. To manage computational resources effectively, they need to be able to substitute comparable, but not necessarily identical services seamlessly based directly on semantic descriptions of their functional capabilities, quality of service and timeliness of availability, without regard for whether those services were known in advance to the client, or have revised their interaction protocols since 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 incompatibile information models and mismatches in exchange protocols utilized by different communities of service providers. One big reason for these differences is that they were developed by different groups. Another is that models, syntactic encodings and protocols change over time as services evolve to meet changing needs. Dynamically accessible semantic descriptions of service capabilities and utilization protocols can help to overcome these barriers, but only in a distributed environment which fundamentally supports individual software agents' ability to interpret (perhaps after translation) unfamiliar ontologies and declaratively described process constraints. Lastly, given the open ended nature of such distributed environments, the architecture must support effective means for managing semantically interpretable security authorizations and ensuring the privacy of transmitted information.

Expected Stages of Semantic Web Service Development and Adoption

Based on our requirements collection for these different target environments, we expect that some aspects of our proposed architecture will be seen as more central to some classes of applications than others, and that some other aspects will take longer to be adopted. In particular, we anticipate that many of the high payoff near-term applications developed will de-emphasize fully automated discovery and focus on the use of semantic mediation for interoperability between clients and services selected by users or services that are automatically chosen from small collections of pre-identified candidates. For example, such collections could be formed by companies that have contracts that gain them entry to a particular community of service providers. These kinds of application scenarios can avoid the use of automated negotiation between clients and services that would come in later stages of semantic web service development. Nonetheless, they might still require support for semantic interoperability to address issues such as regular changes to their interaction protocols, message formats and semantics. Overall, we see something like the following stages of development and exploitation of semantic web service technologies occurring over the next few years.

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

In the near term, we expect that situations requiring dynamic service discovery and utilization will be predominantly ones where humans will continue to be involved in the selection process, either because the selection criteria are not sufficiently formalized or because the number of available services is not large enough to require complex semantic matching. In such situations, the key technological advance will be in utilizing semantics for service enactment, the process of mediating service requests and responses so that a client does not need to have hard coded knowledge of the syntax of invocation messages.

As the technology matures, or perhaps in tandem with this first stage, we anticipate the development of mechanisms for supporting automated service discovery and matchmaking. A key element of this phase of development will be the development of shared, extensible community-wide ontologies for describing capabilities, services and goods, and moving these ontologies into the public domain as semantic web accessible terms.

The third stage of semantic web service development will address more complex and extended service interactions, as necessary for on-line negotiation of service contracts, and for multi-party interactions such as the utilization of proxies or brokers that present interfaces to composite services. Brokers may fully or partially mediate other services while hiding some of their complexity. For example, they might allow a user to plan a whole trip, while semantically mediating the identification of and interaction with a number of back-end services, but require the client work directly with the back-end service agents when things go wrong it becomes necessary to request compensation for service contract failures.

3. Underlying Assumptions

The architectural framework we describe stands on the shoulders of two emerging technological concepts: Web Services and the Semantic Web. From web services we bring the notion that service interfaces can be published on the web using XML, and more specifically, WSDL, and can be invoked using web protocols like HTTP and SOAP. From the Semantic Web we bring the notion of web published and accessible semantic descriptions using dynamically linked and shared ontologies. In addition, work in semantic web services contributes the notions of orchestration, choreography and mediation. We recognize that different communities may not always share ontologies directly, but instead will, in many cases, have different and only partially comparable ontologies and protocols, covering some of the same or related concepts. Complete semantic interoperability may not always be possible, although substantial improvement can be achieved when ontology mappings enable semantic translation between different representations of concepts based on different ontologies, and the tasks being addressed do not necessarily require full 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 of the message format in such a language, or a translation mapping that allows the message to be interpreted semantically.
• Service providers must publish semantic descriptions of their service capabilities and interaction protocols that can be interpreted by and used by prospective service consumers to (1) select appropriate services for their needs, and to (2) successfully interact with those services. These descriptions must utilize widely shared Semantic Web description languages and ontologies that are accessible and shared via the Semantic Web.
• Requestor agents (clients or other web services) must be able to reformulate those internal objectives that they seek to have delegated to external agents as well formed requests to service providers, by using the published, semantically described service interfaces of those providers.

4. Phases of Semantic Web Service Interaction

The process of discovering and interacting with a semantic web service (Figure 1) will, in general, include the following phases:

• Candidate Service Discovery - the distributed search for available services that can accomplish the client's internal goal or objective. A number of alternative protocols for this phase of interaction may be developed, but they will all be utilized by prospective clients as they interact with agents other than the service providers from which they will ultimately request services. Instead, these clients will typically be interacting with a matchmaker or peer who makes recommendations about potentially useful services.
• Service Engagement - this second phase includes the process of interpreting candidate service enactment constraints, partly or fully described by each candidate web service in it's published self-description, and then requesting or possibly negotiating with each prospective service to reach agreement on the terms of the service to be provided.

  Engagement concludes with both service and client knowing and agreeing to the terms of service provision in an explicit or implicit Service Contract (SC). If explicit negotiation occurs, it may address such things as the determination of the particular price to be paid for a service, agreement about the attributes of the product that the service provider will provide, or the quality of the service provided. Enactment protocols may also address issues of authentication and authorization for either or both the service requestor and provider to engage in the service enactment protocols that follow.

• Service Enactment - the interactive process coordinated by messages between clients and services that accomplishes their mutual objectives as specified by a Service Contract developed during engagement. If the primary objectives of the contract are not accomplished, then a compensation protocol may be utilized. During execution, if the transport model allows for asynchronous interactions, the client may use protocols that allow for the monitoring of the status of the service process.

Figure 1 gives an overview of the relationships between these phases of interaction as a kind of workflow model. A client starts with an internal goal that it intends to accomplish by utilizing an external service. Correspondingly, service providers have the general goal of providing the services they were designed to provide, often in exchange for some form of compensation. These agent goals are reiterated in various forms in semantic descriptions of used in exchanges during interaction processes. Client goals are represented in the semantic descriptions created to query semantic service registries as requirements on potential service providers. They are also represented, typically in a different form, in the requests to potential providers of services.

In the overall service utilization process, service requests (messages from clients to propective services) are part of the second or Engagement stage. These requests to services may simply be honored by a provider (in which case we move directly to the Enactment stage), or serve as the prelude to a multi-step negotiation protocol culminating in a "handshake" indicating mutual acknowledgement of a joint contract. The third stage, that of service enactment, consists of alternative protocols to initiate service activity, monitor service processes, and confirm service completion. If the service terminates abnormally after a contract has been formed, there may be a final set of protocol interactions to address compensation issues.

Figure 1: Service Interaction Process Overview

In the following sections, we describe the requirements and architectural supports for each of these stages of service interaction. The architecture for each stage will be described primarily in terms of abstract protocols for accomplishing the stage's requirements. The protocols will consist of exchanges of messages of various semantic types, and identifying the state changes in the role players resulting from these messages. Our message types are assumed to be represented in an ontology of communcations acts.

We will utilize the set of communications performatives developed by the FIPA community [FIPA-ACL] as an initial set of abstractions on which to build our ontology of the message types referenced in these abstract protocols. The FIPA performatives we will refer to are the following:

• Inform - The sender informs the receiver that a given proposition is true. This is used, for example, in advertising a service. The content of such messages is a proposition. In more specialized Inform message types, the content could be a part of the full proposition, with the message type conveying some contextual part of the description. For example, an Advertise message would be a special kind of Inform that communicated to the receiver (generally, a matchmaker) that the content of the Advertise was a description of an available service. Its use would be limited to contexts where the recipient had (by publishing a service model) agreed to communicate that information to other agents when queried appropriately. Inform messages are also used for such things as to reply to queries, and to convey service process status.
• QueryRef - The sender asks the receiver for the object(s) referred to by a referential expression. This is used to query a matchmaker during discovery. The content of a QueryRef is a descriptor or referential expression that can be used as a query pattern.
• Request - The sender requests the receiver to perform some action. Variants include RequestWhen, which also specifies a proposition which, when true, will trigger doing the action. Simple service requests use this performative.
• Agree - The act of agreeing to perform some action (at some time).
• Refuse - The act of refusing to perform a given action requested by another agent (typically the message recipient), and explaining the reason for the refusal.
• Cancel - The act of one agent informing another that the first agent no longer has the intention that the second agent perform some action.
• Propose - The act of submitting a proposal to perform an action, given certain preconditions.
• AcceptProposal - The act of accepting a previously submitted proposal to perform an action.
• RejectProposal - The act of rejecting a proposal to perform some action (during a negotiation).

Semantic Protocol Overlays

There are multiple aspects to the semantics of a service request that can each cause a service to respond with a message addressing issues or problems with the request. This will particularly be true as messages themselves are formulated using semantic description languages. Missing information, unmet constraints, and invalid authorizations are just a few of these issues. For example, a request may not specify all of the optional values for service constraints that the service provider needs to determine how or when it performs the service, such as the shipping method to be used. Similarly, a request may not include sufficient information about the sender's authority to make the request.

Often such issues are addressed in the engagement stage of service interaction. Strictly speaking, service provider replies that ask for clarifications of various kinds could all be considered types of error responses, but we will treat them as semantically characterizable sub-dialogs, as they lead to semantically similar message exchanges that can occur in a number of different parts of our protocols. We will represent these generically as a kind of 'overlay' or subdialog so that we do not have to repeat them many times in the protocols representing our three main stages of service interaction.

Specific service implementations may only allow these dialogs to occur at particular points in their more detailed service interaction specifications, and their service description models will have to describe these restrictions. Our primary objective here is to identify what is common about these protocols and characterize their semantic message types.

In the following sections, where we describe a set of abstract protocols for the three main stages of service interaction, we have simplified the diagrams of these protocols by not including the many different ways that these sub-dialogs might be interleaved. Instead, we introduce them once here, and then mention where they will occur.

Clarification Sub-dialog

In some of the abstract protocols shown below, a service may refuse to process a Query, Request or Inform because the request is semantically ill-formed for some reason, or certain pieces of information required to make the request executable were not provided. For example, there might be a two-day advance notice reqired on a request for a funds transfer from a bank. Specifying today's date on the request would be considered a semantic error that results in a refusal with a reason. This reason could be used by the client to reformulate the request. This kind of clarification sub-dialog has the form shown in Figure 2. When the service can provide a semantic description stating a reason for the failure, then the agent making the request may reformulate the request and try agein. When a refusal is not accompanied by a reason for the refusal, then no continuation is possible. In subsequent figures, we will indicate it by a simple CLARIFY branch where this dialog might occur.

Figure 2: Abstract Clarification Dialog Protocol Fragment

The trigger to this general pattern of response is that the the message sent by the service provider be interpretable as having semantics to be consistent with the FIPA performative REFUSE. so that the client is aware both that the request as previously made will not be honored, and that the cause was the particular stated inadequacy of the request. If present, the latter enables the request to be reformulated in such a way that the protocol can continue as indicated.

Generic Authorization/Permission Sub-dialog

Another aspect of requesting a service is the supplying of appropriate credentials of the requestor to demonstrate permission for the request to be honored. The communication of credentials information is often not tied to the particular request, and so may be done once for an extended set of requests (e.g., a log-in). Therefore, for any particular request, the credential information could be optional, and the service might ask for credentials after any request where it did not know the sender's authorization. When credentials are required, they are generally supplied before the completion of the engagement stage of interaction. Note, though, that permission may also be required to interact with a matchmaker during the discovery stage, for advertising and/or for querying the matchmaker.

Figure 3 captures the general case for this protocol sub-dialog, including both the condition when the client proactively provides credentials as part of a request, and the condition when the service requests credentials after a query or request is made.

Figure 3: Abstract Authorization Protocol Fragment

This protocol fragment utilizes some additional semantic classes of message types formulated as specializations of FIPA message types, as shown in the following table. The point here is that even though the protocol is specified abstractly, and does not reflect what a particular service might implement, protocols of this kind will be characterized by an exchange of messages that fall within these types.

This kind of abstract characterization of a class of protocols and their semantics elements can thus be used to guide the interpretation of and the formulation of responses to a variety of services. In the sections that follow, where we detail the three main phases of service interaction, we will repeat this pattern of describing abstract protocols and their semantic message elements.

5. Service Discovery

Service discovery is the process by which a client (service requestor), identifies candidate services to achieve the client's objectives, by interacting with peers or special purpose middle agents (matchmakers). From an architectural point of view, the discovery process involves three types of stakeholders:

• service providers have the goal of providing particular types of services (possibly for compensation), and publish or advertise their services to enable potential clients to discover and utilize them,
• service requestors have the goal of finding services that can accomplish some internal objective, and
• matchmakers are middle agents that can be used to find (descriptions of) the service providers that match the stated requirements of a requestor. Matchmakers that both find and invoke services as proxies for the requestor are called brokers.

Following the Service oriented architecture (SOA), service providers advertise with middle agents by sending descriptions of the services that they provide through publish protocols; and service requestors use query protocols to ask the middle agent to find the services that more closely satisfy their needs. The role of these middle agent matchmakers is to recognize which provider has the capabilities that most closely satisfy the needs of the requestor.

For current generation web services, this is predominantly a manual process, in the sense that registries like UDDI [UDDI] are designed to be searched by developers of client systems, rather than middle agents or users of client systems during execution. In the Web services architecture, web services correspond to service providers, services clients are the requestor, and UDDI registries are the middle agents.

In contrast, semantic matchmakers use semantic relations to find services described using Semantic Web languages [Dec97] [Sy99] [DAML-S] [OWL-S] [Pa03] [Ve04] [WSML] [WSMO]. The language the SWSI Architecture committee will use to specify protocols for advertising service capabilities and for agents to discover useful services will be described by the SWSI Language Committee.

In general there are design tradeoffs to be made in selecting level of abstraction of the capability description used in a query to a matchmaker. Typically, a requestor has a specific goal, while service providers publish generalized descriptions of their capabilities intended to capture the range of specific activities they support, such as selling a general class of items. To be effective for matching against published service descriptions, capability descriptions should more abstract than specific goals, but may need to include information about how the goal should be achieved, and under what constraints. For example, if the client's goal is to fly from Pittsburgh to Boston on July 3 for less than $300, the client might query for capabilities of individual service providers, that included services such as quoting prices for and selling airline tickets. A more detailed match might check that the provider supported particular cities, or allowed pricing constraints to be included in its queries. Abstract capability expressions for airline ticket vendors would most likely not include details such as the times, routes and costs of particular flights that they offered for sale. These details would need to be resolved during negotiations or interactions directly with a selected service.

The use of abstract capability descriptions must be reflected in the power of the description languages used for Web Service discovery. The use of abstract capability descriptions where attributes may be described as allowing ranges or classes of values requires less transfer and storage of data, since the capability description abstracts much of the information required to represent particular goals. It also means that matches between the descriptions generated from requestor goals and those published by service providers may be imprecise, leading to a need for a post-match negotiation. To appreciate this, consider the advertisement of Amazon.com's Web service. The described capability of the service is to locate and sell books, but this specification does not show what books are available, whether they are in stock etc. These details are typically negotiated between individual requestors and services after they are discovered, although there is clearly a continuum of possible divisions of these third-party matching/brokering and direct negotiation processes.

The use of abstract capability descriptions thus implies an architectural division between discovery and negotiation, based on the premise that discovery can be performed as an interaction between a requestor and one or a set of middle agents that are aware of a set of general service capabilities provided by other agents. Negotiation, in contrast, is part of the engagement process, by which a requestor and service provider finalize an agreement on the precise service to be delivered. In effect, a client or requestor simultaneously finalizes its selection of which services are to be utilized only when it has negotiated out the details of the precise service to be provided to a particular client. While one might view the discovery process as not completing until a service has been selected, our view is that discovery only involves the requestor's acquisition of information about some candidate services.

The requirements for service discovery can be divided into the language requirements supporting a provider's ability to express its capabilities and a requestor's ability to describe abstractly classes of relevant services that might be used to achieve its goals; functional requirements specifying the tasks that need to be collectively performed; and architectural requirements describing classes of interaction protocols supporting the functional requirements, and specifying how the role players will interact during the discovery process.

Language Requirements

The stakeholders involved in the discovery process must be able to communicate their requirements and their capabilities to other role players in choreographed interactions. The semantic language requirements for discovery are based on the need to describe and communicate the following using a semantic description language:

• The characteristics and constraints (preconditions, fulfillment limitations) of the services that are available
• The requirements of service requestors, namely
1. The goals that it wants to achieve
2. The capabilities that it expects from the provider
3. Additional constraints such as quality of service, security and privacy parameters
• The abstract message types utilized in the protocols specifying interactions between the role players, as described in the protocols listed below.

Functional Requirements

The discovery process has these overarching requirements:

• The ability to describe in a general manner the capabilities of and constraints on services that could be used to fulfill other agent's future goals or requirements.
• The ability of a client to describe its own internal goals and create abstract descriptions of methods by which other web services might support or achieve those goals in order to facilitate matching of its goals to published service capabilities.
• The ability of clients to locate and interact with peers or matchmakers that can respond to requests to match capability queries against advertised service descriptions, potentially including meeting client specified constraints on quality of service and degree of match.
• 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.
• The ability of a client to decide if it can satisfy the pre-conditions specified in a prospective service's self-description.

Architectural Requirements

Protocols to support these functional requirements in a peer to peer and middle-agent enabled service discovery environment 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 explicit representations of goals, these should be included in the discovery and matchmaking task.
• Candidate Service Discovery Protocols: Clients requiring services to satisfy their objectives must be able to formulate as queries descriptions of requirements for services that could meet these objectives. These descriptions should include any limitations on how or where or when the objectives should be met, or on the form or content of the information that might be provided in order to initiate the service. These service requirements may be provided in a single query or by an extended interaction protocol that elicits additional discriminatory requirements based on the available candidates. The protocols should enable responses to queries to include descriptions of multiple services (either in a single response or streamed), and to include or enable requests for characterization of the degree and quality of match or mismatch.

These protocols assume capabilities of the middle agents:

• Agents responding to such queries must be able to compare service requirement descriptions to a variety of service advertisements.
• Matchmakers, like other kinds of registries, may be federated and organized for matchmaking along community or semantic functional categories [Si04].
• If the middle agents are brokers rather than matchmakers, responses may be based on the result of selected and executed service(s), and negotiation with services may be mediated by the broker. We will assume in the rest of this document that the middle agents are matchmakers rather than brokers.

Abstract Protocols

The abstract protocols shown in figures 4 and 5 below represent the set of interactions between service providers, matchmakers or registries, and clients in search of particular services. In each of these diagrams, the links are labeled (as in UML) with a condition shown in square brackets, typically a message received, and an action that results in entering a new process state.

Note that interactions with a matchmaker may potentially be as complex as interaction with any other service. In specifying protocols for discovery, we have not therefore described in full detail all of the potential elaborations that we describe later for general services, including the possibility of authentication requirements, and revisions to ads or their cancelation after publication.

Advertisement Protocol

Figure 4 represents the class of protocols by which a provider provides a service to a registry or peer that makes recommendations. The registry may, on evaluating the proposed advertisement, respond with a variety of critiques of the proposed advertisement, or refuse to accept it at all.

Figure 4: Service Advertisement Protocol

Discovery Query Protocol

Figure 5 represents the protocol by which a client interacts with a registry or peer to discover a service that could potentially satisfy it's requirement. After evaluating whether the returned descriptions are consistent with the client's goals and it's ability to meet the service's applicability (pre) conditions, the client may generate a revised query. Note that the registry may ask for clarification of the query, or for authorization to use the service. These potential subdialogs are as shown above.

Figure 5: Service Advertisement Protocol

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 authorized or not valid etc.
  With Semantic Web Services, non-repudiation may involve logical reasoning about the fulfillment of contracts, as by the generation of a logical proof or formal explanation that makes use of entries in an audit trail, together with non-repudiation support that the audit trail represents evidence of certain events, implies a conclusion that the contract was fulfilled (or not).

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

Protocols for service engagement describe message exchanges between service providers and requestors that result in formal or informal agreements for services to be provided. There are three fundamental protocols, reflecting a range of sophistication among the parties to an agreement. The simplest protocol, which is equivalent to the FIPA query-reply protocol [FIPA-ACL], is used to establish the provision of a service without any negotiation or formal contract. The second protocol, which is equivalent to the FIPA request protocol, requires the provider to agree to or refuse a request, and results in a non-negotiated commitment to provide a service. The third, and most complex, protocol is used to establish a formal negotiated contract for the provision of a service. The parties can iterate over the terms of the contract until agreement is reached or the negotiation is abandoned. The result is a set of commitments that bind the parties to each other until the contract is fulfilled.

The abstract protocols for engagement have been motivated by representative use case examples, accompanying each figure shown below. The set of additional abstract message types used are collected at the end of this section.

Simple Query Protocol

Example:

Requestor: "Please provide your service for me."

This use case requires no agreement from the provider, just an attempt to enact its service, as shown in Figure 6. A failure to provide the service would be undistinguishable from a denial of service.

Figure 6: Engagement: Query Protocol

Simple Request-Reply Protocol

Example:

Requestor: "Will you provide your service for me?"

Provider: "OK." | "NO."

Figure 7: Engagement: Request-Reply Protocol

As shown in Figure 7, the Request-Reply protocol requires the service to either agree or refuse to provide the service before enactment begins.

Negotiate-Commitment Protocol

Example1:

Requestor: "Will you provide your service for me?"

Provider: "Only if you pay me ten dollars".

Requestor: "I will pay you five dollars if you provide your service by 5:00 pm."

Provider: "OK." | "NO."

Result if OK: an explicit contract for the service, and implicit commitments by the parties to satisfy the terms of the contract.

Example 2:

Requestor: "Will you provide your service for me?"

Provider: "Only if you pay me ten dollars".

Requestor: "I will pay you five dollars if you provide your service by 5:00 pm."

Provider: "How about three dollars? I will provide my service by 7:00 pm."

Requestor: "OK." | "NO."

Result if OK: an explicit contract for the service, and implicit commitments by the parties to satisfy the terms of the contract.

Figure 8: Engagement: Negotiate-Commitment Protocol

These use cases illustrate the kinds of negotiations that can take place between a requestor and a provider. Note that these are all two-party negotiations. The negotiations typically involve the two parties exchanging proposals and counterproposals until an agreement or a refusal is reached. Also note that both parties are required to notify the other when a negotiation is abandoned. Time-outs are used so that no party is left hanging when another party misbehaves or fails. The result of a successful negotiation is an explicit contract that can be modeled as a commitment between the parties.

The table below shows informally the semantics of the messages used in the engagement protocol figures above, and the FIPA performatives that each is an elaboration of.

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

• Representing and specifying objectives (e.g., as requests): The client (service consumer) needs to be able to specify the goals or objectives it is trying to achieve by requesting a service. This might be in the form of a goal ontology or by formally specifying the important aspects of the desired state. A goal ontology might contain a concept such as "perform travel reservation" representing a shared understanding. A desired state might be specified as the traveler owning a ticket with certain properties. Objectives are used to formulate queries for service discovery by third parties, to select among candidate services identified in that process, and to identify specific information to include in 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 querying a logging service may be widely standardized.
• Interaction monitoring services are those that will be resonsible for ensuring that interaction protocols are observed.
• Policy monitoring services make sure that all services that are invoked maintain the contractually guaranteed QoS aggreements are maintained.

Abstract Enactment Protocols

Service enactment is the process of service invocation and monitoring by determining the information needed to request the service to be performed, monitoring it, and determining how to react when the service responds with either success or failure. Abstract enactment protocols, presented in this section, model three possible interaction scenarios. In the first scenario, we consider a synchronous communication, where the service requestor sends a message and then waits for a return message. In two other scenarios, we consider asynchronous communication, where the service requestor talks to the service provider, but after sending a message it does not expect a synchronous message back. In the first case of asynchronous communication, a one-way message is sent from the requestor to the provider and the service requestor does not expect any message back. In the second case of asynchronous communication, a reply message is expected by the service requestor at some point in time. The UML diagrams below model these protocols taking into consideration the failure and exception situations which might happen during a conversation between service requestor and provider.

Each of the scenarios described below has the same set of preconditions, namely, the discovery and engagement processes leading to an explicit or implicit service contract. The engagement phase must be executed before enactment to establish a service contract. In each of these abstract protocols, enactment communication is initiated by a service requestor when sending the first invocation message.

Synchronous Enactment Protocol

The synchronous enactment protocol describes the case in which a service requestor issues a message to a service provider and waits in synchronous mode for the reply message. The service requestor either receives a message or a time-out happens. Both the provider and requestor make a distinction between sending a reply and sending a failure message. The timeout of either party is visible to the other party as well. In case of requestor timeout, the provider does not have to send a reply any more. The protocol also includes a compensation state once the failure situation takes place.

Figure 9: Enactment: Synchronous Protocol

Asynchronous One Way Protocol

The asynchronous one way protocol, the simplest from these three protocols, describes the case where a one-way message is sent from a service requestor to a service provider. In this scenario only one failure situation is considered, when the service provider is not able to understand or to process the received message so the failure notification is issued to the requestor. There is no output message for this scenario if execution is successful.

Figure 10: Enactment: Asynchronous - One Way Protocol

Asynchronous Two-Way Protocol

In an asynchronous two way communication protocol, the service requestor, after sending an initial message, does not lock the channel but moves into a wait state while, at the same time, being capable of sending subsequent messages. Once the service provider finishes processing a message from the service requestor, it is capable to issue a reply message in an asynchronous fashion. Although the communication remains asynchronous, both parties must be able to relate any messages exchanged as being part of the same conversation. The service requestor can query for a status of previously sent messages to check their current status at the provider side. Both timeout and failure situations can happen at the service requestor and the service provider sides. Similar to synchronous protocol, the asynchronous protocol includes compensation state for the situations when failure happens.

Figure 11: Enactment: Asynchronous - Two Way Protocol

The following table shows the types of messages that were involved in the various enactment protocols above.

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.
• Provenance information management services: These are middleware services that are responsible for the delivery of data probenance related information. These services play an important role in ensuring that the data provided to clients is of appropriate quality. Examples of domains requiring these services include bioinformatics and medical information suppliers, content delivery services such as news services, and security management services.

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 occurrence.
• Cost: Cost of the service to the requestor, and measures of resources consumed.
• Reliability: Measures of likelihoods of success/failure and fail-safe outcomes
• Operational Metrics: Other domain specific quality 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.
• QoS based Optimization: There is often a need to optimize business processes based on various quality of Service criteria. Various optimization techniques like Integer Linear Programming or genetic algorithms can be used to optimize processes [Ag04] [Ze03] based on QoS 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

• [Ag04] Rohit Aggarwal, Kunal Verma, John A. Miller and William Milnor, "Constraint Driven Web Service Composition in METEOR-S," Proceedings of the 2004 IEEE International Conference on Services Computing (SCC 2004), Shanghai, China, September 2004 , pp. 23-30
• [TBL00] Tim Berners-Lee "Semantic Web Architecture" Slide from presentation , 2000.
• [Bu04] Mark Burstein Ontology Mapping for Dynamic Service Invocation On the Semantic Web Proceedings of the AAAI Spring Symposium on Semantic Web Services Palo Alto, March, 2004.
• [Ca04] Jorge Cardoso, Amit Sheth, John Miller, Jonathan Arnold, and Krys Kochut, Quality of Service for Workflows and Web Service Processes, Journal of Web Semantics, 2004.
• [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.
• [FIPA-ACL] Foundation for Physical Agents, FIPA Communicative Act Specification, Document SC00037J, 2002.
• [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.
• [Si05] Kaarthik Sivashanmugam, John A. Miller, Amit Sheth, Kunal Verma, Framework for semantic web service composition, International Journal of Electronic Commerce Vol. 9 No. 2, pp. 71-106, Winter 2004-2005.
• [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.