E-CONTRACT MODELING AND E-ENACTMENT

Transcription

1 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 CENTER FOR DATA ENGINEERING International Institute of Information Technology Hyderabad , INDIA AUGUST 2010

2 Copyright 2010 All Rights Reserved ii

3 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. Date Adviser: Prof. KAMALAKAR KARLAPALEM iii

4 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. iv

5 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 ER EC 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 e-contract systems, we also provide a formalism to support e- contract commitment by introducing a multi-level composition model for activities in 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. v

6 Contents Chapter Page List of figures.. ix List of Tables.. xi 1. Introduction Types of Contracts Contract Lifecycle Contract Elements Document Contracts to E-contracts Research Problem Scope and Limitations of This Thesis Thesis Outline Related Work E-contract Modeling E-contract Representation and Specification E-contract Monitoring Workflows Web Services E-contract Frameworks, Architectures and Systems Commercial E-contract Management Systems Discussion Summary E-contract Modeling: ER EC Model Introduction ER EC Meta-Model Meta-model constructs Contract events Exceptions Conceptual model for e-contract Modeling Example Contracts Buyer-and-Seller contract Investment contract Mapping ER EC constructs to Workflows Workflow meta-schema Mapping ER EC to workflow specification Dynamic workflows for e-contract enactment FMS Contract: Case Study Comparison with Related Work.. 44 vi

7 3.7. Summary of Contract examples Summary E-contract Framework and Methodology Introduction ER EC Framework and Methodology Contract Workflow and Consistency Events and ECA Rules Workflows Implementation Architecture Summary Modeling Evolving E-contracts Introduction Supporting Evolving E-contracts Template Driven Modeling Scenarios for E-contract Evolution Active Meta Modeling for E-contracts Support for evolving e-contracts Taxonomy of operations to affect e-contracts evolution Mechanisms to support active behaviour of e-contracts Implementation Issues ER *EC Methodology Two-way Active Behaviour for Evolving E-contracts ER *EC Architecture for Evolving Applications Summary E-contract Activity Commitments Introduction Activities in e-contracts Activity commitments Basic Concepts Composition Model for Activities Path Model Composition Execution Transactional Properties Implementation Issues Tree Model Composition Execution Transactional Properties Implementation Issues Multi-Level Model Composition vii

8 Execution Transactional Properties Multi-Level commitment and Closure Implementation Issues Summary Payments Introduction Cost and Payment Payment for Basic Activities Multi-level Composition Discussion Summary Conclusions Summary of Contributions Applicability ER EC meta-model ER EC Framework and Architecture ER *EC support for evolving e-contracts Activity Commitments and Payments Future Work Other pertinent approaches for e-contracts. 139 References Appendix A: Case Study House-Building Contract Appendix B: Glossary 161 viii

9 List of Figures Figure Page 1.1. Contract Lifecycle A Meta Model for E-Contract ER EC diagram for buyer-seller contract ER EC model for investment E-Contract A typical workflow meta-schema Mapping activities to workflow Augmenting exceptions as additional activities to workflow Text Segment related to Change Management of FMS contract ER EC model for e-contract Financial Messaging Solution Workflows for Change Management of FMS e-contract Sub workflow for activity [A-4] in Change Management of.. 42 FMS e-contract (a) Parametric workflows for payments (b) Workflow views for. 43 Receive Payments (c) Dynamic workflows for carryout changes W Framework CrossFlow meta-model ER EC diagram for e-contract Textile Value-chain Workflow for e-contract Textile Value chain ER EC framework for e-contracts Process design model for e-contracts ACD for fund transfer activity And-Or Graph of Event level Specification of Fund Transfer Activity And-Or Graph of Event level Specification of Material Supply Activity Implementation architecture for ER EC framework E-contract enactment at macro level ER EC Model Instantiation Model instantiation from multiple ER EC models ER *EC model Active meta-modeling of e-contracts Model instance before and after change depicting scenario Instance by migrate and merge depicting scenario New model Instance by build Meta-ECA Rule Driven E-contract Evolution Standard template of Housing-Loan contract Template with change of roles Template with addition of sub-contract Template with additional concepts.. 87 ix

10 5.14. A high level ER EC Model for e-contract enactment ER *EC Methodology Progression for Active behaviour of evolving e-contracts An ER *EC architecture for evolving applications E-Contract Activity Commitment System - High level view Execution stages of an activity (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 Procurement Example Partial backward-recovery in the Tree-model Procurement example with two plants Two-level composition for the Procurement example An example of Multi-level model Different terminations 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. ER EC 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 A.7. Standard template of Housing-Loan contract 155 A.8. Template with change of roles 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 A.13. Two-level composition for the Procurement example x

11 List of Tables Table Page 2.1. Logics/Rules useful in representing e-contracts E-contract projects Exceptions in the meta-model for e-contracts Some clauses in investment contract Some Activities of FI, Investors and Banks in Investment contract Rules of investment contract for ER EC model Mapping of Parties to agents Activities of each party for the Change Management Activities of each party for the Textile value chain contract APC Specifications Rules definition for Fund Transfer activity Event definition for Fund Transfer activity Condition definition for Fund Transfer activity Action definition for Fund Transfer activity Activity log definition for Fund Transfer activity Basic Web Service Specifications for Inter-organization 70 Communication Support 5.1. Meta-model change requirements during evolution Operations affecting ER EC model evolution Handling changes during e-contract evolution Dependency-Table List of issues and solutions in e-contract activity commitments 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 A.1. APC constructs for House-Building contract 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 xi

12 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 interorganizational 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 1

13 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 e-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). 2

14 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. Business Process Information Exchange Contract Negotiation Contract Preparation E-contract Execution Contract Enactment Contract Monitoring & Management Figure 1.1 Contract Lifecycle 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. 3

15 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. 4

16 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 ER EC 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 5

17 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 crossorganizational 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 6

18 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 7

19 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. 8

20 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 e-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 ER EC meta-model that can be instantiated a specific ER EC model for modeling a contract under consideration. showed mapping of ER EC 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 ER EC 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 9

21 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 miniworld 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 ER EC 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 metamodel in a more easy form, resulting necessary procedures for changes in the 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 e-contract document to e- enactment of e-contracts. 10

22 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 ER EC 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 activitycommitment 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 ER EC 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. 11

23 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 software-intensive system. Chiu et al, 2005 [CCHC2005] described a meta-model of an e- Contract template in UML. The 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. 12

24 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 contractbased business processes, creating an implementation routine that minimizes human intervention in contract design. Fantinato and his colleagues [FTG2006] [FGT2006] described a contract metamodel based on feature 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. 13

25 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-contracts is still an open research problem. Logic/Rules Horn Logic Description logic Defeasible logic Deontic logic ECA rules Derivation rules Event Calculus Usage Derivation rules (rule changing), Negation as failure, Procedural attachments, external data integration. Represent the terms (contract vocabularies and domain-specific concepts ) used in a contract; Conflict resolution and priority relation of rules; Represent rights and obligations with violations as exceptions. Specifying events and actions, and modeling the active behaviour of e-contracts Deductive reasoning on contract rules, default rules and priority relations of rules 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 14

26 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: O breceivegoods - O SQualityOfService O SOfferDiscount O srefundandpenality 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 e-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 ( released a standard known as Semantic of Business Vocabulary and Business rules (SBVR) to specify vocabulary and business rules for business processes. 15

27 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 eventbased 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. 16

28 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 metamodels. 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 17

29 integration), and it also specifies the interaction pattern of a collection of Web services. Next, the Web Service Choreography Interface (WSCI) [WSCI2002] describes the flow of messages exchanged by a Web service participating in interactions with other Web services. In particular, WSCI describes the dynamic interface of the Web service participating in a given message exchange by means of reusing the operations defined for a static interface. Further, WS-Coordination [WS-C2002] defines an extensible framework for coordinating activities using a set of coordination protocols. Based on WS-Coordination, WS-Transaction [WS-T2002] presents an XML language to describe an atomic transaction for coordinating activities in a short period of time, and also a business activity for coordinating activities in a long period of time by applying business logic. However, all these efforts do not provide the exception handling mechanisms other than the primitive SOAP (Simple Object Access Protocol) fault mechanism [W3C], which is one of important requirements in the execution of e-contract that may arise due to the violation/deviation from a particular clause. Hung and Chiu [HC2004] have proposed the development of workflow based information integration with exception support through SOAP fault in a web service environment. Chiu et al. [CCT2003] proposed architecture for e-contract enforcement in an e-service environment based on Deontic logic and Web services. 2.6 E-contract Frameworks, Architectures and Systems Various research groups have proposed several e-contract frameworks, architectures and systems. Smith [S1980] invented a contract net protocol for structuring contractor and subcontractor market places. Milosevic and Bond [MB1995] presented a research prototype - Business Contracts Architecture (BCA) which support contract establishment, execution, monitoring and enforcement stages in a contract life cycle. BCA was one of the first approaches trying to provide exhaustive support to automate contract management. It provides a repository where standard contracts and reusable contracts can be stored to be retrieved later. There are three pre-cursor projects namely COSMOS, CrossFlow and SweetDeal to deploy e- contracts. Table 2.2. shows coverage of various stages of e-contract for these projects. COSMOS Crossflow Sweetdeal Business Information Exchange Negotiation Modeling Specification Monitoring Enactment Management Table 2.2 E-contract projects 18

30 COSMOS (Common Open Service Market for SMEs) [GBWLM1998] is a forerunner project in the area of e-contracts, provides a set of services to facilitate e-contract use on the Internet. COSMOS provide a basic architecture and a meta-model outlining the structure of a contract. This system also facilitates automation of obligations fulfillment and Petri-net based workflows derivation for a contract. This project is based on Contract Object Model to describe an e-contract as a combination of objects, which can be exchanged between different parties and stored in XML format. However, this project has some weaknesses. COSMOS assumes conflict-free specifications and can reason neither about conflicting obligations nor about powers of parties. Also, it ignores the possibility of deviation from expected behavior and does not provide reason about the consequences of violation. The CrossFlow project [GAHL2000] introduces dynamic contracting and configuration for service enactment and defines inter-organizational business process among the parties. CrossFlow contracts are specified in XML and they are built on the Process Description Language (PDL) using the Workflow Management Coalition (WfMC). The CrossFlow project treats e-contracts systematically through contract templates, allowing template creation using preexistent e-contracts that are frequently used in business domains. This project provides automatic support for virtual organizations focusing on e-contracts that specify the interaction between the parties in a high-level. However, this project has some issues namely (i) lack of sufficient support for specification of rules, constraints, rights and duties, (ii) No sophisticated mechanism such as workflow views for information and control exchange between workflows of different organizations and (iii) Contract enforcement is not straight forward. Grosof and Poon [GP2003] developed the SweetDeal system, which allows software agents to create, evaluate, negotiate and execute e-contracts with substantial automation and modularity. Their approach represents contracts in RuleML and incorporates ontology-based process knowledge descriptions. In SweetDeal, the relation between the contract elements and its semantics, and the representation of contract rules that enables automatic processing and interpretation are notable aspects. The main weakness of this project is the lack of comprehensive support for process specification and all rule types. The ebxml ( comprehensive framework supports all contract cycle phases, letting organizations specify business process definitions and perform business transactions over a network. Marjanovic and Milosevic [MM2001] presented a formal model, which introduces the specification, verification and scheduling aspects of e-contracts. Further, Cole and Milosevic [CM2001] extended the ebxml meta-model to support e-contract meta-modeling. Sallé [S2002] proposed an agent-based electronic contract framework for the automation of contractual relationships. The E-commerce application Development and Execution Environment (EDEE) presented in [AEB2002] provides mechanism for capturing provisions of contracts, policies and law. It is an asynchronous Event Condition Obligation style business process automation as an alternative to conventional synchronous Event Condition Action approach followed in active databases. In addition, EDEE provides framework for storage and consistency checking of intra, inter and extra organizational policies. Chakravarthy and Singh [CS 2008] described an event-driven 19

31 architecture for cross-organizational business processes. Here, events are used to model normal and exceptional outcomes. 4W is a conceptual framework for B2B e-contracting that involves four groups - Who, Where, What and How - and their inter-relationships [AG2003]. Specifically, the Who group comprises two or more participating parties; the Where group comprises a legally enforceable agreement, which illustrates the contract s context; the What group comprises obligations in return for certain rights; and the How group comprises the parties commitment. The 4W framework helps structure the contract content and its machine interpretability, which helps automate contract enactment; the enactment s efficiency and effectiveness is aided by supporting tools, such as contract viewing and tracking. Chiu, Cheung and Till [CCT2003] developed an e-contract deployment system based on multiple layer framework in which the e-contracts are modeled in UML and the implementation architecture is based on cross-organizational workflows using Enterprise Java Bean and Web services. E-ADOME [CCT2003] and CrossFlow [GAHL2000] systems describe the workflow interfaces as activities and transitions in e-contracts. E-ADOME further describes workflow views for cross-organizational workflow interoperability and uses workflow views as a basis for its e-contract development framework. Vandana [V2003] proposed a framework for modeling and representing contractual knowledge in the form of Multi Tier Contract Ontology (MTCO), and also proposed a methodology for deducing the Contract Workflow Model (CWM) from MTCO. The MTCO has a structured and layered collection of individual ontologies moving from the top generic level progressively down to specific template ontologies. This layered framework consists of three layers: (i) Upper Level Contract Ontology to define the essential elements in every contract type, (ii) Specific Domain Level Contract Ontology to define more precise terms related to the specific contract type and (iii) Template Level Contract Ontology to define standard contractual obligations and their associated fulfillment patterns. The CWM outlines the preferred choreography of business performance that successfully fulfills the execution of contract obligations. The deduced CWM is visualized as an aid to monitor the contract, as a starting point for business process integration and business process workflow design. This is the first and only work on modeling the semantics of the e-contract in the form of ontology, and still there is ample scope to develop knowledge models for e-contract systems. Iwaihara, Jiang and Kambayashi [IJK2004] presented a Workflow-Contract-Solution model to support the execution of e-contract business processes. Angelov, Till and Grefen [ATG2005] proposed architectures to support updates in dynamic, communication-intensive contract enactment environment. These architectures are mainly providing security aspects in a dynamic environment. Business Transaction Framework based on Abstract Transactional Constructs, developed by Wang et al [WGV2006], provides a specification language for identifying and interpreting clauses in e-contracts. However, an adequate formalism for e-contract commitment is yet to be addressed for specifying e-contract commitments. The most recent and significant project in e-contracts is CONTRACT project ( It develops frameworks, components and tools for modeling, implementing, verifying 20

32 and monitoring distributed e-business systems. The main focus of this project is on interorganizational e-contracts, which describe the behaviour of each individual service and the whole system. This project also provides models and a reusable contract language specification. Existing electronic contract approaches are not enough for full-fledged e-contract support starting from e-contract document to its e-enactment, since e-contracts have special characteristics and specific dynamism and flexibility requirements. Therefore, new frameworks and models specially tailored for e-contracts need to be designed. 2.7 Commercial E-contract Management Systems Forrester research report [BLL2007] cites more than 16 commercial contract management applications from companies such as Emptoris, Procuri, Ariba, I-many and SAP. Moreover, several new players - including CMA Contiki, Ecteon, Ominiware and Symfact - are providing contract management solutions. Most of these contract life-cycle management systems work well for different stages of the contract lifecycle such as contract creation, negotiation and compliance. Currently these solutions aim to ensure adherence to contract terms and conditions in real time and support analysis of all contractual obligations, rights, conflicts and benefits. 2.8 Discussion Although the literature describes many e-contract-related technologies, several open issues remain, including the following: a) How to conceptually model e-contracts with the capabilities of modeling exceptions and low-level semantic relationships? b) Is there a unified approach for modeling and specifying an e-contract by considering multiperspective semantics and e-contract commitments? c) Is it possible to extract linguistic patterns and event patterns, and to derive e-contract specifications using logic, if required? d) How to provide flexibility and scalability to adapt to changes to mini-world and/or run-time changes for modeling and enactment of evolving e-contracts? e) Is there a mechanism to translate modeling constructs into deployable workflows? f) How to build a comprehensive framework for specification and implementation of dynamic and parametric e-contract applications? g) Is there a systematic approach or methodology to capture structural, functional and behavioural aspects of e-contracts for their enactment and fulfillment, including evolving e- contracts? h) Can we define generic templates for domain-specific or functional e-contracts and develop a methodology to enact specific e-contract instances? 21

33 i) How to provide transactional support for activity commitments and handling payments? j) How to coordinate autonomous organizations and parties and efficiently handle the e- contract s execution and evolution over time? k) Is there a way to build models and/or language support for Dispute resolution and arbitration? In this thesis, we address the points a, d, e, f, g and i mentioned above. The points c and e are dealt in [ARK2007] and the points b, h, j and k are not addressed and are left as future work. 2.9 Summary In this chapter, we reviewed the literature on e-contracts in the areas of modeling, contract representation and specification, monitoring, workflows and web services. We also presented the works on e-contract frameworks, architectures and systems and briefly described the commercial systems. In the next chapters, we present our ER EC model and framework for modeling and enactment of e-contracts, adopting ER EC model for evolving e-contracts and finally present multi-level composition model to support activity commitments and payments. The inference of various terms used in rest of the thesis is as follows: Framework: A framework provides a generic view of components that will do the work. Architecture: Architecture provides a data/process flow among these components and their interaction along with other software components required to develop a system. Methodology: Methodology provides a step-by-step procedure how the work is done Contract Model: A model is a representation of the contract data/process which can facilitate specification and implementation of a framework. Contract Meta-model: A meta-model is an explicit model of the constructs needed to build specific models for e-contracts (which are the application domain of interest). The developed model must be in accordance with its meta-model. Meta-modeling: The procedure in building meta-models Meta-schema: Meta-schema is an instance of a specific model using the constructs provided by Meta-event: Meta-ECA: the meta-model. Meta-event is an event based on the constructs of a meta-model, and its instantiation could be a specific meta-event. Meta-ECA is an ECA (Event-Condition-Action) where the conditions and actions are pertaining to a meta-event. Contract Mini-world: The portion of the real world relevant to the contract is referred to as the contract mini-world, that is, it represents universe of discourse about the contract. The contents in the mini-world are well understood by the designers of the e- contract system. We start presenting our work with modeling of e-contracts by defining a meta-model, referred as ER EC meta-model, in the next chapter. 22

34 Chapter 3 E-contract Modeling: ER EC Model Usually, the specification of e-contract elements and relationships among these elements are handled by a data model at the conceptual level, a Database Management System at the logical level, and Workflow Management Systems at run-time. Modeling of e-contracts is quite a challenging task as the contract statements involve abstraction (that is, lacking precise and concise specification of activities and clauses) and are governed by legal processes. Modeling requires knowledge about the specific business domain, the role of specific parties and handling of clauses and exceptions. This chapter focuses on modeling e-contracts and introduces the ER EC model for conceptual modeling of e-contracts. This work also focuses on deriving workflows from ER EC model. 3.1 Introduction Contracts are complex to understand, represent and process electronically. Usually, contracts involve various entities such as parties, activities and clauses. A contract will specify how it will be executed, the restrictions on the parties involved, etc. Contracts are voluminous documents filled with legal jargon and with no clear path for finding the relevant clauses that need to be met by the business partners. Further, a clause can refer to other clause(s) in the list of clauses of a contract. One or more parties involved in the contract can enter into a subcontract. A subcontract itself is a contract, thus it may have its own parties, activities and clauses. Thus, contracts can be nested. A contract will have a list of activities to be performed and some of these activities may also be nested. That is, an activity is composed of other activities. Some activities may be carried out in parallel and some sequentially. The contract will be for a specified time period or duration, which will be defined in the contract. This duration will define the active life stage of the contract. It is expected to last till the contract is completed. A contract completion may not occur when some clauses beyond completion of activities need to be adhered to, for example, maintenance and warranty period. The activities will be linked with parties, and each party will have to carry out one or more activities. The clauses in the contract may list out the activities; however the activities may or may not be linked with clauses. For example, 70% of the payment is made after the systems received and the remaining amount will be paid in two installments after six months and one year respectively from the date of installation. In this example, the clauses are linked with payment activity, but not vice-versa. This helps us to have a library of common activities that cater to various clauses in the contracts. 23

35 An e-contract is a contract modeled, specified, executed and enacted (controlled and monitored) by a software system (such as a workflow system). With e-contracts, quick action needs to be taken in order to detect violation of clauses and appropriate responses when clauses are violated. This calls for a concise and visual representation of an e-contract and e-contract modeling is the first step to handle it. As seen above, e-contracts are complex in nature, a more adequate way of handling the design can be attained through a meta-model, which serves as building model of models for e-contracts. There are numerous advantages of meta-models as they: (i) provide a guided approach to conceptual modeling, (ii) facilitate the design of models for specific domains, such as banking, telecommunication and healthcare, (iii) provide flexibility and a generic solution to support (evolving) e-contracts, and (iv) allow reusability and extensibility for future applications/enhancements to suit the changing needs of business organizations. In the next section, we describe our ER EC meta-model for modeling e-contracts. 3.2 ER EC Meta-Model The elements in an e-contract are Parties, Activities, Clauses and Payments. Parties play different roles in a contract. Two or more parties are involved in performing activities of a contract. For example, in a purchase of goods contract, one party is a buyer and there can be many sellers. A contract has a set of clauses. Each party has a well-defined role in a contract, which is specified in the contract document. For example, in a purchase of goods contract, one party is a buyer and there can be many sellers. Each contract has a specific time period, the time during which the contract is in force. Moreover, external events and natural disasters influence the fulfillment of contracts, thus, giving rise to unexpected exception clauses. Even though a contract can have many entities involved, a contract in its simplest form can be characterized as an ordered list consisting of {CL, A, P}, where CL is the set of clauses; A is the set of activities to be performed by different parties; P = {P1, P2,..., Pn} is the set of parties, n 2. Each clause in a contract may relate to multiple activities. Figure 3.1 shows the ER EC meta-model for a contract Meta-model constructs The ER EC meta-model has the following constructs for modeling e-contracts: 1. Contracts A contract is a legal agreement between multiple parties. 2. Clauses A contract consists of many interdependent clauses that need to be fulfilled. 3. Activities A clause is fulfilled by successfully executing one or more activities. 4. Parties One or more parties undertake an activity. 5. Exceptions Exceptions model deviations from fulfillment of contracts. 24

36 In addition to entities and relationships and their attributes, ER EC meta-model models exceptions as external rules. Exceptions in e-contracts play a major role when a process/task deviates from a clause. The exceptions are represented as parallelograms (as rules). For the sake of simplicity, the attributes of entities and relationships are not shown in the diagram. The meta-model of e-contract allows us to capture the conceptual level details about the elements involved in a contract. The entities in the meta-model are parties, activities, clauses, budget, roles and payments. Note that this meta-model also facilitates easier modeling of e-contracts by being a template that can be instantiated for specific applications. The ER EC meta-model has been motivated by the earlier work on ER-R model [TNCK 1991] for modeling active databases. The ER-R model represents event-based situation-action rule and incorporates rule object that controls the state of the data objects (entities and relationships) and their attributes. It contains information about events and additional input data. In addition to database events, the ER EC model captures the contract events that control the state of the contract and provides Exception object to monitor/manage the contract events when contract violation occurs. Rule-1 Reject Request Addition of New Parties (1, n) Is a (1, 1) Contract (0, n) Can have (1, 1) Sub Contract (1, n) (1, n) Parties (1, n) Has (1, n) Activities (1, n) (1, n) (1, n) Can have Have Clauses (1, n) Lists (1, n) (1, n) Roles Role changes (0, n) Rule - 2 Allowed Not Allowed Can have refer (1, n) (1, 1) Budget Payments Rule - 3 Budget Over Stop Work Relations Rules Events Figure 3.1 A Meta Model for E-Contract Subcontract is a weak entity of Contract. Though, a subcontract previously exists as a contract and it can also be a part of the main contract for an application. The entities, namely, parties, activities and clauses form a relationship with a contract. The coordination among activities is captured during mapping to workflows using the e-contract activity specification. Clauses in a 25

37 contract are similar to constraints (or Conditions/Rules). Since a clause can refer to another clause, the Clause entity in the meta-model is self-related. The relationship Lists between Clauses and Activities model the activities in a clause. Each party plays some role in a contract. The many-to-many relationship between Parties and Roles in the meta-model represents that one party can have many roles, and different parties can play the same role. Payments is an important entity in e-contracts. Payment transactions are always between the parties, and the payment is made to payee based on the clauses defined in the contract. The Payments in the meta-model have a ternary relationship with Parties and Budget entities. The budget is continuously monitored during payments so that the expenditure is within the budget. If the amount in a payment transaction exceeds the balance budget amount (i.e., budget exceeds), then an exception budget over is raised. Exceptions defined in the meta-model are associated with entities in the form of Event-Condition-Action (ECA) rules. Domain specific ECA rules can then be bound to contract for versatile exception handling. The information about the contracts including parties, clauses and activities form the interlinked metadata that is stored in a database. The activities have attributes such as Activity Identification, Starting-Date, Ending-Date, Name of Activity, Description, Requirements and Specifications. As an activity may have multiple requirements and specifications, these attributes can be multi-valued attributes or, if required, can be modeled as separate entities. Additional entities and relationships can be incorporated into the ER EC meta-model depending on specific needs of the application domain. However, the ER EC meta-model models the core components required for e-contract fulfillment. There may be Payment Schedule(s) linked with the Activity, so that the payment may be done after successful completion of an activity. Thus, when a contract is being executed, many events will occur and operations on different files (tables) will take place. The meta-models presented in the literature (ex. [KGV 2000, ebxml 2000, FTG 2006]) for e- contracts serve as placeholders where the variables/parameters can be set for a contract. However, these models lack flexibility to generate different instances satisfying a given contract. So, additional relationships to be built and procedures needs to be written in the application logic to handle contractual interactions, which are very complex and most of the times these logics/routines are not known during design of an e-contract system or changes occur during the execution of an e-contract (for example, to add a new party). So, in e-contract modeling, we need high level, easy to use notations for capturing the semantics of the contractual requirements and flexible enough to meet the stated requirements. The presented ER EC meta-model covers capturing of all relevant entities and relationships required for an e-contract and specific models can be instantiated (as explained in section 3.3.) for a given contract. Also, activities executed by each party obviously need to be coordinated at run-time to ensure that the executions are consistent with respect to right and obligations and thus our model provide explicit provision for representing exceptions. Moreover, the presented ER EC meta-model serve as a reference model so that e-contracts can be designed using available technologies/tools such as RosettaNet and ebxml. 26

38 3.2.2 Contract events An event happens at a point of time and has no duration. At any particular time some action will cause an event to occur. The action like Change Status of Activity will cause the occurrence of an event like Status Updated. A Contract event such as addition of new party may trigger several database operations. Similarly, new activity may trigger several insertions or updates across the tables. The contract events will be caused by the actions in the execution of the contracts. A contract event may lead to several database events, however a database event can occur independent of contract events. Suppose, when an address of a party in the contract is changed (a database event), it is not a contract event since it will not affect the execution of the contract. In figure 3.1, we use ER-R model [TNCK 1991] to model an event. Some of the contract events in the meta-model are contract completed, subcontract made, subcontract over, new party joined, activity started, activity completed, party violates clauses, activity deviates from clauses, activity updated, activity requires more budget, payment initiated, payment made, role added, role updated and synchronization (as exception event) of activities not followed. The event is defined as below: <event> ::= <contract_event> <database_event> <composite-event> ::= <temporal_event> <external_event> <event> AND <event> <contract Event> ::= started <contract_object> attempted completed <contract_object> attempted deviates <CLAUSES> attempted <ACTIVITY> synchronization attempted update <contract_object> attempted. The database events are associated with data objects (<data_object>), and <database_event> is defined as in [TNCK1991]. In the above definitions, <contract_object> and <data_object> can be an entity set or a relationship set, and <attribute> is an attribute of a <contract_object> or <data_object>. Further, contract events and database events can have more events than those specified above. A temporal event is a time-based event, which could be relative (20 minutes after contract starts) or absolute (at 3.00 PM). An External event could be, for example, a document arrived. We introduced meta-events and associated them with ER EC meta-model to support evolving e- contracts in section Exceptions Exceptions in a contract are mainly due to the deviations from the clauses defined in the contract. The meta-model of a contract shows exceptions, which occur frequently during the contract process due to unanticipated possibilities, deviation from clauses, and a violation of contract. Some of the exceptions in the meta-model are shown in the table 3.1. Exceptions may occur asynchronously or occur in scattered places in a contract process (e.g., budget over), and these cannot be directly 27

39 handled by explicit rule based processing such as IF-THEN-ELSE constructs. Thus, there is a requirement for extra constructs and semantics in a workflow meta-schema to address the exception modeling and management. (i) Exception_name: Addition of new party Event: Insert a new party attempted Condition: New party can not be added during the execution of a contract Action: Reject the request (ii) Exception_name: Role Changes Event: Update the role of a party attempted Condition: Change of role violates the clauses. Action: Allowed (ROLE updated); Not Allowed (iii) Exception_name: Budget over Event: Total amount in the budget is over attempted Condition: Expenditure exceeds the budget Action: Stop work; allocate more budget (BUDGET updated) Table 3.1 Exceptions in the meta-model for e-contracts Conceptual model for e-contract First, an e-contract is conceptualized from the requirements collected by the user through the e- contract document. Once it is conceptualized, it is presented in an ER EC model by handling a contract. The complete contract is modeled as a single ER EC model. In case sub-contracts exist within a contract, each sub-contract can be modeled as separate ER EC model and all models can be integrated as a single ER EC model. After that, the clauses within e-contract need to be fulfilled by executing one or more activities. Each activity is handled by one or more parties. Therefore, in an e-contract, the actual work done is modeled by activities and is fulfilled by parties successfully executing the activities. In other words, clauses in a contract are fulfilled by successful execution of activities by parties. The ER EC meta-model can be treated as a template of an ER EC model for e-contracts for instantiating and executing multiple workflow instances. This is because an e-contract has a fixed set of relationships that are commonly held over various entities within the conceptual model for an e- contract. For example, the has relationship among the entities contract, parties, clauses and activities will exist in a conceptual model for an e-contract. That is: A. E-contracts are standardized with some parametric inputs required at specification time for a new e-contract. B. There are many fixed entities and relationships in an e-contract. C. Additional flexibility is accommodated by customizing the e-contract instance with more relationships and entities specific to an e-contract being modeled. D. There is a mix of entity types and entities (representing instances) co-existing in an ER EC model. This is a special feature of this model that is used in translating an ER EC model to a set of workflows. 28

40 3.3 Modeling Example Contracts The ER EC model allows capturing the low-level relationships among the instances of entity types, which will help to conceptualize the e-contract and facilitate the representation of complexities associated with the contract. To illustrate modeling e-contract using ER EC model, two example contracts are given below. The first one is Buyer-and-Seller contract and the second one is Investment contract. The notions used in these examples are as follows: ER EC meta-model: a meta-model is a reference model which is helpful in conceptual modeling of different conceptual models for modeling of e-contracts (shown in figure 3.1) ER EC model: a conceptual model instantiated from ER EC meta-model for conceptual modeling of a specific contract under study. Instance of ER EC model: an instance of a specific ER EC model for a specific e-contract Buyer-and-Seller contract Figure 3.2 illustrates ER EC model for the buyer-and-seller contract example. For the sake of simplicity, only a few entities and relationships are shown in the figure. The entity types parties, activities and clauses form a relationship with the contract. In the contract, buyer, seller and bank are Activities Order of Goods Buyer-Supplier Contract Payment exceeds one Million Shipment of Goods has Delivery time > 2 weeks Delivery of Goods Parties have Delivery approval Transfer of Funds Payments Buyer Supplier Bank refer Goods damaged during shipment Compensate Good not received Reject Not sufficient balance Wait Send Clarification Invalid account details Hold Resend again Exceptions Relation between entity types Relation between instances of entities Input events for exceptions Output events for exceptions Figure 3.2 ER EC diagram for buyer-seller contract 29

41 the parties, which are shown as instances of the entity set Party. Payment transactions are always between the parties and a payment is made to a payee based on the clauses defined in the contract (Clauses-Parties-Payments relationship). Exceptions (e.g., goods damaged during shipment) are modeled as external rules (shown as parallelograms). Exceptions in a contract are mainly due to deviations from the clauses defined in the contract. For example, in the case of the example contract, during the execution of the activity Shipment of Goods, in case the received goods is not of the agreed quality, the exception Goods damaged during shipment may arise. To handle this exception, a compensate action as per the clause needs to be carried out. The activity Transfer of Funds is carried out between the payer s and payee s banks (relationship is shown by the dotted line between the activity Transfer of Funds and the party Bank ) and in case the payer s account does not have the sufficient balance, it may raise the exception Not sufficient balance. Similarly, when the cost of the goods is more than one million, the steps specified in the clause Payment exceeds one million need to be followed Investment Contract Consider a Financial Institution (FI) in a country which has different types of investment schemes. Some of the schemes are opened for a short period and other schemes for a longer period. The FIs periodically issue Bonds or Securities for fixed amount in which individual investors or the institutional investors can invest (i.e. Bond holders). The payment of interest, which is promised in advance, may be done electronically or through paper instruments. When an individual/institution invests the amount with FI, they enter into a contract. The terms and conditions of the operation of Bond or security are defined by FI. It has to periodically pay the interest and must return the amount to the holder after the period defined in the contract is over. The investors will make initial payments through bank. The FI will be periodically paying interest through bank. Here, the contract and subcontracts involved are: 1. FI and Banks/agencies for accepting the Application Form and initial amount from Investors and sending the Application Forms to FI and collected amount to the account of FI (with FI s own bank). 2. FI and Banks (in some cases may be different from 1) for periodic payment of interest/warrant/dividend. 3. Among banks for inter bank funds transfer 4. Bank and investor investor being the account holder of the bank 5. FI and Investors 6. Among the investors for the transfer of ownership 7. Agencies and banks for transfer of funds 30

42 CL-a. Who can invest (like say citizen of the country and or institutions), how they can invest (like say singly, jointly etc.) CL-b. Minimum Amount, Maximum Amount and Other restrictions Maturity Period CL-c. Promise of return, mode and periodicity of interest payment etc. CL-d. Other conditions like whether Transfer of ownership allowed, Pre-mature withdrawal allowed or not, reinvestment in other schemes allowed or not etc. and penal clauses like payment of additional penal interest in case the interest is not paid in time. Table 3.2. Some clauses in investment contract In above case (5) is the main contract relevant to our example and others are sub contracts. However, the sub contracts listed in (3) and (4) can exist irrespective of main contract. The contract at (7) is required, if there is a contract between FI and agencies (i.e. not banks). In this case, there has to be another sub contract for the transfer of funds. The clauses in the main contracts will be as indicated by the FI at the time of notification. Table 3.2. and Table 3.3. presents some clauses and activities in the investment contract respectively. Table 3.4. presents some of the rules defined in the metamodel for the present example. Activity FI 1. Issuing notification for bonds/security 2. Entering into an agreement with banks/agencies for acceptance of application forms and amount. 3. Receive Application forms and funds, scrutinize applications, pass accounting entries, allot bonds/ securities to investors, return the amounts for rejected applications and unallotted amount, issue bonds and certificates, send acceptance notifications to holding agencies and investors, periodically pay the promised interest, repay or reinvest in new scheme, etc. Activity Investors 1. Submit the signed and completed application and pay the amount 2. Get notification 3. Hold the Bond/Security till maturity or carry out allowed operations like Transfer, pre mature withdrawal etc. 4. Tally the periodic interest received Activity Bank 1. Receive Application Form and Amount 2. Send Applications to FI and collected Amount to FI s Bank 3. FI s bank will credit the amount collected to FI s Account 4. FI s Account will be debited for periodic interest and repayment, the amount to be transferred to different bank accounts. 5. Transfer the interest and amount received to the investor s account. Table 3.3 Some Activities of FI, Investors and Banks in Investment contract 31

43 Rule 5 Rule 4 Rule 3 Rule 2 Rule 1 Rule_Name : Allot_Bonds_To_Investors Triggering_event : Amount_Received and Application_Scrutiny_Successful Condition : Decide upon the Bond Allocation policy. Action : Return the remaining Amount if the Face_Value of Bonds allotted is less than paid amount. Resultant_Event : {Allot Bonds, Return Amount, Inform_Depository} Suppose that investor has applied for Bonds of face value say X and he has paid amount Y (>X) then the amount (Y-X) is returned. The information is sent to the depository. Rule_Name : Pay_Interest Triggering_event : Due_Date Condition : There should not be any hold on interest payment Action : Calculate the interest payable and credit it to the investor s Account Resultant Event : {Calculate Interest Due, Amount_Transfer, Bank_Transfer} The interest will be calculated and the amount will be transferred to the Account of the Customer Exception : Not able to credit Incorrect_Account_Info, Interest cannot be paid Rule_Name : Transfer_Bond Triggering Event : Transfer Condition : There should not be any hold on transfer of ownership Action : Update the Holder Database Resultant Event : {Get_New_Act_Details, Change_Holder} The bonds will be transferred to new holder. Transfer will change the ownership. Exception : Transfer not allowed Rule_Name : Repay_Bond Triggering Event : Maturity_Period_Over Condition : There should not be any hold on repayment Resultant Event : {Calculate_Amount, Transfer_Funds} Exception : Reinvest in new scheme, Not able to Repay, Incorrect Account details Rule_Name : Pre_Mature_Closure Triggering Event : Holder_Request Condition : There should not be any hold on pre-mature withdrawal Resultant Event : { Calculate_Amount, Transfer_Funds} Exception : Premature withdrawal not allowed, Incorrect Account details Table 3.4 Rules of investment contract for ER EC model Figure 3.3. shows the schema for the contract in our example. In the Figure 3.3, the instance level information is co-existing with conceptual level information. That is, in the case of Parties, FI is a particular instance of entity Party. But we show it as a specific entity (object) in the entity type Parties. This feature is very much needed to model e-contracts, because the information captured at the instance level of an entity is different from other instances of the same entity type due to its specific behaviour in a contract. For example, the information captured for the Party instance FI is entirely different from the Party instance Investor. This feature is also a feasible solution because of small number of entities involved in each entity-type. Another interesting feature of ER EC model is the relationships between the instances of entities. These relationships are in addition to the relationships between entities. That is, for example, consider the relationship between Activity instances Submission and Fund-Receipt & Info. to FI and Parties instance FI and Investor. Here, the relationship is between the instances of entity types Activities and Parties. The investor submits an application for a bond through a bank/agency. The 32

44 Activities (A 1,A 2,A 3, A 4) A 1 Submission Contract Sub Contracts Fund Receipt & Info. To FI Scrutiny Investment have Agreement Bank Customership Allotment A 2 Inter-Bank Periodic Repayment Clauses A 3 Maturity Repayment Change Ownership has Parties have Payments CL-a CL-b CL-c A 4 Funds Transfer FI Agency CL-d Investor Bank refer Invalid Reject Wait No Sufficient Balance Send Clarification Invalid Account Details Hold Resend Again Exceptions Relations between entity types Relations between instances of different entities Contract Events Output events for exceptions Input events for exceptions Figure 3.3 ER EC model for investment E-Contract bank/agency receives the application and the required amount, and sends the information to FI. These low-level relationships among the instances of entity types will help to conceptualize the e-contract and facilitate translation of ER EC model to workflows (covered in the next section). 3.4 Mapping ER EC Constructs to Workflows Quintessentially, workflows are used to automate the business processes that govern the adherence to e-contracts. The goal of an e-contract execution is to provide deployable workflows. A 33

45 workflow is concerned with the automation of procedures where documents, information or tasks are passed between participants according to a defined set of rules to achieve, or contribute to, an overall business goal [WfMC1995]. This section deals with workflows for e-contract enactment and methodology to translate an e-contract to a workflow that can be executed by a workflow management system. The execution of an e-contract involves several processes/tasks and monitoring activities, which can be represented as workflows. However an e-contract involves the complex inter/intra relationships among workflows in a contract. An e-contract can be seen as a global manifestation over a set of inter-related workflows. Most workflow models do not have the capabilities to provide this global view of an e-contract arising out of these relationships. Due to this, the workflows for an e-contract must be carefully specified in order to satisfy the contract semantics and related to meet the contract requirements. A workflow process models the workflow using activities and the flow of control and data among the activities. Other details about parties, exceptions, clauses and contracts are not explicitly represented. This generates a gap between a conceptual model of an e-contract and workflow. Therefore, a visual representation is needed to conceptualize e-contracts, and these e-contracts still need to be deployed using available conventional workflow technology augmented with additional databases and user applications. After mapping activities of an ER EC model to a workflow, additional applications may need to be written to monitor and enforce e-contracts. Otherwise, workflow systems need to be enhanced to handle e-contracts. Further, the enactment of e-contracts necessitates the generation and initiation of dynamic workflows during the e-contract execution, besides the static workflows. Here, the focus is translating an e-contract conceptual model to an implementation level workflow or activity Workflow Meta-Schema Workflow is automation of a business process. Workflow Management Systems (WFMS) have been extensively used in businesses to design, execute, and monitor processes [GHS1995]. It provides an efficient environment for collaboration, coordination and communication among agents - people and software programs - to complete activities in a particular order and with certain rules, procedures and constraints. Figure 3.4 illustrates a typical workflow meta-schema [WfMC1995]. Note that workflow is same as an activity, and an activity of a workflow is same as a task as proposed in activity management system [KYH1995]. A reference to an activity should be clear based on whether it is a part of a workflow or an independent activity. The meta-models (i.e., meta-schemas) for e-contract and workflow combined together helps in the implementation of an e-contract, thus a mapping between the two models has to be performed. Unfortunately, the mapping may lose some semantics when transforming from a "semantically richer" ER EC (explained in previous sections) model to a workflow. Therefore, the workflow model has to be 34

46 Workflow Definition Type Role may refer to Activity consists of uses Workflow Relevant data has may have Transition conditions uses Invoked Application may refer to Figure 3.4 A typical workflow meta-schema augmented with a database for storing additional information about parties, clauses, contracts, and any other related data and business processes. In general, a contract contains a number of clauses, and any deviation from a clause violates the contract. It is required that each clause should be monitored continuously during the entire contract process. Activities are the actual work elements in a contract. A contract consists of large number of activities, and each activity, in-turn, consists of multiple inter-dependent tasks that need to be coordinated, scheduled and executed. Also, there must be dependency checks among various activities Mapping ER EC to workflow specification Typically, e-contracts are deployed using workflows. Workflow components include actors, processes, activities, roles, events, constraints and exceptions. A process indicates which tasks/activities have to be performed and in which order they have to be performed. Workflows are typically used to express inter- and intra- organization business activities/processes. Contract obligations are fulfilled by the execution of related business processes on behalf of the parties involved. Business processes may need to communicate with external world by raising appropriate events and workflows have to capture and handle them. These events need to be mapped to activity, process and sub-processes depending upon the level of abstraction and context. An action can be described by a list of pre-conditions and post-conditions. In e-contracts, workflows need to be deployed for fulfillment of activities (or obligations) by respective parties. In our ER EC model, we conceptually modeled the contract elements such as parties, activities and clauses. So, for enactment of e-contracts through workflows, the conceptual model constructs defined in ER EC model have to map to workflow components. The mapping of ER EC model to a workflow is done as follows: Step 1. All parties are mapped to agent types/roles. Step 2. Activities to workflows and activities in a workflow. 35

47 Step 3. Contracts to events that occur. Step 4. Clauses to conditions that need to be satisfied. Step 5. Exception handling to additional activities in a workflow. Step 6. Payments and contracts to documents and additional input/output events. The above steps for mapping an ER EC model to a workflow needs to be carried out to facilitate instantiation and execution of an e-contract. The steps are based on the relationship among various constructs in ER EC model. Therefore, first, parties need to be mapped to agents that perform (are responsible for) various activities. Second, the activities themselves need to be mapped to a workflow. This may require additional business processes to be specified. For example, the activity scrutiny may require a new business process in a FI to be specified. This Scrutiny workflow may require additional agents to be involved in the execution. Third, the contracts and clauses are mapped to events that need to occur to intimate the satisfaction of a clause or completion of a (sub-) contract. Note that these additional events need to be modeled and specified in the workflow. In case some of the clauses are not satisfied exception handling will take over the processing of a contract. This exception handling may require additional activities (depending on clauses) to be added to the workflow. Payments are also treated as clauses that need to be satisfied. It should be noted that this mapping only handles the workflow support component required to execute an e-contract. Additional databases and other human-supported activities and business processes need to be specified for the implementation support for e-contracts. Further, ER EC model s main objective is to facilitate conceptual understanding of dependencies within an e-contract and their mapping to a workflow. Workflow Parties Payments (sub-)contracts 1 Investor, Bank, agency, FI Investor -> Bank/Agency Bank/Agency -> FI Bank Customership Inter-Bank 2 FI, Investor, Bank FI -> Investor Agreement, Bank Customership Inter-Bank 3 Investor, FI Investor -> Investor Agreement 4 Bank Bank -> Bank Inter-bank Table 3.5 Mapping of Parties to agents Consider the Investment contract example described in section First, the parties are mapped to agents as described in Table 3.5. Figure 3.5 shows how the activities A1, A2, A3, and A4 are mapped to workflows A, B, C, and D, respectively. Augmenting workflows B and D with exception handling based on exceptions in Investment ER EC model is shown in Figure 3.6. After specifying the workflows, they can be incorporated at various parties for supporting e- contracts. For example, workflow A enables an investor (say, Rama) to submit a requisition to buy some ICICI bonds from Citibank. At Citibank, the workflow A will enable relevant information, documents and payments (through his account in Citibank) to be provided by Rama. Further, 36

48 workflow A will transmit the documents to ICICI and the payment is transferred from Citibank to ICICI. After that, workflow B is initiated at ICICI to scrutinize and allot the bonds to Rama. Once Rama is allotted the bonds, Workflow D is initiated at ICICI to transfer funds to Rama s account in Citibank, either periodically and/or at maturity time based on the contract. In case, Rama is interested to sell the bonds to another investor, (say, Sunil), the workflow C enables Rama to transfer the ownership of his bonds to Sunil. Here, the workflow C is initiated by Rama and the transfer takes place at ICICI. Start Submission Fund Receipt & Info. To FI Fund Transfer (a) Mapping Activity A 1 to workflow A End Start Scrutiny Periodic repayment Maturity Payment Fund Transfer Allotment Fund Transfer (b) Mapping Activity A 2 to workflow B End Change Fund Start End Start Ownership Transfer End (c) Mapping Activity A 3 to workflow C (d) Mapping Activity A 4 to workflow D Figure 3.5 Mapping activities to workflow Start Scrutiny Allotment Periodic repayment Invalid account details Hold Resend Again Invalid Reject Fund Transfer Maturity Payment Fund Transfer End (a) Augmenting Invalid and Invalid account details exceptions to workflow B Start Fund Transfer End No sufficient balance (b) Augmenting No sufficient balance exception to workflow D Wait Send clarification Figure 3.6 Augmenting exceptions as additional activities to workflow 37

49 3.4.3 Dynamic workflows for e-contract enactment Traditional workflow management systems mainly support process modeling and concentrate on specifying task dependencies instead of interpreting a contract [AEB2002]. Workflows do not support the notion of clauses. A clause encompasses the combined behaviour of a set of activities. That is, in order for a clause to be satisfied or checked, it generates a set of activities that need to be executed using workflow technologies. These activities generate events that determine whether a clause is satisfied or not. For example, a clause may say deny credit payment to a customer who has defaulted payments twice over last six months.. In this case, once an order is issued an activity is to be generated to check whether a customer has defaulted and depending on the satisfaction of the clause further processing is initiated. This loose coupling with the semantics of e-contract business process incorporated in a clause enhances ER EC model over traditional data and workflow models. In case of large contracts, it is feasible to envision hundreds of workflows to support it. Therefore, there is a specific need to have a toolkit that manages these workflow specifications and their relationship with contracts, clauses, parties and activities. In this work, e-contracts are mapped and deployed as activities in CapBasED-AMS [HYK 1996]. Three kinds of workflows are used for this study: i) Parametric workflows, ii) Workflows views and iii) Dynamic workflows. Parametric workflows The parametric workflows are generated by computing a function with different parameters. The input to this function is static workflow with a set of parameters, and at run-time the values of parameters are provided to generate different workflows. These parametric workflows handle most of the productionized e-contracts. Workflow views Usually, most of the contracts involve parties from different organizations and a business process spans over inter-related cross-organizational workflows [S 1999, WH 2002]. Workflows views support this type of cross-organizational workflows and are essential for enforcing a contract. The different types of workflows views and their implementation are described in [CKL 2001] and are used in this work. Dynamic workflows Finally, dynamic workflows are generated based on the situation. A workflow is dynamically composed based on the current status of e-contract execution to facilitate further processing of the e- contract. This is essential for turnkey e-contracts wherein the e-contract itself evolves over time. Further, exceptions can occur during the e-contract execution and they need to be handled by generating and executing dynamic workflows. For example, as per the change management of a contract, each change request evolves dynamic workflows. Suppose, the sequence of activities A 1, A 2, A 3, A 4, A 5, A 6 in a workflow is Seq(A 1, OR(A 2, A 3 ), AND(A 4, A 5, A 6 )). Depending on the execution of previous workflows and the exceptions raised, specific workflow will be executed. However, in certain circumstances, human intervention is compulsory to take a decision and accordingly a new type of workflow may need to be generated for the fulfillment of e-contract. 38

50 In e-contracts, the contract documents stipulate the business activities that the parties should execute under the observance of strict sequence, time and other constraints. In order to accomplish modeling e-contracts, workflows also need to be modeled. In most of the occasions, the business processes in e-contracts are characterized by lack of ability to completely predefine and/or evolving (as organizations adjust their activities in response to influences such as new legislation, competition and innovations, besides unforeseen scenarios). In order to handle these situations, in this work, we incorporated flexibility while modeling workflows (as described above) so that the actual workflow process is generated at runtime. These specifications may be unique to each instance. In the next section, we illustrate the usefulness of the above types of workflows in the context of e-contracts through a case study. 3.5 FMS Contract: Case Study The Financial Messaging Solution (FMS) is a system that facilitates standards for transmitting Financial Messages for inter- and intra- bank transactions in the banking and financial sector in India. The contract is between the software developer (who will develop application software), service provider (who will provide communication network) and participating banks. The solution is an Electronic Data Interchange (EDI) like messaging standard for secure messages for domestic banking transactions across the industry. In India, a bank has a number of branches at different geographical locations, and has one or more bank gateways to which different branches are connected. All the bank gateways will be connected to a Central Hub. The FMS messages from a bank branch to another bank branch will be delivered via Bank Gateways and the Central Hub. On the other hand, intra-bank messages can be switched at the Bank Gateway level and need not come to the Hub. The FMS provides improved efficiency and speedy operations for fund transfer, and generation of MIS reports for the banking industry. The FMS contract involves design, development, commission, testing, acceptance support and implementation of the system, demonstration of guaranteed performance as per the scope and schedules defined in the contract, besides imparting training to the concerned persons. The contract document has about two hundred pages. The monitoring of FMS contract as per specifications given in the document is a major challenge, as it involves a number of activities that have to be carried out in a synchronized manner. Many people from different organizations and various places are involved in the project. This contract involves subcontracts and a number of activities and each activity, in turn, may give rise to inter/intra organizational workflows. Some of the typical activities involved in this contract are: 1. Identify the deliverables of the contract. A time schedule for the activities, ordering of hardware and software is required. It will involve a subcontract between the participating banks and software and hardware vendors. 2. The work completed is required to be monitored Progress Monitoring 39

51 3. It has to be inspected for correctness Testing Activity 4. Depending upon the successful completion, the payment instructions to the banks are generated Payments Either Purchaser or Contractor can identify the need for change on the accepted deliverables. [Clause CL-a] 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. [Clause CL-b] On receiving this request Contractor will allocate a CMR number to the request and will notify it to the Purchaser. The contractor will then evaluate the need of this change with respect to Priority, Feasibility of the change, and Impact on time frame and cost. The contractor might ask for relevant clarifications regarding the change request. It is the responsibility of the purchaser to provide the clarification in time. The Contractor will place the results of evaluation to Purchaser. [Clause CL-c] The Purchaser can approve/disapprove the change requests after seeking the relevant clarifications on the evaluation from the contractor. In case the change is approved then the Contractor will schedule the changes based on priority. The contractor will then make the necessary changes and release them to Purchaser for acceptance. The purchaser will carry out the acceptance and provide the acceptance certificate. The Change Management Form will be recorded with the result raised change request, who has incorporated the change, date of release to Purchaser.[Clause CL-d] Figure 3.7 Text Segment related to Change Management of FMS contract Figure 3.7 shows some of the clauses related to Change Management in FMS contract. This figure illustrates the complexity of the contract specified in a verbose manner that needs to be modeled. The Change Management procedure has an impact on deliverables, time schedule, acceptance and payments. A: Application Software Developer [A-1]. Examine the Request. Seek clarifications and replies [A-2] Assign Change Management Request (CMR) Number [A-3] Accept or Reject the change [A-4] Carry out changes [A-5] Receive Payments B: Banks [B-1] Identify the Change Management Request [B-2] Clarifications and Replies about changes [B-3] Examine the impact of acceptance of change [B-4] Upgrade Hardware/Software, if necessary [B-5] Acceptance of Upgrades [B-6] Acceptance of the changes [B-7] Payments to different parties like Vendors/ Service Provider/Application Software Developers C: Service Provider [C-1] Identify the Change Management Request [C-2] Clarifications and Replies about changes [C-3] Examine the impact of acceptance of change [C-4] Upgrade Hardware/Software, if necessary [C-5] Acceptance of Upgrade [C-6] Acceptance for the changes [C-7] Receive Payments D: Vendors [D-1] Receive request for Hardware/Software [D-2] Supply Hardware/Software [D-3] Installation [D-4] Receive Payments Table 3.6 Activities of each party for the Change Management To illustrate the presented approach, FMS contract document is studied and selected some of the complicated parts to model them using ER EC model and enactment using workflows. FMS is a multiparty contract. The entities in this contract are Application Software Developer (ASD), Banks, Service provider and Vendors. The various Subcontracts in the Financial Messaging Solution are a) 40

52 Banks and Vendors (SC-1), b) Banks and Service Provider (SC-2), c) Banks and Application Software Developer (SC-3), d) Inter Bank (SC-4), e) Service Provider and Vendor (SC-5), and f) Bank Customership (SC-6). Activ A-1 A-3 A-5 A-2 A-4 B-1 B-3 B-5 Contr FMS have Sub SC-1 SC-2 SC-3 SC-4 SC-5 SC-6 B-2 B-4 B-6 B-7 has Clauses CL-a CL-c CL-d CL-b C-1 C-3 C-5 C-2 C-4 C-6 Parties have refer C-7 Vendors Payments D-1 D-2 D-3 D-4 Banks Service Provider Application Software Developer Invalid Request/ Information Clarification Wait No Sufficient Balance Send Clarification Wait Acceptance Failure Hold Resend Again Relations between entity types Relations between instances of different entities Contract Events Excepti Output events for exceptions Input events for exceptions Fig ER EC model for e-contract Financial Messaging Solution Though this contract involved many work elements, the Change Management (CM) procedure has been considered for illustration. The provision for the Change Management in the contract is to handle the changes in the requirements of the banks after the initial specifications are signed. The requirement for the change can have considerable impact on the design of the software for FMS. This may result in upgrading hardware and/or software with new versions. Thus, CM itself gives rise to more sub-contracts. Table 3.6. shows the Activities of each party for the Change Management. It gives rise to different Workflows that have to be carefully monitored by the execution manager. Figure 3.8 shows the ER EC model for FMS contract that visually captures the conceptual schema. The activities and clauses represented in the figure 3.8 are corresponding to the list of activities and 41

53 clauses mentioned in the figure 3.7 and table 3.6 respectively. For the sake of clarity, few links are only shown in the ER EC diagram. Start Identify Request Assign Priority, Description Inform to Vendor Clarification Banks/ Service Provider (Activities: B-1 to B-7, C-1 to C-7) End H/W & S/W Requirements Payment No sufficient balance Acceptance for Change Acceptance Failure Upgradition of H/W & S/W Invalid Information Start Receive invoice Supply HW &SW Installation Receive Payments End Vendors (Activities: D-1 to D-4) Installation Failure Start Request Examination Assign CMR No. Accept Carryout changes Receive Payments Application Software Devloper (Activities: A-1 to A-5) Reject Acceptance Failure End No sufficient balance Figure 3.9 Workflows for Change Management of FMS e-contract From the figure 3.7 and table 3.6, it can be observed that a single clause can depend on activities of several parties and also an activity may relate to many clauses. This many-to-many relationship between clauses and activities causes execution of multiple workflows to satisfy a clause. These complexities can be taken care of by generating interrelated workflows. Figure 3.9 shows the workflows for Change Management of FMS contract. These workflows are concerned with activities mentioned in Table 3.6. In the example, the four clauses (CL-a to CL-d) related to Change Management (see figure 4.4) are associated to these workflows when a task change request is initiated. For example, referring to the clause CL-d The Purchaser can Start Analysis Identify design changes Coding Testing End Sub-workflow of carry out Activity Testing Failure Figure 3.10 Sub workflow for activity [A-4] in Change Management of FMS e-contract 42

54 Start Send Payment instruction Sign the check by single person Issue the check End (a) Start Send Payment instruction Sign the check by two persons Issue the check End Start Receive Payment End Start Ack. Check receipt Ack. Check clearance End Start (b) Receive Check Ack. Check receipt Check deposit in bank Insufficient balance Send the Check for clearance Credit check amount Ack. Check clearance End Start Analysis for new model Identify design changes Coding additional module Testing End Testing Failure Start (c) Modify existing code Testing End Testing Failure Figure 3.11 (a) Parametric workflows for payments (b) Workflow views for Receive Payments (c) Dynamic workflows for carryout changes approve/disapprove the change requests after seeking the relevant clarifications on the evaluation from the contractor, if a failure occurred while carrying out changes, an exception Acceptance Failure will raise and subsequently another activity should activate to carry out that change. Inserting a task and thereby instantiation of a new workflow requires synchronization with the tasks that are completed earlier. Actually, the workflows for e-contracts that involve complexity can be further shown as being composed of different (sub-)workflows at different levels. For example, the activity carrying out' changes can result in workflows at lower levels (Figure 3.10). However, the monitoring and execution of workflows has to be carried out based on the corresponding ACD diagrams as explained in the next chapter. There can also be situations where the system has to decide about the starting point of the aborted workflow. For example, in the case of exception invalid information, the execution of workflow can resume from the same point once the correct information is given. On the other hand, in the case of No sufficient balance exception, the workflow can either terminate through arrangement (as specified in contract) with parties or it can be rolled back to consistent point and restart the workflow. The workflows for e-contracts can be further presented as different types of workflows (Figure 3.11) like parametric, dynamic workflows and workflows views for specific activities. The payments activity in the workflow for Banks/Service provider is considered as a parametric workflow (Figure 3.11a) based on whether the check has to be signed by a single person (top workflow) or by two persons (bottom workflow) depending on the amount transacted. In this example, the check amount is the parameter for the workflow. More inputs can be added for parameters such as considering multi 43

55 party signatures on a check. Similarly, Receive Payments is considered for workflow views, and three workflow views are generated as shown in Figure 3.11b. Finally, the carry out change activity is considered to show the dynamic workflows (Figure 3.11c). The change request upgradation of software can be handled in two ways based on the requirements: one is to modify the existing code and another is to write a new module. That is, the execution of a particular workflow will be chosen dynamically. In this work, these workflows are specified manually after translating ER EC model to workflows elements. Our ER EC model aids in specifying workflows. The workflow management systems technology is moving towards providing functionalities to meet the above-mentioned requirements. 3.6 Comparison with Related Work Modeling e-contract is an active research component in several e-contracting projects. Most of the contract models are derived from the contents provided in the contract document whereas some works also consider the contract environment while modeling. In this section, first we compare our ER EC meta-model with 4W framework and then with CrossFlow meta-model. The 4W framework [AG2003] is a conceptual framework that supports business-to-business e-contracting, which contains the concepts that describe an electronic contract and its environment, as well as the relations between these concepts. It defines contract meta-model with four concepts namely Who, Where, What and how as given bleow: Who concept Model the parties involved in the contract establishment and enactment. Where concept model the context of the contract What concept - model exchanged values and their exchange. It describes combination of words that form obligations. How Concept - related to the means and processes for contracting. 4W framework is centered on the contract concept and this contract concept is related to the four groups of concepts as shown in figure The 4W framework forms a basis for designing an e- contracting system that supports automated e-contract establishment, enactment, and management, besides e-contracting system requirements analysis. A subset of the concepts in the 4W e-contracting framework is only considered in the contract model. The concepts of 4W conceptual framework can be related to ER EC meta-model entity types. The Contract entity type is equivalent to Contract concept in the 4W framework. Parities entity type serves the Who concept, which describes the actors that participate in the contracting process. The exchanged values and the exchange value provisions are described by the What concept. Here, the exchanged value between the parties can be a product, a service or a reward. The What concept and How concept together form the Processes concept defined in the 4W framework. Thus, the What and How concepts are equivalent to Activities in the ER EC meta-model. So, the Processes concept can serve the purpose of Activities in the ER EC model. Constraints, which are part of exchange value provisions, in How concept can partly cover the Clauses in our model. 44

56 ER EC model does not have equivalent of Where concept. However, the different contexts of Where concept such as legal, business and geographical can be modeled using the entities such as Roles, Activities and Clauses in ER EC model. Figure W Framework (taken from [A2006 ]) From the above discussion, it can be evident that 4W framework addresses subset of ER EC model. Concepts such as Sub-contracts, Rules, Events and Exceptions are missing in the 4W framework. This may be due to its objective of serving the model as part of conceptual framework focusing on requirement capturing and analysis of e-contracting. Another reason could be its main coverage of contract establishment (information, pre-contracting and contracting) phase. However, the ER EC model focuses more on e-enactment and thus incorporation of events, rules and exceptions are compulsory in order to have comprehensive details to model e-contracts. Next, we compare our ER EC meta-model with CrossFlow meta-model which is a significant in e- contract meta-models. The ER representation of the Crossflow meta-model is shown in Figure CrossFlow meta-model is developed by Koetsier et al [KGV 2000] for e-contract establishment. CrossFlow project establishes the contract between two parties namely the provider and the consumer of an e-service. The meta-model has five main parts: (i) (ii) Concept Model: It establishes the terminology for the contract. It consists of a list of parameters formed by name, type and description. Process Model: It defines the inter-organizational business process between the parties. (iii) Enactment Clause: It defines additional enactment requirements (other than workflow definitions) which are used for controlling, monitoring, QoS checks, etc. (iv) Usage clause: It defines how contracts are used for service outsourcing. (v) Description: It contains natural language text for human reading. 45

57 Contract (1, 1) (1, 1) (1, 1) (1, 1) (1, 1) has has has has has (0, 1) (0, 1) (N, M) (0, 1) (0, 1) Process Model Description Concept Usage Clause Enactment Clause (1, 1) (1, 1) (0, N) (0, N) Consists of (1, N) Process Element (0, N) Refers to Refers to (0, N) (0, M) (0, N) (0, M) Refers to Refers to (0, M) (0, M) Refers to Figure 3.13 CrossFlow meta-model [KGV 2000] CrossFlow meta-model and ER EC meta-model have few characteristics in common. CrossFlow meta-model covers lower level details about clauses in terms of Enactment Clause and Usage Clause. However, this meta-model lacks modeling exceptions and Payments. Also, it misses the Parties and Sub-contracts entities since the CrossFlow meta-model was developed for bi-lateral contracts (between one producer and one consumer) only. On the other hand, ER EC model does not have Description entity as in the case of CrossFlow meta-model which allows incorporation of human readable text. This is because, our approach assumes that the negotiation and signing phases of e- contract is completed and the involved parties are agreed to enact the contract. We expect that the natural language statements are shown in some logic representations so that they are in machine readable format. Similar to 4W framework, the CrossFlow modeling also focuses more on contract establishment phase. CrossFlow project also supports cross-organizational workflow management in virtual enterprises. Though it defines a service-oriented model for cross-organizational workflows, it does not provide mapping of modeling constructs into workflow and deriving dynamic workflows based on the run-time environment. Textile Value-chain Contract We studied the contract associated with a State Textile Corporation (STC), which is functioning as the nodal agency for one of the State Governments in India, for protecting and promoting the interests of a large number of weavers engaged in self-employment in the handloom sector. This contract involves subcontracts and multiple individual contracts are grouped as a composite contract. This may give rise to both inter- and intra-organizational workflows. STC has established around 28 number of Handloom Production Units (HPUs) spread all over the state. These units interact with weavers to cover their basic needs such as (a) training, (b) supply of raw material, (c) technical support and supply of designs, (d) procurement of finished goods with 46

58 quality assurance. STC markets the products through different showrooms established all over the country, and also supplies to various organizations on their requirements. The head office is the central point for STC to regulate its stocks and material movement. Textile industry is basically a process industry. Applying different processes on the basic raw material produces the finished product, and these processes pass through various stages. At each stage some transformation takes place on the input material, for example, the cotton gets converted into yarns, yarns get weaved into the cloth, the cloth may be dyed, printed and finally sent to showrooms for sale. Weavers and printers carry out the weaving and printing processes, respectively. Raw material supplied by different mills is sent to weavers, and weaved cloth is sent to printers for printing the designs. Finished goods are supplied to different showrooms for selling to the customers while damaged goods are sent back to central store for record keeping. Initially, STC estimates the demand for the product based on the periodic input received from showrooms, orders placed and market trends on customers interests. The projected demand and the existing inventory are used for deciding the acquisition of raw materials. Payments are handled through banks, with fund transfer between (a) customers and showrooms, (b) organizations and STC, (c) showrooms and STC, (d) mills and STC and (e) weavers/printers and STC. A: STC [A-1]. Requirement analysis, [A-2] Inventory management [A-3] Estimation of raw material (yarn) [A-4] Purchase order to Mills [A-5] Shipment of raw material to weavers [A-6] Shipment of weaved material/gray cloth to Printers along with required design specifications. [A-7] Shipment of finished goods to showrooms/institutions/organizations [A-8] Training to weavers on modernization of new machinery/tools C: Weavers [C-1] Receive the raw material, [C-2] Process material [C-3] Supplying the weaved material/gray cloth to D: Printers STC/Printers [D-1] Receive the weaved material [D-2] Process (dying and printing) the material [D-3] Shipment of finished goods to STC E: Showrooms/Institutions/ Organizations [E-1] Send the request for material (cloths) [E-2] Receive the material [E-3] Sell the material [E-4] Inventory management in case of showrooms B: Mills [B-1] Receive the invoice [B-2] Supply raw material F: Banks [F-1] Account Subscription (customership) [F-2] Fund Transfer Table 3.7 Activities of each party for the Textile value chain contract The textile value-chain contract is a composite contract, that is, it involves a number of bilateral contracts. The parties involved are: STC, Mills, Weavers, Printers, Banks, Showrooms and Organizations. These parties will form Who concept in the 4W framework. The contracts are between: 47

59 1. STC and Mills The contract includes the clauses related to raw materials supply, quality, quantity, and payment. There may be time schedules for suppliers to adhere to. Some clauses may indicate direct delivery of raw material to weavers, based on their distance apart. 2. STC and Weavers The contract involves raw material weaving process, and sending weaved material/gray cloth back to STC. There may be some quality requirements and time schedules linked with these activities. The contract also involves training for weavers to modernize with new machinery and tools. 3. STC and Printers The contract is mainly for weaved cloth printing by the printer and delivery of the finished goods to STC. It contains the details about the quality, quantity and designs. These clauses involve the time limits and the handling of damaged goods. 4. STC and Showrooms The contract describes the activities to be performed by the distributors. It involves the activities related to sales, performance, commission, payments and inventory details. Some clauses are related to damage goods. 5. STC and Organizations Organizations such as schools, prisons and public sector companies may request STC to supply specified goods to them. This contract enables direct supply from STC to particular organizations, rather than through showrooms. 6. Inter-bank The contract enables inter-bank transactions for payments. 7. Bank Customership The contract enables an individual or corporate customer to have an account with the bank. It facilitates fund transfer as well as loans to bank customers. Because there are weavers societies, the contract between STC and weavers is actually between STC and group of weavers. Similarly, STC has to distribute the work among different printers depending on independent printer s capability. So, in the textile industry there are different types of contracts, in which a variety of inter-related activities are present. The payments by itself may be handled in different ways. In some cases it may be paid in installments, and in some cases it may be paid in advance. Since CrossFlow project is developed for bi-lateral contracts (useful to model individual contracts mentioned above), however, modeling composite contract and supporting inter-related activities between different contracts have not been dealt by this project. The Process model in CrossFlow meta-model consists of contract activities as Process elements. Table 3.7 shows the activities at each party in the contract. Fig presents the ER EC model while Fig presents workflows (including interorganizational workflows) for the textile value-chain e-contract. Both 4W framework and Crossflow project have not provided the instantiation of conceptual model from their meta-models. This is due to their design objectives, according to which, it has to cover only the concepts that are directly related to the e-contract creation. In addition, 4W framework also considers the e-contract environment which is not part of contract document (ex., concepts related to legal context and precontracting context) but required for B2B e-contracting. On the other hand, the CrossFlow project allows capturing the requirements specified in contract document in a more systematic form and represents it in XML format. Further, CrossFlow enables templates with placeholders to fill the data 48

60 to support repeated contracts such as STC and Printers bi-lateral contract described in Textile valuechain contract. ER EC meta-model described in this chapter allows conceptual modeling of e-contracts at a more granular level relationships when compared with 4W framework and CrossFlow meta-model. Further, our approach provides mapping of ER EC model to deployable inter-organizational workflows. Providing the information about the low level relationships in ER EC model not only helps in proper monitoring, but also facilitates a proper execution plan for contract fulfillment and its successful closure. STC&Mills A-1 A-2 A-3 A-4 A-5 A-6 A-7 A-8 Textile have STC & Printers STC& ShowRooms / Inst. STC&Weavers Bank Customership Inter-Bank B-1 B-2 C-1 C-2 C-3 has CL-1 D-1 D-2 CL-2 D-3 Parties have CL-3 E-1 E-2 E-3 E-4 STC Payments Weavers CL-4 CL-n F-1 F-2 Mill Bank Printer Showroom / organization refer Design not upto the mark Reject No Stock Time Limit Crossed No Sufficient Balance Wait Send Clarification Invalid Account Details Hold Resend Again Exceptions Relations between entity types Relations between instances of different entities Contract Events Output events for exceptions Input events for exceptions Figure 3.14 ER EC diagram for e-contract Textile Value-chain 49

61 Start Requirement analysis Inventory Management Estimation of raw material Purchase order to Mills Shipment of raw material to weavers STC (Activities A -1 to A -8) Shipment of weaved material Shipment of finished goods Training to weavers End Start Receive the invoice Supply raw material End Mills (Activities B-1 to B-2) No stock Time limit crossed Start Receive the raw material Process the material Supplying the weaved material End Weavers (Activities C-1 to C-3) Time limit crossed Start Receive the weaved material Process the material Supplying the weaved material End Printers (Activities D-1 to D-3) Goods not upto the mark Goods damaged Time limit crossed Start Send request for material Receive the material Sell the material End Showrooms/Institutions (Activities E-1 to E-4) Goods damaged No stock Inventory Management Start Account Subscription End Invalid account details Banks (Activities F-1 to F-2) Fund Transfer No sufficient balance Figure 3.15 Workflow for e-contract Textile Value chain 3.7 Summary of Contract examples The ER EC meta-model supports instantiation of model for a variety of e-contracts. In the sections 3.3, 3.5 and 3.6, we described four contract examples namely Buyer-and-Seller (BS) contract, Investment contract, FMS contract and Textile Value-Chain (TVC) contract. The features of these contracts are given below. 50

62 Simple Vs Composite contracts BS, Investment and FMS contracts are simple contracts, where as the TVC contract is a composite contract. Bilateral Vs Multiparty contracts BS contract is a bilateral contract between buyer and seller, where as the Investment, FMS and TVC contracts are multi-party contracts. Sub-contracts Vs Independent contracts There are no sub-contracts in BS contract, where as Investment and FMS contracts have subcontracts. In the case of TVC contract, there are several independent contracts which form as a composite contract. Here, the composite contract is modeled as main contract and all independent contracts as sub-contracts. Type of Contracts BS and Investment contracts are of sequential type, FMS contract is a turnkey type and TVC is a cyclic type. Modeling Events and Exceptions Both input and output events for exceptions are represented in ER EC models shown in this chapter for all example contracts. Contract events among activities are explicitly shown in Investment contract example. 3.8 Summary E-contracts are complex and difficult to understand and facilitating an implementation of e- contracts is not straightforward. Therefore, we have developed a meta-model for e-contracts, namely ER EC meta-model and illustrated example ER EC models. ER EC model is useful to represent the complex inter/intra relationships among entities in an electronic contract. The salient feature of the ER EC model is the conceptualization of instances and constructs, and relationships among them. This advocated the notion of an ER EC model to be a template for a class of e-contracts to be supported by a set of parties. In this case, a particular e-contract may involve some of the parties to engage in fulfillment of the e-contract. Thus, the notion of conceptual model as a template instantiated at runtime is proposed. The points that need to be noted are: 1. The ER EC model is a natural way for modeling e-contracts. The important aspects namely, clauses, activities and parties can be easily conceptualized and their relationships can be modeled. 2. Exceptions to clauses are integral part of e-contracts which needs to be modeled carefully. In ER EC model, we provide facilities to link up contracts and activities, and exceptions are modeled using rules. 3. The meta-model for e-contracts can be augmented to include additional e-contract requirements such as authorization and delegation. We also have shown how an e-contract is mapped to a set of workflows that can be executed by different parties. A methodology for this mapping has been provided along with an illustrative 51

63 example. Thus, ER EC model is one of the first models to facilitate conceptual modeling of crossorganizational e-contracts that are implemented by cross-organizational workflows. The mapping of ER EC data model to WFMC workflow concepts handles workflow support components that are required to execute an e-contract. However, there is a need of augmenting databases and human-supported related activities to provide implementation support for e-contracts. Moreover, it should ensure consistent execution of workflows according to the business processes. In the next chapter, we introduce the ER EC framework and a detailed methodology to support e-contract enactment. We also present semantics for ECA (Event-Condition-Action) rules based on SNOOP language and defined the tables for Rule, Event, Condition, Action and Activity log for distributed ECA rule processing, besides web services support that streamlines data and event support across organizational boundaries of the business partners involved in the contract. 52

64 Chapter 4 E-contract Framework and Methodology As contracts are complex, their enactment is predominantly established and fulfilled with significant human involvement. This necessitates a comprehensive framework for generic fulfillment of e-contracts. ER EC meta-model described in the previous chapter captures the inter-relations among entities involved, such as parties, contracts, subcontracts, clauses, activities, events and exceptions for modeling e-contracts. These modeling constructs are then mapped to workflows in order to support execution of the contract. The ER EC model lets us capture low-level relationships among instances of entity types, which helps us conceptualize the e-contract and facilitate representation of its associated complexities. However, in order to achieve e-contract fulfillment, the system must (i) comply with (and reconcile) business process execution and contractual promises, (ii) modify the workflow process and dynamically generate new workflows based on activity commitments and related clauses, and (iii) monitor and manage the e-contract by handling exceptions and events. Organizations typically require significant human involvement to establish, deploy, and oversee the e-contracts. Likewise, organizations need a comprehensive framework for generic e-contract fulfillment. In this chapter, we present an ER EC framework for designing e-contract processes, a mechanism that allows modeling, enactment and monitoring. This framework centers on the ER EC model that bridges between the XML contract document and web services based implementation model of an e-contract. 4.1 Introduction Even though e-contracts can be specified, 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. Further, there is a need to have a methodology for requirement elicitation from voluminous documents to workflows and rules. The main points considered for an e-contract execution are: a. Association with human beings, who have to make many critical decisions during the e- contract enactment. b. External events, which play a major thrust on the execution of e-contract. For instance, the changes in the taxes may have cascading effect on the pricing issues. c. Exceptions (i.e., deviations from clauses/conditions) raised during the process. d. Sequence of the activities taking place, that is, involvement of several activities to be carried out either sequentially or in parallel. Some activities can also be nested. e. Subcontracts. A contract may have many sub-contracts, each of which is governed by the parent contract. 53

65 f. Composite contract, that is, several independent contracts facilitate a contract. For instance, a textile contract may have independent contracts such as procurement of yarn, weaving, printing and sales. g. Intra- and Inter- organization workflows that support the activities of an e-contract, together with the implementation model with Web Services. h. Handling of Documents This chapter describes a framework that integrates various components to address e-contract e- enactment based on the current state of technologies and approaches. However, at many places, human intervention and human ingenuity is required for the useful solution. 4.2 ER EC Framework and Methodology A layered framework, ER EC framework, has been developed in [RKC 2004, RKD 2005] for modeling and enactment of an e-contract. The Text of Contract Document forms the basic requirement for an e-contract enactment. Figure 4.1 depicts our ER EC framework, which consists of the following layers: 1. Document layer XML-based e-contract specifications, which facilitate document and semantic exchange. 2. Conceptual layer - ER EC meta-model for capturing the inter-relations among entities involved, such as parties, contracts, subcontracts, clauses, activities, events, exceptions, business rules, and so on. In particular, we are concerned with exceptions, events and business rules, which have crucial effects on e-contract enactment and fulfillment. The ER EC model (also referred to as data model for e-contracts) for a specific contract can be instantiated from the ER EC meta-model [KDR 2001]. 3. Logical layer This layer consists of Data Model, event-condition-action (ECA) rules, Activity- Party-Clauses (APC) constructs, workflows and Activity Commit Diagrams (ACD). The Data Model is the core part that enables monitoring of the underlying complexities among the entities involved in a contract. ER EC model represents relationships that are commonly held over various entities within the conceptual model for an e-contract. Additional flexibility is accommodated by customizing an e-contract instance with more relationships and entities specific to an e-contract being modeled. This model also maps the e-contract activities into a set of workflows (as described in chapter 3, section 3.4). There is a mix of entity types and entities (representing instances) co-existing in an ER EC (meta-) model. This special feature is useful in translating an ER EC model to a set of workflows. APC constructs are elicited from XML e-contract document according to the relationships among the entities in the data model. This enables tracking of contract clause violations and raising the corresponding exceptions during contract enactment. ACDs facilitate monitoring of transaction commit/rollback and also maintenance of the event log. The event log records information about the state of the enactment corresponding to both preevent and post-event. It contains the details such as time of the event, action considered and 54

66 which party is responsible. It also keeps track of current status of the execution of the e-contract. Thus, the APC constructs and ACDs together maintain the consistency and transactional aspects during e-contract enactment (transaction commitments have been dealt separately in Chapter 6). 4. Implementation layer It includes Workflow Management System (WFMS), software components and Web Services. The WFMS coordinates the execution of software components for each task together with human interactions required for enactment of the e-contract. Exceptions and their handlers for the e-contract specified in ECA-rules, which are also processed by the WFMS. Inter-organizational interfaces are implemented with Web Services to extend the WFMS s ability to coordinate activities and react to the information received from other organizations. Web Services technology provides loosely coupled standard interfaces among organizations in the form of a set of well-defined functions for both programming and user interfaces. The ER EC model and APC constructs help in specifying the workflows for activities of an e- contract. The ACDs facilitate monitoring workflow execution based on the specifications provided in the contract, as well as the exceptions that may occur during the execution of the workflows. Further execution level semantics are provided by workflow instances. CONTRACT DOCUMENT XML - CONTRACT DOCUMENT Document Layer ER EC Meta-model (template) Conceptual Layer ER EC Data Model APC Constructs Activity Commit Diagrams Logical Layer Workflows ECA Rules Implementation Layer Relation Tables Workflow Instances Legend: Input Process Flow Software Components WFMS Web Services Monitoring & updation Instantiation Figure 4.1 ER EC framework for e-contracts 55

67 Notion of Database supported e-contract enactment The most important aspect of layered ER EC framework is the notion of database supported e- contract enactment. In the document layer, the XML contract document provided tags for contract elements, which are useful to identify the hierarchical relationships among them. This helps in modeling of events, which is a crucial step in establishing ECA rules for event handling as well as exception handling. This layer is also useful to develop a natural language interface to e-contract enactment system. The conceptual layer guides to conceptually represent the e-contract in the form of ER EC data model and helps in capturing application semantics from contract documents. The logical layer is useful to capture execution level semantics. The ER EC data model helps in designing relational tables and also enables mapping of the data model constructs into workflows. APC constructs and ACD diagrams facilitate writing application and database triggers and tracking events that are raised during contract execution. A trigger fires when the corresponding event occurs and some condition is satisfied. The implementation layer provides necessary support for running contract instances such as generate events, monitoring conditions and logging the activity execution. Below we describe a methodology that provides step-by-step procedure how the e-contract enactment is done. Our approach is based on the methodology for database application design promoted by Batini et al. [BCN 1992]. Figure 4.2 shows e-contract process design in which the entire design is basically divides into two parallel segments. One segment corresponds to the conceptual design of an e- contract and the other corresponds to the consistency aspects of e-contract execution. The methodology for supporting e-contract enactment consists of the steps given below. 1. The e-contract document is transformed to XML tagged e-contract document. 2. The main contract and its subcontracts are identified and modeled in our ER EC model. Also, the activities of e-contracts and the dependencies among these activities are identified. 3. A generalization of parties is identified to include the parties relevant for the contract. A set of clauses that need to be fulfilled is identified and incorporated into the ER EC model. A set of exceptions is listed and related to various activities and their handling 4. A set of activities is listed and mapped into workflows. Activity-Party-Clauses (APC) constructs are extracted from the contract document and ACDs are constructed for all activities for monitoring the consistency of the execution. 5. Finally, these activities are deployed as workflows managed and executed by a workflow management system (WFMS). Exceptions and event handling are specified in ECA-rules. Interorganizational interfaces are formulated and implemented with Web Services. 56

68 Contract Document Requirements Collection (subcontracts, parties, activities, clauses, relationships, events, exceptions, etc. ) Contract Model requirements Contract Process Requirements Structural validation Conceptual e-contract specification XML-tagged e-contract specification Conceptual schema (ER EC data model) A P C Constructs A C D Workflow Mapping (Logical Design) ECA Rules Behavior validation Application Design Log records specification Log Records Functional Validation Logical Schema Transactions Physical Design (Relations, Workflow Instances, Applications) Internal Schema Figure 4.2 Process design model for e-contracts 57

69 The text of Contract Document is the basic source for the requirement for e-contract enactment. Extraction of contract process requirements and model requirements consists of following steps: 1. List the set of contracts that need to be automated. For each contract list out: a. The parties involved in enacting the contract b. The activities performed in the contracts c. Clauses that need to be satisfied in the contracts d. The payment terms for the contract execution. e. Deliverables that need to be met. f. Legal issues when exceptions occur or if deliverables are not met. 2. List the composite contracts and/or subcontracts, and for each component, contract information in (1) needs to be collected. 3. For each activity the set of tasks that need to be done is to be collected. 4. For each clause the set of actions that need to be taken when the clause is satisfied, and when it is not satisfied have to be collected (this will help in specifying the ECA rules during logical design). 5. For each party all the particulars must be collected. 6. For each payment all the relevant information needs to be collected. 7. The interaction and relationship among contracts, clauses, activities, parties, and payment terms need to be specified. During conceptual contract specification, an e-contract is conceptualized from the requirements collected by the user through the e-contract document. Once a contract is conceptualized, it is presented in an ER EC model by first handling a contract. The complete contract is modeled as a single ER EC model. After that, the clauses within e-contract need to be fulfilled by executing one or more activities. One or more parties handle each activity. Therefore, in an e-contract, the actual work done is modeled by activities and is fulfilled by parties successfully executing the activities. In other words, clauses in a contract are fulfilled by successful execution of activities by parties. 4.3 Contract Workflow and Consistency Activities are performed by the parties and continuously checked against the concerned clauses during execution of the activity. In order to establish the consistency, it is essential to identify the relationship among the activities, parties and clauses. APC constructs are extracted from the contract document and are specified in XML ( syntax as shown in Table 4.1. The APC specifications consist of three sets of tags, namely, the parties involved, the activities involved and the clauses in the contract. Since each activity is performed by the set of concerned parties bound to the clauses associated with it, tags are provided for exceptions raised during the execution of their respective activity. Sample APC constructs for House-Building contract example is given in Appendix A. 58

70 Party Activity Clauses <Party> <Party Number>..<Party Name >.. </Party> + <Activity> <Activity Number> <Description>. <Start Date > <End Date>. < Previous Activity> <Recurring Time>.. <Next Activity>. <Parties Responsible>..</Parties Responsible> + <Clauses> < /Clauses> + <Exceptions> </Exceptions> + </Activity>+ <Clause> <Clause Number> <Description> <Activity Number>.+...<Party Number> + </Clause> + Table 4.1 APC Specifications We construct ACDs from APC constructs to monitor the transaction commit and to maintain the log. The ACDs represent the sequence of atomic activity transactions and keep the log of activities that are to be carried out. These diagrams drive the workflows during the workflow execution. Any erroneous execution in an activity is thus reflected back so that a new workflow can be generated according to whether a particular transaction is rolled back or not. Once all the activities are successfully completed, the corresponding workflow element will be marked as committed. Therefore, the ACDs ensure consistent, atomic and durable execution of the activities. In order to ensure consistent execution of the workflow, we also use ACDs for intra-activity consistency and activity logging for inter-activity consistency. (Composition model is a formal model for ACDs, which will be covered in chapter 6.) Activity logging is straightforward wherein a log record is generated each time an activity begins execution; and a log record is generated when an activity completes the execution. The semantics of Party1 gives debit instruction to its bank A and party 2 Bank A debits Party 1 account Bank B inform to Party 2 L Bank A send to clearing centre for clearance Bank B credits to Party 2 s account L Clearing instructions will go to Bank B (party 2 s bank) Figure 4.3 ACD for fund transfer activity 59

71 consistent workflow execution are assumed to be implicit in execution of the workflow according to the workflow definition. This is reasonable because these workflows are generated from an e-contract process model which is tagged to a consistent textual contract document. Thus, consistent execution of e-contract is dependent on consistent execution of each activity. This is guaranteed by the logging procedure for intra-activity transactions presented. An activity commit diagram for fund transfer activity is shown in Figure 4.3 as an example. Here, the money is transferred from party 1 to party 2, where party 1 has an account in bank A and party 2 has an account in bank B. In the activity commit diagram, the solid arrows represent the next transaction to be performed and the dashed arrows represent rollback point where transaction(s) have to be rolled back in case that transaction is not committed. Consider the transactions shown in the activity commit diagram for fund transfer activity. The messages are logged for each atomic activity. In case of insufficient balance in the account of party 1, the activity transaction Bank A debits Party 1 account will be aborted and the corresponding message is logged (Logging an atomic transaction is shown with the letter L in the diagram). This transaction is rolled back to the previous activity. Once an atomic activity is committed, the letter L will be replaced by C to indicate that the corresponding atomic transaction is committed. After successful execution of an activity, the corresponding workflow entity will be notified as committed. Thus, the activity commit diagram ensures message logging of activities and thereby proves consistency of workflow execution as per the specifications of e-contract. Each activity can have many atomic transactions, and these atomic transactions tightly integrate with the clauses specified in a contract document. This necessitates dynamic generation and initiation of workflows during the e-contract execution, besides the static workflows. An activity transaction is said to be committed if all its atomic transactions are committed. The interesting feature in an e- contract enactment is that though an atomic transaction cannot be committed at a particular instant of time, it is not necessary to rollback the entire transaction. That is, only few atomic transactions are to be rolled back meaning that the all-or-nothing commit protocol may not hold good for all activity commitment transactions. On the other hand, some of these atomic transactions cannot be rolled back based on the logic involved in clauses. For example, the advance payment transaction cannot be rolled back in case the goods are not received in a stipulated time. In the ER EC model each activity is interpreted as a transactional workflow. Transactional workflow correctness guarantees a consistent overall state if each atomic transaction is executed correctly (or not at all) and there was a consistent initial state. However, in the context of electronic contracts some of the properties may slightly differ. For example, at the workflow level, rollback the complete transaction is not an option; rather we can define it as compensation. The compensation tries to modify an erroneous state such that the consistency is maintained as though the erroneous operation had never been executed. Whenever an erroneous operation happens, the individual atomic transaction is rolled back, and its commitment does not block any of the previously executed atomic transactions. If any activity is not committed the execution of the contract may not proceed further. Given any ACD, log records generation does the required bookkeeping to determine (i) the atomicity of the activity, (ii) adherence to the activity definition to maintain consistent execution, and 60

72 (iii) durability of actions performed in the activity. Therefore, consistent execution of workflows follows, and thus consistent execution of e-contracts follows. Further, the ACD facilitates structural validation, functional validation and behavior validation through mostly human inspection. Specific software tools can be built to automate parts of this evaluation. For example, Petri-net based tools are useful to check for completeness of ECA rule specification for clause validation through reachability analysis. Lee [L1998] and Xu [X 2002] used Petri-nets to represent the events and actions of contracts. The places in Petri-nets correspond to states of each party where as transitions correspond to actions of different parties. Further, these structures are useful to verify the correctness of workflow procedures [AH2000]. In a similar way, Daskalopulu et al [DDM2001] used finite state machines to represent state of contracts and evaluate correctness of contracts. 4.4 Events and ECA Rules Execution of electronic contracts is event-driven, that is, the actions taking place during the contract execution is determined by the occurrence of various events. ECA rules facilitate the monitoring and execution of a contract. A rule has three components: an event, a condition and an action. Rules can be specified on both primitive atomic events and composite events. Composite events, each of which in turn consists of a set of atomic events, are specified as event expressions, which are formed using event operators. Events, either atomic or composite, happen instantaneously at specific points in time. Events are associated with activity transactions and specified to happen after a transaction begins and before a transaction commits/aborts. An event expression maps a time domain that contains only the events at which the event expression is satisfied into a Boolean domain ({True, False}). Event-Condition-Action (ECA) rules are well established in the context of databases, which has the functionality of active capability that satisfies the needs of various applications and timely response to situations. The ECA rules that are to be evaluated during the execution of an activity/task of a contract can be formulated as given below: a. Carefully look into all the statements in the contract document, especially the clauses. b. Extract statements with phrases such as if then else, but, contract violates and other user specified phrases. c. Prepare groups of statements in such a way that each activity/task is associated with a particular group. d. Identify the set of events and actions for each group of statements, and translate them into Event-Condition-Action (ECA) Rules. e. List the exceptions associated with each ECA Rules. Contract Event Semantics An event can be specified by an event expression. A composite event can be specified using the event operators of SNOOP language developed by [CKAK 1994]. For example, the events generated 61

73 for the fund transfer activity can be shown as an And-Or graph (Figure 4.4). The semantics of these operators are given below: 1. Disjunction ( ): E1 E2 occurs when E1 occurs or E2 occurs. 2. Conjunction ( ) : It is of two events E1 and E2 denoted as E1 E2 irrespective of their order of occurrence. 3. Conjunction (Any, All): Any (I, E1, E2, E3 En) I n occurs when any I events out of the n distinct events occur. 4. Sequence (;) : E1;E2 occurs when E2 occurs given that E1 has already occurred. 5. Aperiodic event operator ( A, A*) : allows for the specification of an aperiodic event bounded by the occurrences of two arbitrary events(defining an interval of time ). 6. Periodic event operator (P, P*) : allows for the specification of an event that repeats itself within a constant and finite amount of time 7. Not ( ) : it detects the non-occurrence of the event E2 in the closed interval formed by E1 and E3. It is denoted as (E2)(E1, E3). As contract enactment and monitoring involves parties at different locations, we also have to keep track of the locations associated with the events, the condition evaluation and the execution of actions (as shown in the Tables 4.2 to 4.6). As such, distributed ECA rule processing can be facilitated as further presented in our implementation architecture in section 4.6. Take Instruction Debit instruction from P1 to bank A Amount = not available Check Party 1 account amount = available Debit Party 1 account Start Check Time out Request additional Information Check Time out Send to clearance center for clearing Instruction to P2 from P1 Stop Information incomplete or false Amount credited to party 1 Information to clearance center Amount credited to party 2 Party 2 account = not available Clearance information to bank B Party 2 account = available Information to party 2 Figure 4.4 And-Or Graph of Event level Specification of Fund Transfer Activity 62

74 Figure 4.5 shows the And-Or graph of event level specification for material supply activity. The fund transfer activity is a composite activity here (shown in bold ellipse in the figure). Note that the distributed events have to be specified carefully and their dependencies have to be monitored during e-contract execution. This is because rules will be triggered when one of its associated events occurs and, if their execution depends on other rules, clause violation or conflicts may arise, or even deadlocks may occur. Start Stop Find Suppliers Accept Reject No Quotation received Revise the specification Get quotation and/or products information Received quotes are in the required order No matching quote received Evaluate and Select the quote Request for additional information Send to supplier for acceptance Information missing Not Confirmed Material is in order Fund Transfer Send the payment invoice Check Time out Confirmed User Evaluation Send the material Material is not in order Arrange the shipment Prepare the Material Figure 4.5 And-Or Graph of Event level Specification of Material Supply Activity Consider an example of fund transfer activity. The semantics of some of the events of this activity is as follows: 1. E1 :Party 1 gives the instruction to its bank A and Party 2 SEQ(P1; BA P2) ( Debit Instruction) 2. E2 : Bank A debits party 1 account SEQ(BA;P1)(Debited). 3. E3 : Bank A send to clearing center for clearance. Event P( amount, clearance center*). 4. E4 : Clearing instruction will go to bank B Event P(Clearance center, instruction*) 5. E5 : Bank B credits to party 2 account SEQ(Instruction; credited to party 2) 6. E7 : Bank B inform to party 2 SEQ ( credited; information to party 2 ). 63

75 An ECA definition table is defined as follows: RuleTable (Rule id, Event id, Condition id, Action id, Source location, Rule evaluation location ) Event (Event id, Event Type, description, object Affected,Rule Fires, Event evaluation location) Condition( Condition id, Condition Type, description, Condition evaluation location ) Action (Action id, Action Type, Description, Object Affected, Event Raises, Action performed location) Activitylog ( Time, event, object, Prev Action, Post Action) The commit and rollback information is updated in the ACD of the corresponding activity, which are used to guarantee the completion of transactional event. Usually, the execution of an e-contract includes distributed events. These distributed events can be handled by sending the source of "and-or" composition to the target site of the condition evaluation. For instance, Xu and Jeusfeld [XJ2003] presented commitment graphs along with the semantics of a contract based on temporal logic to detect and monitor the contract violations. Consider the four atomic events: start of account 1 debit, finish of account 1 debit, start of account 2 credit and finish of account 2 credit. The semantics of these can be written as follows: A3 : SEQ( A4, (C6 Λ C7) ) A4 : SEQ( A2, (C2 Λ C4 ) ) A2 : SEQ(A1, C4) A5 : SEQ(A3, C7 ) In our approach, the combination of ECA and ACD framework ensures the guarantee for the completion of transactions, and also provides consistency when a contract violation occurs. Contract activities and clauses are analyzed and then transformed into a set of ECA rules (see Table 4.2). The set of ECA rules collectively formulates a representation of contract clauses for subsequent enforcement as well as enactment. Enactment rules are triggered to invoke necessary actions on time, while enforcement rules are triggered when there is deviation from clauses results. The internal and external events are listed as shown in table 4.3. When an event occurs, it triggers corresponding rule(s) (see table 4.3) and the condition parts of these rules (as defined in table 4.4) will be evaluated. When the condition is satisfied, the action part (table 4.5), which is a workflow in our work, will be executed. The actions in the rules may update the state of the business entities, which in turn may trigger other events. During the execution of workflow activities, these details are logged as shown in table 4.6. The execution of activities may further lead to other events, such as exceptions. The following procedure describes how the system behavior can be processed: 1. There is a start event according to the contract semantics (example, start event, occurs when contract enactment started). 2. List all rules, which are triggered by this event. 3. Create an ACD with all actions that are contained by the rules obtained in step List all events, which can be occurring during the execution of actions of step If necessary, add actions or events that may arise due to external environment and not mentioned in the contract. 6. Link the control flows across actions, respecting the event triggering chain. 64

76 7. Keep track of the sequence of executing actions (for backtracking) 8. During the execution of Actions a. If action failed then perform rollback (from restart point specified in ACD). b. Do consistency check by handling appropriate enforcement ECA rules (for clauses violation) or exception handlers in case of exception c. Mark the states of executing actions (committed, rollback) 9. Repeat from step 2 until all the rules are processed. Rule id Event id Condition id Action id Source Location Rule Evaluation Location R1 E1 C1, C2 A1 L1 L2 R2 E2 C3 A2 L1 L1 R3 E3 C8 A3 L1 L1, L2 R4 E4 C9 A4 L2 L1, L2 R5 E5 C7 A5 L1 L2, L1 R6 E6 C4 A6 L2 L2 R7 E7 C10 A7 SYS L2 Table 4.2 Rules Definition for Fund Transfer Activity Event id Event Type description object Affected Rule Fires Event evaluation Location E1 Trans(instruction) Start(T1) Party 1 R1 L2 E2 Ext (signal) Finish(T1) Party 1 R7 L2 E3 Trans(instruction) Start(debit account) Account debited R5 L1 E4 Trans(instruction) Start(credit account ) Account credited R6 L2 E5 Trans(instruction) Finish(debit account) Account debited R4 L1 E6 Trans(instruction) Finish(credit account) Account credited R3 L2 E7 Ext (signal) Time out Party 2 R7 Sys Table 4.3 Event definition for Fund Transfer activity Condition id Condition Type Description Condition evaluation Location C1 Transaction Available(Bank A) L1 C2 Transaction Available(Party 1) L2 C3 Db Accepted (Party 1 instruction) L2 C4 Transaction Available ( Party 1 account in bank A) L1 C5 Transaction Available ( Bank 2) L2 C6 Transaction Available( Party 2) L2 C7 Transaction Available(party 2 account in bank B L2 C8 Db Updated Party 1 account L1 C9 Db Updated Party 2 account L2 C10 Transaction Time out Sys Table 4.4 Condition definition for Fund Transfer activity 65

77 Action id Action Type Description Object Affected Event Raises Action performed Location A1 Trans(instruction) Finish (T1) Party 1 E2 L1 A2 Trans(instruction) Start(debit account) Account debited E4 L1 A3 Trans(instruction) Start(credit account ) Account credited E6 L2 A4 Trans(instruction) Finish(debit account) Account debited E4 L1 A5 Trans(instruction) Finish(credit account) Account credited E1 L2 Table 4.5 Action definition for Fund Transfer activity Time Event Object Prev Action Post Action T1 E1 Bank A database NULL Available T2 E3 Party 1 Available Updated T3 E4 Bank B database NULL Available T4 E5 Party 2 Available Inserted Table 4.6 Activity log definition for Fund Transfer activity In this work, the consistency aspect of an e-contract is handled through ACDs, which illustrates a procedure (or a workflow) for a set of actions. A state in this type of graph represents an (atomic) activity (i.e., an action). A transition from one state (source) to another state (target) is triggered by completion of the activity in the source state. The synchronization between different events raised during execution is controlled through distributed event processing. When the trigger event occurs, one or more target states become active (as depicted in And-Or graphs in figure 4.4.). This triggering event is the completion of the source state activity or the receipt of a new data object. Detailed activity transaction commitments such as compensation and re-execution are dealt in our composition model in chapter Workflows The production of workflows according to the changing requirements during the e-contract execution is a major challenge. Hence, there is a need for workflows to ensure the consistency of e- contract. Since, these workflows are to be generated at run time, there is a need for dynamic workflows (see Chapter 3). The use of dynamic workflows is two-fold: (i) adaptation to new requirements during the execution, and (ii) for maintaining consistency of the execution. Workflow instances are produced based on the start/commit/rollback of a particular activity execution. The tight integration among the components of process model helps monitor the execution of a contract and thereby useful for deployment of e-contract. The workflows in the process design handle most of the productionized e-contracts. Usually, most of the contracts involve parties from different organizations and a business process spans over 66

78 inter-related cross-organizational workflows. Workflows support this type of cross-organizational workflows and are essential for enforcing a contract. Workflows can also be generated based on the situation. A workflow is dynamically composed based on the current status of e-contract execution to facilitate further processing of the e-contract. This is essential for turnkey e-contracts wherein the e-contract itself evolves over time. Further, exceptions can occur during the e-contract execution and instantiate new workflow instances. The execution of specific workflows depends on the execution of previous workflows, transactions commit/rollback and the exceptions that are raised. However, in certain circumstances, human intervention is required to take a decision and accordingly a new type of workflow may need to be generated for the fulfillment of e-contract. The application design includes a set of new applications that would cater towards automation of e-contracts are specified. This process is similar to building applications on a database system. In e- contracts some of these applications could be triggered or initiated by the workflow tasks. In logical schema design and transaction design step, SQL statements are specified for transactions on a database system. These transactions could be embedded within the workflow tasks. The physical design and internal schema deals with schema specification for databases supporting the e-contracts, workflow specification, and other event specifications that automate the e-contract enactment. Note that these specifications are fairly routine specifications which can be automatically generated from the conceptual specification of e-contracts. 4.6 Implementation Architecture In this section, we present implementation architecture for the ER EC framework and outline the Web Services design required for inter-organizational communications during contract enactment. System Architecture Figure 4.6 depicts the implementation architecture for the ER EC framework. The six main modules for the ER EC Contract Support System are as follows. 1. Contract Document and Template Manager maintains the contract templates and contracts in its original form and in XML format. It also assists the administrators to code contracts into XML format. Here, the XML format is used for transmitting the data. 2. APC Specification Manager maintains the APC specifications and their consistencies with reference to the relevant contract clauses, parties, and activities, as discussed in the previous sections. 3. ACD Specification Manager maintains the Activity Commit Diagrams and their consistencies with the related workflows and contracts. 4. Workflow Generation / Specification Subsystem generates workflows and rules from APC and ACD specifications. It also allows the administrators to customize and edit them. Workflow definitions created are to be executed in the E-ADOME (E-Services based Advanced Object Modeling Environment) workflow engine [CKLK 2002]. 67

79 5. ECA-rule Manager keeps track of generated rules with their corresponding actions and allows users to define additional rules if necessary. 6. Contract Enactment Monitor receives events and results from the workflow engine, application specific components, and external business partners through Web Services interfaces. In addition, the ER EC Contract Support System requires the following software components and facilities in order to function. 1. Relational Database is required as the backing storage for the data and metadata for contracts, workflows, rules, and the application, etc. 2. Application Specific Components are required for encapsulation and realization of the domainspecific logic for the application specified by the contract. We are using Enterprise JavaBean (EJB) components [DDGLSZ 2003] in our prototype for its strong Web, database, and interoperability support. Our intention is to support and integrate with existing software components to minimize the cost and effort for the implementation. 3. Web Service Server provides the services and transport of inter-organizational communications among business partners involved in the contract. 4. E-ADOME Workflow Engine executes the workflow specified or generated from the EREC Contract Support System. E-ADOME [CKLK 2002] is chosen for its strong support for specifying, executing and monitoring inter-organizational workflows and the key features are as follows: (i) effective coordination of agents (both software and human agents) and an objectoriented capability-based approach to match activities and agents; (ii) automatic resolution of expected exceptions and exception driven workflow recovery; (iii) dynamic binding of exception handlers to activities with scoping, and to classes, objects and roles; (iv) addition, deletion and modification of exception handlers at run-time through workflow evolution support; (v) specifying and reusing exception handlers upon unexpected exceptions and systemassisted exception handling; and (vi) application of workflow evolution and workflow recovery in exception handling. Web Services Support To manage cross-organizational collaborations, we need collaborative arrangements among contracting parties. This warrants more transparency of data and processes, as well as of parties performance. Web services [DDGLSZ 2003] technology supports reusable business processes across distributed and heterogeneous environments and gives organizations loosely coupled standard interfaces through a set of well-defined functions for both programming and human-user interfaces. Web services provide inter-organizational communications services and relay among contracting business partners. In particular, they can communicate events and data through Web services, using a publish-and-subscribe mechanism as the fundamental contract-enactment support across organizational boundaries. Three basic Web Services, viz., for publishing events, for receiving events, for subscribing events, are identified as shown in Table

80 Business Partners Public UDDI Registry Internet Intranet Web Service Server Contract Document and Template Manager ER EC Contract Support System e-contract APC Spec APC Specification Manager Application Specific Components ACD Specification Manager Contract Enactment Monitor ACD Spec rules rules Workflow Generation/ Specification Subsystem ECA Rule Manager Rules Workflow Spec. Rules. E-ADOME Workflow Engine events Results Events Database for e-contracts, Workflows, Rules, etc. Figure 4.6 Implementation architecture for ER EC framework The publish Web service sends an event to relevant business partners. The input parameter is the occurred event or exception. Based on this, the Web service checks the subscribers list, the security policies and notifies the subscribers. Notification can be performed via different kind of protocols like , fax, ICQ message, or even an invocation of another Web service. How the subscribers should be notified is specified during the previous subscription process via the subscribe Web service. The publish Web service can be a composite Web service, which uses different Web services for various ways of transmission. The subscribe Web service registers requests for an event subscription including several parameters such as the requester, the subscribed event, and how the requester wants to receive the event notification. In a real application scenario, one non-dedicated subscribe Web service is sufficient. However, it is also possible to provide a Web service for each event. This is also true for the receive Web service. A non-dedicated Web service can parse the incoming message and invoke other Web services or components based on the message sender, event type or event name. Alternatively, dedicated event receiving Web services may be invoked directly by the event publishing party or by a message queue handler after receiving an message. With these Web services based support, organizations can also send primitive events (when required) among business partners at different sites to generate the requisite composite events. Such events can then cause an e-contract system to evaluate an ECA rule s condition for fulfilling the contract activities (see Table 4.4). If the condition is evaluated to be true, the system can trigger the action for execution through a target Web Service. A unified Web services infrastructure thus lets us streamline distributed events and ECA rule processing. 69

81 Publish Web Service Input: EventReceivingAcknowledge EventReceivingAcknowledge Output: EventMessage Date Sender Receiver Event o Event name o Event type o Event subject o Event message body o Prio Subscribe Web service Input: SubscriptionRequest Eventprovider o Name o Address o SubscribedEvent NotificationParameter o transmissionport o TransmissionParameter (like fax icq number...) Output: SubscriptionResponse SubscriptionResult Receive Web Service Input: EventNotification Date Sender Receiver Event o Event name o Event type o Event subject o Event message body Prio Output: EventReceivingResponse EventReceivingAcknowledge Table 4.7 Basic Web Service Specifications for Inter-organization Communication Support To further streamline interactions among enterprises, application layer semantics (such as content taxonomy and category definitions), protocols for interaction, and service-level standards are called for. Trade unions and regulatory bodies may help in such standardizations and service grids can be formed for seamless and large-scale interoperation in the future. The utility of the presented approach is in: Storing and managing e-contract elements Potential for automatic generating and deploying workflows for e-contract enactment Analyzing what-if scenarios with respect to e-contract clause violation. In the e-contract context, there is some research in comprehensive contractual description of Web services, including WSLA Framework, WS-Agreement, WS-Policy, Semantic Web Services, and Web Services Modeling Framework ( for example, [IST 2009, BHJ 2009] ). 4.7 Summary The implementation architecture for the ER EC framework has been designed in such a way that the ER EC contract support system can be plugged into and interoperate with existing application software component or systems. Further with the implementation based on contemporary Web Services, it streamlines data and event support across organizational boundaries of the business partners involved in the contract. In addition to component software and WFMS support, wrappers may be built around legacy systems to enable compatibility with Web Services. To create a framework, we categorized the deployment challenges into four layers document, conceptual, logical and implementation. The ER EC framework addresses the mechanism for modeling, enactment and monitoring e-contracts effectively. It bridges the gap between the XML contract 70

82 document and Web Service based implementation model of an e-contract. Further, this enactment system supports dynamic modifications to the model during deployment of an e-contract upon mutual agreement of the participants. Web Services shield most of these modifications from crossorganizational interfaces among external business partners of the e-contract. Thus, flexible enactment and fulfillment can be achieved. We also introduced Activity Commit Diagrams (ACD) from APC constructs to ensure consistent execution of e-contract by monitoring the transaction commit and maintaining the logs. The e-contract methodology described in this chapter is iterative and driven by structural, functional and behavioural validation steps. Structural validation checks the conceptual model s correctness while it models the e-contract requirements. Functional validation ensures that e-contract requirements are met and mapped to e-contract functionality. Behaviour validation ensures the consistency aspects according to the requirements. In the real world, a contract may evolve over a period of time due to changes in the design-time and run-time environment. So, modeling of an e-contract should provide provision to keep track of mini-world and run-time changes. In the next chapter, we enhance our methodology to support the changes occur during design-time as well as run-time (enactment) of e-contracts. Since, e-contracts are complex in nature, a more effective way of handling the evolution can be achieved through metamodel. Meta modeling helps in adapting a data model to new requirements. We develop an active meta-modeling approach by introducing the taxonomy of evolution operations and handling metaevents in order to facilitate the structural and behavioural conformance of modeling of e-contracts evolution. 71

83 Chapter 5 Modeling Evolving E-contracts The methodology presented in the previous chapter assumes that all the requirements are known before enactment of an e-contract. However, e-contract evolves over a period of time and there are many scenarios of changes in e-contract environment (mini-world) that can adversely affect the execution of e-contracts. Hence, there is a need for evolution operations for e-contracts that can be applied to conceptual model, which can be propagated down to the logical and implementation levels. This chapter addresses the operations and methodology to support evolving e-contracts by enhancing the capabilities of ER EC model. 5.1 Introduction Due to technology advancements, new market requirements and new laws, organizations need to constantly refine their contracts in order to effectively meet the changing constraints and opportunities. Many of the changes or expected exceptions with respect to evolution of business environment may not be available to model the business processes when they were first envisaged. This is especially true in the case of e-commerce and e-business applications. For example, in an e- contract system, a contract statement On receiving the request, Contractor will allocate a CMR (Change Management Request) number to that request and will notify it to the Purchaser. The contractor will then evaluate the need of this change with respect to Priority, Feasibility of the change, and Impact on time frame and cost. is not clear to model it unless the actual change is provided to the system. This can happen only during the enactment and it requires changes based on the new change request. Thus, modeling a complex application at first instance does not reflect a complete scenario. This calls for an iterative active methodology that constantly monitors run-time environment and changes in real-world specifications to keep the deployed applications/processes current. Chen et al [CTW 1999] presented several important research directions in conceptual modeling. It was stressed that data changes and schema changes in the real-world and at any given time, a conceptual model can be as a multi-level and multi-perspective abstraction of reality. This direction motivated us to develop evolving conceptual models. The ER EC model described in chapter 3 provides a meta-model for describing the data, relationships and the associated information such as rules and exceptions to support modeling electronic contracts, and the e-contract meta-model serves to build a model of models for e-contracts. Since, e-contracts are complex in nature, a more effective way of handling the evolution can be achieved through meta-model. Meta modeling helps in conceptualizing the data models and provides required facilities to support functionality for adapting a data model to new requirements. In this 72

84 chapter, we present ER *EC methodology, which enhances the capabilities of ER EC model, for evolving applications. First, we develop an active meta modeling approach by introducing the taxonomy of evolution operations and handling meta-events in order to facilitate the structural and behavioural conformance of modeling of e-contracts evolution. Active meta modeling enables upkeep of metamodel and the corresponding mapping requirements at run-time due to changes in e-contract environment or exceptions that arise at run time, or changes initiated by users. Next, in the context of this work, the role of two-way active behaviour and template driven development of applications is presented. This methodology facilitates capturing active behaviour from run-time transactions and provides a means of using this knowledge to guide subsequent application design and its evolution. The manifestation of this methodology to be implemented for a complex application would require appropriate level of effort and human inputs along with design and deployment tools. We use the term template to refer ER EC meta-model with constraints for a specific application, and sometimes used it interchangeably with the term model for easy interpretation. 5.2 Supporting Evolving E-contracts E-contract evolution is a basic step towards flexibility in e-contract enactment systems, which requires a consistent and effective monitoring of workflows of parties while they are executing. There are two approaches for meta-modeling for evolving applications: (i) Lazy approach and (ii) Eager approach. In the lazy approach, the meta-models need to be modified on demand. On the other hand, the eager approach facilitates the active modeling of meta-models based on the events or exceptions raised during the application execution. In the eager approach, the events arise during run-time are recorded and adapt the meta-models based on the behaviour with the help of ECA rules. For example, when there is an event for change in the ordered goods specification; the corresponding ECA rule - Event: OnGoodSpecificationChange, Condition: NotOccurred(Delivery), Action: Perform AlterSpecifications and Resend considers this as temporal external event and adapt the meta-model accordingly to incorporate the new specifications. In this work, we focus on active meta-modeling approach for e-enactment of evolving e-contracts. In order to handle e-contracts in a dynamic environment, the ER EC model has to be instantiated by invoking the most appropriate model (if possible) that best meets the requirements of the changes. In this chapter, we have addressed the intricacies involved in supporting evolving e-contracts through an active meta modeling framework. This framework captures the active behaviour (due to run-time and design-time environments changes) of e-contracts during its enactment and models it through meta- ECA rules. The changes required in the meta-model are handled through a set of operations and metaevents that need to be propogated to logical level by specifiying the evolution polices and behaviour for these changes. Figure 5.1 shows a macro level description of e-contract evolution. There are two major factors that influence the contract evolution namely, the changes in the e-contract design-time environment and the changes in the e-contract run-time environment. Here, the design-time environment (i.e., 73

85 mini-world) refers to the e-contract environment that is influenced by factors that affect e-contract enactment (for example, legal, government and social implications). Design time environment change: Any change in the parameters in the design-time environment generates necessary stimuli to initiate actions to modify the ER EC model. For example, an increase in the service tax in a new budget may affect the payment conditions in a contract. The e-contract enactment must appropriately handle such changes for proper execution of the contract. Therefore, ER EC model gets adapted by the actions to conform to the changed design-time world. Run-time Environment change: The e-contract run-time environment manages and keeps track of the contract clauses and activities of various parties involved during its enactment. During the execution of a contract, there may be deviations in the clauses or exceptions in the run-time environment. For example, non-delivery of goods by a specified time may lead to a clause violation. Similarly, a network failure (an exception) may prevent an electronic fund transfer in time. Such exceptions or clause deviations need to be handled during e-contract enactment. This necessitates that the ER EC model has to adapt to incorporate such occurrences and provide a remedy for continuing the contract execution. ER EC Model Remedy Exceptions/ Clause violations E-contract Run-time Environment Stimuli/ changes Conformance E-contract Design time environment Figure 5.1 E-contract enactment at macro level Usually, a well-defined conceptual model leads to the development of an effective and reliable application. An application system design usually follows developing conceptual model, logical model, physical model, implementation architecture and finally deployment of system. In today s business environments, it is necessary to envisage and understand the operations of business processes and changes that occur during its lifetime. Further, the e-business applications mostly involve multiple organizations and multiple parties. This necessitates the need of active behaviour to synchronize the changes in business logic and business processes across different levels of conceptual/logical models. During e-contract system design, the requirements are collected from the contract document and the e-contract elements such as parties, activities and clauses are extracted to model an e-contract. Workflows will be identified to execute the activities carried out by different parties. However, changes in mini-world and run-time during e-contract enactment need modification at conceptual level as well as at logical level. 74

86 5.3 Template Driven Modeling A template typically has a set of fixed concepts to describe various requirements, specific entities that have specific meaning of entities (such as party and payments), built-in relationships, set of constraints, set of rules, a mapping methodology and consistency requirements. In the context of e- contracts, we consider a template as an instance of a meta-model for a specific application domain (with certain constraints). Constraints help in ensuring integrity, reliability and consistency of the models for an e-contract application during its entire life cycle. Templates contain a number of template variables (ex. date variable in penalty clauses) and the constraints allow placing correct values in the placeholders for a given contract. Also, templates are refined based on the experience with previous contracts in a particular domain, so they are more reliable. Thus, templates enable reusability and flexibility to model variety of scenarios. Templates provide the ability to define models on the basis of available information, where the full specification/design is made at a later point of time (say during run-time). Advantages of template driven modeling are: Templates helps in visualizing the artifacts from a real world applications Templates guides the modeling and enactment processes. Templates allows flexible support for a variety of processes (by considering only suitable concepts, leaving others) Templates can be extended by adding more concepts Templates helps in keeping track of multiple versions of templates used in execution Templates help in building standard templates (or template library) over a period of time for each domain. Specifically, for e-contract applications the base ER EC model starts by initiating a template from ER EC meta-model and drives the e-contract application. The template contains the semantics of the application. Different semantics can give raise to different scenarios of application. Modeling of applications requires both human and system driven specification and deployment in order to handle the active behaviour of applications. A problem of current interest is to manage movement from one template to another at run-time or even evolve the template (to meet new requirements of modified e- contract), if required. This work uses a suite of ER EC Models, referred as ER *EC meta-model, and its corresponding methodology, which act as a template for modeling the change requirements during application evolution. It models data and process/functional requirements of an application. But in general, the execution of an e-contract is influenced by various factors, some of which may not be envisaged during the requirements analysis. In order to handle such applications in a dynamic environment, an ER *EC model has to be instantiated by invoking the most appropriate template that best meets the requirements of the changed environment. 75

87 5.4 Scenarios for E-contract Evolution In general, a data model is a set of concepts to describe a database schema. ER EC model is a set of concepts to develop an enactable e-contract. During evolution of an e-contract, the ER EC model is able to incorporate the changes occurred and sometimes it may require addition or modification of a concept. In this section, we discuss on several possibilities that may arise during e-contract execution which may eventually require a change in the ER EC model. While an e-contract is being enacted, the parties involved, the clauses, the ECA rules may change dynamically because of changes in the miniworld and/or in the run-time environment. Further, in the changed scenario, an e-contract may require one or more subcontracts for its enactment which are not envisaged at the beginning of the e-contract execution. In order to visualize such revisions in the e-contract scenario, the ER EC model has to adapt appropriately. This further requires translation of e-contract instances to deployable workflows. Hence, e-contract deployment necessitates an appropriate model management at multiple levels. Below we discuss three possible scenarios to deal with conceptual modeling for reflecting the changes during e-contract evolution. Scenario 1: A model can be instantiated and necessary modifications can be made on it depending on the revised scenario (figure 5.2). Such an approach is suitable only when there is a change in the number of entities involved. Here, there is no major structural change in the model. Consider an example of a contract between a borrower and the bank related to housing loans (This contract is a part of main contract House-Building and the details can be found in Appendix A). This contract is a long-term contract, say, for 20 years. The borrower can opt for either fixed or floating interest rates for the loan. According to the contract the monthly repayment for the loan is to be made by borrower. In case the borrower becomes defaulter for more than a specified period, then the bank contacts the guarantor to repay the installments. Here, the role of the guarantor has changed to borrower. Thus, a new template is instantiated by modifying the role of the party Guarantor. Similarly, an increase/decrease in the interest rates leads to a different set of clauses to be followed. This may result in add/modify the clauses. ER EC Figure 5.2 ER EC Model Instantiation Scenario 2: An e-contract may require one or more additional model elements (for example, subcontracts), which are to be incorporated in the model. 76

88 This can be possibly be handled by maintaining a set of ER models corresponding to several possible application scenarios and then instantiating a model from the most appropriate ER models (figure 5.3). In the event of a change, one can move from an instance of one model to an instance of another model which can further drive the e-contract enactment. ER 1 EC ER 2 EC ER p EC Figure 5.3 Model instantiation from multiple ER EC models Suppose that every loan is associated with insurance in the borrower-bank contract. In the event of death or any disability of the borrower, the original contract will take a different shape in the form of a new sub-contract between the bank and insurance company. This sub-contract may require a different set of parties, activities, clauses, etc. Further, it may have few sub-sub-contracts to meet the requirements such as police verification, medical certificate etc. Under the changed circumstances, the original model has to be replaced or augmented with an instance of another model. Scenario 3: The change could evolve the template itself. By this we mean that one can always use a standard ER EC model and instantiate a model when an e-contract is enacted, but as time progresses, to cope up with the changing scenario, evolve the model by adding or modifying the schema concepts. However, this approach is difficult to implement, as it requires complete structural changes within a model. Consider a situation wherein a house built with the loan amount has to be dismantled due to expansion of a road. In this case, the government has to compensate a prescribed amount to the borrower for the portion of the house that was damaged. Here, not only adding a party (i.e., government) takes place, but also the policies that govern different activities changes. This necessitates generation of new set of models and possibly requires adding new concepts (for example, dependent event concept) to the ER model. The above scenarios are not exhaustive. More scenarios may arise which leads to more complex ER* EC ER 1 *EC ER 2 *EC ER p *EC Figure 5.4 ER *EC model 77

89 cases that determine appropriate evolution of the e-contracts. Table 5.1. shows possible changes needed in the meta-model for different evolutions: We combine the first two approaches and introduce the concept of a Global ER EC model (Fig. 5.4), referred as ER *EC [RK 2007a]. This ER *EC model can be thought of as union of all ER EC models which can deal with different e-contract enactments. Formally, ER *EC = {ER 1 EC ER 2 EC. ER p EC } where, p is the maximum number of available ER EC models at a given time. Here, each ER EC model is considered as one element (or object) and the union operator keeps all the ER EC models as a set. In case a new ER EC is developed for a specific application it will be added to the set using union. In this way, the Global ER EC will grow. Evolution Characteristics Possible changes in the meta-model New policies and legislations, and unforeseen Adding a new construct to model scenarios Changes of the enterprise organization and operation strategies Change in parties and their roles, activities or clauses Sub-contracting Adding a new subcontract Influence of internal and external factors such as mergers and acquisition Merging two or more contracts Activating/de-activating some of the constructs Change in the parties role Activating/de-activating roles of parties Updations in Quality of Service parameters Adding or modifying clauses and corresponding relationships with other entities New dependencies between contractual Updation in relationships and constraints elements Table 5.1 Meta-model change requirements during evolution As and when situation demands, due to changes in the e-contract enactment scenario, an appropriate model can be instantiated from a ER EC model (which is a subset of the ER* EC model) in order to seamlessly model the data and processes. This way of adapting an ER *EC model can be visualized as having a global model comprising of all the concepts such as entities, attributes, relations, and aggregations to act as model elements that are required in various possible execution scenarios. To start with, at the beginning of execution, the most appropriate model elements can be activated and as time progresses, in the event of any change, some of the model elements can be deactivated and some other can be activated to meet the requirement. This gives rise to a new instance of the model that is used in the changed context. New model elements are added in case there is no suitable concept available. That is, model elements are added or modified based on the active behaviour of business transactions during their execution due to run-time changes or mini-world changes. Here, we highlight that how ER *EC model can serve both as a manifestation of conceptual as well as logical model for enactment of evolving e-contract. This is a feature which provides the power of both treating the model as a conceptual description, and also as a model that can be manipulated as a logical database. 78

90 5.5 Active Meta Modeling for E-contracts Usually, the parties agree on terms and conditions (clauses) of a contract before starting execution. However, a contract process does not describe a concrete work procedure but provides abstract representations of rules and clauses [IJK 2004]. When a dispute occurs or an exception is raised, parties in the contract arrive at a mutually agreed process to fulfill the contract enactment. Moreover, contracts are governed by laws established by the government or rules specified by the society concerned. As a contract may evolve over a period of time due to changes in the mini-world, it necessitates design of generic models that abstracts the details of the supporting infrastructure. Figure 5.5 shows our approach to deal with active meta-modeling for enactment of evolving e- contracts [RK 2007b] and is described in subsequent sections. The main engine for supporting execution of e-contract is the context sensitive instance of the meta-model shown as data model in figure 5.5. The two validations, namely, structural and behavioral ensure that the run time environment is consistent with the design specifications. If the run-time environment is not consistent or design-time environment changes - the meta-eca rules kick-in and select appropriate data model or in the worst case modify the meta-model to meet the new requirements. Structural validation Metamodel Changes Behavioural validation Meta- ECA Rules Data model Changes in the Business logic (miniworld & Run-time) e-contract execution environment Figure 5.5 Active meta-modeling of e-contracts In the following, we (i) illustrate when e-contract needs to evolve, (ii) the occurrence of this evolution at different levels of traditional three-schema architecture, and (iii) how the manifestation of the evolution through a set of operations is presented Support for evolving e-contracts Deployment of e-contracts poses challenges at conceptual level, logical level and implementation level (like traditional three-schema architecture). Also, the changes in the factors influencing the contract execution require changes at one or more levels. The factors that need to be handled during e-contract evolution include the following: 79

91 At conceptual level: Certain clauses are modified during the contract execution of the contract either by the will of the parties involved or by force of law Unpredicted events render certain clauses practically or legally vacuous or contradicting clauses Exceptional situations arise, for which the contract explicitly defines what should be done. For example, in a housing-loan contract, if the debtor fails to pay, then the guarantor is called to do the payment. At logical level: Changes in the database schema and workflow schema Version maintenance of schemas Conflicts between different schemas Generating/modifying ECA rules when unpredicted events occur Handling of exceptions At implementation level: Generating new workflows based on the changes in the clauses and occurring of new events Handling of exceptions Relating workflow activities dynamically to the contract clauses that are modified during enactment. Here, our focus is on modeling the active behaviour of e-contracts through evolution operations, meta-eca rules, evolution policies and behaviour validation at conceptual and logical levels. The proposed active meta-model approach facilitates handling/propagating changes to lower levels. That is, we considered one more level, namely meta-model (or meta-schema), in addition to the three-level schema architecture that is often used in the design of database applications. The conceptual level changes are handled through sequence of operations and meta-eca rules as described in the section Whenever a change occurs, first the current meta-model is checked whether the change can be handled by instantiating a new instance. Otherwise, a new conceptual model (template) is evolved. The operations must be applied atomically and in the specified sequence in order to handle the desired change. Though application of any sequence of operations generates syntactically correct model, however if the operations are not applied in the specified order, the resulted model behaviour may not be in agreement with the changes needed. The logical level changes are handled through the evolution primitives and behavioural semantics as described in section Below we provide the e- contract evolution properties. The system for e-contract evolution possess three properties namely correctness, completeness and consistency. Correctness refers to the provision of modifying schema without affecting its semantics. That is, providing this property ensures that the schema is syntactically correct after modification. Completeness refers to the possibility of transforming a generic conceptual schema/model into another generic conceptual schema. This property enables the modeling of e-contracts so that it can handle unexpected exceptions. Completeness also implies that unaffected aspects of e- contract are carried forward after. 80

92 Consistency refers to the achievement of modifying schema without causing run-time errors. The consistency of e-contract schema can be structural consistency and behavioural consistency. The structural consistency implies that after any sequence of modifications applied to a schema that is in legal state, the resulting schema remains legal. The behavioural consistency implies that application of set of primitives to a legal e-contract schema results in another e-contract schema that is in legal state. In the next sub-section, we introduce taxonomy of ways in which running instances of e-contract schema can be dynamically modified Taxonomy of operations to affect e-contracts evolution The taxonomy of operations to evolve e-contracts that takes place in conceptual modeling is presented below: Adapt: The model is allowed to adapt based on the new requirements. It includes cases of run-time changes and exceptions, where the structure of model does not change, but some constructs have to be treated differently because of some exceptional and unforeseen requirements. Migrate: The change affects the current model instance and hence a new model has to be instantiated. A meta-model can be used to generate new model. The new e-contract has to be complete with respect to the original contract. Merge: A new model is instantiated and merged with the current model. This is mostly required when more and more sub-contracts arise in e-contract enactment. Build: The change cannot be handled with current model and also a new model cannot be instantiated. That is, the meta-model may not generate a model that supports changed scenario. In this case, new concepts have to evolve and refine/augment the meta-model and instantiate a new model. It will consist of generating a new meta-model from existing meta-model and instantiating an instance of the newly generated meta-model. This is required when an unforeseen event occurs and cannot be incorporated with the existing models. The above four operations are useful to evolve new conceptual model for an e-contract when there is a change occurs. Application of sequence of these operations follows the taxonomy properties as given below: Taxonomy Properties Adapt Migrate Merge Build Commutative Yes No Yes No Associative Yes No Yes No Distributive No No No No However, the resultant behaviour after the model changes is depends on the specification model and very specific to the e-contract under consideration. 81

93 Another aspect of e-contract evolution is that how the instances of models before and after change execute. One simplified mechanism is to allow any one running instance at any point of time. Intuitively, e-contracts spans longer periods, there is also a need of allowing multiple running instances (that are instantiated before and after change the model) during some period. The following operations manage evolution with respect to running instances: Abort: The change needs to have a new model instance immediately after the change occurs. This allows stopping the running instance of old model and start running the instance of new model. Additive: The change needs to have a new model while continuing the current model. This results in running multiple models over a period of time. This is especially required when the changes affect the activities carried out after a specified time while continuing the old processes. The currently executing instance of a model will continue and a new model is enacted for the changed specifications and at a later time some of the concurrently executing models can be terminated as per the termination semantics of the e-contract. Managing running instances totally depends on semantics of specific contract under consideration. Moreover, the three properties namely commutative, associative and distributive are not applicable in the case of running instances for the operations Abort and Additive. A brief description is provided below for various changes that can occur during contract evolution and how they can be conceptualized. A typical e-contract modeling and enactment framework consists of (i) e-contract specification in text, (ii) conceptual modeling, (iii) logical manifestation of conceptual modeling, (iv) additional databases and workflows to support e-contract and (v) run-time management of e-contract. When additions are made to the text in the contract document, it follows the operation adapt in which the current instance is augmented with some more entities/elements. Similarly, when certain clauses have been modified or added, new ECA rules have to be generated and accordingly the model can be modified by defining a sequence of evolution operations. The operations for the three scenarios described in the section 5.4 are given below. Figure 5.6. shows the case for scenario 1. Here, the changes can be made in the model instance itself as per the revised scenario. As there is no structural change, it requires addition or modification of some elements in the model. In scenario 2, additional set of model elements has to be incorporated into the model. This requires migrate and/or merge operations depending on the change. For example, if a sub-contract has to be incorporated it requires both migrate and merge operations (figure 5.7). In this case, entities and relationships, which have participation in both the instances, are to be modeled appropriately. Scenario 3 needs the operation build. The changes in this scenario cannot be modeled directly using the meta-model. In the case of the example described in scenario 3 (section 5.4), it requires adapt and build operations. In the case of adding a new party, the adapt operation facilitates augmentation of one more party element into the model. The build operation facilitates instantiation of a new model (not from the meta-model) with the new construct, which was not envisaged during constructing meta-model. This feature requires that the meta-model itself has to be adaptable or a new meta-model has to be evolved (figure 5.8). In the conceptual modeling of evolving e-contracts, one or more operations have to be performed to carry out the changes. In addition to the cases described here, more complex cases can exist for different scenarios in e-contracts. Moreover, evolving 82

94 conceptual models based on the operations result in carrying out appropriate changes at logical and implementation levels. Meta-Model Adapt Meta-Model Model Instance Before change Model Instance that implements revised scenario Figure 5.6 Model instance before and after change depicting scenario 1 Meta-Model Migrate Meta-Model Current Model Instance New model Instance Merge Current Model Instance + New Model Instance Figure 5.7 Instance by migrate and merge depicting scenario 2 Meta-Model Build New Meta-Model Model Instance Before change New Model Instance Figure 5.8 New model Instance by build During requirement analysis of an e-contract application, specific meta-events have to be identified. In the housing loan example described earlier, some of the meta-events are: default rate, death/disablement and road expansion. Here, meta-event is an event at abstract level, and the actual event is known only at run-time. Same meta-event can handle multiple events. In this example, these three are considered as meta-events during design-time, so that an actual event takes place, it is checked to which meta-event it is associated. For instance, if the number of non-repayments crosses a specified limit, then the borrower becomes a defaulter. We consider non-repayment by a specified date in a month as an event whereas defaulting is a meta-event. Here, a customer can default due to many reasons such as non-repayment, check bounced and customer did some fraud in one or multiple banks. Therefore, we treated defaulting as a meta-event. Figure 5.9 shows the implementation mechanism for supporting meta-eca rule driven e-contract evolution by changing the meta-models. Similar ECA representation has been used by Chiu et al. [CCT 2003] for contract enforcement. Meta ECA rules trigger from one instance of an ER EC model to another instance. When a meta-event occurs, it triggers some rules, and the condition part of these rules will be evaluated. Conditions are logical expressions defined on the state of contract entities. A 83

95 simple Boolean expression can be used to specify the logical expressions. For instance, the following expression ( {House_construction, Loan_repayment} Executing Not_Paid_Installments > 3 (Fund_transfer Done) ) represents the condition for monitoring a housing loan repayment. Executing and Done are states of contract activities; House_construction, loan_repayment and fund_transfer are contract activities; and not_paid_installments is a contract variable (parameter). Logical expressions can also be specified using deontic logic [MM 2001]. However, deontic logic is not suited always as it is not designed to be executable. Therefore, deontic expressions have to be mapped to expressions that can be executed at either compile time or execution time. Contract Clause precondition triggers Condition Rule action Meta-model exploits Role run-time Meta Event mini-world Based on uses plays carries e-contract enactment owns Parties Figure 5.9 Meta-ECA Rule Driven E-contract Evolution Whenever a condition is satisfied, certain actions are performed to create/modify the model. The set of meta-eca rules collectively formulates an operation model of the contract clauses for subsequence enactment. The meta-events that are not conceived during the requirement analysis can be handled through human intervention. Below we explain the adaptability of ER EC model for the examples given for three scenarios described in section 5.4. Here, the meta-events are defaulting, death/disablement and road expansion. In each of these cases a new model is instantiated from the ER EC model repository. For simplicity, the diagrams used to depict the templates are shown only with few elements that are necessary for understanding. When a borrower is granted loan by a bank, the contract is initiated between the said parties which we refer as the housing-loan contract. The contract is enacted as per a standard ER EC model where the parties are, the bank, borrower, guarantor, insurance company (figure 5.10). However, at the beginning the bank and the borrower are only the active parties and the guarantor, insurance company does not have any active role to play in the contract. 84

96 Case 1: (Run-time change) - Borrower defaults As per the contract the borrower is supposed to repay the installment by a due date. If the borrower fails to do that then an event raised and the system produces the responsive action in the form of an alert. If the borrower fails to pay for 3 months (condition) then a meta-event defaulting occurs. (This example is a simple case of meta-event. Defaulting can also occur by other events as well, for instance paid through check, but check is not realized.) In such a scenario the bank may contact the guarantor to pay for the balance amount for the loan. The template shown in the figure 5.11 depicts these changes. This meta-event triggers the following procedure: On event <defaulting> begin Activate party <guarantor> Assign party <guarantor> role <borrower> Deactivate party <borrower> End Housing-Loan Housing-Loan Activities has Clauses Activities has Clauses have Parties Have Parties Roles Roles Bank Borrower Bank Borrower Guarantor Insurance Company Guarantor Insurance Company Figure 5.10 Standard template of Housing-Loan contract Figure 5.11 Template with change of roles Case 2: (Run-time change) Borrower s death/disablement There are two possibilities of this meta-event: (i) the insurance company pays the balance amount in the case of borrower expired and the house is allotted to the nominee; (ii) the insurance company releases a compensation amount in the case of borrower has disablement. Thus, when this meta-event leads to a subcontract insurance-claim thereby instantiating a new instance of ER EC model. Figure 5.12 shows the new template with a sub-contract insurance-claim. Note that there was no subcontract entity in the original template (figure 5.10). This meta-event triggers the following procedure: 85

97 On event <death-disable> begin Instantiate model with sub-contract < insurance-claim> copy party <insurance> of contract <housing-loan> to contract <insurance-claim> if <death> then begin add party <nominee> assign party <insurance> role <borrower> deactivate party < borrower > raise event (full payment )/* <payment> by party <insurance>) */ raise event (allotment) /* <allotment> to party <nominee>) */ end if <disablement> raise event (compensation ) /*provide compensation to borrower */ end. Housing-Loan Linked to Insurance-Claim Activities has Clauses Activities has Clauses Parties Have Parties Bank Borrower Roles Guarantor Insurance Company Nominee Insurance Company Case 3: (Mini-world change) - road expansion This meta-event might not have been conceived during requirement analysis. It is a change in the mini-world which may happen rarely, however this change has to be adapted and modeled appropriately. This would require human intervention for creating suitable model by augmenting new concepts and/or modifying existing model elements. In the housing-loan contract, the new concepts could be virtual entities society, human rights, besides adding a party like government, which have to be modeled appropriately in the template (figure 5.13). In the figure the virtual-entity is shown as a dashed rectangle. The process is explained as follows: On event <road-expansion> Figure 5.12 Template with addition of sub-contract begin Activate party <government> Add virtual-entity <society, human rights > Add virtual-role to virtual-entity <society, human rights > /* estimate compensation amount for the damage */ raise event (estimate damage) /* provide compensation to house owner */ raise event (compensation ) end 86

98 Here, the virtual-entity and virtual-role are new concepts and have to be modeled appropriately in both meta-model and conceptual model. Housing-Loan Activities has Clauses Have Parties Roles Bank Society Human Rights Guarantor Insurance Company Borrower Figure 5.13 Template with additional concepts From the above cases, it is known when a meta-event occurs, the focus of running e-contract shifts, thus triggering selection of appropriate model instance. It is not difficult to perceive specific e- contract domains, a set of ER EC models defined and put in use. These examples show the complexities involved in coming up with ER *EC meta-models and the amount of human intervention and tools that required semi-automate support of evolving applications. The use of ER *EC models are multi-fold: (i) It is easy to deploy as it is possible to fine tune a model instance to a specific application domain, (ii) Since most of the contracts have similar characteristics, a model is reusable and enables rapid deployment for multiple applications and (iii) A model instance can be augmented with additional constraints/concepts and consistency requirements to suit the additional requirements of an application. Augmenting model instance in this way makes the ER EC model more generic and adaptable to new scenarios (ex. new Service Level Agreements for applications outsourcing through Cloud) that are not envisaged earlier and/or a similar evolution may not be happened in the past. In order to handle mini-world and run-time changes in the contract execution environment, appropriate templates must be selected. Usually, when a contract begins a standard template is chosen from the repository to drive the contract. As the contract evolves, specific templates can be arrived at to suit a particular application under consideration. However, if standard templates are not available to deal with certain unforeseen events, then a generalized template can be used to drive the contract instead of an abnormal termination of the contract. The generalized template elements are actually a superset of standard template elements and human intervention is necessary to choose suitable template elements to be considered in the generalized template. Thus, starting with a standard template the template selection process can move in either direction to a more generalized template or a specific one. 87

99 5.5.3 Mechanisms to support active behaviour of e-contracts In this section, we show how the active behavior can be facilitated through various mechanisms for supporting changing e-contracts. Figure 5.14 shows the high-level description of ER EC model for e-contract enactment. ER EC model instance for a specific contract can be instantiated from the ER EC meta-model (meta-schema). In this work, the changes occurred during evolution of an e-contract are treated as exceptions. During evolution of an e-contract, the ER EC model is able to incorporate changes and sometimes it may require addition or modification of a concept. The exceptions (or changes) are easily handled by modifying the instance values without affecting the ER EC instance for the same e-contract. However, some of the changes that adhere to the meta-schema require instance level evolution and some changes require modifications in the meta-schema itself. Thus, there are two kinds of e-contract evolution of ER EC model: (i) meta-level evolution : in this case, the old (i th ) ER EC meta-schema modifies into a new ( j th ) meta-schema. That is, ER EC EC i ER j (ii) instance level evolution: in this case, the old (i th ) ER EC instance is modified into a new (j th ) ER EC instance. That is, ER EC i ER EC j ER EC Meta-Model ER EC Instance Relation Tables Static & Dynamic Workflows Workflow Instances Figure 5.14 A high level ER EC Model for e-contract enactment We propose a set of primitives that allow generic modification of e-contract schema, while preserving syntactical correctness of e-contract schema. At the same time, the running instances will need to respect the new rules as well. During contract evolution, the contract parameters or contract entities (such as parties, clauses, activities and sub-contracts) may change. These parameters can be added or removed in the e-contract schema. We introduce primitives such as AddParameter, RemoveParameter, AddEntity and RemoveEntity to handle these changes in the schema. Handling of some of the unexpected exceptions may cause changes in semantics of the e-contract schema, that is, addition of new entities and relationships. Thus, the two primitives AppendEntityType and AppendRelationshipType help in supporting such kind of behavioural changes in the schema. Primitives deal with adding or removing distinct concepts from meta-model. We describe the template based meta-model as T M = < Entities, ET, RT, Parameters, σ> 88

100 Here, Entities is the set of entities of meta-model, ET is the set of Entity types, RT is the set of Relationship types, parameters is the set of variables and σ is the condition function associating with each concept. A condition σ(s) for some concept depends on the domain. We will denote T M-BE = < Entities BE, ET BE, RT BE, Parameters BE, σ BE > as the meta-model before evolution (BE), and T M-AE = < Entities AE, ET AE, RT AE, Parameters AE, σ AE > as the metamodel after evolution (AE). The formal semantics of the primitives are given below: AddParameter (ParName p, defaultvalue d): adds a parameter to the model. If ( : < p, x> Parameters BE ) then Parameters AE = Parameters BE {<p,d>} Here, x is some value. RemoveParameter (ParName p): removes a parameter from the model. That is, Parameters AE = Parameters BE - {<p,y>}, where y is such that {<p,y>} Parameters BE. AddEntity(Entity e, EntityType E): adds an entity of a specific entity type to the meta-model. If ( : < e, E> Entities BE ) then Entities AE = Entities BE {<e, E>}. Here, σ(e) =. RemoveEntity(Entity e, EntityType E): removes an entity of a specific entity type from the metamodel. Entities AE = Entities BE - {<e, E>}. AppendEntityType(EntityType E): adds an entity type to the meta-model. ET AE = ET BE {E}, and σ(e) =. AppendRelationshipType(RelationshipType R): add a relationship type to the meta-model. RT AE = RT BE {R} These primitives are applied to the meta-model in a specific order in order to mange the change. The consistency of application of these primitives on a model is checked with respect to the running instances. The model after change is said to be in consistent with the model before change, if there are no run-time errors. In case there are run-time errors, we assume human intervention to handle it. Table 5.2 provides the requirements of changes in ER EC meta-level and instance-level evolution for the operations described in section 5.4. and Table 5.3 provides the requirements at database and workflows for an e-contract during its evolution. Here, we highlight that how ER EC model can serve both as a manifestation of conceptual as well as logical model for an e-contract enactment. This is a feature which provides the power of both treating the model as a conceptual description, and also a model that can be manipulated as a logical database. 89

101 Operations Require ER EC meta- level evolution Require ER EC instance-level evolution Action required during run-time Adapt No No Update database and workflow instances Migrate No Yes Update database, Generate new workflow instances Merge No Yes Update database and workflow schemas. Build Yes Yes (new instantiation) Additive Yes Yes (new instantiation) Update database schema & workflow schema. Update database schema & workflow schema. Table 5.2 Operations affecting ER EC model evolution Changes in Evolution Notation Changes in Database Changes in Workflow Action required during run-time Add New Party +P n Yes Yes New workflow is to be added according to the role of new party Delete Party - P i Yes Yes The workflow related to party Pi is to be appropriately handled. Party changed P i P j Yes No Update Database about party Pj details. Add new activity +A n No Yes Add new workflow for An - A i No Yes The workflow related to activity Ai is to be appropriately handled. Delete an activity Activity modified A i A j No Yes Modify workflow A sequence of A * * i A j No Yes Modify workflow activities are modified Add new clause +C i No No Update ECA rule-base Delete a clause - C i No No Update ECA rule-base Clause modified C i C j No No Update ECA rule-base A sequence of clauses are modified Add new entity type Add new Relationship type C i * C j * No No Update ECA rule base +ET Yes Yes Update database schema, add new workflows, if require +RT Yes Yes/No Update database schema, add new workflows, if require Table 5.3. Handling changes during e-contract evolution 90

102 Behavioural relations between roles in a contract express the ordering of their activities carried out by the parties in the contract. Moreover, business rules apply to the roles involved, specifying refinement of their behaviour based on the different clauses specified in a contract. Specification of meta-model for an e-contract will be of the form: <Party> ::= PartyID : Party_name [PartyID : Party_name] * <Role > ::= Role_ID : Role_name : Activity <Activity> ::=Activity_ID : Activity_name [Activity_name] * <Clause> ::=Clause_ID : Clause_sentence <Evolution Policies> ::= Policy_sentence <Behaviour> ::= Behaviour_sentence Here, behaviour_sentence typically specifies the active behaviour in the ER EC model that needs to be satisfied in order for a clause or evolution policy is to be fulfilled and is defined as follows: The action_list is a sequence of actions related to contract application, database operations or the operations (or sequence of operations) on meta-model shown in Table 5.2. Here, the execution of actions in one rule may give rise to new meta-events that may fire other rules. A rule is defined as follows: Behaviour_sentence ::= WHEN meta_event FIRE rule. Meta_event ::= meta_event_id : meta_event_type Rule ::= rule_id [ ( description ) ] : [IF condition THEN] action_list CREATE RULE rule_id [description] {BEFORE AFTER } meta_event EXECUTE PROCEDURE procedure_name (procedure_parameters); Here, rule_id maps directly into rule_name, description maps into a string of characters for documentation purpose and event maps into the corresponding language construct. The meta-events could be contract event, internal event (for example, database event) or external event. Each object referred in the meta_event, condition or action_list part of the behaviour sentence is mapped into a database table. Further, each value referred in the condition or action_list is mapped into a value in the corresponding domain. The mapping process translates the behaviour definition into the specification of procedures and rules in the DBMS under consideration. Our idea here is the active capabilities of meta level modeling fill the gap of providing functionalities that exist at the logical level that do not have corresponding modeling constructs at the conceptual level. The mapping process is intended to use by a translation tool that automatically generates the executable DBMS language statements corresponding to the active behaviour specified in the ER EC model. As an example, consider the scenario 2 case of meta_event death. The following procedure modifies the meta-model of Housing-loan contract. 91

103 CREATE PROCEDURE Proc_Borrowers_DD (Contract Housing_Loan, Contract Insurance_claim, Number repayment_balance) AS DECLARE message VARCHAR NOT NULL; BEGIN IF (repayment_balance > 0) THEN BEGIN ACTIVATE insurance_claim CONTRACT; CREATE RELATIONSHIP_TYPE Linked_To; ADD LINK BETWEEN Housing_Loan AND insurance_claim USING Linked_To; CREATE RELATIONSHIP_TYPE Have; ADD LINK BETWEEN Housing_Loan.Parities AND Insurance_claim.Parties AND Housing_Loan.Roles WITH Have; ASSIGN ACTIVITIES of Borrower to Insurance_claim.Parties. Insurance_company; MARK DELETE Housing_Loan.Parites.Borrower; MARK DELETE Housing_Loan.Parties.Insurance_Company; RAISE EVENT Re_Pay_from_Insurance_company; Message: All references to BORROWER being deleted END ELSE Message : No Balance for Repayment MESSAGE: The Account is cleared. Allot house to nominee PERFORM ACTIVITY Allotment_house_to_nominee; END The above procedure also raises other events and triggers corresponding activities to be carried out. This will enable to update the necessary table in the metadata and initiate a new workflow instances as required by the contract. The operations defined in section facilitates structural validation of meta-level and the specifications defined above facilitate the behavioural validation at meta-level. Thus, these operations and specifications at meta-level facilitates execution-driven, consistency-driven and flexibility-driven e-contract execution environment. The structural and behavioural consistencies in e-contract modeling are guaranteed for the application of a single primitive or a sequence of primitives, thus validating the modification applied to the e-contract schema. We note that the evolution operations determine how the meta-model changes. Hence, more precise syntax and semantics have to be made with an appropriate language. We can expect that such a language would have constructs for specifying the active modeling aspects of e-contracts evolution Implementation issues The changes that occur during contract enactment need to be propagated to the conceptual and logical levels for bookkeeping, version control as well as handling the changes, for example coordination between the old workflows instances and new workflow instances during execution. However, direct handling the changes at conceptual and logical level is more complex because of inherent complexity exits in the e-contract execution. The meta modeling approach helps to effectively handle these changes and propagate to conceptual, logical and implementation levels. In the proposed active meta- model based mechanism to handle the e-contract evolution, the crucial aspect is to capture the events that are required to propagate to other levels. We have associated metaevent with each event in our model. As discussed earlier a meta-event is concerned with several events. Our idea here is to have a procedure to handle meta-event, and when an actual event occurs, it 92

104 identifies which meta-event that concerns it and handles it through meta-event procedure. They execute the associated meta-eca rules in order to incorporate the corresponding change in the metamodel. This change in meta-model is propagated to the implementation level e-contract instance. Such events and associated meta-eca rules can be incorporated in the e-contract engine. 5.6 ER *EC Methodology Similar to ER EC methodology described in chapter 4, the e-contract process design model for the entire design basically divides into two concurrent segments (see figure 5.15). In chapter 4 (figure 4.2), the behavoural validation is mainly concerned with the run-time exceptions and clause violations, and it does not concern with schema changes. However, in figure 5.15, we are concerned with the active behaviour due to both min-world and run-time changes and accordingly allowing schema modifications. The two segments in figure 5.15 are dependent on each other to effectively design the entire e-contract. One segment corresponds to the conceptual design aspects of the e-contract and the other one corresponds to the active behaviour of the e-contract execution. The requirement collection forms the basis for complete process design. Model requirements facilitate the conceptual design where as the process requirements facilitate the execution aspects of the application. As shown in the figure 5.15, the relationships between the two segments facilitate capture of the dynamic behaviour of applications and incorporate the necessary updates required at the conceptual level of the design process. Here, the ER *EC model will act as a library of meta-models or templates. This template library was built over knowledge created while working with various applications. That means, it has a set of domain specific templates. The conceptual schema is developed by instantiating an ER EC model from ER *EC model. Once a model (or template) is selected for a specific application requirement according to the business requirements, the logical schema for both databases and logical level processes is derived after mapping the model components into run-time workflow components. The static and dynamic behaviour of applications are handled in the segment shown in dashed lines and boarders in the figure The static criteria can be verified at the application specification and used in the matching procedure with conceptual schema. The events that will raise during the execution along with ECA rules are derived from the application specifications. Expected exceptions are also captured during this step. Exceptions and ECA rules are helpful in specifying the logical level processes. These specifications are used in run-time workflow mapping. The dynamic behaviour will be handled by writing log records from the execution of applications. A knowledge base is built from the unexpected events and exceptions (due to mini-world and business process changes). This knowledge base will form as a source for facilitating active behaviour and incorporates the new rules that manage the exceptions and events. The ER model is modified either by updating the conceptual schema or instantiating a model instance from an appropriate model. In case no suitable model is identified to instantiate the appropriate ER EC model, a new model needs to be designed and added to ER *EC meta-model. The process model is also modified according to the application evolution. 93

105 The ER *EC methodology is iterative and is driven by three validation steps, namely, structural validation, functional validation, and behavioral validation. Structural validation is the traditional correctness check of a conceptual model in correctly modeling the data requirements. Functional validation ensures that the applications and the transactions meet the application requirements, and map to the functionality that exists in the mini-world. Behavior validation is the one that is triggered by the constant monitoring of the run-time environment and mini-world changes. This is captured by means of exceptions and user feedback to detect the mismatch between the implemented applications/processes and what exists in the mini-world. In a highly process oriented environments these exceptions can lead to process evolution and work specification changes. Therefore, these three Mini-world Requirements Collection and Analysis Data requirements Application Requirements Conceptual specification Application specification Structural validation Conceptual schema (ER data model) Exceptions Active Behaviour ECA Rules Behavioral changes Knowledge Base (Run-time & Mini-world) Process specifications (Logical Design) Workflow specifications Behavior validation Application Design Log Records Log records specification Functional Validation Logical Schema Application s Physical Design (Relations, Workflows,.) Internal Schema Run-time Environment Figure 5.15 ER *EC Methodology 94

106 validation steps are the driver for the ER *EC methodology for evolution. The log records, exception events, and ECA rules are part of the driver for supporting this methodology. ECA rules facilitate monitoring and execution of an application. The ECA rules are well established in the context of databases, which has the functionality of active capability that satisfies the needs of various applications and timely response to a situation. Initially, application execution behaviour (and their underlying workflows), and events as well as snapshots of run-time environment, will be fed into an active database [M1983]. In order to manage the active behaviour of applications effectively, the semantic behaviour of rules and exceptions must be captured. It can be modeled by considering the events and actions along with the update primitives for conceptual modeling the application evolution. These in turn are held in learning appropriate changes to conceptual models (or templates). 5.7 Two-way Active Behaviour for Evolving E-contracts The main idea here is to facilitate deployment of data models that sustain over a period of time. This approach follows a two-way perspective of actively evolving conceptual models: (i) across the time domain (present, past and future) and (ii) at various levels (meta, conceptual, logical and application level). The main component is the active behaviour, which learns the execution behaviour and, accordingly makes the changes required at various levels. Further, it also propagates the changes to the next generation (from past to present to future). Figure 5.16 shows the two-way active behaviour for evolving applications. Each vertical segment of figure 5.16 follows the ER *EC methodology described in the section 5.6. The evolution from present to future can be handled in one of the following three ways based on the available tools that support the evolution: Model (or Template) selection Operator assisted evolution of ER *EC models Complete re-design of ER *EC models (from scratch) The Model selection mechanism manifests itself as a ER *EC methodology problem where in an evolving e-contracts needs to select appropriate model to meet its contract requirements. A specific case of e-contract is described in the section 5.5, which illustrate one such environment. In the second case, a set of operations have to be developed in order to handle the active behaviour so that these can be programmed to (semi-) automatically (with human intervention) design/update/derive the suitable ER *EC models. The last approach requires an automated system that learns the behaviour and arrives at designing appropriate ER *EC models. This requires a sophisticated set of tools, and current tools do not have the capability to automate this completely. The ER *EC methodology is helpful for maintenance, archiving and retrieval, besides providing a library of ER *EC meta-models specific to various domains. This approach is also useful when an application system located in various countries. A typical standard application such as core banking solution (CBS) in a bank also requires evolution when it is placed in different countries due to 95

107 international/local rules and regulations. An application needs to evolve whenever these rules and regulations change. Thus, there is a notion of spatio-temporal dimension of evolving application and matching them to different conceptual models. Past Present Future Mini-world Mini-world Mini-world Meta Model Conceptual Model Logical Model Con Str Concept F L T A C T I V E B E H A V I O U R B e h EE a x C v c A i e o r a l Con Str Concept F L T A C T I V E B E H A V I O U R B e h EE a x C v c A i e o r a l Con Str Concept F L T A C T I V E B E H A V I O U R B e h EE a x C v c A i e o r a l Application Logic & Business Process R A u M T M e Run-time System R A u M T M e Run-time System R A u M T M e Run-time System Figure 5.16 Progression for Active behaviour of evolving e-contracts 5.8 ER *EC Architecture for Evolving Applications This section describes handling of events and selection of models from templates repository at run-time. The changes in the mini-world and/or runtime environment are considered as events that would require appropriate action for the application execution. For example, an event may be caused due to change in the policy or an exception in the run-time environment. This may affect the entities in the ER *EC model. Thus, the event handler plays a major role in the application evolution. 96

108 Run Time Template Evaluator Add / Modify Template Repository M o d e l 1 Evolution Patterns Meta ECA Rules Model Selector Run Time Template (s) Monitor Run Time Environment Application Specific components E-ADOME Workflow Engine Workflow Generation/ Specification subsystem Mini world Application evaluation policies Metadata Database Database for workflows, Rules, etc. Event Handler ECA Rule Manager Figure 5.17 An ER *EC architecture for evolving applications Depending on the event, the event handler generates new instance of ER *EC meta-model, if required, by invoking appropriate template. E-contract evolution requires the modification of schema definitions and in-turn changes in workflow definitions, as a remedy. Moreover, additional ECA constructs are needed in the system during work in progress; an advanced schema evolution capability is required at run-time. The metamodeling approach to e-contract modeling facilitates application evolution and thereby workflow enactment. The present work offers a practical solution from application modeling, enactment, to evolution. Application evolution policies that refer to adaptable instances of ER *EC schema while the application is executing need to be maintained. The capabilities of ADOME-WFMS [CLK 2001, CKLK 2002] are enhanced in order to facilitate the application evolution with the help of schema evolution and generate evolution patterns to affect changes in an ER *EC model. Evolution patters are specific to applications under consideration. For example, in an e-contract application, the evolution patterns could be of the form {e-contract} + {Activity} + {Clause} * {Action} *. These patterns are useful to describe how the evolution changes will be specified, implemented and perceived. Figure 5.17 shows architecture of an e-contract system to actively model ER EC meta-model and its instances. The run-time environment details such as workflows, rules, etc. are maintained in the database. Workflow Generation / Specification Subsystem generates workflows and rules. It also allows the administrators to customize and edit them. Workflow definitions created or specified are executed by the E-ADOME workflow engine. That is, the workflow engine enacts the workflows specified by the workflow Generation/specification subsystem. The Event handler manages the events occurring during the execution of workflows. It handles events in a unified manner for both normal and exception parts of a business process workflow. The 97

109 ECA rule Manager generates appropriate ECA rules based on the input from Event Handler. It also keeps track of generated rules with their corresponding actions and allows users to define additional rules if necessary. The workflow engine and the ECA rule manager works in a synchronized manner. Thus, the ECA rules control the workflow execution and the events that occur during the workflow execution result in appropriate actions. The changes in the mini-world update the corresponding database. The miniworld database maintains the currency of information such as evolution policies, versions etc. that governs execution of the application. Metadata database captures the updates that taken place in the run-time as well as in the mini-world. These updates become input to the Run-time Template evaluator. Run time template evaluator generates candidate templates and add/modify the template repository. Template repository contains the templates that are specific to application under consideration in XML format. Templates are added or modified based on the requirements collected from runtime environment changes as well as mini- world changes. Here, Monitor acts as broker between the run time environment and mini-world. It generates/modifies the evolution patterns and (meta-) ECA rules. Monitor receives events and results from the run time environment and mini-world, as well as from application specific components. The modeling of changes in the application evolution can be seen as a different kind of meta processes (tasks). These meta processes can be modeled and evolution patterns and meta ECA rules can be extracted from the meta processes. Further, Application Specific Components are required for encapsulation and realization of the domain-specific logic for the application. The three components namely Monitor, evolution patterns and meta ECA rules will serve as Run-time template evaluator. Model selector selects the appropriate Run Time template(s) from the Template Repository, which in turn drives the application execution. 5.9 Summary Run-time application environments are affected by the changes in mini-world or technology changes. Large number of applications are process driven. For robust applications that can evolve over time, there is a need for a methodology that implicitly handles changes at various levels from mini-world to run-time environment through a layers of models and systems. In this chapter, we presented a pragmatic approach to support evolving e-contracts. We illustrated scenarios that determine the need of evolving e-contracts and developed an active meta modeling approach by introducing the taxonomy of evolution operations. Meta-ECA rules are also introduced to model the active behavior and drive the e-contract evolution. The evolution operations and meta-events facilitate the structural and behavioural conformance of e-contracts due to evolution. The notion of supporting evolving e-contracts in this work is driven by ER EC meta-model. Also, a template driven two-way active behaviour for supporting changing e-contract applications is presented. The presented methodology for actively evolving ER *EC meta-models caters to various application domains. A specific ER *EC model handles a specific application requirement scenario for a specific duration of 98

110 time. The idea presented in this work is useful in visualizing this evolution procedure and develop specific methodologies, procedures and tools to actively support application evolution. A key ingredient in the presented methodology is the use of monitoring and bookkeeping of mini-world and run-time changes to propose an ECA rule based solution. Finally, an architecture is described for e- enactment of evolving e-contracts. The ER EC model and framework developed in chapter 3, 4 and 5 are useful for modeling and enactment of an e-contract. The ACDs in the ER EC framework provide activity-commitment semantics at conceptual level that are specified based on the contract document. At logical level, the commitment specifications facilitate specifying the semantics for transactional support, activity commitment, and workflow commitment in the execution of an e-contract. So, an e-contract system is wanting without commitment support; commitments at various levels must be coordinated and consolidated. The existing formal models partially satisfy the transactional support, particularly the atomicity property. However, atomicity in the traditional transactional system might not completely hold or be meaningful in e-contract systems because the contract contains many interdependencies among its various elements, and different workflow levels are mandatory for contract enactment. Hence, we might need additional properties, such as compensatibility and retriability. In the next chapter, we introduce multi-level composition model to supports activity commitments in e-contracts. 99

111 Chapter 6 E-contract Activity Commitments The activities in a contract are generally complex and interdependent. An e-contract system must ensure the progress of the activities and their termination. Since e-contract activities may be handled by different parties autonomously and in a loosely coupled fashion with several interdependencies, e- contract systems need a suitable transactional support. In this chapter, we describe a multi-level composition model for activities in e-contracts to provide transactional support in their execution. This model allows for the specification of a number of transactional properties, like atomicity and commitment, for activities at all levels of the composition. Also, it enables the study of interdependencies between the executions of e-contract activities, which will help in monitoring behavioral conditions stated in an e-contract during its execution. 6.1 Introduction In e-contracts, the activities are to be executed by the parties satisfying the clauses, with the associated terms of payment. So, an e-contract system must ensure the progress of the activities and their termination. Consider, an example, a contract for building a house. The parties of this contract include a customer, a builder, a bank and an insurance company. The contract has several parts: (a) The builder will construct the house according to the specifications of the customer. Some of the activities such as carpentry, plumbing and electrical work may be sub-contracted; (b) The customer will get a loan for the construction from the bank. He will apply for a mortgage, and work out details of payment to the builder, directly by the bank, after inspection of the work at multiple intervals; and (c) The house shall be insured comprehensively for the market value covering fire, flood, etc. in the joint names of the bank and the customer. The activities of the customer and the builder include the following. - Customer: (i) submitting the loan application, (ii) setting up coordination between bank and builder, (iii) receiving payments, and (iv) arranging monthly repayments. - Builder: (i) scheduling different works involved in the construction, (ii) procuring raw material, (iii) building the house as per the agreement, (iv) giving part of the work to sub-contracts, if any, (v) receiving the payments, (vi) making payments to its staff and sub-contract parties, if any, and (vii) handing over the constructed house to the customer. The goals of an e-contract include precise specification of the activities of the contract, mapping them into deployable workflows, and providing transactional support for their execution. 100

112 6.1.1 Activities in e-contracts Contracts are complex in nature. Both the initial specification of the requirements and the later verification of their execution with respect to compliance to the clauses are very tedious and complicated. This is due, partly, to the complexity of the activities. Typically, the activities are interdependent with other activities and clauses. They may be executed by different parties autonomously, in a loosely coupled fashion. They are long-lasting. Though the desirable outcomes of their executions are stipulated in the contract specification, their executions may yield unexpected results. This might result in re-design and even re-specification of the contract. We assert that a key to handle the complexity in executions of contract activities is adherence to transactional properties. In database applications, atomicity is strived for in a (simple) transaction execution. That is, a transaction is executed either completely or (effectively) not at all. Partial execution is rolled back. On successful completion, the transaction is committed. In multi-database and other advanced database applications, transactions may be committed (locally) and then rolled back logically, by executing compensating transactions. This property is called compensatability. The property of repeatedly executing a transaction until successful completion is also considered; this is called retriability. In e-contract activities also, both compensatability and retriability properties are encountered for the activities, and in fact, in more sophisticated ways. For example, (i) Both complete and partial executions may be compensated, (ii) Both successful and unsuccessful executions may be compensated, (iii) Even committed executions may be retried, (iv) Retrying may mean, in addition to re-execution, adjusting the previous execution, and (v) Activities may be compensated and/or retried at different times, relative to the execution of other activities. Example 6.1: An instance of (iii), in the contract for building a house, is the following. A pipe may be fixed correctly as specified in the contract. Suppose it breaks a month later, while constructing a miniwall in the balcony. As per the clause stated in the contract any damage or loss of goods/material during construction of house is the responsibility of the builder and the builder has to repair or replace at no additional cost, the builder has to fix the pipe. An instance of (iv) is, in the process of repayment of a bank loan, if a check is bounced for some reasons, the customer has to pay penalty in addition to the actual amount. E-contract activities differ from typical database transactions in many ways: (i) Different successful executions are possible for an activity; (ii) Unsuccessful executions may be compensated or re-executed to get different results; (iii) Whether an execution is successful or not may not be known until after several subsequent activities are executed, and so it may be compensated and/or re-executed at different times relative to the execution of other activities; (iv) Compensation or re-execution of an activity may require compensation or re-execution of several other activities; etc. 101

113 In this work, we propose a multi-level composition model for activities in e-contract [VRK 2007]. We start with basic activities and construct composite activities hierarchically. In the first level, a composite activity consists of basic activities; in the next level, a composite activity consists of basic and/or composite activities of level one; etc. The highest level activity will correspond to the single activity for which the contract is made. We call this the contract-activity. (We note that there could be multiple contracts for a single activity. For example, for building a house, there could be separate contracts between (i) customer and the builder, (ii) customer and the bank, (iii) customer, bank and insurance company, etc. These contracts will be related. We consider this set of contracts as a part of a single high level contract whose contract-activity is building the house.) Then, our contention is that the execution of each activity, at every level, should satisfy transactional properties. Every activity in the contract must be closed at some time. On closure, no execution related to that activity would take place. The closure could take place on a complete or incomplete execution, and on a successful or failed execution. On closure of the contract-activity, the e-contract itself can be closed. The e-contract closure is mostly a human decision. It may involve auditing, handing over documents, releasing assets, dispute resolution (if any), settling payments (including post-deliverable payments), etc. However, in this work, we consider commitment of e-contract as e-contract closure. We use the term e-contract commitment logic to refer to the entire logic behind the commitment of the various activities of the e-contract, and the closure of the activities and the e-contract. Our composition model helps streamlines the process of closure of the e-contract. In e-contracts, interaction occurs between parties which are autonomous and work together using loosely-coupled services. A contract consists of numerous activities that are to be carried out by parties and contract clauses that address a specific concern in the business interaction. Since interorganizational work elements are handled through contracts and most of the contracts are complex and voluminous, manual verification is both expensive and error prone. This necessitates a welldefined commitment framework for correctness and successful execution of e-contracts [DNS 2008; GVA 2001]. For atomicity, either a complete successful execution or an (effectively) null execution should be obtained. Given a non-null, partial execution, the former is obtained by forward-recovery and the latter by backward-recovery. The retriability and compensatability properties relate to whether forward-recovery or backward-recovery can be carried out. Transaction concepts, as the ACID (Atomicity, Consistency, Isolation and Durability) properties, were first proposed for database applications. In early applications, the database system was centralized, the execution time was relatively short, and the number of concurrent transactions was relatively small. For distributed database systems and long-running transactions, several variations of the basic transaction model were proposed. Some examples are chained transactions, saga, nested transactions and ACTA framework [CR 1990; CR 1991]. Later proposals include [DML 1991] for long-running transactions and [AAAKGM 1996] for workflows. The Activity-Transaction Model (ATM) in [CD 1996] allows long-running transactions and provides recovery mecahnisms for transaction workflows that consist of transaction hierarchies. 102

114 Compensatability and retriability properties were first identified in the context of atomicity of multi-database applications (for instance, [V 1991]). To achieve atomicity (of a global transaction) in autonomous execution (of the subtransactions), a multi-database transaction is modeled to consist of a sequence of compensatable transactions, followed possibly by a pivotal (that is, non-compensatable) transaction and a sequence of retriable transactions. In particular, each multi-database transaction can have at most one pivot. Schuldt et al. [SABS 2002] extended this idea to transactional processes by allowing multiple pivots. Clearly, with multiple pivots, atomic execution may not be possible (when some pivots are executed but others cannot be executed). They defined a property, called guaranteed termination, which formalized graceful termination of the transaction after some pivots were executed. In addition, the pivots in a guaranteed termination were executed in sequence. Further extension was done in [VV 2004, VV 2007], in the context of composition of Web Services. In this work, (i) the guaranteed termination concept was extended to atomicity (of global transaction, or composite activity or service), (ii) forward- and backward-recovery procedures for achieving atomicity were given, and (iii) non-sequential, tree-like, execution of the pivots was accommodated. Then the transactional properties (atomicity, compensatability, retriability and pivot) were extended to hierarchically composed activities/services. It was shown that the transactional properties can be considered at each level independently of the properties of the other level activities. The proposal to address activity commitments in e-contracts in this work is along the lines of [VV 2004, VV 2007] but tailored and extended to e-contract environment Activity commitments Transactional semantics, workflow semantics, clauses and payment components of e-contract need to be considered for addressing e-contract commitments. Workflow semantics deals with the composition logic, namely, the semantics of the executions of the individual activities that constitute the workflow. Transactional semantics deals with the commitment logic, about atomicity, forwardand backward-recovery and commitment of the executions, and closure of the activities and the e- contract. Both clauses and payments influence, and are influenced by, both the workflow and transaction semantics. Payment aspects of e-contracts are covered in chapter 7. Figure 6.1 shows a high-level view of activity commitment system. The figure has two components: specification engine and execution engine. E-contract document is the basic input to the entire system. The specification engine extracts activities and clauses specifications. These specifications are useful to generate workflow specifications and multi-level composition model. The e-contract activity characteristics described above give rise to sophisticated interdependencies between executions of different activities. These dependencies deeply impact both the recovery and commitment aspects. Activity and clause specifications are also useful to derive the dependencies between activities. Using the audit trials provided by the log manager, the components of the execution engine ensure the atomicity of the executions of the e-contract activities. A few papers in the literature discuss the transactional properties of e-contract activities. Papazoglou [P 2003] describes a taxonomy of e-business transaction features and presents a business 103

115 transaction model that relax isolation and atomicity requirements of ACID transactions in a loosely coupled environment consisting of autonomous trading partners. This paper also describes backward and forward recovery for long-running business transactions. Jain et al. [JAS 1999] present a flexible composition of commitments, known as metacommitments. These commitments are mainly associated with the role of a party and ensuring whether a particular activity is committed or not. They do not refer the commitments with respect to the execution states of an e-contract activity. Xu [X2004b] proposes a pro-active e-contract monitoring system that is based on contract constraints and guards of the contract constraints to monitor contract violations. This paper represents constraints using propositional temporal logic in order to provide formal semantics for contract computation at the contract fulfillment stage. However, the formalism in this paper does not provide the execution level semantics of an e-contract commitment E-contract document Specification Engine Activity/Clause Specification Workflow specification Composition Model Dependencies Specification Database Log Manager Workflow Engine Execution Engine Commitment Engine Dependencies & Recovery coordinator Figure 6.1 E-Contract Activity Commitment System - High level view Some of the dependencies identified in our work are along the lines of those for database transactions given by Chrysanthis and Ramamrithm in [CR 1991]. To the best of our knowledge, adequate formalism for e-contract commitment and activity dependencies based on the transactional properties of the execution of e-contract activities have not been studied in the literature. In this chapter, we focus on execution engine, particularly on the aspects required in developing commit design and dependencies and recovery coordinator components. We propose a multi-level composition model for the (composite) activities of a e-contract. Transactional properties have been defined to suit the real world, non-electronic, activities. The salient points are the following. i. Transactional properties are defined for executions of activities rather than activities themselves. This accounts for the fact that different executions of the same activity might have different characteristics. 104

116 ii. Atomicity is defined for executions of composite activities of any level in spite of the executions of even some basic activities being non-atomic. This helps in dealing with backward- and forward-recoveries at each level independent of its descendent levels. iii. The scope of retriability is extended from executing the same activity again, or executing some other substitute activity, to adjustments to the original execution. iv. Two levels of commitment, weak and strong, are defined. On weak commitment, the execution becomes non-compensatable, and on strong commitment it becomes non-retriable. Weak commitment is the commitment property of the traditional database operations and the pivotal property of multi-database operations. The strong commitment property definition is new. Both (a) defining transactional properties for activities of a contract and (b) influencing e-contract design with transactional properties are novel and have not been done before. We use the composition model to study the interdependencies among the executions of the activities. 6.2 Basic Concepts In this section, we present the concepts and notations relevant for transactional properties in the context of e-contracts, and in the next section we present the model. Basic Activities We consider certain activities as basic in our model. Typically, these are the activities which cannot be decomposed into smaller activities, or those that we want to consider in entirety, and not in terms of its constituent activities. In e-contract environment, some basic activities may be executed electronically (for example, processing a payment), but most others will be non-electronic (for example, painting a door). We desire that all basic activities are executed atomically, that is, it is either not executed at all or executed completely. However, incomplete executions are unavoidable and we consider them in our model. Constraints Each activity is executed under some constraints. Examples of constraints are (i) who can execute the activity, (ii) when it can be executed, (iii) whether it can be executed within a specified time period, (iv) cost of execution, (v) what properties need to be satisfied for an execution to be acceptable, and (vi) compensatability or other transactional properties. The first four constraints relate to workflow semantics. The last two relate to transactional semantics. A complete execution of an activity that satisfies all the constraints specified for the execution of that activity at the time of its execution is called a successful termination, abbreviated s-termination, of that activity. The constraints themselves are specified in terms of an s-termination predicate, or simply, st-predicate. A complete execution which does not satisfy the st-predicate is called a failed termination, abbreviated f-termination. The s- and f-termination distinction is applied to incomplete executions also, depending on whether the st-predicate is satisfied thus far. 105

117 Example 6.2: Consider the activity of painting a wall. The execution is incomplete while the wall is being painted, and complete once the painting is finished. If the paint job is good at the end (respectively, in the middle), the execution is a complete (respectively, incomplete) s-termination. If the paint job is not satisfactory, we get a complete or incomplete f-termination. The st-predicate specifying the goodness of the job could be: (i) one undercoat and one other coat of paint and (ii) no smudges in the ceiling or adjacent walls. For many activities, especially non-electronic ones, some acceptability criteria may be highly subjective and depend on the application environment. For example, consider the activity of building a wall. Quantitative aspects such as the dimensions of the wall, its location, etc. can be expressed easily. Smoothness of the finished surface and extent of the roundedness of the corners will be application dependent. The requirements for a wall in a children s hospital will be different from those for one in an army barrack. We propose that a predicate, termed property-predicate, be defined for each of the requirements and the acceptability, that is the st-predicate, be stated in terms of satisfying a Boolean expression of the property-predicates. Determining whether a property-predicate is satisfied or not in an execution will be left to the application semantics. Thus, the st-predicate for the construction of a wall could be (d AND s AND r) where d is the dimension predicate stating whether the dimensions of the wall are according to specifications, s is the smoothness predicate and r is the roundedness (of the corners) predicate. Then, an execution which does not satisfy one or more of these predicates will be an f-termination. Clearly, several different f-terminations are possible. As another example, the st-predicate for finishing a wall could be ((u AND o) OR (u AND w)) where u refers to an undercoat of painting, o is an overcoat with smooth finish and w is wall-papering. Here, two s-terminations are possible, one yielding a painted surface and the other with wall paper. The constraints may change, that is, the st-predicate of an activity may change, as the execution of the contract proceeds. In the above example of building a wall, the required thickness of the wall may change from 6 inches to 8 inches, thus changing the dimension predicate. Similarly, two coats of paint may be required in addition to undercoat. Such changes may invalidate a previous s-termination. When this happens, the execution needs to be adjusted. We note also that, with changes in the stpredicate, an earlier f-terminated execution may become an s-termination. It follows that we may not know whether a termination is an s-termination or an f-termination until some time later. Compensatibility One of the ways an execution can be adjusted is by compensation, namely, nullifying the effects of the execution. Absolute compensation may not be possible in several situations. In some cases, the effects of the original execution may be ignored or penalized and the execution itself considered as compensated. It is possible that an execution can be compensated within a certain time, but not afterwards. The time could be real time (for example, flight reservations can be cancelled without penalty within 24 hours of booking, and vinyl flooring glued to the floor can be removed before the glue sets) or specified relative to the execution of some subsequent activities (for example, flight bookings can be cancelled until paid for, and a (stolen) cheque can be cancelled before it is cashed). Inability to execute a compensating activity within a prescribed time limit may also make the original execution non-compensatable. 106

118 Note that we do not attribute compensatability property to an activity, but only to an execution of that activity. For the same activity, some executions may be compensatable, whereas others may not be. For example, when we book flight tickets we may find that some tickets are non-refundable, some are fully refundable, and some others partially refundable. Purchasing a fully refundable ticket may be considered to be a compensatable execution, whereas purchasing any other type of ticket could be non-compensatable. Thus, compensatability of the execution (purchasing a flight ticket) is known only during execution, and not at the specification time of the activity. We look at compensation as a logical roll back of the original execution. Then, compensation may also be done by executing some other, compensating, activity. The compensating activity could be executed at different levels, in our multi-level model. Retriability Another way of adjusting an execution is by retrying. By retriability, we mean the ability to get a complete execution satisfying the (possibly new) st-predicate. It is possible that the original execution is compensated fully and new execution carried out, or the original execution is complemented, perhaps after a partial compensation, with some additional execution, for instance, the second coat of painting in Example 6.2. Another example is, a day after pouring concrete for the foundation of a house, the thickness of the concrete may be found to be insufficient, and additional concrete poured for the required thickness. Retriability may also be time-dependent. It may also depend on the properties of execution of other preceding, succeeding or parallel activities. Again, in general, some executions of an activity may be retriable, and some others may not be retriable. We note that retriability property is orthogonal to compensatability. That is, an execution may or may not be retriable, and, independently, may or may not be compensatable. Execution States We consider an execution of an activity with a specified st-predicate. On a termination, if we are not satisfied with the outcome, that is, the st-predicate of that activity is not satisfied, then we may reexecute. In general, several re-executions and hence terminations are possible. We assume the following progression of the states of the (complete or incomplete) terminations. 1. The termination is both compensatable and re-executable. 2. At some stage, the termination becomes non-compensatable, but is still re-executable. Then, perhaps after a few more re-executions, we get a termination which is either a. non-re-executable to get a complete s-termination, and we take this as an f- termination, or b. re-executable to get eventually a complete s-termination, and we identify this state as non-compensatable but retriable. 3. Continuing re-executions in state 2.b, at some stage, we get a complete s-termination which is non-compensatable and non-re-executable. It is also possible that an (un-compensated) execution remains in state 1 and never goes to state 2, and similarly an execution is in state 2.b, but never goes to state

119 We say that an execution in state 2.b is weakly committed, that is, when it is or has become noncompensatable, but is retriable. An execution in state 3 is strongly committed. We note that both weak and strong commitments can be forced upon externally also. That is, the execution can be deemed as (weakly or strongly) committed, for reasons outside of that execution. An example is payment to a sub-contractor for execution of an activity, and the non-obligation and unwillingness of the subcontractor to compensate (in case of weak commitment) or retry (in case of strong commitment) the execution after receiving the payment. We say also that an activity is weakly (strongly) committed when an execution of that activity is weakly (strongly) committed. We allow compensatability and retriability properties to be applicable to incomplete executions also. We assume the first two of the above state transition sequences for partial executions. That is, a partial execution is both compensatable and retriable in the beginning, and may become noncompensatable at some stage. Then, if it is retriable, that is, a complete s-termination is guaranteed, then the execution can be weakly committed. Note that we are simply allowing the transition from uncommitted to weakly committed state to occur even before the execution of the activity is complete. We do not allow transition from weakly committed to strongly committed state until (or some time after) the execution is completed. Start Execution in progress Execution stopped Complete or incomplete f-termination Complete or incomplete s-termination Incomplete weakly committed s-termination Re-execute Compensate Complete weakly Committed s-termination Retry Closed null termination Closed non-null f-termination Closed strongly committed s-termination Figure 6.2 Execution stages of an activity Figure 6.2 depicts the execution stages (boxes) of an activity, and possible transitions (arrows) between them. Some notable points are the following. - Re-execution may possibly occur after a partial or full backward-recovery. - As stated earlier, retry denotes re-execution that is guaranteed to yield an s-termination. - A full backward-recovery yields the null termination. If re-execution of the activity is intended after the null termination, we take the backward-recovery as part of retry; otherwise, it is taken as compensation. 108

120 - A complete s-termination may become an f-termination, with a change in st-predicate. If this happens before weak commitment, the transitions of an f-termination are followed. Otherwise, if the execution is already weakly committed, then a retry that guarantees s-termination is assured. - If the compensation succeeds we get the null termination. Otherwise, we get a non-null f- termination. The final state of execution of a basic activity is closure. Figure 6.2 shows three possible states of closure: (i) null; (ii) non-null (incomplete or complete) f-termination; and (iii) (complete) s- termination, which also corresponds to strong commitment of the execution. Figure 6.2 is applicable to composite activities also. Complete and incomplete, and s- and f- terminations can be defined for composite activities, analogously. This is done in the model. We illustrate the different categories with the following example. Example 6.3: Let U be a composite activity consisting of (i) writing and printing a letter, (ii) preparing an envelope, and (iii) inserting the letter in the envelope and sealing it. Call the activity (ii) as C. Then C is composed of (a 1 ) printing the From and To addresses on the envelope, perhaps with a printer and (a 2 ) affixing a stamp on the envelope. Consider an execution of U. The following possibilities arise. - (i) is done but (ii) fails possibly because of printing a wrong address. Now we may decide not to bother preparing a new envelope and sending the letter. This is an incomplete f-termination. - (i) and (ii) are done. (iii) is not done (yet). This is an incomplete s-termination. - All the three activities are done, but we realize afterwards that the address is wrong, that is, (ii) is not executed correctly. This is a complete f-termination. - All activities have been done correctly. This is a complete s-termination. 6.3 Composition Model for Activities We now describe our composition model for the activities in an e-contract. We start with a specification of one level, the "bottom" level, in the first two sub-sections, and give multi-level model in Section Path Model We start with a simple model, called the path model, to illustrate the various key aspects. We will extend it to a general model in the next sub-section. Our description is in four parts composition, execution, transactional properties, and implementation details. We use bold font to denote compositions, and italics to denote their executions, that is, the composite activities Composition - Composition C is a rooted tree. It is for an activity of a higher level composition U. - An st-predicate is associated with C. This will prescribe the s-terminations of C (We define s- terminations of a composition later). 109

121 - Nodes in the tree correspond to basic activities. They are denoted as a 1, a 2, etc. - With each node in the tree, an st-predicate and a children execution predicate, abbreviated cepredicate, are associated. - The st-predicate specifies s-terminations of that activity. The ce-predicate specifies, for each s- termination of that node, a set of children from which exactly one child has to be executed, the child being chosen according to a given partial order of preferences. The ce-predicates for the leaf nodes of the composition are null. - We assume that the st-predicate and ce-predicate of each of the nodes in C are derived from the stpredicate of C. Example 6.4: Figure 6.3 (a) shows a composition where C i s are construction activities for a product and I j s are Inspection activities. After the first two stages, C 0 and C 1, of the construction, the inspection I 1 is carried out. Depending on the result, say quality of the product after C 1, C 2 is carried out if possible, and C 2 or C 2 otherwise, in that order. This will be the ce-predicate at I 1. Only the inspection I 2 after C 2 is shown. The st-predicate for each C i will be the guidelines to be followed for that construction. The st-predicate for each I i will be the acceptable results of the things to be checked in that inspection Execution - An execution of activity a i is denoted a i. - A successful execution E of C yields a composite activity C. The execution consists of s- terminations of activities in a path from the root to a leaf (and f-terminations of some other activities). The corresponding nodes form a sub-tree of C, called execution-tree. If all the activities in this path have been executed completely, then E is a complete execution of C. (The example, shown in Figure 6.3(b), has executions of C 0, C 1, I 1 and C 2 with s-terminations and C 1 and I 2 with f-terminations.) Otherwise, that is, if only the activities from the root to some non-leaf node have been executed (for example, only C 0, C 1 and I 1 ) and/or the executions of some activities are not complete (C 2 is still being executed), then it is an incomplete execution of C. If E is a complete (incomplete) execution and each activity in E has s-terminated, then E is a complete (incomplete) s-termination of C. A complete s-termination is usually called simply as an s-termination of C. An f-termination of C is either a complete or incomplete execution in which executions of some activities have f-terminated. - In each s-termination C, at each non-leaf node a i, the selection of the s-terminated child of a i satisfies the ce-predicate currently specified for a i in C. - Both the st-predicate and the ce-predicate at each node a i may be changing as the execution of subsequent activities of C proceeds. 110

122 - Partial execution of C will be represented by a path from the root a 1 to some node a i in the tree, and will be denoted (a 1,..., a i ), and also as C [1,i]. Here, the part that is yet to be executed to get a complete termination of C is the subcomposition of C from a i, called the suffix of C from a i, denoted C [i]. The subcomposition will contain the subtree of C rooted at a i, with the st-predicate and ce-predicate of a i adjusted according to the execution C [1,i], and the st-predicate and cepredicate of all other nodes in the subtree being the same as in C Transactional Properties We first define transactional properties for basic activities. - An execution a i is said to be compensatable if there is a re-execution that will yield the null termination. It is re-triable if there is a re-execution that will yield a s-termination. - An activity a i is atomic if every execution of a i guarantees either a complete s- termination or the null termination. - Each activity a i in C may first be weakly committed, and then strongly committed some time after its s-termination. - Once a i is weakly committed, as stated earlier, it cannot be compensated, and once it is strongly committed, it cannot be retried. - The activities in C are (both weakly and strongly) committed in sequence. That is, when a i is weakly committed, all activities that precede a i in C and have not yet been weakly committed are also weakly committed. Similarly, strong commitments of the executions are also in sequence We now state the transactional properties for the composition. - Composition C assumes that each of its activities a i is executed atomically. Thus an incomplete f- termination of a i is assumed to be compensatable, to get an effective null execution. - The execution of the entire composition C is intended to be atomic in U. (We elaborate this later.) That is, an execution of C should eventually yield a complete s-termination or the null termination. - Consider an execution E of C. If E is an incomplete s-termination, then forward-recovery is carried out by executing the suffix of E in C or a different acceptable sub-composition, to get a complete s-termination. C 0 C 0 C 0 C 1 C 1 C 1 I 1 I 1 I 1 C 2 C 2 C 2 C 2 C 2 C 2 C 2 I 2 I 2 (a) (b) (c) Figure 6.3 (a) A composition, (b) An execution of the composition, (c) A closed c-tree for the execution-tree I 2 111

123 If E is either incomplete or complete f-termination, then the executions of some activities may have to be adjusted (partial backward-recovery) to get an incomplete s-termination, and a forward-recovery is carried out. To get the null termination, E has to be compensated. This is the full backward-recovery Implementation Issues (a) Point of Commitment The execution of an activity a i can be weakly committed any time, and then, after an s- termination, can be strongly committed any time. Weak commitment immediately after the s- termination gives pivotal property in the traditional sense. Waiting until the end of the execution of the entire composite activity will give the compensatability and retriability options until the very end. The longer the commitment is delayed, the more flexibility we have for adjustment on execution of the subsequent activities. However, commitment of some subsequent activities may force the commitment of a i. (b) Adaptivity As mentioned earlier, the ce-predicate will keep changing as the execution proceeds. (This is illustrated below, in Example 6.5.) Also, additional execution paths can be added, as descendents of a node, in the middle of the execution of the composite activity. Some execution paths may be deleted too. Thus, the composition could be adaptive and dynamic. (c) Partial Backward-Recovery Typically, the recovery starts with re-execution of a j, for some j i, where a i is the latest activity that has been or being executed. If a j has to be compensated, then all activities in the execution following a j are also compensated, and a different child of a j-1 is chosen with possibly an updated cepredicate at a j-1. If a j is retried, then, after retrying, a j+1 may need to be compensated or retried. Continuing this way, we will find that for some k, k j, the activities in the sequence (a j,, a k-1 ) are retried and those in (a k,, a i ) are compensated. This is illustrated in the bottom half of Figure 6.4. The following example illustrates backward-recovery. Example 6.5: In the composition of Figure 6.3(a), suppose C 2 was executed after I 1, and I 2 fails. It may be decided that the product be sent back to C 1 for some adjustment and inspected, and the options C 2 and C 2 explored. This would amount to rolling back I 2 and C 2, and re-executing C 1 and I 1, each with adjusted st-predicate. Here the adjusted ce-predicate for I 1 will have only C 2 and C 2 options. Suppose C 2 is tried and the execution was successful. Then the execution-tree will contain all the nodes except C 2, with C 2 and I 2 as f-terminations. This is shown in Figure 6.3(b). Here, nodes for the f-terminated activities are shaded. 112

124 In the above argument, the first activity a k+1 that needs to be compensated is determined after reexecuting its preceding activity a k.. It is quite possible, in some cases, that a k+1 is determined even before re-executing its predecessors. It is also possible that for some of the activities in (a j+1,, a k ), their previous executions are still valid, that is, no re-executions are necessary. We simply take this as requiring trivial re-executions. In Figure 6.4, we note that if m is the largest index such that a m is strongly committed, then j > m, and if n is the largest index such that a n is weakly committed, then k+1 > n. This follows since, by the definitions of strong and weak commitments, executions of activities up to a m cannot be retried and those up to a n cannot be compensated. In the figure, a n is not shown. It will be between a m and a k+1. (d) Dependencies Several dependencies are possible between execution states of different activities. I. In general, any of the compensation, weak commit and strong commit actions on one activity may require any of these three actions for another activity. Such dependencies are similar to the abort and commit dependencies for database transactions given by Chrysanthis and Ramamrithm in [CR 1991]. They are given in Table 6.1. The entries indicate the possibilities of the corresponding dependencies, and the entries indicate the impossibility. a j a i Compensate Weak Commit Strong Commit Compensate Weak Commit Strong Commit Table 6.1 Dependency-Table a 1 Last strong commitment point a m Strongly Committed part a l Weakly Committed part Re-execution point a j Re-tried part a k Adjusted part Compensated part a i Figure 6.4 Partial backward-recovery in the Path model 113

125 The relative positions of the nodes a i and a j are as in Figure 6.4, that is, a i is a descendent of a j. Each entry in the table describes that the specified action in the execution of a i requires the specified action in the execution of a j, and also the dependencies where the roles of a i and a j are reversed. Recall that the s- or f-termination status of an execution may be known only at a later time. Hence, with respect to Figure 6.5, it is possible that the f-termination of a j is known only after a i is executed. Thus, it makes sense to talk about how the actions on a node affect the executions of its descendents. Note also the following. o We assume that both weak and strong commitments are in top-down order. Therefore, if a i is weakly committed, then a j must be weakly committed too if it has not been done already. The same applies to strong commitment. o If a j is compensated, then a i must be compensated too. II. Several dependencies which involve re-execution are also possible. We arrive at a general form in several steps [VRK 2009]. 1. In our formalism, a change in the st-predicate of an activity may change the status of its earlier execution from s- to f-termination and hence warrant either a re-execution to get a new s-termination or compensation. That is, a change in the st-predicate value can account for both retrying and compensation. Therefore, we can define dependencies of the form: An f-termination of an activity changes the st-predicate of another activity and, in fact, of several activities. 2. Secondly, recall that the st-predicate is a Boolean expression of property-predicates. Then an f- termination means that some of these predicates are not satisfied. Depending on the propertypredicates that are not satisfied, several f-terminations are possible. We allow for each of these f- terminations to change the st-predicates of other activities possibly differently. Therefore, we can expand the dependencies as follows. Each different type of f-termination of an activity changes the st-predicates of a set of activities in a specific way. 3. Dependencies involving s-terminations are also possible. We have seen that different s- terminations are possible. Each can affect other activities differently. Therefore, a general form of dependencies is: A specific (s- or f-) termination of an execution changes the st-predicates of a set of activities in a specific way. Note that this takes care of another case also: An execution of an activity a k may be an f- termination (with respect to st-predicate prescribed for that activity) but, for some reasons, we need to keep that execution. Then, the only way could be changing the st-predicates of some other activities which in turn change the st-predicate of a k and make the current execution a s-termination. III. We can also state dependencies of the following type. A specific (s- or f-) termination of an activity triggers compensation, weak commit or strong commit of executions of some other activities. The (compensate, re-execute, weak commit and strong commit) actions on a i change the stpredicates of some other activities. 114

126 (The top half of Figure 6.4 shows the weak and strong commits triggered by the compensation or reexecution of the activities in (a j,, a i ).) The execution of an activity a i can be weakly committed any time, and then, after an s- termination, can be strongly committed any time. Weak commitment immediately after the s- termination gives pivotal property in the traditional sense. Waiting until the end of the execution of the entire composite activity will give the compensatability and/or re-executability options until the very end. The longer the commitment is delayed, the more flexibility we have for adjustment on execution of the subsequent activities. However, as we have seen above, executions and commitments of some subsequent activities may also force the commitment of a i. IV. Dependencies constraining the beginning of an execution of an activity can also be defined. For example, for activities a j and descendent a i possible dependencies are: a i cannot begin execution until a j (i) s-terminates, (ii) weak-commits, or (iii) strong-commits. Note that our composition model assumes that the execution of a i cannot begin until the execution of a j begins. We end this sub-section with an example that illustrates some dependencies. Procurement Example This example is drawn from the contract for building a house explained in Section 6.1, that concerns with procurement of a set of windows for the house under construction. The order will contain a detailed list of the number of windows, the size and type of each of them and delivery date. The type description may consist of whether part of the window can be opened and, if so, how it can be opened, insulation and draft protection details, whether made up of single glass or double glass, etc. The activities are described in the following. The execution-tree is simply a directed path containing nodes for each of the activities in the given order, as shown in Figure 6.5. P1. Buyer: Order Preparation Prepare an order and send it to a seller. P2. Seller: Order Acceptance Check the availability of raw materials and the feasibility of meeting the due date, and, if both are satisfactory, then accept the order. P3. Seller: Arrange Manufacturing Forward the order to a manufacturing plant. P4. Plant: Manufacturing Manufacture the goods in the order. P5. Plant: Arrange Shipping Choose a shipping agent (SA) for shipment of the goods to the buyer. P6. SA: Shipping - Pack and ship goods. P7. Buyer: Check Goods Verify that the goods satisfy the prescribed requirements. P8. Buyer: Make Payment Pay the seller. We describe several scenarios giving rise to different transactional properties. 1) Suppose that once the seller decides to accept the order, the order cannot be cancelled by the buyer or the seller, P1 P2 P3 P4 P5 P6 P7 P8 Figure 6.5 Procurement Example 115

127 but modifications to the order are allowed, for example, delivery date changed, quantity increased, etc. If only the modifications that do not result in the non-fulfillment and hence cancellation of the order are allowed, then when the seller accepts the order, both P1 and P2 can be weakly committed. (On the other hand, if there is a possibility of the order getting cancelled, weak commitment has to be postponed. We do not consider this case any further in the following.) 2) Suppose there is a dependency stating that the order can be sent to the manufacturing plant only after its acceptance by the seller, that is, the execution of P3 can begin only after P2 is weakly committed. 3) The plant may find that the goods cannot be manufactured according to the specifications, that is, P4 fails. Then the buyer may be requested to modify the order. For example, if the failure is due to inability to produce the required quantity by the due date, then the modification could be extension of the due date or reduction of the quantity or both. (Similar situation arises when the buyer wants to update the order by increasing the quantity.) This will result in a re-execution of P1 followed by a re-execution of P2. Then the past execution of P4 may be successful or a reexecution may be done. Weak commitments of P1 and P2 allow for such adjustments. 4) If the buyer finds that the goods do not meet the type specifications, that is, P7 fails, then, P4 has to be re-executed. In addition, P5 and P6 have to be re-executed. (This situation may arise also when the plant realizes some defects in the goods and recalls them after they were shipped.) Here, the re-executions may consist of the buyer shipping back the already received goods to the plant and the plant shipping the new goods to the buyer. An example is: two of the windows have broken glasses and a wrong knob was sent for a third window. (The knob has to be fixed after mounting the window.) Then, replacements for the two windows have to be made (in P4), the damaged windows and the wrong knob have to be picked up and the new ones delivered, perhaps by the same shipping agent (in which case the re-execution of P5 is trivial). 5) The shipping agent is unable to pack and ship goods at the designated time, that is, P6 fails. Then either the delivery date is postponed (adjustment in the st-predicate of P1) or the plant may find another shipping agent, that is, P5 is re-executed. In the latter case, it follows that P6 will also be re-executed Tree Model We now present an extension, called the tree model. Here, we consider compositions that allow for more than one child to be executed at non-leaf nodes. Therefore, the execution yields a tree, instead of just a path, as a composite activity. The features of this model are essentially the same as in the path model. The difference is only in the complexity of the details. We outline the details in the following. 116

128 Composition Here also, a composition C is a tree and it is a part of a higher level composition U. A stpredicate is associated with C. A st-predicate and a ce-predicate are associated with each node. These will be derived from the st-predicate of C. The ce-predicate is null for all leaves of C. The cepredicate at non-leaf nodes may be sophisticated. More than one child may be required to be executed. In general, several sets of children may be specified with the requirement that one of those sets be executed. These sets may be prioritized in an arbitrary way. Execution of children within a set may also be prioritized in an arbitrary way Execution An execution E of C yields a composite activity C, which is a sub-tree of C, namely, an execution-tree, such that - It includes the root and some descendents; - Some nodes are (fully compensated) f-terminations; If a node is an f-termination, then all descendents of that node in the execution tree are also f-terminations; and - The execution of each s-terminated node satisfies the st-predicate prescribed for that node, and the non-f-terminated children of each non-leaf node of the sub-tree satisfy (fully or partially) the ce-predicate specified in C for that node. An s-termination of C is an execution of C such that the non-f-terminated nodes yield a sub-tree of C that contains (i) the root, (ii) some leaves of C and (iii) all nodes and edges in the paths from the root to those leaves. A partial execution E of C will be represented by a sub-tree of C consisting of all the nodes of C that have been executed so far and the edges between them. The suffix of the execution E can be defined similar to that in the path model. It will consist of sub-trees of C rooted at some of the leaves of the execution tree, with st- and ce-predicates properly adjusted Transactional Properties The following definitions refine those given for the path model. - We say that the execution a i is locally compensatable if the execution can be undone to get the null termination. We also define another notion: a i is compensatable relative to C if either a i is locally compensatable or it can be compensated by executing a compensating activity within C. - Similarly, an execution a i is locally retriable if there is a re-execution that will yield an s- termination. And, a i is retriable relative to C if either a i is locally retriable or additional activities can be executed in C to get the effects of an s-termination of a i. 117

129 - An execution a i is locally weakly committed if it is locally non-compensatable (but locally retriable) and weakly committed relative to C if it is non-compensatable relative to C (but retriable relative to C). The strong commit properties are similar. - We define atomicity of a basic activity also in two ways: a i is locally atomic if every execution guarantees either a complete s-termination or the null termination; and it is atomic relative to C if either it is locally atomic or (i) any non-null f-termination can be compensated by executing a compensating activity in C and (ii) any incomplete s-termination can be extended to a complete s-termination by executing additional activities in C. Composition C expects that each of its activities a i is atomic relative to C. - Again, the execution of the entire composition C is intended to be atomic in U. That is, an execution of C should yield a complete s-termination or the null termination. Therefore, if an s- termination of an activity a i is not possible in some execution, then (that execution of a i is compensated and) execution of a different set of children satisfying the ce-predicate of its parent is tried. If unsuccessful, then a different s-termination of the parent is tried. If not, similar adjustments at the grand-parent level are tried, and so on. Thus, either a complete backward recovery yielding the null termination or a partial backward recovery followed by forward execution to get an s-termination of C is carried out. Forward-recovery of E will consist of execution of the suffix of E. Partial backward-recovery of E will again consist of retrying the executions of some of the activities of the execution-tree, and compensating some others. This is illustrated in Figure 6.6. Re-executed part Compensated part Figure 6.6 Partial backward-recovery in the Tree-model Implementation Issues All the issues discussed in the path model section are applicable here also. In the general case, where the execution-tree is a tree (see Fig. 6.6), the dependencies and the partial rollback are similar to the path case. The difference is only in the complexity of the details. All the dependencies 118

130 P3 P4-A P4-B P5-A P5-B P6-A P6-B Figure 6.7 Procurement example with two plants discussed so far are applicable in the general case also, both for vertically (that is, ancestrally) and horizontally related activities. In addition, for horizontally related activities a i and a j, all combinations in the Dependency-Table 6.1 are possible, that is, all entries will be. Dependencies that involve ce-predicates are also possible. A general statement would be: A specific (s- or f-) termination, compensate, weak and strong commit actions of an activity changes the ce-predicates of some other activities. Procurement example revisited: In the example illustrated in the last sub-section, suppose the seller splits the order into two parts and assigns them to two plants Plant-A and Plant-B. Then the node P3 will have two children and its ce-predicate will contain the details of the individual orders. Corresponding to P4, P5 and P6, we will have P4-A, P5-A and P6-A for Plant-A, and P4-B, P5-B and P6-B for Plant-B. This is shown in Figure 6.7. We describe a few scenarios and the resulting dependencies. 1) The seller may decide that shipping should not start until all the goods in the order have been manufactured. The gives rise to the dependencies: begin P5-A and P5-B only after both P4-A and P4- B s-terminate. 2) P5-A fails, that is, Plant-A is unable to find a shipping agent. Then, the shipping agent of Plant-B may be asked to ship the goods of Plant-A also. This may involve changing the st-predicate if the execution of P6-B has not been done or re-execution of P6-B otherwise. 3) The buyer is not satisfied with the goods manufactured in Plant-A, that is, P7 fails. Then, the seller might settle for the buyer returning those goods and Plant-B manufacture those goods and send to the buyer. This involves changing the ce-predicate at P3, compensation of P4-A, P5-A and P6-A, and reexecution of P4-B, P5-B and P6-B Multi-Level Model So far, we have dealt with compositions at a single level, in fact, the bottom-most level where all activities are basic activities. Now we extend the model by allowing basic or composite activities in the compositions. This gives us a multi-level, hierarchical, composition model. The highest level activity is the contract-activity. In the previous sections, a composition C is described as a tree. An 119

131 P1 P2 P3 P4-A P4-B P5-A P5-B P6-A P6-B P7 P8 Figure 6.8 Two-level composition for the Procurement example execution of C yields a composite activity C, which is a path graph in the path model and a tree in the tree model. We call (both of) them a composite activity tree, or c-tree in short. An outline of the multi-level model is the following Composition A composition C is a tree as in the tree model. Nodes in the tree are (sub)compositions of basic or composite activities. Compositions of composite activities are, again, trees as in the tree model. Thus C is a nested tree. An st-predicate is associated with C Execution Execution of each subcomposition of C yields a c-tree. (For a basic activity, the c-tree will have just one node.) To put these trees together, we use the following notation. A c-tree is converted to a one source one sink acyclic graph by adding edges from the leaves of the tree to a single (dummy) sink node. We call this a closed c-tree. Figure 6.3(c) shows a closed c-tree for the execution-tree in Figure 6.3(b). Figure 6.8 illustrates the two-level composition for the Procurement example. In the execution of a multi-level composition C, at the top level we get a closed c-tree with nodes corresponding to the executions of activities in C. Each of the activities will again yield a closed c- tree. Thus, the graph can be expanded until all the nodes correspond to basic activities. Partial execution is considered as in the tree model, level by level, in nested fashion. 120

132 Transactional Properties At each individual level, for each node, the transactional properties discussed with the tree model are applicable. After the recovery of one node, the recovery efforts at the parent level execution will continue. We have already discussed s-terminations and f-terminations of composite activities. We can define compensatability, retriability and commit properties as well as atomicity for composite activities as we did for basic activities, namely, both locally as well as relative to the parent level composite activity U. For example, C is locally compensatable if the null effect can be obtained by simply modifying the composition C and executing, and is compensatable relative to U if it is compensatable either locally or by executing a compensating activity, say C, within U. In the latter case, C will also be specified as a tree with suitable st-predicate. (For example, if the original execution is building a garden shed in the backyard, the compensation might be the demolition of that shed.). This compensation will also be specified as a tree with suitable st-predicate. Retrying a composite activity involves, in the general case, a possible backward-recovery followed by forwardrecovery. The forward-recovery part can be accommodated by adding additional subtrees at some nodes and specifying the st- and ce-predicates for the nodes in them, and adjusting the ce-predicates of other nodes appropriately. Thus, in general, re-execution of a composite activity would require adjusting the composition of that activity in terms of adding and/or deleting some nodes and adjusting the st- and ce-predicate of the nodes. This can also be thought of as coming up with a new composition for that activity, mapping the previous execution on the new composition, identifying the s-terminated part, and doing a backward- and/or forward-recovery. The re-execution and adjustments of the st- and ce-predicates will then be top-down. We can also extend these definitions across multiple levels. For example, in the above case where C is compensatable relative to U, we say that a i is also compensatable relative to U even if a i is not compensatable relative to C. By this, we mean that the effects of a i can be compensated either by compensation of C by C or by a compensating activity a i, both in U. The definitions for retriability are analogous. Thus, in general, re-execution of a composite activity would require adjusting the composition of that activity in terms of adding and/or deleting some nodes and adjusting the st- and ce-predicate of the nodes. This can also be thought of as coming up with a new composition for that activity, mapping the previous execution on the new composition, identifying the s-terminated part, and doing a backward- and/or forward-recovery Multi-Level Commitment and Closure (a) Commitment As we referred to earlier, suppose C is a composition corresponding to a composite activity of U, and a i is the composition of an activity of C. Let a i, C and U be the respective executions. We have defined the compensatability and properties of a i to be relative to C. Similarly, compensatability and retriability of C will be relative to U. 121

133 Example 6.6: In Example 6.3, suppose the addresses are printed and the stamp glued, and we find later that the To address is incorrect. If the affixed stamp cannot be removed, the activity a 2 is noncompensatable, but only relative to C. The activity C itself may be compensatable relative to U, amounting to just tearing up the envelope and bearing the loss of the stamp. Then, though a 2 itself is not compensated the composite activity containing a 2 is compensated. Similarly, the commitment properties at the two levels are also independent of each other. We give two examples. (1) Activity a i could be strongly committed, meaning that it cannot be compensated or re-executed in C, but C itself may be weakly committed relative to U, meaning that it may be re-executed perhaps with additional activities. C could be weakly committed even if some activities of C are not executed yet, if retrying of C can be carried out by compensating the current execution completely and re-executing it to get an s-termination. (2) An example of a i being weakly committed and C being strongly committed is that of fixing (perhaps in the warranty period) a broken pipe after the construction of the house is finished and the builder paid fully. Thus our model allows, as mentioned in Section 6.1, re-executing even a committed activity, by dealing with commitment in multiple levels. (b) Closure of Composite Activities A composite activity C also can be closed in three different states depicted in Figure 6.2, namely, null termination, (incomplete or complete) non-null f-termination, and (complete) strongly committed s-termination. The null execution might be the result of executing a compensating activity. Therefore, in any of these terminations of C, the constituent activities of C might be closed in any of the three terminations. Now, C may be closed either before or after some or all of the constituent activities of C are closed. An example of the former would be not waiting for the closure, or even termination, of some activities that compensate some other activities in the original execution of C, that are guaranteed to succeed. (c) Closure of E-contract Some of the activities (usually high level ones) will correspond to parts of the contract or subcontracts. As noted earlier, at the highest level, the composition is for the entire contract-activity. On closure of such activities, the corresponding contracts themselves might be closed. Closure of a contract intuitively refers to expiring the life or validity of the contract. For example, a contract for building a house may close after the warranty period during which the builder is responsible for repairs. A sub-contract for maintaining an air-conditioning system installed in that house may close at a different time. The transactional properties in our model can be used to refine the conditions for closure of the contracts Implementation Issues All the issues discussed for the single level (bottom level) composition are applicable here also within each level, and also across levels. For example, suppose as before that a i is an activity of C which is a composite activity of U, and C is another composite activity of U. We may have a dependency of the type: if a i is strongly committed then C has to be compensated. 122

134 We discuss some additional issues in the following. We have associated an st-predicate and a ce-predicate with each activity in our model. They are activity-dependent. We can expect that they can be expressed more precisely for some activities than for some others. In fact, for some activities, what constitutes s-termination may not be known until after an execution of that activity, and even after the execution of many subsequent activities. We note also that the st-predicate of a composite activity determines the st-predicate and the ce-predicate of its constituent activities. Hence, specification of the st- and ce-predicates is crucial. This will be the role of the (activity and) workflow semantics. Whereas the semantic specification of ce-predicate would be application-dependent, syntactic specification may be made more precise, with an appropriate language. We can expect that such a language would have constructs for specifying priorities and Boolean connectives. An example is booking an all (flight-hotel-food) inclusive package, and if it is not available then booking flights and three-star hotels separately, for a vacation. The ce-predicate allows specifying preferences in the selection of the children activities to be executed. Preferences may exist for s-terminations too. This may depend on functional as well as nonfunctional aspects of the execution. Such preferences can be incorporated in the model easily. In a multi-level set up, the activities that are re-executed or rolled back would, in general, be composite activities, that too executed by different parties autonomously. Therefore, the choices for re-execution and roll back may be limited and considerable pre-planning may be required in the design phase of the contract. Multi-level composition model is useful to handle escalations, if necessary. In e-contracts, when a dispute occurs, the concerned parties arbitrate and find appropriate solution to overcome it. Suppose, at one level, any dispute occurs, it can be resolved by taking appropriate action at next higher levels. M1 M11 M12 M113 a b c d e f Figure 6.9 An example of Multi-level model 123

135 Consider the multi-level composition model shown in Figure 6.9. Assume that the low-level node e (in M 113 ) is successfully terminated. If any dispute occurs after execution of node e, then it can be escalated. Suppose, the concerned parties decide the resolution procedure as to re-execute, then the composite activity M 113 is re-executed, by changing the ce-predicate of M 11. Note that though the atomic activity e is strongly committed in the previous executions, the composite activity M 113 is reexecuted. This is similar to example described in Example 6.6. Table 6.2 presents issues and solutions to support activity commitments through composition model (path, tree and multilevel models) while enacting e-contracts. In this thesis work, we assume that composition model is build manually from the (i) activities and clauses of an e-contract and (ii) the relationships specified in ER EC models and (iii) workflows defined over inter- and intraorganizational activities. Further, in order to provide support for developing this composition model, we need additional technologies and tools including active database support, logic formalisms, WFMS and web services. Issues Different executions of an activity might have different characteristics An activity has been executed successfully or not may not be know until some other subsequent activities have been executed. When execution of an activity is not successful, then executions of some other activities have to be adjusted. Guarantee termination for in-complete executions Monitoring Successful termination of activities Tracking the activity executions Many interdependent activities and clauses govern activities execution. Backward and forward recovery of activities execution at each level independent of its descendent levels Supporting composite activities commitments Supporting higher- activity commitments, including contract itself as a whole. Composition model support Attributing transactional properties to the execution of activities instead of activities themselves. Weak commit and strong commit ensures this dependency Compensation and re-execution properties of an activity transaction are useful in adjusting other activities execution. Attributing compensation and retriability properties to incomplete executions also. Attributing a st-predicate and ce-predicate to an activity. Monitoring Execution-tree derived from a composition. Relating interdependencies to execution states of the activities. Atomicity defined for executions of composite activities of any level ensures the backward and forward recoveries Tree model helps in handling composite activity commitments with the transactional properties as defined similar to path model. Multi-level model helps in guaranteeing the successful termination of higher-level activities and also contract closure. Table 6.2 List of issues and solutions in e-contract activity commitments 124

136 6.4 Summary In this chapter, we have presented a framework for e-contract commitment by considering transactional properties for executions of activities of the e-contract. Accommodating the transactional properties can improve an e-contract design and, in turn, help in the enactment of the underlying contract. Some important aspects are the following. i. Level-wise definitions of compensatability and retriability clarify the properties and requirements in the executions of activities and sub-activities, in contracts and sub-contracts. This helps in delegating responsibilities for satisfying the required properties in the executions to relevant parties precisely and unambiguously. ii. We are able to look at and formalize closure of the activities from commitment perspective. iii. Closure of the contract can be tied to closure of the activities and commitments. Features such as the life of a contract may extend far beyond the termination of execution of the activities are accommodated fairly easily. iv. Interdependencies of the executions of the activities, in particular with respect to re-execution and roll back, can be brought out more clearly and explicitly. v. We could see the interdependencies between the transactional properties and clauses. This will help in designing clauses appropriately in the preparation phase of a contract and in satisfying the clauses in the execution phase of the contract. vi. Terms of payments for the activities (including the contract-activity) can be related to the execution states of the activities (see chapter 7). The transactional properties described in this work will be useful in other applications also, irrespective of whether the activities are electronic, non-electronic or both. In the presented multi-level model, we get composite activities in the form of a special type of acyclic graphs. This structure may be sufficient for most activities. It contains sequence, AND splits and joins, and OR splits and joins, for instance. However, the model can be extended to get composite activities in arbitrary acyclic graph structures. This extension is beyond the scope of this thesis. An e-contract system must ensure the progress of activities and their termination. Since e- contracts consist of multiple activities executed with several inter-dependencies, any failure could have cascading effects on other executed or executing activities. In this work, we have also brought out these dependencies explicitly and facilitated solutions that can be incorporated within an e- contract system. This study will be helpful in monitoring behavioral conditions stated in an e-contract during its execution. The e-contract closure is mostly a human decision. It involves settlement, of payment and other issues, between the parties. To eventual closure of the contract, the transactional properties described in this chapter should help to coordinate payments. This is because payments are integral part of most of the contracts. We extend our composition model to streamline payments and closure of the e- contract. There are two critical aspects that dictate the payments in the e-contracts. First, one should be able to ascertain that the e-contract has been executed to deserve the payment. This requires us to 125

137 have an understanding about the execution states of the e-contracts (or, of activities, therein). Second, there needs to be understanding of amount of payments to be made. Unfortunately, the e-contracts only specify certain scenarios where payments need to be made. If payment is required for some other scenario then it is treated as exception which can require a time consuming process to ensure the need for payment (so as to not to set a precedent). But unfortunately, even to decide on the requirement for payment appropriate accounting of the progress made in the e-contract has to be available. In the next chapter, we show that the transactional properties in our composition model provide a good basis for the design of the payment terms for the executions of activities. Also, a flexible scheme, both for cost evaluation and for payment, is described to deal with identifying the payments to be made, and initiating the payment. 126

138 Chapter 7 Payments The activities in e-contracts are to be executed by the parties satisfying the clauses, in accordance with the associated terms of payment. The payment component of e-contracts has two sides, cost and payment itself. Both need to be monitored. The composition model described in the previous chapter is useful to track the activities execution and their payments. For instance, the cost at any point in the execution can be derived from the execution-tree at that time. However, the payments need to be treated specially, because of the following: Payments transactions are internally non-compensatable. Payments are tightly coupled with activity transactions, which may result in multiple payment points. Payment transactions and activity transactions will act as coupled transactions. Payment transactions need to be handled in a non-trivial manner as they possess additional run-time dependency, rather than specification time. Also, cost of an activity is directly related to activity progression, that is, it depends on execution states of an activity such as number of compensations and retrys. This chapter focuses on payment issues in e-contracts. Payments are meant for, and so are closely related to, the execution of activities specified in the contract. We consider (i) the payment amount for the execution of an activity, (ii) the time of payment relative to the execution and (iii) tracking the payment against the execution of the activity. For the first two, we use an execution model that enables representing a variety of states encountered in the generally complex executions of the activities in a contract. For tracking, we use a multi-level composition model, described in the previous chapter, for the activities. This study brings out various issues that need to be addressed in designing a payment monitoring system. 7.1 Introduction A contract is a legal agreement involving parties, activities, clauses and payments. The activities are to be executed by the parties satisfying the clauses, in accordance with the associated terms of payment. Consider a contract for building a house described in chapter 6, section 6.1. An example of a clause relating to payments can be, in verbatim, as follows. If the bank is of the opinion that the progress of work of construction of the said house is unsatisfactory, the bank shall be at liberty to decline to make payment of any undisbursed installment of the said loan or at its discretion postpone the payment thereof until such time the bank is satisfied that the cause or causes for its dissatisfaction with the progress and quality of work has or have been removed.. 127

139 Payments are made to parties. They may be constrained by clauses. Unlike in traditional information systems, executions of activities in e-contracts are subjected to risks and losses (in case of non-performance), trust issues (among parties with respect to satisfactory execution), ambiguity in specifications (in clauses), different types of failures (especially of non-electronic ones) and potential variations in outcomes. All these parameters influence the cost of an activity in the e-contract. Most importantly, payments are meant for, and so are closely related to, the execution of activities in the contract. We show that our multi-level composition model helps in computing the costs and for monitoring payments. Different terminations in an execution of an activity are given in Figure 7.1. In the case m > 1, each Termination-i, for i between 1 and m-1, is both compensatable and re-executable. Terminationm either leads to a (compensated or non-compensated) f-termination or becomes a weakly committed wc-termination-1. In the latter case, we eventually get a strongly committed sc-termination. Note that the case where both m and n are 1 refers to the first termination itself being successful, and weakly and strongly committed. We identify the execution states of the activities in terms of their transactional (compensatability, retriability and commit) properties and relate the states to costs of, and payments for, the activities. We show how the composition model helps both for computing the costs of the executions and monitoring payments. Payments are meant for the execution of the activities in the e-contract. Hence, we should be able to ascertain that the activities have been executed (or compensated) satisfactorily to deserve payment. We are concerned with three critical aspects that dictate the payments for an activity: the cost of execution of the activity; the amount of payment for the execution; and the time of payment for that activity. All these require a good understanding of the execution states of the activities and hence the e-contract. Begin Termination-1 Start execution Re-executions Compensatable and Re-executable Termination-m, m 1 Try to Compensate Weak commit f-termination wc-termination-1 Noncompensatable and non-re-executable Retrys wc-termination-n, n 1 Non-compensatable but retriable Strong Commit Figure 7.1 Different terminations sc-termination Non-compensatable and non-re-executable Payment enabled points 128

140 7.2 Cost and Payment Below we discuss different ways of assigning cost and the amount of payment for an execution [VRK 2008]. Let C be a composite activity consisting of basic activities a 1, a 2, etc. There are two aspects cost of execution of an activity a i (i) for a i and (ii) for C, that is, the cost charged to C and hence to be paid by (the service executing) C to (the service executing) a i. We look at both of them. We use cost(a i ) and payment(a i ) to denote (i) and (ii), respectively. Cost: - A cost may be associated with each execution related to a i. The total cost cost(a i ) will depend on the number of executions related to a i. - Different s-terminations are possible. They may have different costs. (For example, fully refundable flight tickets normally cost more than non-refundable tickets.) We will not concern about how the costs are arrived at. - A non-executed null termination will cost nothing. If an activity a i has been executed and then compensated, even if the resulting execution is effectively null, a cost may have to be associated. - With non-null f-terminations also, a cost may be associated. - Each re-execution may incur additional cost. Therefore, as the number of re-executions (as depicted in Figure 7.1) increases, the cost of the activity cost(a i ) will keep going higher. - Therefore, the final cost of execution, cost(a i ), will depend on the number of (re-executions and hence) terminations, and will be known to a i only when its execution is strongly committed. Payment: - Payment for a i, namely, payment(a i ), may not directly depend on the number of executions related to a i. - The cost of an execution resulting in a f-termination and the cost of compensating that execution may not be charged for the payment. - When several re-executions are done, the costs for some of them may not be charged. - The above considerations apply when the payment amount is determined after the execution of the activity. However, depending on which costs are not charged to C, payment(a i ) may be known earlier. For example, if the charge is zero for a compensated a i, it can be known even before the compensation is complete, and if re-execution costs are not charged to C, then payment(a i ) can be known on weak commitment of a i. - On the other hand, payment(a i ) could be fixed even before the execution of a i starts, for example, when the parties are entering into contracts. Then the amount could be based on the number of anticipated re-executions and the prospects of arriving at a satisfactory s- termination eventually. The cost and payment for a composite activity will depend on the costs and payments for the individual activities in the composition that are executed. 129

141 We now illustrate some scenarios in the Procurement example of Section 6.3 (Chapter 6). A. When the goods are not delivered on time (P6), the buyer can insist on canceling the order. Then, a cost is incurred in the initial delivery of the goods as well as in the return of the goods as part of canceling the order, though the effective execution of that activity is null. B. Consider another related clause: If the goods are not confirming as per the contract, the buyer may require the seller to remedy the lack of conformity by repair. Then further costs are involved in returning the goods, repairing them and sending them back to the buyer. There are two aspects for payment(s) for an activity also enabling payments and making payments. Various payment options are as given below : - For each activity, either a single payment or multiple (partial) payments may be enabled at various terminations depicted in Figure 7.1. Similarly, payments can be made just once or in several installments. The number of installments need not correlate with the number of enabling points. - A payment can be (partly or fully) refundable or non-refundable. In the former case, we need to calculate refund with respect to payments made previously (for example, when some activity that has been prepaid has not been executed). In the latter case, making payments may be delayed until a good estimate of the cost of execution is obtained. - As stated earlier, the actual cost of execution may be known only after strongly committed s- termination or f-termination. Then, any payments done in other states may have to be adjusted at the end. We will not consider the details (such as the time and the amount) of the adjustments in this work. A payment monitoring system should keep track of the state of termination, payment-enabled and payment-made points and the amounts, for each activity. 7.3 Payment for Basic Activities We first consider the bottom-most level, where each composite activity is composed of basic activities; the general model for activities at multiple levels is considered in the next section. The same composition model described in section 6.3 of chapter 6 is applicable for handling payments. Each activity in the execution-tree has to be paid for. - For each activity, payment(s) may be enabled and made in any of the terminations of execution of that activity, as discussed earlier (see figure 7.1), and also in the states of weak or strong commits relative to C. In addition, payment for a i may be enabled either when a i is locally weakly committed or only when it is weakly committed relative to C, meaning that it will not be compensated even by a compensating activity in C. - If an execution a i is compensated by execution a i of a compensating activity, then both a i and a i will appear in the execution-tree, and costs may be attributed to them individually. - Similarly, if re-trying of a i is done by executing additional activities, their executions will also be in the execution-tree and costs can be assigned to them. 130

142 - Enabling and making payments for different activities can occur at different times. - Dependencies may exist between enabling/making payments of different activities. - Dependencies may also exist between enabling/making payments for one activity and starting the execution of (and similarly, compensating, weakly committing and strongly committing) another activity, and vice versa. - At any stage, the activities whose payments have been enabled and those whose payments have been made are kept track of with a payment-enabled-tree and a payment-made-tree, respectively. We note that the execution-tree (example shown in figure 6.3(b)) and the two payment trees are all sub-trees of the composition graph C. As the execution of the contract progresses, all these trees will grow. By comparing them, the correspondence between the execution of the activities and enabling/making payments for them can be obtained. Example 7.1: For the case discussed in the Example 6.5 (chapter 6), a payment-made-tree could have all the nodes except I 2. This is shown in Figure 7.2. Comparing with the execution-tree described in Figure 6.3(b) (chapter 6), payment for I 2 has not been done yet, and payment for C 2 has also been done even though only one of C 2 or C 2 is to be executed. The payment for the nonexecuted activity has to be adjusted later on. The cost of an execution E of a composite activity C is simply the sum of the payments for the executions of its constituent activities. Below we present an example to illustrate the execution of activities and terms of payments. In the house-building contract, consider a sub-task involving construction of a wall and painting it. The activities are shown in Table 7.1. The work begins with the gathering of all required materials such as bricks, cement, paint, paint brushes, etc. On Inspection-I, if some materials are missing, then they are also gathered (re-execution of activity 1). Once all the materials are gathered, a 20cms thick wall is constructed as per the building specifications. After this process, Inspection-II is done to check the strength of the wall and the quality of the job done. If slight fixing is needed, some more work is done (re-execution) and then the inspection is carried out again. If (zero or more) slight fixes do not yield satisfactory results, the wall is demolished (compensating activity) and a 30cms thick wall is built, starting from acquisition of further material. (This is a partial roll back of the execution.) Even with the new wall, slight fixing and/or complete demolishing and re-building may occur, in fact, several times. Eventually, when the wall is constructed to the satisfaction, it is painted. C 0 C 1 I 1 C 2 C 2 C 2 Figure 7.2 A payment-made-tree for the composition 131

143 Activity Specification Execution Commitment Aspect Terms of Payments 1. Material acquisition Materials gathered 1a. Acquisition of additional material 2. Inspection-I Materials found missing Materials found in order Re-execute 1 (1a) and 2 Weak commit 1, 2 Payment-1 (for 1 and 2) due 3. Building 20cms thick wall Wall constructed 3a. Doing slight fixing 3b. Demolishing wall 3c. Building 30cms thick wall 4. Inspection-II Slight fixing required Wall not strong enough Re-execute 3 (3a) Compensate 3 (3b), retry 1 (1a), & 2, and reexecute 3 (3c) and 4 Payment-2 (for 3, 4, & re-executions of 1-4, if any) due 5. Painting the wall 5a. Do undercoat 5b Do overcoat Construction done in order Undercoat and one overcoat 6. Inspection-III Very bad paint job Another overcoat needed Job done in order Strong commit 1-4 Re-execute 5. (5a and 5b) and 6 Weak commit 5; Retry 5 (5b), 6. Strong commit 5,6 Do not start until Payment-1 and Payment-2 received Payment-3 due Table 7.1 Some activities and payments of an example: construction and painting job of a wall The re-execution and compensation details are given in the table. Re-executions carried out after weak commits are stated as retrys. Weak and strong commit points for the various activities are also given. On weak commit of activities 1 and 2, the acquired materials cannot be returned (activities cannot be compensated). When the wall is constructed according to satisfaction, activities 1 to 4 are strongly committed. Note that activities 3 and 4 are directly strongly committed, without earlier weak commit. For the paint job, weak commit occurs when it is found that another undercoat is not required, and strong commit occurs when the painting is completely satisfactory. The table states the terms for three payments: when they are due and the requirement that the first two payments must be received before painting of the wall can start. The costs for the execution, including re-executions and compensations, are included in the payment descriptions. Payments Activities Related Cost Incurred (as per Column 3, Table 2) Payment-1 Activity 1 and Activity 2 C1 + C2 + RE1a + RE2 Payment-2 Activity 3 and Activity 4 Re-executions of 1 to 4 if any. C3 + C4+ RE3a + CS3b + RE1a + RE2 + RE3c + C4 Payment-3 Activity 5 and Activity 6 C5 + C6 + RE5a + RE 5b + C6 + RE5b + C6 Table 7.2 Costs for execution of the activities described in Table

144 Table 7.2 shows the costs while executing the activities as given in Table 7.1. The cost of the first execution, compensation and re-execution are denoted as C, CS and RE respectively, followed by the activity number specified in Table 2. Note that, in a normal straightforward situation, the expected cost of the composite activity for construction and painting of the wall is C1 + C2 + C3 + C4 + C5 + C6. However, due to multiple re-executions and compensation, the total cost may become higher than the expected cost. 7.4 Multi-level Composition For computing the cost as well as keeping track of the payments, a straight-forward approach is to use the (multi-level) execution-tree and similarly the corresponding payment trees. All these will be updated, as the execution proceeds and payments are enabled and made. One way of computing the cost of a composite activity is considering the single level execution tree of that activity. For example, in a composition U consisting of a composite activity C which again consists of basic activities a i s, payment(a i ) of each a i (which is the amount charged to C) is added to get cost(c). However, payment(c) may be different, and this is the amount used, for each constituent activity of U, to compute cost(u). Thus the costs can be computed recursively, in bottom-up fashion. For keeping track of the payments also, several sub-trees (of the fully nested payment trees described above) can be used depending on the level of detail that we are interested in. For example, considering the composite activity C, if at the level of U, only the lump-sum payment for C is of interest, then there is no need to expand the node corresponding to C to the sub-tree representing the execution of the activities of C. (This latter sub-tree will be used at the level of C.) This will be appropriate, for example, when C is a sub-contracted activity, executed and managed by a different party. The extended definitions of transactional properties allow enabling and making payments in sophisticated ways. For example, payment for a i can be enabled only when it is weakly committed relative to U. This policy might be appropriate when payment authorizations come from U and not from C. The various dependencies can be defined between activities at different levels too. For example, payment for a i may be enabled after payment for U is enabled and irrespective of whether payment for C is enabled. Another example is starting the execution of some activity D in U only after payment is made for a i. 7.5 Discussion We have expressed that costs are determined by the executions. It is also possible that costs and payments influence the execution. Examples are: 133

145 - We associated a cost for each retry. Then, the total cost for execution of an activity will increase with the number of re-executions. If a maximum cost is stipulated for an activity, then that could limit the number of re-executions. - Payment may influence the time of commitment. For example, a non-refundable payment can be associated with weak commitment which can be delayed until it is certain that the execution does not need to be compensated. Similarly, if no retrys can be expected after payment, then strong commitment can be combined with the payment. Activities in e-contract may be executed autonomously. Then, details of payments for them may also be kept autonomously. The ability to deal with payment trees of different levels, with activities described at different depths of the hierarchy, supports the autonomy. In the literature, the inter-dependency among contract satisfaction, activity execution and payments has not been explicitly modeled. The utility of such modeling in deploying and managing the commitment and payment aspects of e-contract is immense. Some of the open issues in this problem domain are: initiating payment transactions for making appropriate payments; extraction of related clauses for payments and monitoring of payments; and finding profitable contracts in an organization when multiple contracts are in execution. It is expected that, in future, e-contract management systems will seamlessly process contracts and monitor their completion and payment aspects. In contracts, payment terms are arrived at based on negotiations. Normally, we can expect that all payments will be made before the closure of the contract. However, there are exceptions some of which may be very sophisticated. An example is a contract for the construction of a flyover in which (a part of) the payment is through toll gate collection for a few years after the construction is finished. 7.6 Summary In this chapter, we addressed the vital issue of payments in e-contracts. Payments are closely linked to the execution of activities. Terms of payments for the activities (including the contractactivity) can be related to the execution states of the activities. With an execution model that accommodates the complexity of the activities in contracts, we have correlated several payment issues to the states of execution. This study brings out various issues that need to be addressed in designing a payment monitoring system. 134

146 Chapter 8 Conclusions E-contracts begin as legal documents and end up as processes that help organizations abide by the legal rules while fulfilling contract terms. As contracts are complex, their deployment is predominantly established and fulfilled with significant human involvement. Thus, automated fulfillment of e-contracts is a challenging task. In this thesis, we have analyzed and discussed some of the salient features and problems faced in modeling and enactment of e-contracts. We have analyzed the e-contract documents in depth and proposed a conceptual model and a framework to design and deployment of an e-contract system. Starting from a contract document the thesis has proposed a methodology for arriving at the enactment based on the ER EC model. This research has tried to use, extend and integrate several related research approaches. The presented examples and case studies have demonstrated the practicality and usability of the ER EC model in the design and implementation of e-contract systems. Document contracts gave us breadth and depth of the problem, but we can apply our solution to from the scratch contracts that are designed. 8.1 Summary of Contributions A brief summary of the original contributions of this research are given below: First, the thesis has proposed a means to represent the meta-model for modeling e-contracts by extending the ER model, known as ER EC model (Chapter 3). Emphasis has been laid on modeling rules, exceptions and complex inter-relationships between various entities including activities, parties and clauses. The meta-model is a very generic so that any contract can be easily instantiated using this meta-model. The ER EC model also fills the gap between the conceptual model and workflow systems. This is a significant aspect of this research, which presents a pragmatic approach to conceptualize e-contracts and facilitate their deployment. Chapter 4 presents an ER EC framework in order to facilitate an integrated approach for e-contract enactment. This framework addresses the mechanism for modeling, enactment and monitoring e- contracts effectively. This research has also proposed a methodology for process design model, which handles both contract model requirements and contract process requirements. This methodology is not only aids monitoring structural and behavioral aspects of e-contract execution, but also helps in developing workflows for contract enactment. Our methodology is illustrated by means of a case study conducted using Financial Messaging Solution contract. In Chapter 5, a methodology is presented that envisions meeting the challenges of evolving conceptual model and the related logical models and run-time environment to rapid changes in mini- 135

147 world and run-time environment. The main contributions are (i) developed an active meta-modeling approach for e-contracts, (ii) presented taxonomy of operators for evolution of e-contracts, (iii) handling meta-events for e-contract enactment and (iv) presented active meta-modeling framework for enactment of changing e-contracts while managing ongoing execution of instances of e-contracts Chapter 6 addresses the commitment aspects for e-contracts, which ensure the progress of activities and their termination. We have developed a multi-level composition model for transactional support. Since e-contracts consist of multiple activities executed with several inter-dependencies, any failure could have cascading effects on other executed or executing activities. In this work, we have brought out these dependencies explicitly and facilitated solutions that can be incorporated within an e-contract system. Chapter 7 deals with payment issues in e-contracts. The composition model developed in chapter 6 is used to associate cost and payments to the states of execution. This work facilitates monitoring behavioral conditions stated in an e-contract during its execution and designing of a payment monitoring system. 8.2 Applicability The primary goal of designing an e-contract system is to enact an executable e-contract. That means, having an (e-)contract document signed by the parties, the e-contract system should handle all (most of) the tasks automatically. Another aspect of e-contract system is to make free from (legal) ambiguities in order to streamline successful fulfillment of contract. As presented in the thesis, contract documents are voluminous and involve many human assisted tasks. On reviewing the literature related to e-contracts, we decided that the modeling is the key starting point to create e- contract systems, and a database system perspective does provide a complete framework to enact e- contracts. Thus, in this thesis work, we aimed at creating a database (at multiple levels from metamodel to implementation level - see figure 4.1) driven e-enactment environment for e-contracts. We now present how our framework can be applied in a realistic situation and what specific issues need to be handled, if required, at various levels of our framework ER EC meta-model The ER EC meta-model presented in this thesis is expressive, flexible, extensible and reusable to support business contracts. This conceptual modeling of e-contracts helps in capturing application semantics and ease of understanding. 4W conceptual framework [AG2003] defines contract metamodel with four concepts namely Who, Where, What and how. Similar to 4W conceptual framework, the COSMOS contract model [GBWLM1998] describe four basic groups of concepts namely Who, What, How, and Legal. These models intends to achieve a complete and contextindependent contract models, but these lacks in representing relationships among parties and their activities with respect to their associated clauses and payments. This may be due to their focus more 136

148 on legal aspects and information exchange between the parties. The CrossFlow project [KGV2000, GAHL2000] presents a meta-model for contract establishment, which allows template creation using pre-existent contracts. Chiu et al [CCT2003] described templates as entities in e-contract meta-models and may contain parameters whose values are specified during contract establishment. However, all these works still require further work to model business processes involved in e-contracts, especially to model contract entities such as sub-contracts and payments. Moreover, these models have not been built to suit the requirements at execution level such as event processing and exception handling. This may be due to their coverage to contract negotiation and preparation stages. Our ER EC model develops a novel framework for conceptually modeling e-contracts. The ER EC model also enables describing additional semantics (for instance, identifying a clause or set of clauses when there is deviation from expected behaviour), which are useful in specification of workflows. CrossFlow project [GAHL2000] introduces dynamic contracting and configuration for service enactment. Along the same lines, we have shown in this thesis how conceptually modeled e-contracts are mapped to workflows ER EC Framework and Architecture Our ER EC framework and methodology addresses the mechanism for modeling, enactment and monitoring e-contracts. It also facilitates Web Service based implementation model for an e-contact. Business Contracts Architecture (BCA) presented in [MB1995] support automation of contract management. Key elements in BCA are contract repository, notary, contract monitor, and contract enforcer. BCA does not facilitate tracking of events raised during contract realization and also not suitable for dynamically changing business environments. The Multi-Tier Contract Ontology (MTCO) framework described in [K2003] captures and models the relevant contract knowledge and information for generic business contracts. Their emphasis is on providing meaningful interpretation between business, technical and legal vocabularies and analyzing the obligations to achieve contract fulfillment. This framework mainly focuses on information reuse, but provides less detailed representation of functionalities required for an e-contract enactment system. The main reason for this is their focus on information reuse rather than providing comprehensive knowledge about e- contracting process for enactment of e-contracts. A three layer (Business Layer, Structure Layer and Implementation Layer) framework presented in [CCT2003] aims at development of e-services as an application built on top of workflow systems. They have also proposed an architecture for e-contract enforcement in an e-service environment based on deontic logic and Web Services. But still, sophisticated distributed event mechanisms and transaction aspects have not been addressed. Our ER EC approach presented in this thesis helps in linking conceptual model and the contract process flow for e-contract enactment. 137

149 8.2.3 ER *EC support for evolving e-contracts The ER *EC methodology supports any changes of structures, processes and interactions through active conceptual modeling for evolving e-contracts. This approach upkeep the e-contract application running with new and old applications at the same time as per the revised scenarios. Moreover, modeling of active behaviour allows handling of important and relevant aspects of evolving e- contracts including the activities and changes under different perspectives based on our knowledge and understanding. Though there are some works on workflow evolution [CCPP 1996], to the best of our knowledge, our approach is first of its kind in describing evolving e-contracts Activity Commitments and Payments The composition model and transactional properties described in this thesis allows specification and execution aspects of activities as well as payments. Recent studies focus more on developing transactional models to support web services (for example, [BPG2005]), but there is less or no emphasis given on transactional aspects for activity commitments in e-contracts. The commitment model proposed by Xu et al [XJ 2003] supports e-contract monitoring. Their commitments are related to the commitment by the parties to carry out certain tasks agreed as part of the contract. So, these commitments are useful to act as a guard while enforcing the contract and monitoring the violations, if any, but their work does not track the progression of activity execution. This is because of their focus on pro-active monitoring e-contract execution rather than handling success/failure terminations. Our multi-level composition model supports keeping track of progression of activity execution by associating transactional properties to execution states of activities, and enables guaranteed termination of e-contract activities. 8.3 Future work There are some limitations to our work to present a holistic view of e-contract enactment system. The meta modeling can be strengthened by explicit representation of responsibilities when a subcontract entered into a contract, for instance, representing their payments, and also their relationships with respect to other contracts. Once a contract is modeled it needs to be represented using some logic formalisms. Though there are several logics available in the literature, they provide limited support for obligations, penalties and permissions. It may be needed to have a combination of these logics to support a variety of contract activities and clauses, and their intricacies. This also necessitates interoperability among such logics or development of a unified logic. In the present work, we arrived at specification of workflow for deployment by humans. However, we have not provided a tight integration between the specification models and execution components. It may be needed to understand the interactions between these components in detail. Further, in building activity commitments, we envisage that several activities will execute in parallel. However, in e-contract execution, it is not enough to foresee the dependencies, but it is also required to see the intermediate results. That means, there is a need of viewing intermediate results of other activities while executing, thereby providing sphere of visibility of an activity execution. For example, in a 138

150 house-building contract, the activities related to plumbing, electricity and construction of a wall should view the progress of one activity with respect to other two. Further, in our work, all parties are treated equally and ensure that the obligations agreed in a contract are met. We have not discriminated the activities and/or interpretation of clauses from a specific party point of view. This kind of discrimination may help in identifying suitable contract arrangement for a particular organization with other organizations. Anushree et al [ARK 2007] developed a MTDC (Methodology and Toolkit for Deploying Contracts) solution for contract visualization and enactment based on ER EC model. This toolkit uses natural language processing software and human intervention to specify system specific workflows. The e-contract engine has a Pattern Recognition System, Sentence Classifier, ER EC Model Component, Workflow Specification Component, and Xflow Workflow Enactment Component. A dictionary is prepared by extracting common contract-keywords from multiple related contract documents for a specific domain. The pattern recognition system and the sentence classifier along with human interaction are used to extract the activities and clauses based on the contract-keywords and identify interdependencies to generate ER EC model. The ER EC model component takes these specifications as inputs and generates ER EC model for a specific contract. This model is mapped to workflow specifications by Xflow specification component, which in turn generates the workflow instances for execution of e-contracts by Xflow workflow enactment component. In another work, the ER EC model has been enhanced by introducing star entity type (E*) and star relationship type (R*) constructs in order to capture the semantics of e-contract applications. Star entity type enables set of one or more entity types in the relationship and star relationship type relax relationship type to allow flexible interrelationships. We envision the following ways in which the ideas developed in this thesis can be extended. Establishing linkage between conceptual models and the process flows can be automated so that the models can serve as executable conceptual models. Further, business policies and pre- and postconditions can be added in the conceptual models in order to incorporate business vocabulary into the model. Organizations enter into multiple contracts with various partners to improve their business. So, enabling e-contract systems to find the profitable e-contracts and facilitating risk mitigation during e-contract execution will become another dimension to the e-contracts. Discovering e-contract workflow patterns for re-use across various contracts in similar industries facilitates preparing future contracts and deploys them quickly Other pertinent approaches for e-contracts As seen above, our perspective is to facilitate database supported e-contracts. However, a fullfledged e-contract system should look into other dimensions such as (i) logic programming, (ii) reasoning and rule interpretation, (iii) support of natural language, (vi) exploiting technologies such as vocabulary and stronger syntax such as OWL, (v) Artificial Intelligence and machine intelligence, (vi) Software engineering and (vii) Legal. The work presented in this thesis helps in understanding an e-contract e-enactment system from database perspective and open up many possible avenues for further research in the field of e-contracts. 139

151 References [A1998] W. M. P. van der Alast, The application of Petri Nets to Workflow Management, Journal of Circuits, Systems and Computers, 8(1), pp , [A2006] S. Angelov, Foundations of B2B electronic contracting, Ph.D Thesis, Technische Universiteit Eindhoven, Eindhoven, [A2009] K. Anushree, On extracting, enacting and modeling e-contracts, M.S. by Research Thesis, IIIT-Hyderabad, August [AAAKGM 1996] Alonso, G., Agrawal, D., Abbadi, A.E., Kamath, M., Gunthor, R., and Mohan, C., Advanced transaction models in workflow contexts, In Proc. of the 12th International conference on Data Engineering (ICDE '96), pp ,1996. [AB2002] A. Abrahams and J. Bacon, A software implementation of Kimbrough s disquotation theory for representing and enforcing electronic commerce contracts, Group Decision and Negotiations, 11, pp , [AEB2002] A. Abrahams, D. Eyers and J. Bacon, An asynchronous rule-based approach for business Process Automation using Obligations, in: Proceedings of the 3rd ACM SIGPLAN Workshop on Rule Based programming (RULE 02) pp , [AG2003] S. Angelov and P. Grefen, The 4W Framework for B2B E-contracting, International Journal of Networking and Virtual Organizations, 2(1), pp.78 97, [AH2000] W. M. P. van der Aalst and A. H. M. ter Hofstede. Verification of workflow task structures: A Petri-net-based approach. Information Systems, 25(1), pp , [AKV2003] W. M. P. van der Aalst, A. Kumar, H. M. W. (Erik) Verbeek: Organizational Modeling in UML and XML in the Context of Workflow Systems. In Proc. of 18th Annual ACM Symposium on Applied Computing (SAC 2003), pp , [AM2000] A. Agostini and G. De Michelis, Improving flexibility of workflow management systems, in: Business Process Management: Models, Techniques and Empirical Studies, Spring-Verlag LNCS 1806, pp , [ARK 2007] K. Anushree, P. Radha Krishna and K. Karlapalem, A Methodology and Toolkit for Deploying Contract Documents as E-contracts, 26th International Conference on Conceptual Modeling (ER 2007), CRPIT 83, 91-96, [ATG2005] S. Angelov, S. Till and P. Grefen, Dynamic and Secure B2B E-contract Update Management, Proc. ACM Conference on Electronic Commerce, Canada, pp , [BCN1992] C. Batini, S. Ceri, S.B. Navathe, Conceptual Database Design An Entity- Relationship Approach, The Benjamin/ Cummings Publishing Company Inc, Redwood City, California, [BHJ 2009] J. Biba, J. Hodik, M. Jakob, Contract observation in web services environments. In: Proceedings of International Workshop on Service-Oriented Computing: Agents, 140

152 Semantics, and Engineering (SOCASE 2009), London, UK. Springer, Heidelberg, 2009 [BLL2007] A. Bartels, S.C. Leaver, and H. Lo, Contract Life-Cycle Management Attracts New Entrants, 10 August 2007, [BPG2005] S. Bhiri, O. Perrin and C. Godart, Ensuring Required Failure Atomicity of Composite Web Services, WWW 2005, pp , [CCC 1994] L. Chien-Tsai, Panos K. Chrysanthis and Shi-Kuo Chang : Database Schema Evolution through the Specification and Maintenance of Changes on Entities and Relationships, In Proceedings of the 13th International Conference on the Entity- Relationship Approach (ER-94), LNCS 881, pp , [CCHC2005] D K. W. Chiu, S.C. Cheung, P. C. K. Hung, S. Y. Y. Chiu, A. K. K. Chung, Developing e-negotiation support with a meta-modeling approach in a web services environment, Decision Support Systems, 40, pp 51-69, [CCPP 1996] F. Casati, S. Ceri, B. Pernici and G. Pozzi : Workflow Evolution, In Proceedings of the 15th International conference on conceptual modeling (ER-96), LNCS, [CCT2003] D. K. W. Chiu, S. C. Cheung, and S. Till,: A Three-layer Architecture for E- Contract Enforcement in an E-service Environment, 36th International conference on System Sciences (HICSS36), p. 74, [CD 1996] Q. Chen and U. Dayal, A Transactional Nested Process Management System. Proc. 12th Intl. Conf. on Data Engineering,pp , [CKAK 1994] S. Chakravarthy, V. Krishnaprasad, E. Anwar and S.-K. Kim: Composite events for active databases: Semantics, contexts and detection, In Proceedings of the 20th VLDB conference, Santiago, Chile, pp ,1994. [CKL2001] D. K. W. Chiu, K. Karlapalem, and Q. Li, Views for inter-organization workflow in an e-commerce environment, in: IFIP 2.6 Data Semantics conference on Semantics in E-Commerce, [CKLK2002] D.K.W. Chiu, K. Karlapalem, Q. Li, E. Kafeza, Workflow views based e-contracts in a cross-organization e-service environment, Distributed and Parallel Databases 12 (2 3), , [CLK 1999] D.K. W. Chiu, Q. Li, and K. Karlapalem: A meta-modeling approach for workflow management system supporting exception handling, Information Systems, 24(2), 1999, pp [CLK 2000] D. K. W. Chiu, Qing Li, and K. Karlapalem, Web Interface-Driven Cooperative Exception Handling in ADOME Workflow Management System, Proc. WISE 2000, pp , Hong Kong, [CLK2000b] D. K. W. Chiu, Q. Li and K. Karlapalem, Facilitating Exception Handling with Recovery Techniques in ADOME Workflow Management System, Journal of Applied System Studies, 1(3),

153 [CLK 2001] D. K. W. Chiu, Q. Li and K. Karlapalem, Web interface driven cooperative exception handling in ADOME workflow management system, Information Systems, 26-2, pp , [CM2001] J. Cole and Z. Mlosevic, Extending Support for Contracts in ebxml, IEEE Computer Society, pp , [CNSK2007] T. C. Chieu, T. Nguyen, M. Sridhar and T. Kwok, An Enterprise Electronic Contract Management System Based on Service-Oriented Architecture, IEEE International Conference on Services Computing (SCC 2007), [CR 1990] P. K. Chrysanthis,, and K. Ramamritham, ACTA: A Framework for Specifying and Reasoning about Transaction Structure and Behavior. Proceedings of the ACM SIGMOD International Conference on Management of Data: , [CR 1991] P. K. Chrysanthis, and K. Ramamritham, A Formalism for Extended Transaction Models, Proc. of the 17th Int. Conf. on Very Large Data Bases, , [CS 2008] P. Chakravarthy and M. Singh, Incorporating Events into Cross-organizational Business Processes, IEEE Internet Computing, 12(2), pp , [CSSW2004] M-J Carlos, S. Shrivastava, E. Solaiman and J. Warne, Run-time Monitoring and Enforcement of Electronic Contracts, Electronic Commerce Research and Applications, 3, pp , [CTW 1999] P. P. Chen, B. Thalheim and L. Y. Wong : Future Directions of Conceptual Modeling, LNCS 1565, P. P. Chen, J. Akoka, H. Kangassalo, and B. Thalheim, Eds. Berlin, Germany: Springer, [D1999] A. Daskalopulu, Logic-Based Tools for the Analysis and Representation of Legal Contracts. Ph.D thesis, Imperial College London, [D+2001] A. Dan, T. N. Nguyen, D. M. Dias, F. N. Parr, R. Kearney, M. W. Sachs, T. C. Lau and H. H. Shaikh, Business-to-Business Integration with tpaml and a Business-to- Business Protocol Framework, IBM Systems Journal, 40(1), [DDGLSZ 2003] H.M. Deitel, P.J. Deitel, J.P. Gadzik, K. Lomeli, S.E. Santry and S. Zhang. Java Web Services for Experienced Programmers, Prentice Hall, Upper Saddle River, New Jersey, [DDM2001] A. Daskalopulu, Theo Dimitrakos and T. Maibaum, E-contract fulfillment and Agents Attitudes, Proceedings of ERCIM WG E-Commerce Workshop on the role of trust in e-business, Zurich, October, [DDM2002] A. Daskalopulu, T. Dimitrakos, and T.S.E. Maibaum, Evidence-Based Electronic Contract Performance Monitoring, The Informs J. of Group Decision and Negotiation, 11(6), pp , [DJC1995] Department of Justice Canada. A survey of legal issues relating to the security of electronic information, Technical Report, Department of Justice, [DM 2001] A. Daskalopulu and T. Maibaum, Towards Electronic Contract Performance, 12th DEXA International Workshop on Database and Expert Systems Applications, IEEE CS-Press, pp ,

154 [DS1997] A. Daskalopulu and M. J. Sergot, The Representation of Legal Contracts, AI & Society, 11(1/2), pp. 6-17, [DML 1991] U.Dayal, Meichun Hsu, R. Ladin, A Transactional Model for Long-Running Activities. VLDB 1991: , [DNS 2008] N. Desai, N. C. Narendra and M. P. Singh, Checking Correctness of Business Contracts via Commitments, Proc. of 7th International Conference on Autonomous Agents and Multiagent Systems (AA-MAS 2008), Estoril, Portugal, [DTM2002] A. Daskalopulu, T. Dimitrako and T. Maibaum, Evidence-based Electronic Contract Performance monitoring, INFORMS Journal of Gorup Decision and Negotiation, [DW1995] F. Dignum and H. Weigand, Modeling communication between cooperative systems, Proc. of CAiSE 95, pp , [ebxml2000] Business Process Project Team, The ebxml Business Procedss Meta-model Second draft 6/23/00, [F+ 2004] A. D. H. Farrell, Marek J. Sergot, C. Bartolini, M. Salle, D. Trastour, and A. Christodoulou, Performance Monitoring of Service-Level Agreements for Utility Computing using the Event Calculus, Proc. First IEEE International Workshop on Electronic Contracting, IEEE CS Press, pp 17-24, [FGT2006] M. Fantinato, I. M. de S. Gimenes and M. B. F. de Toledo, Web Service E-contract Establishment Using Features, Business Process Management (BPM 2006), Springer, LNCS 4102, pp , [FTG2006] M. Fantinato, M. B. F. de Toledo, I. M. de S. Gimenes, A Feature-based Approach to Electronic Contracts, Proceedings of the 8th International Conference on E- Commerce Technology and the 3rd International Conference on Enterprise Computing, E-Commerce, and E-Services (CEC/EEE 06), [G1999] B. N. Grosof, A declarative approach to business rules in contracts: courteous logic programs in XML, in: Proceedings of the 1st ACM Conference on Electronic Commerce (EC99), Colorado, USA, [GAHL2000] P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig, CrossFlow: Cross- Organizational workflow management in Dynamic virtual enterprises, International Journal of Computer Systems Science and Engineering, 15(5), pp , CrossFlow Web site. [GBWLM1998] F. Griffel, M. Boger, H. Weinreich, W. Lamersdorf, M. Merz, Electronic Contracting with COSMOS How to Establish, Negotiate and Execute Electronic Contracts on the Internet, Proc. of 2nd Int l Workshop on Enterprise Distributed Object Computing (EDOC 98), Cambridge University Press, pp.46-55, [GHS 1995] D. Georgakopoulos, M. F. Hornick, A. P. Sheth: An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases 3(2): pp ,

155 [GM2006] G. Governatori and Z. Milosevic, A Formal Analysis of a Business Contract Language, International Journal of Cooperative Information Systems, 15(4), pp , [GP2003] B. Grosof and T. Poon, SweetDeal: Representing Agent Contracts with Exceptions using XML Rules, Ontologies and Process Descriptions, 12th WWW Conference, ACM Press, pp , [GV2006] P. Grefen and J. Vonk, A Taxonomy of Transactional Workflow Support, International Journal of Cooperative Information Systems, 15, 1, , [GVA 2001] P. Grefen,, J. Vonk, and P. Apers,, Global transaction support for workflow management systems: from formal specification to practical implementation. The VLDB Journal 10, pp , [HC2004] P.C.K. Hung and Dickson K.W. Chiu. Developing Workflow-based Information Integration (WII) with Exception Support in a Web Services Environment. In: Proc of 37th Hawaii International Conference on System Sciences (HICSS37), IEEE Press CDROM, [HM2001] C. Herring and Z. Milosevic, Implementing B2B Contracts using BizTalk, Proc. of 34th Hawaii International Conference on System Sciences (HICSS-34), Hawaii, Honolulu, pp , [HYK1996] P. C. K. Hung, H. Pl. Yeung and K. Karlapalem, CapBasED-AMS: A capabilitybased and event-driven activity management system, in: Proceedings of the ACM SIGMOD Conference on Management of Data, Montreal, Canada, [IJK2004] M. Iwahihara, H. Jiang and Y. Kambayashi, An Integrated Model of workflows, e- Contracts and Solution Implementation, ACM Symposium on Applied Computing, pp , [IST2009] CONTRACT deliverable D4.1, Web Services framework for contract based computing, IST CONTRACT PROJECT, [JAS1999] A.K. Jain, IV M Aparicio. and M. P. Singh, Agents for Process Coherence in Virtual Enterprises, Communications of the ACM, 42(3), pp , [KDR2001] K. Karlapalem, A. R. Dani and P. Radha Krishna, A Framework for Modeling Electronic Contracts, 20th International Conference on Conceptual Modeling (ER2001), LNCS vol (Springer-Verlag) pp , [KG2005] A. Kumar and J. Wainer, Meta Workflows as a Control and Coordination Mechanism for Exception Handling in Workflow Systems, Decision Support Systems, 40, pp , [KGV2000] M. Koetsier, P. Grefen, J. Vonk, Contracts for Cross-Organizational Workflow Management, Proceedings 1st International Conference on Electronic Commerce and Web Technologies, London, UK, pp , [KN2006] T. Kwok and T. Nguyen, An Enterprise Electronic Contract Management System using Dual XML and Secure PDF documents, 10th IEEE International Enterprise 144

156 Distributed Object Computing Conference Workshops, IEEE Computer Society, p. 57, [KS 1998] G. E. Kersten and S. Szpakowicz : Modeling business negotiations for electronic commerce, In Proceedings of the 7th workshop on Intelligent Information Systems, IPI PAN, Warsaw, 1998, pp [KZ2002] A. Kumar and J. L. Zhao, Workflow support for electronic Commerce applications, Decision Support Systems, 32, , [L1998] R. M. Lee, A Logic Model for Electronic Contracting, Decision Support Systems, 4(1), pp , [L1998b] R. Lee, Towards Open Electronic Contracting, EM Electronic Markets, 8(3), pp.3-8, [L2001] F. Leymann, Web Services Flow Language (WSFL 1.0), IBM Corporation, [L2005] P. F. Linington, Automating support for e-business contracts, International Journal of Cooperative Information Systems, 14 (2&3), pp.77-98, [LO2005] Lopes H Cardoso, and E. Oliveira, Assisting and Regulating Virtual Enterprise Interoperability through Contracts, Agent-based Technologies and applications for enterprise interoperability(atop), pp.1-12, 2005 [LS1997] Y. Lei and M. P. Singh, A comparison of workflow metamodels, Proceedings of the ER'97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, UCLA, Los Angeles, California, [MB1995] Z. Milosevic and A. Bond, Electronic Commerce on the Internet: What is still Missing?, Proc. of 5 th conference of the Internet Society, pp , Honolulu, [MJPD2002] Z. Milosevic, A. Jøsang, M.A. Patton, T. Dimitrakos: Discretionary enforcement of Electronic Contracts, Proc. 6th Int l Enterprise Distributed Object Computing Conf. (EDOC 02), IEEE CS Press, pp , 2002 [MM2001] O. Marjanovic and Z. Milosevic, Towards formal modeling of e-contracts, in: Proceedings of the 5th IEEE International Enterprise Distributed Object Computing Conference, Seattle, Washington, pp , [M1983] M. Morgenstein : Active databases as a paradigm for enhanced computing environments, In Proceedings of the International Conference on Very Large Databases, [MS2005] A. U. Mallya and M. P. Singh, Modeling exceptions via commitment protocols, In Autonomous Agents and Multi-Agent Systems, ACM Press, pp , [MSO2006] Z. Milosevic, S. Sadiq and M. Orlowska, Translating Business Contract Constraints into Compliant Business Processes, 10th IEEE Conference on Enterprise Distributed Object Computing, IEEE CS Press, pp , [MSSW2003] C. Molina-Jimenez, S. Shrivastava, E. Solaiman, and J. Warne. Contract Representation for Run-time Monitoring and Enforcement. In Proc. IEEE Int. Conf. on E-Commerce (CEC), Newport Beach, USA, pp ,

157 [PDK2005] A. Paschke, J. Dietrich and K. Kuhla, A logic based SLA Management Framework, In 4th Semantic Web Conference (ISWC 2005), [PS 2007] C. Prisacariu and G. Schneider, A Formal Language for Electronic Contracts, In Proc. 9th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS 07), LNCS Vol 4468, pp , [R1996] R. Raman, Cyber Assisted Business EDI as the Backbone of Electronic Commerce EDI-TIE B.V. [RD1998] M. Reichert and P. Dadam, ADEPTflex: Supporting dynamic changes of workflow without losing control, Journal of Intelligent Information Systems 10 (2) (1998) [P 2003] M. P. Papazoglou, Web Services and Business Transactions, World Wide Web: Internet and Web Information Systems, 6, pp , [PV 1995] H. Proper and T. P. Van der Weide : A General Theory for Evolving Application Models, IEEE Transactions on Knowledge and Data Engineering, Dec [RK 2007a] P. Radha Krishna and K. Karlapalem, Actively Evolving Conceptual Models for Mini-world and Run-time Environment, Proc. of the ER 06 Workshop on Active Conceptual Modeling of Learning (ACM-L 2006), LNCS 4512, pp , [RK2007b] P. Radha Krishna and K. Karlapalem, Active Meta Modeling Support for Evolving E-contracts, 26th International Conference on Conceptual Modeling (ER 2007), Auckland, New Zealand, Australian Computer Society, CRPIT 83, , [RK 2008] P. Radha Krishna and K. Karlapalem, Electronic Contracts, IEEE Internet Computing, vol. 12, No. 4, pp , [RKC 2004] P. Radha Krishna, K. Karlapalem and D. K. W. Chiu, An EREC Framework for E- Contract Modeling, Enactment and Monitoring, Data and Knowledge Engineering, 51, 1, 31-58, [RKD 2005] P. Radha Krishna, K. Karlapalem and A. R. Dani, From Contracts to E-Contracts: Modeling and Enactment, Information Technology and Management Journal, 4, 1, , [RPG2005] M. Rouached, O. Perrin, and C. Godart, A contract-based approach for monitoring collaborative web services using commitments in the event calculus. 6th International Conference on Web Information Engineering System (WISE05), pp , [S1980] R. G. Smith, The contract net protocol: High Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computers 29 (12), pp , [S1998] M. T. Schmidt, Building workflow business objects, object-oriented programming systems languages applications, OOP-SLA 98 Business Object Workshop, London, pp , [S1999] A. W. Scheer, ARIS-Business Process Modeling, Springer, Berlin,

158 [S2002] [Sc2002] M. Sallé, Electronic Contract Framework for Contractual Agents, In: Proc. of 15th Conference of the Canadian Society for Computational Studies of Intelligence, AI 2002, Canada, LNCS vol. 2338, Springer-Verlag, pp , M. Schoop, Electronic markets for architects the architecture of electronic markets, Information Systems Frontiers 4(3), pp , [SABS2002] H. Schuldt, G. Alonso, C. Beeri, H.J. Schek, Atomicity and Isolation for Transactional Processes, ACM Transactions on Database Systems, 27, pp , [T2001] S. Thatte, XLANG - Web Services for Business Process Design, Microsoft Corporation, [TMKG2004] R. Tagg, Z. Milosevic, S. Kulkarni and S. Gibson, Supporting Contract Execution through Recommended Workflows, 15th International Conference of DEXA 2004, LNCS-3180, pp.1-12, [TNCK1991] A. K. Tanaka, S. B. Navathe, S. Chakravarthy and K. Karlapalem, ER-R: An enhanced ER model with situation-action rules to capture application semantics, Proc. of Int. Conf. on Conceptual modeling ( ER 91), pp , [V1999] D. Verma, Supporting Service Level Agreements on IP Networks, Macmillan Technical Publishing, [V2003] K. Vandana, Using Multi-tier Contract Ontology to Model Contract Workflow Models, Dissertation, Stockholm University and the Royal Institute of Technology, Stockholm, SWEDEN, [V 1991] K. Vidyasankar, Atomicity of Global Transactions in Distributed Heterogeneous Database Systems, Proc. of the DEXA-91, pp , [VRK 2007] K. Vidyasankar, P. Radha Krishna, and K. Karlapalem, A Multi-Level Model for Activity Commitments in E-contracts, 15th International Conference on Cooperative. Information Systems (CoopIS 2007), Portugal, LNCS 4803, Springer, , [VRK 2008] K. Vidyasankar, P. Radha Krishna and K. Karlapalem, Study of Execution Centric Payment Issues in E-contracts, 2008 IEEE International Conference on Services Computing (SCC 2008) July 8-11, 2008, Honolulu, Hawaii, USA, IEEE Computer Society, Vol 2, pp , [VRK 2009] K. Vidyasankar, P. Radha Krishna and K. Karlapalem, Study of Dependencies in Executions of E-contract Activities, 13th East European Conference on Advances in Databases and Information Systems (ADBIS), LNCS 5739, pp , [VV 2004] K. Vidyasankar, and G. Vossen, A Multi-Level Model for Web Service Composition, In: Proc. of the 3rd IEEE International Conference on Web Services, San Diego, U.S.A., pp ,

159 [VV 2007] K. Vidyasankar, and G. Vossen, Multi-Level Modeling of Web Service Compositions with Transactional Properties, Technical Report, Memorial University, St. John s, Canada, [VKF2002] S. Varadarajan, K. Kasravi, R. Feldman, Text-Mining: Application Development Challenges, Proc. 22nd International conference on Knowledge Based Systems and applied Artificial Intelligence (ES02), Springer Verlag, 2002 [W3C] World Wide Web Consortium (W3C): [WFMC2000] Workflow Management Coalition. Workflow Standard Interoperability Wf-XML Binding, WFMC-TC-1023, [WGV2006] T. Wang, P. Grefen and J. Vonk, Abstract Transaction Construct: Building a Transaction Framework for Contract-driven, Service-oriented Business Processes, In: Proc. of the ICSOC- 2006, LNCS 4294, Springer, pp , [WH 2002] H.Weignad andw-j.v.d. Heuvel, Cross-organizationalworkflowintegration using contracts, Decision Support Systems, 33, pp , [WSCI2002] Sun Microsystems, Web Service Choreography Interface (WSCI), Version 1.0, [WSMD2003] H. Weigand, M. Schoop, A. D. Moor and F. Dignum, B2B Negotiation Support: the Need for a Communication Perspective, Group Decision and Negotiation, 12 (1). 3-29, [WS-C2002] IBM Corporation, Web Services Coordination (WS-Coordination), August [WS-T2002] IBM Corporation, Web Services Transaction (WS-Transaction), August [WX2001] H. Weigand, and L. Xu, Contracts in e-commerce. In 9th IFIP 2.6 Working Conference on Database Semantic Issues in E-Commerce Systems (DS-9), [X2004] L. Xu, Monitoring Multi-Party Contracts for E-Business, Ph.D. thesis, Tilburg University, 2004 [X2004b] L. Xu, L. A Multi-party Contract Model, In: ACM SIGecom Exchanges Vol. 5, No.1, pp , (2004b). [XJ2003] L. Xu, Manfred A. Jeusfeld, Pro-active monitoring of electronic contracts, in: Proceedings of Advanced Information Systems Engineering 15th International Conference, CAiSE 2003, LNCS, vol. 2681, Springer-Verlag, pp ,

160 Appendix - A Case Study House-Building Contract In this appendix, we revisit House-Building contract. The parties of this contract include a customer (borrower), a builder, a supplier, a bank and an insurance company. House-Building contract is a composite contract, that is, it involves a number of bi-lateral contracts. The contracts are between: 1. Builder and Customer The builder will construct the house according to the specifications of the customer. Some of the activities such as carpentry, plumbing and electrical work may be subcontracted. 2. Builder (Buyer) and Supplier - The contract includes the clauses related to materials supply, quality, quantity, and payment. There may be time schedules for suppliers to adhere to. 3. Customer (Borrower) and Bank The contract enables housing loan an individual or corporate customer to have an account with the bank. It facilitates fund transfer as well as loans to bank customers. The customer will get a loan for the construction from the bank. He will apply for a mortgage, and work out details of payment to the builder, directly by the bank, after inspection of the work at multiple intervals. 4. Inter-bank It enables inter-bank transactions for payments 5. Insurance Company and Customer (Borrower) The house shall be insured comprehensively for the market value covering fire, flood, etc. in the joint names of the bank and the customer. The activities of the parties include the following: - Customer: (C-i) monitor the work carried out by the builder, (C-ii) submit the loan application, (Ciii) set up coordination between bank and builder, (C-iv) receive payments, and (C-v) arrange monthly repayments. - Bank: (B-i) scrutinize the loan application, (B-ii) assess the loan limit and take legal opinion, (B-iii) undertake the mortgage, (B-iv) sanction the loan, (B-v) release the payment, (B-vi) receive the monthly re-payments, (B-vii) fund transfer, and (B-viii) conduct inspection of the work progress. - Builder: (U-i) schedule different works involved in the construction and procure raw material, (Uii) build the house as per the agreement, (U-iii) give part of the work to sub-contracts, if any, (U-iv) receive the payments, (U-v) do payments to its staff and sub-contract parties, if any, and (U-vi) handover the constructed house to the customer. - Insurance company: (I-i) receive the application form, (I-ii) scrutinize the form, (I-iii) estimate the premium, (I-iv) approve a policy, (I-v) receive payments, (I-vi) assess damage(s) in case of a claim and (I-vii) resolve the claims, if any. - Supplier: (S-i) accept the order, (S-ii) arrange the required goods, and (S-iii) ship the goods. Examples of clauses that relate to procurement and bank loan, in verbatim, is shown in figure A.1 and A.2 respectively. 149

161 Terms of Payment: 100% payment will be made against delivery by cheque after inspection and acceptance of the material at our place. When the material is ready for dispatch, before supplying the material, please arrange to send three copies of Performa invoice indicating D.C. No. & Date in order to keep the demand draft ready.[clause CL-a].. Liquidated Damages: A. Failure to supply the goods by the time specified on the order will make the supplier liable to an unconditional liquidated damage of ½% (half percent) per week subject to a maximum of 10% (Ten Percent) of the price of the goods in arrears at the discretion of the STC.[ Clause CL-b] B. The purchaser shall have the right to cancel either wholly or in part the portion of the contract which is yet to be executed by supplier in case the delivery is not in accordance with the time specified in the order. [Clause CL-c]. Jurisdiction: All questions, disputes of differences arising under, out of or in connection with the contract shall be subject to the exclusive jurisdiction of the court within the local limits of whose jurisdiction the place from which the purchase order is issued, is situated. [Clause CL-d]. Quality: All goods and works must conform to the specifications quoted on the order and are to be strictly in accordance with approved samples of designs. Goods supplied are subject to inspection by our authorized representatives and the inspector has right to reject the goods of conforming to our specifications. [Clause CL-e]... Inspection: All goods and works are subject to our inspection. Inspection, either at your works or delivery as agreed will be carried out. The decision of our officer nominated/authorized by the GM, Materials is final. Rejected goods will be returned to the suppliers at his cost including freight on original shipment. [Clause CL-f] Figure A.1 Text segments of clauses related to procurement of goods Installments: The first installment shall be paid to the bank from the month following the month in which the construction of the building is completed or occupied or on the expiry of a period not exceeding twenty four months after the date of disbursement of the first installment of the loan, whichever is earlier..[clause CL-g].. Depreciation value of House : If, at any stage, there is any depreciation in the value of the house constructed, the bank shall be entitled to demand from the borrower further security to make up the deficiency within a period to be fixed by the bank. If, on such demand being made by the bank to the borrower, the borrower fails to comply with the demand, the outstanding amount of his loan (with interest) will become immediately payable in full and the bank may proceed to recover the same in any manner open to it. [Clause CL-h]. Inspection: If the bank is of the opinion that the progress of work of construction of the said house is unsatisfactory, the bank shall be at liberty to decline to make payment of any undisbursed installment of the said loan or at its discretion postpone the payment thereof until such time the bank is satisfied that the cause or causes for its dissatisfaction with the progress and quality of work has or have been removed and the bank shall incur no responsibility or liability to the borrower either in damage or otherwise for declining to make payment or postponement of payment of any undisbursed installment as aforesaid. [Clause CL-i] Figure A.2 Text segments of clauses related to bank loan Figure A.3 presents the ER EC model for House-Building contract. Figures A.4 and A.5 presents workflows for activities related to Bank and Supplier respectively. The resultant model is used to monitor the activities, and whenever a violation of a particular clause/condition the corresponding exception(s) should take place. Consider the clauses [CL-a], [CL-b], [CL-e] and [CL-f] in Figure A.1. All these clauses are linked with the activity Shipment of finished goods. Some of these clauses are to be checked in sequence and some simultaneously. Suppose the event Goods received occurs, the following conditions are to be evaluated: (i) IF Not received in time THEN Apply liquidated damages Raise Time limit crossed Exception 150

162 (ii) IF design is according to the specifications THEN Accept material ELSE Reject Return the goods Deduct the payment for rejected goods as per the rules applicable. (iii) IF material accepted THEN If received Performa invoice THEN make payment. Else Keep payment pending. I-i I-iv I-vi I-ii I-v I-Vii I-iii House- Building have Builder- Customer Insurance Company- Customer Bank - Customer S-i S-ii S-iii Builder -Supplier Inter-Bank U-i U-ii U-iii U-iv U-v U-vi has CL-a CL-b CL-c CL-d C-i C-ii C-iii Parties have CL-e CL-f C-iv C-v B-i B-ii B-iii B-iv B-i B-vi B-vii B-viii Builder Customer Bank Payments Supplier Insurance Company CL-g refer CL-h Design not upto the mark Reject No Stock Time Limit Crossed No Sufficient Balance Wait Send Clarification Incomplete work Hold payment Revisit Again Exceptions Relations between entity types Relations between instances of different entities Contract Events Output events for exceptions Input events for exceptions Figure A.3 ER EC model for e-contract House-Building 151

163 The translation of contract clauses into ECA rules is not straightforward. It requires substantial business process re-engineering and automated tools. Moreover, it requires inputs of human experts. For some semi-structured contracts (ex., specified in ebxml), it may be feasible to automate some aspects of translating clauses to ECA rules. Table A.1. presents APC specifications for few activities and clauses. Figure A.6 presents activity commit diagram for fund transfer activity. Here, the money is transferred from party 1 to party 2, where party 1 has an account in bank A and party 2 has an account in bank B. In the activity commit diagram, the solid arrows represent the next transaction to be performed and the dashed arrows represent rollback point where transaction(s) have to be rolled back in case that transaction is not committed. Consider the transactions shown in the activity commit diagram for fund transfer activity. The messages are logged for each atomic activity. In case of insufficient balance in the account of party 1, the activity transaction Bank A debits Party 1 account will be aborted and the corresponding message is logged (Logging an atomic transaction is shown with the letter L in the diagram). This transaction is rolled back to the previous activity. Once an atomic activity is committed, the letter L will be replaced by C to indicate that the corresponding atomic transaction is committed. After successful execution of an activity, the corresponding workflow entity will be notified as committed. Start Scrutinize the loan application Assess the loan limit Undertake the mortgage Sanction the loan End Start Check the work progress Release the payment Fund Transfer End Not Satisfactory Start Receive monthly payment End Figure A.4 Workflows for Bank Activities Start Order Acceptance Arrange the goods Ship the goods End No stock Time limit crossed Figure A.5 Workflow for Supplier activities 152

164 Party Activity <Party> <Party Number> P1 </Party Number> <Party Name> Customer </Party Name> </Party> <Party> <Party Number> P2 </Party Number> <Party Name>Bank </Party Name> </Party> <Party> <Party Number> P3 </Party Number> <Party Name>Builder </Party Name> </Party> <Party> <Party Number> P4 </Party Number> <Party Name>Insurance Company </Party Name> </Party> <Party> <Party Number> P5 </Party Number> <Party Name>Supplier </Party Name> </Party> <Activity> <Activity Number> C-i </Activity Number> <Description> monitor the work carried out by the builder </Description> <Start Date> </Start Date> <End Date> </End Date> <Parties Responsible> P1</Parties Responsible> <Parties Responsible> P3</Parties Responsible> <Clauses> CL-e </Clauses>.. <Exceptions> Not upto the mark </Exceptions>. </Activity> <Activity> <Activity Number> C-v </Activity Number> <Description> arrange monthly repayments </Description> <Start Date> </Start Date> <Recurring Time> 30 days </Recurring Time> <End Date> </End Date> <Next Activity> U-iv </Next Activity> <Parties Responsible> P2</Parties Responsible> <Parties Responsible> P3</Parties Responsible>.. <Clauses> CL-i </Clauses>.. <Exceptions> Invalid Account Details </Exceptions> <Exceptions> Not transferred due to connectivity </Exceptions>. </Activity> Clauses <Clause > <Clause Number> CL-a </Clause Number> <Description> Terms of Payment: 100% payment will be made against delivery by cheque after inspection and acceptance of the material at our place. When the material is ready for dispatch, before supplying the material, please arrange to send three copies of Performa invoice indicating D.C. No. & Date in order to keep the demand draft ready </Description> <Activity Number>U-i</Activity Number> <Activity Number>U-iii</Activity Number> <Party Number>P3</Party Number> <Party Number>P5</Party Number> </Clause>. <Clause > <Clause Number> CL-g </Clause Number> <Description> Installments: The first installment shall be paid to the bank from the month following the month in which the construction of the building is completed or occupied or on the expiry of a period not exceeding twenty four months after the date of disbursement of the first installment of the loan, whichever is earlier. </Description> <Activity Number>C-v</Activity Number> <Activity Number>V-vi</Activity Number> <Party Number>P1</Party Number> <Party Number>P2</Party Number> </Clause>.... Table A.1 APC constructs for House-Building contract 153

165 Party1 gives debit instruction to its bank A and party 2 Bank A debits Party 1 account Bank B inform to Party 2 L Bank A send to clearing centre for clearance Bank B credits to Party 2 s account L Clearing instructions will go to Bank B (party 2 s bank) We considered an example drawn from the contract for building a house that concerns with housing-loan to illustrate the adaptability of ER EC model for evolving e-contracts. Here, the agreement is between a borrower and the bank. According to the contract the monthly repayment for the loan is to be made by borrower. When a borrower is granted loan by a bank, the contract is initiated between the said parties. The contract is enacted as per a standard ER EC model where the parties are, the bank, borrower, guarantor, insurance company (figure A.7). However, at the beginning the bank and the borrower are only the active parties and the guarantor, insurance company does not have any active role to play in the contract. The following three scenarios are considered to illustrate the adaptability of ER EC models for the occurrence of meta-events defaulting, death/disablement and road expansion. Figure A.6 ACD for fund transfer activity Case 1: (Run-time change) - Borrower defaults As per the contract the borrower is supposed to repay the installment by a due date. If the borrower fails to do that then an event raised and the system produces the responsive action in the form of an alert. If the borrower fails to pay for 3 months (condition) then a meta-event defaulting occurs. (This example is a simple case of meta-event. Defaulting can also occur by other events as well, for instance paid through check, but check is not realized.) In such a scenario the bank may contact the guarantor to pay for the balance amount for the loan. The template shown in the figure A.8 depicts these changes. This meta-event triggers the following procedure: On event <defaulting> begin Activate party <guarantor> Assign party <guarantor> role <borrower> Deactivate party <borrower> End 154

166 Case 2: (Run-time change) Borrower s death/disablement Suppose that every loan is associated with insurance in the borrower-bank contract. In the event of death or any disability of the borrower, the original contract will take a different shape in the form of a new sub-contract between the bank and insurance company. This sub-contract may require a different set of parties, activities, clauses, etc. Housing-Loan Housing-Loan Activities has Clauses Activities has Clauses have Parties Have Parties Roles Roles Bank Borrower Bank Borrower Guarantor Insurance Company Guarantor Insurance Company Figure A.7 Standard template of Housing-Loan contract Figure A.8 Template with change of roles There are two possibilities of this meta-event: (i) the insurance company pays the balance amount in the case of borrower expired and the house is allotted to the nominee; (ii) the insurance company releases a compensation amount in the case of borrower has disablement. Thus, when this meta-event leads to a subcontract insurance-claim thereby instantiating a new instance of ER EC model. Figure A.9 shows the new template with a sub-contract insurance-claim. Note that there was no subcontract entity in the original template (figure A.7). This meta-event triggers the following procedure: On event <death-disable> begin Instantiate model with sub-contract < insurance-claim> copy party <insurance> of contract <housing-loan> to contract <insurance-claim> if <death> then begin add party <nominee> assign party <insurance> role <borrower> deactivate party < borrower > raise event (full payment )/* <payment> by party <insurance>) */ raise event (allotment) /* <allotment> to party <nominee>) */ end if <disablement> raise event (compensation ) /*provide compensation to borrower */ end. 155

167 Housing-Loan Linked to Insurance-Claim Activities has Clauses Activities has Clauses Parties Have Parties Bank Borrower Roles Guarantor Insurance Company Nominee Insurance Company Figure A.9 Template with addition of sub-contract Case 3: (Mini-world change) - road expansion Consider a situation wherein a house built with the loan amount has to be dismantled due to expansion of a road. In this case, the government has to compensate a prescribed amount to the borrower for the portion of the house that was damaged. Here, not only adding a party (i.e., government) takes place, but also the policies that govern different activities changes. Housing-Loan Activities has Clauses Have Parties Roles Bank Society Human Rights Guarantor Insurance Company Borrower Figure A.10 Template with additional concepts This meta-event might not have been conceived during requirement analysis. It is a change in the mini-world which may happen rarely, however this change has to be adapted and modeled appropriately. This would require human intervention for creating suitable model by augmenting new concepts and/or modifying existing model elements. In the housing-loan contract, the new concepts could be virtual entities society, human rights, besides adding a party like government, which have to be modeled appropriately in the template (figure A.10). In the figure the virtual-entity is shown as a dashed rectangle. The process is explained as follows: 156

168 On event <road-expansion> begin Activate party <government> Add virtual-entity <society, human rights > Add virtual-role to virtual-entity <society, human rights > /* estimate compensation amount for the damage */ raise event (estimate damage) /* provide compensation to house owner */ raise event (compensation ) end To illustrate the activity commitment and payments, we considered an example drawn from the contract for building a house that concerns with procurement of a set of windows for the house under construction. The order will contain a detailed list of the number of windows, the size and type of each of them and delivery date. The type description may consist of whether part of the window can be opened and, if so, how it can be opened, insulation and draft protection details, whether made up of single glass or double glass, etc. The activities are described in the following. The execution-tree is simply a directed path containing nodes for each of the activities in the given order, as shown in Figure A.11. P1. Buyer: Order Preparation Prepare an order and send it to a seller. P2. Seller: Order Acceptance Check the availability of raw materials and the feasibility of meeting the due date, and, if both are satisfactory, then accept the order. P3. Seller: Arrange Manufacturing Forward the order to a manufacturing plant. P4. Plant: Manufacturing Manufacture the goods in the order. P5. Plant: Arrange Shipping Choose a shipping agent (SA) for shipment of the goods to the buyer. P6. SA: Shipping - Pack and ship goods. P1 P2 P3 P4 P5 P6 P7 P8 Figure A.11 Procurement Example P7. Buyer: Check Goods Verify that the goods satisfy the prescribed requirements. P8. Buyer: Make Payment Pay the seller. We describe several scenarios giving rise to different transactional properties. 1) Suppose that once the seller decides to accept the order, the order cannot be cancelled by the buyer or the seller, but modifications to the order are allowed, for example, delivery date changed, quantity increased, etc. If only the modifications that do not result in the nonfulfillment and hence cancellation of the order are allowed, then when the seller accepts the order, both P1 and P2 can be weakly committed. (On the other hand, if there is a possibility of the order getting cancelled, weak commitment has to be postponed. We do not consider this case any further in the following.) 157

169 2) There may be a dependency stating that the order can be sent to the manufacturing plant only after its acceptance by the seller, that is, the execution of P3 can begin only after P2 is weakly committed. 3) The plant may find that the goods cannot be manufactured according to the specifications, that is, P4 fails. Then the buyer may be requested to modify the order. For example, if the failure is due to inability to produce the required quantity by the due date, then the modification could be extension of the due date or reduction of the quantity or both. (Similar situation arises when the buyer wants to update the order by increasing the quantity.) This will result in a re-execution of P1 followed by a reexecution of P2. Then the past execution of P4 may be successful or a re-execution may be done. Weak commitments of P1 and P2 allow for such adjustments. 4) If the buyer finds that the goods do not meet the type specifications, that is, P7 fails, then, P4 has to be re-executed. In addition, P5 and P6 have to be re-executed. (This situation may arise also when the plant realizes some defects in the goods and recalls them after they were shipped.) Here, the re-executions may consist of the buyer shipping back the already received goods to the plant and the plant shipping the new goods to the buyer. An example is: two of the windows have broken glasses and a wrong knob was sent for a third window. (The knob has to be fixed after mounting the window.) Then, replacements for the two windows have to be made (in P4), the damaged windows and the wrong knob have to be picked up and the new ones delivered, perhaps by the same shipping agent (in which case the re-execution of P5 is trivial). 5) The shipping agent is unable to pack and ship goods at the designated time, that is, P6 fails. Then either the delivery date is postponed (adjustment in the stpredicate of P1) or the plant may find another shipping agent, that is, P5 is re-executed. In the latter case, it follows that P6 will also be re-executed Suppose the seller splits the order into two parts and assigns them to two plants Plant-A and Plant-B. Then the node P3 will have two children and its ce-predicate will contain the details of the individual orders. Corresponding to P4, P5 and P6, we will have P4-A, P5-A and P6-A for Plant-A, and P4-B, P5-B and P6-B for Plant-B. This is shown in Figure A.12. We describe a few scenarios and the resulting dependencies. 1) The seller may decide that shipping should not start until all the goods in the order have been manufactured. The gives rise P4-A P5-A P6-A Figure A.12 Procurement example with two plants P4-A P5-A P6-A P1 P2 P3 P7 P8 P3 P4-B P5-B P6-B P4-B P5-B P6-B Figure A.13 Two-level composition for the Procurement example 158

170 to the dependencies: begin P5-A and P5-B only after both P4-A and P4-B s-terminate. 2) P5-A fails, that is, Plant-A is unable to find a shipping agent. Then, the shipping agent of Plant-B may be asked to ship the goods of Plant-A also. This may involve changing the st-predicate if the execution of P6-B has not been done or re-execution of P6-B otherwise. 3) The buyer is not satisfied with the goods manufactured in Plant-A, that is, P7 fails. Then, the seller might settle for the buyer returning those goods and Plant-B manufacture those goods and send to the buyer. This involves changing the ce-predicate at P3, compensation of P4-A, P5-A and P6-A, and reexecution of P4-B, P5-B and P6-B. Figure A.13 shows a closed c-tree which illustrates a two-level composition for the Procurement example. Illustration of some scenarios in the Procurement example. A. When the goods are not delivered on time (P6), the buyer can insist on canceling the order. Then, a cost is incurred in the initial delivery of the goods as well as in the return of the goods as part of canceling the order, though the effective execution of that activity is null. B. Consider another related clause: If the goods are not confirming as per the contract, the buyer may require the seller to remedy the lack of conformity by repair. Then further costs are involved in returning the goods, repairing them and sending them back to the buyer. Below we present a small example to illustrate the execution of activities and terms of payments. In the house-building contract, consider a sub-task involving construction of a wall and painting it. The activities are shown in Table A.2. The work begins with the gathering of all required materials such as bricks, cement, paint, paint brushes, etc. On Inspection-I, if some materials are missing, then they are also gathered (re-execution of activity 1). Once all the materials are gathered, a 20cms thick wall is constructed as per the building specifications. After this process, Inspection-II is done to check the strength of the wall and the quality of the job done. If slight fixing is needed, some more work is done (re-execution) and then the inspection is carried out again. If (zero or more) slight fixes do not yield satisfactory results, the wall is demolished (compensating activity) and a 30cms thick wall is built, starting from acquisition of further material. (This is a partial roll back of the execution.) Even with the new wall, slight fixing and/or complete demolishing and re-building may occur, in fact, several times. Eventually, when the wall is constructed to the satisfaction, it is painted. The re-execution and compensation details are given in the table. Re-executions carried out after weak commits are stated as retrys. Weak and strong commit points for the various activities are also given. On weak commit of activities 1 and 2, the acquired materials cannot be returned (activities cannot be compensated). When the wall is constructed according to satisfaction, activities 1 to 4 are strongly committed. Note that activities 3 and 4 are directly strongly committed, without earlier weak commit. For the paint job, weak commit occurs when it is found that another undercoat is not required, and strong commit occurs when the painting is completely satisfactory. 159

171 Activity Specification Execution Commitment Aspect Terms of Payments 1. Material acquisition Materials gathered 1a. Acquisition of additional material 2. Inspection-I Materials found missing Materials found in order Re-execute 1 (1a) and 2 Weak commit 1, 2 Payment-1 (for 1 and 2) due 3. Building 20cms thick wall Wall constructed 3a. Doing slight fixing 3b. Demolishing wall 3c. Building 30cms thick wall 4. Inspection-II Slight fixing required Wall not strong enough Re-execute 3 (3a) Compensate 3 (3b), retry 1 (1a), & 2, and reexecute 3 (3c) and 4 Payment-2 (for 3, 4, & re-executions of 1-4, if any) due 5. Painting the wall 5a. Do undercoat 5b Do overcoat Construction done in order Undercoat and one overcoat 6. Inspection-III Very bad paint job Another overcoat needed Job done in order Strong commit 1-4 Re-execute 5. (5a and 5b) and 6 Weak commit 5; Retry 5 (5b), 6. Strong commit 5,6 Do not start until Payment-1 and Payment-2 received Payment-3 due Table A.2 Some activities and payments of an example: construction and painting job of a wall Payments Activities Related Cost Incurred (as per Column 3, Table 2) Payment-1 Activity 1 and Activity 2 C1 + C2 + RE1a + RE2 Payment-2 Activity 3 and Activity 4 C3 + C4+ RE3a + CS3b + RE1a + RE2 + RE3c + C4 Re-executions of 1 to 4 if any. Payment-3 Activity 5 and Activity 6 C5 + C6 + RE5a + RE 5b + C6 + RE5b + C6 Table A.3 Costs for execution of the activities described in Table A.2 The table states the terms for three payments: when they are due and the requirement that the first two payments must be received before painting of the wall can start. The costs for the execution, including re-executions and compensations, are included in the payment descriptions. Table A.3 shows the costs while executing the activities as given in Table A.2. The cost of the first execution, compensation and re-execution are denoted as C, CS and RE respectively, followed by the activity number specified in table A.2. Note that, in a normal straightforward situation, the expected cost of the composite activity for construction and painting of the wall is C1 + C2 + C3 + C4 + C5 + C6. However, due to multiple re-executions and compensation, the total cost becomes higher than the expected cost. 160

172 Appendix - B Glossary Architecture: Architecture provides a data/process flow among these components and their interaction along with other software components required to develop a system. Contract: Contract is a legally enforceable agreement, in which two or more parties commit to certain obligations in return for certain rights. ER EC model: a conceptual model instantiated from ER EC meta-model for conceptual modeling of a specific contract under study. Framework: A framework provides a generic view of components that will do the work. Meta-ECA: Meta-ECA is an ECA (Event-Condition-Action) where the conditions and actions are pertaining to a meta-event. Meta-event: Meta-event is an event based on the constructs of a meta-model, and its instantiation could be a specific meta-event. Meta-model: A meta-model is an explicit model of the constructs needed to build specific models for e-contracts (which are the application domain of interest). The developed model must be in accordance with its meta-model. Meta-modeling: The procedure in building meta-models Meta-schema: Meta-schema is a instance of a specific model using the constructs provided by the meta-model. Methodology: Methodology provides a step-by-step procedure how the work is done Mini-world : The portion of the real world relevant to the contract is referred to as the contract mini-world, that is, it represents universe of discourse about the contract. The contents in the mini-world are well understood by the designers of the e-contract system. Model: A model is a representation of the contract data/process which can facilitate specification and implementation of framework. Template: It is an ER EC (or ER*) meta-model with constraints for a specific contract. 161