E-CONTRACT MODELING AND E-ENACTMENT

Thesis submitted in partial fulfillment of

the requirements for the degree of

DOCTOR OF PHILOSOPHY

in

COMPUTER SCIENCE

by

P. RADHA KRISHNA

200799010

CENTER FOR DATA ENGINEERING

International Institute of Information Technology

Hyderabad - 500 032, INDIA

AUGUST 2010

ii

Copyright © 2010

All Rights Reserved

iii

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

iv

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.

v

Abstract

Contracts play a major role in establishing binding relationships between various business units

and also between businesses and their customers. A contract consists of numerous activities that have

to be carried out by the involved parties and contract clauses that address specific concerns in the

business process interaction. An e-contract is a contract modeled, specified, executed and deployed

(controlled and monitored) by a software system (such as a workflow system). As contracts are

complex, their deployment is predominantly established and fulfilled with significant human

involvement. This necessitates a comprehensive framework for generic fulfillment of e-contracts. So,

the goal of e-contracting is to transform a traditional contract document into an executable e-contract.

This thesis investigates on modeling and enactment aspects to develop database supported e-

contracts. Development of e-contract system, starting from modeling to enactment, is still a novel

application area, as it affects a confluence of various database and information infrastructure

technologies, including active conceptual modeling, ECA rules, formal commitment models,

workflows, and web services. The problem is addressed as a modeling problem: Given a paper

contract, model the contract elements, map them to workflows and formalize the commitment aspects

In e-contracts, there has to be an underlying implementation technology that ensures their

execution according to the specification. In particular, during execution, the contracts have to be

consistently monitored with automated mechanisms, such as by events and rules. E-contracts need a

conceptual model in order to extract the relationships between various elements in a contract, and

detect the violation of clauses and respond appropriately. We introduce EREC

model to model e-

contracts and develop a comprehensive methodology and framework to transform the conceptual

model to a set of workflows to support e-contract enactment.

Supporting evolving models during enactment is one of the key elements in implementation and

enactment of e-contracts. Mini-world changes, as well as run-time changes, influence the e-contract

deployment. As contracts evolve, it is also necessary to have a system, which manages their evolution.

Thus, we also explored on modeling dynamic behavior of e-contracts to support evolving e-contracts.

To ensure transactional support in 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.

vi

Contents

Chapter Page

List of figures …………………………………………………………………………….. ix

List of Tables …………………………………………………………………………….. xi

1. Introduction ………………………………………………………….......................... 1

1.1. Types of Contracts ………………………………………………………………. 2

1.2. Contract Lifecycle ………………………………………………………………. 2

1.3. Contract Elements ……………………………………………………. ………… 4

1.4. Document Contracts to E-contracts ……………………………………………… 6

1.5. Research Problem ………………………………………………………………... 7

1.6. Scope and Limitations of This Thesis ……………………………………………. 9

1.7. Thesis Outline …………………………………………………………………… 11

2. Related Work ………………………………………………………………………….. 12

2.1. E-contract Modeling …………………………………………………………….. 12

2.2. E-contract Representation and Specification …………………………………… 13

2.3. E-contract Monitoring ………………………………………………………….. 16

2.4. Workflows ……………………………………………………………………… 17

2.5. Web Services …………………………………………………………………… 17

2.6. E-contract Frameworks, Architectures and Systems …………………............... 18

2.7. Commercial E-contract Management Systems …………………………………. 21

2.8. Discussion………………………………………………………………………… 21

2.9. Summary………………………………………………………………………… 22

3. E-contract Modeling: EREC

Model ……………………………………….................... 23

3.1. Introduction ……………………………………………………………............. 23

3.2. EREC

Meta-Model ……………………………………………………………… 24

3.2.1. Meta-model constructs ...……………………………………………….. 24

3.2.2. Contract events ………………………………………………………… 27

3.2.3 Exceptions …………………………………………………................. 27

3.2.4. Conceptual model for e-contract ……………………………............... 28

3.3. Modeling Example Contracts ………………………………………………… 29

3.3.1. Buyer-and-Seller contract ……………………………………………. 29

3.3.2. Investment contract ………………………………………………….. 30

3.4. Mapping EREC

constructs to Workflows ……………………………………… 33

3.4.1. Workflow meta-schema ………………………………………………. 34

3.4.2. Mapping EREC

to workflow specification …………………………….. 35

3.4.3. Dynamic workflows for e-contract enactment ……………………….. 38

3.5. FMS Contract: Case Study ……………………………………………………. 39

3.6. Comparison with Related Work ……………………………………………….. 44

vii

3.7. Summary of Contract examples ………………………………..……………… 50

3.8. Summary ……………………………………………………………………… 51

4. E-contract Framework and Methodology …………………………………………….. 53

4.1. Introduction …………………………………………………………………….. 53

4.2. EREC

Framework and Methodology …………………………………................ 54

4.3. Contract Workflow and Consistency ………………………………………….. 58

4.4. Events and ECA Rules ………………………………………………………… 61

4.5. Workflows …………………………………………………………………….. 66

4.6. Implementation Architecture ………………………………………………….. 67

4.7. Summary ………………………………………………………………………. 70

5. Modeling Evolving E-contracts ……………………………………………………… 72

5.1 Introduction …………………………………………………………………….. 72

5.2. Supporting Evolving E-contracts ……………………………………………… 73

5.3. Template Driven Modeling …………………………………………………… 75

5.4. Scenarios for E-contract Evolution …………………………………………… 76

5.5. Active Meta Modeling for E-contracts ……………………………………….. 79

5.5.1. Support for evolving e-contracts ……………………………………… 79

5.5.2. Taxonomy of operations to affect e-contracts evolution ………………. 81

5.5.3. Mechanisms to support active behaviour of e-contracts ………………. 88

5.5.4. Implementation Issues ……………………………………………….. 92

5.6. ER*EC

Methodology ………………..…………………………………………… 93

5.7. Two-way Active Behaviour for Evolving E-contracts ………………………… 95

5.8. ER*EC

Architecture for Evolving Applications ………………………............... 96

5.9. Summary ………………………………………………………………………. 98

6. E-contract Activity Commitments ……………………………………………………. 100

6.1. Introduction ……………………………………………………………………. 100

6.1.1. Activities in e-contracts ………………………………………………… 101

6.1.2. Activity commitments ………………………………………………… 103

6.2. Basic Concepts …………………………………………………………………. 105

6.3. Composition Model for Activities ……………………………………............. 109

6.3.1. Path Model ……………………………………………………………. 109

6.3.1.1. Composition ………………………………………………….. 109

6.3.1.2. Execution …………………………………………………….. 110

6.3.1.3. Transactional Properties ……………………………………… 111

6.3.1.4. Implementation Issues ……………………………………….. 112 6.3.2. Tree Model …………………………………………………………….. 116

6.3.2.1. Composition ………………………………………………….. 117

6.3.2.2. Execution …………………………………………………….. 117

6.3.2.3. Transactional Properties ……………………………………… 117

6.3.2.4. Implementation Issues ……………………………………….. 118

6.3.3. Multi-Level Model ……………………………………………………. 119

6.3.3.1. Composition ………………………………………………….. 120

viii

6.3.3.2. Execution …………………………………………………….. 120

6.3.3.3. Transactional Properties ……………………………………… 121

6.3.3.4. Multi-Level commitment and Closure ……………………… 121

6.3.3.5. Implementation Issues ……………………………………….. 122

6.4. Summary ……………………………………………………………………… 125

7. Payments ……………………………………………………………………………. 127

7.1. Introduction …………………………………………………………………… 127

7.2. Cost and Payment …………………………………………………………….. 129

7.3. Payment for Basic Activities …………………………………………………. 130

7.4. Multi-level Composition ……………………………………………………… 133

7.5. Discussion ……………………………………………………………………. 133

7.6. Summary ……………………………………………………………………… 134

8. Conclusions ………………………………………………………………………… 135

8.1. Summary of Contributions ………………………………………………….. 135

8.2. Applicability …………………………………………………………........... 136

8.2.1. EREC

meta-model …………………………………………… ............ 136

8.2.2. EREC

Framework and Architecture …………………………………. 137

8.2.3. ER*EC

support for evolving e-contracts ……………………………. 138

8.2.4. Activity Commitments and Payments ……………………………… 138

8.3. Future Work ………………………………………………………….......... 138

8.3.1. Other pertinent approaches for e-contracts …………………………. 139

References ……………………………………………………………………………... 140

Appendix – A: Case Study – House-Building Contract..…………………………....... 149 Appendix – B: Glossary ……………………………………………………………… 161

ix

List of Figures

Figure Page

1.1. Contract Lifecycle …………………………………………………………. 3

3.1. A Meta Model for E-Contract ………………………………………............. 25

3.2. EREC

diagram for buyer-seller contract …….………………………………… 29

3.3. EREC

model for “investment” E-Contract ........................................................ 33

3.4. A typical workflow meta-schema …………………………………………… 35

3.5. Mapping activities to workflow …………………………………………….. 37

3.6. Augmenting exceptions as additional activities to workflow ………………. 37

3.7. Text Segment related to Change Management of FMS contract ……… ….. 40

3.8. EREC

model for e-contract “Financial Messaging Solution” ………………. 41

3.9. Workflows for Change Management of FMS e-contract ………………….. 42

3.10. Sub workflow for activity [A-4] in Change Management of …………….. 42

FMS e-contract

3.11. (a) Parametric workflows for ‘payments’ (b) Workflow views for ………. 43

‘Receive Payments’ (c) Dynamic workflows for ‘carryout changes’

3.12 . 4W Framework …………………………………………………………… 45

3.13. CrossFlow meta-model …………………………………………………… 46

3.14. EREC

diagram for e-contract Textile Value-chain ………………………… 49

3.15. Workflow for e-contract ‘Textile Value chain’ …………………………. 50

4.1 EREC

framework for e-contracts ………………………………………….. 55

4.2. Process design model for e-contracts …………………………………….. 57

4.3. ACD for fund transfer activity ………………………………………......... 59

4.4. And-Or Graph of Event level Specification of Fund Transfer Activity…….. 62

4.5. And-Or Graph of Event level Specification of Material Supply Activity…... 63

4.6. Implementation architecture for EREC

framework ………………………… 69

5.1. E-contract enactment at macro level ………………………………….. …. 74

5.2. EREC

Model Instantiation ………………………………………………….. 76

5.3. Model instantiation from multiple EREC

models …………………………... 77

5.4. ER*EC

model ……………………………………………………………….. 77

5.5. Active meta-modeling of e-contracts ………………………………………. 79

5.6. Model instance before and after change depicting scenario 1 ……………. 83

5.7. Instance by migrate and merge depicting scenario 2 …………..………….. 83

5.8. New model Instance by build ………………………………..…………….. 83

5.9. Meta-ECA Rule Driven E-contract Evolution …………………………….. 84

5.10. Standard template of Housing-Loan contract ……………………………… 85

5.11. Template with change of roles …………………………………………….. 85

5.12. Template with addition of sub-contract …………………………………… 86

5.13. Template with additional concepts ……………………………………….. 87

x

5.14. A high level EREC

Model for e-contract enactment ………………………. 88

5.15. ER*EC

Methodology ………………………………………………………… 94

5.16. Progression for Active behaviour of evolving e-contracts …………………. 96

5.17. An ER*EC

architecture for evolving applications ………………………….. 97

6.1. E-Contract Activity Commitment System - High level view ……………… 104

6.2. Execution stages of an activity …………………………………………….. 108

6.3. (a) A composition, (b) An execution of the composition, …………………. 111

(c) A closed c-tree for the execution-tree

6.4. Partial backward-recovery in the Path model ……………………………… 113

6.5. Procurement Example ……………………………………………………… 115

6.6. Partial backward-recovery in the Tree-model ……………………………… 118

6.7. Procurement example with two plants ……………………………………… 119

6.8. Two-level composition for the Procurement example ……………………… 120

6.9. An example of Multi-level model …………………………………….......... 123

7.1. Different terminations ………………………………………………………. 128

7.2. A payment-made-tree for the composition …………………………………. 131

A.1. Text segments of clauses related to procurement of goods ………………… 150

A.2. Text segments of clauses related to bank loan ……………………………… 150

A.3. EREC

model for e-contract House-Building ………………………………… 151

A.4. Workflows for Bank Activities ……………………………………………… 152

A.5. Workflow for Supplier activities ……………………………………………. 152

A.6. ACD for fund transfer activity …………………………………………….. 154

A.7. Standard template of Housing-Loan contract ……………………………… 155

A.8. Template with change of roles …………………………………………….. 155

A.9. Template with addition of sub-contract ……………………………………. 156

A.10. Template with additional concepts ………………………………………… 156

A.11. Procurement Example ……………………………………………………… 157

A.12. Procurement example with two plants …………………………………….. 158

A.13. Two-level composition for the Procurement example …………………….. 158

xi

List of Tables

Table Page

2.1. Logics/Rules useful in representing e-contracts ………………………............... 14

2.2. E-contract projects ……………………………………………………………… 18

3.1. Exceptions in the meta-model for e-contracts ………………………………….. 28

3.2. Some clauses in “investment” contract ………………………………………... 31

3.3. Some Activities of FI, Investors and Banks in “Investment” contract ………… 31

3.4. Rules of “investment” contract for EREC

model ………………………………. 32

3.5. Mapping of Parties to agents ……………………..…………………………… 36

3.6. Activities of each party for the Change Management ………………………… 40

3.7. Activities of each party for the Textile value chain contract ………………….. 47

4.1. APC Specifications …………………………………………………………… 59

4.2. Rules definition for Fund Transfer activity ………………………….............. 65

4.3. Event definition for Fund Transfer activity ………………………..………… 65

4.4. Condition definition for Fund Transfer activity ……………………..… ……. 65

4.5. Action definition for Fund Transfer activity ………………………..……….. 66

4.6. Activity log definition for Fund Transfer activity …………………………… 66

4.7. Basic Web Service Specifications for Inter-organization …………………… 70

Communication Support

5.1. Meta-model change requirements during evolution ………………………… 78

5.2. Operations affecting EREC

model evolution ………………………………… 90

5.3. Handling changes during e-contract evolution ………………………. …….. 90

6.1. Dependency-Table ………………………………………………………….. 113

6.2. List of issues and solutions in e-contract activity commitments ……………. 124

7.1. Some activities and payments of an example: construction and ……………. 132

Painting job of a wall

7.2. Costs for execution of the activities described in Table 7.1 ………………… 132

A.1. APC constructs for House-Building contract ……………………………….. 153

A.2. Some activities and payments of an example: construction and ……………. 160

Painting job of a wall

A.3. Costs for execution of the activities described in Table A.2 ……….............. 160

1

Chapter 1

Introduction

Competitions among businesses made the organizations to perform better, faster and bet cost

effective, besides maintaining high performance in carrying out their activities. Thus, organizations

are focusing more on their core business activities and moving towards outsourcing to carry out other

activities. This necessitates organizations to work with partners by mutually arriving at contractual

agreements in order to identify specific parties’ (organizations or individuals) roles, responsibilities,

obligations and deliverables. Conventionally, a (legal) contract forms the basis to regulate interactions

between different parties in businesses and governs legal aspects when there is a breach of contract.

In the last few decades, the business world witnessed a growing need in exploring innovative

ways of automating the regulation of business interactions electronically. Electronic Data Interchange

(EDI) is the early development (in 1990’s) in electronic commerce and it was considered as a term

that refers solely to electronic transactions and contracts [DJC1995]. EDI has a standard data format

to enable computer-to-computer message transmission, there was not much support to semantics of a

contract, and lot of support to right kind of message passing through set data-exchange protocols.

Though EDI introduced efficient communications between organizations, it was not widely accepted

due to its cost, lack of flexibility and technological limitations [R1996]. Later in 2000, OASIS

(Organization for the Advancement of Structured Information Standards) developed an XML based

EDI trading partner agreement Markup Language (tpaML). The tpaML focused on specifying inter-

organizational agreements, in terms of messages exchanged, message sequences and the underlying

transport and security infrastructure [D+2001]. The ebXML (electronic business XML) is the latest

initiative in providing standards, which is a combined standardization effort by UN/CEFACT (United

Nations body for Trade Facilitation and Electronic Business) and OASIS.

In recent years, there is an explosion of business applications exploiting Internet and Web as a

medium. Business trends have been observed from on-line shopping (Business-to-Customer, B2C) to

on-line auctions to Business-to-Business (B2B) interactions. Electronic contracts (or simply e-

contracts) helps in building such new business relationships and fulfill contractual agreements

through electronic contracting systems. E-contracts enable precise specification of contractual

activities, terms and conditions, compliance checking and enforcement. In addition to legal binding

between parties, e-contracts are also used across different workflows systems to fulfill (cross-

)organizational business processes [KGV2000] and integrating different web services [CCT2003].

Thus, an e-contract is viewed from a simple electronic contract document to a computerized

facilitation or automation of a contract.

With the advent of e-commerce, many online business transactions involve both implicit and

explicit contracts that are accepted by entities involved in the transactions. For example, buying a

2

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

3

Traditionally, contracts are voluminous documents that are created, executed and managed via

paper-based methods. These contracts incorporate certain commitments made by the involved parties.

For example, in a buyer-and-seller contract, the buyer agrees to purchase certain goods, whereas the

seller agrees to supply goods of a certain quality. However, a contract between two or more business

partners can be much more complex than the buyer and seller transaction. Such a contract may have

different phases like identifying business partners; matching offers against requirements; negotiating

terms, conditions and pricing; signing; and execution.

Contract lifecycle involves Business Information Exchange leading to Contract Negotiation, then

to Contract Preparation, and finally paves way for both Contract Enactment and Contract Monitoring

& Management (Figure 1.1). All these processes can be summarized into three main stages namely:

(i) Contract Preparation, (ii) Contract Negotiation, and (iii) Contract Fulfillment (or successful

execution).

(i) Contract Preparation

In this phase, contract document is prepared by specifying the contractual roles, abstract business

interactions and contractual conditions. Rules and constraint are also added which should be adhered

to during the contract fulfilment phase [CNSK2007]. Both functional (ex., terms and conditions, order

of activities to be carried out) and non-functional requirements (ex., quality of the service) are

included in the contract document. That is, contract preparation provides the specifications for the

fulfillment of the contract. Usually contracts are drafted based on some pre-defined format (template),

which has a number of place holders (or variables) that are agreed upon in the contract negotiation

phase.

(ii) Contract Negotiation

Contract negotiation is a decision process in which contracting parties make individual decisions

and interact with each other, and come to a mutual agreement on the contract content [L1998,

CCT2003]. In contract negotiation phase, payments, deliverables (along with their quality), and

milestones are agreed upon. A successful contract negotiation ascertains the terms that are beneficial

to all the parties involved.

Business Process Information Exchange

Contract Negotiation

Contract Preparation

Figure 1.1 Contract Lifecycle

Contract Monitoring & Management

Contract Enactment

E-contract Execution

4

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.

5

Escalations: When there are conflicts among parties during contract execution, the involved tasks

need to be escalated to parties who have higher roles. Contract document contains

explicit statements with regard to escalations and the people responsible to handle the

escalations.

Authorization: In contracts, authorization refers to the process of determining which permissions a

party or an organization is supposed to have for carrying out certain tasks. For

example, one agency is authorized to carry out currency exchanges.

Jurisdiction: Jurisdiction of a contract defines the region or provenience where the legal proceedings

can take place when there are disputes. Jurisdiction clauses refer the disputes arising

under the contract to a country, territory or place for hearing and resolve.

In the literature, a lot of work has been done in e-contract negotiation and business process

support. Weigand et al.[WSMD2003] presented a support system for carrying out negotiations for

business-to-business transactions. In their work, the formal analysis of different types of negotiations

is performed from the communication perspective based on Haberma’s theory of communication

action, and the norm-oriented, goal-oriented, document oriented models and protocols are described.

Schoop [Sc2002] presented non-automated negotiation support models to support human negotiators

in their complex negotiation process involved in the document management for e-contracting. Though

there is no specific work in the literature to support budgets in an e-contract system, budgets can be

easily accommodated into the system. We modeled budget in our EREC

meta-model (Chapter 3). Xu

[X2004] described a temporal logic based formalism to support contract commitments. In this thesis

work, we presented contract commitments by developing a multi level composition model (Chapter

6). Authorization can be supported by specifying roles to concerned parties. Similarly, specification

of escalations and Jurisdiction can be supported as part of clauses. However, supporting identification

and handling escalations as well as Jurisdiction are difficult tasks in building an e-contract system as

they require appropriate interpretation of clauses, which are very specific to individual contracts;

domain-dependent (insurance, manufacturing, etc.) and are usually assisted by humans who are

experienced in resolving such tasks [A2009].

Consider a ‘buyer-and-seller’ contract, where the principal parties are the buyer and the seller.

The contract activities include dispatch of goods by the seller, receipt of the goods by the buyer and

payment of the goods to the seller. The contract also contains clauses such as delivery terms for the

seller, which are negotiated and agreed upon by mutual consent of both the buyer and the seller. Thus,

the primary obligations of the buyer is to pay the money and accept the goods based on the delivery

terms; and that of the seller is to deliver the goods as per the contract meeting the buyer’s

requirements.

Clauses can be satisfied by activity completions. Activities are initiated by success or failure of

clauses and/or due to temporal and external events. Obligations furnish clauses related to Quality of

Service (QoS) such as performance, availability and security; obligations are described as a part of

the Service Level Agreement (SLA) in the contract document [V1999]. Non-adherence of contract

deliverables is solved through issuance of Penalties, which are explicitly specified in the agreed

contract. Contracts can have complementary or compulsory SLAs which have to be fulfilled during

6

contract enactment. E-contract management solutions should maintain, monitor and manage contract

rules derived from these SLAs. Contract parties should verify QoS parameters by performing an SLA

monitoring, which involves monitoring the performance status of the offered service. The e-contract

management system could assess the SLA requirements and apply penalties if there is any deviation.

As a last resort, disputes can be arbitrated. However, the basic premise of an e-contract is to

successfully complete the execution, and automation of the dispute resolution process [DDM2002,

MJPD2002] is a separate problem itself.

1.4 Document Contracts to E-contracts

As stated above, a contract is a statement of intent that regulates behavior among organizations

and individuals. Until now, most contracts have had a ‘paper appearance’ and have been handled

manually for the most part. An e-contract is an electronic version of the conventional contract which

stipulates that the involved parties agree to fulfill specified activities and also regulates cross-

organizational business processes over the Internet. More formally, an e-contract can be modeled,

specified, executed, controlled and monitored by a software system. Several advantages can be

attributed to the use of e-contracts including improved productivity, accelerated contract lifecycle,

reduced risks and improved security, increased profits and superior monitoring of contract enactment.

These are mainly due to the mapping of e-contract documents to workflows which are supported by

secure IT infrastructure, thus resulting in better productivity. Moreover, electronic bookkeeping

(including legal aspects), authorization, alerts and tracking are possible with an e-contract system. In

e-contracts, all (or a number of) activities are carried out electronically, thus overcoming the delays

involved with their manual counterparts, and also personal biases.

Contemporary contract documents with legal jargon do not provide a clear path for deciphering

the relevant clauses which are to be met by the involved parties. E-contracts can be modeled to detect

the violation of clauses and respond appropriately. Hence clauses in an e-contract must be represented

in a standard format for easy comprehension. Further, the e-contract system can facilitate dispute

resolution by providing relevant information from audit trails.

E-contract handling offers new ways of interaction among parties and modifies existing ones. For

example, over a period of time, organizations can learn about contracts that are not profitable and use

this knowledge to come up with revised contracts to reduce their losses.

E-contracts are rapidly becoming an important component for conducting business in cyberspace

since their advent in the business negotiation scenario. With their use, it is becoming plausible to

optimize the negotiation phase and the contract management process. The adoption of XML based

contracts must be the first step towards a truly IT supported contracting process. It is highly likely

that different forms of e-contracts will emerge, depending on the type of industry; and that the

existing market places will extend their services along with the e-contracting services. The challenge

here lies in transforming traditional contracts into executable e-contracts. The e-contracts problem

requires a comprehensive integrated solution, and not a loosely coupled solution of various disparate

7

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

8

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.

9

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 EREC

meta-model that can be instantiated a specific EREC

model for modeling a

contract under consideration.

• showed mapping of EREC

model to Workflows and present different types of workflows for

e-contract enactment.

• presented a methodology and framework to arrive at implementation architecture for e-

contracts.

• extended the EREC

model and methodology to support e-contract evolution and enactment

thereby.

• developed a composition model for activity commitments and dependencies during e-contract

activities execution, tracking payments and eventual closure of e-contract.

1.6 Scope and Limitations of This Thesis

The proposed work in this thesis relies on e-enactment of e-contracts through modeling, thereby

providing Database Driven e-Enactment Environment (DDEE) for deploying e-contracts. This

environment uses meta-models, which are helpful to instantiate appropriate data models and in-turn

drive the contract enactment. The DDEE approach provides better support for managing contracts and

10

their evolution by keeping data models in synchronization during complete contract enactment period

(that is, from contract execution start to its closure). DDEE facilitates tracking of changes in the mini-

world as well as run-time environment to synchronize the data models based on the evolution of e-

contracts. It also helps in versioning the models and captures the knowledge from run-time execution

of contracts.

This thesis work assumes that the parties have agreed about the terms and conditions specified in

the contract document and the contract document is signed, that is, both contract negotiation and

contract preparation stages have been completed, and the contract is ready for enactment.

In this work, we assume that the unwritten contracts are handled manually and disputes, if any,

will be handled through arbitration. Next, processing legal statements and dealing with legal

ambiguity to support e-contracts is a separate problem itself and hence not dealt in this thesis work.

The EREC

model proposed in this thesis provides support and convenience for handling expected

exceptions, and the unexpected exceptions are resolved in a human-assisted mode [CLK2000b].

However, our DDEE enables provision for incorporating these unexpected exceptions in the meta-

model in a more easy form, resulting necessary procedures for changes in the 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.

11

1.7 Thesis Outline

The main body of this thesis is organized as follows:

Chapter 2 reviews related work from different dimensions of e-contracts, including modeling,

representation and specification, monitoring, workflow and architecture and framework.

Chapter 3 presents e-contract modeling, which forms the core of this thesis work to support

modeling and enactment of e-contracts. This chapter introduces the conceptual model, referred as

EREC

model, which models the contract elements, and provides mapping to workflow elements to

facilitate contract enactment.

Chapter 4 presents a methodology and framework for e-contract system development. This

chapter introduces four layer framework for e-contracts and builds an e-contract methodology by

considering both conceptual and execution aspects of e-contract systems. We also explained activity-

commitment diagrams, and used SNOOP language to handle contract events. Further, workflow

engine along with web services have been used in developing implementation architecture for e-

contracts.

Chapter 5 is concerned with the evolving e-contracts, which is another vital part of our research.

We extend our EREC

model to support evolution by introducing evolution operations and meta-ECA

rules. We also explain progression for Active behaviour of evolving e-contracts and how these

technologies facilitate structural and behavioural conformance of e-contracts due to evolution.

Chapter 6 introduces a multi-level composition model which provides transactional support for e-

contracts commitments. We associate the commitments with respect to e-contract activity execution

states. We also explain the path and tree models, and activity dependencies. These works together

enable monitoring the behavioral conditions stated in an e-contract during its execution.

Chapter 7 presents payment aspects in e-contracts. With an execution model that accommodates

the complexity of the activities in contracts, we have correlated several payment issues to the states of

execution of activities. The variety of states in the execution enables a fine-grained association of

payments to activities. We have also given a simple mechanism for tracking payments against

execution of the activities.

Finally, Chapter 8 summarizes the findings of this research and discusses directions for future

work.

12

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.

13

ebXML Meta-Model [ ebXML2000] provides support for e-contracts, which has an economic

basis, in a limited way. This meta-model consists of five groups: Resources and Contracts, Markets

and Parties, Business processes and Rules, Business Service Interfaces and Communications, and

Information Model. In this meta-model, the business processes and rules group are strongly related

contracts, which specifies processes that govern the fulfillment of commitments as part of the

agreement.

Linington [L2005] presented model-driven approach based on meta-models to support contract-

based business processes, creating an implementation routine that minimizes human intervention in

contract design. Fantinato and his colleagues [FTG2006] [FGT2006] described a contract meta-

model based on feature 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.

14

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 Usage

Horn Logic

Derivation rules (rule changing), Negation as

failure, Procedural attachments, external data

integration.

Description logic

Represent the terms (contract vocabularies and

domain-specific concepts ) used in a contract;

Defeasible logic Conflict resolution and priority relation of rules;

Deontic logic

Represent rights and obligations with violations as

exceptions.

ECA rules

Specifying events and actions, and modeling the

active behaviour of e-contracts

Derivation rules

Deductive reasoning on contract rules, default rules

and priority relations of rules

Event Calculus

Derive temporal reasoning over effects of events

on fluents (contract tracking).

Table 2.1 Logics/Rules useful in representing e-contracts

Angelov et al [AG2003] present an in-depth study about the requirements on an e-contract

specification language based on the 4W e-contracting framework. This framework states that an

efficient e-contract specification language should include at least three different constructs: data

constructs, rule constructs and process constructs; should allow the specification of the information to

be exchanged and the activities to be performed; should provide mechanisms to specify and manage

changes in the contract elements.

Daskalopulu and Maibaum [DM2001] represented contracts using Modal Action Logic for formal

specification of temporal constraints and error recovery, and Deontic Action Logic for temporal

15

reasoning over Deontic specifications. Governatori and Milosevic [GM2006] described FCL using

Defeasible logic and Deontic logic to express contract specifications.

In the works of Daskalopulu et al [DDM2001], Finite Sate Machines are used to attempt to assess

contract status and implication of eventualities. Carlos et al. [CSSW2004] described contracts by

Finite State Machines and presented an X-contract (executable contract) system that deals with

ambiguities existing in contract documents. This system also supports monitoring and enforcing the

rights and obligations of parties at run-time.

Tagg et al [TMKG2004] employed Business Contract Language (BCL) for specification of

business processes and derived recommended workflows. BCL is an XML-based language and it

facilitates specifying e-contracts in a way that allows automatic management including contract

monitoring and enforcement based on the event concepts. BCL is also useful to define behavioral

constraints and structural aspects, as the definition of the clauses and sub-clauses that compose the e-

contracts. Farrell et al [F+ 2004] presented automated performance monitoring of e-contracts in terms

of tracking contract states by expounding an XML formalization of the event calculus and ecXML.

Logic based formalisms (e.g., BCL, Formal Contract Logic (FCL) [MSO2006]) can be used to

describe semantics including constraints, obligations, permissions, prohibitions and violations in

contracts. For example, a clause “In case of goods not received in good condition, the seller should

offer the goods at a discount price. If the seller fails to fulfill this obligation, the seller will refund the

amount fully with the penalty (e.g. interest)” can be represented in FCL as :

Rule1: ObReceiveGoods |- OSQualityOfService ⊗ OSOfferDiscount⊗ OsRefundAndPenality

The semantics represented in the logic-based formalisms need to be mapped to business process

specifications using available languages such as BPMN, BPEL and Petri-nets. Logics can be

internally used in 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 (www.omg.org) released a standard

known as Semantic of Business Vocabulary and Business rules (SBVR) to specify vocabulary and

business rules for business processes.

16

Although there are several efforts to specify e-contracts, a specific e-contract specification

language is still missing. The existing logics and rules are useful in order to specify and represent e-

contract activities and clauses; however they need a precise specification of activities and clauses

which is hard to define from contract documents due to its high-level of abstraction.

2.3 E-contract Monitoring

Monitoring an e-contract requires precise expression of contract semantics to comprehend the

behaviour of contract parties. The requisites influence both the contract language design and contract

architecture components. E-contract monitoring is a process whereby, activities of the parties listed in

the contract are governed by the clauses, so that the execution of the activities can be monitored and

violations acted upon. Specification and detection of events play a vital role in the process of

analyzing, monitoring and visualizing the behavior of each party involved in the e-contract. Thus, one

major requirement for e-contract monitoring is event based monitoring. Another noteworthy feature

is to have pro-active monitoring of events.

Abrahams and Bacon [AB2002] presented a mechanism for storing, monitoring and enforcing e-

commerce contract provisions based on Kimbrough’s Disquotation Theory. This work focuses on

prepositional content in a sentence and expounds the fulfillment and violation conditions. It also

demonstrates its application to the creation of computational environment for monitoring and

enforcing electronic contracts.

Herring and Milosevic [HM2001] presented a BizTalk technology for B2B contracts to monitor

the business interactions governed by a contract.

Weigand and Xu [WX2001] proposed a model that focuses on task allocations and process

coordinations. Xu and Jeusfeld [XJ2003] described proactive monitoring of activities using temporal

logic for any contract violations to fulfill the contract during its execution. Xu [X2004] proposes a

pro-active e-contract monitoring system to monitor contract violations. They represent constraints

using propositional temporal logic in order to provide formal semantics for contract computation at

the contract fulfillment stage. However, their formalism does not provide the execution level

semantics of an e-contract commitment.

Lopes and Oliveira [LO2005] described an agent-based environment to provide contract related

services for virtual enterprises. Their framework also provides contract formalization using structured

normative approach, their monitoring and enforcement. Rouached et al [RPG2005 ] presented event-

based framework associated with a semantic definition of the commitments expressed in the event

calculus to model and monitor multi-party contracts.

The technologies related to event monitoring, active databases and expert systems are germane to

detect conflicts and violations in e-contract environments; however, they do not keep event histories

that are essential for contract monitoring purposes.

17

2.4 Workflows

Workflow technology provides a way of modeling and automating business processes. The

Workflow Management Coalition (WfMC) has recently proposed standards for an Interworkflow

Application Model to model inter-organizational workflows and Wf-XML [WFMC2000], which is an

interchange format specification for an XML language designed to model the data transfer

requirements for inter-operating process specification. These documents describe the modeling and

specification of the overall workflows and inter-organization issues. Much research has been devoted

to formal verification of workflow systems for business processes. In [A1998, AH2000], petri-net

based structures are used to verify the correctness of workflow procedures. Van der Aalst et al.

[AKV2003] developed a formal organizational model using UML and XML to support workflow

systems. Akhil Kumar and Zhao [KZ2002] presented a language XRL (Extensible Routing

Language) to support the routing of workflow for Internet-based electronic commerce services. The

jointFlow [S1998] standards proposed by OMG group facilitates the enactment of workflow process

components and supports interfaces for process execution, monitoring and interoperation between

process components. Lei and Singh [LS1997] detailed a comparison of various workflow meta-

models. The ADOME WfMS model [CLK2000] facilitates exception handling during workflow

execution.

Green and Vonk [GV2006] describe the relationship between transaction management systems

and workflows for transactional business process support. Iwaihara, Jiang and Kambayashi [IJK2004]

presented a Workflow-Contract-Solution (WCS) model to support e-contract oriented execution of

business processes. The CrossFlow model [GAHL2000] provides cross-organizational workflow

support to provide role based interfaces and connecting workflows by runtime role mapping.

Though most of the above works are not directly related to workflows for e-contract processes,

they are useful in hanldling e-contract activities. Usually workflow processes are very clearly stated.

But, a contract process does not describe a concrete work procedure but provides abstract

representations of obligations and rights. This necesisates a need for translation mechanism to

translate e-contract elements into workflow processes.

2.5 Web Services

XLANG [T2001] is based on the Web Service Description Language (WSDL) service description

with an extension element that describes the behavior of the services as a part of a business process.

In XLANG, the behavior of each Web service is specified independently, and the interaction between

Web services is only through message exchanges expressed as operations in WSDL. Similarly,

Leymann [L2001] describes Web Services Flow Language (WSFL) on their MQSeries workflow

engine that is also layered on the top of the WSDL. The WSFL is an XML language for the

description of Web services compositions for supporting workflows. WSFL specifies the appropriate

usage pattern of a collection of Web services in order to achieve a particular goal (e.g., information

18

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

19

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 (www.ebxml.org) 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

20

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 (www.ist-

contract.org). It develops frameworks, components and tools for modeling, implementing, verifying

21

and monitoring distributed e-business systems. The main focus of this project is on inter-

organizational 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?

22

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 EREC

model and framework for modeling and enactment

of e-contracts, adopting EREC

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

the meta-model.

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

EREC

meta-model, in the next chapter.

23

Chapter 3

E-contract Modeling: EREC 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 EREC

model for conceptual modeling of

e-contracts. This work also focuses on deriving workflows from EREC

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.

24

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 EREC

meta-model for modeling e-contracts.

3.2 EREC 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 EREC

meta-model for

a contract.

3.2.1 Meta-model constructs

The EREC

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.

25

Can

have

Lists Have

Budget

Reject

Request

Rule-1

Allowed

Not Allowed

Budget

Over

Addition

of New

Parties

Parties

Is a (1, n)

(0, n)

Payments

refer

Role

changes

Sub

Contract

Relations

Rules

Events

Rule - 2

Stop

Work Rule - 3

Roles

Can

have

Has

Clauses

Activities

Contract

Can

have

Figure 3.1 A Meta Model for E-Contract

(0, n)

(1, n)

(1, 1)

(1, n)

(1, n)

(1, n)

(1, 1)

(1, 1)

(1, n)

(1, n)

(1, n) (1, n)

(1, n) (1, n)

(1, n)

In addition to entities and relationships and their attributes, EREC

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 EREC

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 EREC

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.

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

26

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 EREC

meta-model depending on specific needs of the application domain.

However, the EREC

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 EREC

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 EREC

meta-model serve as a reference model so that e-contracts can be designed using

available technologies/tools such as RosettaNet and ebXML.

27

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

<temporal_event> | <external_event>

<composite-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 EREC

meta-model to support evolving e-

contracts in section 5.5.

3.2.3 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

28

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.

3.2.4 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 EREC

model by handling a contract.

The complete contract is modeled as a single EREC

model. In case sub-contracts exist within a

contract, each sub-contract can be modeled as separate EREC

model and all models can be integrated

as a single EREC

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 EREC

meta-model can be treated as a template of an EREC

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 EREC

model. This is a special feature of this model that is used in translating an EREC

model to a set

of workflows.

(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

29

Activities

Delivery time >

2 weeks

Invalid account details

Hold

Resend again

Wait

Send Clarification

has

Supplier

have

Payments

Parties

∪

Exceptions

Buyer

Delivery

approval

Bank

Goods

damaged

during

shipment

Order of Goods

Shipment of Goods

Delivery of Goods

Transfer of Funds

Reject

Not sufficient balance

• •

Figure 3.2 EREC

diagram for buyer-seller contract

Good not received

refer

Buyer-Supplier

Contract Payment exceeds

one Million

Compensate

• • •

Relation between entity types Input events for exceptions

Relation between instances of entities Output events for exceptions

3.3 Modeling Example Contracts

The EREC

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 EREC

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:

� EREC

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)

� EREC

model: a conceptual model instantiated from EREC

meta-model for conceptual modeling

of a specific contract under study.

� Instance of EREC

model: an instance of a specific EREC

model for a specific e-contract.

3.3.1 Buyer-and-Seller contract

Figure 3.2 illustrates EREC

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

30

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.

3.3.2 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

31

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

model for the present example.

Activity FI 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. 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.

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

32

Ru

le 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.

Ru

le 2

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

Ru

le 3

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

Ru

le 4

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

Ru

le 5

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 EREC

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 EREC

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

33

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 EREC

model to workflows (covered in the next section).

3.4 Mapping EREC 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

Reject

CL-a

CL-b

CL-d

refer

Clauses

Investment

Contract

Agreement

Bank

Customership

Inter-Bank

Sub Contracts

Activities

(A1,A2,A3, A4)

Invalid Invalid

Account

Details

Hold

Resend

Again

No

Sufficient

Balance

Wait

Send

Clarification

Bank

Agency

have

Submission

Maturity

Repayment

Periodic

Repayment

A1

A2

Scrutiny

A3 Change

Ownership

A4

Funds

Transfer

Allotment

Payments

Parties

∪

FI

Exceptions

Investor

CL-c

Relations between entity types Contract Events

Relations between instances of Output events for exceptions

different entities Input events for exceptions

have

has

Fund

Receipt &

Info. To FI

Figure 3.3 EREC

model for “investment” E-Contract

34

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 EREC

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.

3.4.1 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"

EREC

(explained in previous sections) model to a workflow. Therefore, the workflow model has to be

35

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.

3.4.2 Mapping EREC

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 EREC

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 EREC

model have to

map to workflow components. The mapping of EREC

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.

Role

Invoked Application Transition

conditions may refer to

may

refer to

consists of

uses Workflow

Relevant data

uses

has

may

have

Workflow Type

Definition

Activity

Figure 3.4 A typical workflow meta-schema

36

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 EREC

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 EREC

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, EREC

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 3.3.2. 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 EREC

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,

37

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

Scrutiny Allotment Periodic

repayment

Maturity

Payment

End

Invalid

Hold

Resend

Again

Start Fund

Transfer End

No sufficient

balance

Wait

Send

clarification

Invalid

account

details

(a) Augmenting Invalid and Invalid account details exceptions to workflow B

Reject

(b) Augmenting No sufficient balance exception to workflow D

Fund

Transfer Fund

Transfer

Figure 3.6 Augmenting exceptions as additional activities to workflow

Figure 3.5 Mapping activities to workflow

Start End Start End

Start Scrutiny

Allotment

Periodic

repayment

Maturity

Payment

End

Fund

Transfer

(a) Mapping Activity A1 to workflow A

Start Submission Fund

Transfer End Fund Receipt &

Info. To FI

(c) Mapping Activity A3 to workflow C (d) Mapping Activity A4 to workflow D

(b) Mapping Activity A2 to workflow B

Fund Transfer

Fund

Transfer Change

Ownership

38

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 EREC

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 A1, A2,

A3, A4, A5, A6 in a workflow is Seq(A1, OR(A2, A3), AND(A4, A5, A6)). 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.

39

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

40

“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

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

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.

To illustrate the presented approach, FMS contract document is studied and selected some of the

complicated parts to model them using EREC

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)

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

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

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

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

41

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

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 EREC

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

Fig. 3.8. EREC

model for e-contract “Financial Messaging Solution”

refer

have

Payments

Parties

Vendors

Banks

Relations between entity types Contract Events

Relations between instances of Output events for exceptions

different entities Input events for exceptions

Service Provider

Application Software Developer

CL-a CL-c CL-d CL-b

Clauses

Contr

FMS have

SC-5 SC-6

Sub SC-1 SC-2 SC-3

SC-4

Activ

A-2

A-5 A-3

A-4

B-1 B-5

B-2 B-6

B-3

B-4

C-2

C-5 C-3

C-6

D-1 D-3

C-1

B-7

C-7

C-4

D-2

D-4

A-1

Clarification

Invalid

Request/

Information

Acceptance

Failure

Hold

Resend

Again Wait

Send

Clarification

Excepti

No

Sufficient

Balance Wait

∪

has

42

clauses mentioned in the figure 3.7 and table 3.6 respectively. For the sake of clarity, few links are

only shown in the EREC

diagram.

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

Figure 3.10 Sub workflow for activity [A-4] in Change Management of FMS e-contract

Analysis Start Identify design changes

Coding End

Testing

Sub-workflow of “carry out “ Activity Testing Failure

Figure 3.9 Workflows for Change Management of FMS e-contract

Start Identify

Request Assign

Priority,

Description

Inform

to

Vendor Clarification

H/W & S/W

Requireme-

nts

Upgradition

of H/W &

S/W

Acceptance

for Change Pay-

ment

Start Receive

invoice Receive

Payments

End

Installation Failure

Start Assign

CMR No.

End Reject

Acceptance Failure Invalid Information

Installa-

tion

Supply

HW &SW

Accept Carryout

changes Receive

Payme-

nts

No sufficient balance Acceptance Failure

Request

Examina-

tion

Banks/

Service

Provider

(Activities:

B-1 to B-7,

C-1 to C-7)

End

No sufficient balance

Vendors

(Activities: D-1 to D-4)

Application Software Devloper

(Activities: A-1 to A-5)

43

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

Figure 3.11 (a) Parametric workflows for ‘payments’ (b) Workflow views for ‘Receive Payments’

(c) Dynamic workflows for ‘carryout changes’

(c)

(b)

(a)

Send Payment instruction

Sign the check by single person

Issue the check

Start

End

Send Payment instruction

Sign the check by two persons

Issue the check

Start

End

Start End Receive Payment

Ack. Check receipt

Ack. Check clearance

Start End

Ack. Check receipt

Receive Check

Check deposit in bank

Start

End

Coding additional module

Credit check amount

Ack. Check clearance

Testing Failure

Insufficient balance

Send the Check for clearance

Start

End

End

Start

Testing

Testing Failure

Identify design changes

Analysis for new model

Modify existing code

Testing

44

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 EREC

model to

workflows elements. Our EREC

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

EREC

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 3.12. 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 EREC

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 EREC

meta-model. So, the Processes

concept can serve the purpose of Activities in the EREC

model. Constraints, which are part of

exchange value provisions, in How concept can partly cover the Clauses in our model.

45

EREC

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 EREC

model.

From the above discussion, it can be evident that 4W framework addresses subset of EREC

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 EREC

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 EREC

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 3.13.

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) Concept Model: It establishes the terminology for the contract. It consists of a list of

parameters formed by name, type and description.

(ii) 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.

Figure 3.12 4W Framework (taken from [A2006 ])

46

CrossFlow meta-model and EREC

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, EREC

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

(0, M)

(0, M)

(0, N) (0, N)

(0, N)

(1, 1)

(0, 1) (0, 1) (N, M) (0, 1) (0, 1)

(1, 1) (1, 1) (1, 1) (1, 1) (1, 1)

(1, N)

(1, 1)

(0, M) (0, N)

(0, M) (0, N)

Contract

Process

Model

Description Usage

Clause

Enactment

Clause

Process Element

has has has has has

Consists

of

Refers

to

Concept

Refers

to

Refers

to

Refers

to

Refers

to

Figure 3.13 CrossFlow meta-model [KGV 2000]

47

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.

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:

C: Weavers

[C-1] Receive the raw material,

[C-2] Process material

[C-3] Supplying the weaved material/gray cloth to

STC/Printers

D: Printers

[D-1] Receive the weaved material

[D-2] Process (dying and printing) the material

[D-3] Shipment of finished goods to 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

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

48

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. 3.14 presents the EREC

model while Fig. 3.15 presents workflows (including inter-

organizational 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 pre-

contracting 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

49

CL-2

CL-n

have

Bank Customership

Inter-Bank

Invalid Account Details

Hold

Resend Again

Wait

Send Clarification

has

Bank

Weavers

have

Payments

Parties

∪

STC

Exceptions

Mill

CL-3

Relations between entity types Contract Events

Relations between instances of Output events for exceptions

different entities Input events for exceptions

Printer

Showroom / organization

STC&Mills

STC&Weavers STC &

Printers

STC& ShowRooms / Inst.

No

Stock

A-3

A-5

A-7

A-4

A-6 A-8

B-1 B-2

C-1 C-3 C-2

D-1 D-2

E-1 E-2

E-3 E-4

F-1 F-2

Time Limit

Crossed

Reject

D-3

No Sufficient Balance

CL-4

……

Figure 3.14 EREC

diagram for e-contract Textile Value-chain

Design not upto the mark

refer

Textile A-2 A-1

CL-1

to support repeated contracts such as STC and Printers bi-lateral contract described in Textile value-

chain contract.

EREC

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 EREC

model to deployable inter-organizational workflows.

Providing the information about the low level relationships in EREC

model not only helps in proper

monitoring, but also facilitates a proper execution plan for contract fulfillment and its successful

closure.

50

3.7 Summary of Contract examples

The EREC

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.

Figure 3.15 Workflow for e-contract ‘Textile Value chain’

Supply raw

material End

Start Receive the raw material

Process the material

End Supplying the weaved material

Start Process the material

End Supplying the

weaved material

End Sell the material

Account Subscription End

Receive the material

STC (Activities A -1 to A -8)

Mills (Activities B-1 to B-2)

Weavers (Activities C-1 to C-3)

Printers (Activities D-1 to D-3)

Showrooms/Institutions (Activities E-1 to E-4)

Start

Banks (Activities F-1 to F-2)

Receive the weaved material

End

Requirement

analysis Start

Inventory

Management Estimation of

raw material

Shipment of

raw material

to weavers Shipment of

weaved

material

Shipment of

finished goods Training to

weavers

Receive the

invoice

Time limit crossed

Goods damaged

Goods not upto the mark

Time limit crossed

Send request for material

Inventory

Management

No stock

Goods damaged

Fund Transfer

Start

Invalid account details

No sufficient balance

Time limit crossed

No stock

Start

Purchase

order to Mills

51

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

contracts. 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 EREC

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

EREC

meta-model and illustrated example EREC

models. EREC

model is useful to represent the

complex inter/intra relationships among entities in an electronic contract. The salient feature of the

EREC

model is the conceptualization of “instances” and constructs, and relationships among them.

This advocated the notion of an EREC

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

time is proposed. The points that need to be noted are:

1. The EREC

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

EREC

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

52

example. Thus, EREC

model is one of the first models to facilitate conceptual modeling of cross-

organizational e-contracts that are implemented by cross-organizational workflows.

The mapping of EREC

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 EREC

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.

53

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. EREC

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 EREC

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 EREC

framework for designing e-contract processes, a mechanism that allows

modeling, enactment and monitoring. This framework centers on the EREC

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.

54

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 EREC Framework and Methodology

A layered framework, EREC

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 EREC

framework, which consists of

the following layers:

1. Document layer – XML-based e-contract specifications, which facilitate document and semantic

exchange.

2. Conceptual layer - EREC

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 EREC

model (also referred to as data

model for e-contracts) for a specific contract can be instantiated from the EREC

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. EREC

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 EREC

(meta-) model. This special feature is useful in translating an

EREC

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

event and post-event. It contains the details such as time of the event, action considered and

55

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 EREC

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.

Figure 4.1 EREC

framework for e-contracts

EREC Meta-model

(template)

Relation Tables

APC

Constructs

Workflows

EREC Data

Model

Implementation Layer

Logical Layer

Conceptual Layer

Legend:

Input

Process Flow

Monitoring

& updation

Instantiation

Activity Commit

Diagrams

Workflow Instances

CONTRACT DOCUMENT

Document Layer XML - CONTRACT DOCUMENT

ECA Rules

Software

Components WFMS Web

Services

56

Notion of Database supported e-contract enactment

The most important aspect of layered EREC

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 EREC

data model and helps in capturing application semantics from contract documents. The

logical layer is useful to capture execution level semantics. The EREC

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 EREC

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 EREC

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. Inter-

organizational interfaces are formulated and implemented with Web Services.

57

Requirements Collection (subcontracts, parties, activities, clauses, relationships, events, exceptions, etc. )

Contract Document

Contract Model requirements

Conceptual schema (EREC data model)

Contract Process Requirements

Log

Records

Logical Schema Transactions

Application Design

Physical Design (Relations, Workflow Instances, Applications)

Internal Schema

Workflow Mapping (Logical Design)

A P C Constructs

A C D

XML-tagged e-contract specification

Structural validation

Functional Validation

Conceptual e-contract specification

Behavior

validation ECA Rules

Figure 4.2 Process design model for e-contracts

Log records specification

58

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 EREC

model by first handling a contract. The complete contract is modeled as a single

EREC

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 (www.w3.org/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.

59

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

Party <Party> <Party Number> ..<Party Name >.. </Party> +

Activity <Activity> <Activity Number> …<Description> …. <Start Date > … <End Date> …. < Previous Activity>…<Recurring Time> ..… <Next Activity>…. <Parties Responsible>..</Parties Responsible> + <Clauses>…< /Clauses> + <Exceptions>…</Exceptions> + </Activity>+

Clauses <Clause> <Clause Number> <Description> <Activity Number>.+...<Party Number> + </Clause> +

Table 4.1 APC Specifications

Figure 4.3 ACD for fund transfer activity

Party1 gives debit instruction to its bank A

and party 2

Bank A debits Party 1

account

Bank A send to clearing

centre for clearance

Clearing instructions will go to Bank B

(party 2’s bank)

Bank B credits to

Party 2’s account

Bank B inform to Party 2

L

L

60

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 EREC

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

61

(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

62

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.

Figure 4.4 And-Or Graph of Event level Specification of Fund Transfer Activity

Start

Take Instruction

Request additional Information

Information

incomplete

or false

Stop

Check Party 1 account

Amount =’ not

available ‘ amount

=’available’

Send to clearance center for clearing

Amount

credited to

party 2

Party 2 account

= ’available’

Information to party 2

Amount credited to party 1

Party 2 account

= ’not available’

Check

Time out Check Time out

Instruction to P2 from P1

Information to clearance center

Clearance

information to

bank B

Debit

Party 1

account Debit instruction from P1 to bank A

63

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.

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

Accept

Reject No matching

quote

received

Material

is in order

Information

missing

Not Confirmed

Received quotes

are in the

required order No Quotation

received

Figure 4.5 And-Or Graph of Event level Specification of Material Supply Activity

Start Find Suppliers

Revise the specification

User

Evaluation

Stop

Evaluate and Select the quote

Confirmed

Send to supplier for acceptance

Fund Transfer

Check

Time out

Arrange the shipment Send the

material Prepare

the

Material

Get quotation and/or products information

Request for

additional

information

Send the payment invoice

Material is not in order

64

An ECA definition table is defined as follows:

RuleTable (Rule id , Event id , Condition id , Actionid, 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 2.

4. List all events, which can be occurring during the execution of actions of step 3.

5. 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.

65

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 Conditionid Actionid 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

Eventid EventType description object Affected RuleFires 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

Conditionid 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

66

Time Event Object PrevAction PostAction

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 6.

4.5 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

Actionid ActionType 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

67

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 EREC

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 EREC

framework. The six main

modules for the EREC

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].

68

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 EREC

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

specific 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 object-

oriented 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 system-

assisted 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 4.7.

69

Web Service Server

Public UDDI

Registry

Business

Partners

Internet

ACD

SpecificationManager

Database for e-Contracts,

Workflows, Rules, etc.

E-ADOMEWorkflowEngine

Contract Document

and Template

Manager

EREC Contract Support System

e-Contract

Workflow

Spec.

Intranet

APC Specification

Manager

WorkflowGeneration/ Specification

Subsystem

Contract Enactment Monitor

ECA Rule

Manager

rules

events

ACD Spec

APC Spec

rules

Rules

Rules.

Events Results

Application

SpecificComponents

Figure 4.6 Implementation architecture for EREC

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

e-mail, 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 e-mail 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.

70

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, www.ist-contract.org [IST 2009, BHJ 2009] ).

4.7 Summary

The implementation architecture for the EREC

framework has been designed in such a way that

the EREC

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 EREC

framework addresses the mechanism for modeling,

enactment and monitoring e-contracts effectively. It bridges the gap between the XML contract

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 E-Mail

• SubscribedEvent

• NotificationParameter

o transmissionPort

o TransmissionParameter

(like email | 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

71

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

organizational 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 meta-

model. 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 meta-

events in order to facilitate the structural and behavioural conformance of modeling of e-contracts

evolution.

72

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 EREC

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 EREC

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

73

chapter, we present ER*EC

methodology, which enhances the capabilities of EREC

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

model 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 EREC

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 EREC

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

events 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.,

74

Conformance

Remedy

Exceptions/ Clause violations

Stimuli/ changes

E-contract Design time

environment

E-contract Run-time

Environment

Figure 5.1 E-contract enactment at macro level

EREC Model

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 EREC

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,

EREC

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 EREC

model has to adapt to incorporate such occurrences and provide a remedy for continuing the contract

execution.

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.

75

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 EREC

model starts by initiating a template from

EREC

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 EREC

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.

76

5.4 Scenarios for E-contract Evolution

In general, a data model is a set of concepts to describe a database schema. EREC

model is a set

of concepts to develop an enactable e-contract. During evolution of an e-contract, the EREC

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 EREC

model. While an e-contract is being enacted, the

parties involved, the clauses, the ECA rules may change dynamically because of changes in the mini-

world 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 EREC

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.

Scenario 2: An e-contract may require one or more additional model elements (for example,

subcontracts), which are to be incorporated in the model.

EREC

Figure 5.2 EREC

Model Instantiation

77

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.

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 EREC

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

Figure 5.4 ER*EC

model

ER1*EC

ER2*EC

ERp*EC

ER*EC

Figure 5.3 Model instantiation from multiple EREC

models

ER1EC ER2

EC ERpEC

78

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 EREC

model (Fig.

5.4), referred as ER*EC

[RK 2007a]. This ER*EC

model can be thought of as union of all EREC

models

which can deal with different e-contract enactments. Formally,

ER*EC

= {ER1EC

∪ ER2EC

∪ ……………. ∪ ERpEC

}

where, p is the maximum number of available EREC

models at a given time. Here, each EREC

model is

considered as one element (or object) and the union operator keeps all the EREC

models as a set. In

case a new EREC

is developed for a specific application it will be added to the set using union. In this

way, the Global EREC

will grow.

As and when situation demands, due to changes in the e-contract enactment scenario, an

appropriate model can be instantiated from a EREC

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.

Evolution Characteristics Possible changes in the meta-model

New policies and legislations, and unforeseen

scenarios

Adding a new construct to model

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

elements

Updation in relationships and constraints

Table 5.1 Meta-model change requirements during evolution

79

Figure 5.5 Active meta-modeling of e-contracts

Meta-model

Data model

Structural

validation Behavioural

validation

Meta- ECA Rules

e-contract execution environment

Changes

Changes in the Business logic (mini-world & Run-time)

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.

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.

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

80

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

5.5.2. 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 5.5.3. 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.

81

• 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.

5.5.2 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.

82

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

83

Figure 5.6 Model instance before and after change depicting scenario 1

Adapt

Meta-Model

Model Instance

Before change

Model Instance

that implements revised

scenario

Meta-Model

Figure 5.7 Instance by migrate and merge depicting scenario 2

Migrate

Meta-Model

Current Model Instance

New model Instance

Meta-Model

Merge

Current Model Instance + New Model Instance

Figure 5.8 New model Instance by build

Build

Meta-Model

Model Instance

Before change

New Model Instance

New Meta-Model

conceptual models based on the operations result in carrying out appropriate changes at logical and

implementation levels.

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 EREC

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

84

Based on carries

exploits

plays

owns

uses

action

mini-world run-time

Rule Condition

e-contract enactment

Meta-model Role

Meta Event

triggers precondition

Parties

Figure 5.9 Meta-ECA Rule Driven E-contract Evolution

Contract Clause

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.

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 EREC

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 EREC

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 EREC

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.

85

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:

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 EREC

model. Figure

5.12 shows the new template with a sub-contract “insurance-claim”. Note that there was no sub-

contract entity in the original template (figure 5.10). This meta-event triggers the following

procedure:

On event <defaulting> begin Activate party <guarantor> Assign party <guarantor> role <borrower> Deactivate party <borrower>

End

have

Roles

Housing-Loan

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure 5.10 Standard template of Housing-Loan contract

Have

Roles

Housing-Loan

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure 5.11 Template with change of roles

86

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>

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

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.

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure 5.12 Template with addition of sub-contract

Have

has

∪

Nominee

Activities

Insurance

Company

Clauses

Parties

Roles

Housing-Loan Linked to Insurance-Claim

87

Here, the virtual-entity and virtual-role are new concepts and have to be modeled appropriately in

both meta-model and conceptual model.

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 EREC

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

EREC

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.

Have

Roles

Housing-Loan

has

Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure 5.13 Template with additional concepts

Society

∪

Human Rights

88

Figure 5.14 A high level EREC

Model for e-contract enactment

Relation Tables Static &

Dynamic Workflows

Workflow Instances

EREC Meta-Model

EREC Instance

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 EREC

model for

e-contract enactment. EREC

model instance for a specific contract can be instantiated from the EREC

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 EREC

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 EREC

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 EREC

model:

(i) meta-level evolution : in this case, the old (ith

) EREC

meta-schema modifies into a new ( jth

)

meta-schema. That is, ERiEC

���� ERjEC

(ii) instance level evolution: in this case, the old (ith

) EREC

instance is modified into a new (jth )

EREC

instance. That is, ERECi ���� ER

ECj

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 TM = < Entities, ET, RT, Parameters, σ>

89

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 TM-BE = < EntitiesBE, ETBE, RTBE, ParametersBE, σBE > as the meta-model

before evolution (BE), and TM-AE = < EntitiesAE, ETAE, RTAE, ParametersAE, σAE > as the meta-

model 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> ∈ ParametersBE) then ParametersAE = ParametersBE ∪ {<p,d>} Here, x is some value.

RemoveParameter (ParName p): removes a parameter from the model. That is,

ParametersAE = ParametersBE - {<p,y>}, where y is such that ∃ {<p,y>} ∈ ParametersBE.

AddEntity(Entity e, EntityType E): adds an entity of a specific entity type to the meta-model.

If (¬∃: < e, E> ∈ EntitiesBE) then EntitiesAE = EntitiesBE ∪ {<e, E>}.

Here, σ(e) = ∅.

RemoveEntity(Entity e, EntityType E): removes an entity of a specific entity type from the meta-

model.

EntitiesAE = EntitiesBE - {<e, E>}.

AppendEntityType(EntityType E): adds an entity type to the meta-model.

ETAE = ETBE ∪ {E}, and σ(E) = ∅.

AppendRelationshipType(RelationshipType R): add a relationship type to the meta-model.

RTAE = RTBE ∪ {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 EREC

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 EREC

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.

90

Operations Require EREC meta- level evolution

Require EREC 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)

Update database schema & workflow schema.

Additive Yes Yes (new instantiation)

Update database schema & workflow schema.

Table 5.2 Operations affecting EREC

model evolution

Changes in Evolution

Notation Changes in Database

Changes in

Workflow

Action required during run-time

Add New Party +Pn Yes Yes New workflow is to be added according to the role of new party

Delete Party - Pi Yes Yes The workflow related to party Pi is to be appropriately handled.

Party changed Pi � Pj Yes No Update Database about party Pj details.

Add new activity +An No Yes Add new workflow for An Delete an activity

- Ai No Yes The workflow related to activity Ai is to be appropriately handled.

Activity modified Ai � Aj No Yes Modify workflow

A sequence of activities are modified

Ai* � Aj

* No Yes Modify workflow

Add new clause +Ci No No Update ECA rule-base

Delete a clause - Ci No No Update ECA rule-base

Clause modified Ci � Cj No No Update ECA rule-base

A sequence of clauses are modified

Ci* � Cj

* No No Update ECA rule base

Add new entity type

+ET Yes Yes Update database schema, add new workflows, if require

Add new Relationship type

+RT Yes Yes/No Update database schema, add new workflows, if require

Table 5.3. Handling changes during e-contract evolution

91

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 EREC

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:

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 EREC

model.

As an example, consider the scenario 2 case of meta_event ‘death’. The following procedure

modifies the meta-model of Housing-loan contract.

Behaviour_sentence ::= WHEN meta_event FIRE rule’.’ Meta_event ::= meta_event_ID ‘:’ meta_event_type Rule ::= rule_ID [‘(‘ description’)’] ‘:’ [IF condition THEN] action_list

92

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 5.4.2 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.

5.5.4 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 meta-

event 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

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

93

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

model. 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 EREC

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 EREC

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 5.15. 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 EREC

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.

94

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

Active Behaviour Behavioral changes Knowledge Base (Run-time & Mini-world)

Data requirements Application Requirements

Log

Records

Logical Schema

Application

s

Application Design

Physical Design (Relations, Workflows,….)

Internal Schema

Process specifications (Logical Design)

Exceptions ECA Rules

Application specification

Structural validation

Functional Validation

Conceptual specification

Behavior validation

Workflow specifications

Figure 5.15 ER*EC

Methodology

Log records specification

Conceptual schema

(ER data model)

Mini-world

Run-time Environment

Requirements Collection and Analysis

95

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

96

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.

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.

• • •

Mini-world

Mini-world

Mini-world

Past Present Future

Meta

Model

Conceptual

Model

Logical

Model

Application

Logic &

Business

Process

Str

Con

Concept

Str

Con

Concept

Str

Con

Concept

F L TF L T

F L T

Run-time System e

Ru

AT

M

M

Run-time System e

Ru

AT

M

M

Run-time System e

Ru

AT

M

M

A C T I V E B E H A V I O U R

Behavioral

Exce

ECA

A C T I V E B E H A V I O U R

Behavioral

Exce

ECA

A C T I V E B E H A V I O U R

� Behavioral

Exce

ECA

• • • • • •

• • •

Figure 5.16 Progression for Active behaviour of evolving e-contracts

97

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

modeling 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 EREC

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

Add / Modify

Mini world

Run Time Template Evaluator

Run Time Environment

Database for workflows,

Rules, etc.

E-ADOME Workflow Engine

Workflow Generation/ Specification subsystem

ECA Rule Manager

Evolution Patterns

Run Time Template (s)

Event Handler

Template Repository

M o d e l 1

Meta ECA Rules

Model Selector

Figure 5.17 An ER*EC

architecture for evolving applications

Metadata Database

Monitor

Application evaluation policies

Application Specific components

98

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

world 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 EREC

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

99

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 EREC

model and framework developed in chapter 3, 4 and 5 are useful for modeling and

enactment of an e-contract. The ACDs in the EREC

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.

100

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.

101

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

wall 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 re-

payment 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.

102

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

organizational 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 well-

defined 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.

103

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.

6.1.2 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, forward-

and 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

104

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

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.

Execution Engine

Specification Engine

E-contract document

Activity/Clause Specification

Workflow specification Composition Model

Commitment Engine Workflow Engine

Figure 6.1 E-Contract Activity Commitment System - High level view

Database Log Manager

Dependencies Specification

Dependencies & Recovery coordinator

105

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.

106

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

predicate, 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.

107

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

execute. 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 3.

108

We say that an execution in state 2.b is weakly committed, that is, when it is or has become non-

compensatable, 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 sub-

contractor 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 non-

compensatable 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.

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.

Complete or incomplete f-termination

Execution stopped

Execution in progress

Start

Compensate

Closed null termination

Closed non-null f-termination

Incomplete weakly committed s-termination

Complete weakly Committed s-termination

Closed strongly committed s-termination

Figure 6.2 Execution stages of an activity

Retry Re-execute

Complete or incomplete s-termination

109

- 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 (a1) printing the From and To addresses on the envelope, perhaps with a printer

and (a2) 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 6.3.3.

6.3.1 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.

6.3.1.1 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).

110

- Nodes in the tree correspond to basic activities. They are denoted as a1, a2, etc.

- With each node in the tree, an st-predicate and a children execution predicate, abbreviated ce-

predicate, 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 st-

predicate of C.

Example 6.4: Figure 6.3 (a) shows a composition where Ci’s are construction activities for a product

and Ij’s are Inspection activities. After the first two stages, C0 and C1, of the construction, the

inspection I1 is carried out. Depending on the result, say quality of the product after C1, C2 is carried

out if possible, and C2′ or C2″ otherwise, in that order. This will be the ce-predicate at I1. Only the

inspection I2 after C2 is shown. The st-predicate for each Ci will be the guidelines to be followed for

that construction. The st-predicate for each Ii will be the acceptable results of the things to be

checked in that inspection.

6.3.1.2 Execution

- An execution of activity ai is denoted ai.

- 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 C0, C1, I1 and C2′ with s-terminations and C1 and I2 with

f-terminations.) Otherwise, that is, if only the activities from the root to some non-leaf node have

been executed (for example, only C0, C1 and I1) and/or the executions of some activities are not

complete (C2′ 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 ai, the selection of the s-terminated child of ai

satisfies the ce-predicate currently specified for ai in C.

- Both the st-predicate and the ce-predicate at each node ai may be changing as the execution of

subsequent activities of C proceeds.

111

- Partial execution of C will be represented by a path from the root a1 to some node ai in the tree,

and will be denoted (a1, ..., ai), 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 ai, called the suffix of C from ai,

denoted C[i]. The subcomposition will contain the subtree of C rooted at ai, with the st-predicate

and ce-predicate of ai adjusted according to the execution C[1,i], and the st-predicate and ce-

predicate of all other nodes in the subtree being the same as in C.

6.3.1.3 Transactional Properties

We first define transactional properties for basic activities.

- An execution ai 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 ai is atomic if every execution of ai guarantees either a complete s- termination or

the null termination.

- Each activity ai in C may first be weakly committed, and then strongly committed some time after

its s-termination.

- Once ai 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 ai is

weakly committed, all activities that precede ai 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 ai is executed atomically. Thus an incomplete f-

termination of ai 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.

C2′ C2

C1

I1

C0

C2′ C2″ C2

C1

I1

Figure 6.3 (a) A composition, (b) An execution of the composition,

(c) A closed c-tree for the execution-tree

I2

C0

(a) (b) (c)

I1

I2

C2′

C0

C1

I2

C2

112

• 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.

6.3.1.4 Implementation Issues

(a) Point of Commitment

The execution of an activity ai 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 ai.

(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 aj, for some j ≤ i, where ai is the latest activity

that has been or being executed. If aj has to be compensated, then all activities in the execution

following aj are also compensated, and a different child of aj-1 is chosen with possibly an updated ce-

predicate at aj-1. If aj is retried, then, after retrying, aj+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 (aj, …, ak-1) are

retried and those in (ak, …, ai) 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 C2 was executed after I1, and I2 fails. It

may be decided that the product be sent back to C1 for some adjustment and inspected, and the

options C2′ and C2″ explored. This would amount to rolling back I2 and C2, and re-executing C1 and I1,

each with adjusted st-predicate. Here the adjusted ce-predicate for I1′ will have only C2′ and C2″

options. Suppose C2′ is tried and the execution was successful. Then the execution-tree will contain

all the nodes except C2″, with C2 and I2 as f-terminations. This is shown in Figure 6.3(b). Here, nodes

for the f-terminated activities are shaded.

113

In the above argument, the first activity ak+1 that needs to be compensated is determined after re-

executing its preceding activity ak.. It is quite possible, in some cases, that ak+1 is determined even

before re-executing its predecessors. It is also possible that for some of the activities in (aj+1,…, ak),

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 am is strongly committed, then j > m,

and if n is the largest index such that an is weakly committed, then k+1 > n. This follows since, by the

definitions of strong and weak commitments, executions of activities up to am cannot be retried and

those up to an cannot be compensated. In the figure, an is not shown. It will be between am and ak+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.

aj

ai Compensate Weak

Commit

Strong

Commit

Compensate √ √ √

Weak Commit × √ √

Strong Commit × × √

Table 6.1 Dependency-Table

a1

Re-execution point

Last strong commitment

point

Compensated part

Re-tried part

Adjusted part

Figure 6.4 Partial backward-recovery in the Path model

am

al

aj

ak

ai

Strongly Committed part

Weakly Committed part

114

The relative positions of the nodes ai and aj are as in Figure 6.4, that is, ai is a descendent of aj.

Each ‘√’ entry in the table describes that the specified action in the execution of ai requires the

specified action in the execution of aj, and also the dependencies where the roles of ai and aj 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 aj is known only after ai 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 ai is

weakly committed, then aj must be weakly committed too if it has not been done already. The

same applies to strong commitment.

o If aj is compensated, then ai 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 property-

predicates 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 ak 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 ak 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 ai change the st-

predicates of some other activities.

115

P1

Figure 6.5 Procurement Example

P2

P3

P4

P5

P6

P7

P8

(The top half of Figure 6.4 shows the weak and strong commits triggered by the compensation or re-

execution of the activities in (aj, …, ai).)

The execution of an activity ai 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 ai.

IV. Dependencies constraining the beginning of an execution of an activity can also be defined. For

example, for activities aj and descendent ai possible dependencies are: ai cannot begin execution

until aj (i) s-terminates, (ii) weak-commits, or (iii) strong-commits. Note that our composition model

assumes that the execution of ai cannot begin until the execution of aj 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,

116

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

6.3.2 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.

117

6.3.2.1 Composition

Here also, a composition C is a tree and it is a part of a higher level composition U. A st-

predicate 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 ce-

predicate 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.

6.3.2.2 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.

6.3.2.3 Transactional Properties

The following definitions refine those given for the path model.

- We say that the execution ai is locally compensatable if the execution can be undone to get the

null termination. We also define another notion: ai is compensatable relative to C if either ai is

locally compensatable or it can be compensated by executing a compensating activity within C.

- Similarly, an execution ai is locally retriable if there is a re-execution that will yield an s-

termination. And, ai is retriable relative to C if either ai is locally retriable or additional

activities can be executed in C to get the effects of an s-termination of ai.

118

- An execution ai 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: ai 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 ai 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 ai is not possible in some execution, then (that execution of ai 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.

6.3.2.4 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

Re-executed part

Compensated part

Figure 6.6 Partial backward-recovery in the Tree-model

119

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 ai and aj, 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 re-

execution of P4-B, P5-B and P6-B.

6.3.3 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

Figure 6.7 Procurement example with two plants

P4-A

P5-A

P6-A

P4-B

P5-B

P6-B

P3

120

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.

6.3.3.1 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.

6.3.3.2 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.

Figure 6.8 Two-level composition for the Procurement example

P4-A

P5-A

P6-A

P4-B

P5-B

P6-B

P3

P7

P8

P1

P2

121

6.3.3.3 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 forward-

recovery. 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 ai is also compensatable relative to U even if ai is not

compensatable relative to C. By this, we mean that the effects of ai can be compensated either by

compensation of C by C′ or by a compensating activity ai′, 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.

6.3.3.4 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 ai is the composition of an activity of C. Let ai, C and U be the respective executions. We have

defined the compensatability and properties of ai to be relative to C. Similarly, compensatability and

retriability of C will be relative to U.

122

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 a2 is non-

compensatable, 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 a2 itself is

not compensated the composite activity containing a2 is compensated.

Similarly, the commitment properties at the two levels are also independent of each other. We

give two examples. (1) Activity ai 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 ai 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.

6.3.3.5 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 ai 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 ai is strongly committed then C’ has to be compensated.

123

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

functional 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

Figure 6.9 An example of Multi-level model

M11 M12

M113

d e f

b c

a

124

Consider the multi-level composition model shown in Figure 6.9. Assume that the low-level node e

(in M113) 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 M113 is re-executed, by changing the ce-predicate of M11. Note that though the

atomic activity e is strongly committed in the previous executions, the composite activity M113 is re-

executed. 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 EREC

models and (iii) workflows defined over inter- and intra-

organizational 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

Composition model support

Different executions of an activity might

have different characteristics

Attributing transactional properties to the execution

of activities instead of activities themselves.

An activity has been executed successfully

or not may not be know until some other

subsequent activities have been executed.

Weak commit and strong commit ensures this

dependency

When execution of an activity is not

successful, then executions of some other

activities have to be adjusted.

Compensation and re-execution properties of an

activity transaction are useful in adjusting other

activities’ execution.

Guarantee termination for in-complete

executions

Attributing compensation and retriability properties

to incomplete executions also.

Monitoring Successful termination of

activities

Attributing a st-predicate and ce-predicate to an

activity.

Tracking the activity executions Monitoring Execution-tree derived from a

composition.

Many interdependent activities and clauses

govern activities execution.

Relating interdependencies to execution states of

the activities.

Backward and forward recovery of

activities execution at each level

independent of its descendent levels

Atomicity defined for executions of composite

activities of any level ensures the backward and

forward recoveries

Supporting composite activities

commitments

Tree model helps in handling composite activity

commitments with the transactional properties as

defined similar to path model.

Supporting higher- activity commitments,

including contract itself as a whole.

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

125

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

126

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.

127

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.”.

128

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. Termination-

m 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.

Strong Commit

Retrys

Figure 7.1 Different terminations

Weak commit Try to Compensate

Re-executions

Start execution

Begin

Termination-1

Termination-m, m ≥ 1

wc-termination-1 f-termination

wc-termination-n, n ≥ 1

sc-termination

Compensatable and Re-executable

Non-compensatable and non-re-executable

Non-compensatable but retriable

Non-compensatable and non-re-executable

Payment

enabled

points

129

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 a1, a2, etc. There are two

aspects – cost of execution of an activity ai (i) for ai 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) ai. We look at both of them.

We use cost(ai) and payment(ai) to denote (i) and (ii), respectively.

Cost:

- A cost may be associated with each execution related to ai. The total cost cost(ai) will depend

on the number of executions related to ai.

- 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 ai 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(ai) will keep going higher.

- Therefore, the final cost of execution, cost(ai), will depend on the number of (re-executions

and hence) terminations, and will be known to ai only when its execution is strongly

committed.

Payment:

- Payment for ai, namely, payment(ai), may not directly depend on the number of executions

related to ai.

- 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(ai) may be

known earlier. For example, if the charge is zero for a compensated ai, it can be known even

before the compensation is complete, and if re-execution costs are not charged to C, then

payment(ai) can be known on weak commitment of ai.

- On the other hand, payment(ai) could be fixed even before the execution of ai 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.

130

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 ai may be enabled either when ai 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 ai is compensated by execution ai′ of a compensating activity, then both ai and ai′

will appear in the execution-tree, and costs may be attributed to them individually.

- Similarly, if re-trying of ai is done by executing additional activities, their executions will also be in

the execution-tree and costs can be assigned to them.

131

C0

C2′ C2″ C2

C1

I1

Figure 7.2 A payment-made-tree for the composition

- 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 I2. This is shown in Figure 7.2. Comparing with the execution-tree

described in Figure 6.3(b) (chapter 6), payment for I2 has not been done yet, and payment for C2″ has

also been done even though only one of C2′ or C2″ is to be executed. The payment for the non-

executed 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.

132

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 7.1

Activity Specification Execution Commitment Aspect Terms of

Payments 1. Material acquisition 1a. Acquisition of additional

material

Materials gathered

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 3a. Doing slight fixing 3b. Demolishing wall 3c. Building 30cms thick wall

Wall constructed

4. Inspection-II � Slight fixing required � Wall not strong enough � � Construction done in

order

Re-execute 3 (3a) Compensate 3 (3b), retry 1 (1a), & 2, and re-execute 3 (3c) and 4 Strong commit 1-4

Payment-2 (for 3, 4, & re-executions of 1-4, if any) due

5. Painting the wall 5a. Do undercoat 5b Do overcoat

Undercoat and one overcoat

Do not start until Payment-1 and Payment-2 received

6. Inspection-III � Very bad paint job � Another overcoat

needed � Job done in order

Re-execute 5. (5a and 5b) and 6 Weak commit 5; Retry 5 (5b), 6. Strong commit 5,6

Payment-3 due

Table 7.1 Some activities and payments of an example: construction and painting job of a wall

133

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 ais,

payment(ai) of each ai (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 ai 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 ai 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 ai.

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:

134

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

activity) 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.

135

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 EREC

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 EREC

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 EREC

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 EREC

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 EREC

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-

136

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

model 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.

8.2.1 EREC

meta-model

The EREC

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

model 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 context-

independent 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

137

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 EREC

model

develops a novel framework for conceptually modeling e-contracts. The EREC

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.

8.2.2 EREC

Framework and Architecture

Our EREC

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 EREC

approach presented in this thesis helps in linking conceptual model and the contract

process flow for e-contract enactment.

138

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.

8.2.4 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 sub-

contract 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

139

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 EREC

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, EREC

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 EREC

model. The EREC

model component takes these specifications as

inputs and generates EREC

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 EREC

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

relationships.

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

conditions 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.

8.3.1 Other pertinent approaches for e-contracts

As seen above, our perspective is to facilitate database supported e-contracts. However, a full-

fledged 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.

140

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. 21-66, 1998.

[A2006] S. Angelov, Foundations of B2B electronic contracting, Ph.D Thesis, Technische

Universiteit Eindhoven, Eindhoven, 2006.

[A2009] K. Anushree, On extracting, enacting and modeling e-contracts, M.S. by Research

Thesis, IIIT-Hyderabad, August 2009.

[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. 574-581,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. 487-524, 2002.

[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. 93-103, 2002.

[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, 2003.

[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. 43-69,

2000.

[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. 603-608, 2003.

[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. 218-234, 2000.

[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, 2007.

[ATG2005] S. Angelov, S. Till and P. Grefen, Dynamic and Secure B2B E-contract Update

Management, Proc. ACM Conference on Electronic Commerce, Canada, pp. 19-28,

2005.

[BCN1992] C. Batini, S. Ceri, S.B. Navathe, Conceptual Database Design––An Entity-

Relationship Approach, The Benjamin/ Cummings Publishing Company Inc,

Redwood City, California, 1992.

[BHJ 2009] J. Biba, J. Hodik, M. Jakob, Contract observation in web services environments. In:

Proceedings of International Workshop on Service-Oriented Computing: Agents,

141

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,

www.forrester.com/research/Document/Excerpt/0,7211,42419,00.html.

[BPG2005] S. Bhiri, O. Perrin and C. Godart, Ensuring Required Failure Atomicity of

Composite Web Services, WWW 2005, pp. 138-147, 2005.

[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. 132-149, 1994.

[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, 2005.

[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, 1996.

[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, 2003.

[CD 1996] Q. Chen and U. Dayal, A Transactional Nested Process Management System. Proc.

12th Intl. Conf. on Data Engineering,pp.566-573, 1996.

[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. 606-617,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, 2001.

[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), 193–216, 2002.

[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, pp159-184.

[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. 174- 182, Hong Kong, 2000.

[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), 2000.

142

[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.93-120, 2001.

[CM2001] J. Cole and Z. Mlosevic, Extending Support for Contracts in ebXML, IEEE

Computer Society, pp.119- 127, 2001.

[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), 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: 194-203, 1990.

[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, 103–112, 1991.

[CS 2008] P. Chakravarthy and M. Singh, Incorporating Events into Cross-organizational

Business Processes, IEEE Internet Computing, 12(2), pp. 46-53, 2008.

[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.108-125, 2004.

[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, 1999.

[D1999] A. Daskalopulu, Logic-Based Tools for the Analysis and Representation of Legal

Contracts. Ph.D thesis, Imperial College London, 1999.

[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), 2001.

[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, 2003.

[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, 2001.

[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. 469–485, 2002.

[DJC1995] Department of Justice Canada. A survey of legal issues relating to the security of

electronic information, Technical Report, Department of Justice, 1995.

[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.771 – 777, 2001.

143

[DS1997] A. Daskalopulu and M. J. Sergot, The Representation of Legal Contracts, AI &

Society, 11(1/2), pp. 6-17, 1997.

[DML 1991] U.Dayal, Meichun Hsu, R. Ladin, A Transactional Model for Long-Running

Activities. VLDB 1991: 113-122, 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, 2008.

[DTM2002] A. Daskalopulu, T. Dimitrako and T. Maibaum, Evidence-based Electronic Contract

Performance monitoring, INFORMS Journal of Gorup Decision and Negotiation,

2002.

[DW1995] F. Dignum and H. Weigand, Modeling communication between cooperative

systems, Proc. of CAiSE’95, pp. 140-153, 1995.

[ebXML2000] Business Process Project Team, The ebXML Business Procedss Meta-model

Second draft 6/23/00, www.ebxml.org/specdrafts/Busv2-0.pdf.

[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, 2004.

[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 290-305, 2006.

[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), 2006.

[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, 1999.

[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.277-290, 2000.

CrossFlow Web site. http://www.crossflow.org.

[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, 1998.

[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. 119-153, 1995.

144

[GM2006] G. Governatori and Z. Milosevic, A Formal Analysis of a Business Contract

Language, International Journal of Cooperative Information Systems, 15(4),

pp.659-685, 2006.

[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. 340-349, 2003.

[GV2006] P. Grefen and J. Vonk, A Taxonomy of Transactional Workflow Support,

International Journal of Cooperative Information Systems, 15, 1, 87-118, 2006.

[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.316-333, 2001.

[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, 2004.

[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. 4078 -4087, 2001.

[HYK1996] P. C. K. Hung, H. Pl. Yeung and K. Karlapalem, CapBasED-AMS: A capability-

based and event-driven activity management system, in: Proceedings of the ACM

SIGMOD Conference on Management of Data, Montreal, Canada, 1996.

[IJK2004] M. Iwahihara, H. Jiang and Y. Kambayashi, An Integrated Model of workflows, e-

Contracts and Solution Implementation, ACM Symposium on Applied Computing,

pp.1390 – 1395, 2004.

[IST2009] CONTRACT deliverable D4.1, Web Services framework for contract based

computing, IST CONTRACT PROJECT, www.ist-contract.org.

[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. 62-69, 1999.

[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. 2224 (Springer-Verlag) pp. 193-207, 2001.

[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. 89-105, 2005.

[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. 110-121, 2000.

[KN2006] T. Kwok and T. Nguyen, An Enterprise Electronic Contract Management System

using Dual XML and Secure PDF documents, 10th IEEE International Enterprise

145

Distributed Object Computing Conference Workshops, IEEE Computer Society, p.

57, 2006.

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

[KZ2002] A. Kumar and J. L. Zhao, Workflow support for electronic Commerce applications,

Decision Support Systems, 32, 265 – 278, 2002.

[L1998] R. M. Lee, A Logic Model for Electronic Contracting, Decision Support Systems,

4(1), pp. 27-44, 1998.

[L1998b] R. Lee, Towards Open Electronic Contracting, EM – Electronic Markets, 8(3), pp.3-

8, 1998.

[L2001] F. Leymann, Web Services Flow Language (WSFL 1.0), IBM Corporation, 2001.

[L2005] P. F. Linington, Automating support for e-business contracts, International Journal

of Cooperative Information Systems, 14 (2&3), pp.77-98, 2005.

[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, 1997.

[MB1995] Z. Milosevic and A. Bond, “Electronic Commerce on the Internet: What is still

Missing?”, Proc. of 5th conference of the Internet Society, pp 245-254, Honolulu,

1995.

[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. 39–50, 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. 59-68, 2001.

[M1983] M. Morgenstein : Active databases as a paradigm for enhanced computing

environments, In Proceedings of the International Conference on Very Large

Databases, 1983.

[MS2005] A. U. Mallya and M. P. Singh, Modeling exceptions via commitment protocols, In

Autonomous Agents and Multi-Agent Systems, ACM Press, pp. 122-129, 2005.

[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.211-220, 2006.

[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. 103-110, 2003.

146

[PDK2005] A. Paschke, J. Dietrich and K. Kuhla, A logic based SLA Management Framework,

In 4th Semantic Web Conference (ISWC 2005), 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. 174-189, 2007.

[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) 93-

129.

[P 2003] M. P. Papazoglou, Web Services and Business Transactions, World Wide Web:

Internet and Web Information Systems, 6, pp. 49–91, 2003.

[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. 1995.

[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. 57–71, 2007.

[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, 103-108, 2007.

[RK 2008] P. Radha Krishna and K. Karlapalem, Electronic Contracts, IEEE Internet

Computing, vol. 12, No. 4, pp. 80-88, 2008.

[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, 2004.

[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,

363 – 387, 2005.

[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.

426–434, 2005.

[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. 1104-

1113, 1980.

[S1998] M. T. Schmidt, Building workflow business objects, object-oriented programming

systems languages applications, OOP-SLA’98 Business Object Workshop,

London, pp. 64-76, 1998.

[S1999] A. W. Scheer, ARIS-Business Process Modeling, Springer, Berlin, 1999.

147

[S2002] 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. 349-353, 2002.

[Sc2002] M. Schoop, Electronic markets for architects – the architecture of electronic markets,

Information Systems Frontiers 4(3), pp. 285-302, 2002.

[SABS2002] H. Schuldt, G. Alonso, C. Beeri, H.J. Schek, Atomicity and Isolation for

Transactional Processes, ACM Transactions on Database Systems, 27, pp. 63-116,

2002.

[T2001] S. Thatte, XLANG - Web Services for Business Process Design, Microsoft

Corporation, 2001.

[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, 2004.

[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. 59-75, 1991.

[V1999] D. Verma, Supporting Service Level Agreements on IP Networks, Macmillan

Technical Publishing, 1999.

[V2003] K. Vandana, Using Multi-tier Contract Ontology to Model Contract Workflow

Models, Dissertation, Stockholm University and the Royal Institute of Technology ,

Stockholm, SWEDEN, 2003.

[V 1991] K. Vidyasankar, Atomicity of Global Transactions in Distributed Heterogeneous

Database Systems, Proc. of the DEXA-91, pp. 321-326, 1991.

[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,

300-317, 2007.

[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. 135-142, 2008.

[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. 301-313, 2009.

[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 462-469, 2004.

148

[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, 2007.

[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): www.w3c.org

[WFMC2000] Workflow Management Coalition. Workflow Standard – Interoperability Wf-XML

Binding, WFMC-TC-1023, 2000.

[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. 434-439, 2006.

[WH 2002] H.Weignad andW-J.V.D. Heuvel, Cross-organizationalworkflowintegration using

contracts, Decision Support Systems, 33, pp. 247–265, 2002.

[WSCI2002] Sun Microsystems, Web Service Choreography Interface (WSCI), Version 1.0,

2002.

[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, 2003.

[WS-C2002] IBM Corporation, Web Services Coordination (WS-Coordination), August 2002.

[WS-T2002] IBM Corporation, Web Services Transaction (WS-Transaction), August 2002.

[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), 2001.

[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. 13-23, (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. 584–600, 2003.

149

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

contracted.

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, (C-

iii) 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, (U-

ii) 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.

150

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 EREC

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

151

(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.

have

Bank - Customer

Inter-Bank

Incomplete work

Hold

payment

Revisit Again

Wait

Send Clarification

has

Bank

Supplier

have

Payments

Parties

∪

Builder

Exceptions

Customer

Relations between entity types Contract Events

Relations between instances of Output events for exceptions

different entities Input events for exceptions

Insurance

Company

Builder-Customer

Builder -Supplier

Insurance Company-Customer

No

Stock

I-iii

I-v

I-Vii

I-iv

I-vi

B-i B-ii B-iii

B-iv

B-vii B-viii

Time Limit

Crossed Reject

No Sufficient Balance

Figure A.3 EREC

model for e-contract House-Building

Design not upto the mark

refer

House-

Building

I-ii I-i

CL-a CL-b

CL-c CL-d

CL-e CL-f

CL-g CL-h

B-i B-vi

C-i C-ii C-iii

C-iv C-v

U-i U-ii U-iii

U-iv U-v U-vi

S-i S-ii S-iii

152

Arrange the

goods

Ship the

goods Order

Acceptance

Time limit crossed

No stock

Start End

Figure A.5 Workflow for Supplier activities

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.

Figure A.4 Workflows for Bank Activities

Scrutinize

the loan

application End

Fund

Transfer

Start

Not Satisfactory

Assess

the loan

limit

Undertake the

mortgage

Sanction

the loan

Release the

payment

Check the

work progress Start End

Receive monthly payment Start End

153

.

Party <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> <Activity Number> C-i </Activity Number> <Description> monitor the work carried out by the builder </Description> <Start Date> 01.04.2009 </Start Date> <End Date> 30.08.2009 </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> 01.05.2009 </Start Date> <Recurring Time> 30 days </Recurring Time> <End Date> 03.04.2019 </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

154

We considered an example drawn from the contract for building a house that concerns with

“housing-loan” to illustrate the adaptability of EREC

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 EREC

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 EREC

models for the occurrence of meta-events defaulting,

death/disablement and road expansion.

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

Figure A.6 ACD for fund transfer activity

Party1 gives debit instruction to its bank A

and party 2

Bank A debits Party 1

account

Bank A send to clearing

centre for clearance

Clearing instructions will go to Bank B

(party 2’s bank)

Bank B credits to

Party 2’s account

Bank B inform to Party 2

L

L

155

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.

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 EREC

model. Figure

A.9 shows the new template with a sub-contract “insurance-claim”. Note that there was no sub-

contract 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.

have

Roles

Housing-Loan

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure A.7 Standard template of Housing-Loan contract

Have

Roles

Housing-Loan

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure A.8 Template with change of roles

156

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.

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:

has

∪ Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure A.9 Template with addition of sub-contract

Have

has

∪

Nominee

Activities

Insurance

Company

Clauses

Parties

Roles

Housing-Loan Linked to Insurance-Claim

Have

Roles

Housing-Loan

has

Bank

Guarantor

Activities

Insurance

Company

Clauses

Borrower

Parties

Figure A.10 Template with additional concepts

Society

∪

Human Rights

157

P1

Figure A.11 Procurement Example

P2

P3

P4

P5

P6

P7

P8

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.

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

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

158

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

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

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

Figure A.12 Procurement example

with two plants

P4-A

P5-A

P6-A

P4-B

P5-B

P6-B

P3

Figure A.13 Two-level composition

for the Procurement example

P4-A

P5-A

P6-A

P4-B

P5-B

P6-B

P3

P7

P8

P1

P2

159

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

execution 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.

160

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.

Activity Specification Execution Commitment Aspect Terms of

Payments 1. Material acquisition 1a. Acquisition of additional

material

Materials gathered

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 3a. Doing slight fixing 3b. Demolishing wall 3c. Building 30cms thick wall

Wall constructed

4. Inspection-II � Slight fixing required � Wall not strong enough � � Construction done in

order

Re-execute 3 (3a) Compensate 3 (3b), retry 1 (1a), & 2, and re-execute 3 (3c) and 4 Strong commit 1-4

Payment-2 (for 3, 4, & re-executions of 1-4, if any) due

5. Painting the wall 5a. Do undercoat 5b Do overcoat

Undercoat and one overcoat

Do not start until Payment-1 and Payment-2 received

6. Inspection-III � Very bad paint job � Another overcoat

needed � Job done in order

Re-execute 5. (5a and 5b) and 6 Weak commit 5; Retry 5 (5b), 6. Strong commit 5,6

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 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 A.3 Costs for execution of the activities described in Table A.2

161

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.

EREC

model: a conceptual model instantiated from EREC

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 EREC

(or ER*) meta-model with constraints for a specific contract.