1 / 36

Dickson K.W. CHIU Senior Member, IEEE kwchiu@acm, dicksonchiu@ieee

Enhancing E-service Collaboration beyond Process Enactment: from Requirements to Event Driven Realization. Dickson K.W. CHIU Senior Member, IEEE kwchiu@acm.org, dicksonchiu@ieee.org. Introduction. e-service - service provided over the Internet

cody-johnson
Download Presentation

Dickson K.W. CHIU Senior Member, IEEE kwchiu@acm, dicksonchiu@ieee

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enhancing E-service Collaboration beyond Process Enactment: from Requirements to Event Driven Realization Dickson K.W. CHIUSenior Member, IEEE kwchiu@acm.org, dicksonchiu@ieee.org

  2. Introduction • e-service - service provided over the Internet • adoption of e-services for B2B process collaboration • need for a more in depth study • not just “regular” process enactment – basic knowledge • requirement engineering beyond basic enactment is almost unexplored • Enforcement • Exception detection – how do you know what is happening inside your partners’ organization? • Exception handling – how deviations can be controlled or compensated • Business relationship management • quality collaboration • need to do extra things • process “transparency”

  3. Project Background • My PhD thesis research on exceptions in WFMS • D.K.W. Chiu, Q. Li and K. Karlapalem. A Meta Modeling Approach for Workflow Management System Supporting Exception Handling. Information Systems, 24(2):159-184, 1999. • D.K.W. Chiu, Q. Li and K. Karlapalem. Web Interface-Driven Cooperative Exception Handling in ADOME Workflow Management System. Information Systems, 26(2):93-120, 2001. • Extension to cross-organization workflows • D.K.W. Chiu, K. Karlapalem, Q. Li and E. Kafeza. Workflow Views Based E-Contracts in a Cross-Organization E-Service Environment. Distributed and Parallel Databases, 12(2-3):193-216, 2002. • CRM • D.K.W. Chiu, et al. An Event Driven Approach to Customer Relationship Management in an e-Brokerage Environment. HICSS36, IEEE Computer Society Press, Jan 2003. • Conference Paper • D.K.W. Chiu, S.C. Cheung, and S. Till. An Architecture for E-Contract Enforcement in an E-service Environment. HICSS36 best paper nomination.

  4. Objectives • a methodology to structure B2B process collaboration in multiple layers and multiple perspectives • Conceptual models expressed in UML • life cycle similar to that of a software system, i.e., definition, analysis, and realization • a more thorough understanding of B2B process collaboration from its fundamentals to system design • a methodology is presented for the engineering of e-service process collaboration from high-level business requirements down to system design details • a system architecture and feasible implementation outline with Enterprise Java Bean (EJB) and Web services • evaluate our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers

  5. Simplified Business 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 • CRM should be anywhere anytime … BusinessInformationExchange Contract Negotiation ContractEnforcement

  6. Motivating Business Process Example Can this show anything beyond regular process execution - enforcement and relationship management? Sub-process

  7. Example Enforcement Requirements • End user notify system integrator: changes in delivery requirements or payment arrangement - • System integrator notify end user - changes in delivery date • When a vendor changes the lead-time but the delivery schedule can still be met within the end user’s deadline, the change can be tolerated. • The system integrator should present a revised delivery schedule to the end user according to the parts vendor’s reported lead-time. • When a certain part is stopped from production, the system integrator request the end user’s approval of using an alternative part. • When there is a significant aggregated price change in parts during the end user’s evaluation, a revised quotation (price) is sent to the end user through an event-triggering mechanism. Most of the above are related to exception handling…

  8. Enforcement Requirements in General • 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

  9. Example Relationship Management Requirements • Any involved organization wants to be able to inquire the progress of business processes at other business partners’ side such as order processing, payment. • A service provider wants to relay relevant information to business partners from other sources or upon enquiry, such as technical information, drivers update, product news. • Effective measures for handling complaints and feedbacks from business partners are essential to help rescue threatened relationship and reduce attrition.

  10. A Three-Layered Architecture for B2B Collaboration Enforcement Requirements Relationship Management Requirements Enactment Requirements Relationship Policies Workflow Processes Enforcement Policies Collaboration Requirements ECA Rules Business Rules Enterprise JavaBeans Web Services System Design

  11. Artifacts of B2B Collaboration Architecture

  12. A Meta-model of B2B Process Collaboration Obligation Permission Prohibition Exception Enforcement Requirement Enforcement Policy Business Event Temporal Event specifies 1 * * Relationship Mgmt Requirement realizes * Event * * 1..* Collaboration Requirement Business Rule 1..* Condition 1 realizes specifies * +subscriber +publisher 1..* * 1 * Relationship Mgmt Policy Business Party performs Action realizes * 1 * * Workflow Process specifies Enactment Requirement aggregation 1 inheritance

  13. System Architecture based on ECA rules 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 Database ECA rules Event Repository Event Subscribers List Business Entities Other Collaboration Parties Requirement Enforcer Collaboration ProcessEnactor Event Event Event Adapter Event Event A Party as an e-Service Provider Event Timer Event Web Service Interface

  14. Event-driven workflow execution model (that is, ECA rule based) Business partners have to trigger the corresponding start-events (say, quotation enquiry) to start B2B process collaboration. If the process is a composite one, the collaboration process enactor will raise a start-event for the first sub-process This will continue recursively downward the composition hierarchy until a leaf sub-process or task. The collaboration process enactor sends a start-event to the task to initiate it. After the task is finished successfully, the task replies to the collaboration process enactor by raising a finish-event with the results (if any). The collaboration process enactor then carries on with the next step according to the returned result. Upon failures or timeouts, an appropriate exception event will also be raised accordingly. Enactment Requirements to ECA rules

  15. E: received (QUOTATION_ENQUIRY), C: true, A: perform (CHECK_PART_INFO) E: finish (CHECK_PART_INFO), C: true, A: perform (PREPARE_QUOTATION) E: finish (PREPARE_QUOTATION), C: true, A: perform (PREPARE_EXTRA_INFO) Enactment ECA rules example

  16. 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 Enforcement Requirements to ECA rules

  17. 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

  18. 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 )

  19. 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’ …

  20. 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 …

  21. 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!)

  22. Relationship Management Requirements • CRM help an organization to streamline customer services and maximize the value of customers • New in the B2B context – objectives: • provision of quality service • monitoring of collaborating processes • better dissemination of information • effective handling of complaints • Automation for CRM is even more essential for B2B • Approach • Concentrated on business rule designs for asynchronous event driven • particularly for exceptions • Transform business rules from if-then form to ECA form • Isolate the relevant events • record the objectives of each rule to determine its usefulness and hence its priority of implementation in a phased approach

  23. Quality of service • Often not explicitly enforced in a contract • But this should not just be optional • Do better than required or specified => competitive • Example, though some obliged actions may have a distant deadline, the management may decide to perform it as soon as feasible. • Example ECA-rule for quicker delivery • E: received (ORDER) • C: valid( place( DELIVER ) ) & ready( DELIVER ) • A: perform( DELIVER )

  24. Monitoring of collaborating processes • Helps business partners to plan ahead and reduce uncertainties • Example: a customer can hardly tell whether the manufacture process of the product has already commenced when the order is cancelled • Improve the situation by informing the customer when the manufacturing process has commenced • Better than handling enquiries passively => reduce the need for human enquiries and thus operating costs. • Non-monitorable => monitorable • ECA rule example: • E: start (DELIVERY) • C: true • A: notify (customer (DELIVER))

  25. Dissemination of useful information • Widely in practice for B2C relationship management. • Financial institutions often provide market information to their customers as extra services. • Facilitate the customer to make decision and in turn may help effective collaboration. • For example, system integrator forward vendor’s technical information or software updates to the relevant customers. • Prevent problems from occurring • improves the service quality • reduce the cost of support • Example ECA rule: • E: received (INFO) • C: relevant (INFO, customer) • A: notify (customer ( INFO) )

  26. Effective handling of complaints • Avoids customer attrition • Help rescue threatened relationship • Complaints involve exception conditions • need to be handled by appropriate trained personnel or even the management manually • should be performed as soon as possible to reduce customer grievance • Example ECA rule: • E: received (COMPLAINT) • C: true • A: notify (handling_personnel (customer ( COMLAINT)))

  27. 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

  28. Web Service 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

  29. 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

  30. takeOrder Web Service Input: OrderRequest Buyer Name Address E-Mail ProductList Product Product ID Product Name Quantity Price Output: OrderResponse OrderResult OrderNr Password Estimated Delivery Date trackOrder Web Service Input: OrderStatusRequest OrderNr Password Output: OrderStatus Progress Estimated Delivery Date Optional: DeliveryNr Example Web Services for Collaboration

  31. Example Web Service Name: ChangeOrderRequest Input: ChangeContractDataRequest ChangeRequestID Customer Id OrderNumber ToChangeContractData OldValue NewValue ReasonOfChange Output: ChangeContractDataResponse ChangeRequestID Approved (Yes/No) AuthorizedBy AdditionalComment ToChangeContractData NewValue “Catch-all-exception” Web service Precaution – unhandled exceptions forward to administrators Each events / exceptions sub-class hierarchy as Web service Extra parameters / data E.g., End User -> System Integrator Cancel Order Request Change Order Request Change Delivery Date Request Change Delivery Location Request Delay Payment Request Return Unsatisfied System Request E.g., Part Vendor -> System Integrator Price List Update Price Update New Parts Update Part Recall Notification Part Obsolescence Notification Driver Update Web Services for External Exception / Event Reception

  32. Event Chaining • Possible because of automated receipt and sending of events • Efficient and effective knowledge dissemination • E.g., driver update: • part vendor -> system integrator -> end user

  33. Process Monitoring • Name: GetProcessStatus • Input: ProcessStatusRequest • CustomerId • OrderNumber • Output: ProcessStatusResponse • CustomerID • OrderNumber • StatusReport (content depend on the customer, status, etc.) • ContactPersonInfo (for further information)

  34. Evaluation - Concerns of different stakeholders

  35. Conclusions • A pragmatic three-layer architecture for B2B e-service process collaboration (collaboration requirement layer, business rule layer, and system design layer) • Support for enactment, enforcement, and relationship management • A meta-model for B2B collaboration based on a unified artifact of event-condition-action • A methodology for eliciting knowledge of collaboration requirements into business rules in ECA format • Typical problems that can be discovered by our methodology, together with some measures of overcoming them • A system architecture and feasible implementation outline with Enterprise Java Bean (EJB) and Web services • Evaluation of our approach from the perspective of three main stakeholders of e-collaboration, namely users, management, and systems developers

  36. Continuing and Future Work • Methodologies for preventive measures avoiding contract breaches. • Process adaptation for interoperability with process views and event flows analysis – different partners have different interactions. • Alerts – urgency in process integration (esp. healthcare) • Application of this framework in other domains, particularly B2B process enforcement (exceptions) and *CRM* • Financial institutions, insurance, … • e-tourism, e-government, e-learning, …

More Related