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

Version 1.0 is now available for public comment.

Table of contents



1. Introduction

The Semantic Web Services Initiative (SWSI) is an 'ad hoc' initiative of academic and industrial researchers, many of whom are involved in DARPA, 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:

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:

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.

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):

In other words, for dynamic web services to function, clients must be able to semantically interpret the published descriptions of unfamiliar service interfaces and make use of them to decide which service to use and to formlate requests to those selected services. As these service interfaces continuously evolve, this will enable the interactions to continue to occur smoothly. If the changes make a service inappropriate for a particular client's need, then it will allow that client to discover new services that meet its needs better.

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:

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.

Overview Figure
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:

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.

Clarification dialog protocol fragment
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.

Authorization protocol fragment
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.

Message Type Performative From To Comment
InformAuth Inform Client Server May be included as part of original request message
QueryAuth Query Ref Server Client A request for the name of authorization source or authorization token of the client.
AuthOk Inform Server Client Acknowledge that authorization is accepted by server.
Unauthorized Inform Server Client Report that authorization is NOT accepted by server.

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


5. Service Discovery

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

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:

Functional Requirements

The discovery process has these overarching requirements:

Architectural Requirements

Protocols to support these functional requirements in a peer to peer and middle-agent enabled service discovery environment will include the following:

These protocols assume capabilities of the middle agents:

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.

Discovery Advertisement Protocol
Figure 4: Service Advertisement Protocol

Message Type Performative From To Comment
Advertise Request Client Server Although also an Inform, the request is to record and publish the description, which means it can be Refused and the service may fail to install it.
RefuseAdvert Refuse Server Client Reasons can include ill-formedness, lack of authorization, wrong type of service for this broker.
AdvertInstalled Inform Server Client (Shown as 'OK') Acknowledges that posting is accepted by server.
ReviseAdvert Inform Client Server (Not shown.) After installation, a Request to update an advertisement previously accepted by the server.
CancelAdvert Cancel Client Server (Not shown.) After installation, a Request to terminate the publishing of an Ad.

Discovery Query Protocol

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

Discovery Query Protocol
Figure 5: Service Advertisement Protocol
Message Type Performative From To Comment
FindService Query Ref Client Server Request information about relevant services. Must include an abstract characterization of the services sought.
FS_Result Inform Server Client A reply reporting the results of a successful query.

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

Architectural Requirements

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.

Engagement: Query Protocol
Figure 6: Engagement: Query Protocol

Simple Request-Reply Protocol

Example:

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

Provider: "OK." | "NO."

Engagement: Request-Reply Protocol
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.

Engagement: Commitment Protocol
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.

Message Type Performative From To Comment
RequestService Request Client Server Content is the description of the service desired, potentially along with anciliary information to identify the requestor, provide authorization, or convey non-functional preferences and conditions. Also used for revised requests.
AcceptRequest Agree Server Client Acknowledge receipt of request and inform of intent to perform the service.
CancelRequest Cancel Client Server Inform that the client no longer has the intention that the server perform the service previously requested.
OfferService Inform Server Client Inform a client of a description of a service that the server will intend if client agrees. Typically used to make a counter offer or to elaborate on the details of the action the server will do in responding to the request.
AcceptOffer Inform Client Server Inform server that client agrees to offered service.
RefuseOffer Inform Client Server Inform server that client does not agree to the offered service. This is an alternative to R' (Figure 8) where no new request is made, so that the service may make a new offer.

7. Service Process Enactment and Management

Once a service has been identified that can satisfy a client goal or requirement, it must be invoked and monitored, by determining the information needed to request the service be performed, and determining how to react when the service responds with either success or failure [DA01][Mc02][Eb04].

Functional Requirements

Architectural Requirements

While many of the functional capabilities above must be resident within clients and servers, some may be provided by middle agents. In these cases, standardized protocols may be defined, which would utilize widely shared ontologies.

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.

Enactment: Synchronous Protocol
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.

Enactment: One Way Asynchronous Protocol
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.

Enactment: Two Way Asynchronous Protocol
Figure 11: Enactment: Asynchronous - Two Way Protocol

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

Message Type Performative From To Comment
InvokeService Request Client Server Message content is a reference to the agreed upon service contract, developed during the engagement phase. If the preceding engagement protocol consisted only of a request (the Engagement Query-Reply Protocol) or Enactment followed directly after the client agreeing to an offer in the Negotiate-Committment protocol, then this message is skipped.
ServiceResult Inform Server Client Communicate the informational result of a service, along with its status.
ServiceFailed Inform Server Client Communicate the failure of a service enactment, possibly with an accompanying reason.
QueryStatus Query Ref Client Server Request update on the status of a service in progress.
ServiceStatus Inform Server Client Communicate the status of a service enactment, possibly with an accompanying reason.
CancelService Cancel Client Server Signal that client no longer intends Server to perform service contract.
CancelServiceforError Cancel Client Server Client timeout results in it no longer intending Server to perform service contract.
CancelAck Inform Server Client Acknowledge that server has received Cancel or Error and stopped performing service.
RequestCompensation Request Client Server Request the initiation of a compensation process after a ServiceFailed message is received. Compensation would be based on an (implicit or explicit) Service Contract.
Compensation Inform Client Server Inform client of the completed execution of and result of a compensation process.
RefuseCompensation Refuse Server Client (not shown) Inform client that server does not agree to the provide compensation for stated reason

8. Community Support Services

This class of middleware services (architectural requirements) support various aspects of distributed activity that can be supported with semantic web architectures. They represent the following desiderata of Semantic Web services and web services generally:

Functional Requirements

Architectural Requirements


9. Service Lifecycle Support Services

In distributed environments, including web services and the Grid, resources are shared among partners and across communities. The Grid community has begun adapting their approach to resource sharing to align it with and benefit from the increased interoperability provided by web services and to anticipate the additional benefits of Semantic Web services technology [Fo02]. The issues that they have addressed are also important for many other kinds of Semantic Web Services applications.

The lifecycle of a resource is a set of states and transitions between those states. During their lifetime resources can be in a set of stages (e.g., down, starting, up, failed, stopping etc.), and substages (e.g., idle, busy, degraded etc.) during which they may or may not be managed via manageability interfaces of their associated services. (e.g., a failed resource may not respond to some management commands.)

The types of resources that can be shared range from CPU cycles to storage facilities, from databases to software components. This diversity in the types of resources has led to development of "Resource Models" [WSRF][GCRM][CIM] that are the basis for the recently developed ontologies for resources which will provide a common vocabulary for interchanges about controling and managing them [Ta03].

Semantic descriptions of resources will not be sufficient by themselves to support a sustainable resource sharing environment. Resources and the services utilizing them have a lifecycle relationship that also needs to be modeled and taken in to account to achieve dynamic resource sharing. In general, we must model the dependencies and relationships among services that reflect resource sharing, the resource management policies and manageability capabilities that services and resources provide, and the lifecycles (state models) of both resources the web services they interact with.

These ontologies can be used to ask and answer questions or make resource management or resource provisioning decisions such as:

Functional Requirements

Resource management agents acting on behalf of service requestors need to have three types of information to make provisioning decisions: resource and service status information, resource manageability capabilities, and resource provisioning policies. With Semantic Web Services, each of these types of information may be represented and acquired dynamically, and used to control and manage resource sharing among communities of many service users.

Architectural Requirements


10. Cross-cutting Requirements

Two areas other requirement areas that impact the architecture of semantic web services generally are the overarching needs for security and information privacy, and means of expressing and ultimately controlling or monitoring the quality of the services provided. We address these issues here.

Quality of Service

In Web processes for e-commerce and other kinds of GRID and Web service applications, suppliers and customers define a binding agreement or contract between the two parties, by specifying Quality of Service (QoS) metrics [Ca04][Ze03]. Examples of QoS metrics include deadlines, quality of products, and cost of services. The management of QoS metrics is critical to the success of organizations participating in e-commerce. It affects how services are advertised, is a major topic in negotiation processes that precede contract formation and service provision, and can impact how enactment occurs and the type and level of compensation when it does not occur successfully. Therefore, when services or products are created or managed using workflows or Web processes, the underlying discovery, coordination and execution engine must accept the specifications and be able to estimate, monitor, and control the QoS rendered to customers.

Metrics and means of monitoring and adjusting for QoS may, depending on domain and performance requirements, be actively managed for any of the following:

Issues that must be addressed include:

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.

Functional Requirements

Architectural requirements


References