A Three-Layer Architecture for E-Contract Enforcement in an E-Service Environment

1. A Three-Layer Architecture for E-Contract Enforcement in an E-Service Environment Dickson K.W. CHIUDept. of Computer Science & Engineering, Chinese University of Hong Kong kwchiu@acm.org, kwchiu@cse.cuhk.edu.hk

2. Introduction • e-Contract • Computerized facilitation or automation of a contract • Cross-organizational business processes over the Internet • e-Service system to readily create e-contracts with enforcement measures will soon become a critical success factor • Particularly applicable to standard business interactions, such as the purchase and sale of goods. • e-Contract templates • Reduce effort in development and support of the contract’s whole lifecycle (such as negotiation, enactment and enforcement The PURCHASER shall send a Letter of Credit for the GOODS to the SUPPLIER in the currency of [ ] within [ ] days of the invoice date. The SUPPLIER shall on receipt of the Letter of Credit ships the GOODS to the PURCHASER within [ ] days and provides the PURCHASER with shipment details.

3. e-Contract Enforcement • Recognition (monitoring) and handling of contract breaches • Enforcement and enactment are handled differently(enactment deals with regular activities) • Compliance of a contract has to be kept under constant surveillance • Monitoring of variables – states of the business process • Challenges • constantly checking validity of all these variables incurs tremendous overheads • extended across organizational boundaries • may include confidential information, e.g., bank accounts

4. Objectives • A meta-model of e-contracts and e-contract templates - address specific semantic requirement of contracts for supporting B2B applications • An architecture for cross-organizational e-contract enforcement (in addition to enactment) • A methodology for elicitation of e-contract enforcement based on this multiple layer architecture • A feasible implementation outline for e-contract enforcement with Enterprise Java Bean (EJB) and Web services

5. Three Layer Architecture for E-contract Enforcement

6. e-Contract Template refines involves Meta-Model of an e-Contract Template e-Contract Party 2..* 1 Accepted Value 1 * Contract Clause Template Variable 1..* * references Obligation Permission Prohibition

7. A Sales e-Contract Template as an Instance of the Meta-model involves involves Purchaser :Party Supplier :Party Sales :e-Contract Template Shipping & Insurance :Contract Clause Deposit Payment :Contract Clause Pricing :Contract Clause Delivery :Contract Clause freight :Template Variable deposit :Template Variable quantity :Template Variable delivery date :Template Variable insurance premium :Template Variable unit price :Template Variable return policy :Template Variable

8. E-Contract Lifecycle Contract Enactment • Based on business experience and requirements, contract templates (with variables) are abstracted from previous contracts • A contract template is modeled as an e-Contract template • Each successful e-Negotiation will lead to an e-Contract • Enforcement and enactment are executed differently and in parallel BusinessInformationExchange Contract Negotiation ContractEnforcement

9. System Architecture Database Event Repository Event Subscribers List Business Entities Contract Enforcer Contract Enactor Event Event Other Parties Event Adapter A Party as an e-Service Provider Ext.Event Event Event Timer Event External Web Service Interface Internet • Motivated by the active database paradigm • Event - occurrence of something interesting to the system itself or to user applications • Event driven execution of rules in event-condition-action (ECA) form • ECA (active) rules: On event if condition then action • Exceptions and alerts are events too (action = handler) • Ensure efficiency and timeliness - monitor becomes only active when an interesting event occurs

10. Improvement from deontic logic – well-defined execution semantics and when to execute BAO stands for an object that encapsulates a business action whose execution triggers the object creation Case study – “Terms and Conditions of Sale, Service and Technical Support”, Dell, Hong Kong http://www.ap.dell.com/ap/hk/en/gen/local/legal_terms.htm From Contract Clause to ECA rules

11. Upon reaching the deadline Tobl, a temporal event is generated by the Timer Contract enforcer (of counter party of the action) check if the obliged party has performed the required business action Aobl, searching the log file for invoked actions / occurrence of related events If the obligation has not been fulfilled, the contract enforcer raises an exception Enforcing Obligation

12. 7.1 Dell shall deliver the Products to the place of delivery designated by Customer and agreed to by Dell as evidenced in Customer’s invoice (“Place of Delivery”) Enforcing Obligation Example • 10.7 …Dell shall respond to a request for such Emergency Service as soon as practicable after its receipt of such request. • Analyst has to clarify and substitute ambiguities with concrete deadline in the formulation E: onDay( after( receiptDate( EMERGENCY_REQUEST ), N ) ) ) C: NOT responded( EMERGENCY_REQUEST ) ) A: raise( exception( EMERGENCY_REQUEST )

13. Enforcing Prohibition • The contract enforcer should treat an occurrence of a prohibited action as an exception. • Problem - observation of prohibitions • if a party performs a prohibited action, the party will probably try to hide or distract this fact as long as possible • unless the party does this by mistake or misunderstandings) • autonomous nature of different organizations • Example - 14. Each party shall treat as confidential all information obtained from the other pursuant to a Contract which is marked 'confidential’ …

14. Enforcing Permission • Temporary allowance to perform an otherwise prohibited action • within a certain allowed time period • under certain situations (i.e., events plus conditions) • otherwise exception • Example - 2.1 … Dell shall be entitled to refuse to accept orders placed by the Customer if the Customer breaches or Dell, on reasonable grounds, suspects that the Customer will breach this warranty …

15. Enforcing Permission - Problem • Example - 3.1 … If Dell allows a Customer to cancel its order after manufacture but before shipment of the Product, Dell shall be entitled to levy a cancellation charge equal to 20% of the price of the Products.… • Customer can hardly know the commencement of manufacture of the product - almost non-monitorable • Dell may improve the situation by informing the customer when the commencement starts through its enactment system. (CRM!)

16. Discussion of Problems • General measures to handle contract breaches or exception involves • domain specific knowledge • explicitly specified in other contract clauses • implicitly regulated by laws and standards • Ambiguity and impreciseness of natural languages • reference to other laws, regulations, standard trade practices • parties involved should discuss and clarify the matter • amend existing or forthcoming contracts accordingly • Autonomous nature of individual organizations • Required events might not be monitorable • Cooperation and trust - improves the transparency of operations (CRM!) • Add explicit clauses in the contract to demand these events • Lack of e-services standards

17. Implementation Outline Database Event Repository Subscribers List Security Policies Counter Party Party NOTATIONS interface depend event event event Web Services Manager Web Services Manager receive publish subscription request receive notify event request event component subscribe subscribe request Event Adapter request • Event Adaptor – event publish-and-subscribe paradigm

18. Web Services of the Event Adaptor • Publish Web service • invoked by the event adaptor • input parameter is the occurred event or exception • checks the subscribers list and the security policies, and then notifies the valid subscribers (via e-mail, fax, ICQ message, or even via another Web service) • Subscribe Web service • registers requests for an event subscription • parameters: the requester, the subscribed event, and how the requester wants to receive the event notification • Receive Web service • receive subscribed events published by the counter party • received events are recorded at the Event Repository and forwarded to the Event Adapter • in turn transforms them into the forms as required by the Contract Enforcer and the Contract Enacter

19. Conclusions • A meta-model for e-Contracts and e-Contract templates • A pragmatic architecture for cross-organizational e-contract enforcement comprising three layers, viz., document layer, business layer, and implementation layer • A methodology for developing e-contract enforcement rules, in an e-service environment, using a supplier’s example • An system implementation outline based on Web-service and EJB

20. Future Work • Methodologies for preventive measures avoiding contract breaches • Process adaptation for interoperability - Workflow Views Based E-Contracts in a Cross-Organization E-Service Environment. (Distributed and Parallel Databases, 2002) • ECCRM - An Event Driven Approach to Customer Relationship Management in an e-Brokerage Environment (HICSS36) • B2B integration - A Data-driven Methodology to Extending Workflows Across Organizations over the Internet (HICSS36) • e-Negotiation based on contract templates • On e-Negotiation of Unmatched Logrolling Views (HICSS36) • A Contract Template Driven Approach to e-Negotiation Processes(PACIS 2002) • A Meta-model for e-Contract Template Variable Dependencies Facilitating e-Negotiation(ER2002) • Enterprise Document Management • A Watermarking Infrastructure for Enterprise Document Management (HICSS36)