iiit hyderabadweb2py.iiit.ac.in/publications/default/download/... · iv acknowledgments first and...
Post on 02-Oct-2020
0 Views
Preview:
TRANSCRIPT
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.
top related