View
217
Download
1
Embed Size (px)
Citation preview
1
Enhancing E-service Collaboration with Enforcement and Relationship Management: a Methodology from
Requirements to Event Driven Realization
Dickson K.W. CHIU Senior Member, IEEE
[email protected], [email protected]
Shing-Chi CHEUNG, Sven TILLDept. of Computer Science
Hong Kong University of Science & Technology{scc, till}@cs.ust.hk
eService Collaboration-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”
eService Collaboration-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.
eService Collaboration-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
eService Collaboration-5
Simplified Business Contract Lifecycle
BusinessInformationExchange
Contract Enactment
ContractEnforcement
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 CRM should be anywhere anytime …
eService Collaboration-6
Motivating Business Process Example
Can this show anything beyond regular process execution -enforcement and relationship management?
Sub-process
eService Collaboration-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…
eService Collaboration-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
eService Collaboration-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.
eService Collaboration-10
A Three-Layered Architecture for B2B Collaboration
Enterprise JavaBeans
Web Services
ECA Rules
WorkflowProcesses
EnforcementPolicies
Enforcement RequirementsEnactment
Requirements
CollaborationRequirements
Business Rules
System Design
RelationshipPolicies
Relationship Management Requirements
eService Collaboration-11
Artifacts of B2B Collaboration Architecture
Layer Perspective Artifacts
Collaborationrequirements
Users, managers,Analysts
Meta-model for B2B Collaboration:Enactment requirements (Workflow Processes)Enforcement requirements (Enforcement Polices) Relationship management requirements (Relationship Management Polices) Parties and Roles
Business rules Analysts Meta-model for process enactment and exception handling: Business events, Business rules, Business actions and Business entities
System design Analysts & Programmers
Task system design (Enterprise JavaBeans components)Process system design (BPEL or workflow engine)Cross-organizational interface (Web Services XML schemas)
eService Collaboration-12
A Meta-model of B2B Process Collaboration
1
specifies
**
*
+publisher1
*
1..**
performs
1..*
1
EnforcementRequirement
*
*
specifies EnforcementPolicy
CollaborationRequirement
EnactmentRequirement
WorkflowProcess
specifies
1
BusinessRule
*
1
Event
Action
Condition
BusinessParty*
BusinessEvent
Exception
TemporalEvent
+subscriber *
Obligation Permission Prohibition
aggregation
inheritance
realizes
realizes
Relationship MgmtRequirement
Relationship Mgmt Policy
*
realizes
1..*
eService Collaboration-13
System Architecture based on ECA rules
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
Requirement Enforcer
Collaboration ProcessEnactor
Event Adapter
Web Service Interface
Event Event
A Party as an e-Service
Provider
Database
ECA rulesEvent Repository
Event Subscribers List Business Entities
Internet E
vent
Event
Eve
nt
Other Collaboration
Parties
Timer Event
eService Collaboration-14
Enactment Requirements to ECA rules
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.
eService Collaboration-15
Enactment ECA rules example 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)
eService Collaboration-16
Enforcement Requirements 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 http://www.ap.dell.com/ap/hk/en/gen/local/legal_terms.htm
Clause type Event Condition Action
Obligation (Shall …)
onDay(deadline(BAO ) ) NOT occurred( BAO )
raise( exception( BAO ) )Prohibition
(Shall not …) onOccurred( BAO) prohibitionCondition( BAO )
Permission (may …)
NOT permitted( BAO )
eService Collaboration-17
Enforcing Obligation
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
E: onDay( deadline( BAO ) )C: NOT occurred( BAO )A: raise( exception( BAO ) )
eService Collaboration-18
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 Customer’s 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 )
eService Collaboration-19
Enforcing Prohibition
Enforcement rule form Enforcement 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 - 14. Each party shall treat as confidential all information obtained from the other pursuant to a Contract which is marked 'confidential’ …
eService Collaboration-20
Enforcing Permission
Enforcement rule form Enforcement 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 - 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 …
eService Collaboration-21
Enforcing Permission - Problem
Enforcement rule form Enforcement 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 - 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!)
eService Collaboration-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
eService Collaboration-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 )
eService Collaboration-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))
eService Collaboration-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) )
eService Collaboration-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)))
eService Collaboration-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
eService Collaboration-28
Web Service Implementation Outline
Event Adaptor – event publish-and-subscribe paradigm
Web ServicesManager
EventAdapter
publish
subscribe
receive
notify
Database
Event RepositorySubscribers ListSecurity Policies
Web ServicesManager receive
event
event
event
event
Counter Party Party
requestsubscribe
request
request
interface
depend
event
subscriptionrequest
component
NOTATIONS
eService Collaboration-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
eService Collaboration-30
Example Web Services for Collaboration
takeOrder Web ServiceInput: OrderRequest Buyer
Name Address E-Mail
ProductList Product
Product ID Product Name Quantity Price
Output: OrderResponse OrderResult
OrderNr Password
Estimated Delivery Date
trackOrder Web ServiceInput: OrderStatusRequest OrderNr Password Output: OrderStatus Progress Estimated Delivery Date Optional: DeliveryNr
eService Collaboration-31
Web Services for External Exception / Event Reception
Example Web ServiceName: ChangeOrderRequestInput: 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
eService Collaboration-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
eService Collaboration-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)
eService Collaboration-34
Evaluation - Concerns of different stakeholders
General Concerns Enactment Enforcement RM
User Assist their workInteroperability and connectivitySystem / information availability Convenience and ease of use
Workflow automationReliability – retries, search alternatives
Reduce tedious manual checkingTimeliness of services
Improved service call-center or web page More transparent business processes
Management Cost vs. BenefitImprove productivityScalabilitySecurityReduction in total development costCommunications cost
Increase business opportunitiesConvergence of disparate business functionalities
Business process monitorabilityCompliance to contracts / trade standard / regulations / lawsException and crisis managementKnowledge management
Improve customer relationshipsImproved servicesKnowledge management
System Developer
Development / Maintenance effort & costRequirement elicitationReusabilityScalabilityUncertainty in the use of new technologiesOverall system complexityIntegration with existing systems
Phase approach that accommodate existing basic enactment information systems
Event monitorabilityDifficulties in programming captured knowledge
Difficulties in programming captured knowledge
eService Collaboration-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
eService Collaboration-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, …