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.