Much of the material in this dissertation has been published in conference proceedings or in journal articles as listed below. Some of the material in Chapter 5 was published in 1, while the material in Chapter 6 was published in 3.
Contracts in the Business World
A business operation can be said to be in accordance with the contract if its execution is done in accordance with the rights, obligations and prohibitions of the roles of the players as defined in the contractual clauses. During the execution of a contract, an automated system must be able to handle exceptional situations that affect the normal execution of business operations.
A Contract Scenario
C5: Cancellation of a purchase order by the Buyer removes all obligations for both parties and ends the business transaction. In any other situation, the seller is prohibited from canceling the purchase order after accepting it (prohibition).
Overview of This Work
Implementation of the contract: In this phase, the business partners work together to achieve the goals they have set for the business partnership, according to the patterns specified in the contract. In traditional business practice, human customer agents manage every step of all interactions.
Electronic Contracts for Business Partnership
Desirable Language Features
For example, it must be possible to articulate what the consequences are for the successful submission of a purchase order, without having to delve into the details of the conversation that arises between the parties involved. Exception handling: It should be possible to specify how to handle the consequences of exceptional situations that arise due to the inherently distributed nature of the underlying computations.
The 4W Framework
The rest of this chapter will be devoted to this discussion and to an evaluation of the work presented here in comparison with these. Finally, after a discussion on the legal implications of using e-contracting, the authors use the 4W framework to analyze and discuss two research works, CrossFlow [16] and ebXML [17].
Complex Event Processing and Rapide
It is possible to write such rules in Rapide, which increases the flexibility and power of the language. Furthermore, there is no notable mention of methods for formal verification, despite the complexity of the agent networks that it is possible to specify with Rapide.
The Synchronization Point Model
Another relevant aspect of Rapide and of the model presented in [18] is its treatment of causality between events. These go through process services, abstract representations of the public business processes that participants expose to access in VE.
Law-Governed Interaction and Moses
Since they are both implemented as an extension of actual programming languages, they are both implementable according to the definition presented in Section 2.2.1. They are both sufficiently expressive, as shown by the examples shown in [22] and in the numerous examples in the Moses documentation.
Heimdahl
It is not possible to prohibit actions that could have negative consequences or that are not allowed during a given period of business relationship. Although formal verification methods can be devised for this language, the authors did not address this topic in the works presented here.
Business Contract Language and Business Contract Architecture
As for BCL, when analyzed in light of the criteria outlined in Section 2.2.1, it can be said to be declarative and expressive. Implementability is guaranteed by using the model-driven approach described in [30]; a carefully written transformation metamodel will replace any non-implementable contractual clause in the business model into an implementable one in the target model.
Non Intrusive Monitoring and BPEL
This means that one of the shared services has made an assumption about this request that is inconsistent with other assumptions for the service it is using. Finally, the work presented by the authors covers in depth two of the three areas required for a complete business interaction monitoring system, discussing a detailed theoretical model and a language for describing the knowledge required for monitoring.
Defeasible Logic in RuleML
Real life contracts often contain provisions to deal with unfulfilled obligations, and usually these provisions impose obligations contrary to duty in an effort to recover from the breach of contract. However, the communication model of the business partners is not discussed, so it is not clear how the monitoring is actually carried out.
SORM and Cremona
Not all obligations are imposed as a result of an OR state change; some, the background obligations, are in effect independently of the current state, and can be imposed or removed without interfering with it. If examined in light of the list of relevant research areas from Section 2.2, it fits best with the Contract Representation Language area (even though it specializes in the Negotiation Stage); a theoretical model is given attention.
EU CONTRACT Project
Identifying the components and services used by agents to play their roles in the partnership. As for the contract representation language, which is the work of another research group, it can be analyzed in light of the features described in section 2.2.1 in this way.
EROP in Context
- Instantiation of Contracts
- The EROP Ontology
- Formal Definitions: Deadlines, Rights, Obligations and Prohibitions
- Contract Compliance of Business Operations
The model for non-intrusive monitoring (NMI) presented in [35] shares with the EROP model the reification of exceptional outcomes of the execution of a business operation. The history of the business transaction before the operation corresponds to what is stipulated in the contract.
Execution of Business Conversations
Execution Model
The impact of base and content validation is shown in Figure 3.4, which illustrates how buyer and seller states can become mutually inconsistent when an action message is valid in terms of base but invalid in terms of content. The output from this is an explicit synchronization of the results, as explained in the next subsection.
Outcome of Business Operations
Specifically: (a) events with the same outcome are combined into a composite event of the same type; (b) if one of the event outcomes is TecFail, then the composite event is of type TecFail, regardless of the type of the other event; (c) if one of the output events is BizFail and the other is Success, then the composite event is of type BizFail. BizFail BizFail BizFail Success T ecFail T ecFail BizFail T ecFail T ecFail T ecFail Success T ecFail T ecFail BizFail T ecFail T ecFail T ecFail T ecFail.
Contract Compliance Checker
Assumptions
This resolution process will be able to make use of the historical data stored by the Event Logger, a part of the CCC introduced in the next subsection. The transmission and processing delays (TPD) from the synchronization facilities to the CCC's Event Queue, discussed below, are limited and known.
Architecture of the CCC
Verification of Compliance by the CCC
Representation of Contractual Clauses with Rules
Structure of a Rule
For example, the constraint that the event must be of type POSubmission can be expressed as≡P OSubmission. For example, the constraint that the originator of an event must be a customer role player can be expressed as ase.originator == "customer".
Exception Handling in EROP
In the first scenario, the payment is made in the first attempt within the seven-day period (7d). In the last scenario the payment succeeds on the second attempt (Pay Success) while the seller successfully exercises his right to cancel (Seller Canc. Success) after the buyer's first attempt to pay fails (Pay BizFail); if payment execution Success and Seller Canc.
Declaration Section
This chapter will introduce the EROP language, providing an informal overview of its features and syntax, and the full EROP version of the sample contract presented in Section 1.2. The examples and bits of code in this chapter all come from the EROP version of the Buyer-Seller contract that will be presented in Section 4.4.
Rule Syntax
Trigger Block
- Event Matches
- Event Field Constraints
- ROP Set Constraints
- Historical Constraints
In the case of a Timeout, this is the name of the role player expected to initiate the execution of the business operation that timed out. In the case of a Timeout, this is the name of the role player that was expected to respond to the operation that timed out.
Action Block
- ROP Set Manipulation
- Conclusion of a Contract Instance
- Conditional Statements
The if-then-else statement is used, as in normal programming, to allow conditional execution of actions on the right-hand side of rules depending on the value of a boolean expression. These are the keywords Success, TecFail, BizFail, InitFail, Other and are used to identify action blocks to be executed in the event that the event under control has an outcome status of Success, Technical Failure, Business Failure, Initialization Failure, or any which is not covered by the same rule.
The Buyer-Seller Contract in EROP
Rule R2Rejection is also derived from clause C3, but it is triggered when the seller rejects a purchase order. Rule R8Timeout also derives from clause C6 and is triggered when the seller's obligation to deliver the purchased goods expires.
Conclusion
Introduction
The goods that do not conform to the service quality agreement will be replaced by the supplier (obligation) within 3 days of notification by the buyer (right), otherwise the supplier (buyer) will refund the money and pay a penalty of USD 1000 to the buyer. (Obligation). Prices are as stated in the sales order, unless otherwise agreed in writing by (Supplier).
EROP Version
Rule R2 below derives from clause 6.1, and deals with the case of the buyer failing to fulfill his obligation to pay for the goods ordered. In this rule, a successful payment is detected as late as there is a time lapse for the obligation to pay in the history of the transaction.
Scenario: Travel Agency
Scenario
C5: If payment by other means mentioned above fails in any way, the transaction is terminated and both parties lose all pending rights, obligations and estoppels. As can be noted in point C4, all types of failures (initial, business and technical) are taken into account, both for credit card payments and for payments using other means.
EROP Version
C6: If the payment is successful, the travel agency is obliged to deliver the necessary items to the customer within four days. The following rule removes the customer's obligation to pay by credit card and imposes a new payment by other means if the credit card payment fails for the third time, as set out in clause C4.
Rental of Grid node time
Scenario
EROP Version
Scenario: Music Streaming Service
Scenario
EROP Version
Pursuant to clause C3, if a user does not renew a subscription (that is, if the obligation to subscribe again times out), then the user reverts to a free subscription and Pandora regains the right to advertise. In this case, music playback will fail and the user will be entitled to request a refund.
Discussion
- Declarative Approach
- Inheritance
- Implementability
- Expressiveness
- Exception Handling
- Usability
- Verifiability
- Scale
- Context
- Language Translation and Checking
Thus, the problem of maintaining implementability is avoided by only allowing implementable constructs in the definition of the EROP language. A real-life EROP system would come with a full set of tools for the language, as presented in Chapter 4, to verify the syntactic correctness of the contracts written by EROP users and to translate it into a form that can be used directly by CCC.
Implementation Choices
Database Engine
Decision Engine
The reason for choosing a rule engine to power the Relevance Engine is the small semantic gap between EROP rules and business rules; as previously discussed in Chapter 4, EROP rules are fundamentally business rules that make use of the EROP ontology. Another notable feature is the possibility to write the consequences of rules (their right-hand sides, which in EROP are mainly actions) directly in a programming language (specifically Java, Python and Groovy).
Implementation of the EROP Ontology
The EROP Ontology
Obligation (simple): A business operation that a role player must perform or be penalized. Prohibition: A business operation that a role player is not allowed to perform, or he will be penalized.
Ontology Implementation
ROP Set: A set (possibly empty) of all rights, duties, and prohibitions in effect for a Role Player at any given time. Business transaction: the entirety of the performance of a contract, from the moment it commences to its successful or unsuccessful conclusion.
The Contract Compliance Checker
Prohibitions are treated explicitly in the EROP model instead of being treated as a supplement to rights or as negative obligations. The Relevance Engine relies on an instance of Drool's rule engine to power its decision-making capabilities.
The Historical Database
Tables
The relevance engine is sent a signal every time a new event is added to the queue; finally the RE takes the first Event object in the queue and feeds it to the Drools engine instance. It is this last component that matches the Event and its context (history, etc.) to the rule base, identifies the relevant rules, and performs their right-hand actions.
Historical Queries
These methods construct SQL queries for the historical database from the received parameters, submit them to the database server, then parse the results and return them. According to the SQL standard, the result of the query is the number of rows in the event history table that record events within the desired limits.
Translation
Augmented Drools
The problem of creating an appropriate implementation for the EROP language thus becomes a problem of translating EROP to Augmented Drools. We will show in the rest of this section how EROP statements are mapped into Augmented Drools statements.
Definitions in Augmented Drools and EROP
Because of its origins, Augmented Drools is more colloquial than the EROP language, and also less abstract and human-readable, and more Java-style, especially in the notation for the actions on the right-hand side of the rule. The EROP language is fully mapped to Augmented Drools, so that it is possible to write contracts in Augmented Drools with the same expressive power of EROP, but, as mentioned above, are more verbose, more implementation-aware, but more less statement in style and less opulent. in syntactic sugar[78], but, more importantly, it can be run directly in the available software - the Drools rules engine.
Rule conditions in EROP and Augmented Drools
The syntax for defining rules is the same in Drools and EROP, since the second is derived from the first: ruleRuleName whenconditionsthen actionsend. Comments in AD, like in Drools, begin with a hash sign (#), and continue until the end of the line. status, timeConstraint) would become.
Actions in EROP and Augmented Drools
In EROP, the execution of a contract is concluded with the keyword terminate, to which an argument must be added, the result of the execution. The terminate EROP keyword refers to the AD statement engine.conclude(), which takes as a parameter a string representing the result of contract execution; engine is the current reference to the Relevance Engine.
Conditional structures
This is accomplished by the act recognition cycle of the rules engine, using the Rete algorithm presented in [77]. The Rete algorithm uses a data flow network to represent the conditions on the left side of the rules.
