HICSS36-eService-1 A Three-Layer Architecture for E-Contract Enforcement in an E-Service Environment Dickson K.W. CHIU Dept. of Computer Science & Engineering, Chinese University of Hong Kong Shing-Chi CHEUNG, Sven TILL Dept. of Computer Science Hong Kong University of Science & Technology {scc,

HICSS36-eService-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 contracts 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.

HICSS36-eService-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

HICSS36-eService-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

HICSS36-eService-5 Three Layer Architecture for E-contract Enforcement LayerPerspectiveArtifacts DocumentUsers, managers Meta-model for e-contracts and templates: Contract clauses (Obligation, Permission, Prohibition) and Parties BusinessSystem analyst Meta-model for e-contract enforcement: Business events, Business rules, Business actions and Business entities Implemen- tation ProgrammersBusiness action implementation (Enterprise JavaBeans components) Cross-organizational interface (Web services XML schemas)

HICSS36-eService-6 Meta-Model of an e-Contract Template e-Contract Template * 1 1..* Template Variable 2..* involves * refines ObligationPermissionProhibition e-ContractParty Contract Clause references Accepted Value 1

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

HICSS36-eService-8 E-Contract Lifecycle Business Information Exchange Contract Enactment Contract Enforcement Contract Negotiation 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

HICSS36-eService-9 System Architecture 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 Contract EnforcerContract Enactor Event Adapter External Web Service Interface Event A Party as an e-Service Provider Database Event Repository Event Subscribers List Business Entities Internet Event Ext. Event Other Parties Timer Event

HICSS36-eService-10 From Contract Clause to ECA rules 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 Clause type EventConditionAction Obligation (Shall …) onDay(deadline (BAO ) ) NOT occurred( BAO ) raise( exception( BAO ) ) Prohibition (Shall not …) onOccurred( BAO) prohibitionCondition( BAO ) Permission (may …) NOT permitted( BAO )

HICSS36-eService-11 Enforcing Obligation Upon reaching the deadline T obl, 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 A obl, searching the log file for invoked actions / occurrence of related events If the obligation has not been fulfilled, the contract enforcer raises an exception E: onDay( deadline( BAO ) ) C: NOT occurred( BAO ) A: raise( exception( BAO ) )

HICSS36-eService-12 Enforcing Obligation Example 7.1 Dell shall deliver the Products to the place of delivery designated by Customer and agreed to by Dell as evidenced in Customers invoice (Place of Delivery) Enforcement rule (Customer)Enactment rule (DELL) E: onDay( deadline( DELIVER ) ) C: NOT occurred( DELIVER ) A: raise( exception( DELIVER ) ) E: onDay( before( deadline( DELIVER ), 6 ) ) C: valid( place( DELIVER ) ) & ready( DELIVER ) A: perform( DELIVER ) 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 )

HICSS36-eService-13 Enforcing Prohibition Enforcement rule formEnforcement rule (Both Parties) E: onOccurred( BAO ) C: NOT permitted( BOA ) A: raise( exception( BAO ) ) E: onOccurred( INFO ) C: confidential( INFO ) A: raise( exception( INFO ) ) 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 Each party shall treat as confidential all information obtained from the other pursuant to a Contract which is marked 'confidential …

HICSS36-eService-14 Enforcing Permission Enforcement rule formEnforcement rule example (Both Parties) E: onOccurred( BAO ) C: prohibitionCondition( BAO ) A: raise( exception( BAO ) ) E: onOccurred( REFUSE_ORDER ) C: NOT badlisted( customer( REFUSE_ORDER ) ) A: raise( exception( REFUSE_ORDER ) ) 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 … 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 …

HICSS36-eService-15 Enforcing Permission - Problem Enforcement rule formEnforcement rule example (Both Parties) E: onOccurred( BAO ) C: prohibitionCondition( BAO ) A: raise( exception( BAO ) ) E: onOccurred( LEVY ) C: NOT ( dateOfCancellation( order( LEVY ) ) > dateOfManufacture( order( LEVY ) ) & cancellationApproved( order( LEVY ) ) ) A: raise( exception( LEVY ) ) Example … 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!)

HICSS36-eService-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

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

HICSS36-eService-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 , 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

HICSS36-eService-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 suppliers example An system implementation outline based on Web-service and EJB

HICSS36-eService-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)