http://www.cs.ncl.ac.uk/research/groups/distributedsystems/. Abstract. ... ness partnership, the contract will stipulate when purchase orders are to be submitted ...
COMPUTING SCIENCE A Model for Checking Contractual Compliance of Business Operations M. Strano, C. Molina-Jimenez, S. Shrivastava.
TECHNICAL REPORT SERIES No. CS-TR-1094
April, 2008
TECHNICAL REPORT SERIES No. CS-TR-1094
April, 2008
A Model for Checking Contractual Compliance of Business Operations Massimo Strano, Carlos Molina-Jimenez, Santosh Shrivastava. Abstract This paper assumes that business-to-business ({B2B}) interactions between trading partners are being regulated by electronic contracts. The electronic representation of terms and conditions of the contract should be such that it can be utilized at run time for compliance checking of business interactions between trading partners, ensuring that these interactions indeed correspond to meeting the rights and obligations that each partner has promised to honour. With this view in mind, the paper develops a model for establishing a correspondence between events that can be captured from the underlying messaging middleware (e.g., purchase order issued, invoice sent, purchase order canceled, etc) and the sets of rights, obligations and prohibitions that the trading partners have. Any attempt at the establishment of such a correspondence must resolve the technical issues that arise due to the distributed nature of the computation. A particularly difficult problem is establishing the validity of the actions of trading partners when business interactions have encountered software and hardware related problems (e.g., node crashes, clock skews, unpredictable transmission delays, message loss etc.). The model presents a technique for representing contractual rights, obligations and prohibitions of trading partners and shows how the events captured from the underlying messaging middleware can be combined in a careful manner for evaluating contractual compliance. The paper goes on to show how the model can form the basis for developing contract representation languages and run time systems for monitoring and enforcing contract compliance.
© 2008 University of Newcastle upon Tyne. Printed and published by the University of Newcastle upon Tyne, Computing Science, Claremont Tower, Claremont Road, Newcastle upon Tyne, NE1 7RU, England.
Bibliographical details STRANO, M., MOLINA-JIMENEZ, C., SHRIVASTAVA, S. A Model for Checking Contractual Compliance of Business Operations [By] M. Strano, C. Molina-Jimenez, S. Shrivastava. Newcastle upon Tyne: University of Newcastle upon Tyne: Computing Science, 2008. (University of Newcastle upon Tyne, Computing Science, Technical Report Series, No. CS-TR-1094)
Added entries UNIVERSITY OF NEWCASTLE UPON TYNE Computing Science. Technical Report Series. CS-TR-1094
Abstract This paper assumes that business-to-business ({B2B}) interactions between trading partners are being regulated by electronic contracts. The electronic representation of terms and conditions of the contract should be such that it can be utilized at run time for compliance checking of business interactions between trading partners, ensuring that these interactions indeed correspond to meeting the rights and obligations that each partner has promised to honour. With this view in mind, the paper develops a model for establishing a correspondence between events that can be captured from the underlying messaging middleware (e.g., purchase order issued, invoice sent, purchase order canceled, etc) and the sets of rights, obligations and prohibitions that the trading partners have. Any attempt at the establishment of such a correspondence must resolve the technical issues that arise due to the distributed nature of the computation. A particularly difficult problem is establishing the validity of the actions of trading partners when business interactions have encountered software and hardware related problems (e.g., node crashes, clock skews, unpredictable transmission delays, message loss etc.). The model presents a technique for representing contractual rights, obligations and prohibitions of trading partners and shows how the events captured from the underlying messaging middleware can be combined in a careful manner for evaluating contractual compliance. The paper goes on to show how the model can form the basis for developing contract representation languages and run time systems for monitoring and enforcing contract compliance.
About the author Massimo Strano is a PhD student within the School of Computing Science, Newcastle University. Carlos Molina-Jimenez received his PhD in the School of Computing Science at the University of Newcastle upon Tyne in 2000 for work on anonymous interactions in the Internet. He is currently a Research Associate in the School of Computing Science at the University of Newcastle upon Tyne where he is a member of the Distributed Systems Research Group. He is working on the EPSRC funded research project on Information Coordination and Sharing in Virtual Enterprises where he has been responsible for developing the Architectural Concepts of Virtual Organisations, Trust Management and Electronic Contracting. Santosh Shrivastava was appointed a Professor of Computing Science, University of Newcastle upon Tyne in 1986; he leads the Distributed Systems Research Group. He received his Ph.D. in computing science from Cambridge in 1975. His research interests are in the areas of distributed systems, fault tolerance and application of transaction and workflow technologies to e-commerce, virtual organisations and Grid-based systems. His group is well known as the developers of an innovative distributed transaction system, called Arjuna and a CORBA based dependable workflow system for the Internet. He has led and managed several European Union funded, multipartner research projects, beginning with BROADCAST (1992) to a project on complex service provisioning on the Internet, TAPAS, that started in 2002. Together with his colleagues he set up a company in 1998 in Newcastle to productise Arjuna transaction and workflow technologies. Now based within the University campus, Arjuna Technologies is a centre of excellence in transaction technologies and is focusing on building products to support reliable Web Services-based applications. Close industry-university collaboration is guaranteed, and research projects on E-commerce platform and services have been initiated.
Suggested keywords ELECTRONIC CONTRACTS, BUSINESS PROCESSES, MESSAGE-ORIENTED-MIDDLEWARE, RIGHTS, OBLIGATIONS, PROHIBITIONS, EXCEPTION HANDLING
A Model for Checking Contractual Compliance of Business Operations Massimo Strano, Carlos Molina-Jimenez and Santosh Shrivastava School of Computing Science, Newcastle University, UK, {massimo.strano, carlos.molina, santosh.shrivastava}@ncl.ac.uk, WWW home page: http://www.cs.ncl.ac.uk/research/groups/distributedsystems/
Abstract. The electronic representation of terms and conditions in a contract for a business–to–business (B2B) partnership should be such that it can be utilized at run time for compliance checking of B2B interactions, ensuring that these indeed match the rights and obligations that each partner has promised to honour. B2B interactions have several constraints on timing and validity of messages that need to be satisfied for their successful completion. Establishing the validity of B2B interactions is made difficult in the presence of software and hardware related problems. Taking these observations into account, the paper develops a model to represent contractual rights, obligations and prohibitions of B2B partners and shows how the events captured from the underlying messaging middleware can be combined in a careful manner to evaluate contractual compliance.
1
Introduction
In the business world, legal contracts are normally used to regulate the interaction between two or more trading parties. When conducting business electronically, electronic contracts would be needed to regulate business interactions. By regulation we mean compliance checking and/or enforcement of business-tobusiness (B2B) partner interactions to ensure that they comply with the rights and obligations of partners, B2B process specifications and standardized message exchange patterns. Appropriately specified electronic contracts can play a central role in compliance checking and enforcement. Electronic contracts need to specify both functional and non-functional requirements. Functional requirements are equivalent to the terms and conditions of traditional legal contracts, expressing what business operations the partners are permitted, obliged and prohibited to execute. They also stipulate when and in what order the operations can executed. For instance, for a buyer-seller business partnership, the contract will stipulate when purchase orders are to be submitted and within how many days of receiving payment the goods have to be delivered, etc. Non-functional requirements (stated in terms of Service Level Agreements) on the other hand stipulate the requirements of the infrastructure that the business partners use to interact with each other, namely, the quality
of the service. For example, a non-functional requirement might specify that an offered service is expected to provide a response time below 25 milliseconds during business hours. This paper focuses on functional requirements. A primitive B2B message based interaction (referred to as a business conversation) is executed with the intention of exchanging one or more electronic business documents (e.g., a purchase order, invoice). Messages in a given business conversation (as stipulated in industry standards such as RosettaNet Partner Interface Processes[1, 2], ebXML[3]) have various timing and validity constraints for the successful completion of the conversation. Thus a failure to deliver a valid message within its time constraint could cause conflicting views of an interaction (one party regarding it as timely whilst the other party regarding it as untimely). A conflict can also arise if a message is delivered but processed due to some message validity condition not met at the receiver: the sender assumes that the message is being processed whereas the receiver rejected it. Such conflicts will eventually lead the parties to divergent views on the state of the shared business activity, and therefore on contract compliance. Consider for example a buyer who makes a payment: has the buyer met his obligation? Could it be that the payment event, as observed by the seller, occurred after the deadline stipulated in the contract, thus from his view the buyer has not met the obligation? What if the buyer makes a payment within the deadline but, unknown to him, the attempt does not succeed due to a technical problem at the seller’s end? To resolve such issues, we introduce a monitoring component called Contract Compliance Checker (CCC) provided with the specification of the contract in force and capable of observing significant events while the partners are interacting. The function of the CCC is then to maintain a record of events and act as an arbiter to provide answers to the questions raised earlier. It should be clear that, in order to establish the validity of the actions of trading partners with respect to the contract in force, the CCC must take into account the distributed nature of the underlying computations by paying due attention to timing and message validity constraints as well as the impact of any software and hardware related problems encountered during interactions (e.g., node crashes, clock skews, unpredictable transmission delays, message loss etc.). Existing work on contract specification and monitoring has not paid enough attention to these aspects. We remedy the situation by presenting a technique for representing contractual rights, obligations and prohibitions of trading partners and discuss what events need to be captured from (or equivalently, supplied by) the underlying messaging middleware and how they can be combined in a careful manner by the CCC for evaluating contractual compliance. The paper essentially develops a model that underpins the CCC —the main contribution of the paper— and discusses how the model can form the basis for developing contract representation languages and run time systems for monitoring and enforcing contract compliance. This paper is organized as follows. In the next section we present the relevant concepts that underpin our model: contracts, business conversations and the overall event management architecture. In Section 3, we define our basic concepts and present our model. In Section 4, we present an example to illustrate our 2
model using a sample contract. Then we present related work in Section 5. Finally, in Section 6 we present our future research directions.
2 2.1
Background Concepts Contracts
The business scenario that motivated our research is depicted in Fig. 1. The buyer and the seller represent two autonomous organizations that have chosen to conduct business by means of exchanging messages over Internet communication channels. To interact, the buyer and the seller need to expose to each other interfaces to their private business processes (their actual business infrastructure); in the figure these interfaces are represented by the public business processB and public business processS , respectively. To preserve their autonomy, the buyer and the seller conceal behind their public business processes those aspects of their business that they do not wish to disclose; in the figure this is represented by the private business processB and private business processS .
Fig. 1. Private and public business processes.
The whole business interaction between the buyer and the seller can be regarded as the execution of a shared cross–organizational business process, composed out of public business processB and public business processS . Notice that public business processB and public business processS are composed out of a set of complementary business conversations, for example, Purchase Order conversationB and Purchase Order conversationS ; and Notify of Invoice conversationB and Notify of Invoice conversationS [4]. We assume that the buyer and the seller chose to stipulate terms and conditions of their interaction in a conventional business contract. Such a contract is used to derive the cross– organizational business process; that is, the business operations stipulated in the contract are mapped into business conversations. For example, the operation Issue a Purchase Order of clause C1 of our sample contract later in this Section is mapped into a conversation to execute a purchase order. It is worth mentioning that the buyer and the seller are in a peer-to-peer relationship in 3
the sense that both have the potential and means for initiating business conversations. We are interested in the design of contract-derived mechanisms for the observance of contractual terms and conditions; in the figure, this mechanism is represented by the box labelled Contract Compliance Checker. One can extract from a contract a list of clauses stating rights (R), obligations (O) and prohibitions (P), and any associated constraints that the business partners are expected to honour. Informally, a right is something that a business partner is allowed to do; an obligation is something that a business partner is expected to do unless they wish to take the risk of being penalized; finally, a prohibition is something that a business partner is not expected to do unless they are prepared to be penalized. Each contractual party is represented by one or more agents (not necessarily humans), taking on roles to become role players, responsible for initiating and responding to business conversations. Our model can support n role players, but in the scenario presented in this paper we will assume that only two roles, buyer and seller have been defined. As an example, we show below seven clauses from a hypothetical contract where we explicitly identify rights, obligations, prohibitions and constraints. It is worth clarifying that these clauses are not meant to form a complete list; a practical contract would have additional clauses detailing other aspects of the interaction. – C1: The buyer has the right to submit a Purchase Order (Right), as long as it is from Monday to Friday and from 9am to 5pm (Constraint). – C2: The seller has the obligation to accept or reject a Purchase Order within 24 hours (Obligation). If this obligation is not followed upon, the seller will be obliged to pay a fine within 24 hours (Obligation). – C3: If the Purchase Order is accepted, the seller is obliged to submit an invoice within 24 hours (Obligation). – C4: The buyer has the obligation to pay the due amount within seven days of reception of the invoice (Obligation). – C5: Once payment has been received, the seller is obliged to deliver the goods within seven days (Obligation). This will remove all obligations and conclude the contract. – C6: If the buyer does not satisfy the obligation to pay, or cancels the Purchase Order after the goods have been delivered (Prohibition), the buyer will be sanctioned, imposing an obligation to pay a fine (Obligation). 2.2
Business Conversations
Business conversations usually have various Quality of Service (QoS) constraints (timing, security, message validation, etc.). To illustrate this, we take the specific case of RosettaNet Partner Interface Processes (PIPs), that define basic business conversations [1, 2]. Each PIP document specifies the vocabulary and the business process with the choreography of the message dialogue, and includes business action and business signal (acknowledgment) messages. RosettaNet is employed here only as a running example of a possible communication standard. 4
In RosettaNet, a buyer is expected to use the Request Purchase Order PIP 3A4, to express its desire to buy. In a similar fashion, the seller is expected to use PIP 3C3 (Notification of Invoice) to invoice the buyer. A graphical representation of these two PIPs is shown in Fig. 2(a). PIP 3C3: Notify of Invoice buyer seller ficati
base−val
ement
ReceiptAcknowledg
ement
ifi
InvoiceNot base−val action−msg
base−val
base−val
ReceiptAcknowledg
ement
2 hours
PurchaseO
Legend:
base−val
Action Message Signal Message base−val
ReceiptAcknowled
gement
base−val
n rderConfirmActio
1) Error Found: buyer declares PIP executed unsuccessfully. 2) buyer starts execution of Notification of Failure PIP
content−val action−msg
PIP 0A1
Base Validation
(a) RosettaNet PIP 3A4 and PIP 3C3.
seller n cationActio 2 hours
InvoiceNoti
base−val
ReceiptAcknowledg
buyer
onAction 2 hours
2 hours
24 hours
PIP 3A4: Request Purchase Order buyer seller PurchaseOrde rRequestActi on
base−val signal−msg
1) No errors found: seller declares PIP successfully executed and closed. 2) Seller starts execution of next PIP.
next PIP
(b) Base and Content Validation.
Fig. 2. Timelines and validity constraints.
Notice that the receiver of an action message is obliged to acknowledge it by sending a signal message back within two hours. Although each PIP performs a conceptually simple action, in an asynchronous environment, such as the Internet (where communication and processing delays can be unpredictable), we face the problem that the PIP initiator (e.g., seller, for PIP 3C3) and its responder (buyer, for PIP 3C3) could end up with contradictory views of a PIP execution. For example, in PIP 3C3, if the ReceiptAcknowledgment signal message is lost or arrives after the two hour limit, the buyer’s and seller’s views could respectively be successful and failed termination; subsequent executions of public business processes at each end could diverge, causing business level errors. RosettaNet relies on negative acknowledgments to synchronize trading partners at PIP level and minimize the errors propagated to the business application [2]; however, as discussed below, some errors inevitably could propagate to the business level. Both action and signal messages must satisfy what is known as base-validation. This validation is always performed by the receiver’s PIP implementation, verifying against a static set of syntactic and data validation rules. A positive acknowledgment is sent to indicate that an action message has been received and successfully base-validated. A negative acknowledgment is sent to indicate that an action message has been received but failed its base-validation. Action messages must also satisfy what is known as content-validation as well before they can be accepted by the receiver’s business application. Content-validation involves the verification of the semantics of the message against the receiver’s internal business rules. This validation varies from trading partner to trading partner and is normally performed by the receiver’s private business process. 5
The relevance of base and content validation (base-val and content-val, respectively) is illustrated in Fig. 2(b), where for simplicity we use a single action message (PIP 3C3). The figure illustrates how the states of the buyer or seller can become mutually inconsistent when the action message is base-valid but content-invalid. When the buyer discovers the error, it signals a failure to alert the seller; for this RosettaNet provides a special Notification of failure PIP 0A1. Given the wide variety of events that can be generated at both sides of a conversation (send, receive, timeout, retry,. . . ), it is worthwhile to examine if any aggregation can be performed to make only a few significant events visible to the Contract Compliance Checker. Our approach, to be discussed in Section 3.6, is inspired by the ebXML specification [3]; it consists of treating each conversation as an atomic execution unit, the execution of which generates just two events (one per participant) chosen from the set {Success, BusinessFailure, TechnicalFailure}.
3 3.1
Model and Definitions Communications Infrastructure and Architecture
Business conversations are executed over a Message Oriented Middleware (MOM), that takes care of their queueing and delivery. Business partners interact with each other in a loosely coupled manner using the MOM (Fig. 3(a)).
Contract Compliance Checker Contract Repository
Private Business Process B
Public Business Process B
Contract Compliance Checker
Event Composer
Seller
Current ROP sets
Rule consultation
Private Business Process S
Event Queue
Buyer
Public Business Process S
Relevance Engine Historical Queries
Timeo
uts
Rights
Obligs
Prohibs buyer
Rights
Obligs
Prohibs seller
Time Keeper
Event Logger
Message Oriented Middleware
Timeout events Composite events
Event Composer
(a) Communication Infrastructure.
Primitive Events
(b) Components of the CCC.
Fig. 3. Communication Infrastructure with Contract Compliance Checker.
3.2
The Contract Compliance Checker
The Contract Compliance Checker (CCC) is a neutral entity (conceptually located between the interacting parties) that observes the ongoing business transactions and verifies their compliance with the contractual clauses. Fig. 3(b) shows a layout of the internal components of the CCC. The Event Composer is responsible for composing events out of the basic ones received from the MOM and for 6
delivering them to the Event Logger and Event Queue. Examples of basic events are the outcome about the initiation of a conversation and the independent outcomes that each partner declares about the completion of a given conversation (see Section 3.6). The Event Logger keeps a history of the interactions between the business partners as seen by the CCC. The Event Queue holds all composite events awaiting to be processed by an entity called the Relevance Engine (RE) that is responsible for executing any rule triggered by these events. The RE can query the Event Logger when it executes rules with historical constraints. The Current ROP sets are the sets of rights, obligations and prohibitions assigned to the role players (to the buyer and seller in our example) at a given time. The Contract Repository holds the contractual clauses in an electronic format that can be consulted by the RE. The Time Keeper keeps track of the expiry time of rights, obligations and prohibitions. When a timeout expires, the Time Keeper generates a timeout event and forwards it to the Event Logger and to the Event Queue. In this way, the expiration of rights, obligations and prohibitions is regarded as another event. As explained at large in Section 3.8, the responsibility of the RE is to keep the ROP sets updated, adding and deleting operations as the contractual interactions develops. In the rest of this paper, we assume that (1) system clocks are synchronized to a known accuracy to provide a global time base; (2) the Event Composer uses the relevant subscription mechanisms of the MOM to receive events in temporal order; (3) the components inside the dashed box of Fig. 3(a) are reliable; however, the buyer’s and seller’s infrastructure as well as communication lines that link them to the MoM, might fail and recover; and (4) a Trusted Third Party has been used to implement the CCC. 3.3
Role Players, Business Operations, Rights, Obligations, Prohibitions
A role player is an agent (not necessarily human) that takes on and plays a role defined in the contract. We can extract from a contract a finite set B = {bo1 , . . . , bon } of business operations that make up the vocabulary of the shared business process. Any operation not in B is said to be an unknown business operation. In our buyer–seller example, we would have B ={Submit Purchase Order, Accept Purchase Order, ...}. As stated earlier, a given basic operation is performed by executing the corresponding basic conversation. A deadline is a time constraint imposed on rights, obligations and prohibitions. We use an expression t evaluating to a time to represent deadlines; the absence of t is taken as no deadline constraint. Rights are sets of business operations that a role player is allowed to perform; formally, we can define a right as a tuple r = (X, t) where X ⊆ B and t is an optional deadline. In our buyer–seller scenario the right to submit a purchase order (clause C1) is an example of a right with no deadline. A business operation boi ∈ B matches a right r = (X, t) (indicated with boi ` r) if boi ∈ X. An obligation is a role player’s commitment to execute one out of a set of business operations by a deadline; it can be formally defined as a tuple (Y, t) where Y ⊆ B and t is a mandatory deadline parameter. An example of obligation 7
in our buyer–seller scenario is the obligation to pay an invoice within seven days (clause C4). A business operation boi ∈ B matches an obligation o = (Y, t) (indicated with boi ` o) if boi ∈ Y . In our model, we explicitly deal with prohibitions, rather than simply treating them as complement to the sets of rights, in order to distinguish between prohibited operations the execution of which results in sanctions and unexpected operations (within the context of the contractual clauses) that should not be executed by business partners. Therefore we define prohibitions as sets of business operations stipulated in the contract clauses the execution of which results in penalties, formally defined as tuples (Z, t) where Z ⊆ B and t is an optional deadline. A business operation type boi ∈ B matches a prohibition p = (Z, t) (indicated with boi ` p) if boi ∈ Z.
3.4
Sets of Rights, Obligations, Prohibitions and Contract Compliance
We use Rrp , Orp and Prp to represent, respectively, the sets of rights, obligations and prohibitions currently assigned to a role player rp. We use ROPrp to refer to the Rrp , Orp and Prp of a role player rp and ROP sets to refer to the R, O and P of all the role players. A business operation boi matches a role player’s Rrp , Orp or Prp (boi ` Rrp , boi ` Orp , boi ` Prp ) if it respectively matches a right, an obligation or a prohibition in them. The Rrp , Orp and P rp are dynamic: the CCC adds and deletes business operations from them as the cross–organisational business process progresses and the rp exercise their rights and acquire new obligations and prohibitions. With these definitions in mind we can now define contract compliance. At the abstraction level defined by the contract, we say that a given operation bo executed by a role player rp at time t is contract compliant if the execution took place in accordance with the contractual clauses. At the abstraction level where events are manipulated, we say that bo is contract compliant if bo ` ROPrp , that is, bo ∈ B and matches a right, obligation or prohibition assigned to the role player. It follows that non–contract compliant operations for a role player rp can be defined by (B − (Rrp ∪ Orp ∪ Prp )) ∪ B; where B − (Rrp ∪ Orp ∪ Prp ) represents operations in B executed out of context; and B is the complement of B and defines the operations that are not part of the vocabulary (unknown operations). The CCC reacts only to contract compliant operations and ignores non–contract compliant, as it does not have the means to handle them because they were left accidentally or intentionally unspecified by the contract designers. It is worth emphasising that as it is, our CCC is only an observer that makes no assumptions or have control over the behaviour of the interacting partners (it is up to them to honour or violate the contract); the CCC can only tell whether a given operation is contract–compliant or not. Note that a role player rp should never simultaneously be permitted and prohibited (or obliged and prohibited) to execute a business operation at any given time. 8
3.5
Events and Event Attributes
Within the context of our model, events are records about the occurrence of business activities [5]. Events are generated by the business partners as they execute business conversations, or by the Time Keeper component of the CCC when deadlines expire. They have five attributes: the operation type (the type of business operation the initiation or execution of which generated the event, or, in case of a deadline expiry, the type of business operation for which the deadline expired), the originator (the role player that originated the event, such as the buyer in a purchase order), the responder (the role player to which the operation is addressed, such as the seller in a purchase order), the time stamp (the time —as seen by the originator’s clock— of the occurrence the operation), and the status (the outcome of the operation as seen by the originator of the event, see below).
3.6
Event Generation and Composition
Initiation of a Business Conversation: In our model we assume that for each conversation we have a unique initiator and a unique responder. The initiator is the party that initiates the execution the conversation, for example, to exercise a right. The responder is the party invited to converse; he might accept the invitation, deliberately ignore it or be technically unable to respond to it. To cover these possibilities we use an explicit initiation handshake to guarantee that the execution of a conversation starts only when the two parties have agreed to be ready for it. A good example of a handshake protocol is the three-way handshake protocol used to establish TCP connections [6]. The outcome of an initiation handshake is either the InitSuccess or InitFailure event (successful or failure initiation, respectively) generated by the initiator. Execution Outcomes of a Business Conversation: We assume that once the execution of a conversation is started (that is, once InitSuccess has generated by the initiator), it will be eventually and unilaterally declared completed by the two parties. The model, following ebXML specification [3], assumes that eventually each party will independently declare its outcome generating an event with a status of Success, BusinessF ailure or TechnicalFailure, which is reported to the Event Composer. When a party considers that, as far as it is concerned, the conversation completed successfully, it generates the Success event. BusinessFailure and TechnicalFailure events model the (hopefully rare) execution outcomes when a party is unable to reach the normal end of a conversation due to exceptional situations. The BusinessFailure event models failures detected at the business level for example, at content–validation time; for instance, the goods–delivery address extracted from the business document is invalid. The TechnicalFailure event models failures detected at the middleware level, for example, a missing message. In some situations, our model needs the support of the MOM to generate events on the party’s behalf. For example, when a party’s computer system is persistently down, a TechnicalFailure event will be generated by the MOM 9
after failing to receive any responses from the party in question. The combinations of the three possible outcome events from the originator and responder in a conversation execution is summarised in Table 1. The third column represents the status of the composite event computed by the Event Composer. Table 1. Outcomes of Event Combination. Originator Success Success BusinessF ailure BusinessF ailure Success BusinessF ailure T echnicalF ailure T echnicalF ailure T echnicalF ailure
Responder Success BusinessF ailure Success BusinessF ailure T echnicalF ailure T echnicalF ailure Success BusinessF ailure T echnicalF ailure
Composite event Success BusinessF ailure BusinessF ailure BusinessF ailure T echnicalF ailure T echnicalF ailure T echnicalF ailure T echnicalF ailure T echnicalF ailure
The type of the composite event is derived from the operation type and the status of the basic events the Event Composer receives. When a conversation is successfully initiated and its execution started, the status of the composite event is derived from the local outcomes of the execution; when a conversation fails to initiate, its status is InitFailure. Thus, given a business operation boi ∈ B, the Event Composer can compose events matching boi of five possible types, namely, InitSuccess, InitFailure, Successful, BusinessFailure, TechnicalFailure. For example, from the business operation Purchase Order Submission the Event Composer can generate the event types POSubInitSuccess, POSubInitFailure, POSubSuccess, POSubBusinessFailure and POSubTechnicalFailure. Likewise, the composite event is stamped with time as read from the clock of the CCC. 3.7
Rules
In our model rules are Event–Condition–Action (ECA) statements derived from the contractual clauses, converted into an electronic format and stored in the Contract Repository; they can be regarded as the electronic representation of the contract. Rules specify how the ROP sets of the role players change in response to events. A rule has the form r = ((e ≡ eventT ype), {c1 , ..., cn }) → {a1 , ..., am } where e is an event, c1 , ..., cn are historical or ROP constraints, and a1 , ..., am are actions executed if the constraints on the left hand side of the rule are all true. This is an example of a rule: ((e ≡ P OSubmissionSuccess), (P urchaseOrderSubmission ` Re.originator )) 0
→ {Oe.responder + = ({AcceptP urchaseOrder, RejectP urchaseOrder}, ‘24h )}
10
This statement can be read in English as “If the event currently being examined is of type Purchase Order Submission, and its originator has the right to execute Purchase Order Submission, then impose on the responder the obligation to accept or reject the purchase order within 24 hours”. We do not discuss here how rules are derived but assume the existence of a verified set of rules; yet it is worth observing that the correspondence between contractual clauses expressed in natural language and rules stored in the Contract Repository is not one–to–one, but many–to–many. Notice that depending on where and how conditions are expressed and verified, the designer can take different alternatives for converting clauses into rules. The approach taken impacts the functionality and complexity of the Relevance Engine. In our approach (see for example R1 in Subsection 4.2), all the conditions related to event attributes (e.g., valid day to submit a purchase order) are encoded within the rule. However, the condition related to contract compliance (e.g., has the buyer the right to submit a purchase order?) is encoded in the ROP sets. Thus, upon receiving an event, the Relevance Engine needs to inspect both the rule and the ROP sets. Another alternative would be to build a more sophisticated Relevance Engine capable of updating the ROP sets (e.g., adding a right to submit a purchase order on Monday and removing it on Friday) on the basis of information deduced from the conditions encoded in the rule. Event Constraints An event constraint is a Boolean expression of the form e ≡ eventT ype; it evaluates to TRUE if e is of type eventT ype and to FALSE if it is not. For example, the constraint that an event e should be of type POSubmissionSuccess can be expressed as e ≡ P OSubmissionSuccess. Event Attribute Constraints An event attribute constraint is a Boolean expression involving the attributes of an event. As an example, the constraint that the originator of an event should be the buyer role player can be expressed as e.originator == “buyer”. Historical Constraints A historical constraint is a Boolean expression of arbitrary complexity used to query the Event Logger about the existence of one or more events in its historical records. It has the form happened(role player, time interval, event type, status). As an example, the condition imposing the constraint that the originator of an event e has submitted a successful purchase order within the time interval [t, t0 ] is happened(e.originator, [t, t’], PurchaseOrderSubmission, success). ROP Constraints A ROP constraint is a Boolean expression to verify if a business operation matches one of the ROP sets of a role player. It has the form OperationType`ROPSet. As an example, the condition to express the constraint that the originator of an event e should have the right to execute a purchase order is PurchaseOrderSubmission ` Re.originator . 11
Manipulation of the the ROP sets The ROP sets are manipulated by the Relevance Engine with the help of the + = and − = actions used to grant and remove, respectively, rights, obligations and prohibitions from the ROP sets. For example, the right to submit a purchase order without time constraints can be granted to a role player rp by the operation Rrp + = ({P urchaseOrderSubmission}). Such a right can be removed by Rrp − = PurchaseOrderSubmission. Contracts Given the above definitions, a contract can be described as a set of involved parties P , a set of role players R, a set of business operations B and a set of rules R. 3.8
Functionality of The Relevance Engine
The current state of the contractual interaction is determined by the ROP sets since they define what operations the role players are expected to execute next. The job of the Relevance Engine is to update the ROP sets as composite events are reported to it via the Event Queue. This is done by determining which of the rules in the Contract Repository are relevant, that is, the rules for which all constraints are true, especially the all-important ROP constraint. The algorithm executed by Relevance Engine is the following: 1. Fetch the first event e from the Event Queue. 2. Query the Contract Repository to identify the relevant rules for e. 3. For each relevant rule r, execute the actions listed in its right hand side. This normally results in the execution of + = and − = operations on the ROP sets of the two or more role players. A relevant feature of this algorithm is that the CCC ignores all events related to non–compliant operations as there are no relevant rules for them.
4 4.1
An Illustrative Example Analysis of the Sample Contract
To show how our model can be applied, we will analyse the contract between the buyer and seller presented in Section 2. From the contract we can derive R = {buyer, seller} , B = {POSubmission, POAcceptance, PORejection, POCancellation, Invoice, InvoicePayment, GoodsDelivery, FinePayment}, where PO stands for Purchase Order. For each business operation in B, there are five event types: two for its successful and unsuccessful initiation, one for its successful termination, one for its technical failure and one for its business failure. We will assume that at the beginning of the life cycle of this contract, the ROP sets of the buyer and the seller are Rbuyer = {({POSubmission}}, Obuyer = ∅, Pbuyer = ∅, and Rseller = ∅, Oseller = ∅, Pseller = ∅. 12
4.2 From Clauses to Rules Given the role players, the event types and the contractual clauses we can derive the set of rules: ((e ≡ P OSubmissionSuccess), 0
{e.originator = ‘buyer , e.day ∈ [M on, ...F ri], e.time ∈ [9, 17], P OSubmission ` Rbuyer }) → {Oseller + = ({P OAcceptance, P ORejection}, ‘24h‘)}
(R1)
0
((e ≡ P OAcceptanceSuccess, {e.originator = ‘seller , P OAcceptance ` Oseller }) 0
0
→ {Oseller − = ({P OAcceptance, P ORejection}, ‘24h ), Oseller + = ({Invoice}, ‘24h )}
(R2)
0
((e ≡ P OAcceptanceT imeout, {e.originator = ‘seller , P OAcceptance ` Oseller }) 0
0
→ {Oseller − = ({P OAcceptance, P ORejection}, ‘24h ), Oseller + = ({F ineP ayment}, ‘24h )} (R3) 0
((e ≡ InvoiceSuccess), {e.originator = ‘seller , Invoice ` Oseller }) 0
0
→ {Oseller − = ({Invoice}, ‘24h ), Obuyer + = ({InvoiceP ay}, ‘7d )}
(R4)
0
((e ≡ InvoiceP aymentSuccess), {e.originator = ‘buyer , InvoiceP ayment ` Obuyer }) 0
0
(R5)
0
(R6)
→ {Obuyer − = ({InvoiceP ay}, ‘24h ), Oseller + = ({GoodsDelivery}, ‘7d )}
0
((e ≡ GoodsDeliverySuccess), {e.originator = ‘seller , GoodsDelivery ` Oseller }) → {Oseller − = ({GoodsDelivery}, ‘7d )}
0
((e ≡ P aymentT imeout), {e.originator = ‘buyer , InvoiceP ayment ` Obuyer }) → {Rbuyer + = ({F ineP ayment})}
(R7)
0
((e ≡ P OCancellationSuccess), {e.originator = ‘buyer , happened(GoodsDelivery, buyer, success)}) → {Rbuyer + = ({F ineP ayment})}
(R8)
R1 triggers when the buyer submits a purchase order, and imposes on the seller the obligation to accept or reject the order. R2 triggers if the seller accepts the purchase order, imposing on him the obligation to invoice the buyer within 24 hours. The obligation to accept or reject the order, no longer needed, is revoked. R3 triggers if the seller does not fulfil his obligation to accept or reject an order, and imposes the obligation to compensate by paying a fine within 24 hours. R4 imposes a seven day deadline on the buyer to satisfy his obligation to pay his invoice when the seller sends him one. R5 triggers when the buyer successfully pays for his purchase, imposing an obligation on the seller to deliver the goods within seven days. R6 triggers when the paid goods are delivered, and removes the seller’s obligation. R7 and R8 respectively trigger when the buyer does not pay the invoice within the deadline and when the buyer cancels the purchase order after goods delivery; in both rules the buyer is sanctioned, with an obligation to pay a fine imposed on him. 13
4.3
Exception Handling with Rules
Rules bridge the gap between the world of events and the world of rights, obligations and prohibitions, linking captured events with modifications to the ROP sets. Since failure outcomes result in events reported to the CCC, its is possible to handle exceptional situations at rule level; it is left to the contracting parties to decide what rules to include to recover them. As it is, our buyer–seller contract has no provision for handling extraordinary circumstances, yet it is quite possible that failures prevent the two participants from satisfying their obligations. As a first example, let us imagine that the buyer has an obligation to pay an invoice; payment is attempted (that is, the buyer attempts to initiate the a payment conversation) but a technical failure occurs (maybe due to a network or hardware problems in the seller’s side) that prevents the buyer from satisfying his pending obligation. If this happens, the buyer will generate an InitFailure event to be sent to the Event Composer and forwarded to the CCC. An alternative to handle this event is the addition of the following clause to the contract: “The Buyer has the right to have the deadline for payment extended by seven days if attempts to pay an invoice fail due to technical reasons (Right). No extensions to the deadline will be granted if the causes of the failure are of business nature (Constraint)”. The rule expressing this clause will include an event constraint of type InvoiceP aymentInitF ailure to capture failure to initiate the conversation and another one of type InvoiceP aymentT echnicalF ailure to capture technical failures emerging from the actual execution of the conversation: ((e ≡ InvoiceP ayT echnicalF ailure)||(e ≡ InvoiceP ayInitF ailure)), 0
{e.originator = ‘buyer , InvoiceP ay ` Obuyer }) 0
→ {Obuyer − = InvoiceP ay, Obuyer + = (InvoiceP ay, ‘7d )}
This rule extends the deadline by revoking the expired obligation to pay and replacing it with a new one that expires seven days later. This additional time interval will hopefully help to solve the problem that is at the root of the failure. As a second example, we can imagine a situation where the seller fails to fulfil a pending obligation (say, deliver paid goods) due to a business failure. If this happens, the Event Composer will receive a business failure event from the seller, the buyer or both, and generate a composite event of type GoodsDeliveryBusinessFailure to be forwarded to the CCC. To handle the composite event we will add another clause to the contract: “The Seller has the right to have the deadline for delivery extended by seven days (Right) if attempts to deliver goods fail due to business reasons (Constraint)”. This clause can be expressed with this rule: 0
((e ≡ GoodsDeliveryBusinessF ailure), {e.originator = ‘buyer , GoodsDelivery ` Oseller }) 0
→ {Oseller − = GoodsDelivery, Oseller + = (GoodsDelivery, ‘7d )}
14
In practical applications, persistent failures could cause these additional rules to extend the life of the contract beyond reasonable length, and open the door to malicious exploitation, as a party could generate false failures to extend a deadline to its convenience. This can be prevented by adding rules to take care of this, for example sanctioning a party generating more than a given number of failures, or terminating the contract if the number of technical or business failures goes above a given threshold.
5
Related Work
The issue of contract enforcement at run time has been the subject of interest of several researchers. LGI (Law-Governed Interaction)is suggested in [7, 8] as a means of regulating contractual interactions between two or more autonomous and distributed agents (e.g., a buyer and seller). Its basic idea is to place a controller, instrumented with the law (e.g., the contractual clauses), between each agent and the network to intercept messages and enforce the law. Though exception handling is mentioned, this issue is not central to LGI. In [9–11] policy statements are specified in a deontic logic notation to precisely define the permissions, prohibitions, obligations, actions, and temporal and non-temporal conditions that a role player needs to fulfil to satisfy the contract. The expressiveness of deontic notation allows the contract designer to verify (with the assistance of software tools) temporal and deontic inconsistencies in the contract. We acknowledge that we are not the first authors to suggest an event–centric approach (also called, history–based) to model contracts. In [12], for instance, an event–centric mechanism is used to monitor contractual service level agreements: contractual norms (permissions and obligations statements) are activated and deactivated by the occurrence of events. For example, the occurrence of the event “Consumer’s mailbox > N Gigabytes”, activates a norm with a consumer’s obligation to pay a penalty. The actual computation model is event calculus-based, so it offers the user built–in primitives for querying at run time what norms are active and inactive. In this aspect our model bears a strong similarity; the examination of the buyer’s and seller’s current sets of right, obligations and prohibitions in our model, would produce similar results. Heimdhal [13] is another history–based policy engine that is related to our work. It is aimed at enforcing resource usage policies such as “No execution should last more than one second”. The policy monitor in Heimdhal decides what actions are legal, from that perspective it is similar to our relevance engine; however, the policy monitor in Heimdhal is an enforcer as it takes actions to enforce policies when something has to be done, for example, it would abort a job after a second of execution. In contrast, our relevance engine is a passive observer that does not interfere with the business process. It only records all business operations executed by the interacting parties and separates them into contract compliance and contract non–compliance. Another ECA based contract enforcer is discussed in [14]. The central idea here is to mediate the interaction between each pair of com15
munication objects by an enforcing Synchronisation Point (SP) which roughly corresponds to our Relevance Engine; it receives the event triggered by the initiator of the operation (e.g. Submitting payment by credit card); consults the contract clauses stored in a knowledge base and decides whether the operation complies with the contract or not. The operation is allowed in the first case and disallowed in the second. The use of events and rules in business process monitoring is also discussed in [15]. The interest here is in monitoring business situations as seen from a single party. The authors did not consider the possibility of conflicting outcomes; for example, where an order is shipped in time but rejected by the shopper because he considers that it did not arrive in time. In [16] an event–driven–architecture for cross-organisational business processes is discussed; events are used to model normal and exceptional outcomes; however, exceptional outcomes covers only what we call business failures, that is, technical failures are not addressed. The need of exception handling in Web service composition is recognised in [17]. We share with this work the interests in exception handling; however, the computation model here is client–server whereas ours is peer–to–peer. Exception handling in workflow executions is discussed in [18]. Again, we depart from this work as we focus on peer–to–peer interactions. Another work on contract monitoring that mentions exception handling is the ER–EC framework [19]. The exceptions of interest here are those that emerge due to business reasons(e.g., bounced check); unlike ours, this work does not consider exceptions due to technical reasons. A common feature of the above paper and several others available in the literature is that they are mainly focused on the logical aspects of the execution of the business contract or business process and do not consider the distributed nature of the environment where the application executes. In this order, they do not account for exceptional situations due to the message delay, loss, business invalid messages, as we do in our model. In contrast, our approach can be considered implementation–oriented with focus on exception handling due to the distributed nature of peer–to–peer business applications. Our aim is to model potential problems that distributed applications should be able to tolerate. Another common feature of the above mentioned publications is that they aim at contract enforcement. The distinctive feature of the CCC of our work is that it is a passive observer that can be used as the basis for building more sophisticated mechanisms (enforcers for instance). Our approach is also modular: we define the responsibilities of the underlying messaging middleware that supports business conversations, and develop our model that can be used for supporting a variety of business functionalities that include exception handlers, monitors, enforcers and contract specification systems. Synchronisation of loosely coupled business partners by means of handshake synchronisation protocols and publish/subscribe middleware is discussed in [20] and [21], respectively. 16
6
Future Work
There are several ways our model can be used and enhanced for building subsystems for contract compliant business process executions. So far, we have assumed the CCC to be a passive observer. It is clear that the information available to the CCC can be used profitably by business partners. For example, a partner can get the “true” view of the termination of business operations from the CCC, and use that to drive its business process, thereby eliminating (or substantially reducing the occurrences of) the situations that arise due to divergence in views. A natural extension of this idea would be to convert the CCC in a contract enforcer that prevents the partners from performing prohibited operations. The enforcer can also be made proactive whereby it can remind partners of their obligations well before the deadlines. The notation we have used in our illustrative example hints at the type of contract representation language that our model can easily support. We have indeed done some preliminary work on designing a language of this kind [22], and on developing an experimental, simplified implementation of a Relevance Engine on top of the rule engine Drools by JBoss [23]. With this background in place, we believe it is quite possible to carry on our work and design an expressive language for contractual specification and develop a feature rich version of a CCC with enforcing capabilities.
References 1. RosettaNet: Rosettanet implementation framework: Core specification Version V02.00.01, 6 March 2002, http://rosettanet.org. 2. RosettaNet: RosettaNet Implementation Framework, Version V02.00.01: High Availability Features - Technical Recommendation (Dec 2004) 3. ebXML Technical Committee: ebXML Business Process Specification Schema, Technical Specification v2.0.4 (Dec 2006) http://docs.oasis-open.org/ebxmlbp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.pdf. 4. Molina-Jimenez, C., Shrivastava, S., Warne, J.: A method for specifying contract mediated interactions. Proc. of 9th IEEE Int’l Enterprise Distributed Object Computing Conf. (EDOC 2005) (Sept 2005) 106–115 5. Luckham, D.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley (2002) 6. Tanenbaum, A.: Computer Networks. Prentice Hall PTR (2003) 7. Minsky, N., Ungureanu, V.: Scalable Regulation of Inter-enterprise Electronic Commerce. Electronic Commerce: Second Int’l Workshop, Welcom 2001, Heidelberg, Germany, November 16-17, 2001: Proc. (Nov 2001) 8. Minsky, N.: Law Governed Interaction (LGI): A Distributed Coordination and Control Mechanism (An Introduction, and a Reference Manual). (October 2005) http://www.cs.rutgers.edu/ minsky/papers/manual.pdf. 9. Goodchild, A., Herring, C., Milosevic, Z.: Business Contracts for B2B. CAISE* 00 Workshop on Infrastructure for Dynamic Business-to-Business Service Outsourcing (June 2000) 5–6 10. Marjanovic, O., Milosevic, Z.: Towards Formal Modeling of e-Contracts. Proc. of 5th IEEE Int’l Enterprise Distributed Object Computing Conf. (Sept 2001) 59–68
17
11. Milosevic, Z., Dromey, R.: On expressing and monitoring behaviour in contracts. Enterprise Distributed Object Computing Conf., 2002. EDOC’02. Proc.. Sixth Int’l (Sept 2002) 3–14 12. Farrell, A., Sergot, M., Salle, M., Bartolini, C.: Using the Event Calculus for the Performance Monitoring of Service-Level Agreements for Utility Computing. Proc. of First IEEE Int’l Workshop on Electronic Contracting (WEC 2004), San Diego, CA, USA 6 (2004) 13. Gama, P., Ribeiro, C., Ferreira, P.: Heimdhal: A History-Based Policy Engine for Grids. Proc. of the Sixth IEEE Int’l Symposium on Cluster Computing and the Grid (CCGRID’06)-Volume 00 (2006) 481–488 14. Perrin, O., Godart, C.: An approach to implement contracts as trusted intermediaries. Electronic Contracting, 2004. Proc.. First IEEE Int’l Workshop on (2004) 71–78 15. Schiefer, J., Rozsnyai, S., Rauscher, C., Saurer, G.: Event-driven Rules for Sensing and Responding to Business Situations. Proc. of the 2007 inaugural Int’l Conf. on Distributed Event-based systems (2007) 198–205 16. Chakravarty, P., Sigh, M.P.: Incorporating events into cro–organizational business processes. IEEE Internet Computing 12(Issue 2) (March/April 2008) 46–53 17. Zeng, L., Lei, H., Jeng, J., Chung, J., Benatallah, B.: Policy-Driven ExceptionManagement for Composite Web Services. Proc. of the 7th IEEE Int’l Conf. on E-Commerce Technology (2005) 355–363 18. Hagen, C., Alonso, G.: Exception Handling in Workflow Management Systems. Software Engineering, IEEE Transactions on 26(10) (2000) 943–958 19. Radha Krishna, P., Karlapalem, K., Chiu, D.: An EREC framework for e-contract modeling, enactment and monitoring. Data & Knowledge Engineering 51(1) (2004) 31–58 20. Molina-Jimenez, C., Shrivastava, S.: Maintaining Consistency between Loosely Coupled Services in the Presence of Timing Constraints and Validation Errors. Proc. of the European Conf. on Web Services (2006) 148–160 21. Molina-Jimenez, C., Shrivastava, S., Cook, N.: Implementing Business Conversations with Consistency Guarantees Using Message-Oriented Middleware. Enterprise Distributed Object Computing Conf., 2007. EDOC 2007. 11th IEEE Int’l (2007) 51–51 22. Strano, M., Molina-Jimenez, C., Shrivastava, S.: A rule based notation to specify executable electronic contracts. http://tinyurl.com/6a545e (2008) (Draft). 23. Proctor, M., Neale, M., Frandsen, M., Tirelli, E.: Drools, the Rule Management System. Technical report, Technical Report, JBoss.org (2008) http://labs.jboss.com/drools.
18
