RE:Re: WorkList/WorkItem Interfaces

I sent some comments to Richard on this originally, providing some background on 
the WfMC perspective (attached below). It is certainly reasonable that work 
item, process instance (and activity instance for that matter) should be 
considered as having common class attributes. There are also some differences 
which were identified originally - essentially concerning practical aspects of 
behaviour which might lead to specification or implementation inefficiencies. 
This was what originally precluded a single definition of "work" which could be 
recursively redefined to whatever level of definition detail was required.
Rgds, Dave Hollingsworth.

--------------------------------------------------------------------------------
original message:

Let me provide some (WfMC) background on work items; we have also had much 
discussion on the subject.

We have a hierarchy of work orientated objects
7 process instance (which may have multiple threads)
7 activity
7 work item

Activity is the smallest unit of work which is specified within the process 
definition
(i) it has a single (human) resource specification (which may return a set of 
potential participants at run time)
(ii) process navigation is specified in terms of (conditional) transitions 
between activities
(iii) it contains a specification of IT tools or applications which are run to 
support the activity (typically either at desktop level in a user context or 
against some central services without a particular user context). Where multiple 
applications (within a single activity) are specified there is an additional 
parameter in the process definition to specify whether execution is sequential 
or parallel; where parallel execution is employed multiple participants may be 
assigned within the single activity.

Beyond these aspects there is no definition of the work content of an activity. 
(For example, an activity that places an instruction on a screen for a user to 
do something and signal to the system when it is completed has no defined work 
content as such within the process definition. The user may do the work manually 
or invoke his own IT tools outside the workflow system context.) 

This model is adequate in many cases and with abstraction of an activity into a 
sub-process [with its own underlying activity structure] can support arbitrary 
complexity.

So why do we need Workitems?

The term work-item refers to an atomic unit of work presented to a human user, 
typically via an in-tray. The workflow service is assumed to maintain a 
work-list for each user which contains the set of work items available for 
action. The detailed operation of the work list mechanism is assumed to be 
vendor / system defined; two basic operational models exist
7 push, where work is automatically forced to a user
7 pull, where the user (or a desktop agent) selects and accepts items from the 
worklist 

Within the client application interface we defined an API set for a client 
application, typically a worklist handler or in-tray manager, to manipulate work 
items in dialogue with the WFMS, essentially using the pull model. [Push 
operations can also be accommodated by use of a distribution agent accessing the 
worklist through a subset of the APIs.]

Given the above approach to defining activities, one could always infer that an 
atomic activity exists as the bottom-most element of the work hierarchy; atomic 
in this sense meaning work allocated to a single participant [or processed in a 
system context] and associated with at most one IT application/tool. 

In this case there would be always be a  one:one relationship between the 
workitem and an atomic activity. The work-item would just represent the user 
manifestation of the activity.

However, many WfMC members were uncomfortable with this since it represents a 
heavyweight approach due to the system overheads potentially associated with 
each activity - e.g. audit & recovery data, system scheduling overheads, 
participant assignment and navigation. Hence we introduced the concept of a 
work-item as a separate element of work hierarchy below the activity, but 
without all the overheads:
7 all work-items within an activity share the same participant assignment 
rule(s)
7 there is no conditional navigation through work-items within an activity 
managed by the workflow system; all workitems within an activity are assumed to 
be actioned either sequentially or in parallel (specified by parameter within 
the process definition)
7 much simpler audit data requirements 

There has been no attempt to standardise the detailed approach to the 
presentation of workitems to users - many different approaches exist using VB 
apps, forms, mail items, applets, etc.

From a SWAP perspective I would recommend a simple approach, also. The pull 
model maps quite simply into a web environment and a number of vendors already 
support browser based worklist handlers using CGI and server side interfaces 
based on elements of WfMC interface 2 or similar. These could migrate easily to 
a SWAP standard, if defined, for this type of functionality.  

I believe work item management should be separate from the broader 
interoperability issues, which are concerned with work initiation and 
partitioning between server domains at a process or sub-process granularity, 
whereas work items are about local distribution of small granularity work.

I hope this helps with some of the background. On a more general level I feel 
there should be more dialogue between the SWAP group and WfMC, so please let me 
know if there are other areas where we might usefully converse.

Regards, Dave Hollingsworth

--------------------------------------------------------------------------------
Dave Hollingsworth
ICL Applications & Technical Consultancy
WfMC Technical Committee
d.c.hollingsworth@x400.icl.co.uk
+44 181 730 4112

Received on Friday, 4 December 1998 12:38:07 UTC