[Zope3-dev] Workflow

[Shane Hathaway]

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

I don't mean to unify them, since they don't compete, so there is 
nothing to unify. :-)

>> 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 ??

No, it's both.

> 
>> 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.

I believe parallel execution is a detail of the process definition.

>> 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.

Yes, for many real-world processes, I agree.  And you have just 
described a process definition.  I see nothing in what you're saying 
that disagrees with my view. :-)

> 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.

I did not say that process instances would be assigned to content 
objects nor the other way around.  I said this last year, but that's not 
what I'm saying anymore.  The workflow engine would make decisions like 
this.

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

I originally came up with "diagram objects" but have since retracted 
that idea.  "Process definition" is the better description.

> 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))

I hope I'll have time to spend there.

Shane