Pervasive Enablement of Business Process 徐天送 2004/11/2.
-
date post
20-Dec-2015 -
Category
Documents
-
view
222 -
download
0
Transcript of Pervasive Enablement of Business Process 徐天送 2004/11/2.
Pervasive Enablement of Business Process
徐天送2004/11/2
Reference
“Pervasive Enablement of Business Process”, Dipanjan Chakraborty, Hui Lei, Second IEEE International Conference on Pervasive Computing and Communications (PerCom’04), March 2004
“Extending the Reach of Business Process”, Dipanjan Chakraborty, Hui Lei, IEEE Comunications, April 2004
Outline
Introduction Design Rationale System Overview Extension to BPEL Conclusion
Introduction
A business process is “a procedure where documents, information or tasks are passed between participants according to defined sets of rules to achieve or contribute to an overall business goal.”
Participants of a business process may be human beings, Web services or other software agents.
Workflow Management System
The modeling and execution of business processes are generally referred to as Workflow Management System (WFMS).
WFMS
A Business Process
Workplace Metaphor
WFMS
A Business Process
Agent
Workplace
Employ a workplace metaphor to present tasks that are to be claimed and performed by human participants.
Disadvantages of Workplace-based User Interface Users are constrained to the desktop computing
environment. A workplace essentially adopts a pull-based
approach, where the user is burdened to periodically inspect his workplace to check out pending staff activities.
WFMS allow for indirect and asynchronous people-to-people communication only.
Communication Tools
Hardware
Software
Limitations of communication tools
They support ad hoc, unstructured collaboration only. There is no built-in mechanism for enforcing any policies or structures on the collaboration process.
Collaboration tools are not integrated with business processes.
Integration
Hardware
SoftwareWFMS
A Business Process
Agent
New challenge
Although a person typically has multiple communication tools, he may have access to only a subset of them at a particular time.
Depending on the circumstance, he may also have a preference on which of the available tools to use.
Travel Request Approval
System(PerCollab)
customer
1. Fill in a form
2. Request Processing
3. Ask for approving
4. Request approving
George(Manager)
5. Grants
6. notify
7. Complete approving
Meeting
Michael(Employee)
Five salient features
Business processes are seamlessly integrated with and accessible from a range of collaboration tools.
Staff activities in business processes are proactively pushed to users.
Dynamic user context information is exploited to select an appropriate collaboration modality for engaging the users.
Five salient features
Coordination policies and structure can be imposed to synchronous, realtime-style people-to-people collaboration.
Collaboration processes can be instantiated programmatically and collaboration results fed back to the calling application.
Design Rationale
Communication Tools Process Language and Container User Context
Design Rationale - BPEL
Business Process Execution Language (BPEL) specifies the potential execution order of operations from a collection of Web services.
Design Rationale - BPEL
But BPEL assumes all participants (or partners) are Web services and does not provide explicit support for human participants.
We provide constructs to explicit model interactions between processes and persons and between persons.
Design Rationale – user context
The best means of engaging a particular person at a particular time depends on a lot of factors: the person’s location, activity, connectivity and personal preferences. Such attributes are often referred to as user context.
System Architecture
Modality Adapters
Extension to BPEL ~1
Separate two kinds of partnerWeb service partner: partners that are Web
services or agents having a Web service interface.
Human partners: partners that represent human participants.
Extension to BPEL ~2
Two categories of interactionOne-way activities: notification-type activities f
or alerting human partners.Two-way activities: request-response type acti
vities where human participants have to provide a reply back to the business process.
Three additional types of constructs in xBPEL Human Partner
used to define a human entity as a participant in a business process.
Process-to-People used to model communication between the human
partners and the BPEL process People-to-People
used to model direct communication between the human participant
Human Partner- humanPartner tag
Process-to-People-interact tag
People-to-People-notify tag, converse tag
XBPEL Translation
xBPEL translator functions:Transform all people-to-people constructs into
process-to-people constructs.Transform all process-to-people constructs to
<invoke> constructs in standard BPEL, using the Interaction Controller Web service as a proxy for all human partners.
Automatically generate the WSDL definition for the resultant BPEL policy.
<interact> translation
Serialize the xBPEL promptData and replyData variables in the <interact> construct and assign them to corresponding parts of the IC input message.
Invoke IC operation for engaging human partner instances.
De-serialize the message returned from the IC and assign it to the xBPEL replyData variable.
<converse> translation
Implementation ~ 1
Tools: IBM BPWS4JSametime 3.0 Client ToolkitLotus Notes 6.0
Implementation ~ 2
Conclusion
We have designed and implemented a system, PerCollab, which integrates workflow and collaboration technologies.
The BPEL should be extend to accommodate the interact with human beings.