home contents changes options help subscribe

last edited 8 years ago by gvanrossum

Trying to unify Entity-based and Activity-based workflows

Status

This is not a proposal, more like a bunch of ideas and remarks.

Author

Florent Guillaume (efge)

Problem

This document presents the different concepts underlying entity-based workflows (EWF) and activity-based workflows (AWF), and tries to find what they have in common and if it is feasible to map one onto another.

Definitions

The following definitions are probably a bit biased toward working with a CMS, and toward the existing DCWorkflow? and OpenFlow? implementations.

Entity-based workflow

An entity-based workflow is a workflow that is centered around one entity, for instance a document.

An entity always has a state associated to it, and a set of possible transitions to new states if certain conditions are met. When an entity is in a given state, the authorized actors have a set of available actions they can do on the entity. Once an actor is happy with his work, he can choose one of the available transitions to a new state.

The prime example in Zope is DCWorkflow?.

The main concepts in the definition of a workflow in an EWF are:

  • states
  • transitions, with guards, deciding what is next

Activity-based workflow

An activity-based workflow is a workflow that is centered around a set of activities that someone (or something) has to do.

A given process instance (an instance of a process definition) may have several active workitems, which are the "pending" work a given actor has to do. Once a workitem is completed, the process definition specifies what are the next activities, and thus what new workitems must be created.

The best known example in Zope is OpenFlow?.

The main concepts in the definition of a process for an AWF are:

  • activities
    • applications that describe work
    • sub-process that recursively describe another process
  • transitions, with guards, deciding what's next

An example

We would like to unify these two concept into one underlying model. As both models can be seen using graphs with nodes and arrows, we would like to be able to map one into the other. Unfortunately, this is not straightforward.

The best way to understand why it is difficult is to try to build the same example in the most natural manner for both paradigms.

This example represents a simplification of a typical workflow for one document in Zope.

  • A document is created by someone (its owner).
  • The owner edits the document.
  • The owner submits the document for publication.
  • A reviewer sees the pending document in some kind of worklist and can reject it or publish it.
  • Once published, the owner or a reviewer can retract the document back to the private state where it can be edited again.

Entity-based version

In an EWF one has have 3 states, private, pending and published, with their transitions. In each state, the set of allowed work-related activities are implied by the roles set on the document and the permissions associated to that role.

  • private: visible/editable by Owner only
    • submit: go to pending
  • pending: visible by Owner and Reviewer, editable by no one
    • reject: go to private
    • publish: go to published
  • published: visible by Anonymous, editable by no one.
    • retract: go to private

The document is always in one of the 3 states, the initial state at creation time is private.

When a reviewer consults his worklist, he sees all the documents in the pending state.

Activity-based version

Here the "publication" workflow really has only one activity pertaining to it:

  • review: review the document, deciding if it has to be rejected or published. If it is published, then the application will take appropriate action to copy it somewhere or change its permissions.

To put a document into the workflow, an actor would create and edit a document (without any workflow attached), and then create a process instance and a workitem for the reviewing of his document.

When a reviewer consults his worklist, he sees all the workitems assigned to him, and can work on them. These workitems have been assigned from a global pool to the reviewer by some site policy (pull, push (manual or automatic)).

Mapping an EWF to an AWF

As we can see, the two models have some differences. As the AWF seems more general, let's see what's needed to map an arbitrary EWF (as exemplified by DCWorkflow?) to it:

  • The activities have to be made explicit.

    In DCWorkflow?, the activities available at a given time on a document are implicit to the state. They are all the activities that can be performed on the document given its current role/permission mapping, and they are made available through views of the UI. But in an AWF the activities are all explicit, and represented by workitems. The actual work to do is done by an application which is explicitely defined too.

  • The role/permission mapping that is set on a document for a given state can be seen has having several functions in an AWF setting.
    • To give some users some permission related to the activities they have to do ("edit" for instance). In the AWF this has to be part of the application itself (before the "edit" view is shown for instance).
    • To change the visibility of the document in a worklist. This is not necessary in the AWF as the worklist does not directly refer to the documents but to workitems.
    • To change the visibility of the document in the site. This has to be made part of a specific application (at the end of the "review" activity if "publish" is chosen for instance).
  • The transitions that were explicitely followed by a user must be made part of the activities preceding them. An activity with potentially several outgoing transitions has to "result" in a variable being set that will be used by the routing to decide what transition will be next.
  • The worklists in DCWorkflow? are defined implicitely by all the documents corresponding to certain criteria. In the AWF they are totally explicit.
  • In DCWorkflow? the document is always in one state of the workflow. But in the AWF a document is not always subject to a workflow, for instance it is only subject to review when the owner decides it should be. The AWF has finer granularity, so there would be a bigger number of AWF process definitions than of DCWorkflow? instances.

Partial conclusion

It will be difficult to map directly and exactly a given DCWorkflow? instance into a AWF. However it can be done manually, probably without loss of generality.

hathawsh (Nov 4, 2002 10:53 am; Comment #1)
I believe there are really two independent concepts that you're grappling with. Separating them makes things a lot clearer. The distinction between "activity-based" vs. "entity-based" is a misnomer. In reality, the first choice is between "application-centric" and "entity-centric" workflow. The second choice is between "activity diagram" and "state diagram".

Entity-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). Entity-centric workflow integrates well into existing applications. Application-centric workflow is the application.

The second choice is the diagramming model. DCWorkflow? uses a state diagram with no concurrency. It could just as easily use a state diagram with parallel flows, an activity diagram, a petri net, a flow chart, or something else. I suggest that for Zope 3 there ought to be "diagram" object types. Every kind of diagram (state, multi-state, activity, petri net, etc.) will provide an interface that workflow engines (or anything else) can use. They will supercede OpenFlow?'s "process definition" objects. They should be reusable in ways other than workflow, something Uri (sp?) suggested long ago.

Regarding mapping of diagrams, I believe you're oversimplifying both types of diagrams. In a state diagram, you also have to describe the transitions. In an activity diagram, you also have to be aware of possible states. So it's possible to map between the two, but perhaps we don't even need to if we have reusable diagram objects.

One could easily implement entity-centric workflow using an application-centric engine by mapping objects to workflow identifiers. Implementing application-centric workflow using an entity-centric engine is equally possible if you assign the word "entities" to mean "process instances" rather than "content objects". Therefore the distinction is less important than it would first appear.

So, in summary: I suggest we create an application-centric workflow engine and use identifiers to provide workflow verbs in the context of an object. CMFStaging? already leans in this direction. Then we should provide diagram object types, which provide an interface workflows engines can use.

jim (Nov 5, 2002 11:21 am; Comment #2)
 >       The main concepts in the definition of a process for an AWF are:
 > 
 >       - activities
 > 
 >         - applications that describe work
 > 
 >         - sub-process that recursively describe another process
 > 
 >       - transitions, with guards, deciding what's next

There are states here too. In fact, activities appear to me to be states. If they aren't states, how do they differ.

It appears to me that applications are equivalent to the features provided by an entity in a given state. Similarly, a process seems like an entity that anables different applications in different states.

Doesn't this imply states? If not, then what are the transitions between?

...

 >     Activity-based version
 > 
 >       Here the "publication" workflow really has only one activity
 >       pertaining to it:
 > 
 >       - review: review the document, deciding if it has to be rejected
 >          or published. If it is published, then the application will
 >          take appropriate action to copy it somewhere or change its
 >          permissions.

I think you could as easily include creation and editing in the process. Most documents are created to be published. In many organizations, autoring is part of an overall process.

 >       To put a document into the workflow, an actor would create and
 >       edit a document (without any workflow attached), and then create a
 >       process instance and a workitem for the reviewing of his document.

Or they culd create a process to create and publish an article. This allows authorship as well as review to be managed (e.g. tracked).

 >       When a reviewer consults his worklist, he sees all the workitems
 >       assigned to him, and can work on them. These workitems have been
 >       assigned from a global pool to the reviewer by some site policy
 >       (pull, push (manual or automatic)).

Similarly, if authorship was covered, the pending articles to be finsidhed would appear in the author's workitems.

...

 >     - The transitions that were explicitely followed by a user must be
 >       made part of the activities preceding them. An activity with
 >       potentially several outgoing transitions has to "result" in a
 >       variable being set that will be used by the routing to decide what
 >       transition will be next.

Well, in OpenFlow?, an activity can pick the next activity. This seems somewhat analogous to picking the next state in DCWorkflow?. DCWorkflow? also has a notion of automatic transitions.

 >     - The worklists in DCWorkflow are defined implicitely by all the
 >       documents corresponding to certain criteria. In the AWF they are
 >       totally explicit.

Yes, but this is a matter of implementation. One could, as easily use explicit work lists in DCWorkflow?.

 >     - In DCWorkflow the document is always in one state of the workflow.
 >       But in the AWF a document is not always subject to a workflow, for
 >       instance it is only subject to review when the owner decides it
 >       should be.

In DCWorkflow?, the document is a process instance. In AWF, a process instance is always in one or more states. 

 >       The AWF has finer granularity, so there would be a
 >       bigger number of AWF process definitions than of DCWorkflow
 >       instances.

I don't see why this would be the case. Finer granuality might lead to more complex process definitions for AWF. (I'm assuming that by "workflow instance", you mean the things that go in the workflow tool that define workflow processes.)

 >   Partial conclusion
 > 
 >     It will be difficult to map directly and exactly a given DCWorkflow
 >     instance into a AWF. However it can be done manually, probably
 >     without loss of generality.

By mapping, I assume you mean mapping automatically,

It seems to me that we have some similar concepts with different jargon.

Key concepts:

  • Workflow process definitions

    Workflow definitions define processes, including states/activities and trasnitions. I imagine that there could be several kinds of these, including kinds that emphasize an activity-based point of view and those that emphasize an entity-oriented point of view.

  • Workflow process instances

    These instances are a kind of content. They could look like an AWF process or like a EWF entity. In the AWF case, they might contain primarily processing information and be able to carry along instances of content being worked on. In the EMF case, the instances have a little bit of processing information (e.g. a state variable) and a bunch of data.

faassen (Nov 5, 2002 11:40 am; Comment #3)
Some interesting links:

Workflow patterns:

http://tmitwww.tm.tue.nl/research/patterns/

It would probably be useful to see which patterns we can catch with any future workflow system for Zope 3.

The author Wil van der Aalst also wrote a lot about why using petri nets for workflows is a good idea. Some of the stuff goes over my head and may be too low level or abstract but it is still worth examining:

http://citeseer.nj.nec.com/vanderaalst98application.html

(pdf or ps in top right corner)

for some examples of how to apply petri nets to represent some of the patterns.

jack-e (Nov 5, 2002 3:52 pm; Comment #4)
 >    It would probably be useful to see which patterns we can catch
 >    with any future workflow system for Zope 3.

Basically i think the following patterns are minimum requirement, everything beyond is optional and lot's of work (Refering to WorkflowPatterns?):

  • Sequence (needed in any case):

    An ActivityInstance? is enabled after another ActivityInstance? in the same ProcessInstance? has completed.

  • Parallel Split (AND-Split):

    A point in the ProcessInstance? where it splits into several, parallel running ActivityInstances?.

  • Exclusive Choice (XOR-Split):

    A point in the Process where ONE of n Transitions evaluates true and creates ONE new ActivityInstance? (first-come-first-serve).

  • Synchronisation (AND-Join):

    A point in the ProcessInstance? that needs to wait for all incoming Transitions from previous ActivityInstances? and then processes further.

  • Simple Join (XOR-Join):

    A point in the ProcessInstance? that waits for one incoming Transition from an ActivityInstance? and then processes further.

  • Loop:

    Repeat a certain sequence of Activities until a condition evaluates true

Most of the other Patterns can be achieved by combining these basic patterns.

TwoFlowers? (Nov 6, 2002 5:54 am; Comment #5)
Author: Daniele Tarini

Unifying the entity-based and activity-based approach to workflow (EWF and AWF) is a charming idea. But the differences the two approaches have make the unifying work pretty hard.

From my point of view AWFs? and EWFs? both have something unique, something that their respective cousin would find difficult to realize without dirty tricks or a lot of pain. For example:

  • AWFs? have difficulties with actions like the retract action in Florent's example. This is because when a workitem is pending on an activity, say review, the activity actions are the only actions the workitem can legally do. Users that are authorized on that activity are authorized for all the actions the activity has. So if you put a retract and publish actions on the review activity the users (all of the authorized users) can do both... the editor has to be put in the authorized users? He should, because he must be able to retract. He should not because he must not be able to publish. There is a workaround, of course, but it involves dirty tricks. Like allowing the editors in the activity and hiding the publish action to editors when they work on the review 's workitems. Or like not allowing the editor in the review activity and take some out-of-workflow action to be taken by editors move their workitems out of review.
  • EWFs?, on the other hand, have difficulties with parallel work to be done on a document, since the document state in a workflow is a single state, and can't be split in two states to be handled at the same time. This means you can't have two administrative offices handle the same paper at the same time, they will have to handle it sequencially. There is a workaround on this as well and it involves either dirty tricks or lot of pain. Like splitting the state in multiple states (eg: from pending_A_and_B_review to pending_A_and_B_review, pending_A_review, pending_B_review). Or like hiding contents to people that made their job, even though state is left unchanged.

I'm sure AWF and EWF have more problems than these two. But these are the first two that come to my mind. What I usually tell myself is "is it straightforward single state workflow? then EFW. Else? then AWF".

The way to map AWF on EWF and viceversa, goes through sorting out the problems AFWs? and EWFs? have. For the two problem examples given above this means allowing different actions for different roles on the same activity for AWFs?, and allowing multiple states for contents for EWFs?. Other problems (I couldn't think of right now) need other solutions. And all this might well go toward a possible unification of AWF and EWF.