Date[              ]       Recordnr[        ]
Who[ Heiko Ludwig, IBM Zuerich
Title[ Virtual Enterprise Co-ordinator (VEC) - Agreement-Driven Gateways 
for Cross-Organisational Workflow Management

Place[ WACC'99

Keywords[ cross organisational, workflow, autonomous, virtual enterprise

Summary[ 

Issues to be solved:
====================
0) Model:
There are processes and work items. Manager interfaces to the 
processes (process management interface PMI), performers carrying out 
the workitem interface to the work items via the work item management 
interface WIMI. Managers can inspect the state, override the state of a 
process or activity, inspect the PES. If a manager overrides a state, 
that state change has to be propageted to the work items and performers. 
Performers only set the state of the work item, and retrieve and set 
data. Typical states are: initiated, running, completed and terminated 
(= abnormal complete, abort). A process has an aggregate state of the 
states of its activities.
Processes contain activities that correspond to work-items. The 
activity has a parent interface to the work item, on the side of the 
work-item this interface is called work-item interface. Subprocesses 
look like work-items for the parent process, yet they have their own PMI 
to a manager, and their own PES.
The process execution specification (PES) specifies the order of 
activites within a process or class of processes defined by process 
templates.

1) Organisational boundaries:
Distributed WfMS local:
Subprocess can be in another WfMS:
- provide communication
- share models, naming,
- provide references to subprocess
- deal with synchronisation, are the same as within one WfMS
Basis for intra-organisational WfMS:
  - manager can monitor progress of each workflow, and even intervene
  - employee has access to process model and all information

Additional items when seperate management, organisation boundaries 
between the WfMS: no assumptions can be made about similarities:
- different resources, kind of resources:one very large, the other very 
small with few parallel processes
- different technologies
- different organisation standards
- separate legal entities
- separate responsibility (financial, ...)

Principles for inter-organisational WfMS:
Privacy: no access to internal information in other organisation 
(process model, data, progress, usage of resources, ongoing 
activities, who does what....)
Goal orientation: instead of internal information definition of an 
agreement concerning goals (expected results) and interfaces (how to 
invoke when)
Flexibility: Provider and Requester may change their processes any time, 
as long as they fulfill agreement.
Independence: No dependence on changes taking place in the WfMS of the 
partner. Possibility to use same workflows for several requester / have 
several providers for some activity.

==> consequences for model:
- subprocesses are enacted by other WfMS than parent process
- connection for transferring data and state-information between sub-
process (seen as work-item from parent) and activity in parent process 
has to be set up explicitly
- terminology differences
- no knowledge or intrusion into other PES
Solution: either fixed standard for domain (does not work), or mutual 
agreement between two instances of WfMSs'.

2) Overcoming boundaries
==> in order to overcome these boundaries, the following has to be 
agreed upon; there are different layers (from bottom to top);
- encoding of data and operations, e.g. IF4, SWAP, jointFlow
- semantics of stanard parameters and operations , e.g. IF4, 
- sematics of activities, processes and data ->VEC
- rules for default and exceptions ->VEC
- monitoring and control 
- QoS

3) Process across organsations
Two organisations, A and B. In order to start co-work they have to go 
through to following phases:
Phases for establish virtual enterprise:
- initiation, making contracts,...
- contracting, technical relationships
- performance, execution of established workflows = start running 
business relationships and connecting technical systems


Paradigm shift: from remote enactment to outsourcing.
Basic approach:
- Agreement: prepare agreement in both organisations, outside of scope 
of VEC. Agreement contains: requester, provider, name of process or 
process template to be performed, name and type of each relevant data 
itme. Agreement language is in development.
- Agreement is given to Request Gateway Manager in requester, and 
Provider Gateway Manager in provider. These two components communicate 
with each other. The requester gateway manager appears like a work-item 
factory to the rest of the requester. The managers create the Requester 
Process Gateway and the Provider Process Gateway, which communicate 
with each other, and which appear in their systems like normal work-
items resp. parent processes.

Interface operations:
- newsubprocess(process name)   -> provider gateway manager
- accept and reject(process + process template name) 
	-> requester gateway manager
- supplydataitem(itemname, value), startprocess(), terminateprocess()  
   	-> provider process gateway
- supplydataitem(itemname,value), processterminated(), 
processcompleted()  
	-> requester process gateway
Names and types of parameters are defined in the agreement. For each 
agreement, the WfMS has a mapping into its own terminolgy (simple 1:1 
mapping), because one provider might have dozens of agreements with 
different requesters for the same process template, each agreement using 
different names.
 
CrossFlow is developed since Sept 1998 until Sept 2000, together with 
IBM France, Sema Group, University of Twente, GMD IPSI Germany, AGFIL.

Prototype implementation:
- IIOP between gateways and gateway managers
- FlowMark as WfMS

Other systems:
1) severl WfMS within one organisation: MGSeriesWorkflow of IBM, 
jointFlow and SWAP as protocol when using WfMS of different vendors.
2) accross organisational boundaries: Wide Area GroupFlow system,  
agreements are used in: Coyote, TOWEC, ConTract


interesting paper and approach!!!