Interorganizational Business Interactions: Contracts, Processes, Evolution

(1)

lution. (Under the direction of Professor Munindar P. Singh).

Business process management in open environments remains a stubborn and important

challenge. In open environments, autonomous organizations having heterogeneous information

systems interact in an ever-evolving manner. The nature of the contractual relationships among

such organizations has a significant bearing on the modeling of the business processes in which

they participate. Conventional approaches are not suitable for open environments because (1) they

lack support for modeling and management of contracts among organizations, (2) the modeling

ab-stractions they offer do not afford crucial software engineering desiderata such as reuse, refinement,

aggregation, and verification, and (3) they fail to provide the designers with guidelines on adapting

the models should the underlying requirements change.

We propose a novel approach for engineering interorganizational business interactions.

Contractual relationships are modeled viacommitments and the interactions for enacting the con-tracts are captured via the modular abstraction of protocols. Relative to how organizations value

the various terms of the contracts and how the contracts are played out via protocols, safety and

benefit of the contracts are reasoned about. A protocol specifies rules that govern the interactions

among the organizations. Protocols can be published to a repository, shared, reused, refined, and

aggregated. We propose a methodology—Amoeba—that guides software designers in the face of evolving requirements on how the protocols and contracts can be adapted.

We evaluate protocols as an abstraction by applying it to model foreign exchange

tions. We find that not only can protocols precisely and adequately capture the necessary

interac-tions, but also that novel interactions having serious business significance can be discovered during

modeling. We propose and evaluate algorithms for checking the correctness properties of the

con-tracts theoretically. We find that our method is sound with respect to pure-strategy Nash equilibria.

Lastly, we evaluate Amoeba via a real-life insurance claim processing case study to handle three

important kinds of changes in requirements: transactional, structural, and contextual. We find that

via Amoeba, the changes can be accommodated simply by composing existing process models with

(2)

by

Nirmit V. Desai

A dissertation submitted to the Graduate Faculty of North Carolina State University

in partial fulfillment of the requirements for the Degree of

Doctor of Philosophy

Computer Science

Raleigh, North Carolina

2007

Approved By:

Dr. Cecil C. Bozarth Dr. James C. Lester

Dr. Munindar P. Singh Dr. Laurie A. Williams

(3)

DEDICATION

To Hina

on the beginning of our

(4)

Biography

Nirmit hails from Ahmedabad, a town in the state of Gujarat, India. He received his M.S. in

Com-puter Science from NCSU in the summer of 2003 and opted to pursue doctoral studies at the same

(5)

Acknowledgements

It has been said that the larger the island of knowledge, the longer the shoreline of mystery. It should

also be said that the longer the shoreline of mystery, the more pivotal the role of the navigators who

guide the paddlers. I am fortunate to be surrounded by navigators who have shown me the way and

helped me paddle through the mysteries to the closure of this work.

I am forever grateful to my advisor Dr. Munindar Singh, for he is the sower of the seeds

of knowledge that have now grown into this dissertation. His teachings and support go well-beyond

this dissertation. I wish to be such a teacher and researcher. If and when I do so successfully, it

would only be because of what I have learned from him.

Knowledge from an academic perspective must be complemented by the experiences from

an industrial perspective. I am deeply indebted to my mentors at IBM Research Drs. Stefan Tai

and Kamal Bhattacharya for exposing me to the essential perspective of the industry research labs.

Kamal went out of his way to ensure that I get the chance to intern at the prestigious Watson

research lab. Stefan not only gave me the chance again, but also mentored and supported me on all

aspects of a research career during my internships. These internships have rounded and enriched

my perspective, contributing to this work and beyond.

The frequent intellectual discussions with my colleagues Amit Chopra, Dr. Ashok Mallya,

Arnav Jhala, Yathiraj Udupi, and Dr. Michael Maximilien have founded, nurtured, and perfected

significant portions of this work. I am indebted for their generous support and intellectual company.

Many individuals have reviewed parts of this work closely and provided me with their critical

sug-gestions that have directly improved the quality of this work. I would like to thank, in no particular

order, Dr. Matteo Baldoni, Dr. Christina Baroglio, Dr. Viviana Patti, Chris Hazard, Scott Gerard,

Dr. Michael Winikoff, Dr. Pınar Yolum, Dr. Nanjangud Narendra, and Dr. Prashant Doshi for their

careful reading and comments on this work.

A significant result of this work was enabled by the support of TWIST committee

mem-bers Matthew Arrott and Bill Specht. I am very thankful to them for providing me with the crucial

understanding of the financial domain and allowing me to use the TWIST foreign exchange

pro-cesses as a case study to evaluate this work.

I am deeply grateful to my advisory committee members Profs. Cecil Bozarth, James

Lester, and Laurie Williams for guiding my energies toward fruitful research directions and advising

me through the various phases of this work. Their valuable criticisms and suggestions have most

(6)

This work was supported by various research grants from NSF, DARPA, and IBM. My

conference travels were supported by scholarships from ACM, IEEE, AAAI, and NCSU. I thank

them for their generous support.

Last but not the least, the sacrifices made by my family overwhelm me. While my wife

has shielded me from all the duties and chores, my parents have patiently let me run my course. My

brother Dr. Kalpit Desai has often corrected me when I am distracted and helped me look both ways

when I am going through critical crossroads. It is only imperative that this work would have neither

(7)

List of Listings

Listing 3.1 Commitment ontology (part 1: declarations) . . . 40

Listing 3.2 Commitment ontology (part 2: operations). . . 41

Listing 3.3 Order protocol . . . 44

Listing 3.4 Commitment ontology (part 3: rules). . . 49

Listing 3.5 Commitment ontology (part 4: rules). . . 50

Listing 3.6 Order with receipt. . . 51

Listing 3.7 Nested commitment in Order protocol . . . 51

Listing 3.8 Querying for commitment safety . . . 65

(11)

List of Figures

Figure 1.1 Insurance claim processing (adapted from the CrossFlow project) . . . 2

Figure 1.2 Scenarios fromIns, Rec, Mon, Han, and Rep in the insurance process . . . 8

Figure 1.3 Conceptual model: business processes based on protocols . . . 9

Figure 2.1 Foamtec contract description . . . 12

Figure 2.2 Foamtec contract in terms of commitments . . . 12

Figure 2.3 A simplified life cycle of commitments . . . 14

Figure 2.4 Relationships among the correctness properties of contracts . . . 27

Figure 2.5 A method for checking correctness properties of contracts . . . 28

Figure 2.6 Transition system for a purchase protocol . . . 29

Figure 2.7 A protocol for proving incompleteness ofchoice . . . 33

Figure 3.1 Life cycle of a commitment in three parts. . . 42

Figure 3.2 Transition system ofOrder and its extension . . . 43

Figure 3.3 A purchasing process . . . 52

Figure 3.4 Protocols in the purchase process . . . 53

Figure 3.5 Exogenous vs. endogenous protocol actions . . . 54

Figure 3.6 Bilateral Price Discovery Processes from [TWIST, b, ch. 7.2.1 and 7.2.2]. . 57

Figure 3.7 Multilateral Price Discovery Process from [TWIST, b, ch. 7.2.3] . . . 58

Figure 3.8 MPD by composing BPD with itself . . . 61

Figure 3.9 Interpretations of some TWIST messages in terms of commitments . . . 63

Figure 4.1 Three elements of requirements of interorganizational business processes . . 69

Figure 4.2 The progression of contractual relationships with composition. . . 75

Figure 4.3 ComposingIns with Rec to produce Bas . . . 77

Figure 4.4 A scenario ofPcsc (pay cash and scrap car) . . . 81

Figure 4.5 Accommodating a transactional change. . . 84

Figure 4.6 Accommodating a structural change . . . 85

Figure 4.7 A scenario ofFra (fraudulent claims detection) . . . 88

Figure 4.8 Accommodating a contextual change . . . 88

Figure 5.1 A process enactment scenario . . . 91

(12)

List of Tables

Table 2.1 Valuations of the buyer and the seller in the purchase example . . . 21

Table 2.2 The pure-strategy Nash equilibrium without commitments . . . 22

Table 2.3 The pure-strategy Nash equilibrium with one commitment . . . 23

Table 2.4 Pure-strategy Nash equilibria with two commitments . . . 24

Table 3.1 Translation ofC+to NCL . . . 37

Table 3.2 MAD-P syntax and its mapping toC+ . . . 46

Table 3.3 Override relationships among concurrent commitment operations . . . 49

Table 3.4 Mapping TWIST price discovery processes to protocols . . . 66

Table 4.1 The main steps of Amoeba . . . 70

Table 6.1 Amoeba evaluated relative to the established criteria . . . 107

(13)

Glossary

A

Agent A concrete computational entity having a legal identity and

acting in the capacity of the adopted roles.

Aggregation Same as composition.

Ambiguity A property of a specification signifying that the specification

has at least one interpretation that is undesirable.

Autonomy A property of an agent signifying its freedom of action.

B

Beneficial contract A contract such that one or all parties are guaranteed to

ben-efit from any enactment scenario.

Business contract Same as contract.

Business-Level semantics A formal encoding of the meanings in terms of concepts

hav-ing business-level significance.

Business logic Same as policy.

Business policy Same as policy.

Business process Same as process.

(14)

C

Choreography A paradigm of service composition that focuses on a global

perspective to capture the pattern of interactions among

ser-vices.

Commitment A legal obligation, that can be manipulated, from a debtor to

a creditor for bringing about a condition.

Composition An act of systematically combining two or more

compo-nents, possibly with additional constraints, to construct a

bigger component.

Contextual requirement A description of the legal rules of encounter that the

organi-zations engaged in business transactions must obey.

Contract A legal document describing the terms and conditions of an

agreement among parties.

Contract enactment An act of carrying out a contract by the actions of the parties

toward satisfying the terms and conditions of the contract.

D

Data-Level semantics A formal encoding of the meanings in terms of concepts

hav-ing data-level significance.

L

Local process A workflow of an organization that is participating in a

busi-ness process.

M

MAD-P A modular action description language for protocol

(15)

O

Open environment A public business environment that is relatively unregulated

and where organizations can freely enter and leave.

Orchestration A paradigm of service composition that focuses on the

per-spective of a composite service invoking other services.

P

Policy A private specification of the business rules of an agent that

govern how the agent plays its roles.

Process Interactions among autonomous agents from a global

view-point.

Process enactment An act of instantiating a process model with agents adopting

the roles and supplying their policies.

Process model A composite protocol and assumed contractual relationships

corresponding to a business process.

Protocol A pattern of interactions among autonomous roles that is

ab-stract, modular, and publishable.

Protocol composition Same as composition.

R

Redundancy A property of a set of specifications signifying that the

cardi-nality of the set can be reduced without altering the

seman-tics.

Refinement An act of systematically modifying a component for specific

requirements.

Requirement A description of what an information system must

(16)

Reusability An ability to use components repeatedly without

modifica-tions to build software systems.

Role The boundary of autonomy in an abstract specification.

Role skeleton A pattern of interactions from the perspective of a role that

is abstract, modular, and publishable.

S

Safe contract A contract such that one or all parties are guaranteed to not

lose value from any enactment scenario.

Structural requirement A description of how the agent contractual relationships within

an organization must be structured.

T

Transactional requirement A description of business transactions an information system

must accomplish.

TWIST Transaction Workflow Innovations Standards Team.

V

Verification An act of formally checking a system for truth or falsity of

correctness properties.

W

(17)

Chapter 1

Introduction

Business process management in open environments remains a substantial and important challenge.

Increasingly, organizations conduct their business over open environments such as the Internet.

Such a trend is motivated by the many benefits envisioned for open environments over traditional

settings [Singh and Huhns,2005]. Specifically, the organizations are autonomous, constrained only by their agreements with others; moreover, their information systems are heterogeneous, enabling

them to make technological choices independent of their partners; and the processes are dynamic,

enabling organizations to refine them easily to keep up with the changing requirements.

However, realizing this vision presupposes substantial research advances. To control

au-tonomy of the organizations, a flexible mechanism to manage the agreements among them is

neces-sary. To support heterogeneity, the interfaces among the partners need to be standardized

indepen-dently of their technological choices. To support dynamism, a mechanism to accommodate changes

in process requirements is needed. While addressing these challenges, engineering desiderata such

as reuse, refinement, aggregation, and verification need to be preserved.

1.1 Motivation

The contributions of this dissertation can be readily appreciated by contrasting it with two common,

but inappropriate, practices in existing business process modeling research; current research (1)

(18)

at the data level, largely ignoring the business-level contracts that they support.

To effectively highlight the challenges and illustrate our approach, we consider an

in-surance claim processing case studied under the CrossFlow project [Browne and Kellett, 1999]. Figure1.1 shows the process flow model taken from the project documentation. AGF Irish Life Holdings (AGFIL), a subsidiary of Allianz, is an insurance company in Ireland. The present

sce-nario deals with automobile insurance. AGFIL underwrites the insurance policy and covers any

losses incurred. Europ Assist provides a 24-hour help-line service for receiving claims. Lee CS

is a consulting firm that coordinates with AGFIL and deals with repairers and assessors to handle

the claims. A network of approved repairers provide the repair services. AGFIL holds ultimate

control in deciding if a given claim is valid and if payment will be made to the repairer. Being a

real-life business scenario previously studied by others, this example provides an independent and

significant test-case for our approach.

Figure 1.1: Insurance claim processing (adapted from the CrossFlow project)

1.1.1 Interactions versus Activities

(19)

services and sets up desired data and control flows among them. Business processes have been

traditionally modeled as workflows, and WS-BPEL reflects this legacy. In essence, activities are the

main abstractions offered by the flow-based approaches.

Workflow-based approaches do not lend themselves well to address the challenges of open

environments [Bussler,2001]. As in this example, traditionally, local processes of the participants are taken as partitions of the global process. Such flows can be understood as composite activities

involving smaller activities. In Figure 1.1, each of the boxes represents a flow and would be the module of abstraction in traditional approaches. By contrast, the interconnections among the boxes

call for more attention in such interorganizational business processes, and these the traditional

ap-proaches do not address adequately.

Flow-based modeling results in a lack of reusable components. The flows are monolithic

in nature, and formed by anad hocintertwining of internal business logic and external interactions. For example, Lee CS may have a policy to behave differently if the estimated cost of repairs is

under a threshold amount. Since such business logic is proprietary, the flow of one agent may not

be available for reuse by another. Moreover, since such business logic is contextual, the flow of one

agent may not be usable by another agent. Consequently, if a new consultant were to participate in

this process, its flow would have to be developed from scratch, even though it would interact with

the other partners in the same manner as Lee CS does.

To illustrate a shortcoming of flow-oriented approaches, it is worth remarking that

Fig-ure1.1does not include the insurance holder. From the standpoint of interactions, this is a major shortcoming. Although the internal flow of the insurance holder’s process (i.e., its box) may not be

important to AGFIL, the insurance holder’s interactions with other parties (i.e., its interconnections)

are crucial and ought to be recognized as such.

1.1.2 Business-Level Semantics versus Data-Level Semantics

In contrast with orchestration, the emergingchoreographyapproaches support a peer-to-peer meta-phor for business processes. Here, the focus is on how the autonomous peers interact with each

other regardless of their internal operations. Choreography efforts include the Electronic Business

Extensible Markup Language (ebXML) Business Process Specification Schema (BPSS) recently

standardized by OASIS [ebBP,2006] and the Web Services Choreography Description Language (WSCDL) [2005] being considered for recommendation by the W3C.

(20)

encoding of thebusiness-levelsemantics. Traditional semantics reflects the occurrence and ordering of tasks (units of orchestrations) or messages (units of choreographies), but fails to identify the

business interactions that these support. For example, existing choreography approaches would

specify that a quote message can be followed by an acceptance or a rejection message, but would

ignore the business commitment that an acceptance of the quote creates. This limitation becomes

more pronounced under requirements evolution, because absent a business semantics, there is no

principled basis for validating a business process or modifying it in a reliable manner.

Recently, semantically rich approaches for SOA-based business process modeling are

gar-nering a lot of attention. The Web Services Semantics (WSDL-S) [2005] project that annotates service descriptions using the Web Ontology Language (OWL) [2004] epitomizes the research ef-forts in the direction of annotating services with semantics. However, these semantic annotations

are data-centric, that is, in a nutshell, they describe the data that the services produce or consume.

Although valuable, description logic-based languages are ill-suited for reasoning about the states of

the contracts and interactions and how they evolve with the actions of the participants. OWL may

describe such phenomena but cannot reason about their properties. For example, verifying such

descriptions for commitment safety or deadlock freedom would require a reasoner specialized for

commitments and actions; a basic description logic reasoner would not do. An analogy would be

that having an ontology for the statements of a programming language in OWL does not mean that

OWL can reason about program termination. Commitments and their safety are explained in details

in Section 2.1.1 and Section 3.4.3. Baader et al. [2005] investigate an approach for combining action logics with description logics. Grossiet al.[2007] propose and apply a similar combination of logics. Both of these works represent the specialization of the description logics that would be

needed for reasoning about actions.

A lack of business-level semantics precludes flexible enactment and reasoning about

com-pliance and correctness. For example, each box in Figure1.1represents a flow that synchronizes at various touch points with other flows. However, the touch points lack a business-level semantics:

they fix the control flow but ignore the business significance of the synchronization. Real-life cases

are rife with subtle business significance. For example, one might ask, does AGFIL eschew the

responsibility for a claim by asking Lee CS to handle it? Is it significant at the business-level if

Europ Assist assigns a claim to a garage before notifying AGFIL? How does it affect the business

relationships if inspectors are directly controlled by AGFIL and not Lee CS? There is no basis for

answering such questions in the absence of an appropriate business-level semantics. Organizations

(21)

regardless of the business-level significance of the deviation.

A lack of business-level semantics also affects the handling of evolving requirements.

Suppose Lee CS wishes to change the way it interacts with the repairers, maybe because of new

service features. Say, Lee CS and the repairer may negotiate an estimate filed by the repairer. Due

to an update in the process of Lee CS, the repairer may no longer be able to interact correctly.

Changes in interorganizational processes affect not only the interactions but also the overarching

contracts supported by the interactions. Additional terms in the contracts may be needed to handle

the new service features. Absent a business semantics, it is not clear what updates to the models

must be made and where, to accommodate such changes. Also, without a business semantics, there

is no basis for checking if the modified contracts are safe and beneficial. Chapter2formalizes the properties of the contracts related to the guaranteed safety and benefits.

1.2 The Proposed Approach

This dissertation addresses some of the key challenges of engineering interorganizational business

processes in open environments. It accommodates autonomy by representing contracts via

com-mitments and techniques for verifying correctness properties of the contracts. Heterogeneity is

supported via protocols that capture interactions among the organizations and abstract out the

pri-vate business logic. Dynamism is supported via Amoeba—a methodology for handling evolving

requirements.

1.2.1 Commitments for Contracts

An organization fulfills its goals by partnering with other organizations and entering into business

contracts with them. Such business contracts form the basis of the business processes that enact

them. The interactions among the organizations and the activities within them have a purpose that

is derived from their overarching contracts. Thus, an approach for business process modeling is

inevitably based on the modeling of the contracts that govern the business processes.

We propose commitments as an abstraction for formally representing business contracts.

Commitments naturally capture the business-level semantics of business interactions. For

exam-ple, a conditional commitmentCC(seller, buyer, pay, goods) means that the seller is committed

(22)

and take actions to enact their contract, the above commitment evolves and tracks the status of

the contract. For example, if the buyer makes the payment, the commitment becomes absolute:

CC(seller, buyer,true, goods). If the seller ships the goods, the commitment is discharged. In

general a business contract is represented as a set of commitments among the organizations.

Before an organization agrees to participate in a contract, it analyzes the contract with

respect to the risks posed and the benefits guaranteed. Such risks and benefits depend upon how

the organization values the various terms of the contract. Business contracts tend to be complex.

In current practice, contracts are often designed by hand and adopted by their participants after

only a manual analysis. This dissertation formalizes two aspects of contract correctness from the

perspective of the preferences of the organizations participating in them. A contract is safefor a participant if participating in the contract would not leave the participant worse off than before.

More strongly, a contract isbeneficialto a participant if participating in the contract would leave the participant better off than before. We present algorithms to partially automate reasoning about the

safety and benefits of formally modeled business contracts.

1.2.2 Protocols for Processes

Once a contract has been agreed upon, the organizations enact it by interacting with each other

toward the satisfaction of their commitments to one another. These interactions constitute the

busi-ness process among the organizations. We propose busibusi-ness protocols as modular abstractions that

naturally capture the business interactions and facilitate superior engineering of business processes.

A business protocol specifies a (conceptually cohesive) set of interactions among two or

more roles. Examples includeOrder placement, Payment, and Shipping. A protocol is

• Meaningful, based on a business semantics given to each interaction in terms of commitments

and other propositions [Yolum and Singh,2002,Winikoff et al.,2005].

• Abstract because, like a component interface, it does not model the proprietary business logic

of the agents enacting its roles.

• Modular because it achieves a specific goal.

Protocols may be composed [Desai et al.,2005]. For example, we may definePurchase as a composition ofOrder, Payment, and Shipping. The same protocols may be composed in different

(23)

in every way: the only difference might be that some protocols exist before the design effort and

some are created during the design effort. As we discuss in Chapter 4, composition is central to the ability to adapt process models according to evolving requirements. Protocol composition

is the mechanism that affords the engineering desiderata of reuse, refinement, and aggregation.

Reuse is achieved as protocols can be composed to develop business processes in different ways.

A repository of protocols can be maintained where protocols are registered. Designers can retrieve

protocols from such a repository and use them or compose them to construct a composite protocol.

New requirements can be captured in a new protocol and composed with the original protocol via

the right set of composition axioms yielding the desired refined protocol. Aggregation is readily

achieved for the composite protocol is an aggregation of the component protocols.

Figure1.2 shows the interactions in the process of Figure 1.1 when modeled as proto-cols. The participants of the process are abstracted as roles in the protoproto-cols. Chapter 4describes the methodology for deriving the protocols from traditionally modeled processes. Essentially,

in-teractions are grouped into protocols according to their purpose. Protocols correspond to multiple

scenarios, Figure1.2shows just one possibility for each protocol. For example, another scenario of Rec would show anauthNOKmessage from the PROVIDERto the CALLCENTER.

Figure1.3 shows the conceptual model underlying our approach. Boxed rectangles are abstract entities, which must be combined with each party’s business logic to yield concrete entities

that can be fielded in a running system (rounded rectangles). Abstract entities can be shared or

published for reuse, refined, and aggregated. Roles are abstract, and are adopted by agents to enable

concrete computations.

Each role’s perspective of a protocol is captured in itsrole skeleton. A role skeleton when integrated with the private business logic of an agent enacting the role yields the agent’slocal

process. Abusiness processis an aggregation of the local processes of all the agents involved. In this way, protocols disaggregate a process in a cross-cutting manner.

1.2.3 Amoeba for Evolution

Because of regulatory and competitive reasons, requirements for business processes often evolve

in subtle ways. As mentioned in Section 1, supporting dynamism means dealing with changing business requirements in a natural manner. Dynamism is crucial because modern businesses must

often reconfigure in the face of regulatory and competitive pressures. We claim that

(24)

Figure 1.2: Scenarios fromIns, Rec, Mon, Han, and Rep in the insurance process

do. This dissertation concentrates on requirements that pertain to interactions among the participants

of an interorganizational process. It proposes guidelines for not only creating a process model but

also modifying it due to evolving requirements.

Following Singhet al.’s classification of architectural patterns for services [2007], we identify three classes of business requirements and changes to them. The identification of the classes

derives from three architectural elements of business processes: the transactions a business process

represents, the organizations that participate in a process, and the overarching context in which the

(25)

1 2..* 1 involves 2..* derives 1 1 Agent adopts 1..* 1..* Local Process 1 1 owns Business Process aggregation of 1 2..* 1 1..* co m p o se d o f 1 1 implementation of 1 1..* im p le m e n ta tio n o f Business Protocol Role Role Skeleton Abstract entity Concrete entity Composite Skeleton Composite Protocol 1 1..* composed of 1 1..* derives defines

Figure 1.3: Conceptual model: business processes understood in terms of protocols and allied concepts

• Transactional. The business transaction that the process seeks to accomplish, e.g., a purchase. An example of change is if we decide to modify a purchase process to include refunds for

damaged goods.

• Structural. The relationships within and among the organizations involved, such as which

party plays which role, or whether a party may delegate or assign certain commitments to

another party. An example of change is when a vendor outsources payment processing to

another party.

• Contextual. The rules of encounter to which the business process is subject. For example,

a contract is voided under fraud by any of the participants. An example of change is when

government regulations change.

Amoeba proposes guidelines for (1) specifying interorganizational processes using

(26)

com-position. We evaluate Amoeba using enhancements of a real-life business scenario of auto-insurance

(27)

Chapter 2

Contracts

Interorganizational business interactions are typically defined by business contracts. A contract

describes the roles and responsibilities of its participants, along with the typical value exchanges

that take place during contract implementation. In current practice, contracts are defined in natural

language, and are often ambiguous.

As a motivating example, let’s consider a real-life business contract as shown in Figure2.1 [Foamtec, 2007]. Briefly, this contract is an agreement among Foamex, AMFS, Foamtec and a Customer. Foam products are to be manufactured in Singapore and shipped to the Customer by

AMFS. AMFS proposes to obtain raw materials from Foamex, ship them to Foamtec, obtain the

finished product from Foamtec, and ship the product to the Customer. The contract merely depicts

the terms and conditions under which the interorganizational interactions take place. It may turn

out to be unsafe or not beneficial for any of the participants. A contract is safe for a participant if

participating in the contract would not leave the participant worse off than before. More strongly,

a contract is beneficial to a participant if participating in the contract would leave the participant

better off than before.

It is not easy for a participant to determine (a) whether it would be beneficial or safe to

enter into this contract, (b) what additional constraints it might place on its interactions to ensure

safety and obtaining a benefit. Whereas contracts often list failure conditions and any associated

penalties, a participant would like to ensure that it is adequately protected. That is, a participant

would like to ensure that the contract is correct from its point of view. Accordingly, this dissertation

(28)

Figure 2.1: Foamtec contract description

preferences, would it be safe or beneficial for that agent to enter into a specific contract?

This dissertation represents a contract as a collection of the participants’ commitments

toward each other [Singh,1999,Wan and Singh,2005]. The interactions that take place to enact a contract are understood in terms of how they operate on the participants’ commitments. The

op-erations on a commitment cause its state to change according to a life cycle (described shortly).

Additional constraints on the interactions are captured via aprotocol, understood as a set of coordi-nation requirements. Protocols are described at length in Chapter3.

(29)

Figure 2.2 depicts the Foamtec contract via commitments. To read this figure, recall that a commitment CC(x, y, p, q) means that x is committed y to bring about q if p is brought

about. A contract would thus be enacted via state changes on commitments. Each such change is

potentially valued by the participants. For example, AMFS’ paying Foamex without a commitment

from Foamex for raw material supply would garner a positive value for Foamex but a negative value

for AMFS.

This dissertation studies correctness from the perspective of an individual participant. It

proposes algorithms for determining the valuation criteria for a participant under which a contract is,

respectively, safe or beneficial for that participant. These algorithms are implemented in a prototype

design tool, using which a contract designer or agent implementer can explore the space of contracts

and protocols that enact them. The contributions of this chapter are to the engineering and analysis

of contracts. While its subject matter touches upon theories of rationality, it makes no general

contribution to the theories of games and rationality. Instead, rationality is used as a motivation

and provides a basis for a soundness test. In particular, we show that if our algorithms produce a

solution, then at least one pure-strategy Nash equilibrium exists.

Section2.1summarizes the key background on the commitment life cycle and valuation constraints. Section2.2introduces new valuation constraints, presents a model for the constraints, and shows how the constraints collectively promote cooperation. Section2.3 formalizes the defi-nitions of safety and benefit as two correctness criteria. Section2.4 presents our main algorithms for checking correctness. Finally, Section2.5presents theoretical results on the properties of these algorithms.

2.1 Background

This section reviews some key background relating to commitments and rationality, which informs

the technical approach developed subsequently.

2.1.1 Commitments

Recall from Section1.2.1that a commitmentCC(x, y, p, q)denotes that xis committed (roughly, obligated) to y to bringing aboutq if pholds. Herep is called the precondition and q the

(30)

Figure 2.3: A simplified life cycle of commitments

is absolutely committed to bring about the condition. Otherwise, it is a conditional commitment.

Commitments, as considered here, can be in one of the five states: act(commitment is in force),

exp(the offer expires on timeout),bas (base commitment, implying the precondition of the

com-mitment is met), sat(the commitment is satisfied as the condition is already brought about), and

vio (the commitment is violated as the base commitment times out). Thus,CC(x, y, p, q) : bas,

CC(x, y, p, q) : vio, CC(x, y,T, q) : act, andCC(x, y,T, q) : expare invalid. We abstract out the

deadlines associated with the commitment and assume the timeouts are exogenous meaning the

agents do not control it. Figure2.3shows a simplified life cycle of a commitment, loosely based on previous works [Desai et al.,2007,Fornara and Colombetti,2003]. Commitments, their lifecycle, the operations that drive it, and their representation are studied at length in Chapter3. In this chap-ter, we consider only the following operations that change the states of the commitments, wherex

andydenote the agents.

• create(x, c)establishes commitmentc.

• detach(y, c) discharges the conditional commitmentc and creates a base commitment with

the same condition.

• discharge(x, c)(c’s debtorx) satisfies the commitment.

Consider, for example, a scenario where a buyer and a seller are exchanging goods for

(31)

obliga-tion from the buyer to the seller that if the goods are delivered, the buyer will pay. In the event

that the precondition goods holds, the conditional commitment changes to a base commitment

CC(buyer, seller,T, payment) : bas. In the event that paymentholds, the buyer’s commitment

is discharged. Commitments do not imply temporal ordering between their conditions and

precon-ditions. For example,paymentmay happen before goods, thus discharging the above conditional

commitment.

2.1.2 States and Transitions

The enactment of contracts, as specified via protocols, can be captured as a transition system.

Sec-tion3.2.1explains how a protocol may be mapped to a transition system. The following discussion is adequate for this chapter.

The states of the transition system consist of fluents and the transitions are labeled with

the actions of agents. Actions may cause the value of the fluents to change, thereby changing the

state. Each actionpcauses a fluentpto hold in the resulting state. Thus, in the following,palways

refers to a fluent caused by an action but not to the action itself. The negation of p is written

p; p captures the fact that p does not hold. Commitments and commitment conditions are state

fluents and commitment operations are actions represented by corresponding fluents. A ‘·’ denotes

a precondition (which may or may not beT). Agents assign values to the states of the world. The

valuations of actions are captured by valuations of the corresponding fluents.

2.1.3 Valuations

This dissertation applies the following basic kinds of values. Note that an agent’s valuation of states

and actions is private and independent of the valuations of other agents. For simplicity, the following

examples assume that money is valued as itself. However, our approach does not depend on such

an assumption.

The value to an agentaof a stateSis denoted byva(S). The valuation function can also

be applied to atomic fluents. We assume that the valuations do not change with time.

• If a fluentp corresponds to an action performed bya, thenva(p)is the cost of performing

the action. This valuation does not take into account the valuation that the agent has for other

effects caused by the action. For example, ifprepresents the fact thatapaid $5, then the value

(32)

pwhich avalues independently ofva(p). Of course, pmay not correspond to an action of

a. For example, ifpcorresponds to a fluent representing the fact thatahas received $5 from

another agent, then the value toaofpmay be $5.

• The value to an agent a of a fluentCC(a, b,·, q) : sat. This valuation does not take into

account the value of the actionsahas to perform to satisfy the commitment. For example, if

the fluent isC(a, b,T,$5) :sat, then the value toaof this fluent may be the improvement to

its reputation due to a commitment being discharged.

• The value to an agentaof a fluentCC(a, b,T, q) :vio. For example, if the fluent isC(a, b,T,$5) :

vio, then the value toaof this fluent may be the penalty it has to pay for violating the

com-mitment. On the other hand, ifadesires disrupting its own business, it derives positive value

by not keeping its own commitments.

• The value to an agent b of a fluent CC(a, b,·, q) : sat. This valuation does not take into

account the value tobof the conditionqbrought about byato satisfy the commitment.

• The value to an agent b of a fluent CC(a, b,T, q) : vio. This valuation does not take into

account the missed value of the conditionqnot brought about byato satisfy the commitment.

For example, if the fluent isC(a, b,T,$5) : vio, thenb may be paid a compensation by the

legal context in which the commitments exist.

2.1.4 Basic Valuation Constraints

Given the above basic valuations, the following are constraints on how agents may value the various

states that may arise during enactment of business contracts. For a given business environment

and a business contract enacted in it, only a subset of these value constraints may hold. Also, we

assume that the agents keep or violate commitments by choice and not because of constraints on

their capabilities or externally caused exceptions.

Performing an action always incurs a cost to the performing agent. If a fluentpcorresponds to an

action performed bya, then

va(p)<0 (2.1)

(33)

This constraint rules out philanthropic agents who may derive positive value out of performing

actions for others.

Debtors value a base commitment higher than the deed, though both are negative.

va(q)< va(CC(a, b,T, q) :bas)<0 (2.2)

This follows from (2.7). Since a debtor benefits from satisfaction of a commitment, it prefers to first commit and then satisfy the commitment via bringing about the condition. Since

bring-ing about the conditionqalways incurs a cost to the debtor, for the debtor, a base commitment

is worse than no commitments.

Creditors assign positive value to the condition of the commitment. IfCC(a, b, p, q) :act, then

vb(q)>0 (2.3)

This implies that commitments are always favorable to the creditors.

Creditors prefer the deed over a base commitment to perform the deed.

vb(q)> vb(CC(a, b,T, q) :bas) (2.4)

This captures the intuition that since debtors may choose to violate their commitments,

cred-itors prefer to have the condition brought about.

Creditors assign positive value to a base commitment.

vb(CC(a, b,T, q) :bas)>0 (2.5)

This accords with (2.3). Being creditor of a base commitments is better than being creditor of no commitment because with a commitment, the prospect of satisfaction of the commitment

remains alive.

Valuation distributes over conjunction of fluents.

(34)

This constraint rules out combinatorial and substitutional valuations. Combinatorial

valua-tions apply when the value of a combination of items is greater than the sum of the value of

individual items. For example, two keys are needed to open a lock, the value of having both

the keys may be greater than the sum of the value of having each key individually.

Substitu-tional valuations apply when the value of a combination of items is less than the sum of the

value of individual items. For example, the value of having both an air ticket and a train ticket

to the same destination on the same day may be less than the sum of the value of having each

ticket individually.

2.2 Proposed Valuation Constraints

This section introduces the enhancements to the above that enable us to formalize contract checking

and develop algorithms for it.

Debtors derive positive value by satisfying commitments.

va(CC(a, b,·, q) :sat)>0 (2.7)

This rules out agents who do not prefer to keep their commitments. It also rules out

environ-ments where keeping a commitment does not increase the reputation of the debtor. In other

words, a debtor prefers to satisfy than not to satisfy its commitment.

For debtors, the benefit of satisfying commitments does not offset the cost of bringing about the condition.

va(CC(a, b,·, q) :sat) +va(q)<0 (2.8)

This rules out environments and agents a debtor’s reputation is valued above the cost of

dis-charging a commitment.

For debtors, the penalty of violation is worse than the cost of discharging commitments.

(35)

This rules out environments in which the violation of commitments may be a better choice

than satisfying commitments. Thus, unlawful agents who prefer to violate their

commit-ments are ruled out. Also, lawless business environcommit-ments where punishcommit-ments for violators are

nonexistent or lenient are ruled out. Note that in the case of multiple commitments, agents

may still choose to violate low-priority commitments to ensure satisfaction of high-priority

commitments. This may happen because the penalties for the low-priority commitments may

be lower than the penalties for the high-priority commitments and the agent cannot satisfy

both. The above constraint still holds.

Debtors create commitments that are beneficial to them.For an agentaifCC(a, b, p, q) :act, then

va(p) +va(q) +va(CC(a, b,·, q) :sat)>0 (2.10)

This rules out irrational agents who create commitments that may not benefit them. In the

case of nested commitments, this applies only to the outermost commitment: the inner

com-mitments may not all be beneficial individually, but the outer commitment as a whole must be

beneficial. A corollary of this constraint is that debtors prefer creating conditional

commit-ments over inaction. However, the value of an active commitment is bounded by the benefit

from the trade corresponding to the commitment.

va(p) +va(q) +va(CC(a, b,·, q) :sat)>

va(CC(a, b, p, q) :act)>0 (2.11)

Creditors assign no value to a discharged commitment beyond the value of the condition.

vb(CC(a, b,·, q) :sat) = 0 (2.12)

Creditors assign no value to a violated commitment beyond the value of the condition.

(36)

Debtors and creditors assign no value to an expired commitment.

va(CC(a, b, p, q) :exp) = 0 (2.14)

vb(CC(a, b, p, q) :exp) = 0 (2.15)

Expired conditional commitments are akin to expired offers. Thus, an expired commitment

has the same value as there being no commitment at all.

2.2.1 Models of Valuation Constraints

The above valuation constraints reflect our intuitions about valuations of commitments and states by

rational agents. However, the consistency of these intuitions needs to be verified. This section shows

that the above constraints have models and thus are consistent. It also shows via an example of trade

that these models promote trade. The following section illustrates the importance of commitments

for encouraging cooperation in business environments.

In the following, astrategyof an agent is its choice of actions at the states of the protocol enacting the contract. An outcomeof a strategy is a state in which the protocol may terminate if the agent follows the strategy. A strategy isdominant for an agent if the agent values all possible outcomes of the strategy higher than the possible outcomes of alternative strategies, regardless of

the strategies of other agents. Apure-strategy Nash equilibriumis a set of strategies, one for each agent, such that no agent can garner higher value than its current strategy by unilaterally changing

its current strategy.

Commitments and Rationality

For the purpose of illustration, let us assume that a buyer and a seller have agreed to trade goods for

money. Also, both the buyer and the seller are rational and have the valuations as shown in Table2.1. These valuations are used in the following only for computing the Nash equilibrium and not for

understanding the preferences of agents as in (2.16) and (2.22)–(2.23). Rather, the preferences of the agents are explained by intuition. Thus, verifying that the preferences are consistent with the

(37)

Table 2.1: Valuations of the buyer and the seller in the purchase example

Seller’s valuation Buyer’s valuation

g −4 6

g 0 0

p 5 −5

p 0 0

Csb :act 0.5 0

Csb :bas −3 4

Csb :sat 2 0

Csb :vio −3 0

Cbs :act 0 0.5

Cbs :bas 3 −4

Cbs :sat 0 2

Cbs :vio −4 0

According to these valuations, like in usual practice, a trade is beneficial to both parties.

First, let us assume an environment where commitments are not enforced. This is typical of open

environments without any regulating agency, and corresponds to assumptions commonly made in

game-theoretic approaches. In this environment, the only possible states areS1 = {g∧p},S2 =

{g∧p},S3={g∧p}, andS4 ={g∧p}. Because the seller is rational, it values these states with the following relationships.

vs(S2)> vs(S4)> vs(S1)> vs(S3) (2.16)

The best scenario for the seller is that the payment is received and the goods are not sent. If commitments are not enforced, the seller would try to achieveS2. Similarly, the buyer would prefer receiving goods and not sending a payment.

By applying (2.6) to (2.16), we have the following inequalities.

vs(g) +vs(p) > vs(g) +vs(p) (2.17)

vs(g) +vs(p) > vs(g) +vs(p) (2.18)

vs(g) +vs(p) > vs(g) +vs(p) (2.19)

(38)

vs(g) > vs(g) (2.20)

vs(g) +vs(p) > vs(g) +vs(p) (2.21)

Table 2.2: The pure-strategy Nash equilibriumwithoutcommitments Send payment Do not send payment

Send goods 1 1 −4 6

Do not send goods 5 −5 0 0

With the valuations of Table2.1, no trades would happen between rational agents as the pure-strategy Nash equilibrium is for both the buyer and the seller to not act, as shown in Table2.2. The cells show valuation of the seller followed by that of the buyer.

Now, let us assume a commitmentCsb =CC(S, B, pay, goods)exists between the buyer

(B) and the seller (S). Hence, the seller has committed to sending the goods if payment is

re-ceived. Also, Constraints (2.1)–(2.15) are in force. For brevity, letgdenotegoodsand letpdenote

payment. In this environment, the only possible states are:

S5 ={Csb:act∧g∧p} S6 ={Csb:bas∧g∧p} S7 ={Csb:sat∧g∧p} S8 ={Csb:sat∧g∧p} S9 ={Csb:vio∧g∧p}

For the seller to send goods, and still benefit from the contract, it should value these states

with the following inequalities while complying with the constraints in force.

vs(S8)> vs(S5)> vs(S7) (2.22)

vs(S8)> vs(S9) (2.23)

In the seller’s valuations, we have the following by intuition: commitment satisfaction above

(39)

Consistency of Constraints

Now let us show that (2.1)–(2.15) are consistent with (2.22)–(2.23). Doing so will prove that there are models of the valuation constraints such that the agents can discharge their commitments and

still benefit individually.

From (2.22)–(2.23), we have the following inequalities. For brevity, the application of the valuation functionvsto the states is assumed and not written out.

(Csb :bas) +g+p > (Csb :act) +g+p (2.24)

(Csb :act) +g+p > (Csb :sat) +g+p (2.25)

(Csb :sat) +g+p > (Csb :vio) +g+p (2.26)

Simplifying (2.24)–(2.26) would give us the following:

(Csb:bas) +p > (Csb:act) +p (2.27)

(Csb:act) +g > (Csb:sat) +g (2.28)

(Csb :sat) +g+p > (Csb:vio) +g+p (2.29)

To prove that (2.20)–(2.21) and (2.27)–(2.29) along with (2.1)–(2.15) are consistent, demon-strating a model is sufficient. It is easy to verify that the valuations of Table2.1 satisfy all of the above constraints, and thus, is a model.

A similar result can be obtained from the perspective of the buyer. The result trivially

extends to generalized commitments, the trading example discussed here is merely an illustration.

However, as shown in Table 2.3, the pure-strategy Nash equilibrium with just one commitment does not promote trade: the commitment motivates the seller but not the buyer. Also, note that the

pure-strategy Nash equilibrium is not a dominant strategy for the seller, but is for the buyer.

Table 2.3: The pure-strategy Nash equilibrium withCC(S, B, pay, goods)

Send payment Do not send payment

Send goods 3 1 −2 6

Let us assume that the buyer and the seller both have commitments to each other:Cbs =

CC(B, S, goods, pay)andCsb =CC(S, B, pay, goods). Constraints (2.1)–(2.15) along with (2.20)–

(40)

S10={Csb :act∧Cbs:act∧p∧g} S11={Csb :bas∧Cbs:sat∧p∧g} S12={Csb :sat∧Cbs:bas∧p∧g} S13={Csb :sat∧Cbs:sat∧p∧g} S14={Csb :sat∧Cbs:vio∧p∧g} S15={Csb :vio∧Cbs:sat∧p∧g}

Given the valuations of Table2.1, the strategy to trade (send goods and send payment, respectively) is the dominant strategy and is one of the pure-strategy Nash equilibria as shown in

Table2.4. This means that no additional constraints need to be enforced for motivating cooperation.

Table 2.4: Pure-strategy Nash equilibria withCsbandCbs

Send payment Do not send payment

Send goods 3 3 ₋₂ ₂

2.3 Contract Correctness

This section introduces our basic terminology and describes correctness properties of interest for

contracts.

Definition 1. A contract is a set of commitments.

For example, a contract C between a buyer and a seller engaged in purchasing can be

represented asC={CC(S, B, pay, goods),CC(B, S, goods, pay)}.

Definition 2. A protocol is a specification of a set of coordination constraints on the actions of agents.

We specify two kinds of coordination constraints. A precedence constrainta≺bmeans

thatamust occur beforeb. A mutual exclusion constraint aXOR bmeans that exactly one ofaor

b must occur. For example, the protocol for the above example may be specified as P={pay ≺

(41)

that exactly one of goodsor paymust occur. In this chapter, we limit ourselves to these

proto-col constraints. Chapter3describes additional meaningful coordination constraints among actions of agents.

Definition 3. An agent is rational if it always chooses a course of action that leads to the most beneficial states in the foreseeable future.

Informally, the foreseeable future is the set of future states that are known to the agents

making the choice. In our formulation, the protocol yields the known future states. A rational agent

would choose the course of action depending on whether or not other agents are known to be

ratio-nal. Here, we only consider rational agents. If all agents are known to be rational to all other agents,

then the agents arepubliclyrational. If all agents are rational but it is not common knowledge, then they areprivatelyrational. We only consider publicly rational agents in the following.

Definition 4. A contract isrationally beneficially omni-correct(rbo) with respect to a set of value constraints if it guarantees that all agents benefit from participating in it as long as the specified

constraints hold, regardless of the protocol.

For example, in the purchase contractC={CC(S, B, pay, goods),CC(B, S, goods, pay)},

given (2.1)–(2.15), both the buyer and the seller benefit regardless of the temporal order in which

payandgoodshappen.

For practical significance, it is more useful to define correctness from the perspective of

individual agents. A contract is correct from the perspective of an agent if the agent benefits from

it.

Definition 5. A contract isrationally beneficially uni-correct(rbu) from the perspective of an agent with respect to a set of value constraints if it ensures that the agent benefits from participating in it

as long as the specified constraints hold.

If an algorithm for checking rbu-correctness for each agent is available then rbo-correctness

can be inferred from it. Also, rbo-correctness implies rbu-correctness for each agent. Guaranteed

benefit may be an unnecessarily strict property. It may be sufficient to check if an agent may incur

losses by participating in the contract.

Definition 6. A contract isrationally safely omni-correct (rso) with respect to a set of value con-straints if it ensures that no agent incurs losses from participating in it as long as the specified

(42)

Definition 7. A contract isrationally safely uni-correct(rsu) from the perspective of an agent with respect to a set of value constraints if it ensures that the agent does not incur losses from participating

in it as long as the specified constraints hold.

By checking rsu-correctness for each agent, correctness can be inferred. Also,

rso-correctness implies rsu-rso-correctness for each agent. For example,C={C(x, y, p)}is rsu-correct fory

relative to the valuationsV={vy(p) >0, vx(p) <0}. However,Cis not rsu-correct forxas it can

only lose by participating in this contract.

Definition 8. A contract isrationally beneficially omni-correctunder a protocol (rbop) with respect to a set of value constraints and a protocol if it ensures that all agents benefit from participating in

it as long as the specified constraints hold and the specified protocol is followed.

For example, in the purchase contract C={CC(B, S, pay, goods)}, given (2.1)–(2.15), both the buyer and the seller benefit as long as the protocol P={pay ≺ goods} is followed. If

the protocol is not followed, the seller may deliver the goods dischargingCC(B, S, pay, goods)and

the buyer will not pay ifvB(pay) < 0 (and if it is rational). Thus, this contract is harmful to the

seller.

A contract may also be correct from the perspective of an agent with respect to a set of

value constraints and a protocol.

Definition 9. A contract is rationally beneficially uni-correct under a protocol (rbup) from the perspective of an agent with respect to a set of value constraints and a protocol if it ensures that

the agent benefits from participating in it as long as the specified constraints hold and the specified

protocol is followed.

In the above example, if the specified protocol does not constrain the order of the seller’s

and buyer’s actions, the contract is not rbup-correct for the seller.

Protocol-based correctness can also be considered relative to safety instead of benefit.

Thus, we can define rsup-correctness and rsop-correctness. This dissertation presents algorithms for

checking rsup and rbup correctness. However, rsop and rbop correctness can be inferred from rsup

and rbup correctness for every agent, respectively. Also, rsu and rbu correctness are special cases

of rsup and rbup correctness with no coordination constraints, respectively. Thus, the algorithms

presented in the following can also be used to check rsu, rbu, rso, and rbo correctness of contracts.

(43)

algo-Figure 2.4: Relationships among the correctness properties of contracts

rithms are needed. The properties of the hollow boxes can be derived via applying these algorithms

in different ways. The higher the property box, the weaker the property. Thus, rbo-correctness and

rso-correctness are the strongest properties whereas rbup-correctness and rsup-correctness are the

weakest properties.

Other interesting properties include correctness relative to partial knowledge of constraints

and knowledge of the rationality of only a subset of agents. We do not study these cases. Correctness

from the perspective of an irrational agent is not defined.

2.4 Checking Correctness

This section first describes the overall methodology and the tools that we have used to

semiauto-matically check the contract correctness properties. Next, algorithms for checking these correctness

properties are presented.

2.4.1 Methodology

Given the constraints imposed on the preferences of the agents due to rationality and the definitions

of the various kinds of correctness properties, we need algorithms to check whether a given

(44)

rbup-correctness and describes how an algorithm for rsup-correctness can be derived from it. As

described above, these algorithms can also be used to compute or infer other correctness properties.

A legal contract is translated to commitments by a contract designer. Methodologies

similar to those proposed by Milosevicet al.[2006] can be adapted for commitments. The contract designer also specifies the protocol coordination constraints for enacting the contract.

Figure 2.5: A method for checking correctness properties of contracts

The protocols along with the commitments can be declaratively specified in an action

logic. As described in Chapter 3, we employ the causal logic C+ [Giunchiglia et al., 2004] as a specification language and the tool CCalc [] for generating the valid states and transitions for

the specified protocol by querying the specifications. The algorithms described below operate on

such transition systems and output a boolean formula of inequality constraints on the valuations of

various protocol states. Such a formula is then evaluated via a SAT solver. The SAT solver is fed

the inequalities that hold due to the constraints of Sections2.1.4and Section2.2. However, not all inequalities can be resolved by those constraints. This is because the states may contain multiple

commitments such that they cannot be ordered. Also, inequalities on the valuations of a business

partner may not be known. Either the contract designer decides on the truth of such inequalities or

the solver assumes them to be false. The truth or falsity of the overall formula reflects whether or

not the contract possesses the concerned property. We have prototyped the requisite tools for such

(45)

the Java Expert System Shell (JESS) [Friedman-Hill,2003] as the SAT solver. Figure2.5shows the steps involved in the method. The dashed edges denote manual steps whereas the solid edges denote

the automated steps. Only the correctness algorithms and the valuation constraints are developed

by us.

2.4.2 Algorithms

Figure 2.6: Transition system for a purchase protocol

We illustrate the algorithms with a purchase protocol which adds an offer message to the

pay-goods example discussed above. The seller (S) makes an offer that creates the commitment.

Payment and goods can be exchanged in any order. Thus, the only coordination constraints are

P={offer ≺pay,offer ≺goods}. Figure2.6shows the transition system generated via CCalc. From each state multiple agents may act simultaneously. Thus, each transition may have

multiple actions, one for each agent. Transitions are labeled with conjunctions of action literals.

Ac-tion literals can be positive (to denote occurrence of the acAc-tion) or negative (to denote nonoccurence

of the action). A transition can have at most one action literal from an agent. Due to protocol

con-straints, if only the nonoccurence of an action is possible from a state, then its literal is discarded

from the transition label. A timeout may cause a transition that is labeled with only negative literals

and is not a self-loop. For example,s1 →s2is a timeout transition.