[Zope3-dev] Workflow

[Ulrich Eck]

>> As a prelude to the work on workflow that will take place at the
>> Sprintathon, and before we hash out the needed interfaces and concepts,
>> I've written a document where I try to explain the different workflow
>> paradigms and look at them with an eye to finding a common ground.

As I'll be with you in Rotterdam .. i'll jump in after a long pause :)

I have not yet learned all the theory of Petri-Nets, StateDiagrams etc.
but i have had long thoughts on Workflow and read a lot related material.
I completley understood DCWorkflow and how it works and i made a prototype
of a WorkflowEngine that implements the WfMC Model completely.


> For the purpose of this discussion, I want to introduce the terms "object
> centric" and "application centric" workflow.  Object centric workflow
> assumes that the user first finds an object (a noun) then chooses what to
> do with it (a verb). DCWorkflow behaves this way. Application centric
> workflow assumes the user first chooses what to do (a verb) then the
> application figures out which objects to operate upon (nouns).  OpenFlow
> does this.  Object centric workflow is meant to be integrated into
> existing applications, while application centric workflow is the probably
> the main focus of the application.


Basically I think the concepts of AWF and EWF differ widely and i doubt
we can unify them without loosing benefits of each.


> DCWorkflow is object centric and uses state diagrams with no concurrency.
> OpenFlow is application centric and uses activity diagrams.  If we wanted
> to, we could upgrade DCWorkflow to use activity diagrams (or state
> diagrams with concurrency), but remain object centric.  Or we could
> instead choose to move to an application centric model while retaining
> state diagrams.  These two choices are really independent.

That's about visualization not implementation, right ??

> Then the difference between object-centric and application-centric
> workflow is simple: in an object-centric workflow, there is a mapping
> from object to process instance, while in an application-centric workflow
> there is a mapping from user (or role) to process instance. Stated
> differently, in an object-centric workflow you make the user find an
> object and then invoke some workflow action on it; in an
> application-centric workflow you present the user with a list of all
> tasks they are supposed to complete (and the user may never visit
> "objects").  In reality, you can combine both views into one system,
> which I expect most people want to do.  DCWorkflow tries to combine the
> two with "worklists", but is only partly successful.

in your description you oversimplify AWF (i still prever this one). It's
not the process that is assigned to the user, it's a WorkItem that one
user or a role has to do. Parrallel execution of tasks (ActivityInstances
that map to WorkItems) with different performers are necessary to implement
AWF properly, as well as different patterns e.g. AND/XOR-Join/Split, Loop.


> There is an interface in CMFCore called WorkflowDefinition.  It is
> similar in spirit to what I am proposing for the interface of process
> definitions, but the methods are too numerous and have the wrong names.
> It's still a start.
>
> Anyone see it differently?

well .. yes :)

I think of an AWF ProcessInstance (PI) in it's own right. After 
Initialization
with WorkflowRelevant Data there might WorkItems be created (tasks you call 
them)
or not .. depending on the inital data for example. It's not necessary to
query a PI for actions that need to be done, the workitems are created by 
the PI.

In my model, a PI is created from a ProcessDefinition (PD) -> think of a 
class and
it's instances. A PD defines Activities (A) and Transitions (T) with 
conditions,
as well as their participants and the applications used by it.

After an PI is instanciated the start-ActivityInstance (AI) is invoked.

An Activity specifies the Implementation e.g. No (needs to be done without 
help
from computer/app), Application (an application is invoked and presented to 
the
assigned performer), Subflow (another PI is created with from the specified 
PD),
Loop (a certain part of the PD is repeated until a condition evalutes to 
True
and the processing goes ahead), Route (a helper to build more advanced 
Workflows).
Activities although define how they behave for incoming/outgoing 
Transitions (e.g.
XOR/AND-Join and XOR/AND-Split).

Transitions have conditions, that are evaluated (in context of 
WorkflowRelevant Data)
and in combination with the Activities-Join/Split-Mode a number (1..n) 
Transitions
are executed that result in new ActivityInstances (AI).

Every AI has one WorkItem (WI) assigned and here is the point, where 
performers/actors
come into the game. They query (or get them pushed) their tasks, fetch and 
complete them.
Within the time a workitem is fetched and not completed, the actor can 
modify
WorkflowRelevant-Data through a well known interface. After completion the 
TransitionConditions
are evaluated and other AI's are instanced or the process is finished.

All this is heavily influenced by the WfMC model .. but it maps to 
real-world processes
best i think.

On the other side it would be an unwanted overhead to assign each 
contentobject a
PI like described above .. so i'ld like to see/build a system where both 
concepts
can live nearby without trying to cripple both concepts just to unify the 
access.

Try to convince me if i'm wrong .. Detailed information about how you would 
build
your diagram object would help understanding your vision better.

p.s. we will meet at #zope3-dev on Friday 14.00h CET for a discussion about 
workflow
and how we will go ahead for our work in rotterdam (vds, efge, hazmat, 
jack-e (me))

cheers

Ulrich Eck
------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck@net-labs.de
http://www.net-labs.de