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 TILL
Dept. of Computer Science
Hong Kong University of Science & Technology
{scc, [email protected]
1
Introduction



e-service - service provided over the Internet
adoption of e-services for B2B process collaboration
need for a more in depth study



Enforcement



not just “regular” process enactment – basic knowledge
requirement engineering beyond basic enactment is almost unexplored
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-2
Project Background

My PhD thesis research on exceptions in WFMS



Extension to cross-organization workflows


D.K.W. Chiu, K. Karlapalem, Q. Li and E. Kafeza. Workflow Views Based EContracts in a Cross-Organization E-Service Environment. Distributed and
Parallel Databases, 12(2-3):193-216, 2002.
CRM


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.
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-3
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-4
Simplified Business Contract Lifecycle
Contract
Enactment
Business
Information
Exchange
Contract
Negotiation
Contract
Enforcement





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-5
Motivating Business Process Example
E n d-U ser
C he ck &
R ece ive
S ystem
Q uo ta tion
E va lua tion
P u rch ase
O rde r
C he ck
P a rts In fo
P rep are
Q uo ta tion
P rep are
E xtra In fo
S e rvice P re pa ratio n
P a ym en t
A u tho rizatio n
E nd
E
rd
ym
y
O
pl
Pa
up
y
ue
ir
eq
t
E
ra
en
er
xt
st
n
u
R
E
q
In
xt
Q u o ta tio n
S
Q uo ta tion
E n qu iry
fo
B e gin
fo
ra
In
fo
B e gin
D eliver &
Install
E nd
Sub-process
O rde r
M issin g
P a rts
B e gin
d
te
da
Up
En
qu
Pa
ir y
rts
In
S ystem In te grator
S e rvice
P rep aration
l
De
P a rts
Q uo ta tion
Install
S o ftw a re
S ystem
Te stin g
E nd
it h
r w nt
e
e
rd
O aym
p
P a rts V en do r
B e gin
A sse m ble
S ystem
D eliver
P a rts
iv e
ry
E nd
Can this show anything beyond regular process execution enforcement and relationship management?
eService Collaboration-6
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 leadtime.
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-7
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-8
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-9
A Three-Layered Architecture for B2B
Collaboration
Enactment
Requirements
Workflow
Processes
Enforcement
Requirements
Enforcement
Policies
Relationship Management
Requirements
Relationship
Policies
ECA Rules
Enterprise
JavaBeans
Web Services
Collaboration
Requirements
Business Rules
System Design
eService Collaboration-10
Artifacts of B2B Collaboration Architecture
Layer
Perspective
Collaboration
requirements
Users,
managers,
Analysts
Business rules
Analysts
System design Analysts &
Programmers
Artifacts
Meta-model for B2B Collaboration:
Enactment requirements (Workflow Processes)
Enforcement requirements (Enforcement Polices)
Relationship management requirements (Relationship
Management Polices)
Parties and Roles

Meta-model for process enactment and exception handling:
Business events, Business rules, Business actions and
Business entities

Task system design (Enterprise JavaBeans components)
Process system design (BPEL or workflow engine)
Cross-organizational interface (Web Services XML
schemas)

eService Collaboration-11
A Meta-model of B2B Process Collaboration
Obligation
Permission
Prohibition
Exception
Enforcement
Requirement
Enforcement
Policy
specifies
1
Business
Event
Temporal
Event
*
*
Relationship Mgmt
Requirement
realizes
*
Event
*
*
1..*
Collaboration
Requirement
1..*
1
specifies
realizes
*
Business
Rule
Condition
+subscriber
1..*
Relationship Mgmt
Policy
*
performs
realizes
Action
*
1
+publisher
Business
Party
*
*
Enactment
Requirement
1
*
specifies
1
Workflow
Process
aggregation
inheritance
eService Collaboration-12
System Architecture based on ECA rules




Database
Other
Collaboration
Parties
Internet
Requirement
Enforcer
ECA rules
Event Repository
Event Subscribers List
Business Entities
Collaboration Process
Enactor
Event Adapter
Timer
Event
Event

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
Event

Web Service Interface
A Party as
an e-Service
Provider
eService Collaboration-13
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-14
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-15
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
Obligation
(Shall …)
Prohibition
(Shall not …)
Permission
(may …)
Event
Condition
onDay(deadline
(BAO ) )
NOT occurred( BAO )
onOccurred( BAO)
Action
prohibitionCondition( BAO )
raise(
exception(
BAO ) )
NOT permitted( BAO )
eService Collaboration-16
Enforcing Obligation
E: onDay( deadline( BAO ) )
C: NOT occurred( BAO )
A: raise( exception( BAO ) )



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
eService Collaboration-17
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-18
Enforcing Prohibition
Enforcement rule form
Enforcement rule (Both Parties)
E: onOccurred( BAO )
E: onOccurred( INFO )
C: confidential( INFO )
A: raise( exception( INFO ) )
C: NOT permitted( BOA )
A: raise( exception( BAO ) )


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-19
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-20
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-21
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-22
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-23
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-24
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-25
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-26
Discussion of Problems

General measures to handle contract breaches or exception
involves




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




domain specific knowledge
explicitly specified in other contract clauses
implicitly regulated by laws and standards
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-27
Web Service Implementation Outline
Counter Party
Web
Services
Manager
Party
event
receive
receive
request
Web
Services
Manager
event
Database
NOTATIONS
Event Repository
Subscribers List
Security Policies
interface
publish
event
notify
depend
event
Event
Adapter
subscription
request
event
component
subscribe
subscribe
request
request

Event Adaptor – event publish-and-subscribe paradigm
eService Collaboration-28
Web Services of the Event Adaptor

Publish Web service




Subscribe 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)
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-29
Example Web Services for Collaboration
takeOrder Web Service
trackOrder Web Service
Input: OrderRequest

Buyer
Input: OrderStatusRequest

OrderNr

Password
Output: OrderStatus

Progress

Estimated Delivery Date

Optional: DeliveryNr




Name
Address
E-Mail
ProductList

Product




Product ID
Product Name
Quantity
Price
Output: OrderResponse

OrderResult



OrderNr
Password
Estimated Delivery Date
eService Collaboration-30
Web Services for External Exception /
Event Reception



“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
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
Part Obsolescence Notification
Driver Update
eService Collaboration-31
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-32
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-33
Evaluation - Concerns of different
stakeholders
User
General Concerns
Enactment
Enforcement
RM
Assist their work
Interoperability and connectivity
System / information availability
Convenience and ease of use
Workflow
automation
Reliability –
retries, search
alternatives
Reduce tedious manual checking
Timeliness of services
Improved service
call-center or web
page
More transparent
business processes
Increase
business
opportunities
Convergence of
disparate
business
functionalities
Business process monitorability
Compliance to contracts / trade
standard / regulations / laws
Exception and crisis
management
Knowledge management
Improve customer
relationships
Improved services
Knowledge
management
Phase approach
that
accommodate
existing basic
enactment
information
systems
Event monitorability
Difficulties in programming
captured knowledge
Difficulties in
programming
captured knowledge
Management Cost vs. Benefit
Improve productivity
Scalability
Security
Reduction in total development
cost
Communications cost
System
Developer
Development / Maintenance
effort & cost
Requirement elicitation
Reusability
Scalability
Uncertainty in the use of new
technologies
Overall system complexity
Integration with existing
systems
eService Collaboration-34
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-35
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, …
eService Collaboration-36
Descargar

A Logical Framework for Exception Handling in ADOME