Contract-driven creation and operation of virtual enterprises

Computer Networks 37 (2001) 111±136

www.elsevier.com/locate/comnet

Contract-driven creation and operation of virtual enterprises Yigal Ho€ner a,*, Simon Field a, Paul Grefen b, Heiko Ludwig a a

IBM Research Division, Zurich Research Laboratory, Saumerstrasse 4, 8803 Ruschlikon, Switzerland b Computer Science Department, University of Twente, Enschede, Netherlands

Abstract This paper examines the support needed for dynamically creating and managing contract-driven virtual enterprises. Our approach to virtual enterprises views contracts as the central theme that runs throughout the enterprises' life cycle and touches upon all major aspects thereof. A Contract Framework integrates the concepts and entities necessary for the contract-centred support. A combination of Virtual Market technology and an advanced Matchmaking Engine (MME) facilitates the creation of service markets where matching business partners can ®nd each other. The market facilitates the deferment of business partner selection and contract signing to the point when the need for the service arises. A set of pre-prepared Internal Enactment Speci®cations (IESs) provides the mapping of the contract to an organisational blueprint, speci®ed in terms of the internal language, resources and infrastructure of each organisation. The blueprint provides a way of automating the con®guration of the Contract Enactment Infrastructure (CEI) for the respective organisations. This complements the deferred selection of a business partner. Advanced CEI technology allows business processes to cross organisational boundaries while providing the consumer with a considerable degree of monitoring and control capability over the contracted service. The integration of our proposed framework and approach supports the creation and management of highly dynamic service markets with automated, ®ne-grained interaction between organisations, thereby ful®lling the ¯exibility and eciency requirements of modern e-business. The approach was used to implement a number of example scenarios and the conclusions drawn from this experience are presented. Ó 2001 Elsevier Science B.V. All rights reserved. Keywords: Virtual Markets; Virtual enterprises; Cross-organisational business processes; Contract Framework; Service contracts; Contract matchmaking; Contract Enactment Infrastructures (CEIs); Dynamic Enactment Infrastructure con®guration

1. Introduction In the current fast-paced economy, we can observe two important trends. First, organisations have to integrate their business processes into

* Corresponding author. Tel.: +41-1-724-8922; fax: +41-1-7248953. E-mail addresses: [email protected] (Y. Ho€ner), sif@ zurich.ibm.com (S. Field), [email protected] (P. Grefen), [email protected] (H. Ludwig).

cross-organisational processes to be able to operate and survive in a market. Integration can be necessary from a functional point of view because products or services simply become too complex to be delivered by a single organisation. Integration may also be necessary from the point of view of eciency, because organizations reduce their activities to core business ones and contract their secondary activities to providers that o€er cheaper or better services. The second trend indicates that business relationships between organisations become more

1389-1286/01/$ - see front matter Ó 2001 Elsevier Science B.V. All rights reserved. PII: S 1 3 8 9 - 1 2 8 6 ( 0 1 ) 0 0 2 1 0 - 9

112

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

dynamic in order to more e€ectively deal with changing market situations. For example, developments in pricing strategy or changes of the quality of delivered goods, require new business relationships to be forged on the ¯y and existing relationships to be dismantled quickly. The combination of both trends leads to the concept of dynamic virtual enterprises. To operate e€ectively and eciently, these virtual enterprises rely heavily on information technology to set up and enact their business processes. A look at business relationships is necessary before we develop the concepts and processes essential for the creation and management of virtual enterprises. 1.1. Business relationships and virtual enterprises Before two organisations can co-operate in a virtual enterprise, a business relationship has to be established between them. To establish this relationship, both organisations are required to participate in the following activities: · Select a suitable service provider and exchange the information between the potential provider and consumer, needed to reach an agreement. · Reach an agreement and sign a contract where necessary. This allows important business relationships to be anchored by a legally binding agreement, safeguarding the business concerns of each participating organisation. Once the business relationship is in place, the organisations can exploit it in order to: · Allocate and con®gure the resources (people, IT systems, organisational knowledge and processes) of both parties, needed to provide and consume the service according to the contract. · Initiate/launch the service when the consumer and provider are ready. · Monitor the progress of the service. · Control the progress of the service. · Close down the relationship on termination or completion of the contract enactment. · Collect long-term monitoring information to allow both parties to ®ne-tune their service provision and consumption and their partner selection process.

Most of the above processes usually involve lengthy activities requiring a considerable amount of human participation and other resources. In particular, contract establishment and the allocation and con®guration of organisational resources for a speci®c contract are complex and time-consuming processes. The investment and the time delay often lead to the creation of business partnerships in anticipation of a future need, long before the speci®c need arises. When the agreement is actually used, the circumstances may have changed and the agreement may be far from optimal. Long-term relationships, which incorporate some level of ¯exibility by ®xing most contract issues while leaving others open, have often been used to overcome these problems. However, they only offer a partial solution to the problem and require the organisations involved to make promises that necessitate the pre-allocation of resources for long periods of time. A virtual enterprise aims to use information technology to achieve a business partnership dynamically, resulting in a business that can quickly form new relationships with service providers in response to business needs as they arise [1]. This requires the ability to defer decision-making, commitment and resource allocation to the latest time possible. This dynamic capability requires the capability to carry out the same process described above, but with a new set of requirements: · Defer the selection of a business partner as late as possible. This ensures that the search for a compatible service provider and consumer is conducted using the most up-to-date requirements and o€ering from both parties. · Speed up the process of reaching agreement to complement the deferred selection of a potential business partner. · Represent agreements in an electronic form that will be used throughout the rest of the business relationship between the two organisations. We refer to the representation of the agreement as a contract. However, whether it is digitally signed or not depends on legal and trust issues surrounding the business partners and is outside the scope of this paper. · Defer allocation and con®guration of resources to the latest possible point to allow the most up-to-

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

date handling of organisational resources, based on current commitments. To avoid losing the bene®ts of the deferred selection and agreement with a partner, each organisation should be able to allocate the necessary resources and con®gure them quickly to prepare for enactment. The electronic contract together with organisationspeci®c information can be used to automate and thereby speed up the process of resource allocation and con®guration. · Provide real-time monitoring that can be exploited together with the contract to verify automatically that the service behaves according to the promises made in the contract. · Provide advanced forms of service control (that go beyond halting, resuming and aborting a service) such as service plan modi®cation or resource allocation, in accordance with the contract. · Defer contract enactment-time decisions and actions to the latest possible point by coupling real-time monitoring information with the advanced control capability. · Provide for the automatic dismantling of the contractual relationship to achieve a clean and speedy release of allocated resources. The deferral of decisions and resource allocation is a cornerstone of virtual enterprises. However, this should not preclude the possibility of early decision-making and early resource allocation where this is deemed appropriate. The need to speed up the above processes and in particular the establishment of the contractual relationship and the set-up of the enactment infrastructure makes it necessary to automate these processes and minimise human intervention insofar as possible. Several issues have to be addressed and developed to make virtual enterprises possible: · Contract-based relationships between organisations: Underlying virtual enterprises is a business relationship that must be de®ned in a contract. The contracts must have an electronic representation that can be used in various phases of the business relationship. Combining the notion of contracts with Virtual Markets to facilitate the advertising and searching for service contracts requires the use of Contract Templates (CTs) ± commonly used contracts that have evolved in

·

·

·

·

113

speci®c markets and become an agreed basis for doing business. The creation and use of virtual service markets: Where providers can advertise their services and consumers can search for the service they require. The known pool of service providers and consumers helps in ®nding compatible business partners needed for constructing a virtual enterprise. The use of a Virtual Market contributes choice and fosters variety and competition. The Virtual Market supporting the selection of a business partner must be well de®ned and restricted (or `closed'). The use of Virtual Markets requires a considerable amount of agreement among the market players and operators. This requires the market services to be well de®ned in a commonly agreed way. Advanced Contract Enactment Infrastructures (CEIs): The infrastructures must be capable of integrating di€erent organisational resources thus enabling the promised service to be provided and consumed in accordance with the contract. The contracted service cannot be viewed in a black-box fashion ± it must support ®ne-grained granularity of service monitoring and control. CTs must correspond to existing service de®nitions and specify what monitoring and control operations are allowed. These can be a subset of those provided by the service. Contract-dependent generation and linking of the enactment infrastructures: The allocation and con®guration of organisational resources and the linking of the infrastructures of the two organisations are to be automated and carried out dynamically. This is achieved by using the speci®cation provided in the contract and a blueprint containing the contract- and organisational-speci®c plan for its enactment. Contract-dependent enactment, supervision and evaluation of the relationship: Some aspects of enactment and supervision of the contracted service can be driven by the contract and the organisational blueprint. If monitoring information can be compared with promises made in the contract and expectations speci®ed in policy statements, some form of evaluation can be automated.

114

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

However, with current AI technology, any attempts to automate fully such complex processes are bound to fail. Some compromises have to be made in the form of limiting the scope of possible partnerships, restricting the ¯exibility of the Virtual Market and constraining the type of services dealt with by the market. The result is the following approach for making the automation of the above processes viable: · De®nition of standard services and contracts used by the Virtual Markets and enterprises. · Creation of closed markets which are restricted to these standard services and contracts and where membership ensures a certain level of trust. · Availability of speci®c modular enactment infrastructures that are capable of enacting the services in accordance with the contracts. · Availability of direct mappings from contract promises to organisational resources and obligations as speci®ed in an organisational blueprint. · Availability of direct mappings of organisational policy statements into estimates that can be compared with monitoring information of the contracted service enactment. 1.2. Aim, context and implementation This paper examines the support needed for dynamically creating and managing contract-driven virtual enterprises. A Contract Framework that integrates the necessary concepts and components is described. These are used to implement the processes that two organisations have to go through in order to establish and enact a contractual relationship between them. The paper is based on ideas and work conducted in two separate initiatives: · Virtual Marketplace (ViMP) ± a set of tools to de®ne, create, operate and manage a ViMP for complex services and products [2]. The tools were developed at the Zurich IBM Research Laboratory in Switzerland. · CrossFlow ± a European research project in the 4th ESPRIT Framework (currently IST 5th Framework) that researched and developed cross-organisational work¯ow support for dynamic virtual enterprises based on the provision

and consumption of a service across organisational boundaries (http://www.cross¯ow.org). In the CrossFlow project, two real-world application scenarios were used to demonstrate the approach outlined in this paper and the components designed and built around it: an insurance scenario and a logistics scenario. 1.3. The structure of the paper Section 2 describes the Contract Framework that contains the concepts and components essential for creating virtual enterprises. Section 3 describes the requirements that contracts and contractual relationships place on Virtual Markets and CEIs. Section 4 describes Virtual Markets and the ViMP advanced Matchmaking Engine (MME) needed for contract matchmaking. Section 5 describes CEIs and the mapping between the contract and these infrastructures. Section 6 describes the phases of a virtual enterprise contract life cycle: · Contract establishment to create the speci®c contract that will de®ne the business relationship. · Dynamic Infrastructure Creation for enactment of the provided service and the linking of the components in both organisations together. · Enactment of the provided service including cross-organisational monitoring and control. · Post-enactment of the service includes service and contract termination and evaluation of the contractual relationship. Section 7 provides a summary, conclusions and possible directions for future work. 2. The Contract Framework Our approach to virtual enterprises views contracts as the central theme that runs throughout the enterprises' life cycle and touches upon all major aspects thereof. The framework provides contract-centred support for the di€erent phases of Virtual Enterprise Life Cycle and this section presents the set of contract-related concepts and components essential for the creation and management of virtual enterprises.

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

2.1. Services, contracts and a Contract Framework The framework relies on two basic concepts of services and contracts. A service is an activity performed by one organisation (the service provider) on behalf of another (the service consumer). A valid contract requires several things: agreement (o€er and acceptance), certainty (what exactly is o€ered), consideration (something of value to be given in return for a service or goods delivered), and an intention (to enter into a legally binding relationship) [3±5]. A service contract is a contract associated with a speci®c service, involving the description of the: · parties to the agreement; · service, including interface description, expected interactions, etc.; · promises concerning the service provision and consumption; · promises concerning additional services such as remuneration; · legal procedures in case of breach of contract and arbitration, for example. Contracts serve two main purposes: · Technical function: A description of the service one party provides and the other consumes, including the interactions necessary to provide and consume the service, the promises each party makes and its obligations. The functional speci®cation may also include procedures for exchange of information where contracts contain a long-term arrangement supporting multiple service provision/consumption cycles. · Legal function: A legal context anchoring the promises and obligations in the functional speci®cation. Arbitration bodies or the courts can use this in case disputes arise. This paper concentrates on the technical aspects of the contract and the manner in which it can be used to support the creation and management of virtual enterprises. The legal aspects of contracts [3] lie outside the scope of this paper. The Contract Framework integrates the set of contract-related concepts and components that are necessary for the creation and management of virtual enterprises. As contracts play a pivotal role in the life cycle of a business relationship, the framework is strongly related to processes such as:

115

contract establishment, enactment infrastructure creation and con®guration, contract enactment, contract termination and contract evaluation.The Contract Framework includes the following concepts and components (Fig. 1): 1. Contract model and language: Speci®es a model underlying service contracts, describing the different aspects such contracts must contain, and a language that has a textual representation in an electronic form. 2. Contract Templates: Generic Templates for common service contracts that evolve over time in a speci®c market and that can be specialised for speci®c contract instances. 3. Internal Enactment Speci®cation Template (IEST): A blueprint specifying how a contract is to be enacted in a speci®c organisation. 4. Contract Matchmaking Templates: The translation of a CT into the Contract Advertisement and Contract Search Templates that can be used by the MME of a speci®c market to ®nd matching service providers and consumers. Other contract-related components are also possible, for example, a veri®cation test-bed derived from a combination of the monitoring information and the promises speci®ed in the contract. Such components are outside the scope of this paper. 2.2. The contract model and language A contract model provides the conceptual structure necessary to describe the tight collaboration of service consumer and provider in a virtual enterprise, revolving around the provision and consumption of a service. Di€erent contract models speci®c to the application domain they are expected to serve can be developed. The CrossFlow contract model [6] speci®ed a generic model that is biased towards the enactment infrastructure that was used in the CrossFlow project, namely, Work¯ow Management Systems (WfMSs) and their current shortcomings. The CrossFlow model includes concepts for representing the structure of the provided service process described by the contract, high-level concepts for monitoring and controlling this

116

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Fig. 1. Elements of the Contract Framework ± the contract model and language, a Contract Template (CT), the related Internal Enactment Speci®cation (IES) Templates of each organisation, and the related Matchmaking Templates.

process in a cross-organisational context, and concepts for ¯exible use of contracts. A modular contract structure has been chosen to allow easy adaptation and extension to speci®c environments. The overall contract model consists of several parts [6]: · The concept model de®nes the concepts that are used in the contract, creating the terminology with which the contract issues can be speci®ed. This is similar to the terminology statements in the ®rst section of a regular contract and ultimately has to relate to the language of the Virtual Market. · The process model describes the internal structure (schedule) of the work¯ow process implementing the service at the contract level. The process schedule is composed of process elements, i.e., the individual activities and transitions. · The enactment model provides concepts to represent the advanced co-operative support that is o€ered during service enactment. Co-operative enactment support can be composed of a number of elementary services, like service execution monitoring, service execution control,

remuneration support, and authentication support. · The usage model de®nes the manner in which the contract can be used. It describes the di€erent usage possibilities of the contract and their conditions allowing, for example, short-term contracts for a single enactment cycle and longterm contracts for multiple ones. · The natural language description is meant for human reading. The above can be generalised to encompass other enactment infrastructures, other notions of a service/process, multi-party contracts, and a more comprehensive notion of guarantees and their enactment or checking. For easy speci®cation and communication of contracts, a contract speci®cation language is required that provides a textual format for the contract model. Choosing a standard meta-language enhances the general acceptance of the contract language and helps the interoperability issues. In the CrossFlow project, XML has been chosen as the basis for this language. For a detailed exposition of the CrossFlow contract language, see [7].

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

2.3. Contract Templates Contracts vary enormously in their size, content and complexity. In order to expedite the construction, consideration and processing of contracts, common contract forms often evolve and become a Standard Form Contract [3], also referred to as a CT [8]. The term `standard' in this context may mean several things: that it is agreed among all participants in some restricted domain (possibly formalised through some standardisation body) or that it could be a bilateral agreement used between two speci®c organisations. Examples of CTs are: sales and order contracts; car and house sale contracts, airline tickets, bank loans and mortgage contracts, marriage and divorce contracts, employment contracts, club membership contracts, and product order forms. The New Jersey Law Revision Commission, in their report relating to Standard Form Contracts [9] asserts that most contracts are in fact based on CTs. CTs are characterised by several features: · The pre-agreed content and format of a CT: This makes it easy to represent and refer to the contract in a formal manner without having to resort to natural language processing, and therefore CTs provide an ideal starting point for automating certain parts of the contract life cycle. · The placeholders or ®elds for contract instance values: The CT can be seen as a skeleton with ®elds which must be ®lled according to the speci®c circumstances of the desired relationship between the parties. CTs can thus be seen as generic forms or templates, tailorable to the circumstances of each contract instance. · The take it or leave it basis on which CTs are often o€ered eliminates the need to negotiate contracts individually where common transactions in a well-established marketplace are concerned. · Di€erent granularity of choice and specialisation: CTs can o€er a range of options with increasing complexity:  monolithic CTs where values are inserted in pre-®xed positions (parameters);  CTs where certain sections can be included or removed;

117

 clause-based CTs where contracts can be composed of clauses, similar to language constructs. The CrossFlow project concentrated on monolithic CTs with minimal ¯exibility allowing the inclusion of certain clauses. This restricts the choice of business relationships between organisations to a ®xed and rigid set of existing CTs in any marketplace. Where variations in contracts are needed, it is necessary to relax the constraint imposed on CTs and allow their composition from units of smaller granularity such as clauses [10]. 2.4. A Contract Template example A CT is similar to a regular contract with ®elds that need to be ®lled in the course of the contract negotiation. Open ®elds can be placeholders for both business and technical parameters of the contract. In the motor claims insurance scenario an insurance company commissions the examination of damaged cars to a loss adjustment company. A loss adjustment CT has a ®eld for the location of the car to be assessed, for example, described in the form of a post-code, and a ®eld for the price for the assessment. Also the CT has ®elds for the communication interfaces that service provider and consumer expose to their business partner, for example, in the form of URLs. 2.5. Internal Enactment Speci®cation Templates To create the necessary enactment environment dynamically and in an automated manner, it is necessary to pre-prepare a blueprint for contract enactment for each organisation. The Internal Enactment Speci®cation (IES) de®nes the way in which an organisation chooses to carry out a contract. It is the translation of the contract into an enactment environment that consists of: processes, people, IT systems, any other organisational resources, their obligations and the interactions they have to engage in to deliver the promises made in the contract. To create the necessary enactment environment dynamically and in an automated manner, the IES is used together with the contract as input to a factory-like mechanism, the CEI Factory, capable

118

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

of creating speci®c service support environments. This is further discussed in Sections 5 and 6. An IEST is the internal equivalent of a CT ± a parameterised IES that can be specialised for the particular contract instance and the available resources at hand. 2.6. Contract matchmaking components In the normal procedure of obtaining agreement, one party makes an o€er and the other party responds with a countero€er. This process may repeat itself several times until an agreement is reached or the di€erences between the parties are found unbridgeable. Exploiting CTs' `take it or leave it' nature, the repeated o€er countero€er sequence is reduced to a de®nition of the terms that can be used in advertising and searching ± a data dictionary, contract advertisement and Contract Search. If contract matchmaking is to be carried out by an MME, there has to be considerable agreement as to the way the o€er and search queries are represented. In the formal world of matchmaking, it will be necessary to derive from a CT the elements that are going to be used in the matchmaking process. The data dictionary contains the minimal necessary agreement for contract matchmaking, as this de®nes the common vocabulary to de®ne what is being o€ered and what is being sought. In addition, in order to speed up the process of advertising and searching for matching business partners, it is possible to create: · Contract Advertisement Template: Contains (in a parameterised way, relating to the ®elds of the CT) the promises made to the consumer and the demands from the consumer. · Contract Search Template: Contains (in a parameterised way, relating to the ®elds of the CT) the promises made to the provider and the demands from the provider. Thus, the parties start from a common point ± the CT, from which a contract advertisement and a Contract Search are derived and then used, in the contract matchmaking process. In the case of CT matchmaking, most of the complexity associated with reaching an agreement can be swept aside, if both parties start by agreeing on the CT which will

be used as the basis of their service provisionconsumption arrangement. This approach has a drawback in limiting potential agreements to those already de®ned in existing CTs. Such a drawback is eliminated, however, where a complete set of standard services and contracts has been de®ned. The following sections present matchmaking and the issues surrounding the processes and agreement necessary to create a service Virtual Market in detail. 3. Contractual relationships and their requirements The need to dynamically establish and maintain contractual relationships places requirements on the Virtual Markets (used to ®nd business partners) and on the enactment infrastructure (needed to enact the contracted service). 3.1. Requirements placed on Virtual Markets Generally, the requirements from the Virtual Market concern the control of the market or its closeness/openness. This is achieved by restricting the provider's and/or consumer's participation and access to the market, and by agreeing on the services being marketed, the way they are described, the languages used to describe them and the matchmaking procedure and policy. Virtual enterprises and the contractual relationships, which they entail, pose the following requirements on the matchmaking process: · The ability of both consumers and providers to select each other: consumers as well as providers should be able to describe what they o€er as well as what they demand of each other. This implies a symmetric model of matchmaking [2]. Di€erent forms of a market can be provided depending on whether the providers' advertisements or the consumers' searches are made permanent or kept transient. This has an e€ect on what triggers the matchmaking process. · A language suciently powerful to describe the o€ers and requirements of both consumers and providers. The language must support the complexity of service contracts and the selection criteria of both parties. This means:

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

 complex service and contract parameters;  ability to express complex demands from the other party. More speci®cally, the parameters of a contract language must be mappable to the property language of the available MME. How other parts of the contract can be mapped onto the MME property and constraint language will be described later. · Tools to de®ne services, advertise and search for them in the market are necessary to make use of the market more straightforward. · Ability to update o€ers in the following manner: withdraw and re-advertise easily ± by using the provided tools [2]. Use dynamic values ± a special feature of the MME to provide the values of some service description properties at the point of matchmaking rather than when being advertised. This supports properties that change with time or are dependent on the speci®c properties of the business partners. · Support the staged exchange of information and negotiations. 3.2. Requirements placed on Contract Enactment Infrastructures The CEI is the combination of organisational resources (people, knowledge, IT systems) that must support the business processes that provides and consumes the contracted service. A CEI should have (some or all of) the following: · Integration capability: The CEI must be able to aggregate di€erent backend/legacy systems, IT applications and processes into a coherent whole. This may entail joining the core service provision system with administrative systems dealing with issues such as remuneration. · Provide a level of independence from the speci®c details of the CEI or parts thereof, abstracting from its speci®c details. · Monitoring capability: Information about the progress of the contracted service should be available where necessary to support:  auditing;  decision-making and the possible subsequent issuing of control operations;

·

· ·

·

119

 evaluation of the ecacy of the contract, the selection of the partner, the organisational policy with respect to the contract enactment, etc. Audit trail capability: Veri®able monitoring information must be logged so that it can serve as evidence when disputes arise over the provision and consumption of a service. Control capability: Facilitating the termination, temporary halting and resumption of the service and the ability to roll back and compensate. Security facilities: Allowing one organisation to use the resources of the other while protecting the autonomy and integrity of both organisations. Translation capability: Facilitate the hiding of internal processes and information from the outside where necessary. Translation may also be necessary between the languages used by the di€erent organisations to describe and communicate about the contracted service.

4. Virtual service markets and contract matchmaking Section 1 described the need for having Virtual Markets as an integral part of the virtual enterprise environment while Section 3 described the requirements that contractual relationships place on such a market. This section describes some of the elements and processes needed to create and run virtual service markets where the business partners of a potential virtual enterprise can ®nd each other. 4.1. Virtual service markets A virtual service market requires support for the following processes: · Service and contract de®nition: Deciding what services and contracts the market will trade, how they are described and what language is used for matchmaking (this depends on the MME and will be explained later). · Set-up and registration: Deciding on the structure of the market components and whether the market is centralised or distributed, etc.

120

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Depending on how `open' or `closed' a market is, providers and consumers will then have to register with the market operators. · Population: Providers and/or consumers placing service contract advertisements/searches into the market. · Day-to-day operations:  searching for compatible business partners;  advertising new services or modifying existing advertisements. Depending on the type of the market, the market may or may not participate in the subsequent interactions between the consumer and provider. These interactions include: · Noti®cation and exchange of information: Notifying the other party of the intention to reach an agreement. Where the information provided for the matchmaking process was insucient to reach an agreement, further information may be exchanged. · Reaching an agreement: Settling on the choices acceptable to both parties. · Signing a contract: Digitally signing a contract and depositing it at a digital notary [11]. · Providing and consuming the service: Some markets mediate in the consumption of the service (as brokers, for example), while in others the role of the market ends with the contract establishment phase. In addition to the above processes, the market will also require market management, maintenance and version control activities, but this is outside the scope of this paper. Creating a virtual service market requires agreement on the services and contracts that are acceptable to the market, their de®nition and description. Further agreement is necessary in all the above processes concerning registration and participation rules and procedures, etc. Reaching agreement on these issues is not a trivial task and is often loaded with apparently far-reaching political and business implications. 4.1.1. Market service and contract de®nition Reaching agreement on how to de®ne common market services can be a complicated matter even when selling services that are considered commodities. The stages that the market operators and

participants have to go through are brie¯y described in the following. Agreement on the services and the service contracts of the market has to lead to the selection of the services that are to be dealt with in the market. Furthermore, the CTs that are to be associated with these services are to be agreed upon. Agreement must also be reached on how the selected services and associated CTs are to be described in terms of abstract process structures, process parameters, quality of service guarantees and primitives to monitor and control the enactment of services. Furthermore, the standardisation of services in the context of speci®c application domains, like the logistics industry or the insurance industry is required. This helps ensure that the participants in the market use the same language to describe the services. Agreement on the market MME and its matchmaking language is essential as the o€ers and demands of each party are to be expressed in this language. The topic of matchmaking and MMEs is described in the following sections. 4.1.2. Creating the matchmaking components The components surrounding the matchmaking process consist of the data dictionary, the advertisement and the Search Templates. The market's data dictionary holds the de®nition of the properties of the services, the CTs and the consumer and provider organisations, necessary to describe all the relevant aspects of a service agreement. The data dictionary may express these properties in its own language or in that of the MME. The requirements described in Section 3 indicated that both the provider and the consumer have to provide information about what they o€er. The link between the data dictionary properties and the CT (which encompasses a standard service description) is as follows: · The names of the services and of the CTs must be unique and agreed on. · The ®elds to be ®lled in must be named and the type of information associated with them de®ned. Fig. 2 shows the process of deriving the data dictionary properties:

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

121

Fig. 2. Combining CT related properties with additional service-related properties to derive consumer and provider properties for the data dictionary.

1. Agree on (one or more) CT in a speci®c application domain. 2. Extract the necessary information from the CT for the consumer and provider sides. This takes the form of a provider and a consumer property list. This list is de®ned in the data dictionary. 3. Add any local properties which may be needed for the selection of a business partner but which may not be part of the information necessary for ®lling the CT. This list is added to the properties already de®ned in the data dictionary. For example, the choice of a business partner may depend on the physical location of their warehouses, but this may not be part of the information necessary for the CT. Similarly, credit information may be used to select the partner but will not be part of the contract. Once the data dictionary contains the de®nition of the property list relevant for a service CT, it is possible to construct the advertising and Search Templates. The advertising/Search Template (Fig. 3) is the de®nition of the provider service contract advertisement/search (in the language of the chosen MME) containing:

· The list of properties (related to the service contract ®elds) to be used in the advertisement/ search with the values of the properties left unspeci®ed. These will be ®lled in as relevant for each advertisement/search instance and will depend on the way the service provision is implemented (resource speci®c details: maximum capacity, QoS guarantees, etc.) and business/ management decisions with respect to cost, guarantees, etc. · The demands the provider/consumer places on the consumer/provider. This will be expressed as an MME constraint expression or script and will re¯ect any business-related demands, for example, the ability of the consumer to pay, manner of payment, or the ability of the provider to deliver a certain QoS guarantee, etc. A way of looking at an agreement is to de®ne what constitutes a compatible contract o€er and Contract Search. In other words, when can the consumer and provider be con®dent that what they promise matches what they demand of each other? The process of deriving the advertising and Search Templates is shown in Fig. 3:

122

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Fig. 3. Exploiting the CT-related properties in the data dictionary to derive advertisement and Search Templates for matchmaking.

1. Use the property lists to build advertising and Search Templates. 2. Use this information for advertising and searching for matching business partners. 3. A successful matchmaking process results in one or more o€ers handed to the consumer. 4. Agreement between the two organisations, which can then be signed if necessary.

4.1.3. Market advertisement and search for compatible partners Once the advertising and Search Templates are in place, the following sequence can take place (Fig. 4): 1. The provider ®lls the relevant advertising template with the values speci®c to the service and contract o€er at hand.

Fig. 4. Filling the advertisement/Search Templates with service-speci®c values and forwarding them to the Matchmaking Engine (MME).

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

123

2. The ®lled template is sent to the market MME. 3. The consumer ®lls the relevant Search Template with the values speci®c to the service and contract needed. 4. The ®lled template is sent to the market MME as a search query. 5. The MME searches through the previously advertised o€ers to ®nd one or more matching ones. 6. The matching o€ers are returned to the consumer. The MME that facilitates the advertisement and search for compatible partners will be described in the following section.

accept it, it may allocate and con®gure resources for the enactment. 4. The acceptance together with relevant information is sent back to the consumer. 5. The consumer is now in a position to create its relevant enactment infrastructure and link the two organisations. The process of contract signing can be integrated into the above sequence where necessary. Such a process may be aided by an electronic notary service acting on behalf of a trusted third party which may take part in the signing of a contract and in storing it [12].

4.1.4. Noti®cation and agreement reaching The noti®cation, exchange of information, and agreement reaching protocol are described in a high-level manner in the following; di€erent ¯avours of this exchange will depend on the speci®c circumstances (Fig. 5): 1. The consumer selects the o€er deemed most appropriate from the returned set of matching offers. 2. A noti®cation accompanied by the information necessary for the provider to enter a contract is sent to the provider. 3. The provider can now make a decision whether to accept the countero€er. Having decided to

4.2. The ViMP advanced Matchmaking Engine An MME is the point where advertisements are directed to and stored on a permanent basis, and where search queries are sent. The MME searches for existing o€ers that match each received search query. A number of existing MMEs are used to support the electronic advertising and searching of goods and services [13]). Examples are ViMP [2], Ariba [http://www.ariba.com], HP e-speak or MIT's Kasbah prototype [14]. An elaborated categorisation of electronic marketplace systems is provided in [15].

Fig. 5. The processes of noti®cation, exchange of information and reaching agreement.

124

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

The MME used in the CrossFlow project is the ViMP MME ± an extension of the ANSAware/ CORBA trading service [16,17]. It is part of the ViMP set of tools for the creation, management and maintenance of Virtual Markets [2]. It is an o€er ± countero€er mechanism that in its present form does not facilitate negotiations. The following sections introduce the ViMP MME and show how it addresses the requirements that contractual relationships place on the matchmaking process as stated in Section 3. 4.2.1. ViMP symmetric matchmaking The requirement stated in Section 3 of allowing both consumers and providers to select each other required a change in the basic functionality of the CORBA Trading Service by making the matchmaking process symmetric [7]. The ViMP MME supports a symmetric matchmaking process as shown in Fig. 6. In the bidirectional matchmaking process, both customers and providers describe what they o€er and require of each other. The change to symmetric matchmaking necessitates the modi®cation of the property-constraint language. Whereas in the CORBA trader, properties were by default service-provider properties, in the symmetric case it is necessary to distinguish between the properties of the consumer and the provider. In the advanced MME each property is therefore preceded by an indication of its origin: · provider side properties are pre®xed with `provider.'; · consumer side properties are pre®xed with `consumer.'. For example, provider.ItemPrice or consumer.Number_of_Items. 4.2.2. ViMP property-constraint extensions As described in Section 3, the matchmaking language has to be suciently powerful to express

the type of properties that organisations are looking for when selecting a partner. The descriptions created with this language are capable of expressing complex attributes such as delivery dates with price tags attached and associated QoS parameters, etc. Date: The CORBA property-constraint language supports ®ve built-in types: integer, ¯oat, string, char and Boolean. Special data representing a date with a number of related arithmetic operations have been added. Records: Nested sequences are neither supported in the CORBA version nor in the extended MME. However, it was decided to extend the language by introducing records as a means of creating compound structures. Sequences of records and records containing sequences are possible. Records provide an easy way to aggregate a number of attributes that belong to a single entity. This together with the notion of an array is particularly useful when addressing a group of people or services, or any entities with multiple attributes. Indexable sequences: Where the number of similar items which have to be dealt with by the MME is not known in advance, it is necessary to introduce indexable sequences. Sequences can be constructed from all basic types as well as from records. Elements of sequences can be referred to using their index in the sequence. This together with a FOR loop construct will enable a variable number of items to be dealt with. ViMP constraint scripts: The language constructs evaluated in the context of contract matchmaking are: · While, Do-while and For-loop constructs; · IF-THEN-ELSE constructs; · temporary variables

Fig. 6. Symmetric matchmaking process in the ViMP Matchmaking Engine (MME).

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

The scripts created with this language are capable of expressing complex demands and express tradeo€ between QoS, price, controllability, etc. 5. Organisations and contract enactment infrastructures In dynamic markets, where the need to ®nd a partner arises from their internal business process enactment, there is a need to quickly and eciently set up the business relationship between the compatible organisations [18]. Having deferred the establishment of a contractual relationship to the point where the relationship is imminently needed, it is necessary to create the appropriate infrastructures in the partner organisations dynamically. Furthermore, it is expected that an organisation will want to provide the same type of a service to more than one business partner. It is therefore necessary to be able to create these multiple environments dynamically and in an automated manner. This section brings together the elements necessary to create the CEIs in the consumer and provider organisations dynamically, based on a previously signed contract: di€erent available CEIs, IESTs and CEI Factories. A speci®c example of how a CEI is generated from a previously agreed contract and IES from the CrossFlow project is also given.

125

5.1. Contract Enactment Infrastructures In many cases, the contracted service provision is not supported by a single system within an organisation. Similarly, the consumption of the service in the consumer organisation may also be carried out by multiple systems and applications. This may be the result of having legacy systems or because the complexity and variety of provided and consumed services exceeds the capability of a single system. We refer to the systems providing core services such as service-providing and serviceusing systems (Fig. 7). In addition, there may be administrative systems (such as re-sourcing, remuneration or auditing applications). Thus, in order to provide and consume a service outside the organisational boundary, it is usually necessary to integrate as well as front-end several internal systems. The part that aggregates these systems and acts as a front end to them is referred to as an Integration Facilitator (IF) [19]. The IF has multiple roles. It encapsulates the functionality of the services and abstracts from the speci®c details of the enactment infrastructure. It directs messages passing between the two organisations to the appropriate system. The messages will have to be checked against the contract and the progress of the contracted service to see if everything is going according to the agreement. To protect the business partners, gateways have to reside at the organisational boundary to check and translate the

Fig. 7. The Integration Facilitator (IF) aggregates the di€erent service and administrative systems (including legacy systems), providing an external interface for service provision and consumption.

126

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

passing interactions. All of these have to be integrated into a coherent whole that can be provided and consumed outside the organisation by the IF. The results of the integration of the service-using/ providing system(s) and the administrative system(s) are the CEI of the respective organisations. Service-using, service-providing and administrative systems can vary substantially depending on the contracted service and the existing infrastructure found in the consumer and provider organisations. Di€erent integration mechanisms are therefore required for di€erent environments. One approach to the service-using and serviceproviding systems is based on the business process paradigm that views those services as a set of activities to be executed in a particular pre-de®ned order or a work¯ow. The process paradigm is supported by specialised WfMSs such as IBM's MQSeries Work¯ow (www.software.ibm.com/ts/ mqseries/work¯ow/), Sta€ware (www.sta€ware. com/) and HP Changengine. It is also supported by Enterprise Resource Planning Systems (ERPs) such as SAP's R3 (www.sap.com) which are largely aimed at supporting a single organisation. Extricity's `Alliance' system facilitates a work¯ow that involves multiple participating organisations and similarly, Microsoft's BizTalk server provides a graphical editor to de®ne a work¯ow that spans multiple organisations. Having introduced a number of CEIs, it is now possible to discuss how a contract is mapped onto the speci®c CEI of an organisation. 5.2. Mapping a contract to a Contract Enactment Infrastructure The complexity of CEIs is such that automating the mapping of a speci®c contract onto the available organisational resources is beyond the means of current technology and knowledge. Our approach to this problem is to pre-prepare one or more blueprints for contract enactment for each organisation and CT, using it with the appropriate contract-speci®c values obtained from the contract establishment phase. An IES de®nes the way in which an organisation chooses to carry out a contract ± a blueprint for contract enactment [20]. It is the internal

counterpart of the contract, generated in the context of the organisation and its internal policy. It can be regarded as the translation of the contract into an enactment environment that consists of the processes, people, IT systems and other organisational resources, their obligations and the interactions they have to engage in to deliver the promises made in the contract. The IES is used together with the contract as input to a factory-like mechanism, the CEI Factory, discussed in the following section. No two organisations are likely to have the same processes, people and IT infrastructure and therefore each IES is organisation speci®c. It is often advantageous to have a number of di€erent allocation and con®guration schemes that cater for a variety of resources and cost constraints that apply at the time that the set-up is to be created. Di€erent enactment strategies may be applicable in di€erent circumstances (such as a di€erent business partner, di€erent resource constraints). Therefore, for each service contract that an organisation is capable of consuming or providing, there will be one or more IESs associated with it. Changes in the organisation do not have to be re¯ected in the contracts that are provided or consumed by an organisation, as long as a new IES, mapping the contract into the available resources, can be constructed. Likewise, the same service can be associated with di€erent CTs as long as there is an IEST containing a mapping between the CTs and the service. An IEST is the internal equivalent of a CT ± a parameterised IES that can be specialised for the particular contract instance and the available resources at hand. 5.3. The Contract Enactment Infrastructure Factory The Contract Enactment Infrastructure Factory or CEI Factory for short is the component responsible for creating the CEI that will act to produce or consume a speci®c contracted service. CEI Factories of the service consumer and service provider build the contract-speci®c enactment infrastructure separately for the service provider and service consumer [21,22]. They do this by combining two components:

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

· the contract containing the speci®c details of external expectations; · the IES ®lled with details from the contract and based on information about currently available resources. The creation of the CEI depends on the granularity of the language used to construct IESTs and the available components, and can be done in several ways (described in increasing order of complexity): · selection of an existing parameterised monolithic module; · con®guration and assemblage of existing parameterised modules; · generation (of code) of one or more modules. 5.4. Creating the Contract Enactment Infrastructure Depending on whether early or late resource allocation/binding strategy is chosen, the process of creating the CEI can take place at: · Contract advertising phase: if each instance of the service is advertised as a single advertisement, this ensures that every contract o€ered has the necessary resources to satisfy it. · Exchange of information/agreement reaching phase: while ®lling in the contract details, the resources are allocated. This is potentially wasteful as the contract may never be signed, but ensures that the contract is backed up when signed by the ability to deliver the promises. · Contract signing: the allocation of resources at this stage ensures the contract signing is backed up by the ability to deliver. This also ensures a speedy initiation of the contracted service. · Initial service consumption request: ensures that the resources are allocated as late as possible but risks not having the resources available at that point of time unless some overall resource allocation strategy is applied. The decision as to when to allocate resources relates to an early or late resource allocation/ binding strategy. Early allocation of resources involves the locking of the resources for a period until they are actually needed. In fact, where options exist in the processes executed by the consumer organisation, the resources may be allocated

127

but never used. Late binding, on the other hand, assures that there is no wasted allocation of resources. However, when an organisation comes to allocate the resources needed for a speci®c contract enactment, the resources may not be available. In some cases, a consumer organisation will be willing to pay more for guaranteed delivery of service. Thus, much of the early versus late binding issue concerns promises made and the cost associated with these demands. Fig. 8 shows a typical sequence of events when creating the CEI on the provider side (the same sequence is applicable to the consumer side): 1. The contract and IES are fed to the CEI Factory. 2. The CEI Factory processes the input and determines the modules necessary for creating the IF and the con®guration parameters for the service-providing and administrative systems. 3. The CEI Factory then con®gures the above components, creating the CEI and the external service provision interface. 4. The relevant information about the interfaces is handed back to the CEI Factory. This can be handed to the other organisation for ultimately linking the two infrastructures. 5.5. The CrossFlow Contract Enactment Infrastructure The CrossFlow project focuses on services that match the business process paradigm of the provider organisation carrying out a service, which is part of the consumer business process, on its behalf. CrossFlow uses the MQSeries Work¯ow System as its service-using and service-providing system. A speci®c example of a possible CEI is the CrossFlow CRAFT [19]. CRAFT is the framework that provides an approach for building enactment infrastructures for organisation±spanning relationships. A single instance of a CRAFT, called the IF, corresponds to one service contract between two organisations (Fig. 9). CRAFT is a framework based on an extendible set of reusable data-driven building blocks and assembly rules. The CEI Factory in CrossFlow con®gures readymade building blocks into a contract-speci®c CEI

128

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Fig. 8. Creating the Contract Enactment Infrastructure (CEI).

Fig. 9. The CrossFlow Integration Facilitator (IF) provides contract-speci®c aggregation of the various service and administrative systems (including legacy systems), providing an external interface for service provision and consumption.

and is therefore called a Con®guration Manager [20]. The IF can aggregate the functionality of internal core and administrative services into a coherent service that can be o€ered or con-

sumed externally. In CrossFlow, the IF integrates the Work¯ow Management System with monitoring, control and transaction management capability. The IF supports the monitoring facilities that provide the consumer with an

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

abstract view of the progress of the service being enacted on their behalf ± a view de®ned in the contract. Similarly, there is a need to allow the consumer a limited level of control over a process that takes place inside its autonomous partner organisation. A Work¯ow Module (WM) acts as an interface layer that abstracts from the details of the speci®c WfMSs, which in the case of CrossFlow is the MQSeries Work¯ow System [23]. Both parties usually require a certain degree of hiding of the internal details and their internal processes are therefore represented externally with reduced granularity. Correspondingly, the IF translates interactions to and from the organisation in all relevant aspects such as data formats, naming conventions and others. To help preserve the autonomy and integrity of each organisation, the IF limits the access to services, i.e., the usage of services of an organisation from outside as well as the usage of outside services from within. This is carried out by Proxy-Gateways (PG) which enforce the appropriate security policy. When services cross organisational boundaries, the internal model and means for measuring resource usage, costing, billing and paying has to be modi®ed and sometimes extended. The need to monitor and supervise the execution and performance of services becomes crucial when organisations make contractual promises for which they are liable. Transaction management capability may also be necessary in some cases. In CrossFlow, all of this additional functionality is provided by an extensible set of Co-operative Support Services (CSS). The infrastructure can also be used to provide administration functionality such as monitoring an organisation's interaction with its environment and triggering the billing and payment of service usage, either through existing administrative systems or as parts of the IF. Up to this point, we have introduced the Contract Framework and a number of components and processes needed to build and manage virtual enterprises. The following section puts it all together and shows how the ideas and components can be used to support the Virtual Enterprise Life Cycle.

129

6. Virtual Enterprise Life Cycle The Virtual Enterprise Life Cycle is a description of the stages two organisations have to go through in order to establish, set up, enact, maintain and manage the desired business relationship between them [21,22]. 6.1. Service contract establishment The process of contract establishment exploits the Contract Framework and the Virtual Market facilities to reach an agreement between the two organisations. A typical sequence of events that leads to the establishment of a contractual relationship between the provider and consumer organisations is as follows (Fig. 10): 1. When the provider WfMS is ready to receive requests for enactment of a process on behalf of a consumer organisation, its manager noti®es its Contract Manager of its readiness to provide instances of this process. 2. The Contract Manager selects a pre-existing CT (from the Service Contract Repository) that describes the service and its associated QoS guarantees, work schedule, monitoring and control points as provided by the service, etc. Appropriate values for these service guarantees including the cost of the service must then be determined. These will be decided according to the capabilities of the enactment infrastructure, the resources that the provider is willing to assign to the enactment, and the price associated with the resources. In addition, the requirements that the provider places on the consumer within the terms of the CT are also speci®ed. The service description and the demands are translated into the property and constraint language of the matchmaking facility. 3. The service-o€er advertisement is then sent to the chosen marketplace MME. In a competitive market, several provider organisations will advertise the same service with the same associated service contract but with di€erent values describing QoS, scheduling and other guarantees, and the price of the service.

130

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Fig. 10. The contract establishment process, resulting in a ®lled Contract Template (CT).

4. At the same time or sometimes later, a consumer business process is initiated. 5. It may require an external service; it then provides the type and some parameters of the service to the Contract Establishment Manager. 6. The relevant information concerning the desired service and its contract (a€ordable pricing, desired QoS, where to search, etc.) is fetched from the Service Contract Repository. 7. The search query is then sent to the chosen marketplace MME. The MME searches through its repository of advertised service offers, looking for matching o€ers and searches. 8. The matchmaking process takes place. 9. If successful, one or more matching service offers are returned to the consumer organisation. The consumer Contract Establishment Manager selects one of the service o€ers. 10. The consumer organisation noti®es the selected service provider of its desire to enter a business partnership with it. 11. The provider decides whether to accept the o€er (i.e., in legal terms, the countero€er) from the consumer. This can be regarded as an implicit contract. If accepted, the resources to be allo-

cated for the outsourcing are determined. The provider's acceptance of the consumer o€er together with any con®guration information needed by the consumer to contact the provider is given to the consumer. The consumer can now con®gure the necessary components on its side and link them to their counterparts on the provider side. The agreement contained in the contract can be digitally signed, but the topic of contract signing is outside the scope of this paper. 6.2. Dynamic Enactment Infrastructure set-up Once a virtual enterprise has been de®ned in an electronic service contract, its details are used for the dynamic construction of an infrastructure for the enactment of the promised service as described in Section 5. CEI Factories of the service consumer and service provider select the appropriate modules and parameterise them to obtain the desired contract-speci®c behaviour in each organisation. A typical sequence of events that leads to the creation of a CEI is as follows (Fig. 11):

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

131

Fig. 11. Creating the Contract Enactment Infrastructure (CEI).

1. After choosing the provider, the consumer Contract Establishment Manager noti®es its counterpart of the selection, at the same time providing it with information about the consumer and their requirements. This exchange results in a contract. 2. If accepted by the provider, the related contract is combined with the relevant IES and fed to the enactment CEI Factory. 3. The enactment CEI Factory uses the contract and IES to generate the contract-speci®c enactment infrastructure. This will include whatever service-providing and administrative systems are necessary, aggregated by the IF. 4. The relevant details of the newly constructed enactment infrastructure and IF are sent back to the consumer.

5. The consumer takes the contract and its own IES and feeds them to its enactment CEI Factory. 6. The enactment CEI Factory generates the contract-speci®c enactment infrastructure. 7. Using the information about the provider, the two newly generated infrastructures can now be linked together and are ready to be activated. 6.3. Contract enactment The enactment of the contract through the service provision/consumption requires a complex co-operation between all CrossFlow modules and the commercial platform below them. After the enactment infrastructure has been set up, the provider service can be started. For this purpose,

132

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Integration Facilitator

Integration Facilitator

Fig. 12. Dynamic con®guration of the contract-speci®c Contract Enactment Infrastructure.

the various modules communicate with each other as illustrated in Fig. 12 to provide the functionality as well as any monitoring and control capability speci®ed in the contract. Speci®c CSS modules may need to access dedicated back end systems (BES) to perform their tasks. Such BESs may consist of internal logistic services, accounting and other management systems or any legacy systems which provide parts of the core or the administrative functionality needed to support an externally provided service. A typical sequence of events taking place during enactment is as follows (Fig. 12): 1. The provider service-providing system generates a monitoring message after the completion of one of the activities speci®ed as its task. This is aggregated with other relevant information in the IF. 2. It may be translated if necessary and then sent to the consumer side if speci®ed as a monitored event in the contract. (A pull mode of operation is also possible, depending on the contract.) 3. The consumer IF translates the message and forwards it to the Service Consuming System and any other interested entities. 4. A decision to modify the service is taken and a command is issued from the consumer side. 5. The provider IF side will check if the operation is allowed at this stage of the service and contract enactment. If it is, the IF will issue the

command to the service-providing system, possibly notifying an administrative Back End System, in case some administrative action has to be taken. 6.4. Contract termination and evaluation Once the service terminates, the relevant parts will check if all the contractual obligations have been ful®lled. If all has been delivered as promised, the IF will terminate the service. If no more service enactment cycles are allowed within this contract, the two IF may then signal each other and terminate themselves. Contract evaluation may take place continuously throughout the service enactment phase. Additional checks and measurement may be conducted at contract termination. The results can be compared with the contract and with the expectations of the organisation. Any noti®cations and reports for management can then be generated and corrective measures be taken. 7. Implementation, conclusions and future work Two real-world application scenarios were used in the CrossFlow project to demonstrate the approach outlined in this paper: an insurance scenario and a logistics scenario.

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

The insurance scenario [24] illustrates the relationship between an insurance company and the external loss adjuster in the context of a motor insurance claim. The insurance company owns the overall claims management process, but some speci®c tasks relating to the inspection of the damaged vehicle, and the preparation of a report assessing the damage sustained and the estimated cost of repair are handled by an independent ®rm of loss adjusters on behalf of the insurer. An extension of this scenario illustrates how the insurer could use an electronic matchmaking environment to select from a panel of loss adjusters, using selection criteria that may vary from one claim incident to another. The logistics scenario [25] illustrates two business processes owned by di€erent organisations that are triggered by a single customer event, and need to be synchronised with each other at various stages. The customer event is the purchase of a mobile phone. This triggers a process in the telecommunications provider to set up the appropriate account and a process in a logistics company to deliver the purchased phone from the warehouse to the customer. The two processes need to synchronise because information relating to the individual phone being delivered needs to be passed from the logistics company to the telecommunications provider, and also because a change in customer circumstances can cause a necessary change in both processes. This paper examines the support needed for dynamically creating and managing contract-driven virtual enterprises. The proposed integrated framework and approach support the creation and management of dynamic business relationships with automated, ®ne-grained interaction between organisations, thereby ful®lling the ¯exibility and eciency requirements of modern e-business. The paper describes a number of novel aspects that go beyond current approaches: · The provision of a Contract Framework that integrates the concepts and entities necessary for the contract-centred support for the di€erent phases of Virtual Enterprise Life Cycle. The framework helps tie together the apparently di€erent issues and technologies in a co-

133

herent fashion. The framework makes it easier not only to apply the simpli®cations but also as a placeholder for relaxing them. The framework provides an approach that can be generalised as it indicates where dependencies in the di€erent issues should be taken into account while also de-coupling them from each other. This makes it easier to accommodate di€erent:  models of services (or products), CTs, contract languages;  markets and MMEs;  organisations, policies, resources and circumstances;  IESs, enactment con®guration managers and CEIs. · Virtual Market technology and advanced matchmaking facilities are provided to create service markets where matching business partners can ®nd each other dynamically and establish a contractual relationship. The use of CTs simpli®es the matchmaking and the enactment infrastructure set-up processes and therefore allows a more dynamic form of partnership establishment. · The use of pre-prepared IES(s) provides the mapping of the contract to the internal concepts, terminology, resources and infrastructure of each organisation. This can be used to dynamically generate the CEI(s) targeted to the requirements of a particular contract. The pre-generation of di€erent IESs allows dealing with di€erent organisational policies, di€erent circumstances, and di€erent CEIs. IESs support the de-coupling of organisational resources from contracts thereby allowing di€erent CTs to be associated with the same service. · The contract-speci®c infrastructure generated dynamically uses advanced CEI technology that allows business processes to cross organisational boundaries. In addition, the CEI is based on an advanced service model that regards the service as more than a single atomic step or black-box. This results in a powerful and ¯exible degree of service monitoring and control by the consumer, thereby providing a desirable feature in virtual enterprises where the contracted service is an integral part of

134

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

the business processes of the participating organisations. Perhaps the most telling conclusion drawn from the CrossFlow project where the architecture and approach described in this paper were used to create the systems in the insurance and logistics scenarios, is that `the devil is in the detail'! There is an inordinate amount of details to be covered in a service contract of any complexity. Naturally, the complexity of the contracts in¯uences the complexity of the enactment infrastructure necessary to ful®l the obligations in the contract. The approach described in this paper cannot do away with the need to have a contract agreed upon at some point. Nor can it do away with the need to translate that contract into the systems and activities that an organisation has to allocate and engage in. The approach shows how to break the problem into its constituent parts and how previous contracts, IESs and enactment infrastructures can be reused and modi®ed to suit new circumstances. It remains to be seen to what extent service speci®cations modelled on a contract model (and speci®ed in its related contract language) developed for one market can be generalised across multiple market domains. Reuse of contract structures is a way to achieve this goal. Further work is devoted to modularisation of contract structures and organising modules at various abstraction levels in a contract hierarchy. Further e€ort is also needed in the area of contract speci®cation languages that can be used in the matchmaking process and be exploited to generate the CEI dynamically. There is a price to pay for the dynamic and automated creation and management of virtual enterprises in terms of the inordinate amount of preparation and prior agreement and the restrictions that have to be made to achieve this. Further work in this area consists of stepwise relaxation of the restrictions and simpli®cations made in the context of the Contract Framework, particularly in the following areas: · The use of monolithic CTs should be extended to ®ner granularity clause-based templates.

· Similarly, IESs should use smaller and more con®gurable building blocks. The building block of the CEI should be made up of smaller modules relating to the clause-based CTs. · The matchmaking process and engines should be re-examined to see whether the strict typing advocated with current technology can be relaxed.

Acknowledgements All members of the CrossFlow project team are acknowledged for their contributions to the project.

References [1] W. Davidow, M. Malone, The Virtual Corporation, Harper Collins, New York, 1992. [2] Y. Ho€ner, C. Facciorusso, S. Field, A. Schade, Distribution issues in the design and implementation of a virtual marketplace, in: L. Kutvonen et al. (Eds.), Distributed Applications and Interoperable Systems, Kluwer Academic Publishers, Boston, MA, vol. 2, 1999, pp. 405±421. [3] A. Boundy, A Concise Business Guide to Contract Law, Gower, London, 1998. [4] J.C. Smith, The Law of Contract, Sweet & Maxwell, London, 1989. [5] Z. Milosevic, A. Berry, A. Bond, K. Raymond, Supporting business contracts in open distributed systems, in: Proc. Second Internat. Workshop on Services in Open Distributed Processing (SDNE95), Whistler, Canada, June 1995. [6] M. Koetsier, P. Grefen, J. Vonk, Contracts for crossorganizational work¯ow management, in: Proc. 1st Internat. Conf. on Electronic Commerce and Web Technologies, Greenwich, UK, 2000. [7] M. Koetsier P. Grefen, J. Vonk, The contract language, The CrossFlow Project Documentation. [8] Y. Ho€ner, A. Schade, Co-operation, contracts, contractual match-making and Binding, in: 2nd Internat. Enterprise Distributed Object Computing Workshop (EDOC `98), November 3±5, 1998, San-Diego, USA. [9] Draft ®nal report relating to ``Standard Form Contracts'', NJLRC ± New Jersey Law Revision Commission, John M. Cannel, Executive Director, New Jersey Law Revision Commission, 153 Halsey Street, Box 47016, Newark, NJ 07101, 1998, website: http://www.lawrev.state.nj.us. [10] D. Fossbrook, A.C. Laing, The A±Z of Contract Clauses, Sweet & Maxwell, London, 1996.

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136 [11] A. Runge, M. Gisler, H. Zimmerman, Relations of legal requirements on digital signatures in electronic commerce, in: Proc. Tenth Internat. Blech Conference, Blech, 1997. [12] F. Gri€el, M. Boger, H. Weinreich, W. Lamersdorf, M. Merz, Electronic contracting with cosmos how to establish, negotiate and execute electronic contracts on the internet, in: Proc. Second Internat. Enterprise Distributed Object Computing Workshop (EDOC '98), La Jolla, 1998. [13] Y. Bakos, A strategic analysis of electronic marketplaces, MIT Quarterly (September) (1991). [14] A. Chavez, P. Maes, Kasbah: an agent marketplace for buying and selling goods, in: Proc. First Internat. Conf. on the Practical Application of Intelligent Agents and Multiagent Technology, London, UK, April 1996. [15] B. Schmidt, Requirements for electronic markets architecture, Electronic Commerce 7 (1) (1997) 3±6. [16] Open Distributed Processing Reference Model, ISO/IEC 10476, ITU-T Recommendation X.900, 1995, Parts 1±3. [17] Object Management Group and X/Open, RFP5 Submission: CORBA Trading Object Service, Document orbos/ 96-05-6, May 10, 1996. [18] G. Alonso, U. Fiedler, C. Hagen, A. Lazcano, H. Schuldt, N. Weiler, WISE: business to business e-commerce, in: Proc. Ninth Internat. Workshop on Research Issues in Data Engineering Information Technology for Virtual Enterprises (RIDE-VE'99), Sydney, Australia, 1999. [19] H. Ludwig, Y. Ho€ner, CRAFT: a framework for integration facilitation in cross-organisational distributed systems. in: K. Kl ockner (Ed.), Proc. 9th EUROMICRO Workshop on Parallel and Distributed Processing (PDP'01), Mantova, Italy, February 7±9, 2001, IEEE Computer Society, Los Alamitos, 2001, pp. 317±326. [20] H. Ludwig, Y. Ho€ner, The role of contract and component semantics in dynamic E-contract enactment con®guration, in: Proc. 9th IFIP Workshop on Data Semantics (DS9), Hong Kong, 2001, pp. 26±40. [21] Y. Ho€ner, H. Ludwig, C. G ulc u, P. Grefen, Architecture for cross-organisational business processes, in: Proc. 2nd Internat. Workshop on Advanced Issues of E-commerce and Web-based Information Systems, WECWIS 2000, Milpitas, CA, USA, 2000. [22] P. Grefen, K. Aberer, Y. Ho€ner, H. Ludwig, CrossFlow: cross-organizational work¯ow management in dynamic virtual enterprises, International Journal of Computer Systems Science and Engineering 15 (5) (2000). [23] MQSeries Work¯ow Web Site, IBM Corporation, USA, www.software.ibm.com/ts/mqseries/work¯ow/. [24] S. Brown, M. Kellet, C. G ulc u, H. Ludwig, Y. Ho€ner, Insurance Demonstrator Report, The CrossFlow Project Documentation, D11b, http://www.cross¯ow.org, 2000. [25] W. Derks, M. Duitshof, Z. Damen, Logistics Demonstrator Report, The CrossFlow Project Documentation, D11d, http://www.cross¯ow.org, 2000.

135

Yigal Ho€ner works on the development of Virtual Market tools in the ViMP project at the e-business Solutions Group in IBM's Zurich Research Laboratory. He is the technical leader of the CrossFlow ESPRIT project, which deals with cross-organisational work¯ow management. His main expertise lies in the ®eld of distributed computing. Before joining IBM in 1996, Yigal worked on the development of distributed system architecture at the Advanced Networked Systems Architecture (ANSA) project in Cambridge, UK. He holds a B.Sc. in Computer Science and Cybernetics and a Ph.D. in Computer Science. Simon Field is the Manager of the ebusiness Solutions Group in IBM's Zurich Research Laboratory. He joined IBM in 1996, bringing with him over 10 years of experience of applying advanced technology in the context of the banking and insurance industries. Before joining IBM, he was the Principal Consultant with Experian Insurance Services, providing advanced information solutions to European insurance organisations. Simon started his career as an insurance underwriter with a major insurance company and was subsequently transferred to their IT division, going on to lead that company's research into expert systems. His interests include electronic markets, machine learning and the adoption of new technology by the insurance industry. Simon is an Associate of the Chartered Insurance Institute, and a Chartered Insurance Practitioner. Paul Grefen is currently an Associate Professor in the Information Systems Group of the Computer Science Department and a member of the Center for Telematics and Information Technology, both at the University of Twente. In 1992, he received his Ph.D. from the University of Twente on the subject of integrity control in parallel database systems. He was a Visiting Researcher at Stanford University in 1994. From 1995 to 1999, he was involved in the WIDE ESPRIT project, which focused on advanced database support for Work¯ow Management Systems. From 1998 to 2000, he was involved in the CrossFlow ESPRIT project, which aims at the development of cross-organisational work¯ow support for dynamic virtual enterprises. He has been a member of the programme committees of a number of international conferences and a regular reviewer for several international journals. He was the main editor of the book on the WIDE project and has published a book on work¯ow management. His current research interests include architectural design of complex information systems, high-level transaction management, advanced work¯ow management, and contract support in electronic commerce.

136

Y. Ho€ner et al. / Computer Networks 37 (2001) 111±136

Heiko Ludwig is a Research Sta€ Member at IBM's Zurich Research Laboratory since 1996. He is a member of the e-business Solution Group and works in the ®eld of cross-organisational process management, service outsourcing, electronic contracts, outsourcing-related security aspects, and service modelling. Prior to that he was a research and teaching sta€ member at the Department of Oce Automation at the Otto-Friedrich University Bamberg, Germany (1992±1996). During that time he worked on projects in the ®eld of co-operative planning and decision-making and the integration of work¯ow and collaborative applications. He holds a Master's (Diploma) degree (1992) and a Ph.D. (1997) in computer science and business administration from Otto-Friedrich University Bamberg, Germany.