consistency and failure handling in electronic...

CONSISTENCY AND FAILURE

HANDLING IN ELECTRONIC

CONTRACTS

Thesis submitted in partial fulfillment

of the requirements for the degree of

MASTERS OF SCIENCE BY RESEARCH

in

COMPUTER SCIENCE

by

NISHTHA MADAAN

201203001

[email protected]

CENTER FOR DATA ENGINEERING

International Institute of Information Technology

Hyderabad – 500032, INDIA

May 2016

Copyright© NishthaMadaan, 2015

All Rights Reserved

International Institute of Information Technology

Hyderabad, India

CERTIFICATE

It is certified that the work contained in the thesis, titled “Consistency and Failure Detection in E-

Contracts” by NishthaMadaan, has been carried out under my supervision and is not submitted

elsewhere for a degree.

---------------- ----------------------

Date Adviser: KamalakarKarlapalem

---------------- ---------------------------

Date Co-Adviser: Radha Krishna P.

Dedicated to my family.

Acknowledgements

I am using this opportunity to express my gratitude to everyone who supported me throughout

the course of my research work from finding a research problem to the process of approaching

the problem in various ways and further getting a solution that works.

I deeply thank Dr. Kamal Karlapalem, my advisor who never gave up on me be it my gaps in

reading a research paper or a gap in my understanding of the problem. He has always helped

me in filling those gaps by portraying the problem into a real life scenario making it easily

understandable. His silent motivation and encouragement has inculcated in me the idea of self

confidence that “You can do it”. This feeling is very important for a person to be able to

believe oneself that you can do something and you can solve the research problem at hand and

thereby has been the biggest motivating factor for me which kept me moving. I would also

extend my gratitude towards Dr. Radha Krishna, my co-advisor who has always been available

for answering all my queries and has helped me in improving my writing skills. He has been

very kind in entertaining some very naive ideas from me and later on defining a refined version

of it. I would also thank my sister for her constant support be it my frustrations about the

courses issues or some research blues she has been there all the times by my side listening to

every small issue. I would also thank my family and friends for their constant support which

has brought me here and have always taught me to never look back at the failures and chase

upcoming goals.

Abstract

E-contracts are textual documents describing various contractual assignments/tasksand

dependencies among contractual elements such as parties, activities, clauses, exceptions and

payments. The dependencies and constraints in e-contract can be differently stated in different

parts of large documents. Inconsistencies in the e-contract document, particularly the contract

activities and clauses specification, may lead to failures during contract enactment. The thesis

work focuses on (i) ensuring consistency at specification level, (ii) failure detection through

consistency checking and their handling at execution levelduring e-contract enactmentand(iii)

failure preventionby assessing the possible failuresthat may arise due to inconsistent task

specifications (leads to violation of constraints during execution) and thereby avoid from

abnormal termination of workflow execution.To determine the consistency of an e-contract

document, we construct two graphs namelySentence Dependency Graphand Contract Element

Dependency Graphfrom dependencies existing in the contract document. We also develop a

methodology usingthese two graphs for consistency detection in an e-contract. We also

present an evaluation of our approach on a sample contract document and come up with

visualization for showing dependencies of contract elements which are present in the document

contract.

Since contracts may evolve over a period of time, an e-contract enactment system should adapt

to changing requirements. For this purpose, we use the concept of Meta Execution

Workflowsfor e-contract enactment. Meta execution workflows allow modification of the

workflow execution engine process to support design and run time changes. In this thesis, we

present a framework to execute workflows in a seamless manner by handling exceptions and

failures, and thereby ensuring consistency during e-contract execution. Our framework, using

meta execution engine, representsthe workflow execution engine and other components of

WFMSin terms of workflows. Our system allows specification, instantiation, modification and

execution of workflows on-the-fly with less human intervention even when failures occur.We

also provide design and implementation aspects of Failure Resilient Workflow System

(FRWS)and demonstrate its applicability for different failure scenarios of anexample e-

contract.Though the proposed solution is specific to e-contract enactment, it can be made

generic and applied to other domains where the business processes are modeled using

workflows.

Contents

Chapter 1 Introduction .......................................................................................................................... 12

1.1 Research Problem ....................................................................................................................... 12

1.1.1 Inconsistencies in an e-Contract………………………………………………………..…13

1.1.2 Exceptions and failures that arise during contract enactment……….………………….…15

1.2 Scope of Thesis........................................................................................................................... 16

1.3 Thesis Outline ............................................................................................................................. 17

Chapter 2 Related Work ....................................................................................................................... 18

2.1 E-Contract .................................................................................................................................. 18

2.2 Workflow Management System ................................................................................................. 19

2.3 Document level E-Contract inconsistencies ............................................................................... 19

2.4 Execution level E-Contract Failures………………………………………………………….. 20

2.5 Summary……………………………………………………………………………………….21

Chapter 3 Consistency of an E-Contract……………………………………………………………...22

3.1 Problem Description…………………………………………………………………………...22

3.2 Seller-Carrier-Buyer E-Contract................................................................................................. 23

3.3 Methodology for ensuring consistency………………………………………………………...26

3.3.1 Semantic Dependency Check…………………………………………………………..…27

3.3.1.1 Semantic Dependencies in text………………………………….…………………..30

3.3.2 Contract Elements Dependency Check ............................................................................... 34

3.3.3 Visualization ……………………………………………………………………………...40

3.4 Summary……………………………………………..………………………………………...41

Chapter 4 Failures in execution of an E-Contract ................................................................................ 42

4.1 Problem Description ................................................................................................................... 42

4.2 Background : Meta Execution Workflow ................................................................................... 43

4.3 Functional Aspects ..................................................................................................................... 44

4.4 Design Aspects ........................................................................................................................... 45

4.5 Implementation Aspects ............................................................................................................. 50

4.6 Comparison of traditional WFMS and FRWS ........................................................................... 63

Chapter 5 Failure Prevention ................................................................................................................ 65

5.1 Problem Description ................................................................................................................... 65

5.2 Methodology to assess failure .................................................................................................... 65

5.3 Summary .................................................................................................................................... 68

Chapter 6Case Study………………………………………………………………………………. ..69

6.1 The Example…………………………………………………………………………………...69

6.2 Summary ……………………………………………………………………………………….80

Chapter 7 Conclusion and Future Work……………………………………………………...............81

Bibliography………………………………………………………………………………………... ..83

List of Figures

Figures

3.1 An overview of the procedure for ensuring a consistent contract….………………….27

3.2 Representing Semantic Dependency Graphs for Sentences…………………….……..28

3.3 Algorithm for consistency check in SDG……………………………………………..30

3.4 Representing sentences of SDG……………………………………………………….34

3.5 Algorithm for constructing EDG………………....……………………………………35

3.6 Dependency Graph for Parties…………...…………………………………………….37

3.7 Dependency Graph for Exceptions…………………………...………………………...37

3.8 Dependency Graph for Activities...………………...………………………………......38

3.9 Dependency Graph for Clauses…..………………..………………………………..….38

3.10 Algorithm for constructing CEDG………..…………………………………………....39

3.11 Depicting dependencies of between different contract elements……………………....40

3.12 Depicting a CEDG graph showing dependency of a sentence………………………...41

4.1 MEW driven Workflow Execution Engine for FRWS………………………………...43

4.2 State Diagram of Workflow Instances………………………………………………….45

4.3 High level Components of FRWS……………………………………………………...46

4.4 Representing workflow specifier and manager as workflows for graduate college...….48

4.5 A sample MEW……………………………………..………………………………….49

4.6 Tasks of buyer seller contract…………………………………………………………..52

4.7 Representing workflow specifier and manager as workflows for seller-buyer……..…..53

4.8 Matchmaker Algorithm……………………………………………………………..…..56

5.1 Representing workflow execution engine………………………………………………66

5.2 Algorithm for assessing failures………………………………………………………...67

6.1 Extended ER contract diagram for STC Contract………………………………..…….69

6.2 Interface for adding a new MEW…………………………………………………...….70

6.3 Interface for adding a new user workflow……………………………………………...72

6.4 Representing tasks in database added from xml file……………………………..……..74

6.5 PSA table in database…………………………………………………………………..74

6.6 Representing coupling of a task from user workflow with MEW tasks……………….75

6.7 Representing failures in execution……………………………………………………...76

6.8 Interface representing failures in execution………………………………………….....77

6.9 Interface representing failure handling steps…………………………………………..77

6.10 Representing result of Retrying a failed instance………………………………………78

6.11 Changing PSA…………………………………………………………………………..79

6.12 Changing Capabilities…………………………………………………………………...79

List of Tables

Table

3.1 Parts of Speech Tags…………………………………………………………………...29

3.2 Sentence Dependency table with POS tags of the words……………………………...32

3.3 Dependencies in the STC Contract…………………………………………………….36

4.1 Categories of failures handled by execution engine……………………………………51

4.2 PSA and their capabilities for seller buyer e-contract………………………………....54

4.3 Task, Conditions and Events for Buyer Seller E-Contract………………………….....55

4.4 Representing database updates at runtime for buyer seller E-Contract……….……….53

4.5 Representing failures encountered in the system………………..……………………..58

4.6 Differences between traditional WFMS and MEW driven WFMS…………..……….64

5.1 Representing execution log and fetched dependencies………………………………...67

12

Chapter 1

Introduction

In recent days, there has been a great increase in number of people switching to online

transactions and in turn increasing business to customer (B2C) interactions and business to

business (B2B) interactions. Consider a scenario of online shopping website where seller

displays the products online for sale thereby facilitating buyers to view and order products

online. Buying a product from the website where products have been placed for sale by seller

implies that buyer andseller agreeing (or signing) on the purchase and the return policy

contract. These contracts are specified implicitly or explicitly (as terms and conditions),

which need to be understood and processed to ensure consistent execution of

workflows/tasks as per the satisfaction of business policies and the users expectations.Thus,

these technological advances necessitatesdiscovery of new tools and methods to automate the

task execution of contracts which weredifficult to handle with conventional contracting

approaches. In the conventional contracting, (i) the parties need to go through a lot of paper

work for performing various activities and check dependencies between contractual entities,

(ii) any deviation from the service level agreement (SLA) will be known only when it is

raised by a human, which results in clause violations, exceptions and failures during the

contract enactment, and (iii) most importantly the first time clause violations would require

thoughtful processing that takes time to be done by humans; whereas our solution does

substantial preprocessing for potential inconsistent states and ways to resolve them ahead of

execution.

E-contract can beviewed as a computerized version (or an automated form) of a tedious

conventional contract. The main elements of an e-contract are Parties, Activities, Clauses,

Payments, Exceptions and Commitments. Parties are the organizations or people involved in

the e-contract. Therefore, parties play a very crucial role in the contract enactment. Activities

represent the tasks (or e-services) to be executed during the enactment process. Clauses

describe the restrictions on the execution of activities. Exceptions may arise due to

incomplete or partial fulfillment of clauses. Payments state how the payments are to be made

when the obligations are met. Commitments include completion of the activities by the

parties as per the agreed terms and conditions and successful closure of e-contract enactment.

1.1 Research Problem

The thesis addresses the following two research problems:

1. Detection of inconsistenciesin an e-contract

2. Handling of exceptions and failures that arise during contract execution

13

3. Failure Prevention

1.1.1 Inconsistencies in an e-contract

The basic input to an E-Contract system is a contract document which later on gets converted

to processes which enact and executethe contract processes and rules. There have been cases

where e-contracts fail duringexecution due to inconsistencies in the document contract

itself.For instance, consider the following two sentences in a school admission contract

document:

“Bright students will be given free bicycles.

Students who are privileged would not be given any benefits.”

When the contract is in execution, inconsistency may arise while deciding whether a

privileged student, who is bright, should be given a free bicycle or not. If this kind of

inconsistency is detected at the document level, then it can be handled during contract

specification itself and thus the contract execution can be successfully completed. Otherwise,

the enactment of the contract may lead to failures. As a result of these failures, the resources

are wasted and users are unsatisfied andfrustratedwhen people try to figure out issues at the

execution level and at the end, determine that e-contract specifications were inconsistent. To

avoid this cumbersome process, we need to find ways to avoid these issues by making sure

that the contractdocument is consistent before executing it. The inconsistency can be at

semantic level or due to contract elements dependences. We address the issue of

inconsistency in the specifications of contractdocument in chapter 2.

Consider the following text froman example contract namelyiTunesContract:

“GIFT CERTIFICATES, ITUNES CARDS AND CODES, ALLOWANCES

Gift Certificates, iTunes Cards and Codes, Content Codes, and Allowances, in addition to

unused balances, are not redeemable for cash and, if redeemed during 14 days from

receiving the receipt, cannot be returned for a cash refund, without prejudice to any

applicable statutory right to a refund in case of faulty or misdescribed gifts; exchanged;

resold; used to purchase Gifts, Gift Certificates, or iTunes Cards or Codes; used to provide

Allowances; used for purchases on the Apple Online Store; or used in Apple Retail Stores.

Unused balances are not transferable.

Gift Certificates, iTunes Cards and Codes, and Allowances purchased in Ireland may be

14

redeemed through the Stores only in Ireland.

iTunes is not responsible for lost or stolen Gift Certificates, iTunes Cards and Codes, or

Allowances. Risk of loss and title for Gift Certificates, iTunes Cards and Codes, and

Allowances that are transmitted electronically pass to the purchaser in Ireland upon

electronic transmission. Risk of loss and title for Codes that are transmitted electronically

pass from iTunes in Luxembourg upon electronic transmission.

iTunes reserves the right to close accounts and request alternative forms of payment if a Gift

Certificate, iTunes Card and Codes, Content Code, or Allowance is fraudulently obtained or

used on the Stores.”

In this snippet, if we quote the following lines “Risk of loss and title for Gift Certificates,

iTunes Cards and Codes, and Allowances that are transmitted electronically pass to the

purchaser in Ireland upon electronic transmission. Risk of loss and title for Codes that are

transmitted electronically pass from iTunes in Luxembourg upon electronic transmission”,

it can be observed that first line says Risk of loss, title for Gift Certificates, iTunes Cards and

Codes and Allowances are passed to purchaser in Ireland upon electronic transmission. And

the second line is contradictory by quoting that Risk of loss and title of Codes pass from

iTunes in Luxembourg upon electronic transmission.

If this document contract isnot validated or checked in some way, it may lead to inconsistent

results while executing the tasks since it says that codes are passed to Luxembourg or

Ireland. This is just an example of semantic inconsistency where we need to check the natural

language sentences and make sure there is no anomaly.

Another kind of issue that can arise when we have incomplete information in a document

which may lead to an inconsistent state during the contract execution.

If we quote another part from the iTunes contract,

“REQUIREMENTS FOR USE OF THE SERVICE

15

Only persons aged 21 years or older can create accounts. Accounts for children under 18

years old can be created by the parent using Family Sharing. Children under the age of 18

should review this Agreement with their parent or legal guardian to ensure that the child and

parent or legal guardian understand it. The software can be downloaded by parent and can

be circulated by family sharing. Your total price will include the price of the product plus

any applicable VAT (in effect on the day of download). A person with an account is entitled

to download the software. Software can be downloaded by a parent and can be circulated

using Family Sharing. Parent will be entitled for a 40% discount for any additional software

downloaded from after 4 paid downloads. No discount is provided in the iBooks Store

downloads.

The Service is available to you only in Ireland. You agree not to use or attempt to use the

Service from outside this location. iTunes may use technologies to verify your compliance.”

According to this contract, a parent gets a discount of 40% after fourpaid downloads. The

next phrase conveys that there is no discount on iBooks Store products. An inconsistent

situation arises when a parent after completing fourpaid transactions tries to download

something from iBooks store expecting a discount of 40% but does not get it because iBooks

Store products are entitled to have no discount. Here, the order of clauses keeps the task

execution in an inconsistent state as the exceptions clauses related to iBooks store and

location Ireland are placed after downloads.We need to addressthese kind of inconsistent

scenarios at the document level itself in order to identify potential failures during contract

execution when certain conditions are met.

1.1.2 Exceptions and failures that arise duringcontract enactment

We address the problem by taking an example of timetable allocation in a graduate college.

In a graduate college a faculty teaches multiple courses. While timetable allocation there are

certain things that need to be taken care of: 1. For each course there should be an assigned

faculty. 2. Same faculty should not be allocated same time for more than one course.

Suppose the User Workflow that needs to be executed is:

Take a course -> Choose a professor with capability to teach that

course -> Allocate timing -> Stop

The above workflow has to be executed according to the requirements stated in the e-

contract.Assume that we have a database which has tables for faculty and course containing

all the relevant information. Now, when the execution begins, the following issues may arise:

16

(1) No professor is available to teach thecourse which has been selected after

executing “Take a course” task.

(2) After executing “Allocate Timing” task, the professor has an issue with the timing and

wants to change it.

In these scenarios,an e-contractsystem should be capable enough to deal with runtime

exceptions and failures that may occur so that the execution is seamless. It should also be

capable enough to assess the failures that can occur by looking at the failures that have come

up in the past.

In this thesis:

- we devised a methodology to detect and to handle inconsistencies in an e-contract at

document level by constructing Sentence dependency graphs and Contract Elements

Dependency Graphs.

- we have developed a system which handles possible exceptions and failures that

occur during execution of tasks of a contract.

- we have proposed a way for prevention of failure

1.2 Scope of the Thesis

We first focus on finding inconsistencies at the document level of e-contracts. Most of the

existing works have explored the inconsistencies at execution level and there is no or less

work has been carried out at document level inconsistencies. In this work, we deal with

document (specification) levelinconsistencies in order to ensure that the contract document is

consistent and ready for enactment.

Next, we focus on handling the exceptions/failures that may arise at runtime to provide

seamless execution of workflows.Our approach is mainly based on metaexecution models

[3]. We show that the usage of metaexecution models makes the system more flexible and

easy to use to incorporate new changes in the system.

We developed a meta execution engine prototype and presented itsdesign and

implementation details (chapter 4 and 5). The description starts from logical layers and

extends to the implementation layer with corresponding design artifacts.

17

1.3 Thesis Outline

The thesis is organized in the following manner:

In Chapter 2, we present thestate-of-the-art for e-contracts and workflow management

systems in different dimensions including consistency issues and exception/failure handling.

In Chapter 3, we designed an approach to detect inconsistencies that occur at document level

of contract and develop a methodology which can deal with these inconsistencies at both

semantic level and contract elements level.

In Chapter 4, we present a system to handle exceptions and failures that occur during task

execution to support seamless execution of tasks.

In Chapter 5, we developed a methodology to assess failures by using execution log and

dependencies data.

In Chapter 6, we validated our approach with a case study on an e-governance contract and

demonstrate the applicability ofour approach.

In Chapter 7, we summarize the contributions made in the thesis and discuss the extendibility

and future work.

18

Chapter 2

Related Work

In this chapter, we present related work with respect to e-Contracts and workflow

management systems (WFMS). We start with highlighting the work done in the field of e-

contracts and WFMS with a focus on 1.)detecting inconsistency in an e-contract specification

and 2.)dealing with exceptions/failures during execution of an e-contract. We also highlight

thelimitations of earlier approaches and the need of additional mechanisms to deal with

failures during e-contract enactment.

2.1 E-Contract

There has been a considerable work done in the field of e-contracts. Angelov and Grefen[4]

proposes a conceptual 4W Framework for business-to-business e-contracting support. Who,

Why, What and hoW are the four concepts identified in a contract. The participation of

parties as actors lead to ‘who’ concept whichcan be further subdivided as a party, a mediator

or an auxiliary implementer. The contextof contract under which it is established define the

‘where’ concept. It includes legal, geographical and business dimensions. ‘What’ concept

models exchanged values during the e-contracting process. Different contracting processes,

contract representation and standards, contracting phases and contract structure forms the

How concept. 4W framework helps in maintaining consistency in the contract to a certain

extent by maintaining specifically who is doing what, where and how. However, there is no

mechanism to track the tasks with respect to 4Ws and coordination among entities in these

four concepts. Further, 4W framework is at conceptual level and hence does not provide

support at execution level. This framework does not address inconsistency in specification

and failure handling at execution time.

Metso and Kutvonen [8] propose multi-party contracts that records the contract business

rules and non-functional requirements as well as have defined role descriptions for fulfilling

contracts. The framework presented is based on B2B middleware services provided by web-

Pilarcos architecture [2]. In this approach agreement between parties is established by

verifying the intended message to be received by the parties.

The CrossFlow project [5] introduces dynamic contracting and configuration for service

enactment and defines inter-organizational business process among the parties. It provides

cross-organizational workflow support to provide role based interfaces and connecting

workflows by runtime role mapping.

19

2.2 WFMS

Workflows help in automating business processes. Van der Aalst et al. [6] developed a

formal organizational model using UML and XML to support workflowsystems. The

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

process components and supports interfaces for process execution, monitoring and

interoperation between process components. In CapBased AMS [10], tokens are used to

model the capability or need of a PSA or task respectively. The specification of activities,

sub-activities, tasks and PSAs are all user driven. This approach is defined to execute

activities as an event driven activity execution paradigm. In our work, we followed the

concept of PSA to deal with exceptions and failures during e-contract enactment.

Sharma et al [3] describes the specification and execution of workflows using Meta Models

by introducing Meta Specification Workflow and Meta Execution Workflow. MSW handles

the specification of workflows and MEW takes care of their execution. Therefore in the

proposed approach MEW serves as a top layer to user workflows which help in executing

user workflows with ease. The MEW forms basis for our system.

In the previous works, the main focus is on updation of workflow to suit the needs of run-

time context, but there is no or less work done in handling failures that arise due to

inconsistencies during the execution of contract. In this work, we introduced mechanisms to

extended the capabilities of MEW in order to support exceptions/failures.

2.3 Document Level E-Contract inconsistencies

Marneffe and Manning [12] defined Stanford typed Dependencies which marks the

dependencies that exist in a sentence by finding out doer of the action. They presented an

approach by which one can understand the grammatical relationships existing in a sentence.

They also represented all sentence relationships as typed dependency relationships, which

helps in extracting useful information from the text. Xiao et al [13] presented a model that

bridges the gap between specified Access Control Policies and the implementation model by

proposing a technique that extracts Security Policies from Software Documents. Theirwork

uses Extensible Access Control Markup Language (XACML) for specifying Access Control

Policies’ constructs which were widely supported by major platform vendors. Gervasi and

Zowghi [14] described a method for automatically discovering inconsistencies in the

requirements specification documents from multiple stakeholders by model checking

techniques which focused on logical contradiction leading to inconsistency in the system.

Rush [15] presented a technique to augment sentence level models for Parsing and POS

20

tagging with inter-sentence consistency constraints by adding consistency constraints to the

MST parser and Stanford Parts of speech tagger and also demonstrated reduction of error

when training data was out of domain or limited.

Several e-contract systems and frameworks exist in the literature. Examples are

ERECframework[16], COSMOS[20], CrossFlow [19], SweetDeal [17] and IST CONTRACT

project (www.ist-contract.org). All these works assume that the contractual sentences are

clearly stated without any ambiguity. Miloesvic [18] presented a technique for formal

modeling of e-contracts and also introduced visualization concepts such as role wind and

time maps and further described how these visualization concepts can be used as decision

support tool during contract negotiation. Fagundes [19] discussed about violation risks in e-

contracts and further presented an extension of Markov Decision Process called as Normative

Markov Decision Process for representation of norms of e-contract. Theirwork also describes

an algorithm for identifying the states of the process which characterize the violation of any

norm where norms express the obligations of different parties.

In our work, we consider contract documents that constitute activities (to be carried out by

parties) and clauses (to be satisfied for successful contract execution), and use parts-of-

speech (PoS) tags and dependency graphs to check for inconsistencies in an e-contract

document.

Most of the approaches (ex. [14] or [19]) detect inconsistencies from natural languages

sentences at specifications level whereas our approach considers contract (business)

semantics also in order to ensure that the contract is free from inconsistencies.

2.4 Execution level E-Contract Exceptions/Failures

There have been many projects (ex., [22, 23, 24, 25, 26]) that facilitate meta modeling to

provide flexibility during workflow execution. ADEPT, an adaptive workflow management,

described by Reichert et al [27] enables ad-hoc workflow changes, workflow schema

evolution and synchronization of inter-workflow dependencies. Their work also has features

to support temporal constraints and inter workflow dependencies. Zhang and Du [26]

described a dynamic planning for workflow process generation method to allow workflow

processes to be more flexible. They defined actions in terms of Description logic and

presented a hierarchical workflow ontology model for routing relations to increase the

process adaptability in workflows. Krishna and Karlapalem [23] viewed the e-contracts as

workflow meta model and described an approach to generate dynamic workflows from an e-

contract meta model. Reichert and Dadam [24] provided a set of modification primitives that

allow change in workflow schema, both static and dynamic. Chiu et al [22] presented a meta-

workflow model to monitor and handle exceptions raised during running of a workflow

21

instance.

The above works support the execution of workflows which include multiple task executions.

However, consistent system state recovery is a challenge in the existing workflow systems

due to the autonomy of constituent services. That is, though each service can be deployed

multiple times, but there is no mechanism to handle the dependencies exist among various

services execution, which may cause delay (or abandon in some cases) and push the system

into an inconsistent state. Thus, these systems need to be augmented with additional

mechanisms to handle failures, for instance, due to dependencies among the tasks. Such

mechanisms handle pre-defined scenarios. However, in real-world applications, it is hard to

envisage all kinds of failures and exceptions during application design. Thus, we introduce

configurable workflow engine control logic, which handles failures as well as exceptions,

rather than doing the same within user workflows.

2.5 Summary

In this chapter, we presented the existing works in the area of e-contact and workflow

management systems. Further, we discussed on finding inconsistencies in e-contract at

document level which has not been explored much in the past. Finally, we looked into the

work on exceptions and failure handling techniques that have been devised to ensure

consistency and successful execution of a workflow, but unfortunately most of the works

failed to address the issue by maintaining automated system and at the same time support

dynamic changes at run time. In the next chapter, we discuss about the issue of

inconsistencies in e-contracts and suggest a methodology to deal with the problem.

22

Chapter 3

Consistency of an E-Contract

The previous chapter discussed about state-of-the-art which addresses the issue of

inconsistency in e-Contract. In this chapter, we address the issue of consistency in e-

contracts,develop a methodology fordetecting inconsistencies at document level and resolves

the overheadsaves the extra effortof finding out what went wrong when a contract workflow

is in execution.We introduce the concept of Semantic Dependency graphs and Contract

Elements Dependency graph which help us in detecting existing inconsistencies in the

document contract.

3.1 Problem Description

In this work, we consider e-contract documents, which are largely textual documents

describing the various details and dependencies in the contract. These dependencies and

constraints in e-contract can be stated differently in different parts of a large document.

Inconsistencies in a contract document leads to serious problems during its execution. For

instance, consider the segment of a contract document below:

“Party A supplies raw materials to Party B. Party B ships the finished

goods to Party C. Party B supplies raw materials to Party A. Party C sends

finished goods to Party D. Party supplying raw material has to be supplied

with finished goods.”

In the above, the first sentence reveals that Party A is the one supplying raw materials to

Party B, but in the third sentence it is Party B that is supplying raw material to Party A. There

may be an inconsistency if the raw material to be supplied is same. Also in this case ‘Party

supplying raw material has to be supplied with finished goods’,the finished goods have to be

supplied to Party A and Party B, in addition to Party D. Here, these contract semantics leads

to an inconsistency. Other examples of commonly occurring inconsistencies among

sentences include the following:

"All payments must be made in within 6 days after receiving the goods."

"non-payment for any goods immediately after goods received leads to penalty".

"Premier customer placing an order is entitled a 5% discount".

"No discounts for Special orders".

Note that the inconsistencies may arise for some specific situation(s). For instance, in the

above example, there is a conflict when premier customer places a special order.

In this work, we focus on finding inconsistencies among contractual sentences (terms and

conditions) that may arise. Further, we find the dependencies among contract elements such

as parties, activities, clauses and exceptions existing in the contract to determine the

23

inconsistencies that occur in the contract document. We also present a methodology that

extracts the existing dependencies and detects inconsistencies (if any) from textual

statements.

Towards achieving this, we perform checks at two different stages:

(1) checking for semantic dependencies existing among the sentences of the document

contract

(2) checking conflict dependencies among contract elements present in the contract.

We evaluate our approach througha seller-buyer contract. Our approach helps in reducing

risk and improving support for handling e-contract business processes (ex. activities, clauses

and exceptions) during contract enactment.

3.2Seller-Carrier-Buyer E-Contract

We consider seller-buyer contract to explain our approach that deals with consistency and

dependency issues in the contract at the sentence level of a contract document.The primary obligations of the buyer are 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 buyer’s satisfaction. Principal parties are: buyer and seller. Contract activities: dispatch of goods by the seller, receipt of the goods by the buyer and payment for the goods to the seller. Clauses include delivery terms for the seller, which are negotiated and agreed upon by mutual consent of both the buyer and the seller.

24

The same contract example is used in rest of the thesisas well for better explanation of the

suggested approach.

We take a specific contract of seller-buyer that is a Textile value chain contractSTC (State

Textile Corporation) which is a large scale industry. Weavers, they are part of small scale

industry and are responsible for preparing the garments or the gray cloth. The raw material to

the weavers is supplied by the Mills. The gray cloth or the garments prepared by the weavers

are sent to the Printers, they do the dyeing, designing and printing of the cloth. The finished

goods are then sent to the showrooms. The amount received after selling the goods is credited

to the parties (STC, Weavers, Mills, and Printers) and the payments are handled by the

banks. In this contract, the parties carry out the activities as per the contractual agreement

between them. There are seven bilateral contracts involved between the parties as given

below:

STC and Mills: STC needs to send raw materials to the weavers, so it buys the material from

the Mills. As it is an e-contract it has set of activities, clauses, payment, exception and

commitment.

STC and Weavers: The raw material is sent by the STC to the weavers. At times due to lack

of time or distance issue, materials are sent by the mills directly to the weavers. The weavers

process the raw materials into finished goods and send them back to the STC.

STC and Printers: The STC provides the finished goods to Printers i.e. supplied from the

weavers. The gray cloths are printed and send back to the STC for selling purpose.

STC and Showrooms: The finished ready to sell goods are sent to the Showrooms.

STC and Organizations: There are organizations that directly purchase the materials from

the STC.

Inter-bank: The payment between the parties is done by the banks.

Bank and Customer: For the transfer of payments or to avail the loans the parties need to

have a bank account so as to ease the transaction.

The contract document comprises of English sentences. From the contract document, we

extracted the following S0 to S10 sample sentences:

S0 : STC buys the material from the Mills.

S1 : STC needs to send raw materials to the weavers,

S2 : The raw material is sent by the STC to the weavers.

S3 : At times , materials are sent by the mills directly to the weavers.

25

S4 : The weavers process the raw materials into finished goods and send them back to

the STC.

S5 : The STC provides the finished goods to Printers that is supplied from the

weavers.

S6 : The gray clothes are printed and send back to the STC for selling purpose.

S7 : The finished ready to sell goods are sent to the Showrooms.

S8 : There are organizations that directly purchase the materials from the STC.

S9 : The payment between the parties is done by the banks.

S10 : For the transfer of payments or to avail the loans the parties need to have a bank

account so as to ease the transaction.

The activities, parties, clauses and exceptions of STC contract are represented below:

Activities:

A1 Placement of orders by the buyer.

A2 Get the orders from the buyer.

A3 Processing of request by the seller.

A4 Sending bid to the carrier.

A5 Response of carrier for the bid.

A6 Choosing of carrier by the seller.

A7 Shipment of goods to the buyer.

A8 Damaged goods are returned to the seller.

A9 Count the number of desktops ordered.

A10 Do the payment 1.) in cash, pay it to the

carrier, carrier will pay it to the seller.

2.) in credit payment pay directly to the seller.

Clauses

C1 Payment will be done using if the account

is a valid account.

C2 Shipment of the goods from one party to

another should not exceed 2 working days.

C3 The quality of the goods should be

maintained.

C4 Payment will be deducted by 10%, if the

time limit exceeds.

C5 The processing of order should not

exceed 5 working days.

C6 Orders received can be rejected if they do

not meet the standards fixed by the

inspection team.

26

Exceptions are deviations from normal behavior of workflows which if not handled lead to

abnormal termination of workflows. Partial (or unsuccessful) workflow executions due to

such terminations keep the workflow into an inconsistent state. On the other hand, outcome

of a workflowexecution does not satisfy the end user due to improper design (model) of

workflow as per the business process specification. This is because of inconsistent statements

specified in the business process specification. That is, the execution is successful, but not as

desired.

In the next section, we outline our approach to ensure consistency in a contract document by

determining dependencies in the contract document.

3.3 Methodology for ensuring consistency

Our main focus is to determine whether a contract document is consistent or not. We first

detect the inconsistencies in the contract document at the semantic level that islinguistic

interpretation of sentences (at English language level) and then find out non-conflicting

dependencies among contract elements.

We summarize the methodology in Figure 3.1 represented below.

Exceptions

E1 Time limit exceeded during shipment.

E2 Time limit exceeded while supplying of raw material.

E3 Processed goods not up to the mark.

E4 Goods damaged while processing.

E5 Time limit exceeded while supplying of weaved material.

E6 Invalid account during fund transfer.

E7 No sufficient balance during fund transfer.

27

Figure 3.1An overview of the procedure for ensuring a consistent contract

In this figure we represent two stages of ensuring consistency in the contract:

Step1: Mark POS tags of sentences and construct Sentence dependency graphs. After

constructing the graphs compare the sentence dependency graphs to check for incorrect

semantics.

Step 2: Construct Element Dependency graphs corresponding to each element of e-Contract.

After this is done we construct contract elements dependency graphs which represents all

dependencies that exist within elements.

We will describe the individual steps in more detail in further sections.

3.3.1 Semantic Dependency Check

We check the semantic dependencies between two sentences in the contract document.

Semantic dependencies are the dependencies that exist among English sentences in such a

way that a new sentence should not contradict other sentence(s). Any two conflicting

statements can be termed as contradictory.Two statements are said to be conflicting if both

statements provide opposite facts/meaning for a given object (or task),To check for

contradictory statements the dependency graph of sentences is compared. The sentences are

said to be inconsistent when there is a contradictionin dependencies of two sentences.

For finding semantic dependencies, we first construct Sentence Dependency Graphs (SDGs)

from contract sentences by performing Parts Of Speech (POS) tagging on sentences. SDGs

28

are constructed using tokens of sentences (or words) in which vertices represent the tokens

and the edges represent the relations between the tokens.

Each token is linked with other tokens on which it is dependent. We store these dependencies

in a dependency table. Two dependency graphs are compared to perform dependency check.

If there is a match in tagged_token, then we compare the subgraphs at every nodeto check for

contradiction. These two sentences are said to be inconsistent, if there is a conflict

dependency between any two nodes. We usedWordnet [19] to map similar concept words

into a single word. The complexity of this approach is O(n log n) in worst case where n is the

number of sentences.

There may be cases when there is a logical error in the sentence of the contract and the

sentence faces no clash with another sentence but yet it is logically incorrect These kinds of

inconsistencies are not dealt using this check as they would be handled by a domain expert.

Consider the following two sentences from the example STC contract :


S3 :At times of emergency,materials are sent by the mills directly to the weavers.

We first mark POS tags for both these sentences and then we compare their dependency

graphs.

S2: The/DT raw/JJ material/NN is/VBZ sent/VBN by/IN STC/NNP to/TO

weavers/NNS

S3: At/IN times/NNS of/IN emergency/NN, materials/NNS are/VBP sent/VBN

by/IN the/DT mills/NNS directly/RB to/TO the/DT weavers/NNS

The semantic dependency graphs for S2 and S3 are shown in figure below.

Figure 3.2: Representing Sentence Dependency Graphs for Sentence S2 and

S3 respectively

29

We start comparing from Verb that is attached to root. In this case it is ‘sent’. Now we

compare the dependencies of all tokens (listed in dependency table 3.2).

In sentence S2, dependencies of sent are: “materials”, “by”, “to”.

In sentence S3, dependencies of sentare: “materials”, “by”, “to”, “at”.

Finally, we check the dependencies of sent in both S2 and S3 for any conflicts. Note that

materials are sent to weavers in both the cases. In S2, it is sent by STC whereas in S3, it is by

mills. If there was no ‘at’ present in S3 with ‘sent’ then the sentences would have been

inconsistent. Since it is mentioned that “At times of emergency, materials are sent by mills to

weavers” and if we refer to dependency table Table3.2, the entry for S3 indicates that sent

has a dependency on ‘at’ and ‘at’ is further dependent on ‘times’. So these two sentences turn

out to be inconsistent. In the similar way, we perform consistency check between other

sentences using their SDGs.

Table 3.1. Parts of speech tags

Tag Signifies

SNo Sentence Number

NN Noun

NN_Mod Noun Modifiers

VB Verb

VB_Mod Verb Modifiers

IN Preposition

IN_Mod Preposition Modifiers

JJ Adjective

JJ_Mod Adjective Modifier

Therefore, the procedure is:

1.) Compare the two SDGs starting from root. Root is connected to main verb in most of the

sentences. Sentences which do not have main verb have helping verb connected to root.

2.) We compare the dependencies of two dependency graphs, if the dependencies for two

graphs are same and nouns are different, then there is a chance of inconsistency because

probably same task has been assigned to different persons and hence it needs to be cross-

checked for inconsistency.

3.) Else, if dependencies are same and nouns are same, then both sentences are consistent.

30

4.) In casethedependencies are different, then we consider two sentences as different and

hence it is marked as consistent at this stage.As there should not be a chance of both

sentences to be inconsistent due to different dependencies.

We tried our approach on 3 e-contracts where it helped us to find a couple of inconsistencies.

3.3.1.1 Semantic Dependencies in the text We represent the contract sentences in a graph where vertices represent the sentences and

edges represent the transitions. One vertex of the graph corresponds to one single sentence.

Generally different people have different ways of interpreting a document. So, we can locate

different paths from start to end and also keep a check on dependencies between sentences.

We mark the Parts of Speech tags of the sentence and we maintain a Sentence Dependency

table with fields shown in table 3.1.

The dependency table serves as a mirror to the sentence since it conveys about the

dependencies of each word present in the sentence.

It represents the dependencies of each token of a sentence. Using this information, we

construct Sentence Dependency Graph for each sentence (using Stanford Parser). For each

sentence, we check whether the term attached with root of Sentence Dependency Graph

belongs to the same Wordnet as the other sentence. If it is Yes then we say that the sentences

are semantically similar and then compare their SDGs .

If we find dependency conflicts, then we report inconsistency, else we mark it as consistent.

The conflicts are determined by comparison of SDGs of two sentences. The algorithm for

consistency check is shown in figure 3.3 below:

Algorithm: To check consistency in Semantic Dependency Graph

1: Input: SNo containing all enumerated sentences of the document

2: Output: True if consistent False if inconsistent

3: SDGCheckconsistency(SNo){

4: for Si and Sj € SNo:

5: if adj_n_Si&&adj_n_Sj € same wordnet W:

6: Then compare SDG(Si,Sj);

7: if there is a dependency clash:

8: Return False;

9: }

Fig. 3.3 Algorithm for consistency check in SDG

According to the algorithm in Figure 3.3, it takes input as sentences enumerated as S0 to Sn.

31

The output will give us whether a sentence is consistent or it has become inconsistent by

having a contradiction with another sentence. According to algorithm we take up each

sentence and compare their dependency graph elements for Si and Sj and check if both

belong to same wordnet W that meansthat both words can be used interchangeably, we

further compare their Semantic dependency graphs. To check SDGs we compare their

dependencies. If noun is same and dependencies are conflicting then the sentences are

marked inconsistent else if noun is different but dependencies are same, in this case also

sentences are marked inconsistent else if nouns and dependencies both vary the sentences are

consistent.This approach has been worked out with various sentences of a contract and

sentences tend to follow this logic. We have used this approach on 3 other contracts and it

has helped us find inconsistencies present in the documents.24 statements are predicted as

inconsistent using our system. Similarly it was found that 6 other statements were

inconsistent but our system could not capture them as there was no dependency clash that

was occurring in these 6 statements.

For our example contract [13], we can get the following Parts of Speech tags for

sentences (the tags have been given according to Penn Tree Bank notation [12]) :

S0 : STC/NN buys/VB the/DT material/NN from/PR the/DET Mills/NN

S1: STC/NNP needs/VBZ to/TO send/VB raw/JJ materials/NNS to/TO the/DT weavers/NNS

S2: The/DT raw/JJ material/NN is/VBZ sent/VBN by/IN STC/NNP to/TO weavers/NNS

S3: At/IN times/NNS of/IN emergency/NN , materials/NNS are/VBP sent/VBN by/IN the/DT mills/NNS directly/RB to/TO the/DT weavers/NNS .

S4: The/DT weavers/NNS process/VBP the/DT raw/JJ materials/NNS into/IN finished/JJ goods/NNS and/CC send/VBP them/PRP back/RB to/TO the/DT STC/NNP

S5: The/DT STC/NNP provides/VBZ the/DT finished/VBN goods/NNS to/TO Printers/NNP that/WDT is/VBZ supplied/VBN from/IN the/DT weavers/NNS

S6: The/DT gray/JJ clothes/NNS are/VBP printed/VBN and/CC send/VBP back/RB to/TO the/DT STC/NNP for/IN selling/VBG purpose/NN

S7: The/DT finished/JJ ready/JJ to/TO sell/VB goods/NNS are/VBP sent/VBN to/TO the/DT Showrooms/NNS

S8: There/EX are/VBP organizations/NNS that/WDT directly/RB purchase/VB the/DT materials/NNS from/IN the/DT STC/NNP

S9: The/DT payment/NN between/IN the/DT parties/NNS is/VBZ done/VBN by/IN the/DT banks/NNS

S10: For/IN the/DT transfer/NN of/IN payments/NNS or/CC to/TO avail/VB

32

the/DT loans/NNS the/DT parties/NNS need/VBP to/TO have/VB a/DT bank/NN account/NN so/RB as/RB to/TO ease/VB the/DT transaction/NN

We represent the dependencies of these sentences below in Table 3.2.

Table 3.2Sentence Dependency Table with POS tags of the words

S

No NN NN_

Mod VB VB_Mod JJ JJ_ Mod IN IN_Mod

S0 STC Buys Buys Material From mills, material

Mills From

S1 STC Needs Sends to, material Raw Material To needs, sends

Weavers To Needs STC,to

S2 STC By Sent material, by,to Raw Material By STC, sent

Weavers To To

S3 Mills By Sent material, by,at,to - - To weavers, by

At times,sent

Emergency Of Of Times,emergency

By mills, sent

S4 Weavers Process Process into, material, send, weavers

- - Into finished, process

Finished Provides, goods

STC To Send To, process

S5 STC Provides Provides STC , finished - - To Printers, supplied

Printers To Finished Provides , goods

Weavers From Supplied To , from From supplied, weavers

S6 Printers Printed Printed Clothes, send Gray Clothes For send , selling

Send For, to, printed

STC To Selling For, purpose To send , STC

S7 Showrooms To Finished Goods, sent To showrooms, sent

S8 Organization Purchase Purchase material, organizations

From STC, materials

STC From

S9 Parties Between Done Payment, by Betw-een

Parties, payment

By banks, done

S10 Parties need, to Need to, parties - - To have, bank

Bank account, have

To need, have

Account Bank Avail to, loans - -

33

After checking for the dependency conflicts, we check the inconsistencies for the example of

STC contract. In the above example contract, there are no inconsistencies. Suppose we

modify two sentences S2 and S3 in the contract example as below and apply our procedure

for inconsistency checks:


S3 : At times, materials are sent by the mills directly to the weavers.

Their semantic dependency graphs (SDG’s) are shown in Figure 3.2. If we remove At times

of emergency from S3 (as we know that “at” is an extra dependency in graph on S3) we get

the two sentences as :


S3 : Materials are sent by the mills directly to the weavers.

In the new SDGs, by comparing these two graphs, we get,

In S2 , sent is dependent on “materials” , “by” , “to”

In S3 , sent is dependent on “materials” , “by” , “to”

Further, there is a dependency conflict of ‘by’.

In S2, by is dependent on STC while in S3, by is dependent on Mills and rest other

dependencies are same. So we can infer that S2 and S3 are inconsistent and there is an

inconsistency at the semantic level itself in this contract.This is ‘OR’ condition only, i.e, S2

OR S3. However, inconsistency may arise when the party Mill is asked to send the material

to both STC and weavers.

We implemented a visualization using gephi tool to show the sentences derived from our

textual contract file. Here, the nodes with same verb and different dependencies having a

conflict are marked in red to represent inconsistency, whereas the consistent nodes are

marked in green color. We construct a visualization for our example contract sentences S0 to

S10 in figure 3.4 where nodes represent the sentences and the edges represent that one is

moving from a sentence to other sentence. Since all sentences get executed sequentially there

exists a dependency among the sentences. The main motivation behind representing a graph

structure is to show dependency of one sentence onto other during execution.Since there are

no conflicts of dependencies in SDGs, sentences are consistent and hence they are marked in

green.

34

Fig. 3.4 Representing Sentences of SDG(Sentence Dependency Graphs)

3.3.2 Data Dependencies in terms of contract elements

In the previous section, we tracedthe contract document for inconsistencies. However, a

contract can have lot of inter- and intra-dependencies among contract elements. For

successful enactment of an e-contract, we need to capture and handle such dependencies.

In our approach, intra-dependencies are captured in terms of element specific Element

Dependency Graphs and inter-dependencies are captured in terms of Contract Elements

Dependency Graphs. In this work, we considered four contract elements namely parties,

activities, clauses and exceptions.

We find theContract elementsdependencies at the initial level for smooth enactment of the

contract.

The dependencies in an E-contract enactment that need to be satisfied generally include:

1. Activities need to be executed by different parties autonomously and in a loosely coupled

fashion.

2. Clauses are to be associated with an activity and are to be satisfied for execution.

3. In case of clause violation, exceptions need to be handled.

These dependencies are for ensuring consistency in an e-contract. Now we use dependency

graphs to check for these dependencies. To perform the check, we follow a bottom up

approach where we find intra dependencies among elements. We merge all these

dependencies and get an inter-dependency model of the contract document.

35

The algorithm for the bottom up approach is shown in the following figure 3.5.

Algorithm : To construct Element Dependency Graph

1: Input : List all the sentence numbers

2: Parties[ ]={P1,P2,P3…}

3: Activities[ ] ={A1,A2,A3…}

4: Exceptions[ ]={E1,E2,E3..}

5: Clauses[ ]={C1,C2,C3..}

6: Output : Element Dependency Graph

7: ContractElementsDependency( ){

8: //Construct PartiesDependencyGraph where Parties

9: are Vertices and SNo are edges

10: for Parties Pi and Pj in Parties [ ]:

11: if Pi is dependent in Pj in some sentence SNo:

12: add an edge from Pi to Pj

13: end for

14: //Construct ExceptionsDependencyGraph where Exceptions


16: for Exceptions Ei and Ej in Exceptions [ ]:

17: if Ei is dependent in Ej in some sentence SNo:

18: add an edge from Ei to Ej

19: end for

20: //Construct ClausesDependencyGraph where Clauses


22: for Clauses Ci and Cj in Clauses [ ]:

23: if Ci is dependent in Cj in some sentence SNo:

24: add an edge from Ci to Cj

25: end for

26: //Construct ActivitiesDependencyGraph where Activities


28: for Activities Ai and Aj in Activities [ ]:

29: if Ai is dependent in Aj in some sentence SNo:

30: add an edge from Ai to Aj

31: end for

32: }

Fig. 3.5 Algorithm for constructing EDG

36

We explain our approach using STC contract. The following table (Table 3.3) shows the

contract elements:

Figures 3.6 to 3.9 show the dependency graphs for parties, exceptions, activities and clauses

respectively.In the dependency graphs an edge represents that one node is dependent on

another node in a particular sentence.

Table 3.3. Dependencies in the STC contract

Sentence No. Related Contract Elements

S0 P4 A1 A2 C4 C6 E1

S1 P1 A1 A2 A4 C2 C3

S2 P1 A12 A13 C2 C4

S3 P4 A7 A8 C2 C3 E1 E2

S4 P3 A10 A11 C5 C6 E3 E4

S5 P1 A14 A16 C5 C6 E4 E5

S6 P2 A17 A18 C2 C3 E1 E6

S7 P1 A16 A17 C2 C4

S8 P1 A18 A19 C3 C6

S9 P6 A19 A20 C1 C4 E6 E7

S10 P6 A20 A19 C1 C4 E6 E7

37

Dependency graph for Parties:

Dependency graph for Exceptions:

Fig 3.6 : Representing dependency

graph for parties


graph for exceptions

38

Dependency graph for Activities:

Disconnected graph means that there are activities that are independent of each other.

Dependency graph for Clauses:


graph for activities

Fig 3.9: Representing dependency

graph for clauses

39

At this stage, sentences of the contract reveal that:

(1) which parties are dependent, (2) which activities are dependent

(3) what clauses are dependent

(4) which exceptions are dependent .

Since, we move in a bottom up manner, we first look at the contract elements and their

dependencies at the sentence level. A sentence in the contract document may bind contract

elements (ex. parties, activities, clauses, exceptions) together. In this step, we progress from

individual dependency graph for each contract element called as Element Dependency Graph

(EDG) to a contract-level dependency graph called as Contract Elements Dependency Graph

(CEDG). CEDG helps in determining whether the contract document is consistent or

not.CEDG can be treated as union of all EDGs where in an edge is added between two

different contract elements if there is a dependency identified in a sentence and the edge is

labeled with corresponding sentence number. Figure 3.10 shows the algorithm for

construction of CEDG.

Algorithm: Constructing Contract Elements Dependency Graphs 1: Input: SNo [ ] = List of all sentence numbers

2: EDG’s of all contract elements

2: Output: Contract Elements Dependency Graph

3: Contract ElementsDependencyGraph ( ):

4: while(SNo is not visited):

5: for x € EDGi and y € EDGj and i≠j:

6: if x is dependent on Y for some SNo:

7: add edge from X to Y

8: endfor

Fig. 3.10Algorithm for constructing CEDG

Table 3.3 shows dependencies extracted from STC contract document. For any two

sentences, say S0 and S4 in the example, we check their dependencies listed in table 4.

Consider a contract element activity. From the dependency table, we know that S0 is

dependent on A1 and A2. We revisit the activity-EDG and check the connected nodes of A1

and A2, and their neighbors. For instance, A2 is connected to A4. So, we can infer that a

sentence that follows S0 has a dependency on A4. The sentence following S0 is S1 and S1

has a dependency on A4 also. So we bring in S1 after S0 and in this way we find the

sequence in which sentences will come by looking at the EDG’s and CEDG’s together .

Similar exercise can be done using other contract elements. Therefore we can say that CEDG

guarantees consistency.

40

3.3.3 Visualization of CEDG

We used gephi tool [29] for visualization. We depict the data dependencies existing in the

contract elements in the form of a 3-dimensional visualization that gives us an interface in

which a user can navigate. Further, for each sentence one can see its dependencies

corresponding to parties, clauses, exceptions or other contract elements.

For the STC contract dependency table, we have the visualization shown in figure 3.11. In

the visualization shown in figure 3.12 the dependency network consists of contract elements:

Parties, Activities, Exceptions, Clauses and Sentences. Parties are marked in Yellow,

Exceptions in Green, Clauses in Magenta, Sentences in Blue and Activities in Red. We can

navigate on each node and check for its dependencies. For instance if we see in Fig 3.12,

dependencies of S7 have been highlighted. S7 is dependent on Activity 16 and Activity 17

(activities marked in red). Also it has dependency on Clause 2 and Clause 4 (clauses marked

in Magenta) and on party 1 (parties marked in yellow).The interactivity features of our

visualization approach for CEDG helps in focusing a portion of a graph (corresponds to a

portion of an e-contract document) that facilitates a clear visibility of complex inter-

dependencies among contract elements.

Fig.3.11 Depicting dependencies of between different contract elements

41

We mark inconsistent statements derived from SDG in CEDG. The elements that are

dependent through inconsistent statements may result in conflict dependency. Further, we

also infer the dependencies that show conflicts between two different contract elements due

to contractual relationships. Examples include an activity without any dependent party, a

clause without any dependent activity and two dependent clauses do not have a common

activity. Such conflict dependencies lead to the e-contract document inconsistency.

3.4 Summary

In this chapter, we presented an approach to resolve the e-contract inconsistency

issues at the document level and thereby reducing the failure rate of the project arising due

to dependencies and semantic dependencies existing in the text document contract. Our

approach checks dependencies at two levels: semantic level and contract elements level.We

constructed two graphs namely Sentence Dependency Graph and Contract Element

Dependency Graph. These constructs helps in ensuring that sentences are semantically

correct and also to find dependencies among contract elements. Further, these two checks

are needed as there may exist a case in which document is inconsistent at the semantic

level itself and we spend a lot of time and effort in execution of the contract and later

on it fails. The presented approach checks that the document is free from all semantic

inconsistencies and thereby progresses in a stepwise manner to ensure smooth enactment

of the contract.In the next chapter, we deal with failuresthat results in during the execution of

e-contract workflows.

Fig. 3.12 Depicting a Contract Elements Dependency Graph showing dependency of a

sentence (Blue) on Clauses(Magenta) and Activities(Red) and Parties(Yellow)

42

Chapter 4

Failures in execution of an E-Contract

In this chapter, we represent how to use and modify meta execution workflows to

successfully execute the workflows without failure. Meta execution workflows allow

modification of workflow execution engine process to support design and run time changes.

We present a meta execution engine which helps in executing workflows in a seamless

manner by handling failures, and thereby ensuring consistency in the process of execution.

We represent workflow execution engine and other components of WFMS in terms of

workflows. The proposed system allows specification, instantiation, modification and

execution of workflows on-the-fly with less human intervention. We also present the meta

execution environment that facilitates workflow handling and database support. The

proposed system is very generic and adaptable to a variety of application failures.


Handling failures leads to escalations and may require experienced personnel to understand

the failure and take a decision based on the status of current execution. Exceptions and

failures seem to be similar but differ significantly from each other. For example, exceptions

may be caused by the scenarios which are not considered by current process design. On the

other hand, failures may be caused by incorrect process design. While we define exceptions

as the deviations from normal behavior of workflows that produce unintended results, which

can be handled by exception handlers properly; whereas we define failure as the inability of a

workflow to perform the required tasks with the given specifications within current execution

environment. For example, in a buyer-seller contract, if goods are not received in a stipulated

time period, then it marks an exception. On the other hand, a buyer cancels the order after the

seller ships the goods mark a failure of execution as there is no laid out procedure to handle it

at that point of time and it may undergo escalation.

Since the root causes for failures and exceptions are different, they need to be handled

differently. In this work, we identify the scenarios where a traditional workflow execution

engine needs additional support to handle failures and resume the execution seamlessly.

43

4.2 Background: Meta Execution Workflow (MEW)

Meta Execution Workflows (MEWs) represent the working of a workflow engine as a

workflow. The concept of defining workflow engine as a workflow is used to increase the

flexibility of modifying execution engine to support evolving application needs. Also, MEW

enables specification of the tasks to be executed by the workflow engine. Workflow

execution engine that is driven by MEW helps in specification and execution of workflows

on-the-fly according to the changing requirements of an application. Our system is designed

to handle failures that occur during workflow execution in order to successfully execute

them.

We extend the capabilities of MEW to handle failures during the execution process by

considering context. Figure 4.1 shows high-level view of MEW-driven workflow execution

engine.

MEW can be instantiated and coupled with user workflows to execute as well as dynamically

update workflows (if required).

Fig. 4.1. MEW driven Workflow Execution Engine for failure handling.

Workflow Execution Engine

Instantiate

Specify,execute, modify

Execute, modify, suspend, Resume, abort

User

Workflows

Specify, Execute

Execution

EngineWorkflow

Instantiate

Meta Execution Workflow Modify/Creat

e

User Workflow Instances

Meta Execution Workflow Instances

44

We deal with the execution of workflows with the flexibility to intervene in the control

flow process on the basis of context of a workflow. We further standardize the automation

processes of meta execution engine for (i) handling the control flow process, (ii) selection of

appropriate workflow on the basis of execution context, (iii) handling exceptions that occur

while execution, and (iv) handling failures that may occur while execution.

This chapter presents an approach to allow for configurable workflow engines to handle

exceptions and failures.

4.3Functional aspects of the system

We create MEW as a workflow where the tasks are defined and executed using a PSA. The

functional aspects of the proposed system are described below.

(i) Control flow process of a workflow

In most of the existing workflow engines, the logic (control and data flow) of workflow

engine was hardcoded. That is, there are finite ways in which workflow engine can execute a

workflow instance, and any other way of executing the workflow instance will require

modifying the workflow engine. For instance, incorporating new capabilities/features (such

as, define compensation handlers, workflow schema evolution, and managing inter and intra

workflow dependencies) into WFMS needs modification of traditional workflow engine.

This necessitates that there should be a mechanism thatcan incorporate pre-defined or newly

specified processes and execute them. Our system hascontrol flow processes to support

specification, execution and control of tasks to be executed and deals with many kinds of

failures in execution.

(ii) Select a workflow on the basis of context of execution

While executing workflows there are multiple instances running and there may be a situation

where an instance requires more resources or PSAs. The database is updated with these

requirements in terms of states of individual instances. The concept of states (such as,

executing, completed execution, failed task) forms a basis for deriving execution context in

our system, and MEWs facilitate selection of appropriate workflows depending on context of

failure that occurred.

45

(iii) Deal with exceptions that occur while execution

Workflow instances may fail due to exceptions (ex. insufficient resources that are required by

a task). Our system also handles such exceptions.

(iv) Deal with failures that may occur while running parallel instances

There can be many instances of different workflows executing at the same time. This may

cause conflicts among tasks of different workflow instances resulting in failure of workflow

instances.

The five states for workflow instances are as follows (see figure 4.2):

Start: A start state indicates that workflow instance is currently being executed.

Finish: Finish state indicates that workflow instance has successfully completed

execution.

Failure: A failure state indicates that workflow instance has failed to execute.

Restart: Restart state indicates that a failed instance has been restarted its execution (after

required adjustments)

Cancel: A cancel state indicates that workflow instance has been withdrawn by the

specifier manually and cannot be executed now.

We represent the states namely start, finish, failure, restart and cancel as 0, 1, -1, 2 and -2

respectively in the runtime database.

4.4 Design of the system

46

Figure 4.3 shows high-level view of our proposed system. There are three major components

of meta execution engine:

1.Workflow Specification,

2.Matchmaker and

3.Workflow Execution.

Fig. 4.2.State Diagram of Workflow Instances

Start

Restart Finish

Cancel

Failure

47

The Workflow specification component is used to specify the MEW as well as user

workflows. Matchmaker component contains list of capabilities of each PSA.

At the execution step, matchmaker assigns different roles to PSAs at run-time depending on

availability of a particular agent at that required time and its capability. Further, after tasks

are assigned to PSA, a MEW is selected and tasks are executed one by one by the Workflow

Execution component. Both workflow specification and workflow execution components

Coordination and ensuring consistency before and after failure

Fig. 4.3 High-level Components for FRWS

Workflow Execution

Assignment of tasks to PSAs

Runtime

Database Tasks

Post events

Task Dispatcher

State Updation

MEW task routines

Workflow

Specification

User Workflow

MEW

Match

Maker

Knowledge base

Metadata (Specification database)

Capability data for PSAs

48

coordinate each other for ensuring consistent execution with respect to specifications and

also during recovery when a failureoccurs. All the workflow specifications (MEW and user

workflows) are stored in specification database (metadata). A knowledge base holds various

definitions of MEWs so that in case of failures or exceptions the execution can be completed

using one of the existing MEW. Run-time information of all workflow instances is stored in

runtime database which is populated while execution. Task Dispatcher picks up tasks from a

pool of ready to execute tasks and is responsible for scheduling the tasks. It is also

responsible for dispatching task instances for execution. Tasks are logged when they are

being executed. The task log contains information pertaining to execution of each task (such

as task name, input and output parameters of the task, and status of the task execution).

There are three types of users in our system: Workflow specifier, Manager and regular User

(PSA).

1. Workflow Specifier: The specifier can specify a MEW and also can select appropriate

MEW from existing MEWs. Initially, Workflow specifier upload the tasks as specified

in the workflows as well as assign PSA to tasks in the system.

2. Manager: A user in this role can create, edit and evaluate workflow instances, and

have access to different workflow definitions specified by various users and can

instantiate new instances of workflows, different workflow definitions specified by

various users and can instantiate new instances of workflows.

3. User (PSA): This kind of user cannot specify or instantiate workflows, but can execute

task instances from its worklists.

We represent the activities of workflow specifier and manager in terms of a workflow as

shown in figure 4.4(a) and figure 4.4(b) respectively.

49

Fig .4.4Representing (a) workflow specifier and (b) manager as workflowsfor admission workflow

The workflow specifier can either instantiate a MEW instance by making use of existing

MEW or add new MEW:

1. Add a new XML file specifying a new MEW workflow.

For example,

a) Start -> Get a task -> Stop, and

Specifier

Add MEW instance Add new MEW Workflow

(a)

Specifier Add new Workflow

Start Insert Review Stop

Get a task

Check Resources

Execute Task

(b)

50

b) Start -> Get a task -> Check resources -> Execute task ->Stop (see figure 4.5)

represent two sample MEW workflows. This allows the manager to use one of the

MEW and accordingly add instances of workflows.

2.

Add

new

workflow instances, as per the system requirement. For example, for admission workflow in

University system,

a.) Start -> Insert the application details -> Stop

b.) Start -> Insert the application details -> Review the application -> Send mail for

acceptance -> Stop.

Manager adds new instances of the workflows. Whenever a manager adds a new instance of

any workflow, a MEW instance runs in the background and coupled with each task of the

workflow. It checks whether each task of the workflow satisfies the MEW workflow, and

accepts or rejects the tasks accordingly. If the task fails at any instance, for example, the task

does not have sufficient resources to fulfill its need, then the system checks for different

levels of failure and performs necessary actions corresponding to each type of failure. The

process continues till the task instance does not fail.

Levels of failure are represented in the following table 4.1.

Table 4.1. Categories of failures handled by execution engine

Fig. 4.5 A Sample MEW

Check Resources Execute Task Stop

Start

Get a Task

51

4.5 Implementation Aspects

We implemented the proposed system using PHP and MySQL. Users can specify MEW as

well as user workflows, create instances of workflows, check their worklists and execute

tasks. A meta execution workflow engine has task scheduler and workflow specifier (figure

4.6). The user can add workflow instances in order to use that workflow and allocate work to

various agents according to their capabilities mentioned in the uploaded XMLs. As an

example, we take seller buyer contract and represent its tasks in fig4.6.

The system can incorporate dynamic changes in the environment and hence updates the

tables whenever changes in problem solving agent or workflow are required. The workflow

Level No. Resolved by Handled by

0 Retrying the workflow task that caused failure Machine/Human

1 Adding and/or Changing the PSA Machine

2 Changing the capabilities of PSA Machine/Human

3 Changing the task Human

4 Adding a new task Human

5 Changing workflow path Machine

6 Add new workflow path Human

7 Changing the MEW used to execute the

workflow instance

Machine

8 Adding new MEW and use it to execute the

workflow instance.

Human

9 Executing workflow instance off-line by using

other means

Human

52

specifier uploads a MEW or may choose an existing workflow from the knowledge base. The

MEW (example shown in figure 4.5) is uploaded in the form of XML file in which the

individual tasks are specified in the following manner:

<task1>

<id> 1 </id>

<task_name> start </task_name>

<event>get_task</event>

<agent> human </agent>

</task1>

Each task has certain attributes such as id, name, event and agent, which can perform that

task (human or system). The specifier can also upload new workflows to be executed.

53

Fig. 4.6 : Tasks of buyer seller contract

Specification file for PSA is shown below:

<psa1>

<id> 1 </id>

<name>krishan</name>

<post> seller</post>

<user_id>krishan</user_id>

<password> **** </password>

<cap1>process_request</cap1>

54

<cap2>send_bid</cap2>

<cap3>choose_carrier</cap3>

<priority> 2</priority>

</psa1>

Here, cap1, cap2 and cap3 tags represent capabilities possessed by the corresponding

PSA. A PSA can have many capabilities. The priority signifies the level of PSA in the

organization hierarchy. The workflow specifier uploads all these details.

This XML is stored in database where the data of PSAs gets stored as shown in table 4.2.

For buyer seller workflow manager and

specifier are mentioned as workflows in figure 4.7.

For the workflow mentioned in figure 4.6, the

tasks are allotted to various agents depending on

TABLE 4.2 : PSA AND THEIR CAPABILITIES FOR SELLER-BUYER E-CONTRACT

Id Name Post user_id Password Capabilities Priority

1 Krishan seller Krishan 123krish Process request,sendbid,Choose carrier 2

2 Vishnu buyer Vishnu Vish1098 Place order,getorder,count desktops 1

3 Narayan carrier Narayan Narayanhu Respond for bid 3

4 Kumar seller Kumar Kumaryun Process request,sendbid,Choose carrier 2

Fig. 4.7 Representing as workflows the tasks done by

(a) workflow specifier and (b) manager for sellerbuyer buyer

55

their capabilities, which are mentioned by the specifier. The role of each agent, assigned on

the basis of capabilities that an agent possesses, is displayed in the worklist of that particular

agent. When matchmaker executes, the tasks are allocated to different PSAs. In table 4.2,

Krishan and Kumar have overlapping capabilities but the priority level is same for both of

them, so allocation of task is done randomly. After task allocation is done and Matchmaker

executes and selected tasks of MEW are executed.

During execution, there may be instances that are running in parallel. The database is

updated in case of instance failures whose status is marked as -1.

The table representing ECA rules is shown below :

An ECA (event-condition-action) rule is triggered based on the event occurred (see Table

4.3), and the necessary workflow is initiated accordingly.

TABLE 4.3 : TASK, CONDITIONS AND EVENTS FOR BUYER SELLER E-CONTRACT

ID Task_name Condition Input Output Event

1 Place Order NULL NULL NULL Get Order

2 Get Order NULL NULL NULL Process Request

3 Process Request NULL NULL NULL Send Bid

4 Send bid NULL NULL NULL Send Response

5 Send Response NULL NULL NULL Choose Carrier

6 Choose Carrier NULL NULL NULL Ship goods

7 Ship goods NULL NULL NULL Check if damaged

8 Check if damaged Yes NULL NULL Return

9 Check if damaged No NULL NULL Count Desktops

10 Return NULL NULL NULL Stop

11 Count Desktops NULL NULL NULL Make Payments

12 Make payments NULL NULL NULL Credit/Cash

13 Credit NULL NULL NULL Stop

14 Cash NULL NULL NULL Stop

TABLE 4.4 : REPRESENTING DATABASE UPDATES AT RUNTIME FOR BUYER SELLER E-CONTRACT

56

When two or more instances run in parallel and any one instance fails, then runtime database

is updated with a status -1 and we try the levels in sequence order for dealing failures. Level

0 is retrying to run the instance. If retrying fails, then we proceed with level 1 which retries

the task by allocating it to another PSA. If the execution is not successful, we continue to

higher levelstill the failure is handled and instance is successfully executed.

Table 4.4 represents status of instances running for each task where i1 to i13 represent the

instance numbers and 0 indicates that instance is currently being executed, -1 indicates that

instancefailed to execute and +1 indicates that instance has been manually withdrawn by the

specifier and 1 indicates that instance executed successfully.

In this way, the proposed system caters to the dynamic changes (change in state of instances

and initiating corresponding workflow on the basis of state) that are made in the system.

ID Task Assigned_t

o

Date i

1

i

2

i

3

i4 i

5

i

6

i

7

i

8

i

9

i10 i11 i1

2

i13

1 Place order Machine 2014-05-

03

1 1 1 +1 0 0 1 1 1 0 -1 1 1

2 Get order Machine 2014-05-

07

0 0 0 0 0 0 0 0 0 0 0 0 0

3 Process

request

Human 2014-05-

10

0 0 0 0 0 0 0 0 0 0 0 0 0

4 Send bid Machine 2014-05-

12

0 0 0 0 0 0 0 0 0 0 0 0 0

5 Send

response

Human 2014-06-

30

0 0 0 0 0 0 0 0 0 0 0 0 0

6 Choose

carrier

Machine 2014-07-

05

0 0 0 0 0 0 0 0 0 -1 0 0 0

7 Ship goods Machine 2014-07-

06

0 0 0 0 0 0 0 0 0 0 0 0 0

14 Stop Machine 2014-07-

09

0 0 0 0 0 0 0 0 0 0 0 0 0

57

The specification workflow starts execution and the specifier uploads the tasks and the PSA’s

in the system. The next task is to execute matchmaker. Matchmaker allocates tasks to PSAs.

After the matchmaker is executed, the execution engine starts executing.

Matchmaker algorithm is represented in the following figure 4.8.

Algorithm: To deal with failures using matchmaker

1: Input: The aborted task with task_status = -1

2: Run_matchmaker()

3: {

4: level = 0;

5: while (task_status = -1 and level <= 9)

6: {

7: try(level);

8: updatetask_status;

9: level++;

10: }

11: }

Fig 4.8: Matchmaker Algorithm

We take same MEW (specified in figure 4.5) for this example. The tasks in MEW execute

step by step and the workflow is executed.

Many processes in traditional workflow engine have been automated in our system such as

changing psa while task execution, changing MEW if task fails when another MEW is used

etc. Also in case of failure of any instance, our system handles the failure and avoids abrupt

terminations. For example, if an instance of a task fails while executing the contract, its status

becomes -1, and thus we retry the process by assigning another PSA for performing the task.

Then the status is changed to 1 once its execution is successful. Suppose, while running the

task "Choose carrier", the instance 10 fails to execute and returns -1. In such case, the match

maker is executed again and the task is retried which in turn leads to successful execution of

task instance and sets i10 to 1 at runtime. Though not impossible, this is a difficult activity in

a traditional workflow engines without human intervention.In case workflow execution does

not complete as Check_Resources task is not fulfilled due to dependencies on more than one

task, then the system prompts the user to change MEW.

There may be other failures that may arise in the system. Consider the case when a buyer

cancels the order before shipment of goods. When the order is cancelled before shipment of

goods, that is after the task Choose carrier is executed, the user cancels the order then the

instance that is currently running returns (-1) Abort state because Check_resources task for

58

MEW corresponding to ship goods fails (table 4.4). This is handled in the system by running

the matchmaker again and assigning the task to another PSA who is capable of handling this

situation by changing the task or by selecting another MEW from the knowledge base. The

algorithm for matchmaker is shown in figure 4.8. The matchmaker starts when task is aborted

(i/e., returns -1). It starts with level 0 which is Retry the task. But if level 0 fails, the level is

incremented by 1 which is Change PSA. In this way, matchmaker keeps trying next levels till

the task_status is changed. We changed (by changing MEW to execute the workflow

instance) the execution logic of the workflow engine to incorporate various cases of failure

and to ensure the consistency.

Table 4.5 represents few of the failures encountered in the system which are handled using

the proposed approach.

Table 4.5 Representing failures encountered in the system

Sr.

No

Case Possible Outcomes/

Exceptions

PSA's

required

Modifications required

1. Execution of “Process

request”.

May execute successfully

or may fail due to inactivity

of allocated PSA

PSA-

Seller-1 is

assigned

initially

Change the PSA from Seller-1

to Seller-2

Results closing the order

(due to non-availability of

required items)

2. While executing the task

“Count Items” if the count

is not equal to the number

of items ordered.

The current workflow

instance aborts execution,

and raise an exception.

PSA-

Buyer

The capabilities of PSA are

changed and corresponding

capabilities are added : return

the order if count is not equal to

the ordered count of desktops,

call for assistance from seller

3. Payment is done in time,

but payment is delayed

due to some issue

(networking) at bank.

This activity needs a check

but there is no PSA who is

responsible for it. So this

activity is in waiting state

(not executed in this case).

A new PSA Pay_Manager is

added in the system who is

responsible for managing all

payment activities and their

dates.

59

CASE 1 :

In case of failure of an instance while executing process request

The system executes the level 0 that is Retries the workflow task that caused failure. So here

the system retries the task of “Process request” again. Now even after retrying if the task fails

then it iterates to level 1 i.e. Changes the problem solving agent used to perform this task.

The task is allocated to some other problem solving agent and if it is successful in completing

the execution then we are done.

In case of failure again, we change the capabilities of the problem solving agent and now the

earlier problem solving agent is capable of performing this task. Further we execute it again

and if there is again a failure we add a new task. Let in this case we change the problem

solving agent from Seller-1 to Seller-2 and then try executing the task “Process Request” and

it gets successfully executed we get rid of system failure.

4. Buyer re-ordered the same

product (assuming that the

previous order is not

through, but not sure

whether it is processed or

not, mainly for on-line

submissions).

This activity causes an

issue due to less

communication between

seller and buyer.

Notify Buyer about re-

order.

PSA-Seller Modify the capabilities of the

PSA seller who was responsible

for processing order, now is also

responsible for informing buyer

that his order has been

processed for the earlier order

and hence indicating the buyer

to cancel the new order

5. Buyer cancelled the order

as the shipment is not

happened by the due date,

but the goods already

started shipment.

Workflow execution may

lead to an issue (not

envisaged during workflow

design).

PSA-3 This problem is resolved using

some offline means so that it

can be executed successfully.

6. Bulk orders placed

(expecting discounts).

Since the current wf does

not check for bulk orders it

will treat bulk orders as

normal orders and no

discount will be given.

PSA-4 Instantiate new workflow, and if

requires change meta execution

workflow

60

CASE 2:

While executing the task “Count Desktops” if the count is not equal to the number of

desktops ordered then it may lead to failure of the system.

It reaches the state Abort. So the failure handling process of our system starts. First it tries to

execute the workflow again, but if this does not work it proceeds to level 1 that is changing

the problem solving agent doing the task. If this also does not work then task is allocated to

another problem solving agent. In case of encountering failure again at this step we change

the capabilities of the PSA. So here in case a buyer does not find the count of desktops equal

to the count he ordered he has a capability to return the desktops or ask the seller to assist

him with finding the remaining desktops. We update the PSA table with corresponding

capabilities.

Sr. No. Name of PSA Capabilities of PSA

1. Seller-1 Process request,sendbid,Choose carrier

2. Buyer-1 Place

order,getorder,countdesktops,makepayment,return

the order if count is not equal to the ordered count

of desktops, call for assistance from seller.

3. Carrier-1 Respond for bid


5. Buyer-2 Place



of desktops, call for assistance from seller

61

CASE 3: Create new PSA

Payment is done through electronic transfer in time, but payment is delayed due to some

issue (networking) at bank.

In this scenario the instance cannot execute further since it sees that the payment is delayed.

In this case we add another PSA in our system who tracks payments and is responsible for

checking when did the buyer make payment. This inturn helps the workflow to run smoothly

and the instances are also executed. The updated PSA table is :



2. Buyer-1 Place


the order if count is not equal to the ordered count of

desktops, call for assistance from seller



5. Buyer-2 Place

order,getorder,countdesktops,makepayment,returnthe

order if count is not equal to the ordered count of

desktops, call for assistance from seller

6. Pay_Manager Manages Payments between parties

62

Case 4 :

Buyer re-ordered the same product assuming that the previous order is not through (made

the order, but not sure whether it is processed or not, mainly for on-line submissions).

In this case we can modify the capabilities of the PSA seller who was responsible for

processing order, now is also responsible for informing buyer that his order has been

processed for the earlier order and hence indicating the buyer to cancel the new order.

The PSA table now becomes like this:


1. Seller-1 Process

request,sendbid,Choosecarrier,Acknowledges

buyer about the order status

2. Buyer-1 Place






5. Buyer-2 Place




63

In this way buyer when receives the acknowledgment that his order has been processed he

will himself cancel the new order placed for the same thing and thereby preventing the

system from any kind of failure.

CASE5 :

Buyer cancelled the order as the shipment is not happened by the due date, but the goods

already started shipment.

To incorporate this failure we try all the levels starting from 0. In this scenario we reach level

9 where we use some other means to execute the workflow instance offline since any other

level could not resolve the failure.

CASE6 :

Bulk orders are given discounts.

When a buyer orders in bulk he should get discounts but in the current workflow that has not

been incorporated anywhere so we add another workflow which checks if it is a normal order

or a bulk order. If it is bulk order then provide the discounts.

The new meta workflow looks something like this:

Apart from the failures mentioned in the table, there can be more possibilities of failures for

example in case of “Carrier lost (damaged in transit)” or ”Goods return (due to non-

6. Pay_Manager Manages Payments between parties

64

satisfactory of goods)”we cater to these kinds of failure thereby making system more

flexible.

4.6 Comparison of traditional WFMS with Failure Resilient Workflow

System

Capability Existing WFMS MEW driven WFMS

Workflow

engine process

Fixed. Workflow

execution engine

processing logic cannot be

changed.

Flexible (can be selected pre-

defined or specify new MEW

based on the execution

context) (section 4.3)

Run-time

changes at

Instance level

Limited facility (when

alternatives are already

specified). Need to be

coded again when

requirements are modified.

Can adapt to modified

requirements with

ease.(section 4.3)

Exception/fail

ure Handling

at Instance

level

Yes, but limited to only

handling expected

exceptions.

Does not work in case of

unexpected exception or

failure that may occur

during task execution.

Handles exceptions and

failures occurring at run time

in a systematic way and avoids

abnormal termination of

workflow instance. (section

4.3)

PSA allocation May get stuck due to

inactivity of problem

Execution will be seamless by

allocating a new PSA when

65

solving agent the present PSA has

failed.(section 4.4)

Evolution: On-

the-fly

addition/modif

ication of

workflows

Not flexible to add new

workflow or modify

existing one during run-

time.

Flexible enough to add new

workflows and modify

existing ones on-the-

fly.(section 4.3)

Table 4.6. Differences between traditional WFMS and MEW

driven WFMS

66

Chapter 5

Failure Prevention

In this chapter we present a methodology to deal with inconsistency that arise during

workflow execution by predicting the failure that can possibly occur while execution. We

capture the task execution in execution log and for each corresponding task the dependencies

at contract elements dependency level (as suggested in Chapter 3) are extracted. Further these

dependencies are used to find failure patterns that can be viewed from past execution logs

and a possible incoming failure is predicted.


Failures during workflow execution lead to system in an inconsistent state. User workflows

may need to be modified to handle such failures. Failure handling at run-time is a challenging

task. So, there is a need to early detection of potential failures from the e-contract

specifications and provide mechanisms to adapt the workflow during run-time in order to

avoid failures during e-contract enactment. In this work, we propose a methodology that

allow the updation of user workflows based on the execution log and the inconsistencies (due

to incorrect process design) derived from e-contract specifications. We use meta execution

workflow and consistency dependency graphs to identify inconsistencies and support

workflow adaption when such inconsistencies leads to failure during e-contract workflow

execution. Our proposed approach helps in building a failure resilient system to support a

seamless execution of workflows.

5.2 Methodology to assess failures

Figure 5.1 represents the execution workflow. Execution log stores the data for success or

failure of each task that gets executed. In chapter 3 we proposed consistency detection graphs

which represent related contract elements in a document contract.

67

Fig 5.1: Representing workflow execution engine

While executing the same document contract if a task execution is logged as fail we look up

its related contract elements from consistency detection graph which helps us in knowing

where the problem lies. The problem maybe with the delay due to party who is responsible

for performing the task or with a clause being violated or it may be due to a particular

pointer. As an example “payment is made at :location” is failed then for any future task if we

get the same :location the current workflow can be stopped and a new workflow can be

instantiated inspite of the current one.

This approach can be extend to finding patterns in data from execution log and consistency

detection graphs. For a task that is logged as failed in execution log, the dependencies for that

particular task can be extracted from consistency detection graph and are stored in

knowledge base of Meta Execution workflow and later on when similar dependencies are

found the task can be predicted as fail and instead of executing the current workflow, a new

workflow can be instantiated.

Thereby for a task in execution we can predict on the basis of past failed tasks that the

current task may fail. In this case the control is passed to MEW. The problem maybe with the

delay due to party who is responsible for performing the task or with a clause being violated

or it may be due to a particular pointer. MEW drives the execution of that failed path by 1.)

changing the workflow path, 2.) instantiating another workflow, 3.) select new workflow

from available workflows, 4.) allows human intervention to add a new workflow which can

handle the failure..

We use the CEDG used in chapter 3 and elaborate the methodology on the same example

with same notations.

68

The algorithm for assessing the failure is represented in figure 5.2.

Algorithm: To assess failure based on execution trace

1: Input: Meta Execution Workflow and User Workflow

2: Output: Possible failures in the system

3: Detect_failure( ):

4: for each task ti to be executed:

5: check the dependencies of failed tasks

6: compare the dependencies of failed tasks

7: if dependencies of ti and failed task have an intersection:

8: add them to knowledge base

Figure 5.2: Algorithm for assessing failure

We take the task “Process Request” with id A10 (Process the raw material) and check for

predicting incoming failureand handling that failure. The execution log till this task gets

executed is represented along with dependencies in Table 5.1 represented below:

Task Task_name Message Dependencies(extracted

from CEDG)

A1 Send Request for

raw material

Fail A2,P1,P4,C2,C3,C4,C6,E1

A2 Request Material Fail A1,P1,P4,C2,C3,C4,C6,E1

A7 Supply raw material Success A8,P4,C2,C3,E1,E2

A10 Process the raw

material

Processing.. A11,P3,C5,C6,E3,E4

Table 5.1: Represents execution log and fetched dependencies

In the table represented above when we look at past failed tasks A1 and A2 we see that both

have a common set of dependencies: {P1,P4,C2,C3,C4,C6,E1}. But when dependencies of

task A7 are checked which is a successful task we get: {A8,P4,C2,C3,E1,E2}. Therefore for

69

a task to fail in future it should not have: Dependencies of failed task – Dependencies of

successful task = {A8, C6}.

From the above result we can say that Clause 6 needs to be checked and fixed. This could be

helpful in dealing any future failure caused due to Clause 6. When task A10 comes up for

execution and it is found that the dependencies of A10 include C6 too so in spite of

continuing the execution of C6 the workflow should be stopped. After stopping the workflow

the control is passed to MEW which drives the execution of this task. Meta execution

workflow iteratively tries to execute the task by changing workflow path, instantiating

another workflow, selecting new workflow from available workflows, allows human

intervention to add new workflows and at the end driving the task to successful execution.

Therefore on the basis of past failures incoming failures can be predicted and handled. After

prediction the data comes into knowledge base where it can be used by Meta Execution

engine to handle the failure.

5.3 Summary

This chapter tries to deal with the problem of predicting failures that arise while executing

workflows in a workflow management system by maintaining an execution log which keeps

the status of each task being executed and uses captured dependencies of contract elements at

the document level to predict the failure of a task. It also makes it easier to deal with the

failure of upcoming task where same kind of failure has been dealt by meta execution

workflow engine previously by retrieving the task dependencies from consistency detection

graphs stored in knowledge base of meta execution workflow.

70

Chapter 6

Case Study

This chapter presents the working of proposed approaches in previous chapters through a

step by step case study. We take a STC contract mentioned in the previous chapters to

demonstrate the work. We start with the document contract and fixing inconsistencies in the

corresponding contract. This has been explained in Chapter 3. Further we take the contract

for its enactment and check if there are any exceptions/failures that arise at run-time, we fix

them using the approaches proposed and hence execute the contract. The execution part has

been explained briefly in Chapter 4. We will elaborate it and explain how it actually works in

implementation.

Example Contract

The EREC diagram for STC contract is shown in figure 6.1

1.1 Activi

ties

Delivery time

> 2 weeks

1.2 Claus

es

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

Rejec

t

Not

sufficient

balance

Fig. 6.1. Extended ER contract diagram for STC 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

71

The parties of STC contract include 1.) STC 2.) Mills 3.) Weavers 4.) Printers 5.) Banks 6.)

Showrooms 7.) Organizations.

The STC contract is a composite contract involving many bilateral contracts such as contract

between 1.) STC and Mills 2.) STC and weavers 3.) STC and printers 4.) STC and

showrooms 5.) STC and organizations.

Step 1.Specification of workflow

There are three users in the system : 1. Specifier 2. Manager 3. Normal User

Specifier uploads the MEW in the system. This is the interface where specifier has option to

upload the MEW.

Figure 6.2 : Interface for adding a new MEW

72

Specifier uploads mew.xml file here. The xml which has been uploaded contains the

following tasks:

<?xml version="1.0" encoding="iso-8859-1"?>

<mew>

<name>mew</name>

<description>mew</description>

<count>5</count>

<task1>

<id>1</id>

<name>start</name>

<postevent>get_task</postevent>

<agent>human</agent>

</task1>

<task2>

<id>2</id>

<name>get_task</name>

<postevent>check_resources</postevent>


</task2>

<task3>

<id>3</id>

<name>check_resources</name>

<postevent>execute_task</postevent>

<agent>machine</agent>

</task3>

<task4>

<id>4</id>

<name>execute_task</name>

<postevent>stop</postevent>


</task4>

<task5>

<id>5</id>

<name>stop</name>

<postevent>NULL</postevent>

<agent>machine</agent>

</task5>

<mew>

73

After MEW has been uploaded, the task workflow of STC contract that needs to be executed are

uploaded.

Figure 6.3 : Interface for adding a new user workflow

And the xml for PSA’s looks as follows:

<?xml version="1.0" encoding="iso-8859-1"?>

<psa_workflow>

<psa_count>5</psa_count>

<psa1>

<id>1</id>

<name>Ram Kumar</name>

<post>Assistant Manager</post>

<user_id>ram</user_id>

<password>ram</password>

<cap1>place_order</cap1>

<cap2>make_payment</cap2>

<cap3>NULL</cap3>

<priority>1</priority>

</psa1>

<psa2>

<id>2</id>

74

<name>lakhansharma</name>

<post>Finance Manager</post>

<user_id>lakhan</user_id>

<password>lakhan</password>

<cap1>send_bid</cap1>


<cap3>NULL</cap3>


</psa2>

<psa3>

<id>3</id>

<name>Hari Raj</name>

<post>Assistant Finance Manager</post>

<user_id>hari</user_id>

<password>hari</password>

<cap1>send_acceptance</cap1>

<cap2>send_rejection</cap2>

<cap3>NULL</cap3>


</psa3>

<psa4>

<id>4</id>

<name>Ratan Sharma</name>

<post>employee</post>

<user_id>ratan</user_id>

<password>ratan</password>



<cap3>NULL</cap3>


</psa4>

<psa5>

<id>5</id>

<name>Raghu Agarwal</name>

<post>employee</post>

<user_id>raghu</user_id>

<password>raghu</password>

<cap1>count_items</cap1>


<cap3>NULL</cap3>


</psa5>

<psa_workflow>

After the workflow has been added, we have a table in the database containing all these details:

75

Figure 6.4 Representing tasks in database added from xml file

PSA table is created in database is as follows:

Figure 6.5: PSA table in database

76

Step 2: Execution of a workflow

When the workflow is executed, the MEW task gets coupled with tasks in User Workflow.

For example we take the MEW task “Process Request” it gets coupled with the user

workflow as represented in figure 6.6.

After successful execution of one user task by MEW, a status “complete” is returned by the

task dispatcher and hence MEW moves on to the next task of user workflow. In this way

tasks are executed one by one towards completion.

Figure 6.6. Representing coupling of a task from user

workflow with MEW tasks

77

Step 4: Check for failures that occur in workflow instance execution

While execution of few tasks if there are no resources available for example PSA is not

available or task can’t be executed due to some other reason the workflow should not stop

there. We have defined states for a workflow namely start, finish, failure, restart and cancel

as 0, 1, -1, 2 and -2 respectively in the runtime database.

For a task instance which has failed to execute due to any possible reason is markedas -1. To

deal with the failure we have stated levels of failure in the previous chapter according to

which we execute the failure handling steps iteratively till workflow is successfully executed.

The database after execution of tasks is in the following condition:

Figure 6.7: Representing failures in execution

Since we observe that status for all the tasks is not 1 and few of them have been marked 1

means these tasks have failed to execute.

We can check failures using Show failures button in the system.

78

Fig. 6.8: Interface showing failures occurred while execution

To handle the failure user can click corresponding handle. Suppose we press Handle

corresponding to Workflow ID 6. The next step is to handle failures :

Fig 6.9: Interface representing steps for failure handling

In our system we have included tasks which can be handled by Machine and for now did not

include the tasks done by human. The next step here is to handle the failure by iteratively

trying these steps. When a user clicks on Retry which is 1st step here the workflow is

executed again. The execution refers to running the matchmaker again that is PSA allocation

to tasks is done again and then the workflow is executed again. In this case it is unsuccessful.

79

In case it would have been successful in handling the failure handling would have stopped at

this step.

The interface for retrying the task with workflow id 6 is shown in the following figure :

Fig: 6.10 : Representing the result of retrying the failed instance

Now we move on to check the next level that is change PSA. We take the available PSA at

that moment who is capable of executing the task and assign the task to him. After this we

execute the instance again. In this case where workflow id is 6 it failed again as shown in fig.

6.11.

Fig. 6.11: Changing PSA

80

After this fails, we move on to the next failure handling step “Change capabilities of PSA”.

In this case user is asked to change capabilities of the PSAand the instance is re-run again. It

is represented in fig 6.12.

Fig. 6.12: Changing PSA Capabilities

Since in this case Hari was assigned send_acceptance task whose instance failed, we add the

capability send_acceptance in Raghu’s capabilities, and re-execute the failed instance. In this

way, the system is capable to deal with different kinds of failures. At the end of failure

handling steps, if the failure is not dealt, then it is withdrawn by the specifier.

6.2 Summary

In this chapter, we presented our approach using a working example starting from

specification to successful execution by combating any kind of exception/failure.We

presented database tables containing specification tables and execution tables and how they

are updated. Existing systems can be augmented with additional mechanismsto handle

failures, for instance, due to dependencies among the tasks. Such mechanisms handle pre-

defined scenarios. However, in real-world applications, it is hard to envisage all kinds of

failures and exceptions during application design. Thus, we introduce configurable workflow

engine control logic, which handles failures as well as exceptions, rather than doing the same

within user workflows.

81

Chapter 7

Conclusion

The work done in the thesis addresses the issue of dealing with consistency issues in an e-

contract. We have developed a methodology to detect inconsistencies in the document

contract and thereby removing those inconsistencies to obtain a consistent contract.We

introduced Sentence Dependency Graph and Contract Element Dependency Graph to

determine the inconsistent activities/tasks specified in an e-contract document.The buyer

seller contract has been used as an example in this thesis work to explain the approach in a

more simplified manner and also demonstrated the usability and applicability of the

suggested approach.

Another important issue that has been dealt is the way of dealing with exceptions/ failures

that occur while executing activities of a contract.State-of-the-art works in the area of

workflows and e-contract systemsprovide dynamic modifications of workflows. However,

there are no systems that allows flexibility during enactment of e-contracts due to evolving

business processes and handle failures without abrupt termination of workflow execution.

This thesis also focus on seamless execution of e-contracts and proposed a system which can

incorporate changes dynamically thereby helps in dealing withexceptions or

failuresoccurring at run time. Towards achieving this, we used the concept of meta execution

workflow and developed a Failure resilient workflow system by designing all the workflow

engine components as workflows. This feature allows easy updation of workflows and also

selects new workflows for instantiation and execution, if required, during the enactment of e-

contract processes. We use the concept of problem solving agents to handle failure by

allocating a failure to an appropriate Problem Solving Agent. Our approach also prevents

possible failures that may occur during e-contract enactment by logging the task data in

execution log and later retrieving dependencies of failed tasks and further find out whether or

not an incoming task would fail.

Future Work:

In our future work, we extend the idea of execution using MEW as a Service to drive

multiple workflow systems where each execution instance can have different

capabilities.This idea ofmoving the code to cloud environment for MEW-as-a-Service enable

the MEW to instantiate appropriate workflow engine (from lightweight to complex)

82

depending on the application requirement.

Using machine learning techniques, we develop a learning sub-system that supports handling

a particular failure and hence, for a new upcoming failure,select a suitable MEW intelligently

rather than involving a human to select another MEW. This would make it easier to select a

particular MEW when a certain case (or a similar case) has been dealt earlier.

We formalize and standardize the data and flow control in the execution of activities. The

formalization can be done using a query language where it would be easy to diagnose all

exceptions and failures that may arise during execution.

83

Bibliography

[1]K. Anushree, P. Radha Krishna and KamalakarKarlapalem, A Methodology and Toolkit

for Deploying Contract Documents as E-contracts, 26th International Conference on

Conceptual Modeling (ER 2007), CRPIT 83, 91-96, 2007.

[2] L. Kutvonen, T. Ruokolainen, J. Metso, and J. –P. Haataja. (2006). Interoperability

Middleware for Federated Enterprise Applications in web-Pilarcos. In D. Konstantas,

J.-P. Bourrières, M. Léonard, & N. Boudjlida (Eds.), Interoperability of Enterprise

Software and Applications (pp. 185–196). Springer London. Retrieved from

http://link.springer.com/chapter/10.1007/1-84628-152-0_17

[3]S. Sharma, KamalakarKarlapalemandP. RadhaKrishna, (2012) A Case for a Workflow

Driven Workflow Execution Engine. In Workshop on Information Technologies and

System. Orlando.

[4] AngelovSamuil and Grefen Paul The 4W framework for B2B e-contractingInt.J.

Netw. Virtual Organ.,pages (78-97), 2003

[5] P. Grefen, K. Aberer, H. Ludwig, and Y. Hoffner, (2000). CrossFlow: Cross-

organizational workflow management in dynamic virtual enterprises. International

Journal of Computer Systems Science & Engineering, 15, 277–290.

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

[7]M. T. Schmidt, Building workflow business objects, object-oriented

programmingsystems languages applications, OOP-SLA’98 Business Object

Workshop, London, pp. 64-76, 1998

[8] J. Metso, and L. Kutvonen, (2005). Managing Virtual Organizations with Contracts.

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

[10]Patrick C. K. Hung, KamalakarKarlapalem: Secure Disconnected Agent Interaction for

Electronic Commerce Activities Using CapBasED-AMS. Information Technology and

Management 3(4): 329-351 (2002)

84

[11] 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

[12]M-C. deMarneffe and C. D. Manning, (2010) Stanford typed dependencies manual,

Stanford Parser Library.

[13] Xusheng Xiao, Amit M. Paradkar, Suresh Thummalapenta, Tao Xie (2012). Automated

extraction of security policies from natural-language software documents. SIGSOFT

FSE 2012: 12

[14] Vincenzo Gervasi, DidarZowghi (2005). Reasoning about inconsistencies in natural

language requirements. ACM Trans. Softw. Eng. Methodol. 14(3): 277-330

[15] Alexander Rush,RoiReichart, Michael Collins, Amir Globerson (2012). Improved

Parsing and POS Tagging Using Inter-Sentence Consistency Constraints ,Association

for Computational Linguistics

[16] P. Radha Krishna, KamalakarKarlapalem, Dickson K. W. Chiu (2004). An EREC

framework for e-contract modeling, enactment and monitoring. Data and Knowledge

Eng. 51(1): 31-58

[17] B. Grosof and T. Poon, (2003). SweetDeal: Representing Agent Contracts with

Exceptions using XML Rules, Ontologies and Process Descriptions, 12th WWW

Conference, ACM Press, pp. 340-349.

[18]Marjanovic, O., Milosevic, Z. (2001). Towards Formal Modeling of e-Contracts. In: The

5th IEEE International EDOC Conference, pp. 59-68.

[19] P. Radha Krishna, KamalakarKarlapalem, (2013). A Methodology for Evolving E-

Contracts Using Templates. IEEE T. Services Computing 6(4): 497-510

[20] P. Radha Krishna, KamalakarKarlapalem, (2008) Electronic Contracts. IEEE Internet

Computing 12(4): 60-68

[21]P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig (2000). CrossFlow: Cross-

Organizational workflow management in Dynamic virtual enterprises, International

Journal of Computer Systems Science and Engineering, 15(5), pp.277-290.

[22] P. Radha Krishna, KamalakarKarlapalem, 2007. “Active Meta Modeling Support for

Evolving E-contracts”, 26th International Conference on Conceptual Modeling (ER

2007), CRPIT 83, pp. 103-108.

http://www.informatik.uni-trier.de/~ley/pers/hd/p/Paradkar:Amit_M=.html

http://www.informatik.uni-trier.de/~ley/pers/hd/t/Thummalapenta:Suresh.html

http://www.informatik.uni-trier.de/~ley/pers/hd/x/Xie:Tao.html

http://www.informatik.uni-trier.de/~ley/db/conf/sigsoft/fse2012.html#XiaoPTX12

http://www.informatik.uni-trier.de/~ley/db/conf/sigsoft/fse2012.html#XiaoPTX12

http://www.informatik.uni-trier.de/~ley/pers/hd/z/Zowghi:Didar.html

http://www.informatik.uni-trier.de/~ley/db/journals/tosem/tosem14.html#GervasiZ05

http://www.informatik.uni-trier.de/~ley/db/journals/dke/dke51.html#KrishnaKC04

http://www.informatik.uni-trier.de/~ley/db/journals/dke/dke51.html#KrishnaKC04

85

[23] M.Reichert, S. Rinderle, and P. Dadam, 2003. “Adept workflow management system:

flexible support for enterprise-wide business processes”, In Proceedings of the 2003

international conference on Business process management (BPM’03), pp. 370–379.

[24] F. Zhang, F. and Y. Du. 2009. “A process generation approach of dynamic workflows

based description logics”, Information Technology Journal, (8), pp.S 998-1005.

[25] KamalakarKarlapalem,Helen P. Yeung and Patrick C. K. Hung. 1995. “CapBasED-

AMS - A Framework for Capability-Based and Event-Driven Activity Management

System”, In Int. Conf. on Cooperative Information Systems (CoopIS 1995) , pp. 205-

219.

[26] J. Eder, and W. Liebhart, 1995. “The Workflow Activity Model WAMO” ,In Int. Conf.

on Cooperative Information Systems (CoopIS 1995).

[27] N. Russell, N., van der Aalst, Wil M.P. and ter Hofstede, Arthur H.M. 2006. “Exception

Handling Patterns in Process-Aware Information Systems”, Technical Report BPM

Center Report BPM-06-04, BPMCenter.org.

[28] M. J. Looise, (2008). Inter-level consistency checking between requirements and design

artefacts, MSc Comptuer Science thesis, Software Engineering, University of Twente.

[29] M. Bastian, S. Heymann, M. Jacomy. (2009). Gephi: an open source software for

exploring and manipulating networks. International AAAI Conference on Weblogs and

Social Media.

[30] J. Eder, and W. Liebhart, “The Workflow Activity Model WAMO”, Int. Conf. on

Cooperative Information Systems (CoopIS), 1995.

[31] E. Elmroth, H. Hernández and J. Tordsson, “A Light-Weight Grid Workflow Execution

Engine, Enabling Client and Middleware Independence”, 7th International Conference

on Parallel Processing and Applied Mathematics (PPAM 2007), Springer Verlag,

LNCS 4967, pp. 754-761, 2007

[32] P. J. Kammer, G. A. Bolcer, R. N. Taylor and M. Bergman, “Techniques for Supporting

Dynamic and Adaptive Workflow”, Journal of Computer Supported Cooperative Work,

Kluwer Academic Publishers vol. 9, no. 304, pp. 269-292, 2000.

1.

2.

3.

http://www.informatik.uni-trier.de/~ley/pers/hd/y/Yeung:Helen_P=.html

http://www.informatik.uni-trier.de/~ley/pers/hd/h/Hung:Patrick_C=_K=.html

http://www.informatik.uni-trier.de/~ley/db/conf/coopis/coopis95.html#KarlapalemYH95