E-CONTRACT MODELING AND E-ENACTMENT
Thesis submitted in partial fulfillment of the requirements for the degree of
DOCTOR OF PHILOSOPHY in COMPUTER SCIENCE by P. RADHA KRISHNA 200799010
CENTER FOR DATA ENGINEERING International Institute of Information Technology
Hyderabad - 500 032, INDIA AUGUST 2010
Copyright © 2010 All Rights Reserved
International Institute of Information Technology
Hyderabad, India
CERTIFICATE
It is certified that the work contained in this thesis, titled “E-CONTRACT MODELING AND E-ENACTMENT” by P. RADHA KRISHNA, has been carried out under my supervision and is not submitted elsewhere for a degree.
Acknowledgments
First and foremost, I would like to thank Prof. Kamalakar Karlapalem for all his advice, ideas and help. I also thank the faculty and staff of IIIT-H and co-researchers at Centre for Data Engineering, IIIT-H for their time-to-time support. Many thanks to Dr. Dickson K. W. CHIU, and Prof. K. Vidyasankar for extensive discussions and collaboration during my research work. Special thanks to Appaji and Kishore for their help. I am also grateful to my colleagues for their continuous encouragement. I also would like to thank all who have had a direct or indirect support in the completion of this thesis.
My special thanks to the members of my Ph.D. panel: Prof. T. V. Prabakar Rao, Prof. Krithi Ramamritham and Prof. Bipin Indurkhya, for their thoughtful comments.
Abstract
Contracts play a major role in establishing binding relationships between various business units and also between businesses and their customers. A contract consists of numerous activities that have to be carried out by the involved parties and contract clauses that address specific concerns in the business process interaction. An e-contract is a contract modeled, specified, executed and deployed (controlled and monitored) by a software system (such as a workflow system). As contracts are complex, their deployment is predominantly established and fulfilled with significant human involvement. This necessitates a comprehensive framework for generic fulfillment of e-contracts. So, the goal of e-contracting is to transform a traditional contract document into an executable e-contract. This thesis investigates on modeling and enactment aspects to develop database supported
e-contracts. Development of e-contract system, starting from modeling to enactment, is still a novel
application area, as it affects a confluence of various database and information infrastructure technologies, including active conceptual modeling, ECA rules, formal commitment models, workflows, and web services. The problem is addressed as a modeling problem: Given a paper contract, model the contract elements, map them to workflows and formalize the commitment aspects
In e-contracts, there has to be an underlying implementation technology that ensures their execution according to the specification. In particular, during execution, the contracts have to be consistently monitored with automated mechanisms, such as by events and rules. E-contracts need a conceptual model in order to extract the relationships between various elements in a contract, and detect the violation of clauses and respond appropriately. We introduce EREC model to model e-contracts and develop a comprehensive methodology and framework to transform the conceptual model to a set of workflows to support e-contract enactment.
Supporting evolving models during enactment is one of the key elements in implementation and enactment of e-contracts. Mini-world changes, as well as run-time changes, influence the e-contract deployment. As contracts evolve, it is also necessary to have a system, which manages their evolution. Thus, we also explored on modeling dynamic behavior of e-contracts to support evolving e-contracts.
To ensure transactional support in contract systems, we also provide a formalism to support e-contract commitment by introducing a multi-level composition model for activities in e-e-contracts. We explain how this formalism allows the specification of a number of transactional properties, like atomicity and commitment, for activities at all levels of the composition. The model also enables study of the interdependencies between the executions of e-contract activities. We show also that the transactional properties facilitate computing the cost of execution of the activities and coordinating payment. The transactional properties eventually help in closure of the contract.
Contents
Chapter Page List of figures ……….. ix List of Tables ……….. xi 1. Introduction ………... 1 1.1. Types of Contracts ………. 2 1.2. Contract Lifecycle ………. 2 1.3. Contract Elements ………. ………… 41.4. Document Contracts to E-contracts ……… 6
1.5. Research Problem ………... 7
1.6. Scope and Limitations of This Thesis ………. 9
1.7. Thesis Outline ……… 11
2. Related Work ……….. 12
2.1. E-contract Modeling ……….. 12
2.2. E-contract Representation and Specification ……… 13
2.3. E-contract Monitoring ……….. 16
2.4. Workflows ……… 17
2.5. Web Services ……… 17
2.6. E-contract Frameworks, Architectures and Systems ………... 18
2.7. Commercial E-contract Management Systems ………. 21
2.8. Discussion……… 21
2.9. Summary……… 22
3. E-contract Modeling: EREC Model ………... 23
3.1. Introduction ………... 23
3.2. EREC Meta-Model ……… 24
3.2.1. Meta-model constructs ...……….. 24
3.2.2. Contract events ……… 27
3.2.3 Exceptions ………... 27
3.2.4. Conceptual model for e-contract ………... 28
3.3. Modeling Example Contracts ……… 29
3.3.1. Buyer-and-Seller contract ………. 29
3.3.2. Investment contract ……….. 30
3.4. Mapping EREC constructs to Workflows ……… 33
3.4.1. Workflow meta-schema ………. 34
3.4.2. Mapping EREC to workflow specification ……….. 35
3.4.3. Dynamic workflows for e-contract enactment ……….. 38
3.5. FMS Contract: Case Study ………. 39
3.7. Summary of Contract examples ………..……… 50
3.8. Summary ……… 51
4. E-contract Framework and Methodology ……….. 53
4.1. Introduction ……….. 53
4.2. EREC Framework and Methodology ………... 54
4.3. Contract Workflow and Consistency ……….. 58
4.4. Events and ECA Rules ……… 61
4.5. Workflows ……….. 66
4.6. Implementation Architecture ……….. 67
4.7. Summary ………. 70
5. Modeling Evolving E-contracts ……… 72
5.1 Introduction ……….. 72
5.2. Supporting Evolving E-contracts ……… 73
5.3. Template Driven Modeling ……… 75
5.4. Scenarios for E-contract Evolution ……… 76
5.5. Active Meta Modeling for E-contracts ……….. 79
5.5.1. Support for evolving e-contracts ……… 79
5.5.2. Taxonomy of operations to affect e-contracts evolution ………. 81
5.5.3. Mechanisms to support active behaviour of e-contracts ………. 88
5.5.4. Implementation Issues ……….. 92
5.6. ER*EC Methodology ………..……… 93
5.7. Two-way Active Behaviour for Evolving E-contracts ……… 95
5.8. ER*EC Architecture for Evolving Applications ………... 96
5.9. Summary ………. 98
6. E-contract Activity Commitments ………. 100
6.1. Introduction ………. 100
6.1.1. Activities in e-contracts ……… 101
6.1.2. Activity commitments ……… 103
6.2. Basic Concepts ………. 105
6.3. Composition Model for Activities ………... 109
6.3.1. Path Model ………. 109 6.3.1.1. Composition ……….. 109 6.3.1.2. Execution ……….. 110 6.3.1.3. Transactional Properties ……… 111 6.3.1.4. Implementation Issues ……….. 112 6.3.2. Tree Model ……….. 116 6.3.2.1. Composition ……….. 117 6.3.2.2. Execution ……….. 117 6.3.2.3. Transactional Properties ……… 117 6.3.2.4. Implementation Issues ……….. 118 6.3.3. Multi-Level Model ………. 119 6.3.3.1. Composition ……….. 120
6.3.3.2. Execution ……….. 120
6.3.3.3. Transactional Properties ……… 121
6.3.3.4. Multi-Level commitment and Closure ……… 121
6.3.3.5. Implementation Issues ……….. 122
6.4. Summary ……… 125
7. Payments ………. 127
7.1. Introduction ……… 127
7.2. Cost and Payment ……….. 129
7.3. Payment for Basic Activities ………. 130
7.4. Multi-level Composition ……… 133 7.5. Discussion ………. 133 7.6. Summary ……… 134 8. Conclusions ……… 135 8.1. Summary of Contributions ……….. 135 8.2. Applicability ………... 136 8.2.1. EREC meta-model ……… ... 136
8.2.2. EREC Framework and Architecture ………. 137
8.2.3. ER*EC support for evolving e-contracts ………. 138
8.2.4. Activity Commitments and Payments ……… 138
8.3. Future Work ………... 138
8.3.1. Other pertinent approaches for e-contracts ………. 139
References ………... 140
Appendix – A: Case Study – House-Building Contract..………... 149
List of Figures
Figure Page
1.1. Contract Lifecycle ………. 3
3.1. A Meta Model for E-Contract ………... 25
3.2. EREC diagram for buyer-seller contract …….……… 29
3.3. EREC model for “investment” E-Contract ... 33
3.4. A typical workflow meta-schema ……… 35
3.5. Mapping activities to workflow ……….. 37
3.6. Augmenting exceptions as additional activities to workflow ………. 37
3.7. Text Segment related to Change Management of FMS contract ……… ….. 40
3.8. EREC model for e-contract “Financial Messaging Solution” ………. 41
3.9. Workflows for Change Management of FMS e-contract ……….. 42
3.10. Sub workflow for activity [A-4] in Change Management of ……….. 42
FMS e-contract 3.11. (a) Parametric workflows for ‘payments’ (b) Workflow views for ………. 43
‘Receive Payments’ (c) Dynamic workflows for ‘carryout changes’ 3.12 . 4W Framework ……… 45
3.13. CrossFlow meta-model ……… 46
3.14. EREC diagram for e-contract Textile Value-chain ……… 49
3.15. Workflow for e-contract ‘Textile Value chain’ ………. 50
4.1 EREC framework for e-contracts ……….. 55
4.2. Process design model for e-contracts ……….. 57
4.3. ACD for fund transfer activity ………... 59
4.4. And-Or Graph of Event level Specification of Fund Transfer Activity…….. 62
4.5. And-Or Graph of Event level Specification of Material Supply Activity…... 63
4.6. Implementation architecture for EREC framework ……… 69
5.1. E-contract enactment at macro level ……….. …. 74
5.2. EREC Model Instantiation ……….. 76
5.3. Model instantiation from multiple EREC models ………... 77
5.4. ER*EC model ……….. 77
5.5. Active meta-modeling of e-contracts ………. 79
5.6. Model instance before and after change depicting scenario 1 ………. 83
5.7. Instance by migrate and merge depicting scenario 2 …………..………….. 83
5.8. New model Instance by build ………..……….. 83
5.9. Meta-ECA Rule Driven E-contract Evolution ……….. 84
5.10. Standard template of Housing-Loan contract ……… 85
5.11. Template with change of roles ……….. 85
5.12. Template with addition of sub-contract ……… 86
5.14. A high level EREC Model for e-contract enactment ………. 88
5.15. ER*EC Methodology ……… 94
5.16. Progression for Active behaviour of evolving e-contracts ………. 96
5.17. An ER*EC architecture for evolving applications ……….. 97
6.1. E-Contract Activity Commitment System - High level view ……… 104
6.2. Execution stages of an activity ……….. 108
6.3. (a) A composition, (b) An execution of the composition, ………. 111
(c) A closed c-tree for the execution-tree 6.4. Partial backward-recovery in the Path model ……… 113
6.5. Procurement Example ……… 115
6.6. Partial backward-recovery in the Tree-model ……… 118
6.7. Procurement example with two plants ……… 119
6.8. Two-level composition for the Procurement example ……… 120
6.9. An example of Multi-level model ………... 123
7.1. Different terminations ………. 128
7.2. A payment-made-tree for the composition ………. 131
A.1. Text segments of clauses related to procurement of goods ……… 150
A.2. Text segments of clauses related to bank loan ……… 150
A.3. EREC model for e-contract House-Building ……… 151
A.4. Workflows for Bank Activities ……… 152
A.5. Workflow for Supplier activities ………. 152
A.6. ACD for fund transfer activity ……….. 154
A.7. Standard template of Housing-Loan contract ……… 155
A.8. Template with change of roles ……….. 155
A.9. Template with addition of sub-contract ………. 156
A.10. Template with additional concepts ……… 156
A.11. Procurement Example ……… 157
A.12. Procurement example with two plants ……….. 158
List of Tables
Table Page
2.1. Logics/Rules useful in representing e-contracts ………... 14
2.2. E-contract projects ……… 18
3.1. Exceptions in the meta-model for e-contracts ……….. 28
3.2. Some clauses in “investment” contract ………... 31
3.3. Some Activities of FI, Investors and Banks in “Investment” contract ………… 31
3.4. Rules of “investment” contract for EREC model ………. 32
3.5. Mapping of Parties to agents ………..……… 36
3.6. Activities of each party for the Change Management ……… 40
3.7. Activities of each party for the Textile value chain contract ……….. 47
4.1. APC Specifications ……… 59
4.2. Rules definition for Fund Transfer activity ………... 65
4.3. Event definition for Fund Transfer activity ………..………… 65
4.4. Condition definition for Fund Transfer activity ………..… ……. 65
4.5. Action definition for Fund Transfer activity ………..……….. 66
4.6. Activity log definition for Fund Transfer activity ……… 66
4.7. Basic Web Service Specifications for Inter-organization ……… 70
Communication Support 5.1. Meta-model change requirements during evolution ……… 78
5.2. Operations affecting EREC model evolution ……… 90
5.3. Handling changes during e-contract evolution ………. …….. 90
6.1. Dependency-Table ……….. 113
6.2. List of issues and solutions in e-contract activity commitments ………. 124
7.1. Some activities and payments of an example: construction and ………. 132
Painting job of a wall 7.2. Costs for execution of the activities described in Table 7.1 ……… 132
A.1. APC constructs for House-Building contract ……….. 153
A.2. Some activities and payments of an example: construction and ………. 160
Painting job of a wall A.3. Costs for execution of the activities described in Table A.2 ………... 160
Chapter 1
Introduction
Competitions among businesses made the organizations to perform better, faster and bet cost effective, besides maintaining high performance in carrying out their activities. Thus, organizations are focusing more on their core business activities and moving towards outsourcing to carry out other activities. This necessitates organizations to work with partners by mutually arriving at contractual agreements in order to identify specific parties’ (organizations or individuals) roles, responsibilities, obligations and deliverables. Conventionally, a (legal) contract forms the basis to regulate interactions between different parties in businesses and governs legal aspects when there is a breach of contract.
In the last few decades, the business world witnessed a growing need in exploring innovative ways of automating the regulation of business interactions electronically. Electronic Data Interchange (EDI) is the early development (in 1990’s) in electronic commerce and it was considered as a term that refers solely to electronic transactions and contracts [DJC1995]. EDI has a standard data format to enable computer-to-computer message transmission, there was not much support to semantics of a contract, and lot of support to right kind of message passing through set data-exchange protocols. Though EDI introduced efficient communications between organizations, it was not widely accepted due to its cost, lack of flexibility and technological limitations [R1996]. Later in 2000, OASIS (Organization for the Advancement of Structured Information Standards) developed an XML based EDI trading partner agreement Markup Language (tpaML). The tpaML focused on specifying inter-organizational agreements, in terms of messages exchanged, message sequences and the underlying transport and security infrastructure [D+2001]. The ebXML (electronic business XML) is the latest initiative in providing standards, which is a combined standardization effort by UN/CEFACT (United Nations body for Trade Facilitation and Electronic Business) and OASIS.
In recent years, there is an explosion of business applications exploiting Internet and Web as a medium. Business trends have been observed from on-line shopping (Business-to-Customer, B2C) to on-line auctions to Business-to-Business (B2B) interactions. Electronic contracts (or simply e-contracts) helps in building such new business relationships and fulfill contractual agreements through electronic contracting systems. E-contracts enable precise specification of contractual activities, terms and conditions, compliance checking and enforcement. In addition to legal binding between parties, e-contracts are also used across different workflows systems to fulfill (cross-)organizational business processes [KGV2000] and integrating different web services [CCT2003]. Thus, an e-contract is viewed from a simple electronic contract document to a computerized facilitation or automation of a contract.
With the advent of e-commerce, many online business transactions involve both implicit and explicit contracts that are accepted by entities involved in the transactions. For example, buying a
book in an online store implies signing the corresponding return policy contract. One of the key difficulties with any kind of contract processing is the legal ambiguity, which makes it difficult to address any violation of the contract terms. This is because not having sophisticated mechanisms to track and ensure contract enactment according to its specification. Therefore, contract handling requires conceptual modeling support to make the intricate details and implications of contract explicit for easy comprehension and implications, and to facilitate the design of comprehensive information systems to enact the contract in an organization. In many organizations, contracts and enactment of contracts are handled by disparate systems. The automated support of contract enactment through an e-contract management system drives the effectiveness and efficiency in contract management.
Usually, interactions among businesses and services are conducted through agreements or contracts. Enterprises work in tandem to achieve common business goals by adhering to these contracts. Web based services and service-oriented computing enhance business process management technologies and workflow management systems, which are major components for business deployment and enactment. The use of these technologies exhorts the need for e-contract management systems to provide better services and efficient monitoring of businesses.
Currently, most of the available models and approaches are human and system driven prototypes (some of them in the process of developing tool-kits) [GBWLM1998, GAHL2000, GP2003, X2004] to popularize contracts. These systems reduce the time required to learn and deploy new e-contracts, and manage workflows for e-contract enactment. There is tremendous need to have comprehensive treatment of contracts through information systems for enactment of e-contracts.
1.1 Types of Contracts
Contracts can be categorized based on their nature of execution as Sequential, Cyclic or Turnkey. A sequential contract is a contract that executes sequentially in a step-by-step manner and ends after certain period of time. A cyclic contract is a contract that exists even after the completion of one cycle of the contract, that is, the same contract holds good for a certain period of time, irrespective of the number of times the contract is fulfilled. For example, the contract between weavers and a textile company may be valid for 2-3 years, and the weaving will take place several times adhering to the same contract. A Turnkey contract has a specific goal that needs to be accomplished within certain time and under certain budget, and is a special case of sequential contract (turnkey contract need not be sequential). Turnkey contracts are most common for Governmental agencies to delegate and monitor a project (such as, building a new flyover).
1.2 Contract Lifecycle
There are several stages involved in a contract such as exchange of information and negotiation, before the execution of the contract. A contract will define a set of activities to be performed by parties satisfying a set of terms and conditions (clauses).
Traditionally, contracts are voluminous documents that are created, executed and managed via paper-based methods. These contracts incorporate certain commitments made by the involved parties. For example, in a buyer-and-seller contract, the buyer agrees to purchase certain goods, whereas the seller agrees to supply goods of a certain quality. However, a contract between two or more business partners can be much more complex than the buyer and seller transaction. Such a contract may have different phases like identifying business partners; matching offers against requirements; negotiating terms, conditions and pricing; signing; and execution.
Contract lifecycle involves Business Information Exchange leading to Contract Negotiation, then to Contract Preparation, and finally paves way for both Contract Enactment and Contract Monitoring & Management (Figure 1.1). All these processes can be summarized into three main stages namely: (i) Contract Preparation, (ii) Contract Negotiation, and (iii) Contract Fulfillment (or successful execution).
(i) Contract Preparation
In this phase, contract document is prepared by specifying the contractual roles, abstract business interactions and contractual conditions. Rules and constraint are also added which should be adhered to during the contract fulfilment phase [CNSK2007]. Both functional (ex., terms and conditions, order of activities to be carried out) and non-functional requirements (ex., quality of the service) are included in the contract document. That is, contract preparation provides the specifications for the fulfillment of the contract. Usually contracts are drafted based on some pre-defined format (template), which has a number of place holders (or variables) that are agreed upon in the contract negotiation phase.
(ii) Contract Negotiation
Contract negotiation is a decision process in which contracting parties make individual decisions and interact with each other, and come to a mutual agreement on the contract content [L1998, CCT2003]. In contract negotiation phase, payments, deliverables (along with their quality), and milestones are agreed upon. A successful contract negotiation ascertains the terms that are beneficial to all the parties involved.
Business Process Information Exchange Contract Negotiation Contract Preparation
Figure 1.1 Contract Lifecycle Contract Monitoring &Management Contract Enactment E-contractExecution
The contract document may be re-drafted, if required, in order to reflect the negotiated terms. The contract formation and negotiations phases together treated as contract establishment stage.
(iii) Contract Fulfillment
Contract fulfillment covers the execution of the contract along with its specific tasks. Typically this phase constitutes delivery of services (or goods) and payments. During contract execution, the interactions between the parties will be monitored for their conformance or violations to the terms and conditions of the contract [X2004].
The automation of the complete contract lifecycle through an e-contract management system will enable faster deployment of automated e-contracts in organizations.
1.3 Contract Elements
Most contracts comprise of the following elements:
• Parties: These are the organizations or people involved in the business process.
• Activities: These represent the tasks or e-services to be executed during the process enactment.
• Clauses: These describe the restrictions on the execution of activities. They are mainly categorized as:
a) Obligations: state what the parties involved should do, thus resulting in deliverables and criteria for Quality of Service.
b) Payments: state how the payments are to be made when the obligations are met.
c) Penalties: state what needs to be done when the obligations are not met. d) Permissions: state what the parties are allowed to do.
e) Prohibitions: state what the parties should not do.
• Arbitration: Describe the auditing requirements and processes to facilitate dispute resolution.
In addition to the above elements, contracts also have negotiation, budget, commitment, escalations, authorization and Jurisdiction.
Negotiation: During contract negotiation parties will arrive at mutually agreed terms and conditions. Also, during negation stage the scope of the work and payments are worked out. Once negotiations are over and parties have signed the contract, they have to obey the negotiated terms for the complete contract period.
Budget: Budget is allocated to each contract. Budgets have to be monitored with regard to project cost and expenses. Payments will be monitored against the budgets during contract enactment to avoid over-expenditure.
Commitment: Contract establishes the business commitments between the parties and parties have to carry out the tasks according to agreed commitments in order to fulfill the contract.
Escalations: When there are conflicts among parties during contract execution, the involved tasks need to be escalated to parties who have higher roles. Contract document contains explicit statements with regard to escalations and the people responsible to handle the escalations.
Authorization: In contracts, authorization refers to the process of determining which permissions a party or an organization is supposed to have for carrying out certain tasks. For example, one agency is authorized to carry out currency exchanges.
Jurisdiction: Jurisdiction of a contract defines the region or provenience where the legal proceedings can take place when there are disputes. Jurisdiction clauses refer the disputes arising under the contract to a country, territory or place for hearing and resolve.
In the literature, a lot of work has been done in e-contract negotiation and business process support. Weigand et al.[WSMD2003] presented a support system for carrying out negotiations for business-to-business transactions. In their work, the formal analysis of different types of negotiations is performed from the communication perspective based on Haberma’s theory of communication action, and the norm-oriented, goal-oriented, document oriented models and protocols are described. Schoop [Sc2002] presented non-automated negotiation support models to support human negotiators in their complex negotiation process involved in the document management for e-contracting. Though there is no specific work in the literature to support budgets in an e-contract system, budgets can be easily accommodated into the system. We modeled budget in our EREC meta-model (Chapter 3). Xu [X2004] described a temporal logic based formalism to support contract commitments. In this thesis work, we presented contract commitments by developing a multi level composition model (Chapter 6). Authorization can be supported by specifying roles to concerned parties. Similarly, specification of escalations and Jurisdiction can be supported as part of clauses. However, supporting identification and handling escalations as well as Jurisdiction are difficult tasks in building an e-contract system as they require appropriate interpretation of clauses, which are very specific to individual contracts; domain-dependent (insurance, manufacturing, etc.) and are usually assisted by humans who are experienced in resolving such tasks [A2009].
Consider a ‘buyer-and-seller’ contract, where the principal parties are the buyer and the seller. The contract activities include dispatch of goods by the seller, receipt of the goods by the buyer and payment of the goods to the seller. The contract also contains clauses such as delivery terms for the seller, which are negotiated and agreed upon by mutual consent of both the buyer and the seller. Thus, the primary obligations of the buyer is to pay the money and accept the goods based on the delivery terms; and that of the seller is to deliver the goods as per the contract meeting the buyer’s requirements.
Clauses can be satisfied by activity completions. Activities are initiated by success or failure of clauses and/or due to temporal and external events. Obligations furnish clauses related to Quality of Service (QoS) such as performance, availability and security; obligations are described as a part of the Service Level Agreement (SLA) in the contract document [V1999]. Non-adherence of contract deliverables is solved through issuance of Penalties, which are explicitly specified in the agreed contract. Contracts can have complementary or compulsory SLAs which have to be fulfilled during
contract enactment. E-contract management solutions should maintain, monitor and manage contract rules derived from these SLAs. Contract parties should verify QoS parameters by performing an SLA monitoring, which involves monitoring the performance status of the offered service. The e-contract management system could assess the SLA requirements and apply penalties if there is any deviation. As a last resort, disputes can be arbitrated. However, the basic premise of an e-contract is to successfully complete the execution, and automation of the dispute resolution process [DDM2002, MJPD2002] is a separate problem itself.
1.4 Document Contracts to E-contracts
As stated above, a contract is a statement of intent that regulates behavior among organizations and individuals. Until now, most contracts have had a ‘paper appearance’ and have been handled manually for the most part. An e-contract is an electronic version of the conventional contract which stipulates that the involved parties agree to fulfill specified activities and also regulates cross-organizational business processes over the Internet. More formally, an e-contract can be modeled, specified, executed, controlled and monitored by a software system. Several advantages can be attributed to the use of e-contracts including improved productivity, accelerated contract lifecycle, reduced risks and improved security, increased profits and superior monitoring of contract enactment. These are mainly due to the mapping of e-contract documents to workflows which are supported by secure IT infrastructure, thus resulting in better productivity. Moreover, electronic bookkeeping (including legal aspects), authorization, alerts and tracking are possible with an e-contract system. In e-contracts, all (or a number of) activities are carried out electronically, thus overcoming the delays involved with their manual counterparts, and also personal biases.
Contemporary contract documents with legal jargon do not provide a clear path for deciphering the relevant clauses which are to be met by the involved parties. E-contracts can be modeled to detect the violation of clauses and respond appropriately. Hence clauses in an e-contract must be represented in a standard format for easy comprehension. Further, the e-contract system can facilitate dispute resolution by providing relevant information from audit trails.
E-contract handling offers new ways of interaction among parties and modifies existing ones. For example, over a period of time, organizations can learn about contracts that are not profitable and use this knowledge to come up with revised contracts to reduce their losses.
E-contracts are rapidly becoming an important component for conducting business in cyberspace since their advent in the business negotiation scenario. With their use, it is becoming plausible to optimize the negotiation phase and the contract management process. The adoption of XML based contracts must be the first step towards a truly IT supported contracting process. It is highly likely that different forms of e-contracts will emerge, depending on the type of industry; and that the existing market places will extend their services along with the e-contracting services. The challenge here lies in transforming traditional contracts into executable e-contracts. The e-contracts problem requires a comprehensive integrated solution, and not a loosely coupled solution of various disparate
components. It is now feasible to develop a comprehensive solution to this problem. More importantly, a complete evaluation of the e-contract problem to determine the sub areas and aspects that need to be further researched has not been done till now. The key issue is to integrate e-contracts as an integral and first-class aspect of business that needs to be tackled with urgency. Otherwise, a gap occurs between contract understanding and actual business execution that may lead to loss of revenues and lack of customer satisfaction. The critical aspects of contract fulfillment, contract cost, and pricing are yet to be studied.
1.5 Research Problem
Electronic contract-handling changes the way organizations interact and raise new ways for interaction between parties. E-contracts begin as legal documents and end up as processes that help organizations abide by legal rules while fulfilling contract terms. Deployment of e-contracts has great challenges from three dimensions: technical, business and legal. Legal dimension has been widely covered in the literature [ex., D1999, V2003]. Also several studies have been considered business and technical domains together [ex., AG2003, CSSW2004]. In this thesis work, we address technical dimension of e-contracts.
The automated support of contract enactment through electronic contracts allows an increase in effectiveness and efficiency in the contract management. Thus, the need for effective e-contracting system is more than obvious.
Consider the following segment extracted from a contract document:
“…….Either Purchaser or Contractor can identify the need for change on the accepted deliverables. If the Purchaser identifies the change requirement, then Purchaser will raise Request for Change (RFC) by filling the Change Management Request form. Its format will be provided by the Contractor. It will essentially cover Change Request Description, Requested Date, Priority of the request (i.e. Very Urgent, Urgent, Normal etc.). The priority will be assigned by the Purchaser Project Manager…….”
As seen above, the descriptions of the e-contract activities, clauses and other terms and conditions are often given as a textual description in a natural language ( eg., English), leaving flexibility to the document creator. In the above example, it is not clear what the accepted deliverables are and when they will be known. This makes very difficult, or even impossible, to interpret the sentences and formulate the semantics description using available formal models/languages/logics (eg., Denotic logic). On the other hand, at the time of signing contract, most of the actual business processes/tasks are not clear. That is, several tasks have to describe at a high level of abstraction before they are carried out and the actual tasks are known during enactment only. Moreover, it is hard to formulate the relationships among activities and between activities and clauses due to complex interdependencies between them. Hence, there is a syntax and semantic gap between the contract document and its executable-counterpart that needs to be bridged through e-contract systems. Current modeling tools, such as ER and UML, do not support this level of abstraction. There is a growing
need of meta-modeling support to model e-contracts which facilitate a more generic model to describe e-contracts and to create instances of the meta-model that is not only specific to a particular e-contract but also adapts to changes occurring during the e-contract enactment. Here, a meta-model could be considered as a design framework that describes the basic model elements and the relationships between the model elements as well as their semantics.
Automation of business processes (or activities) is in general supported by a workflow management system. Since e-contracts involve complex inter/intra relationships among entities, the workflows have to be carefully specified in order to satisfy the contract semantics. That is, the workflows need to be derived from high-level abstraction to actual activities, which require on-the-fly generation of workflows. Most of the current workflow models [CCPP1999, CLK1999, KG2005] do not have the capacity to handle these complexities of e-contracts. Hence, workflow management systems need necessary infrastructure to support e-contract enactment.
Due to the complexity of the e-contracting process, humans are presently heavily engaged in the process, and are doomed to deal with lengthy legal contracts. This necessitates a comprehensive framework for generic fulfillment of e-contracts, which is still an open research problem. The actions taking place during contract execution are determined by the occurrence of various events, and thus an event based model driven architecture for e-contract implementation is needed.
The specification and management of e-contract is handled at conceptual level by a data model, at logical level by a Database Management System and the run-time support for e-contract is handled by Workflow Management System. So, deployment of e-contracts poses a host of challenges at three levels namely conceptual, logical and implementation. A level-wise approach for modeling e-contracts towards enacting their fulfillment drives the design of an e-contract system. The system needs to be accommodated with support for adaptively executing e-contracts when changes take place at the different levels. Thus e-contracting requires a confluence of technologies which have to be loosely adopted, coupled and integrated.
Activities in a contract are complex and interdependent. Both the initial specification of the activities and the later verification of their executions with respect to compliance to the clauses are tedious and complicated. We believe that an e-contract should reflect both the specification and the execution aspects of the activities at the same time. Since activities may be executed by different parties autonomously and in a loosely coupled fashion, coordinating the execution satisfying the dependencies among these activities during contract enactment is a challenging task. Another associated problem is handling payments in e-contracts and there is no model in the literature which handles payments depending on the execution states of activities.
The research problem, focused in this thesis, is to bridge the gap between the signed e-contract document and workflow supported e-contract enactment. A secondary problem is that the dynamically composed e-contract activities usually have complex inter-related dependencies which can generate exceptions and errors during the contract execution. That is, there is a gap in establishing relationships between activities and monitoring the relevant clauses which have to be satisfied for a set of activities to enable successful contract enactment. So, the e-contract system needs to monitor the execution of e-contracts. The third problem is that contract evolves over a period of time.
Modeling of an e-contract should provide provision to keep track of mini-world and run-time changes. The fourth problem is that activities in a contract can be executed by different parties autonomously and in a loosely coupled fashion. Failures can occur due to internal (ex., deviation from actual behaviour such as violation of goods delivery obligation stated in the clause) or external events (ex., document arrived, system or network failures). They may be compensated and/or re-executed at different times relative to the execution of other activities. So, e-contract systems should have a commitment model to provide transactions support to govern the activity execution and activity dependencies. Further, several activities in e-contracts are associated with payments and the cost of an activity depends on its execution (for example, multiple re-executions of an activity costs more). Since payments are integral part of contracts and transacted between parties, payment transactions need to be handled according to execution of concerned activities. So, the commitment model should support payment mechanisms.
The research goal is to develop a comprehensive framework for modeling contracts and their e-enactment. Research tasks are specified below:
• Conceptual modeling of e-contracts through meta modeling • Mapping of conceptual model to workflows
• Methodology and framework to build e-contract systems • Supporting evolving e-contracts
• Supporting execution level activity commitments and their interdependencies.
In this thesis, we • developed EREC
meta-model that can be instantiated a specific EREC model for modeling a contract under consideration.
• showed mapping of EREC
model to Workflows and present different types of workflows for e-contract enactment.
• presented a methodology and framework to arrive at implementation architecture for e-contracts.
• extended the EREC
model and methodology to support e-contract evolution and enactment thereby.
• developed a composition model for activity commitments and dependencies during e-contract activities execution, tracking payments and eventual closure of e-contract.
1.6 Scope and Limitations of This Thesis
The proposed work in this thesis relies on e-enactment of e-contracts through modeling, thereby providing Database Driven e-Enactment Environment (DDEE) for deploying e-contracts. This environment uses meta-models, which are helpful to instantiate appropriate data models and in-turn drive the contract enactment. The DDEE approach provides better support for managing contracts and
their evolution by keeping data models in synchronization during complete contract enactment period (that is, from contract execution start to its closure). DDEE facilitates tracking of changes in the mini-world as well as run-time environment to synchronize the data models based on the evolution of e-contracts. It also helps in versioning the models and captures the knowledge from run-time execution of contracts.
This thesis work assumes that the parties have agreed about the terms and conditions specified in the contract document and the contract document is signed, that is, both contract negotiation and contract preparation stages have been completed, and the contract is ready for enactment.
In this work, we assume that the unwritten contracts are handled manually and disputes, if any, will be handled through arbitration. Next, processing legal statements and dealing with legal ambiguity to support e-contracts is a separate problem itself and hence not dealt in this thesis work.
The EREC model proposed in this thesis provides support and convenience for handling expected exceptions, and the unexpected exceptions are resolved in a human-assisted mode [CLK2000b]. However, our DDEE enables provision for incorporating these unexpected exceptions in the meta-model in a more easy form, resulting necessary procedures for changes in the meta-model and in-turn handling them as similar to expected exceptions. Handling unexpected exceptions have inherent difficulties. However, having the knowledge of such exceptions during enactment of previous contracts, one can use that knowledge to incorporate appropriate handlers into the model. As suggested by Mallya and Singh [MS2005], one can build an external exception handler repository and fetch a specific handler that is appropriate with the unexpected exception and merge it appropriately into the system. DDEE facilitates building library of meta-models which are build over a period of time. Whenever any unexpected exception occurs, first it checks for appropriate meta-model to handle the unexpected exception (the system can determine whether a similar exception occurred while enacting some other contract). Otherwise, the environment allows incorporating changes in the meta-model manually. In both the cases, the DDEE propagates the changes to next levels (logical and implementation) so that the e-contract enactment is carried out further. Handler selection and dynamic augmentation of new handlers are still open issues and they have not dealt in this thesis.
Implementation issues are left open in this thesis because developing a full-fledged workable e-contract system requires several technologies and resources. However, this thesis provides sound foundation for e-contract enactment and demonstrates the feasibility of the proposed concepts through examples and case studies. Enough details at logical and implementation layers are provided to help design and implement e-contract system.
Since other researchers have explored in depth some of the issues needed for e-contract deployment (such as e-contract specification and representation, event handling, exception handling in a WFMS), we have not replicated their work, rather we attempted to concentrate on gaps in the current research and provide a relatively complete framework starting from contract document to e-enactment of e-contracts.
1.7 Thesis Outline
The main body of this thesis is organized as follows:
Chapter 2 reviews related work from different dimensions of e-contracts, including modeling, representation and specification, monitoring, workflow and architecture and framework.
Chapter 3 presents e-contract modeling, which forms the core of this thesis work to support modeling and enactment of e-contracts. This chapter introduces the conceptual model, referred as EREC model, which models the contract elements, and provides mapping to workflow elements to facilitate contract enactment.
Chapter 4 presents a methodology and framework for e-contract system development. This chapter introduces four layer framework for e-contracts and builds an e-contract methodology by considering both conceptual and execution aspects of e-contract systems. We also explained activity-commitment diagrams, and used SNOOP language to handle contract events. Further, workflow engine along with web services have been used in developing implementation architecture for e-contracts.
Chapter 5 is concerned with the evolving e-contracts, which is another vital part of our research. We extend our EREC model to support evolution by introducing evolution operations and meta-ECA rules. We also explain progression for Active behaviour of evolving e-contracts and how these technologies facilitate structural and behavioural conformance of e-contracts due to evolution.
Chapter 6 introduces a multi-level composition model which provides transactional support for e-contracts commitments. We associate the commitments with respect to e-contract activity execution states. We also explain the path and tree models, and activity dependencies. These works together enable monitoring the behavioral conditions stated in an e-contract during its execution.
Chapter 7 presents payment aspects in e-contracts. With an execution model that accommodates the complexity of the activities in contracts, we have correlated several payment issues to the states of execution of activities. The variety of states in the execution enables a fine-grained association of payments to activities. We have also given a simple mechanism for tracking payments against execution of the activities.
Finally, Chapter 8 summarizes the findings of this research and discusses directions for future work.
Chapter 2
Related Work
The literature in e-contracts focuses on sundry areas including electronic contract creation, negotiation, representation language, specification language, modeling, architecture, frameworks, management, collaboration, execution, monitoring, fulfillment, enforcement and security. Several researchers have been investigated e-contracts, and a review of the state-of-the-art on e-contracts is presented in [RK 2008]. The thesis work focus is on enactment of e-contracts and assumes that a contract has been prepared, negotiated and signed by the parties. This chapter provides the background necessary for understanding the remainder of the thesis, and provides a survey of related work.
2.1 E-contract Modeling
In e-contracts, precise and concise specification of activities and clauses suitable for machine interpretation is a challenging task. This is because contractual interactions can be very complex. Moreover, verbose documents and complex logical expressions are difficult to comprehend; thereby modeling of e-contracts is required.
Koetsier, Grefen, Vonk [KGV2000] work on CrossFlow project describes a contract meta-model. This contract model consists of five main parts: Concept model – establishes the concepts of a contract and defines as a list of parameters with their name, type and description; Workflow Definition - an abstract process definition of the service covered by the contract; Enactment Clauses - additional enactment requirements on top of basic workflow processing defined in the workflow definition; Usage Clauses - defines how contracts are used for service outsourcing; Natural Language Description – useful to describe the service in an understandable way and to refer to the legal context of the transaction.
Molina-Jimenez et al [MSSW2003] employed finite state machines to model contract agreements, states being acceptable or unacceptable. Their model mainly facilitates monitoring and enforcement of e-contracts.
A meta-model for an e-Contract template can be specified in Unified Modeling Language (UML), which is a modeling language for visualizing, specifying, constructing, and documenting the artifacts of a softwarintensive system. Chiu et al, 2005 [CCHC2005] described a meta-model of an e-Contract template in UML. The e-e-Contract template consists of a number of contract clauses, grouped as obligation, permission and prohibition. Each clause concerns parties to be bound by the e-Contract and contain a number of template variables, such as the product, price and quantity. These variables can be refined in an e-Contract through negotiations.
ebXML Meta-Model [ ebXML2000] provides support for e-contracts, which has an economic basis, in a limited way. This meta-model consists of five groups: Resources and Contracts, Markets and Parties, Business processes and Rules, Business Service Interfaces and Communications, and Information Model. In this meta-model, the business processes and rules group are strongly related contracts, which specifies processes that govern the fulfillment of commitments as part of the agreement.
Linington [L2005] presented model-driven approach based on meta-models to support contract-based business processes, creating an implementation routine that minimizes human intervention in contract design. Fantinato and his colleagues [FTG2006] [FGT2006] described a contract meta-model based on feature meta-modeling – a software product line concept. Their approach offers contract templates and intends to optimize web-service e-contract establishment process. These studies follow software engineering approaches for e-contract enactment. Our work on modeling differs from these works in identifying interrelationships between contract elements such as activities, parties and clauses, events and rules, and conceptually represents them to facilitate database support e-contract enactment.
Most of the above models are parametric driven template based meta-models. These models mainly lack flexibility and scalability to adapt to changes to mini-world and/or run-time changes. Moreover, they do not have the capabilities of modeling exceptions and also low-level semantic relationships between instance and types of modeling constructs. This necessitates meta-model driven approaches that should be as generic as possible and allows flexibility to suit the needs of modeling specific e-contracts.
2.2 E-contract Representation and Specification
The first step in building an e-contract system is to metamorphose a manually prepared contract (unstructured) into a semi-structured format. To do this, current research applies Data- and Text-Mining techniques [VKF2002] to provide rule-based knowledge representation and extracting business requirements and event patterns. For example, Kwok and Nguyen developed an automatic e-contract data extraction system to extract patterns from PDF documents [KN2006]. The system consists of four components: an administrator module, a PDF parser, a pattern recognition engine, and a contract data extraction engine.
The languages for specifying an e-contract need to be formal, that is, the syntax and semantics of the language should be precisely defined as they are required for verification and validation. They are also useful to represent business vocabularies and to model semantics of rules. Additionally, in order to execute e-contracts automatically, all the relevant semantics must be captured. Substantial research is required to develop efficient techniques to address the consistency of logic-specifications, and methodologies to help users comprehend high levels of logic to correctly specify the semantics of e-contracts. Finally, software systems that can pragmatically support these logics need to be developed.
These logics can be implicitly used to validate and promote smart techniques to support complicated semantics in e-contracts.
Deontic logic has been widely used to specify e-contracts (ex. [MM 2001, PS 2007]). Though this approach is useful to verify that the contract is free from temporal and deontic inconsistencies, it is static in the sense that it cannot describe permissions, obligations and prohibitions that become and cease to be in effect depending on the occurrence of time and other events. In the literature, there are works on enhancements to Deontic logic and several other logics to represent and specify e-contracts. Table 2.1 shows various logics and rules that are useful to represent e-contracts. Paschke et al [PDK2005] described examples of some of these logics to build a SLA management framework. Usually, all these notions are needed in order to represent various aspects of e-contract. However, a single logic is not sufficient enough to represent a complete e-contract. Moreover, providing implementation independency is a difficult task and thus necessitates a unified logic to represent e-contract fully. Comparison and evaluation to recommend a standard language for e-e-contracts is still an open research problem.
Logic/Rules Usage
Horn Logic Derivation rules (rule changing), Negation as failure, Procedural attachments, external data integration.
Description logic Represent the terms (contract vocabularies and domain-specific concepts ) used in a contract; Defeasible logic Conflict resolution and priority relation of rules; Deontic logic Represent rights and obligations with violations as
exceptions.
ECA rules Specifying events and actions, and modeling the active behaviour of e-contracts
Derivation rules Deductive reasoning on contract rules, default rules and priority relations of rules
Event Calculus Derive temporal reasoning over effects of events on fluents (contract tracking).
Table 2.1 Logics/Rules useful in representing e-contracts
Angelov et al [AG2003] present an in-depth study about the requirements on an e-contract specification language based on the 4W e-contracting framework. This framework states that an efficient e-contract specification language should include at least three different constructs: data constructs, rule constructs and process constructs; should allow the specification of the information to be exchanged and the activities to be performed; should provide mechanisms to specify and manage changes in the contract elements.
Daskalopulu and Maibaum [DM2001] represented contracts using Modal Action Logic for formal specification of temporal constraints and error recovery, and Deontic Action Logic for temporal
reasoning over Deontic specifications. Governatori and Milosevic [GM2006] described FCL using Defeasible logic and Deontic logic to express contract specifications.
In the works of Daskalopulu et al [DDM2001], Finite Sate Machines are used to attempt to assess contract status and implication of eventualities. Carlos et al. [CSSW2004] described contracts by Finite State Machines and presented an X-contract (executable contract) system that deals with ambiguities existing in contract documents. This system also supports monitoring and enforcing the rights and obligations of parties at run-time.
Tagg et al [TMKG2004] employed Business Contract Language (BCL) for specification of business processes and derived recommended workflows. BCL is an XML-based language and it facilitates specifying e-contracts in a way that allows automatic management including contract monitoring and enforcement based on the event concepts. BCL is also useful to define behavioral constraints and structural aspects, as the definition of the clauses and sub-clauses that compose the e-contracts. Farrell et al [F+ 2004] presented automated performance monitoring of e-contracts in terms of tracking contract states by expounding an XML formalization of the event calculus and ecXML.
Logic based formalisms (e.g., BCL, Formal Contract Logic(FCL) [MSO2006]) can be used to describe semantics including constraints, obligations, permissions, prohibitions and violations in contracts. For example, a clause “In case of goods not received in good condition, the seller should offer the goods at a discount price. If the seller fails to fulfill this obligation, the seller will refund the amount fully with the penalty (e.g. interest)” can be represented in FCL as :
Rule1: ObReceiveGoods |- OSQualityOfService ⊗ OSOfferDiscount⊗ OsRefundAndPenality
The semantics represented in the logic-based formalisms need to be mapped to business process specifications using available languages such as BPMN, BPEL and Petri-nets. Logics can be internally used in contract management systems to validate and verify the correctness of the e-contract specification, and adherence of enactment to the specification. The business processes must be designed in such a way that they adhere to the contract specifications, and there should be a compliance mechanism for modeling conflicts and violations [MSO2006]. Modeling and designing the contract semantics in this manner helps in deriving the workflow specifications from contract descriptions. Thus formal contract specification languages coupled with a workflow system improve the automation of business processes for their implementation and monitoring during their execution.
The e-contracting logic model described by Lee [L1998b] aims to improve both expressiveness and inferential capabilities of the contracts. First order-predicate logic [L1998] with documentary Petri nets, Object-oriented models [GBWLM1998] and dynamic deontic logic [DW1995] have been proposed for contract representation. Grosof [G1999] proposed a declarative approach to business rules in e-commerce contracts by combining CLP (Courteous Logic Program) and XML. More details on Logic-based tools for the analysis and representation of legal contracts can be found from Daskalopulu’s thesis work [DS1997, D1999]. Similarly, representation of trading contracts can be found in Xu’s thesis work (XJ2003, X2004, X2004b). OMG (www.omg.org) released a standard known as Semantic of Business Vocabulary and Business rules (SBVR) to specify vocabulary and business rules for business processes.
Although there are several efforts to specify e-contracts, a specific e-contract specification language is still missing. The existing logics and rules are useful in order to specify and represent e-contract activities and clauses; however they need a precise specification of activities and clauses which is hard to define from contract documents due to its high-level of abstraction.
2.3 E-contract Monitoring
Monitoring an e-contract requires precise expression of contract semantics to comprehend the behaviour of contract parties. The requisites influence both the contract language design and contract architecture components. E-contract monitoring is a process whereby, activities of the parties listed in the contract are governed by the clauses, so that the execution of the activities can be monitored and violations acted upon. Specification and detection of events play a vital role in the process of analyzing, monitoring and visualizing the behavior of each party involved in the e-contract. Thus, one major requirement for e-contract monitoring is event based monitoring. Another noteworthy feature is to have pro-active monitoring of events.
Abrahams and Bacon [AB2002] presented a mechanism for storing, monitoring and enforcing e-commerce contract provisions based on Kimbrough’s Disquotation Theory. This work focuses on prepositional content in a sentence and expounds the fulfillment and violation conditions. It also demonstrates its application to the creation of computational environment for monitoring and enforcing electronic contracts.
Herring and Milosevic [HM2001] presented a BizTalk technology for B2B contracts to monitor the business interactions governed by a contract.
Weigand and Xu [WX2001] proposed a model that focuses on task allocations and process coordinations. Xu and Jeusfeld [XJ2003] described proactive monitoring of activities using temporal logic for any contract violations to fulfill the contract during its execution. Xu [X2004] proposes a pro-active e-contract monitoring system to monitor contract violations. They represent constraints using propositional temporal logic in order to provide formal semantics for contract computation at the contract fulfillment stage. However, their formalism does not provide the execution level semantics of an e-contract commitment.
Lopes and Oliveira [LO2005] described an agent-based environment to provide contract related services for virtual enterprises. Their framework also provides contract formalization using structured normative approach, their monitoring and enforcement. Rouached et al [RPG2005 ] presented event-based framework associated with a semantic definition of the commitments expressed in the event calculus to model and monitor multi-party contracts.
The technologies related to event monitoring, active databases and expert systems are germane to detect conflicts and violations in e-contract environments; however, they do not keep event histories that are essential for contract monitoring purposes.
2.4 Workflows
Workflow technology provides a way of modeling and automating business processes. The Workflow Management Coalition (WfMC) has recently proposed standards for an Interworkflow Application Model to model inter-organizational workflows and Wf-XML [WFMC2000], which is an interchange format specification for an XML language designed to model the data transfer requirements for inter-operating process specification. These documents describe the modeling and specification of the overall workflows and inter-organization issues. Much research has been devoted to formal verification of workflow systems for business processes. In [A1998, AH2000], petri-net based structures are used to verify the correctness of workflow procedures. Van der Aalst et al. [AKV2003] developed a formal organizational model using UML and XML to support workflow systems. Akhil Kumar and Zhao [KZ2002] presented a language XRL (Extensible Routing Language) to support the routing of workflow for Internet-based electronic commerce services. The jointFlow [S1998] standards proposed by OMG group facilitates the enactment of workflow process components and supports interfaces for process execution, monitoring and interoperation between process components. Lei and Singh [LS1997] detailed a comparison of various workflow meta-models. The ADOME WfMS model [CLK2000] facilitates exception handling during workflow execution.
Green and Vonk [GV2006] describe the relationship between transaction management systems and workflows for transactional business process support. Iwaihara, Jiang and Kambayashi [IJK2004] presented a Workflow-Contract-Solution (WCS) model to support e-contract oriented execution of business processes. The CrossFlow model [GAHL2000] provides cross-organizational workflow support to provide role based interfaces and connecting workflows by runtime role mapping.
Though most of the above works are not directly related to workflows for e-contract processes, they are useful in hanldling e-contract activities. Usually workflow processes are very clearly stated. But, a contract process does not describe a concrete work procedure but provides abstract representations of obligations and rights. This necesisates a need for translation mechanism to translate e-contract elements into workflow processes.
2.5 Web Services
XLANG [T2001] is based on the Web Service Description Language (WSDL) service description with an extension element that describes the behavior of the services as a part of a business process. In XLANG, the behavior of each Web service is specified independently, and the interaction between Web services is only through message exchanges expressed as operations in WSDL. Similarly, Leymann [L2001] describes Web Services Flow Language (WSFL) on their MQSeries workflow engine that is also layered on the top of the WSDL. The WSFL is an XML language for the description of Web services compositions for supporting workflows. WSFL specifies the appropriate usage pattern of a collection of Web services in order to achieve a particular goal (e.g., information
