Semantic Contract Support for E-Business Processes

Fifth Latin American Web Congress

Semantic Contract Support for E-Business Processes Carlos Laufer Catholic University of Rio de Janeiro R. M. S. Vicente 225 Gávea, Rio de Janeiro, RJ, Brazil +55 21 3527-1500 [email protected]

Daniel Schwabe Catholic University of Rio de Janeiro R. M. S. Vicente 225 Gávea, Rio de Janeiro, RJ, Brazil +55 21 3527-1500 [email protected]

As a motivating scenario, suppose the following business process: Carlos, a musician who lives in Brazil, wants to buy a DigiTech BP200 Bass Modeling Processor — an Amp Modeling and Multi-effects Processor designed specifically for bass guitar. Musician's Friend is an USA retailer of musical instruments that has a storefront at Amazon.com. Carlos uses a web search engine to search retailers selling DigiTech BP200 and finds Musician's Friend storefront at Amazon.com. In Musician’s Friend Amazon storefront website, Carlos can find information about the equipment and how he can buy it and receive it at home. In this scenario we identify two agents that would be partners in this business process: Carlos and Musician's Friend. Each of these agents plays one or more roles in the process that occurs to accomplish the deal: Carlos is a buyer and Musician's Friend is a seller that plays also an embedded role of shipper. Each of these agents has its own goal: Carlos wants to buy; Musician's Friend wants to sell. Each of these agents could have restrictions that limit the set of potential partners: Carlos has only a Visa credit card; Musician's Friend doesn’t ship to Brazil. They could also have policies related to issues, such as, products returns, refunds, trust, QoS, etc. Finally, the business process develops through a set of ordered interactions that must be well known and accepted by all the concerned parties. Amazon E-Commerce Service (ECS) exposes Amazon's product data and E-commerce functionality [1]. This allows developers, web site owners and merchants to leverage the data and functionality that Amazon uses to power its own E-commerce business. Using the ECS interface an application can search the Amazon catalog, look-up data for a specific product, and get seller feedback from non-Amazon vendors, set up shopping carts and look-up customer wish lists and registries. Nevertheless, it is not possible to obtain the

Abstract Traditional business transactions are established under well-defined contracts, agreed, explicitly or implicitly, by all the parties involved. To support such transactions in the Internet (and in the Web) it is necessary to characterize all of its aspects, such as agents, contracts, roles, relationships, interactions between partners, policies, etc. This paper presents the Contract Oriented Web Services Model (COWS) — a model for an appropriate environment for E-business dialogues, implemented using Web Services. COWS is based on well-defined contracts agreed upon by all concerned parties and incorporates various levels of applicable policies. Contracts may refer to other contracts and are valid within forae, which have default global policies. A prototype web environment supporting COWS has been implemented to test the concepts that extend the discovery process. All COWS models have been specified as ontologies, using Flora2.

1. Introduction A business process can be understood as being the way a group of parties achieves a common business goal. If we focus on E-Business (in the sense of business processes conducted within the Internet), it is necessary to specify all the interactions and documents exchanged among those parties, including all applicable restrictions. Services can be grouped in three different types [12]: as provision of value in some domain; as a software entity able to provide something of value; as a means of interacting online with a service provider. This work is focused on the third type listed above.

0-7695-3008-7/07 $25.00 © 2007 IEEE DOI 10.1109/LA-Web.2007.11

67

policies related to shipping restrictions, privacy, return, refund, etc. All this information is textual data that is described at the seller’s Amazon storefront. How could Carlos know, using Amazon ECS, if a specific seller can ship BP200 to Brazil, which payments schemes are supported, what is the return policy? Traditional business transactions are established under well-defined contracts, agreed by all the parties involved. To support such transactions in the Internet (and in the Web) it is necessary to characterize all of its aspects, such as, agents, roles, interactions between parties, contracts and policies. The advent of Web Services initiated a trend to support such business processes, but capturing only part of it. Web Services technologies can significantly increase the potential of the current web architecture by providing a way for automating discovery, invocation and communication of functionalities. Nowadays, Web Services architectures allow programs written in different languages, on different platforms, to communicate with each other using a set of web standards, namely: WSDL [22], UDDI [18], and SOAP [14]. There have been several proposals that recognize the limitations of these standards, addressing how the semantic web [3] could support an automated version of business processes, using Web Services [5]. The fusion of both approaches, resulting in so-called Semantic Web Services, is poised to be a key technology of the next generation of the web and could provide a new infrastructure for E-business and E-work [9]. Several initiatives have come into the play, such as OWL-S [11] and the Web Services Modeling Ontology (WSMO) [23]. Semantic WS-Agreement Partner Selection (SWAPS) [10] presents a framework and implementation of a tool for the matching of providers and consumers extending WS-Agreements [2]. It uses, as an example, the problematic agricultural trade in India, for both Farmers and Merchants, and the lack of effective use of IT to facilitate the trade. Farming contracts are represented using WS-Agreements. The farming contract is implicit. There is no explicit definition of the participants of the contract, the roles they play, the choreography of the services, etc. While useful, these initiatives still fall short of adequately characterizing all aspects of E-business processes, as will be discussed next. In this paper, we analyze these shortcomings, and propose the Contract Oriented Web Services Model (COWS). It defines a model for an appropriate environment for E-business using Web Services, based on well-defined contracts agreed by all the concerned parties, and incorporating various levels of policies that apply to such contracts. In addition to the model, which has been formalized in Flora-2, we have also implemented an environment

that allows registering agents service specifications with respect to given well-known contracts, which are also formalized. Based on these specifications, the environment is able to instantiate contracts upon request by some agent who wishes to play one (or more) of the roles in some given contract, and is looking for other parties to fulfill the contract. COWS defines contracts as the heart of business processes. In terms of the classification of [12], we can regard the contracts that are published for advertising as abstract contracts that have restrictions described as policies. The discovery process searches for business parties that could play the roles defined in the contract and also complied, each one, in an egalitarian way, with the restrictions of the other participants in the contract. If the discovery process matches the partners, an agreed contract would be established. The matching takes into account the contract and the restrictions described as policies at the various levels. The remainder of the paper is organized as follows. The two following sections describe E-business dialogues and contracts in a semantic web perspective. Then, the Contract Oriented Web Services Model (COWS) is presented followed by an explanation on how it treats issues like policies and contract chains. To conclude, the last sections present related works, conclusions and future work.

2. E-Business Dialogue A business process on the Internet involves organizations interacting via Web Services, which should be regarded as peers operating on an egalitarian basis. This means that a service requester and a service provider simply become partners in a business transaction, where the service provider engages in a proper dialogue, unlike its current role of simply reacting to requests. To do so, the service provider must have a way to communicate back with the service requester. Currently, this communication consists of only one cycle of interaction and it happens on the same http connection that the request came in on. To enable a proper dialogue between peers, this communication must have business semantics — it must belong to a business transaction. An E-business dialogue is the conversation that takes place between the software systems of business partners in order to conduct a business activity. The dialogue can be simple or complex, based on the business activity that needs to be executed. E-business dialogues occur between partners, which play different roles, and are essentially composed by interactions between these partners, exchanging documents in the process.

68

To create a real-world Web Service, it is necessary to enable conducting E-business dialogues. To create a useful E-business dialogue, through open and accessible public interfaces, it is necessary to use standardized messages, vocabularies and choreography. Essentially, it is necessary to take a standard E-business process and enable it in the Web Services environment. RosettaNet [13] is a non-profit consortium of more than 500 organizations working to create, implement and promote open E-business standards and services. RosettaNet Partner Interface Processes (PIP) are specialized system-to-system dialogs that define business processes between trading partners. As an example, consider RosettaNet’s Request Purchase Order Partner Interface Process ─ PIP3A4 ─ that enables a buyer to issue a purchase order, and a provider to acknowledge whether the order is accepted, rejected, or pending. In PIP3A4 we have two roles: a buyer and a seller. Like actors delivering lines from a movie script dialogue, the organizations “deliver” messages to each other based on the order specified in the E-business dialogue. In E-business dialogues, this concept of sequence and order is known as choreography or orchestration. In the simplest form, it creates a sequence in which the messages are exchanged. The choreography can also be used to create elaborate dialogues that orchestrate services, partners or other E-business dialogues.

consumer. But the (implicit) contract that is established between the parts involved, in an operation described in WSDL, is imposed in a compulsory manner by the provider and unconditionally accepted by the requester, and is associated with only a single interaction between these partners. This class of contracts is unsatisfactory for more complex E-business dialogues. The Foundation for Intelligent Physical Agents (FIPA) [6] is an international organization that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. For example, FIPA Contract Net Interaction Protocol is a pattern for a simple interaction type, where one agent (the Initiator) takes the role of manager who wishes to have some task performed by one or more other agents (the Participants). The Web Services Choreography Description Language (WS-CDL) [20] introduces the idea of contract among parties in a Web Service environment. WS-CDL is an XML-based language that describes peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal. Using the Web Services Choreography specification, a contract containing a global definition of the common ordering conditions and constraints under which messages are exchanged is produced, which describes from a global viewpoint the common and complementary observable behavior of all the parties involved. Each party can then use the global definition to build and test solutions that conform to it. The contract is established between parties that play roles, each role with a set of behaviors. The E-business dialogues are associated to choreographies related to relationships between the participating partners. These choreographies are mainly composed by interactions where the parties exchange data and by the actions to be done in case of exceptions or faults. Without contracts, on-demand interactions are only a limited commitment. The way a group of parties involved in E-business applications achieves a common business goal using Web Services should be specified in a contract. This contract should describe aspects, such as agents, roles, interactions between parties, policies, documents exchanged among these parties, as well as all the exceptions and compensations procedures. An implementation and execution environment for Web Services must take into account the final contract that would be established among all the parties involved in achieving the goal. When composing different Web Services to achieve a

3. Contract Many of the concepts in the Web Services framework come from service-oriented architecture (SOA) [15]. One of the entities configured to support the find, bind and execute paradigm in SOA is the service contract, which specifies the way a consumer of a service will interact with the provider of the service. Britannica online [4] defines that a contract requires the mutual assent of two or more persons, one of them ordinarily making an offer and another accepting it. Wikipedia [19] defines that a contract is any legally enforceable promise or set of promises made by one party to another. The contract may be explicit (either written or oral) or may be implied from circumstances. One of the criteria for a contract to be valid is the mutual agreement (offer and acceptance). WSDL is an XML format for describing network services as a set of endpoints operating on messages containing information. These services are seen as atomic operations between a service requester and a service provider. The way a service is obtained is described in an interface contract — a published agreement between a service provider and a service

69

common business goal, all of them must adhere to a global understanding of the process, a global agreement, described in a contract.

We can’t specify more than two roles, because the functional description takes into account the idea inherit from Web Services, which deals with a simple interaction between a requester of a service and a provider of a service. If we want to deal with businesses, as in the real world, we need to think about the whole process and all the partners involved, in an egalitarian way. An E-business dialogue is seen as an exchange of information between partners playing roles according to established relationships. We assume that the interaction schema of a specific contract, the choreography, is global and predefined. When an agent is a candidate to play a role in a contract, she assumes that she can support all interactions defined in that choreography, which includes the faulty and compensation situations. All partners of a given contract are aware of the same global choreography definition. Global choreographies could be specified by standard initiatives, such as RosettaNet or OASIS ebXML. Global choreographies restrict the world of possibilities, but if we have standard contracts associated with global choreographies, partners of business process of common use could adapt their applications to these choreographies. Alternatively, if each partner specifies its own choreography, we can introduce, in COWS, a choreography-matching phase, as in the current semantic web services initiatives. The web environment for COWS has a registry where a party publishes the role that it can play, using a set of contract patterns, in addition to the business functional information related to the goal to be achieved, as is already published currently. In addition to the traditional goal matching, the discovery service is also responsible for establishing relationships between partners playing specific roles. These relationships are defined in the contracts. The business functional information itself can be described, for example, in WSMO, OWL-S or WSDL. All models in COWS have been specified as ontologies, using Flora2 [7]. We have also constructed a COWS registry and search environment prototype using Flora-2, an advanced object-oriented knowledge base language and application development environment that supports F-Logic specifications. We defined ontologies for contract, forum, and publishing of agents, as well as the rules that permit queries about solutions involving partners in a business contract. Figure 1 presents a diagram of the top level of the COWS ontology, whose parts we discuss next.

4. The Contract Oriented Web Services Model (COWS) The Contract Oriented Web Services Model (COWS) defines a model for an appropriate environment for E-business dialogues implemented using Web Services, based on well defined contracts agreed by all the concerned parties, and incorporating various levels of policies that apply to such contracts. COWS separates service descriptions in two parts: service functional description and service contract description. The functional description contains the information about the data that is the object of the business transaction itself. The contract description contains information about all applicable restrictions, such as payment methods, refunds policies, QoS, privacy policies, rights, trust, etc., as well as the communication protocol that should be established to achieve the results expected by all the concerned parties. WSDL describes the message format and the type of the variables contained in the messages exchanged by Web Services. Service providers can advertise the services offered through UDDI registries, but service consumers cannot advertise they needs through some similar kind of registry. Therefore, current E-business processes are always initiated by a service consumer, which searches for a provider. In this search, the service consumer cannot easily specify any policies of its own that service providers should comply with. OWL-S and WSMO describe the service functionalities with more semantic information than WSDL, but both describe the contract information, mainly, from the provider’s perspective, assuming that the requester is forced to accept the contract (i.e., “take it or leave it”). There are, always, the same two syntactic roles: requester and provider. If, for example, we have a business of selling and buying a product, two semantic different roles are considered the same syntactic role, depending in which agent begins the interaction. If the buyer begins, he is the requester and the seller is the provider. If the seller begins, he is the requester and the buyer is the provider. There isn’t the concept of semantic role. Discovery should be symmetric; the functionality should not restrict a provider to advertise and a requester to actively discover [12]. Even more, if an Ebusiness dialogue involves more than two partners, there is no global contract specification binding all of them, only independent pair-wise contracts.

70

1

1

has

accepts

1 ..*

0 ..*

follows

Forum

1 ..*

1

Agent Bind 1

•

follows

Agent

1

Policy

0..*

•

0 ..*

0 ..*

The COWS Environment should search for sellers and shippers that satisfy the needs of the buyer using a contract that specify the protocols of the PIPs involved in the business process. The discovery service can search for a partner that plays both roles (seller and shipper) or it can search for two different partners, each of them playing one of the roles. In the first case the agents involved will have two different relationships between them: one to handle buying aspects and the other to handle the shipping details. In the second case the agent that plays the buyer role will establish a relationship with the agent that plays the seller role to buy the book and another one with the agent that plays the shipper role. Moreover, the seller must also have a relationship with the shipper. Therefore, the discovery service must know the set of roles and relationships that should be established to achieve a common business goal – i.e., to match the whole contract. When matching the goal of a requester, the discovery service should identify the E-business dialogues that could be used to achieve the goal and, in this way, discover the partners that could take part in the E-business dialogues, each of them playing the appropriated role in compliance to contract patterns. In the previous example, in the case of three partners involved, the discovery service must search for partners that can fulfill the requirements of the goal itself, and also can understand the communication protocols (the PIPs) used in the interactions among the partners. It is important to note that all the parties involved should know that they are taking part in an Ebusiness dialogue and they should be capable of responding to exceptional and faulty situations. A document published by an agent contains information about the agent, its functional description and the contracts that this agent accepts. Figure 3 presents the methods signatures of a published document using Flora-2. Figure 4 presents an example of a published document. In the contract specification the agent indicates the role it plays in the contract and information about the relationships with the other agents that would participate in the contract instantiation, as for example, trust and policy.

follows

1

1

participates in 1

1

acts according to

plays

Choreography

binds

1

Contract

1

has

has

1 2 ..*

1

1

FuncionalDescription

1

Role Bind 1

Contract Bind

binds

1

has 1..*

establishes

1

0 ..*

1

Role 1

1 ..*

1

1

has 1

has

claims

1

1

0 ..*

Trust

Relationship follows

Figure 1. COWS top level vocabulary When someone wants to establish an E-business dialogue, she informs a discovery service the business functional information and the role that she can play in an E-business process defined by a set of contract patterns. Based on this information, the discovery service can search relationships between parts playing specific roles in well-defined contracts. Consider an example of a user who wants to buy a book. Here we will have a relationship between three roles: a buyer, a seller and a shipper (see Figure 2).

buyer

buyer-seller relationship

buyer-shipper relationship

shipper

seller

seller-shipper relationship

Figure 2. Contract with three partners We could use the following set of RosettaNet PIPs to define the business process: • • • • •

PIP4B2 - the buyer sends a shipment receipt notification to the seller; PIP3C5 - the seller prepares a billing statement and notifies the buyer.

PIP3A2 - the buyer requests the price and availability of products to the seller; PIP3A4 - the buyer sends a purchase order request to the seller; PIP3C3 - the seller sends an invoice notification to the buyer; PIP3B1 - the seller sends a transportation request to the shipper; PIP3B3 - the shipper sends the status of the shipment to the buyer;

71

A policy in COWS is composed by a set of facts and rules. COWS allows the specification of policies at four different levels: role, contract, agent and forum. The first three levels are specified by an agent while the last one is a global set of policies that is associated to the forum within which a contract is established. The role level policy is associated with a role played by an agent in a specific contract. The contract level policy is related to the contract to be accomplished by the agents. The agent level policy applies to all contracts that are accepted by the agent. Figure 5 presents an example of a policy (pseudocode) that establishes that an agent only accepts a certain set of other agents as partners for the business. In the example, agent Carlos has no restrictions related to partners playing the seller role, but has a restrict set of partners playing the shipper role: agent FedEx. Each contract is valid under one or more forae. For example, we may have a forum that requires that all agents must be from the same country, must have WSMO descriptions, and so on. A forum is basically composed by a set of policies that all the agents participating in a contract within that forum should satisfy.

agentPublish[hasAgentInfo=>agentInfo ,hasContractInfo=>>contractInfo ,hasPolicy=>>policy]. agentInfo[agentURI=>xsd_anyURI ,name=> string ,country=>string]. contractInfo[contractURI=>xsd_anyURI ,forumURI=>>xsd_anyURI ,hasBindingInfo=>bindingInfo ,hasPolicy=>>policy]. bindingInfo[hasRoleBinding=>>roleBinding]. roleBinding[contractRoleName=>string ,hasRelationshipBinding=>>relationshipBinding ,hasPolicy=>>policy ,hasWebService=>webService]. relationshipBinding[contractRoleName=>string ,hasTrust=>>trust]. functionalDescription[metaModelType=>string, ,descriptionURI=>xsd_anyURI]. trust[bindId=>integer ,credentialURI=>xsd_anyURI ,certificationURI=>>xsd_anyURI]. policy[fact=>string ,rule=>string].

Figure 3. Publish methods signatures _#:agentPublish [hasAgentInfo-> _#[agentURI->CARLOS_URI,name->'Carlos',country->'Brasil'] ,hasContractInfo->> {_#[contractURI->3PARTNERS_CONTRACT_URI ,forumURI->>{FORUM1_URI} ,hasBindingInfo-> _#[hasRoleBinding->> {_#[contractRoleName->'BUYER' ,hasFuncionalDescription-> _#[metaModelType->WSMO, ,descriptionURI->http://tecweb.inf.puc-rio.br/serviceURI] ,hasRelationshipBinding->> {_#[contractRoleName->'SELLER'] ,_#[contractRoleName->'SHIPPER']}]}]]}].

policy(CARLOS, Solution) { FOR EACH partner of Solution IF (partner’s role is 'SHIPPER') THEN IF (partner is 'FEDEX') THEN 'SUCCESS' ELSE 'FAIL' ENDIF ENDIF END FOR }

Figure 4. Buyer publishing example

5. Policies

Figure 5. Policy example

A contract among a set of parties may involve a series of policies that could specify traditional requirements and capabilities, privacy aspects, QoS characteristics, payment methods, refunds policies, etc. An agent that wishes to participate in a business process playing a role in a contract is considered a candidate when it satisfies the policies of the other agents that are involved in that contract. Policies impose restrictions on properties of a service. For an ontological description of policies these restrictions have to be expressed in an underlying knowledge representation formalism. In this way requesters and providers of services can describe their policies with respect to a common ontology in terms of meaningful concepts and relations [8].

6. Contract Chaining Let us consider again the Musician’s Friend scenario. We define a contract C1 (BUYER_SELLER_CONTRACT) that establishes the selling of musical instruments and has two roles: seller and buyer. Musician’s Friend could publish itself in COWS as an agent that accepts contract C1, playing the role of seller, under a forum that establishes that all the agents should be from USA. Carlos, a musician that lives in Brazil, wants to buy a DigiTech BP200 Bass Modeling Processor for his instrument. Carlos could publish himself in COWS as a buyer in contract C1, under a forum that accepts agents from North or South America. If Carlos sends a

72

search request to COWS, Musician’s Friend would not match. Web International Trading is a company providing E-commerce solutions that offers an integrated cross border trade experience for U.S. manufacturers, distributors and retailers to consumers in a variety of countries. Suppose that we have a contract C2 (BROKER_CONTRACT) that establishes the brokerage of musical instruments and has two roles: seller and buyer. This contract also defines that the seller role is connected to the buyer role of contract C1 (see Figure 6).

North or South America, and sends a search request to COWS (see Figure 7), COWS is able to find a solution that is the chaining between C2 and C1, where Carlos is a buyer in C2, Web International Trading is a seller in C2, Web International Trading is a buyer in C1 and Musician’s Friend is a seller in C1.

7. Related Work COWS defines an ontology for contracts based on a few WS-CDL abstract concepts, modeling an environment for discovery, invocation and enactment of Web Services that makes use of contracts. COWS proposes a model where the contract is a global definition that should be taken into account in all the steps of a business process, including the discovery of the participants that would take part in this process. A WS-CDL XML document is only a set of definitions and makes no reference to the discovery, invocation and enactment of the business process defined by the contract. It does not include policies neither the forum concept. For OWL-S the contract is imposed by one of the participants of the business process and is embedded in the process model of the provider, and in WSMO, in the choreography of the provider. In both cases the contract is not a global definition and is embedded in the specification of the service providers. OWL-S can provide descriptions of policies and security requirements [17], but, again, there is the idea of only two partners: a provider that should satisfy the requester needs. There isn’t the idea of partners, which could be more than only two ones, which participate in a business process with a common goal and in an egalitarian way. Preist [12] defines three types of services: abstract, agreed and concrete. An abstract service is some set of concrete services. An agreed service is an abstract service agreed between two parties. A concrete service is said to be a realization of an abstract service if it appears in this set. We can think the abstract service as a service that is described for its advertising and discovering. The discovering process is the first step to establish an agreed service between the parties. Some services need a negotiation as a first phase of interaction between the parties to establish the final agreed service. The agreed service forms the core of the service contract between two parties, which defines the semantics of their interaction. WS-Agreement [2] defines a language and protocol for establishing agreements between two parties. It states that an agreement between a service consumer and a service provider specifies one or more service level objectives both as expressions of requirements of the service consumer and assurances by the service

BROKER_CONTRACT (C2)

role

buyer

role seller binds

BUYER_SELLER_CONTRACT (C1)

role

buyer

role seller

Figure 6. Broker contract example Web International Trading can publish itself in COWS as an agent that accepts contract C1, playing the role of buyer, under the forum that establishes that all the agents should be from the USA. Web International Trading can also publish itself in COWS as an agent that accepts contract C2, playing the role of seller, under the forum that accepts agents in North or South America. BUYER_SELLER_CONTRACT

binds

WebTrade Int binds

binds buyer

seller

Musician's Friend

BROKER_CONTRACT

seller

buyer

binds Carlos

Figure 7. Broker example diagram If Carlos publishes himself in COWS as a buyer in contract C2 under the forum that accepts agents from

73

provider on the availability of resources and/or on service qualities. It is not one of its goals defining a protocol for negotiating agreements. Semantic WS-Agreement Partner Selection (SWAPS) [10] presents a framework and implementation of a tool for the matching of providers and consumers extending WS-Agreements. It uses as an example, the problematic agricultural trade in India, for both Farmers and Merchants, and the lack of effective use of IT to facilitate the trade. An ontology representing the Agriculture domain can provide the matcher with a complete understanding of the domain and the user can supplement this knowledge with rules specific to the domain. In the article it uses WSAgreements to represent farming contracts. The previous contributions do not consider the contract as the heart of the business process and in the publishing phase there is no explicit commitment of the business participants to predefined contracts that have constraints that should be satisfied in an egalitarian way to achieve a common business goal. While they have several aspects related to contracts implicit in their definition, they lack the explicit model that allows integrating all aspects — roles, services, policies, etc.

specified contracts when they publish their service specifications, or when they search for partners. Thus, the contract established between partners when a Web Service is matched, and then enacted, is implicit in the meta-model adopted, and is currently the one imposed by the Web Service provider. There may be some adjustment of Service Levels, but these are still the ones set forth by the service provider; the service consumer can only accept it or reject it. We believe that contracts as specified in COWS allow a more realistic (i.e., closer to current practice outside the Internet) implementation of business transactions on the Web, increasing the degree of automation possible today. As future work we have to integrate the current COWS prototype, developed using Flora-2, with current Semantic Web Services descriptions such as WSMO and OWL-S. The policy module should be extended to allow restrictions consulting the Semantic Web Services descriptions directly, as well as SLA information, and handling of different policy languages and schemas, including WS-Policy [21], WSAgreement and SWAPS. It is clear that general matching of policies cannot be achieved for unrestricted policy expressions, so we will also investigate relevant subsets that can still be fully automated. The choreographies based on WS-CDL W3C recommendation should also be integrated into the model. Furthermore, we must also investigate and develop the enactment phase of the process [16], once bindings for contracts have been found. As mentioned earlier, exceptions may occur, and policies must typically be applied to help cope with such exceptions, as specified in the contract.

8. Conclusions COWS presents a model for a more realistic environment for E-business dialogues that realize business processes, implemented using Web Services, based on well-defined contracts agreed upon by all the concerned parties, and incorporating various levels of policies that apply to such contracts. COWS defines a model where the contract is a global definition that should be taken into account in all steps of a business process, including the discovery of its possible participants. As a consequence, a contract definition provides the framework within which Web Services described in accordance to different meta-models may be integrated, provided mediators are developed to translate between the various meta-models. The functional aspects are obtained from the specific semantic descriptions of each meta-model, and the coordination aspects are obtained from the contracts. COWS models have been specified as ontologies, using Flora-2 and a prototype has been implemented to test the concepts, as illustrated in several real-life examples. The current model of Web Services environment, as exemplified by WSDL, WSMO or OWL-S specifications, can be seen as a restricted case of COWS. In fact, it suffices to consider that the agents playing roles in a business transaction have not

9. References [1] Amazon

E-Commerce Services WSDL. http://webservices.amazon.com/AWSECommerceServic e/AWSECommerceService.wsdl.

[2] Andrieux, A., Czajkowski, C., Dan, A., Keahey, K.,

Ludwig, H., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M. WebServices Agreement Specification (WSAgreement). June 2005.

[3] Berners-Lee, T., Hendler, T.J., Lassila, O. The Semantic Web, Scientific American, May 2001.

[4] Britannica Online, http://www.britannica.com. [5] Fensel, D. Ontologies: Silver bullet for Knowledge

Management and Electronic Commerce, 2nd edition, Springer, 2003.

[6] The Foundation for Intelligent Physical Agents, Interaction Protocol, http://www.fipa.org/repository/ips.php3.

74

FIPA.

[7] Flora-2:

An Object-Oriented Knowledge Language. http://flora.sourceforge.net/.

Base

[8] Grimm, S., Lamparter, S., Abecker, A., Agarwal, S.,

Eberhart, A. Ontology based Specification of Web Service Policies, Proceedings of Semantic Web Services and Dynamic Networks, volume 51 of LNI, pp. 579583. GI, September 2004.

[9] McGuinness, D. L. Ontologies Come of Age, “Spinning

the Semantic Web: Bringing the World Wide Web to Its Full Potential”, Dieter Fensel, Jim Hendler, Henry Lieberman, and Wolfgang Wahlster (editors), pp. 171194, ISBN: 0-262-06232-1, MIT Press, 2003.

[10] Oldham, N., Verma, K., Sheth, A. and Hakimpour, F.

Semantic WS-Agreement Partner Selection, WWW, World Wide Web Conference, Edinburgh, Scotland, May 2006

[11] OWL-S,

Ontology Web Language http://www.daml.org/services/owl-s/1.0/.

Services,

[12] Preist, C. A Conceptual Architecture for Semantic Web Services, ISWC, International Semantic Conference, Hiroshima, Japan, November 2004.

Web

[13] RosettaNet. http://www.rosettanet.org. [14] SOAP, Simple Open Access Protocol 1.2, World Wide Web Consortium. http://www.w3.org/TR/soap12-part1/.

[15] Stevens, M. Service-Oriented Architecture, Java Web Services Architecture, Chapter 2, Morgan Kaufman Publishers, 2003.

[16] Singh, M. P.; Chopra, A.; Desai, N.; Mallya, A.

Protocols for processes: programming in the large for open systems. ACM SIGPLAN Notices, v. 39, Issue 12, December 2004.

[17] Sycara, K., Martin, D., McGuinness, D.L., McIlraith ,S.,

Paolucci, M. OWL-S Technology for Representing Constraints and Capabilities of Web Services, W3C Workshop on Constraints and Capabilities for Web 110

[18] Services, October 2004. [19] UDDI, Universal Discovery Description and Integration

3.0.2, Organization for the Advancement of Structured Information Standards. http://uddi.org/pubs/uddi_v3.htm.

[20] Wikipedia. http://en.wikipedia.org. [21] WS-CDL, Web Services Choreography Description Language, http://www.w3.org/TR/ws-cdl-10-primer/.

[22] WS-Policy The Web Service Policy Framework, http://www-106.ibm.com/developerworkds/library/wspolfram.

[23] WSDL, Web Services Definition Language 1.1, World Wide Web Consortium. http://www.w3.org/TR/wsdl.

[24] WSMO, Web Service Modeling Ontology, DERI. http://www.wsmo.org/TR/d3/d3.1/v0.2/.

75