You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Johan Stuyts <jo...@hippo.nl> on 2004/03/05 17:12:46 UTC
Experience with workflow at Hippo Webworks
Experience with workflow at Hippo Webworks
==========================================
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow I
will start with a (very) brief introduction to workflow.
Workflow introduction
---------------------
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do what)
a document (an object) after a writer has asked for a review (at which
time).
The lists of documents to be reviewed is an example of a pending task list
for an editor.
Each object type can have its own specific workflow.
The demo workflow
-----------------
The demo we created has a workflow for a basic document type, a web page.
I have attached a diagram of it.
A document gets created by a writer. The writer is not allowed to publish
his document directly, he has to ask the editor for review.
The editor can easily review documents because we generate a list of
documents waiting for review. The editor can click on the document and can
either approve or disapprove. If the document gets approved it is
published on the public server.
If the document gets disapproved the writer can not ask for a review
without editing it first. Editing the document when it has been approved
will bring the document back to the editing state too. After making his
changes the user can ask for a review of the new version.
Implementation
--------------
For the document repository we use Slide. For the workflow engine we used
OSWorkflow. We connected these two using Slide interceptors.
When a document is created the interceptor checks to see whether a
workflow already exists. It does this by retrieving the workflow ID from a
WebDAV property of the document. If it doesn't exist a new workflow is
created in the workflow store.
When our frontend retrieves the tree of documents, the interceptor will
retrieve the workflow for each document. Looking at the role of the user
the interceptor will determine which actions are enabled. The enabled
actions (including their display text and activation URLs) are set in a
WebDAV property of the document.
For the generation of the pending task list we used the OSWorkflow query
API to generate the documents which are in the waiting-for-review state.
The approve and disapprove actions are passed to the frontend in the same
way as the commands for a writer.
Not all actions are directly shown in the menu, because the user invokes
them implicitly. The edit action for example is invoked by the interceptor
each time the user saves the document.
Issues
------
We encountered issues with both slides and OSWorkflow during the
implementation.
Before we used Slide, we used the Cocoon repository. The semantics of the
repository interceptors and the Slide interceptors is not the same. With
the repository interceptor we were able to add a property to the document
in postStoreContent(...). In Slide we had to do this in
preStoreContent(...).
Apart from that the Slide interceptors work very well, but (in the version
of Slide we used) they get called a lot. A single store of a document
invoked preStoreContent(...) and postStoreContent(...) multiple times.
OSWorkflow performed great too. The only disadvantage was the complexity
of state machines that can be expressed. As you can see in the attached
diagram nested states are used. OSWorkflow does not support these.
Although the attached workflow does not contain parallel states, we think
it might be needed for some document types. A newsletter for example
follows the same workflow as the attached one. But parallel to this is a
mailing workflow for sending it to the newsletter subscribers.
In the mailing workflow the user can send a test email of the current
version to himself. When he is satisfied he can send the final version to
the newsletter subscribers. After this, he can neither send a test email
nor send it to the subscribers.
But what to do if a mistake in the newsletter is found after sending it to
the subscribers? The subscribers won't be happy to receive another copy,
so the mailing actions should stay blocked. But not correcting the
newsletter on the website looks sloppy. Therefore the
editing/reviewing/publishing workflow has to remain active.
Workflow requirements
---------------------
Building an effective and solid workflow solution requires two
preconditions. Both are outside the scope of the workflow framework:
- understandable role assignment (from a user's perspective) and simple
role retrieval;
- typed document repository. This is necessary to enable different
document types having different workflows attached to them.
When these two preconditions are met, the workflow framework must meet the
following basic requirements:
- the ability to specify under what conditions an action can be invoked.
Authorization is considered a specific type of condition;
- the ability to retrieve the actions which can be invoked by a particalur
user at this moment;
- the ability to query the workflow store for objects which are in a
specific state and are relevant to the current user.
The requirements on the main function of a workflow framework,
state-machine evaluation, depend on the complexity of the use cases which
need to be implemented.
Although we implemented the workflow in our demo using OSWorkflow we were
not completely satisfied. Some actions, edit and delete for example,
should be available in more than one state. We had to promote these
actions to global actions, and add conditions to these actions to check
whether the workflow is in a valid state. Because of this creative coding
the logic of the workflow moved out of its context and difficult to read
from the workflow configuration.
In our opinion a workflow framework supporting almost all constucts from
UML state machines is needed to be able to build powerful, and still
easy-to-understand solutions.
Where to go next
----------------
Our next goals are to make sure the two preconditions are met.
Concurrently we will be creating workflow use-cases to determine how
complex state machines need to be to implement these use cases.
We are very interested in hearing about use cases and workflow-framework
experiences from other people. We will update the existing page about
workflow on the Cocoon Wiki
(http://wiki.cocoondev.org/Wiki.jsp?page=Workflow) with our experiences.
Johan Stuyts
Hippo Webworks
http://www.hippo.nl/
johan (at) hippo (dot) nl
Re: Experience with workflow at Hippo Webworks
Posted by Stefano Mazzocchi <st...@apache.org>.
Johan Stuyts wrote:
> On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi
> <st...@apache.org> wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> Guido Casper wrote:
>>>>
>>>>> Stefano Mazzocchi wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>> If FSM work bad for flow, why would they work any better for
>>>>>> workflow?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> After thinking again about ways to use continuations with workflow I
>>>>> came to the conclusion this might well be possible. But it looks
>>>>> awkward
>>>>> to me.
>>>>>
>>>>> Each document attached to workflow would need a workflow instance as
>>>>> long as the document lives (from creation to deletion). This would
>>>>> mean
>>>>> the continuation stack of every document needs to be persisted to -
>>>>> well
>>>>> - to a database if you don't want to limit your clustering options.
>>>>> The
>>>>> document has a property holding the continuation ID.
>>>>
>>>>
>>>>
>>>>
>>>> You have a point here, Guido. It is true that continuations in a
>>>> distributed environment would need to be made custer-friendly and
>>>> replicated. This would probably impact the overall performance... but
>>>> keep in mind that continuations are just another way to save state.
>>>> That kind of state transformation (think REST) will have to be done
>>>> anyway.
>>>
>>>
>
> I thought about this too and think that the current workflow should be
> accessible without the user holding a special token. If I have a tree of
> documents I should be able to invoke any active command on a document in
> that tree.
with no token, there is no state, therefore no authentication. I think
that what you are asking is either impossible or I wouldn't call it
workflow but simply "accessing a web resource".
>>> The lifetime of a workflow instance also makes a big difference
>>> regarding business process changes. I experienced in a previous job in a
>>> large company some workflows (e.g. purchase orders) who changed several
>>> times a year, depending on structural changes in the company's
>>> organization. And already running instances had to adapt to the new
>>> worflow from the state they were in at the date of workflow change.
>>>
>>> This makes continuations technically not suitable for this, as once a
>>> continuation has been created, it's tied to the program's structure
>>> where it was created, and it cannot be "rerouted" to a location in
>>> another version of the same program.
>>>
>
> This won't be easy in state machines either, but I think it is possible
> if you store state paths. When the workflow instance is read by a new
> workflow definition, the definition matches the paths to his states.
You can call it whatever you want but a "state" in a FSM and a
"continuation" in a script are exactly the same thing, they need to
contain the same amount of data to be able to resort the execution.
The problems in replicating one across containers will be the same
problems in replicating the other.
>>> Furthermore, there exists what is called "ad-hoc" worklows, where a
>>> user, depending on its rights, can modify the workflow for a particular
>>> instance. An example of this is when a document has to be published that
>>> contains highly technical material. The editor may want to add an
>>> additional step in the workflow for the document to be validated by a
>>> technical expert, which doesn't happen in normal cases.
>>>
>>> In that situation, asking a user to write a new version of a program for
>>> that specific need doesn't seem a good solution to me ;-)
>>
>>
>> Wait a second: to you think that guy would be more confortable in
>> writing a FSM code?
>>
>
> I think the option to request review by a technical expert should be
> programmed explicitly by the developers too. Instead of just 'publish'
> and 'disapprove', the editor can also invoke 'request technical review'.
No matter what, an editor is not going to write neither FSM or script
code. And even if you throw something like Oracle Workflow at him, he
will hire somebody else to do it.
>> Let's compare apples to apples here: we are not discussing how the
>> workflows should be edited, but how they are going to impact our system
>> and how we are going to build them.
>>
>> there are several solution on the table and at least two architecturally
>> orthogonal questions:
>>
>> 1) should the workflow engine have direct data control?
>
>
> For me the data should reside in the document/object to which the
> workflow instance :) is attached. The only information stored in a
> workflow instance is (possibly) an identifier which can be used to
> locate the document/object.
>
> The actual implementation of the conditions and the actions that get
> executed on certain events should not be in the workflow definition, but
> should be separate. The workflow definition only references these
> separate implementations. The implementations get passed the identifier
> of the document/object when invoked, so they can retrieve the
> document/object to do their work.
>
>> 2) should the workflow engine deal with procedural scripts or finite
>> state machines directly?
>>
>
> State machine junkie talking: state machines. I see state machines as a
> different way of programming than procedural, and think that coding them
> using procedural code will be more difficult. The conditions and actions
> which connect the workflow instance to the environment it is running in
> are procedural, and that's why I program these in Java (in our demo).
Finite state machine represent a way to program declaratively. This
requires normally a higher level of abstraction and, for example, it
could be identified as the reason why Lisp and friends, although the
most powerful programming languages, didn't take off.
You see the same problem emerging in XSLT (XSLT is, in fact, a Lisp-like
language with an XML syntax, being the direct descendant of DSSSL): it's
hard to find people that can write XSLT. They are a special cast. They
are scarce. This translated on the market as: they cost more!
FSM are harder to program for web applications, I still don't see why
they should be easier to program for workflows.
Probably I need an example here to really appreciate the two
complexities side by side.
--
Stefano.
Re: Experience with workflow at Hippo Webworks
Posted by Johan Stuyts <jo...@hippo.nl>.
On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi <st...@apache.org>
wrote:
> Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Guido Casper wrote:
>>>
>>>> Stefano Mazzocchi wrote:
>>>
>>>
>>>
>>>>> If FSM work bad for flow, why would they work any better for
>>>>> workflow?
>>>>
>>>>
>>>>
>>>> After thinking again about ways to use continuations with workflow I
>>>> came to the conclusion this might well be possible. But it looks
>>>> awkward
>>>> to me.
>>>>
>>>> Each document attached to workflow would need a workflow instance as
>>>> long as the document lives (from creation to deletion). This would
>>>> mean
>>>> the continuation stack of every document needs to be persisted to -
>>>> well
>>>> - to a database if you don't want to limit your clustering options.
>>>> The
>>>> document has a property holding the continuation ID.
>>>
>>>
>>>
>>> You have a point here, Guido. It is true that continuations in a
>>> distributed environment would need to be made custer-friendly and
>>> replicated. This would probably impact the overall performance... but
>>> keep in mind that continuations are just another way to save state.
>>> That kind of state transformation (think REST) will have to be done
>>> anyway.
>>
I thought about this too and think that the current workflow should be
accessible without the user holding a special token. If I have a tree of
documents I should be able to invoke any active command on a document in
that tree.
>>
>>
>> The lifetime of a workflow instance also makes a big difference
>> regarding business process changes. I experienced in a previous job in a
>> large company some workflows (e.g. purchase orders) who changed several
>> times a year, depending on structural changes in the company's
>> organization. And already running instances had to adapt to the new
>> worflow from the state they were in at the date of workflow change.
>>
>> This makes continuations technically not suitable for this, as once a
>> continuation has been created, it's tied to the program's structure
>> where it was created, and it cannot be "rerouted" to a location in
>> another version of the same program.
>>
This won't be easy in state machines either, but I think it is possible if
you store state paths. When the workflow instance is read by a new
workflow definition, the definition matches the paths to his states.
>> Furthermore, there exists what is called "ad-hoc" worklows, where a
>> user, depending on its rights, can modify the workflow for a particular
>> instance. An example of this is when a document has to be published that
>> contains highly technical material. The editor may want to add an
>> additional step in the workflow for the document to be validated by a
>> technical expert, which doesn't happen in normal cases.
>>
>> In that situation, asking a user to write a new version of a program for
>> that specific need doesn't seem a good solution to me ;-)
>
> Wait a second: to you think that guy would be more confortable in
> writing a FSM code?
>
I think the option to request review by a technical expert should be
programmed explicitly by the developers too. Instead of just 'publish' and
'disapprove', the editor can also invoke 'request technical review'.
> Let's compare apples to apples here: we are not discussing how the
> workflows should be edited, but how they are going to impact our system
> and how we are going to build them.
>
> there are several solution on the table and at least two architecturally
> orthogonal questions:
>
> 1) should the workflow engine have direct data control?
For me the data should reside in the document/object to which the workflow
instance :) is attached. The only information stored in a workflow
instance is (possibly) an identifier which can be used to locate the
document/object.
The actual implementation of the conditions and the actions that get
executed on certain events should not be in the workflow definition, but
should be separate. The workflow definition only references these separate
implementations. The implementations get passed the identifier of the
document/object when invoked, so they can retrieve the document/object to
do their work.
> 2) should the workflow engine deal with procedural scripts or finite
> state machines directly?
>
State machine junkie talking: state machines. I see state machines as a
different way of programming than procedural, and think that coding them
using procedural code will be more difficult. The conditions and actions
which connect the workflow instance to the environment it is running in
are procedural, and that's why I program these in Java (in our demo).
> my take would be
>
> 1) no, it should be saparate, sort of a process knowledge base that
> the flow logic interrogates when it need to
>
> 2) procedural scripts: they are always easier to program
>
> but, there are valid and solid arguments to make me change my mind on 2)
> so I think it's better to explore whatever solution makes more sense
> right now and expand for that, instead of spending too much time on the
> whiteboard without getting anything out of the door.
>
--
Johan Stuyts
Re: Experience with workflow at Hippo Webworks
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Guido Casper wrote:
>>
>>> Stefano Mazzocchi wrote:
>>
>>
>>
>>>> If FSM work bad for flow, why would they work any better for workflow?
>>>
>>>
>>>
>>> After thinking again about ways to use continuations with workflow I
>>> came to the conclusion this might well be possible. But it looks awkward
>>> to me.
>>>
>>> Each document attached to workflow would need a workflow instance as
>>> long as the document lives (from creation to deletion). This would mean
>>> the continuation stack of every document needs to be persisted to - well
>>> - to a database if you don't want to limit your clustering options. The
>>> document has a property holding the continuation ID.
>>
>>
>>
>> You have a point here, Guido. It is true that continuations in a
>> distributed environment would need to be made custer-friendly and
>> replicated. This would probably impact the overall performance... but
>> keep in mind that continuations are just another way to save state.
>> That kind of state transformation (think REST) will have to be done
>> anyway.
>
>
>
> The lifetime of a workflow instance also makes a big difference
> regarding business process changes. I experienced in a previous job in a
> large company some workflows (e.g. purchase orders) who changed several
> times a year, depending on structural changes in the company's
> organization. And already running instances had to adapt to the new
> worflow from the state they were in at the date of workflow change.
>
> This makes continuations technically not suitable for this, as once a
> continuation has been created, it's tied to the program's structure
> where it was created, and it cannot be "rerouted" to a location in
> another version of the same program.
>
> Furthermore, there exists what is called "ad-hoc" worklows, where a
> user, depending on its rights, can modify the workflow for a particular
> instance. An example of this is when a document has to be published that
> contains highly technical material. The editor may want to add an
> additional step in the workflow for the document to be validated by a
> technical expert, which doesn't happen in normal cases.
>
> In that situation, asking a user to write a new version of a program for
> that specific need doesn't seem a good solution to me ;-)
Wait a second: to you think that guy would be more confortable in
writing a FSM code?
Let's compare apples to apples here: we are not discussing how the
workflows should be edited, but how they are going to impact our system
and how we are going to build them.
there are several solution on the table and at least two architecturally
orthogonal questions:
1) should the workflow engine have direct data control?
2) should the workflow engine deal with procedural scripts or finite
state machines directly?
my take would be
1) no, it should be saparate, sort of a process knowledge base that
the flow logic interrogates when it need to
2) procedural scripts: they are always easier to program
but, there are valid and solid arguments to make me change my mind on 2)
so I think it's better to explore whatever solution makes more sense
right now and expand for that, instead of spending too much time on the
whiteboard without getting anything out of the door.
--
Stefano.
Re: Experience with workflow at Hippo Webworks
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Guido Casper wrote:
>
>> Stefano Mazzocchi wrote:
>
>
>>> If FSM work bad for flow, why would they work any better for workflow?
>>
>>
>> After thinking again about ways to use continuations with workflow I
>> came to the conclusion this might well be possible. But it looks awkward
>> to me.
>>
>> Each document attached to workflow would need a workflow instance as
>> long as the document lives (from creation to deletion). This would mean
>> the continuation stack of every document needs to be persisted to - well
>> - to a database if you don't want to limit your clustering options. The
>> document has a property holding the continuation ID.
>
>
> You have a point here, Guido. It is true that continuations in a
> distributed environment would need to be made custer-friendly and
> replicated. This would probably impact the overall performance... but
> keep in mind that continuations are just another way to save state.
> That kind of state transformation (think REST) will have to be done
> anyway.
The lifetime of a workflow instance also makes a big difference
regarding business process changes. I experienced in a previous job in a
large company some workflows (e.g. purchase orders) who changed several
times a year, depending on structural changes in the company's
organization. And already running instances had to adapt to the new
worflow from the state they were in at the date of workflow change.
This makes continuations technically not suitable for this, as once a
continuation has been created, it's tied to the program's structure
where it was created, and it cannot be "rerouted" to a location in
another version of the same program.
Furthermore, there exists what is called "ad-hoc" worklows, where a
user, depending on its rights, can modify the workflow for a particular
instance. An example of this is when a document has to be published that
contains highly technical material. The editor may want to add an
additional step in the workflow for the document to be validated by a
technical expert, which doesn't happen in normal cases.
In that situation, asking a user to write a new version of a program for
that specific need doesn't seem a good solution to me ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Guido Casper wrote:
>>> The major drawback currently is that my AbstractState has to know
>>> about all the other states (to prevent each State class having to
>>> know about all the other states) and (when adding NewState) has to be
>>> updated with: allowEnterNewState(doc, user) {return false;}
>>>
>>> I have the gut felling that this may be solved with some piece of
>>> AOP but I don't know enough about AOP and I currently don't care
>>> enough as this already satifisfies my needs.
>>>
>>> Of course any State object allowing transitioning to NewState has to
>>> be updated with the corresponding conditional logic (overriding
>>> allowEnterNewState). Each state has to know about other states it
>>> allows transitioning to and the conditional logic (if any) to do so.
>>
>>
>>
>> This sounds a bit overwhelming, there are too many dependencies to
>> account for and you end up with a very proprietary and not reusable code.
>
>
> What depencies do you mean? Actually I found changing workflow very easy
> and flexible as long as you don't come up with new states.
That being said, if I would find a way to synchronize the state objects
configured in my configuration file with the getAllowedXY Methods in my
AbstractState class I would be perfectly happy (although it doesn't hurt
me enough to further invest much time in looking for a solution for that).
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Johan Stuyts <jo...@hippo.nl>.
On Sun, 07 Mar 2004 21:47:26 +0100, Gianugo Rabellino <gi...@apache.org>
wrote:
> Guido Casper wrote:
>
>> Gianugo Rabellino wrote:
>>> For one, this might buy usage of some well-established worflow
>>> description languages, such as XPDL or BPEL: this would mean, in turn,
>>> being able to use existing tools to manage the workflow configuration.
>>>
>>> This is a very important point IMO: workflow configuration shouldn't
>>> belong to programmers: it's a job for business people who shouldn't
>>> give a damn about Java/Javascript/XML, then need drawing tools.
>>
>>
>> That's perfectly fine. It just doesn't reflect my current use case :-)
>> I can imagine something like that for workflow logic just not for page
>> flow logic.
>
> What is the difference among the two? "Page flow logic" means navigation
> to me, while workflow (in CMS) is a way to describe formally a process
> of any kind that affects the lifecycle of a resource. Now, this actually
> means "how a resource gets published" in its most simple incarnation
> (and granted I've seen so many overcomplex workflow in planning stage
> become a "publish" button in production), but ir could be more complex
> than that.
>
>>>
>>>> <workflow-manager>
>>>> <state name="tobeprocessed" class="TobeprocessedState">
>>>> <entering-action class="TobeprocessedAction"/>
>>>> </state>
>>>> <state name="beingprocessed" class="BeingprocessedState">
>>>> <entering-action class="BeingprocessedAction"/>
>>>> <leaving-action class="LeaveBeingprocessedAction"/>
>>>> </state>
>>>> <state name="tobereviewed" class="ToreviewedState">
>>>> <entering-action class="TobecheckedAction"/>
>>>> </state>
>>>> ...
>>>> </workflow-manager>
>>>>
>>>
>>> I'm afraid it's not that simple. Your workflow allows only for a
>>> linear flow, where you have only one way to go in the opposite
>>> directions (back and forth). But quite often you need to be able to
>>> model n ways in or out, you might need conditionals, you might need
>>> vetoes, and so on and on: workflow is a messy beast to handle.
>>
>>
>> Gianugo, this configuration is not meant to be a description of my
>> workflow.
>> It's a definition of what state objects are available.
>
> Doesn't quite looke like that: you seem to be mixing states and
> transitions, by explicitely telling States which are the back and forth
> states (here transitions are opaque). IMO you should have lists of
> states, list of transitions and then something to glue them together
> (much like woody^H^H^H^H^Hcforms does for definition and template).
I do not agree with you here. A state machine is a single concern for me.
Separating a state machine into states and transitions which are defined
at different locations makes everything more difficult to understand.
The Lenya workflow definition XML places the transitions below the states
and I find this very inconvenient. A transition is bound to the source
state. When I am in a particular state I want to know where I can go next.
I have never needed to know where I came from. If you care about this,
then you don't have a state machine (maybe you should split states). The
current state should provide enough context for handling the next action
that gets invoked.
The only reuse I see are the functions that get called for evaluating
conditions, when entering a state and when leaving a state.
>
>> The actual workflow is made up of the State objects themselves (as I
>> said, the workflow is coded in Java, not in XML). Actually "State
>> object" might be misnamed (I just took it from the state pattern) as
>> they don't hold any state (or other data) but get instantiated by the
>> workflow engine when reading the current state of an object. They just
>> hold the conditional logic. This means, looking at the state objects
>> you don't see the overall workflow. But that's the whole idea. You just
>> code isolated steps and decisions of workflow since every workflow may
>> be broken down into isolated steps.
>>
>> The alternative would be to have a giant nested case statement.
>
> Well, isn't it what the actual workflow is? What you do in the typical
> scenario is:
>
> a) define states;
> b) define transitions;
> c) persist the state as an object attribute;
> d) get the state attribute and run a gian nested case statement.
>
> The State pattern embellishes all this mess, but it's still there
> nevertheless: somewhere you have to put the switchboard anyway.
>
>>>> The major drawback currently is that my AbstractState has to know
>>>> about all the other states (to prevent each State class having to
>>>> know about all the other states) and (when adding NewState) has to be
>>>> updated with: allowEnterNewState(doc, user) {return false;}
>
> Hmmm... I see that all your samples refer to user objects flying around:
> aren't you mixing concerns here? User verification belongs to the
> authorization level...
The authorization has to be performed on individual actions and not on the
whole object. Also the roles of a person are not global, but document
specific. If you have a big site it is possible you have an editor for
each section of the site. If the authorization level is capable of
performing this kind of authorization, the authorization should be moved
here ofcourse.
>
>>> This sounds a bit overwhelming, there are too many dependencies to
>>> account for and you end up with a very proprietary and not reusable
>>> code.
>>
>> What depencies do you mean? Actually I found changing workflow very
>> easy and flexible as long as you don't come up with new states.
>
> ... which is exactly the point of user-defined workflows.
>
>> It is true that the state objects themselves are not reusable (and are
>> not meant to be) but so would be any construct describing the actual
>> workflow (which is the only thing the state objects actually do).
>
> I can live with actual workflow not be reusable, but there must be a way
> to reuse state objects...
>
>>> But in any case, I think that states shouldn't give a damn about other
>>> states: transactions might need that.
>>
>>
>> Yes, maybe they are misnamed. Just replace "states" with "transaction"
>> (or even better "transitions").
>
> Yepp, transitions of course, sorry for the misnaming. :-)
>
> Ciao,
>
--
Johan Stuyts
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Gianugo Rabellino wrote:
> Guido Casper wrote:
>> Gianugo Rabellino wrote:
>>>> <workflow-manager>
>>>> <state name="tobeprocessed" class="TobeprocessedState">
>>>> <entering-action class="TobeprocessedAction"/>
>>>> </state>
>>>> <state name="beingprocessed" class="BeingprocessedState">
>>>> <entering-action class="BeingprocessedAction"/>
>>>> <leaving-action class="LeaveBeingprocessedAction"/>
>>>> </state>
>>>> <state name="tobereviewed" class="ToreviewedState">
>>>> <entering-action class="TobecheckedAction"/>
>>>> </state>
>>>> ...
>>>> </workflow-manager>
>>>>
>>>
>>> I'm afraid it's not that simple. Your workflow allows only for a
>>> linear flow, where you have only one way to go in the opposite
>>> directions (back and forth). But quite often you need to be able to
>>> model n ways in or out, you might need conditionals, you might need
>>> vetoes, and so on and on: workflow is a messy beast to handle.
>>
>>
>>
>> Gianugo, this configuration is not meant to be a description of my
>> workflow.
>> It's a definition of what state objects are available.
>
>
> Doesn't quite looke like that:
Yes, sorry maybe I should have mentioned that more explicitely.
> you seem to be mixing states and
> transitions, by explicitely telling States which are the back and forth
> states (here transitions are opaque).
No, that's not the case.
> IMO you should have lists of
> states,
That's what I (believed to) have.
> list of transitions
Since any state might have n outgoing transitions I coded the outgoing
transitions into the state objects (and therefore maybe they are better
named transistions :-).
> and then something to glue them together
And that will always be the most nasty part.
The way I did it, is that the actual states are no objects, but simply
strings. What should a state object do anyway? (I'm trying to learn). In
the same sense, what should a transition object do if it's not actually
"glueing something together". _Any_ combination of 2 states is a
potential transition (I believe I don't need all these extra objects
because I don't code in XML but in Java). When the workflow engine
encounters a state defined within the configuration, it asks the
state-better-named-transition objects which transitions might be allowed.
Gianugo, I'm in no way against having the possibility to easily
integrate OSWorkflow or other 3rd party workflow engines.
However I believe the complexity of the workflow I described in another
email is >= 80% of all workflow requirements. If I can come up with a
solution (and believe me, I'm wide open to suggestions for improvement
or alternatives) within 3 days, I prefer that. What I want is simple
solutions to simple problems.
I just couldn't find out how to use OSWorkflow within 2 hours so I moved
on. Anything else would have been beyond my budget and my scope.
Did you follow Tim Bray's blog ranting about TPSM (Technology Predictor
Success Matrix)?
http://www.tbray.org/ongoing/What/Technology/Prediction/
He examined 11 candidate predictors (potential success factors for a new
technology). The winner of this 11 candidate predictors was the 80/20
point (being able to come up with 80% of functionality with 20% effort).
:-)
>> What depencies do you mean? Actually I found changing workflow very
>> easy and flexible as long as you don't come up with new states.
>
>
> ... which is exactly the point of user-defined workflows.
I don't need user-defined workflows and I didn't want to suggest to
adapt my approach (just wanting to provide input) but FWIW if you change
getAllowedXY(doc user)
to
getAllowed(state, doc, user)
it at least _appears_ to be more reusable :-)
But again, the major point is connecting the states together, and you
would have to specify it somehow when adding new states or changing the
workflow and I doubt this really is easier to do with a XML syntax.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Gianugo Rabellino <gi...@apache.org>.
Guido Casper wrote:
> Gianugo Rabellino wrote:
>> For one, this might buy usage of some well-established worflow
>> description languages, such as XPDL or BPEL: this would mean, in turn,
>> being able to use existing tools to manage the workflow configuration.
>>
>> This is a very important point IMO: workflow configuration shouldn't
>> belong to programmers: it's a job for business people who shouldn't
>> give a damn about Java/Javascript/XML, then need drawing tools.
>
>
> That's perfectly fine. It just doesn't reflect my current use case :-) I
> can imagine something like that for workflow logic just not for page
> flow logic.
What is the difference among the two? "Page flow logic" means navigation
to me, while workflow (in CMS) is a way to describe formally a process
of any kind that affects the lifecycle of a resource. Now, this actually
means "how a resource gets published" in its most simple incarnation
(and granted I've seen so many overcomplex workflow in planning stage
become a "publish" button in production), but ir could be more complex
than that.
>>
>>> <workflow-manager>
>>> <state name="tobeprocessed" class="TobeprocessedState">
>>> <entering-action class="TobeprocessedAction"/>
>>> </state>
>>> <state name="beingprocessed" class="BeingprocessedState">
>>> <entering-action class="BeingprocessedAction"/>
>>> <leaving-action class="LeaveBeingprocessedAction"/>
>>> </state>
>>> <state name="tobereviewed" class="ToreviewedState">
>>> <entering-action class="TobecheckedAction"/>
>>> </state>
>>> ...
>>> </workflow-manager>
>>>
>>
>> I'm afraid it's not that simple. Your workflow allows only for a
>> linear flow, where you have only one way to go in the opposite
>> directions (back and forth). But quite often you need to be able to
>> model n ways in or out, you might need conditionals, you might need
>> vetoes, and so on and on: workflow is a messy beast to handle.
>
>
> Gianugo, this configuration is not meant to be a description of my
> workflow.
> It's a definition of what state objects are available.
Doesn't quite looke like that: you seem to be mixing states and
transitions, by explicitely telling States which are the back and forth
states (here transitions are opaque). IMO you should have lists of
states, list of transitions and then something to glue them together
(much like woody^H^H^H^H^Hcforms does for definition and template).
> The actual
> workflow is made up of the State objects themselves (as I said, the
> workflow is coded in Java, not in XML). Actually "State object" might be
> misnamed (I just took it from the state pattern) as they don't hold any
> state (or other data) but get instantiated by the workflow engine when
> reading the current state of an object. They just hold the conditional
> logic. This means, looking at the state objects you don't see the
> overall workflow. But that's the whole idea. You just code isolated
> steps and decisions of workflow since every workflow may be broken down
> into isolated steps.
>
> The alternative would be to have a giant nested case statement.
Well, isn't it what the actual workflow is? What you do in the typical
scenario is:
a) define states;
b) define transitions;
c) persist the state as an object attribute;
d) get the state attribute and run a gian nested case statement.
The State pattern embellishes all this mess, but it's still there
nevertheless: somewhere you have to put the switchboard anyway.
>>> The major drawback currently is that my AbstractState has to know
>>> about all the other states (to prevent each State class having to
>>> know about all the other states) and (when adding NewState) has to be
>>> updated with: allowEnterNewState(doc, user) {return false;}
Hmmm... I see that all your samples refer to user objects flying around:
aren't you mixing concerns here? User verification belongs to the
authorization level...
>> This sounds a bit overwhelming, there are too many dependencies to
>> account for and you end up with a very proprietary and not reusable code.
>
> What depencies do you mean? Actually I found changing workflow very easy
> and flexible as long as you don't come up with new states.
... which is exactly the point of user-defined workflows.
> It is true that the state objects themselves are not reusable (and are
> not meant to be) but so would be any construct describing the actual
> workflow (which is the only thing the state objects actually do).
I can live with actual workflow not be reusable, but there must be a way
to reuse state objects...
>> But in any case, I think that states shouldn't give a damn about other
>> states: transactions might need that.
>
>
> Yes, maybe they are misnamed. Just replace "states" with "transaction"
> (or even better "transitions").
Yepp, transitions of course, sorry for the misnaming. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Gianugo Rabellino wrote:
> Guido Casper wrote:
>
>>> Interesting. would you like to share that with us? I think it would
>>> be avery good exercise to see the two approaches one beside the other.
>>
>>
>>
>> I don't have interest in generating my complete workflow logic out of
>> a UML diagramm or a XML file. I remember there have been thoughts
>> about generating flowscript out of a XML file describing my page flow
>> logic, but I doubt that will ever happen. I can't grasp what that
>> would give me (now that I have flowscript available :-).
>
>
>
> For one, this might buy usage of some well-established worflow
> description languages, such as XPDL or BPEL: this would mean, in turn,
> being able to use existing tools to manage the workflow configuration.
>
> This is a very important point IMO: workflow configuration shouldn't
> belong to programmers: it's a job for business people who shouldn't give
> a damn about Java/Javascript/XML, then need drawing tools.
That's perfectly fine. It just doesn't reflect my current use case :-) I
can imagine something like that for workflow logic just not for page
flow logic.
>
>> <workflow-manager>
>> <state name="tobeprocessed" class="TobeprocessedState">
>> <entering-action class="TobeprocessedAction"/>
>> </state>
>> <state name="beingprocessed" class="BeingprocessedState">
>> <entering-action class="BeingprocessedAction"/>
>> <leaving-action class="LeaveBeingprocessedAction"/>
>> </state>
>> <state name="tobereviewed" class="ToreviewedState">
>> <entering-action class="TobecheckedAction"/>
>> </state>
>> ...
>> </workflow-manager>
>>
>
> I'm afraid it's not that simple. Your workflow allows only for a linear
> flow, where you have only one way to go in the opposite directions (back
> and forth). But quite often you need to be able to model n ways in or
> out, you might need conditionals, you might need vetoes, and so on and
> on: workflow is a messy beast to handle.
Gianugo, this configuration is not meant to be a description of my workflow.
It's a definition of what state objects are available. The actual
workflow is made up of the State objects themselves (as I said, the
workflow is coded in Java, not in XML). Actually "State object" might be
misnamed (I just took it from the state pattern) as they don't hold any
state (or other data) but get instantiated by the workflow engine when
reading the current state of an object. They just hold the conditional
logic. This means, looking at the state objects you don't see the
overall workflow. But that's the whole idea. You just code isolated
steps and decisions of workflow since every workflow may be broken down
into isolated steps.
The alternative would be to have a giant nested case statement.
>
>> The major drawback currently is that my AbstractState has to know
>> about all the other states (to prevent each State class having to know
>> about all the other states) and (when adding NewState) has to be
>> updated with: allowEnterNewState(doc, user) {return false;}
>>
>> I have the gut felling that this may be solved with some piece of AOP
>> but I don't know enough about AOP and I currently don't care enough as
>> this already satifisfies my needs.
>>
>> Of course any State object allowing transitioning to NewState has to
>> be updated with the corresponding conditional logic (overriding
>> allowEnterNewState). Each state has to know about other states it
>> allows transitioning to and the conditional logic (if any) to do so.
>
>
> This sounds a bit overwhelming, there are too many dependencies to
> account for and you end up with a very proprietary and not reusable
> code.
What depencies do you mean? Actually I found changing workflow very easy
and flexible as long as you don't come up with new states.
It is true that the state objects themselves are not reusable (and are
not meant to be) but so would be any construct describing the actual
workflow (which is the only thing the state objects actually do).
> But in any case, I think that states shouldn't give a damn about
> other states: transactions might need that.
Yes, maybe they are misnamed. Just replace "states" with "transaction"
(or even better "transitions").
Guido
Re: Experience with workflow at Hippo Webworks
Posted by Gianugo Rabellino <gi...@apache.org>.
Guido Casper wrote:
>> Interesting. would you like to share that with us? I think it would be
>> avery good exercise to see the two approaches one beside the other.
>
>
> I don't have interest in generating my complete workflow logic out of a
> UML diagramm or a XML file. I remember there have been thoughts about
> generating flowscript out of a XML file describing my page flow logic,
> but I doubt that will ever happen. I can't grasp what that would give me
> (now that I have flowscript available :-).
For one, this might buy usage of some well-established worflow
description languages, such as XPDL or BPEL: this would mean, in turn,
being able to use existing tools to manage the workflow configuration.
This is a very important point IMO: workflow configuration shouldn't
belong to programmers: it's a job for business people who shouldn't give
a damn about Java/Javascript/XML, then need drawing tools.
> <workflow-manager>
> <state name="tobeprocessed" class="TobeprocessedState">
> <entering-action class="TobeprocessedAction"/>
> </state>
> <state name="beingprocessed" class="BeingprocessedState">
> <entering-action class="BeingprocessedAction"/>
> <leaving-action class="LeaveBeingprocessedAction"/>
> </state>
> <state name="tobereviewed" class="ToreviewedState">
> <entering-action class="TobecheckedAction"/>
> </state>
> ...
> </workflow-manager>
>
I'm afraid it's not that simple. Your workflow allows only for a linear
flow, where you have only one way to go in the opposite directions (back
and forth). But quite often you need to be able to model n ways in or
out, you might need conditionals, you might need vetoes, and so on and
on: workflow is a messy beast to handle.
> The major drawback currently is that my AbstractState has to know about
> all the other states (to prevent each State class having to know about
> all the other states) and (when adding NewState) has to be updated with:
> allowEnterNewState(doc, user) {return false;}
>
> I have the gut felling that this may be solved with some piece of AOP
> but I don't know enough about AOP and I currently don't care enough as
> this already satifisfies my needs.
>
> Of course any State object allowing transitioning to NewState has to be
> updated with the corresponding conditional logic (overriding
> allowEnterNewState). Each state has to know about other states it allows
> transitioning to and the conditional logic (if any) to do so.
This sounds a bit overwhelming, there are too many dependencies to
account for and you end up with a very proprietary and not reusable
code. But in any case, I think that states shouldn't give a damn about
other states: transactions might need that.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi wrote:
> Guido Casper wrote:
>
>> Stefano Mazzocchi wrote:
>
>
>>> If FSM work bad for flow, why would they work any better for workflow?
>>
>>
>> After thinking again about ways to use continuations with workflow I
>> came to the conclusion this might well be possible. But it looks awkward
>> to me.
>>
>> Each document attached to workflow would need a workflow instance as
>> long as the document lives (from creation to deletion). This would mean
>> the continuation stack of every document needs to be persisted to - well
>> - to a database if you don't want to limit your clustering options. The
>> document has a property holding the continuation ID.
>
>
> You have a point here, Guido. It is true that continuations in a
> distributed environment would need to be made custer-friendly and
> replicated. This would probably impact the overall performance... but
> keep in mind that continuations are just another way to save state. That
> kind of state transformation (think REST) will have to be done anyway.
>
>> Requests for putting a document into another state now simply means (how
>> simple that really is I have no idea as I'm not familiar with the
>> details of Rhino or continuations) getting the continuation stack
>> belonging to the document's continuation ID from the database and resume
>> processing.
>>
>> Besides the hassle to maintain the continuation stacks in a database
>> there is another drawback IMHO.
>>
>> Now that I'm able to describe my workflow in a Javascript, how might
>> that script look like?
>
>
> Yes, I've been thinking about this myself too. No matter what, I'm
> always scared by the complexity that FSM normally reach, especially if
> they are maintained by more people overtime.
>
>> No matter how hard I think about it, it seems I'm unable to come up with
>> a piece of code that looks simpler than what I have without
>> continuations.
>
>
> Interesting. would you like to share that with us? I think it would be
> avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of a
UML diagramm or a XML file. I remember there have been thoughts about
generating flowscript out of a XML file describing my page flow logic,
but I doubt that will ever happen. I can't grasp what that would give me
(now that I have flowscript available :-). My impression has always been
that one major point of flow is to get away from believing that such
conditional logic might be better expressed within a XML file instead of
a piece of code (that sounds like a good sentence to start a pro/vs. MDA
discussion, doesn't it? :-).
I don't know much about FSM engineering. What I did was employing the
GOF state pattern. It's simple and it satisfies my needs. Each state is
represented by a dedicated State object. Each State object knows what
other States it wants to allow transitioning to and knows the
conditions. What I currently have in mind is a simple configuration that
goes like this:
<workflow-manager>
<state name="tobeprocessed" class="TobeprocessedState">
<entering-action class="TobeprocessedAction"/>
</state>
<state name="beingprocessed" class="BeingprocessedState">
<entering-action class="BeingprocessedAction"/>
<leaving-action class="LeaveBeingprocessedAction"/>
</state>
<state name="tobereviewed" class="ToreviewedState">
<entering-action class="TobecheckedAction"/>
</state>
...
</workflow-manager>
The respective "entering-action" knows how to transfer the object into
that state. "leaving-action" optionally does some cleanup (such as
checking in a document that has being checked out when entering
"beingprocessed").
The major drawback currently is that my AbstractState has to know about
all the other states (to prevent each State class having to know about
all the other states) and (when adding NewState) has to be updated with:
allowEnterNewState(doc, user) {return false;}
I have the gut felling that this may be solved with some piece of AOP
but I don't know enough about AOP and I currently don't care enough as
this already satifisfies my needs.
Of course any State object allowing transitioning to NewState has to be
updated with the corresponding conditional logic (overriding
allowEnterNewState). Each state has to know about other states it allows
transitioning to and the conditional logic (if any) to do so.
This seems to me like the most simple and maintainable solution for this
kind of workflow (at least for my simple needs).
Maybe I'm just not getting what OSWorkflow is about but I somehow feel
confirmed by Johan stating OSWorkflow being too complex and too limited
at the same time. So I rather stay with (really simple) Java code.
>
>> Continuations within a webapps are better than a FSMs because the FSM
>> approach is just a workaround for the lack of a single-threaded view of
>> my webapp and continuations brought back that view to me. However for
>> potentially everlasting conditional (and rather detached) workflow
>> state transistions FSMs do not look like a workaround to me but like
>> the (or one) solution.
>
>
> I still don't see that, but, admittedly, my experience with complex
> workflows is limited. But I think it would be a great exercise, as I
> said, to try to describe a natural situation in both ways and see which
> one is easier to grasp or feels more natural to people.
>
>> Page flow control mostly is rather small pieces of potentially complex
>> conditional logic with few branches (the user "is passively guided"
>> through the page flow) while workflow logic looks like an everlasting
>> loop of simple conditional logic with potentially lots of branches
>> (the user "actively triggers" the workflow).
>
>
> I really don't think you can draw a line that easily, but I do see your
> point.
>
> I think it's better to work on a few example of what this might look
> like in the two scenarios (FSM or javascript+continuations) and see what
> happens. WDYT?
I dont't know if my approach qualifies as a FSM (and it certainly is
improvable) but (FWIW) creating a NewState object is as simple as having
maybe 3 methods:
allowEnterTobereviewedState(doc, user) {return true;}
allowEnterReleasedState(doc, user) {
return User.ROLE_EDITOR.equals(user.getRole());
}
allowEnterArchivedState(doc, user) {
return user.getUsername.equals(doc.getlastAuthor());
}
and that's already a complex one :-)
As I said I (currently) have no interest in putting all the workflow
logic into a XML file, although I feel such a class (or an equivalent
construct) may even be generated out of a XML file in some dynamic
AOPish way, but I dont know.
In addition you would have to create an NewStateAction which in most
cases would be simple as well (depends on what you want NewState to mean
and the action to do).
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Unico Hommes <un...@hippo.nl>.
Stefano Mazzocchi wrote:
> Guido Casper wrote:
>
>> Stefano Mazzocchi wrote:
>
>
>>> If FSM work bad for flow, why would they work any better for workflow?
>>
>>
>> After thinking again about ways to use continuations with workflow I
>> came to the conclusion this might well be possible. But it looks awkward
>> to me.
>>
>> Each document attached to workflow would need a workflow instance as
>> long as the document lives (from creation to deletion). This would mean
>> the continuation stack of every document needs to be persisted to - well
>> - to a database if you don't want to limit your clustering options. The
>> document has a property holding the continuation ID.
>
>
> You have a point here, Guido. It is true that continuations in a
> distributed environment would need to be made custer-friendly and
> replicated. This would probably impact the overall performance... but
> keep in mind that continuations are just another way to save state. That
> kind of state transformation (think REST) will have to be done anyway.
>
>> Requests for putting a document into another state now simply means (how
>> simple that really is I have no idea as I'm not familiar with the
>> details of Rhino or continuations) getting the continuation stack
>> belonging to the document's continuation ID from the database and resume
>> processing.
>>
>> Besides the hassle to maintain the continuation stacks in a database
>> there is another drawback IMHO.
>>
>> Now that I'm able to describe my workflow in a Javascript, how might
>> that script look like?
>
>
> Yes, I've been thinking about this myself too. No matter what, I'm
> always scared by the complexity that FSM normally reach, especially if
> they are maintained by more people overtime.
>
>> No matter how hard I think about it, it seems I'm unable to come up with
>> a piece of code that looks simpler than what I have without
>> continuations.
>
>
> Interesting. would you like to share that with us? I think it would be
> avery good exercise to see the two approaches one beside the other.
>
>> Continuations within a webapps are better than a FSMs because the FSM
>> approach is just a workaround for the lack of a single-threaded view of
>> my webapp and continuations brought back that view to me. However for
>> potentially everlasting conditional (and rather detached) workflow
>> state transistions FSMs do not look like a workaround to me but like
>> the (or one) solution.
>
>
> I still don't see that, but, admittedly, my experience with complex
> workflows is limited. But I think it would be a great exercise, as I
> said, to try to describe a natural situation in both ways and see which
> one is easier to grasp or feels more natural to people.
>
>> Page flow control mostly is rather small pieces of potentially complex
>> conditional logic with few branches (the user "is passively guided"
>> through the page flow) while workflow logic looks like an everlasting
>> loop of simple conditional logic with potentially lots of branches
>> (the user "actively triggers" the workflow).
>
>
> I really don't think you can draw a line that easily, but I do see your
> point.
>
> I think it's better to work on a few example of what this might look
> like in the two scenarios (FSM or javascript+continuations) and see what
> happens. WDYT?
>
I used to think that flow would be ideal for the purpose of workflow but
I am currently not so sure.
If you look at the functionality of tools like OSWorkflow it is almost
exclusively constrained to being an FSM. In fact Lenya workflow is just
that, OSWorkflow also has the notion of pre- and post functions mixed in
there but its main concepts translate exactly to the elements of an FSM:
states, transistions, and conditions.
Looking at it that way it seems there are only things to gain from using
precedural continuations instead. Swapping in an awkward looking and
hard to read XML idiom for a more familiar procedural syntax.
I think one of the reasons workflow tools often implemented as a
declarative language is because people tend to think of it in terms of a
static model of organisation structure. Both workflow examples on this
thread were expressed with the help of an FSM-like diagram. Procedures
are always just secundary entities.
The main drawback I see of using javascript for workflow definitions is
that it is too powerful as an expression language. It lacks framework.
It lacks the ability to constrain the task of writing a workflow to the
domain of workflow.
--
Unico
Re: Experience with workflow at Hippo Webworks
Posted by Stefano Mazzocchi <st...@apache.org>.
Guido Casper wrote:
> Stefano Mazzocchi wrote:
>> If FSM work bad for flow, why would they work any better for workflow?
>
> After thinking again about ways to use continuations with workflow I
> came to the conclusion this might well be possible. But it looks awkward
> to me.
>
> Each document attached to workflow would need a workflow instance as
> long as the document lives (from creation to deletion). This would mean
> the continuation stack of every document needs to be persisted to - well
> - to a database if you don't want to limit your clustering options. The
> document has a property holding the continuation ID.
You have a point here, Guido. It is true that continuations in a
distributed environment would need to be made custer-friendly and
replicated. This would probably impact the overall performance... but
keep in mind that continuations are just another way to save state. That
kind of state transformation (think REST) will have to be done anyway.
> Requests for putting a document into another state now simply means (how
> simple that really is I have no idea as I'm not familiar with the
> details of Rhino or continuations) getting the continuation stack
> belonging to the document's continuation ID from the database and resume
> processing.
>
> Besides the hassle to maintain the continuation stacks in a database
> there is another drawback IMHO.
>
> Now that I'm able to describe my workflow in a Javascript, how might
> that script look like?
Yes, I've been thinking about this myself too. No matter what, I'm
always scared by the complexity that FSM normally reach, especially if
they are maintained by more people overtime.
> No matter how hard I think about it, it seems I'm unable to come up with
> a piece of code that looks simpler than what I have without continuations.
Interesting. would you like to share that with us? I think it would be
avery good exercise to see the two approaches one beside the other.
> Continuations within a webapps are better than a FSMs because the FSM
> approach is just a workaround for the lack of a single-threaded view of
> my webapp and continuations brought back that view to me. However for
> potentially everlasting conditional (and rather detached) workflow state
> transistions FSMs do not look like a workaround to me but like the (or
> one) solution.
I still don't see that, but, admittedly, my experience with complex
workflows is limited. But I think it would be a great exercise, as I
said, to try to describe a natural situation in both ways and see which
one is easier to grasp or feels more natural to people.
> Page flow control mostly is rather small pieces of potentially complex
> conditional logic with few branches (the user "is passively guided"
> through the page flow) while workflow logic looks like an everlasting
> loop of simple conditional logic with potentially lots of branches (the
> user "actively triggers" the workflow).
I really don't think you can draw a line that easily, but I do see your
point.
I think it's better to work on a few example of what this might look
like in the two scenarios (FSM or javascript+continuations) and see what
happens. WDYT?
--
Stefano.
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi wrote:
> Johan Stuyts wrote:
>
>> Experience with workflow at Hippo Webworks
>> ==========================================
>>
>> At Hippo we used OSWorkflow to implement a workflow solution in a
>> demo. Below are our experiences.
>>
>> As people with different levels of experience are interested in
>> workflow I will start with a (very) brief introduction to workflow.
>>
>> Workflow introduction
>> ---------------------
>> Very simply put workflow serves two purposes:
>> - to determine who can do what at which time with an object;
>> - to generate a list of pending tasks for users.
>>
>> An example of the first is that an editor (who) can only publish (do
>> what) a document (an object) after a writer has asked for a review (at
>> which time).
>>
>> The lists of documents to be reviewed is an example of a pending task
>> list for an editor.
>>
>> Each object type can have its own specific workflow.
>>
>> The demo workflow
>> -----------------
>> The demo we created has a workflow for a basic document type, a web
>> page. I have attached a diagram of it.
>>
>> A document gets created by a writer. The writer is not allowed to
>> publish his document directly, he has to ask the editor for review.
>>
>> The editor can easily review documents because we generate a list of
>> documents waiting for review. The editor can click on the document and
>> can either approve or disapprove. If the document gets approved it is
>> published on the public server.
>>
>> If the document gets disapproved the writer can not ask for a review
>> without editing it first. Editing the document when it has been
>> approved will bring the document back to the editing state too. After
>> making his changes the user can ask for a review of the new version.
>>
>> Implementation
>> --------------
>> For the document repository we use Slide. For the workflow engine we
>> used OSWorkflow. We connected these two using Slide interceptors.
>
>
> wow, supercool!! I want it :-)
>
>> When a document is created the interceptor checks to see whether a
>> workflow already exists. It does this by retrieving the workflow ID
>> from a WebDAV property of the document. If it doesn't exist a new
>> workflow is created in the workflow store.
>
>
> Interesting terminology you use here: let me ask you this before we get
> confused: "workflow" is for you an instance of the model or the model
> itself?
>
>> When our frontend retrieves the tree of documents, the interceptor
>> will retrieve the workflow for each document.
>
>
> Seems to be the instance. Ok, careful though, because normally people
> refer to workflow as the "model", not the instance.
>
>> Looking at the role of the user the interceptor will determine which
>> actions are enabled. The enabled actions (including their display text
>> and activation URLs) are set in a WebDAV property of the document.
>>
>> For the generation of the pending task list we used the OSWorkflow
>> query API to generate the documents which are in the
>> waiting-for-review state. The approve and disapprove actions are
>> passed to the frontend in the same way as the commands for a writer.
>>
>> Not all actions are directly shown in the menu, because the user
>> invokes them implicitly. The edit action for example is invoked by the
>> interceptor each time the user saves the document.
>>
>> Issues
>> ------
>> We encountered issues with both slides and OSWorkflow during the
>> implementation.
>>
>> Before we used Slide, we used the Cocoon repository. The semantics of
>> the repository interceptors and the Slide interceptors is not the
>> same. With the repository interceptor we were able to add a property
>> to the document in postStoreContent(...). In Slide we had to do this
>> in preStoreContent(...).
>
>
> IMHO, makes more sense to add metadata in pre-saving than in
> post-saving. It's way more efficient for clustered environments.
>
>> Apart from that the Slide interceptors work very well, but (in the
>> version of Slide we used) they get called a lot. A single store of a
>> document invoked preStoreContent(...) and postStoreContent(...)
>> multiple times.
>
>
> well, this is a bug then. there should be a way to connect to an atomic
> event for a content store... you might want to bring this up on slide-dev
>
>> OSWorkflow performed great too. The only disadvantage was the
>> complexity of state machines that can be expressed. As you can see in
>> the attached diagram nested states are used. OSWorkflow does not
>> support these.
>
>
> The more I hear about workflows, the more I think that writing them with
> flow and continuations makes more sense than writing a finite state
> machine.
>
>> Although the attached workflow does not contain parallel states, we
>> think it might be needed for some document types. A newsletter for
>> example follows the same workflow as the attached one. But parallel to
>> this is a mailing workflow for sending it to the newsletter subscribers.
>>
>> In the mailing workflow the user can send a test email of the current
>> version to himself. When he is satisfied he can send the final version
>> to the newsletter subscribers. After this, he can neither send a test
>> email nor send it to the subscribers.
>>
>> But what to do if a mistake in the newsletter is found after sending
>> it to the subscribers? The subscribers won't be happy to receive
>> another copy, so the mailing actions should stay blocked. But not
>> correcting the newsletter on the website looks sloppy. Therefore the
>> editing/reviewing/publishing workflow has to remain active.
>
>
> this screams for long-lasting continuations!
>
>> Workflow requirements
>> ---------------------
>> Building an effective and solid workflow solution requires two
>> preconditions. Both are outside the scope of the workflow framework:
>> - understandable role assignment (from a user's perspective) and
>> simple role retrieval;
>> - typed document repository. This is necessary to enable different
>> document types having different workflows attached to them.
>
>
> granted.
>
>> When these two preconditions are met, the workflow framework must meet
>> the following basic requirements:
>> - the ability to specify under what conditions an action can be
>> invoked. Authorization is considered a specific type of condition;
>
>
> I think you mean "authentication" not "authorization".
>
>> - the ability to retrieve the actions which can be invoked by a
>> particalur user at this moment;
>
>
> yes
>
>> - the ability to query the workflow store for objects which are in a
>> specific state and are relevant to the current user.
>
>
> I don't think the workflow engine should have anything to do with the
> objects. As for basic SoC, the workflow engine should be a separate
> entity, a rule engine.
>
>> The requirements on the main function of a workflow framework,
>> state-machine evaluation, depend on the complexity of the use cases
>> which need to be implemented.
>>
>> Although we implemented the workflow in our demo using OSWorkflow we
>> were not completely satisfied. Some actions, edit and delete for
>> example, should be available in more than one state. We had to promote
>> these actions to global actions, and add conditions to these actions
>> to check whether the workflow is in a valid state. Because of this
>> creative coding the logic of the workflow moved out of its context and
>> difficult to read from the workflow configuration.
>>
>> In our opinion a workflow framework supporting almost all constucts
>> from UML state machines is needed to be able to build powerful, and
>> still easy-to-understand solutions.
>
>
> It would be killer to have a UML drawing tool that would generate
> javascript with continuations!
>
>> Where to go next
>> ----------------
>> Our next goals are to make sure the two preconditions are met.
>> Concurrently we will be creating workflow use-cases to determine how
>> complex state machines need to be to implement these use cases.
>>
>> We are very interested in hearing about use cases and
>> workflow-framework experiences from other people. We will update the
>> existing page about workflow on the Cocoon Wiki
>> (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow) with our experiences.
>
>
> I have no direct personal experience but I've been thinking about flow
> and workflow a lot and I think the only difference is that flow is acted
> by the same person while workflow is acted by more than one person.
>
> If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Each document attached to workflow would need a workflow instance as
long as the document lives (from creation to deletion). This would mean
the continuation stack of every document needs to be persisted to - well
- to a database if you don't want to limit your clustering options. The
document has a property holding the continuation ID.
Requests for putting a document into another state now simply means (how
simple that really is I have no idea as I'm not familiar with the
details of Rhino or continuations) getting the continuation stack
belonging to the document's continuation ID from the database and resume
processing.
Besides the hassle to maintain the continuation stacks in a database
there is another drawback IMHO.
Now that I'm able to describe my workflow in a Javascript, how might
that script look like?
No matter how hard I think about it, it seems I'm unable to come up with
a piece of code that looks simpler than what I have without continuations.
Continuations within a webapps are better than a FSMs because the FSM
approach is just a workaround for the lack of a single-threaded view of
my webapp and continuations brought back that view to me. However for
potentially everlasting conditional (and rather detached) workflow state
transistions FSMs do not look like a workaround to me but like the (or
one) solution.
Page flow control mostly is rather small pieces of potentially complex
conditional logic with few branches (the user "is passively guided"
through the page flow) while workflow logic looks like an everlasting
loop of simple conditional logic with potentially lots of branches (the
user "actively triggers" the workflow).
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Johan Stuyts <jo...@hippo.nl>.
On Mon, 08 Mar 2004 19:58:32 +0100, Guido Casper <gc...@s-und-n.de>
wrote:
> Johan Stuyts wrote:
>> Using the GoF State pattern works great for simple state machines and I
>> use it a lot. But the pattern does not talk about nested and/or
>> parallel states, which become incomprehensible when coded in Java; the
>> state machine logic gets intermixed with the document logic.
>
> Johan, can you give me an example of parallel states?
> I currently can't even imagine what that might look like on a drawing
> (hope my business user can ;-) Also I'm not convinced about the need for
> nested states, although I could think of ways the state pattern might
> account for that (a state object might use the state pattern itself).
> What would be a possible alternative implementation?
>
The example I gave about newsletters is an example about parallel states.
See the attached diagram. You have the usual edit/review/publish cycle for
the web part of the document. And in addition you have a test/send cycle
for the email part. The email part prevents the sending of the newsletter
twice.
The two parts are completely parallel and the total number of possible
states of an object is the Cartesian product of all the parallel parts of
its state machine. For this example (using four states for the
edit/review/publish part) that results in eight possible states.
> As for the newsletter problem I'll have to solve that one as well :-)
> But I can think of ways to solve that without introducing a whole bunch
> of new concepts or terminology just to solve that single use case. If
> you tell me I'm mixing concerns that may be true. I'm fine with mixing
> concerns and bending the framework a little for complex cases if it's
> still easy to grasp.
> But if the technology doesn't allow me to solve simple problems easily
> (there might be people claiming the same to be true for Cocoon (in case
> not being familiar with it) and I think this may be a reason Cocoon not
> being adopted _much_ wider. I don't mean that as a criticism in any way
> (it would be one to myself), it's just a fact, AFAICS), I loose interest.
>
> If somebody comes up with a full featured workflow engine still simple
> to use from Cocoon for simple use cases, I would immediately use that.
>
A state machine implementation must ofcourse be comprehensible for simple
state machines too. To achieve this the implementation must have the
following properties:
- easy overview of the whole state machine; you don't have to locate
multiple files, or have to jump up and down in a file to understand how
things are related;
- be terse; details (with defaults) which are not relevant should not be
shown.
I think it is possible to have both these properties.
> Guido
>
--
Johan Stuyts
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Johan Stuyts wrote:
> Using the GoF State pattern works
> great for simple state machines and I use it a lot. But the pattern does
> not talk about nested and/or parallel states, which become
> incomprehensible when coded in Java; the state machine logic gets
> intermixed with the document logic.
Johan, can you give me an example of parallel states?
I currently can't even imagine what that might look like on a drawing
(hope my business user can ;-) Also I'm not convinced about the need for
nested states, although I could think of ways the state pattern might
account for that (a state object might use the state pattern itself).
What would be a possible alternative implementation?
As for the newsletter problem I'll have to solve that one as well :-)
But I can think of ways to solve that without introducing a whole bunch
of new concepts or terminology just to solve that single use case. If
you tell me I'm mixing concerns that may be true. I'm fine with mixing
concerns and bending the framework a little for complex cases if it's
still easy to grasp.
But if the technology doesn't allow me to solve simple problems easily
(there might be people claiming the same to be true for Cocoon (in case
not being familiar with it) and I think this may be a reason Cocoon not
being adopted _much_ wider. I don't mean that as a criticism in any way
(it would be one to myself), it's just a fact, AFAICS), I loose interest.
If somebody comes up with a full featured workflow engine still simple
to use from Cocoon for simple use cases, I would immediately use that.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Johan Stuyts <jo...@hippo.nl>.
On Mon, 08 Mar 2004 11:41:12 +0100, Unico Hommes <un...@hippo.nl> wrote:
> Johan Stuyts wrote:
>
>> On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
>> <st...@apache.org> wrote:
>>
>>> Johan Stuyts wrote:
>>>
>>>> Experience with workflow at Hippo Webworks
>>>> ==========================================
>>>>
>>>> At Hippo we used OSWorkflow to implement a workflow solution in a
>>>> demo.
>>>> Below are our experiences.
>>>>
>>>> As people with different levels of experience are interested in
>>>> workflow
>>>> I will start with a (very) brief introduction to workflow.
>>>>
>>>> Workflow introduction
>>>> ---------------------
>>>> Very simply put workflow serves two purposes:
>>>> - to determine who can do what at which time with an object;
>>>> - to generate a list of pending tasks for users.
>>>>
>>>> An example of the first is that an editor (who) can only publish (do
>>>> what) a document (an object) after a writer has asked for a review (at
>>>> which time).
>>>>
>>>> The lists of documents to be reviewed is an example of a pending task
>>>> list for an editor.
>>>>
>>>> Each object type can have its own specific workflow.
>>>>
>>>> The demo workflow
>>>> -----------------
>>>> The demo we created has a workflow for a basic document type, a web
>>>> page. I have attached a diagram of it.
>>>>
>>>> A document gets created by a writer. The writer is not allowed to
>>>> publish his document directly, he has to ask the editor for review.
>>>>
>>>> The editor can easily review documents because we generate a list of
>>>> documents waiting for review. The editor can click on the document and
>>>> can either approve or disapprove. If the document gets approved it is
>>>> published on the public server.
>>>>
>>>> If the document gets disapproved the writer can not ask for a review
>>>> without editing it first. Editing the document when it has been
>>>> approved
>>>> will bring the document back to the editing state too. After making
>>>> his
>>>> changes the user can ask for a review of the new version.
>>>>
>>>> Implementation
>>>> --------------
>>>> For the document repository we use Slide. For the workflow engine we
>>>> used OSWorkflow. We connected these two using Slide interceptors.
>>>
>>>
>>> wow, supercool!! I want it :-)
>>>
>>>> When a document is created the interceptor checks to see whether a
>>>> workflow already exists. It does this by retrieving the workflow ID
>>>> from
>>>> a WebDAV property of the document. If it doesn't exist a new workflow
>>>> is
>>>> created in the workflow store.
>>>
>>>
>>> Interesting terminology you use here: let me ask you this before we get
>>> confused: "workflow" is for you an instance of the model or the model
>>> itself?
>>
>>
>> I use the same term for both the model and the instance :">
>>
>>>
>>>> When our frontend retrieves the tree of documents, the interceptor
>>>> will
>>>> retrieve the workflow for each document.
>>>
>>>
>>> Seems to be the instance. Ok, careful though, because normally people
>>> refer to workflow as the "model", not the instance.
>>
>>
>> I will be more explicit in further messages.
>>
>>>
>>>> Looking at the role of the user
>>>> the interceptor will determine which actions are enabled. The enabled
>>>> actions (including their display text and activation URLs) are set in
>>>> a
>>>> WebDAV property of the document.
>>>>
>>>> For the generation of the pending task list we used the OSWorkflow
>>>> query
>>>> API to generate the documents which are in the waiting-for-review
>>>> state.
>>>> The approve and disapprove actions are passed to the frontend in the
>>>> same way as the commands for a writer.
>>>>
>>>> Not all actions are directly shown in the menu, because the user
>>>> invokes
>>>> them implicitly. The edit action for example is invoked by the
>>>> interceptor each time the user saves the document.
>>>>
>>>> Issues
>>>> ------
>>>> We encountered issues with both slides and OSWorkflow during the
>>>> implementation.
>>>>
>>>> Before we used Slide, we used the Cocoon repository. The semantics of
>>>> the repository interceptors and the Slide interceptors is not the
>>>> same.
>>>> With the repository interceptor we were able to add a property to the
>>>> document in postStoreContent(...). In Slide we had to do this in
>>>> preStoreContent(...).
>>>
>>>
>>> IMHO, makes more sense to add metadata in pre-saving than in
>>> post-saving. It's way more efficient for clustered environments.
>>
>>
>> I dont't care what's better. I just thought that two technologies used
>> heavily in Cocoon having different semantics for the same concept was
>> confusing.
>>
> Well I care. The interception mechanism in the repository was crafted
> after Slide's. If there are diverging semantics or you need extra
> functionality it can be fixed quite easily.
>
>>>
>>>> Apart from that the Slide interceptors work very well, but (in the
>>>> version of Slide we used) they get called a lot. A single store of a
>>>> document invoked preStoreContent(...) and postStoreContent(...)
>>>> multiple
>>>> times.
>>>
>>>
>>> well, this is a bug then. there should be a way to connect to an atomic
>>> event for a content store... you might want to bring this up on
>>> slide-dev
>>
>>
>> OK. I will look into this (making sure we don't add the same
>> interceptor multiple times).
>>
> Interception in Slide is quite low level. For instance, when verioning
> is turned on one WebDAV PUT will typically result in 2n pre- and 2n post
> store operations calls where n is the number of versions the resource
> will have after transaction commit. (I even suspect the factor 2 in that
> is actually the number of stores configured for the scope the resource
> is in but I'd have to check that). Anyway, I think that the interception
> model has been superceeded by Daniel Florey's recent work on event in
> Slide but I still have to look into that too.
>
>>>
>>>> OSWorkflow performed great too. The only disadvantage was the
>>>> complexity
>>>> of state machines that can be expressed. As you can see in the
>>>> attached
>>>> diagram nested states are used. OSWorkflow does not support these.
>>>
>>>
>>> The more I hear about workflows, the more I think that writing them
>>> with
>>> flow and continuations makes more sense than writing a finite state
>>> machine.
>>
>>
>> I don't like procedural code to handle complex state. You wind up with
>> a lot of if-statements and it is difficult to determine what happens
>> when a particular action gets invoked. A state machine has a lot of
>> context: I am in state X, so all operations on this state and its
>> parent states are valid. A state machine also hides a lot of
>> implementation details. No need to check what the value of the
>> current-state variable is.
>>
> Continuations do that even better. There isn't even an explicit notion
> of state at all. I don't want to rule out procedural code for handling
> conditional logic in workflow yet. I think the State pattern Guido
> described very effectively solves the nested case complexity. I am very
> interested in pursuing this more.
>
I am more interested in how easy it is to read an implemented state
machine. Of course it is possible to implement a workflow using
continuations, but how easy can I visualize this and use this to discuss
it with customers? Keeping a diagram up-to-date each time some JavaScript
and/or Java changes is cumbersome.
If you put a state machine in an XML document using a well-defined schema,
it should be easy to understand and have a complete overview during the
definition of the state machine (I see a state machine as a single concern
as I posted before). And it is easy, if you are a diagram-layout expert
;), to generate an up-to-date diagram.
>>>
>>>> Although the attached workflow does not contain parallel states, we
>>>> think it might be needed for some document types. A newsletter for
>>>> example follows the same workflow as the attached one. But parallel to
>>>> this is a mailing workflow for sending it to the newsletter
>>>> subscribers.
>>>>
>>>> In the mailing workflow the user can send a test email of the current
>>>> version to himself. When he is satisfied he can send the final version
>>>> to the newsletter subscribers. After this, he can neither send a test
>>>> email nor send it to the subscribers.
>>>>
>>>> But what to do if a mistake in the newsletter is found after sending
>>>> it
>>>> to the subscribers? The subscribers won't be happy to receive another
>>>> copy, so the mailing actions should stay blocked. But not correcting
>>>> the
>>>> newsletter on the website looks sloppy. Therefore the
>>>> editing/reviewing/publishing workflow has to remain active.
>>>
>>>
>>> this screams for long-lasting continuations!
>>
>>
>> How would you handle parallel states using continuations? If you want a
>> unique continuation point for each possible combination of states, the
>> number of continuations points will explode.
>
>
> Won't there always be one continuation per workflow instance? That's
> constant no?
If you do this you will have to keep a state variable (to a Java object)
because you return to the same point. Using the GoF State pattern works
great for simple state machines and I use it a lot. But the pattern does
not talk about nested and/or parallel states, which become
incomprehensible when coded in Java; the state machine logic gets
intermixed with the document logic.
>
> --
> Unico
>
--
Johan Stuyts
Re: Experience with workflow at Hippo Webworks
Posted by Unico Hommes <un...@hippo.nl>.
Johan Stuyts wrote:
> On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
> <st...@apache.org> wrote:
>
>> Johan Stuyts wrote:
>>
>>> Experience with workflow at Hippo Webworks
>>> ==========================================
>>>
>>> At Hippo we used OSWorkflow to implement a workflow solution in a demo.
>>> Below are our experiences.
>>>
>>> As people with different levels of experience are interested in
>>> workflow
>>> I will start with a (very) brief introduction to workflow.
>>>
>>> Workflow introduction
>>> ---------------------
>>> Very simply put workflow serves two purposes:
>>> - to determine who can do what at which time with an object;
>>> - to generate a list of pending tasks for users.
>>>
>>> An example of the first is that an editor (who) can only publish (do
>>> what) a document (an object) after a writer has asked for a review (at
>>> which time).
>>>
>>> The lists of documents to be reviewed is an example of a pending task
>>> list for an editor.
>>>
>>> Each object type can have its own specific workflow.
>>>
>>> The demo workflow
>>> -----------------
>>> The demo we created has a workflow for a basic document type, a web
>>> page. I have attached a diagram of it.
>>>
>>> A document gets created by a writer. The writer is not allowed to
>>> publish his document directly, he has to ask the editor for review.
>>>
>>> The editor can easily review documents because we generate a list of
>>> documents waiting for review. The editor can click on the document and
>>> can either approve or disapprove. If the document gets approved it is
>>> published on the public server.
>>>
>>> If the document gets disapproved the writer can not ask for a review
>>> without editing it first. Editing the document when it has been
>>> approved
>>> will bring the document back to the editing state too. After making his
>>> changes the user can ask for a review of the new version.
>>>
>>> Implementation
>>> --------------
>>> For the document repository we use Slide. For the workflow engine we
>>> used OSWorkflow. We connected these two using Slide interceptors.
>>
>>
>> wow, supercool!! I want it :-)
>>
>>> When a document is created the interceptor checks to see whether a
>>> workflow already exists. It does this by retrieving the workflow ID
>>> from
>>> a WebDAV property of the document. If it doesn't exist a new
>>> workflow is
>>> created in the workflow store.
>>
>>
>> Interesting terminology you use here: let me ask you this before we get
>> confused: "workflow" is for you an instance of the model or the model
>> itself?
>
>
> I use the same term for both the model and the instance :">
>
>>
>>> When our frontend retrieves the tree of documents, the interceptor will
>>> retrieve the workflow for each document.
>>
>>
>> Seems to be the instance. Ok, careful though, because normally people
>> refer to workflow as the "model", not the instance.
>
>
> I will be more explicit in further messages.
>
>>
>>> Looking at the role of the user
>>> the interceptor will determine which actions are enabled. The enabled
>>> actions (including their display text and activation URLs) are set in a
>>> WebDAV property of the document.
>>>
>>> For the generation of the pending task list we used the OSWorkflow
>>> query
>>> API to generate the documents which are in the waiting-for-review
>>> state.
>>> The approve and disapprove actions are passed to the frontend in the
>>> same way as the commands for a writer.
>>>
>>> Not all actions are directly shown in the menu, because the user
>>> invokes
>>> them implicitly. The edit action for example is invoked by the
>>> interceptor each time the user saves the document.
>>>
>>> Issues
>>> ------
>>> We encountered issues with both slides and OSWorkflow during the
>>> implementation.
>>>
>>> Before we used Slide, we used the Cocoon repository. The semantics of
>>> the repository interceptors and the Slide interceptors is not the same.
>>> With the repository interceptor we were able to add a property to the
>>> document in postStoreContent(...). In Slide we had to do this in
>>> preStoreContent(...).
>>
>>
>> IMHO, makes more sense to add metadata in pre-saving than in
>> post-saving. It's way more efficient for clustered environments.
>
>
> I dont't care what's better. I just thought that two technologies used
> heavily in Cocoon having different semantics for the same concept was
> confusing.
>
Well I care. The interception mechanism in the repository was crafted
after Slide's. If there are diverging semantics or you need extra
functionality it can be fixed quite easily.
>>
>>> Apart from that the Slide interceptors work very well, but (in the
>>> version of Slide we used) they get called a lot. A single store of a
>>> document invoked preStoreContent(...) and postStoreContent(...)
>>> multiple
>>> times.
>>
>>
>> well, this is a bug then. there should be a way to connect to an atomic
>> event for a content store... you might want to bring this up on
>> slide-dev
>
>
> OK. I will look into this (making sure we don't add the same
> interceptor multiple times).
>
Interception in Slide is quite low level. For instance, when verioning
is turned on one WebDAV PUT will typically result in 2n pre- and 2n post
store operations calls where n is the number of versions the resource
will have after transaction commit. (I even suspect the factor 2 in that
is actually the number of stores configured for the scope the resource
is in but I'd have to check that). Anyway, I think that the interception
model has been superceeded by Daniel Florey's recent work on event in
Slide but I still have to look into that too.
>>
>>> OSWorkflow performed great too. The only disadvantage was the
>>> complexity
>>> of state machines that can be expressed. As you can see in the attached
>>> diagram nested states are used. OSWorkflow does not support these.
>>
>>
>> The more I hear about workflows, the more I think that writing them with
>> flow and continuations makes more sense than writing a finite state
>> machine.
>
>
> I don't like procedural code to handle complex state. You wind up with
> a lot of if-statements and it is difficult to determine what happens
> when a particular action gets invoked. A state machine has a lot of
> context: I am in state X, so all operations on this state and its
> parent states are valid. A state machine also hides a lot of
> implementation details. No need to check what the value of the
> current-state variable is.
>
Continuations do that even better. There isn't even an explicit notion
of state at all. I don't want to rule out procedural code for handling
conditional logic in workflow yet. I think the State pattern Guido
described very effectively solves the nested case complexity. I am very
interested in pursuing this more.
>>
>>> Although the attached workflow does not contain parallel states, we
>>> think it might be needed for some document types. A newsletter for
>>> example follows the same workflow as the attached one. But parallel to
>>> this is a mailing workflow for sending it to the newsletter
>>> subscribers.
>>>
>>> In the mailing workflow the user can send a test email of the current
>>> version to himself. When he is satisfied he can send the final version
>>> to the newsletter subscribers. After this, he can neither send a test
>>> email nor send it to the subscribers.
>>>
>>> But what to do if a mistake in the newsletter is found after sending it
>>> to the subscribers? The subscribers won't be happy to receive another
>>> copy, so the mailing actions should stay blocked. But not correcting
>>> the
>>> newsletter on the website looks sloppy. Therefore the
>>> editing/reviewing/publishing workflow has to remain active.
>>
>>
>> this screams for long-lasting continuations!
>
>
> How would you handle parallel states using continuations? If you want
> a unique continuation point for each possible combination of states,
> the number of continuations points will explode.
Won't there always be one continuation per workflow instance? That's
constant no?
--
Unico
Re: Experience with workflow at Hippo Webworks
Posted by Johan Stuyts <jo...@hippo.nl>.
On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi <st...@apache.org>
wrote:
> Johan Stuyts wrote:
>
>> Experience with workflow at Hippo Webworks
>> ==========================================
>>
>> At Hippo we used OSWorkflow to implement a workflow solution in a demo.
>> Below are our experiences.
>>
>> As people with different levels of experience are interested in workflow
>> I will start with a (very) brief introduction to workflow.
>>
>> Workflow introduction
>> ---------------------
>> Very simply put workflow serves two purposes:
>> - to determine who can do what at which time with an object;
>> - to generate a list of pending tasks for users.
>>
>> An example of the first is that an editor (who) can only publish (do
>> what) a document (an object) after a writer has asked for a review (at
>> which time).
>>
>> The lists of documents to be reviewed is an example of a pending task
>> list for an editor.
>>
>> Each object type can have its own specific workflow.
>>
>> The demo workflow
>> -----------------
>> The demo we created has a workflow for a basic document type, a web
>> page. I have attached a diagram of it.
>>
>> A document gets created by a writer. The writer is not allowed to
>> publish his document directly, he has to ask the editor for review.
>>
>> The editor can easily review documents because we generate a list of
>> documents waiting for review. The editor can click on the document and
>> can either approve or disapprove. If the document gets approved it is
>> published on the public server.
>>
>> If the document gets disapproved the writer can not ask for a review
>> without editing it first. Editing the document when it has been approved
>> will bring the document back to the editing state too. After making his
>> changes the user can ask for a review of the new version.
>>
>> Implementation
>> --------------
>> For the document repository we use Slide. For the workflow engine we
>> used OSWorkflow. We connected these two using Slide interceptors.
>
> wow, supercool!! I want it :-)
>
>> When a document is created the interceptor checks to see whether a
>> workflow already exists. It does this by retrieving the workflow ID from
>> a WebDAV property of the document. If it doesn't exist a new workflow is
>> created in the workflow store.
>
> Interesting terminology you use here: let me ask you this before we get
> confused: "workflow" is for you an instance of the model or the model
> itself?
I use the same term for both the model and the instance :">
>
>> When our frontend retrieves the tree of documents, the interceptor will
>> retrieve the workflow for each document.
>
> Seems to be the instance. Ok, careful though, because normally people
> refer to workflow as the "model", not the instance.
I will be more explicit in further messages.
>
>> Looking at the role of the user
>> the interceptor will determine which actions are enabled. The enabled
>> actions (including their display text and activation URLs) are set in a
>> WebDAV property of the document.
>>
>> For the generation of the pending task list we used the OSWorkflow query
>> API to generate the documents which are in the waiting-for-review state.
>> The approve and disapprove actions are passed to the frontend in the
>> same way as the commands for a writer.
>>
>> Not all actions are directly shown in the menu, because the user invokes
>> them implicitly. The edit action for example is invoked by the
>> interceptor each time the user saves the document.
>>
>> Issues
>> ------
>> We encountered issues with both slides and OSWorkflow during the
>> implementation.
>>
>> Before we used Slide, we used the Cocoon repository. The semantics of
>> the repository interceptors and the Slide interceptors is not the same.
>> With the repository interceptor we were able to add a property to the
>> document in postStoreContent(...). In Slide we had to do this in
>> preStoreContent(...).
>
> IMHO, makes more sense to add metadata in pre-saving than in
> post-saving. It's way more efficient for clustered environments.
I dont't care what's better. I just thought that two technologies used
heavily in Cocoon having different semantics for the same concept was
confusing.
>
>> Apart from that the Slide interceptors work very well, but (in the
>> version of Slide we used) they get called a lot. A single store of a
>> document invoked preStoreContent(...) and postStoreContent(...) multiple
>> times.
>
> well, this is a bug then. there should be a way to connect to an atomic
> event for a content store... you might want to bring this up on slide-dev
OK. I will look into this (making sure we don't add the same interceptor
multiple times).
>
>> OSWorkflow performed great too. The only disadvantage was the complexity
>> of state machines that can be expressed. As you can see in the attached
>> diagram nested states are used. OSWorkflow does not support these.
>
> The more I hear about workflows, the more I think that writing them with
> flow and continuations makes more sense than writing a finite state
> machine.
I don't like procedural code to handle complex state. You wind up with a
lot of if-statements and it is difficult to determine what happens when a
particular action gets invoked. A state machine has a lot of context: I am
in state X, so all operations on this state and its parent states are
valid. A state machine also hides a lot of implementation details. No need
to check what the value of the current-state variable is.
>
>> Although the attached workflow does not contain parallel states, we
>> think it might be needed for some document types. A newsletter for
>> example follows the same workflow as the attached one. But parallel to
>> this is a mailing workflow for sending it to the newsletter subscribers.
>>
>> In the mailing workflow the user can send a test email of the current
>> version to himself. When he is satisfied he can send the final version
>> to the newsletter subscribers. After this, he can neither send a test
>> email nor send it to the subscribers.
>>
>> But what to do if a mistake in the newsletter is found after sending it
>> to the subscribers? The subscribers won't be happy to receive another
>> copy, so the mailing actions should stay blocked. But not correcting the
>> newsletter on the website looks sloppy. Therefore the
>> editing/reviewing/publishing workflow has to remain active.
>
> this screams for long-lasting continuations!
How would you handle parallel states using continuations? If you want a
unique continuation point for each possible combination of states, the
number of continuations points will explode.
>
>> Workflow requirements
>> ---------------------
>> Building an effective and solid workflow solution requires two
>> preconditions. Both are outside the scope of the workflow framework:
>> - understandable role assignment (from a user's perspective) and simple
>> role retrieval;
>> - typed document repository. This is necessary to enable different
>> document types having different workflows attached to them.
>
> granted.
>
>> When these two preconditions are met, the workflow framework must meet
>> the following basic requirements:
>> - the ability to specify under what conditions an action can be invoked.
>> Authorization is considered a specific type of condition;
>
> I think you mean "authentication" not "authorization".
No, I mean authorization. I assume the user is already authenticated. The
conditions for actions (can) check that a person is authorized to invoke
the action.
>
>> - the ability to retrieve the actions which can be invoked by a
>> particalur user at this moment;
>
> yes
>
>> - the ability to query the workflow store for objects which are in a
>> specific state and are relevant to the current user.
>
> I don't think the workflow engine should have anything to do with the
> objects. As for basic SoC, the workflow engine should be a separate
> entity, a rule engine.
The objects here are the workflow instances, but information from the
objects they are related to is also necessary during queries (for example
to check whether the person has a specific role for an object).
When you query the objects you combine information from two sources: the
repository and the workflow store. This can be done in a couple of ways:
- the workflow store has access to/contains information from the
repository (special functions plugged in to the workflow);
- the repository has access to/contains information from the worfklow
store (WebDAV properties which are set when a state change occurs);
- a facade with its own query interface.
>
>> The requirements on the main function of a workflow framework,
>> state-machine evaluation, depend on the complexity of the use cases
>> which need to be implemented.
>>
>> Although we implemented the workflow in our demo using OSWorkflow we
>> were not completely satisfied. Some actions, edit and delete for
>> example, should be available in more than one state. We had to promote
>> these actions to global actions, and add conditions to these actions to
>> check whether the workflow is in a valid state. Because of this creative
>> coding the logic of the workflow moved out of its context and difficult
>> to read from the workflow configuration.
>>
>> In our opinion a workflow framework supporting almost all constucts from
>> UML state machines is needed to be able to build powerful, and still
>> easy-to-understand solutions.
>
> It would be killer to have a UML drawing tool that would generate
> javascript with continuations!
Generating code would be great, but I think it is possible to have XML
documents which clearly describe complex state machines. Then no code
generation is needed, just a state-machine engine.
>
>> Where to go next
>> ----------------
>> Our next goals are to make sure the two preconditions are met.
>> Concurrently we will be creating workflow use-cases to determine how
>> complex state machines need to be to implement these use cases.
>>
>> We are very interested in hearing about use cases and workflow-framework
>> experiences from other people. We will update the existing page about
>> workflow on the Cocoon Wiki
>> (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow) with our experiences.
>
> I have no direct personal experience but I've been thinking about flow
> and workflow a lot and I think the only difference is that flow is acted
> by the same person while workflow is acted by more than one person.
>
> If FSM work bad for flow, why would they work any better for workflow?
>
I must confess I am a state machine junkie, so my opinion is a bit biased
towards them. For me the main advantage would be that a state machine
(whether in diagram form or in XML form) would be easy to explain to other
people.
--
Johan Stuyts
Re: Experience with workflow at Hippo Webworks
Posted by Stefano Mazzocchi <st...@apache.org>.
Johan Stuyts wrote:
> Experience with workflow at Hippo Webworks
> ==========================================
>
> At Hippo we used OSWorkflow to implement a workflow solution in a demo.
> Below are our experiences.
>
> As people with different levels of experience are interested in workflow
> I will start with a (very) brief introduction to workflow.
>
> Workflow introduction
> ---------------------
> Very simply put workflow serves two purposes:
> - to determine who can do what at which time with an object;
> - to generate a list of pending tasks for users.
>
> An example of the first is that an editor (who) can only publish (do
> what) a document (an object) after a writer has asked for a review (at
> which time).
>
> The lists of documents to be reviewed is an example of a pending task
> list for an editor.
>
> Each object type can have its own specific workflow.
>
> The demo workflow
> -----------------
> The demo we created has a workflow for a basic document type, a web
> page. I have attached a diagram of it.
>
> A document gets created by a writer. The writer is not allowed to
> publish his document directly, he has to ask the editor for review.
>
> The editor can easily review documents because we generate a list of
> documents waiting for review. The editor can click on the document and
> can either approve or disapprove. If the document gets approved it is
> published on the public server.
>
> If the document gets disapproved the writer can not ask for a review
> without editing it first. Editing the document when it has been approved
> will bring the document back to the editing state too. After making his
> changes the user can ask for a review of the new version.
>
> Implementation
> --------------
> For the document repository we use Slide. For the workflow engine we
> used OSWorkflow. We connected these two using Slide interceptors.
wow, supercool!! I want it :-)
> When a document is created the interceptor checks to see whether a
> workflow already exists. It does this by retrieving the workflow ID from
> a WebDAV property of the document. If it doesn't exist a new workflow is
> created in the workflow store.
Interesting terminology you use here: let me ask you this before we get
confused: "workflow" is for you an instance of the model or the model
itself?
> When our frontend retrieves the tree of documents, the interceptor will
> retrieve the workflow for each document.
Seems to be the instance. Ok, careful though, because normally people
refer to workflow as the "model", not the instance.
> Looking at the role of the user
> the interceptor will determine which actions are enabled. The enabled
> actions (including their display text and activation URLs) are set in a
> WebDAV property of the document.
>
> For the generation of the pending task list we used the OSWorkflow query
> API to generate the documents which are in the waiting-for-review state.
> The approve and disapprove actions are passed to the frontend in the
> same way as the commands for a writer.
>
> Not all actions are directly shown in the menu, because the user invokes
> them implicitly. The edit action for example is invoked by the
> interceptor each time the user saves the document.
>
> Issues
> ------
> We encountered issues with both slides and OSWorkflow during the
> implementation.
>
> Before we used Slide, we used the Cocoon repository. The semantics of
> the repository interceptors and the Slide interceptors is not the same.
> With the repository interceptor we were able to add a property to the
> document in postStoreContent(...). In Slide we had to do this in
> preStoreContent(...).
IMHO, makes more sense to add metadata in pre-saving than in
post-saving. It's way more efficient for clustered environments.
> Apart from that the Slide interceptors work very well, but (in the
> version of Slide we used) they get called a lot. A single store of a
> document invoked preStoreContent(...) and postStoreContent(...) multiple
> times.
well, this is a bug then. there should be a way to connect to an atomic
event for a content store... you might want to bring this up on slide-dev
> OSWorkflow performed great too. The only disadvantage was the complexity
> of state machines that can be expressed. As you can see in the attached
> diagram nested states are used. OSWorkflow does not support these.
The more I hear about workflows, the more I think that writing them with
flow and continuations makes more sense than writing a finite state machine.
> Although the attached workflow does not contain parallel states, we
> think it might be needed for some document types. A newsletter for
> example follows the same workflow as the attached one. But parallel to
> this is a mailing workflow for sending it to the newsletter subscribers.
>
> In the mailing workflow the user can send a test email of the current
> version to himself. When he is satisfied he can send the final version
> to the newsletter subscribers. After this, he can neither send a test
> email nor send it to the subscribers.
>
> But what to do if a mistake in the newsletter is found after sending it
> to the subscribers? The subscribers won't be happy to receive another
> copy, so the mailing actions should stay blocked. But not correcting the
> newsletter on the website looks sloppy. Therefore the
> editing/reviewing/publishing workflow has to remain active.
this screams for long-lasting continuations!
> Workflow requirements
> ---------------------
> Building an effective and solid workflow solution requires two
> preconditions. Both are outside the scope of the workflow framework:
> - understandable role assignment (from a user's perspective) and simple
> role retrieval;
> - typed document repository. This is necessary to enable different
> document types having different workflows attached to them.
granted.
> When these two preconditions are met, the workflow framework must meet
> the following basic requirements:
> - the ability to specify under what conditions an action can be invoked.
> Authorization is considered a specific type of condition;
I think you mean "authentication" not "authorization".
> - the ability to retrieve the actions which can be invoked by a
> particalur user at this moment;
yes
> - the ability to query the workflow store for objects which are in a
> specific state and are relevant to the current user.
I don't think the workflow engine should have anything to do with the
objects. As for basic SoC, the workflow engine should be a separate
entity, a rule engine.
> The requirements on the main function of a workflow framework,
> state-machine evaluation, depend on the complexity of the use cases
> which need to be implemented.
>
> Although we implemented the workflow in our demo using OSWorkflow we
> were not completely satisfied. Some actions, edit and delete for
> example, should be available in more than one state. We had to promote
> these actions to global actions, and add conditions to these actions to
> check whether the workflow is in a valid state. Because of this creative
> coding the logic of the workflow moved out of its context and difficult
> to read from the workflow configuration.
>
> In our opinion a workflow framework supporting almost all constucts from
> UML state machines is needed to be able to build powerful, and still
> easy-to-understand solutions.
It would be killer to have a UML drawing tool that would generate
javascript with continuations!
> Where to go next
> ----------------
> Our next goals are to make sure the two preconditions are met.
> Concurrently we will be creating workflow use-cases to determine how
> complex state machines need to be to implement these use cases.
>
> We are very interested in hearing about use cases and workflow-framework
> experiences from other people. We will update the existing page about
> workflow on the Cocoon Wiki
> (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow) with our experiences.
I have no direct personal experience but I've been thinking about flow
and workflow a lot and I think the only difference is that flow is acted
by the same person while workflow is acted by more than one person.
If FSM work bad for flow, why would they work any better for workflow?
--
Stefano.
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Unico Hommes wrote:
>> The drawback to that approach is that other access paths to the repo
>> are not attached to the workflow (of course you can do things like
>> routing your WebDAV traffic through Cocoon).
>>
>
> Well, going through a repository layer on the Cocoon side does not mean
> the actual workflow data cannot be persisted in the form of properties
> on the repository (WebDAV properties in Slide this case). So I don't see
> a big problem there.
Well, the workflow might employ some kind of authorization, such as a
user is only allowed to edit a document if he took that document into
the "beingprocessed" state.
If you pass by the workflow by directly accessing the repo (for instance
with a WebDAV tool) you would pass by that authorization layer.
>> So what might such a WorkflowManager look like? Our WorkflowManager
>> (and I hereby propose to follow that path :-) is implemented as a
>> Avalon component with the following interface:
>> -setState(docURI, requestedState, user, optionalObject)
>> -getState(docURI)
>> -getAllowedActions(docURI, user)
>> -setRepo(repo)
>>
>> I hope the general meaning of the parameters is clear (and the details
>> may be discussed later). "docURI" might be just an object identifier
>> or an object carrying things like doctype information (so that your
>> second precondition is met). "requestedState" might be a State object,
>> an Action object, an Event object, simply a string or whatever.
>> "optionalObject" in our case is string carrying a comment.
>>
>
>
> I think the repository is implementation specific and shouldn't be part
> of the interface.
Agreed.
Guido
> The user might also be regarded as an aspect of the
> manager's state but I am less sure of that.
>
> --
> Unico
>
>
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Experience with workflow at Hippo Webworks
Posted by Unico Hommes <un...@hippo.nl>.
Guido Casper wrote:
> Johan,
>
> thanks a lot for sharing your experiences.
>
> As it happens I'm right now implementing workflow for a customer.
>
> I have no knowledge about OSWorkflow (or any other commercial or
> non-commercial workflow engine) and having looked at Lenya's workflow
> package I couldn't quite get how to use it in my context (I would be
> grateful if Lenya people are listening and jumping into this
> discussion). However while implementing I quickly discovered I came up
> with with similar terms (what surprise :-)
>
> It's interesting that you connected workflow directly at the repository
> (backend) level, which appears right to do so at first. But I believe we
> should try to do it at the "Cocoon level". TBH currently I'm only
> interested to do it at the Cocoon level since this would allow me to use
> it in different "Cocoon contextes". Whether that should read "Cocoon
> repository level" instead of "Cocoon level" I'm not sure since there
> might be other objects (like simple records in a SQL table) to be
> attached to workflow.
>
Yes, I think we should be as undiscriminating as possible regarding the
types of objects that can be the subject of workflow. Even in document
publishing it is often not only the physical document itself that is
under workflow since it has secundary objects such as images or other
type attachments. Or you may want to associate a whole set of documents
as one entity with a workflow instance.
> But to have a common ground (and terminology) I just talk about
> (Cocoon's) repository and documents (being resources or objects having
> workflow attached).
>
> Our customer's repository is also a WebDAV repository and the current
> workflow state is captured as a WebDAV property of the document.
>
> If the Repository interface within the repository block would be
> extended with get/setProperties (maybe we should simply have another one
> "RepoWithProps") I believe the same workflow engine could be connected
> to any repository implementation attached to that interface.
>
Currently property management in the repository block is implemented by
the proxy-like RepositorySource. I *have* been thinking that this would
be nicer to have directly on the Repository interface though. (I don't
really like the inheritence model of all different Source enhancements
and would only like to only resort to that in special cases such as WebDAV).
> The drawback to that approach is that other access paths to the repo are
> not attached to the workflow (of course you can do things like routing
> your WebDAV traffic through Cocoon).
>
Well, going through a repository layer on the Cocoon side does not mean
the actual workflow data cannot be persisted in the form of properties
on the repository (WebDAV properties in Slide this case). So I don't see
a big problem there.
> On a side note, I believe in addition to components implementing the
> Repository interface we could/should come up with a set of components
> (like a WorkflowManager :-) sitting on top of that repository. But this
> gets too much offtopic.
>
> The workflow our customer has goes roughly like this:
>
> ------------ ------------- --------
> |tobereviewed|------>|beingreviewed|------>|released|
> ------------ ------------- --------
> /|\ | |
> | | |
> | \|/ \|/
> -------------- ------------- ------
> |beingprocessed|<--->|tobeprocessed|<------|online|
> -------------- ------------- ------
> /|\ | |
> | \|/ |
> | -------- |
> --------------->|archived|<-------------
> --------
>
> The boxes represent states a particular document might be in and the
> arrows are transitions allowed. Authorization is also taken into account
> in a sense that there are 2 globally valid roles (like user and editor
> :-) and each user must possess one of those. Some transistions are only
> allowed by one of those roles (all this looks very similar to your use
> cases - what surprise again :-). "tobeprocessed" might have a username
> attached to it and "beingprocessed" always has a username attached to it
> (the name of the user who put the document into the "beingprocessed"
> state) and only this user is allowed to edit this document and to
> transfer it into another state. There is another level of authorization
> (such as who might create/delete and edit docs at particular repo
> locations) implemented via WebDAV ACL.
>
Yay! :-)
> We always capture the states as being properties of a document (that
> means there is no such thing as a workflow instance). So a pending task
> list for a user might simply be implemented by a DASL (or whatever query
> language the particular repository implementation might implement) query
> that goes like:
> -give me all documents in "tobeprocessed" state
> -give me all documents in "tobeprocessed" state with my name attached
> -give me all documents in "tobereviewed" state
>
I like it.
> and doesn't have to be a concern of the workflow engine at all.
>
> So what might such a WorkflowManager look like? Our WorkflowManager (and
> I hereby propose to follow that path :-) is implemented as a Avalon
> component with the following interface:
> -setState(docURI, requestedState, user, optionalObject)
> -getState(docURI)
> -getAllowedActions(docURI, user)
> -setRepo(repo)
>
> I hope the general meaning of the parameters is clear (and the details
> may be discussed later). "docURI" might be just an object identifier or
> an object carrying things like doctype information (so that your second
> precondition is met). "requestedState" might be a State object, an
> Action object, an Event object, simply a string or whatever.
> "optionalObject" in our case is string carrying a comment.
>
I think the repository is implementation specific and shouldn't be part
of the interface. The user might also be regarded as an aspect of the
manager's state but I am less sure of that.
--
Unico
Re: Experience with workflow at Hippo Webworks
Posted by Guido Casper <gc...@s-und-n.de>.
Johan,
thanks a lot for sharing your experiences.
As it happens I'm right now implementing workflow for a customer.
I have no knowledge about OSWorkflow (or any other commercial or
non-commercial workflow engine) and having looked at Lenya's workflow
package I couldn't quite get how to use it in my context (I would be
grateful if Lenya people are listening and jumping into this
discussion). However while implementing I quickly discovered I came up
with with similar terms (what surprise :-)
It's interesting that you connected workflow directly at the repository
(backend) level, which appears right to do so at first. But I believe we
should try to do it at the "Cocoon level". TBH currently I'm only
interested to do it at the Cocoon level since this would allow me to use
it in different "Cocoon contextes". Whether that should read "Cocoon
repository level" instead of "Cocoon level" I'm not sure since there
might be other objects (like simple records in a SQL table) to be
attached to workflow.
But to have a common ground (and terminology) I just talk about
(Cocoon's) repository and documents (being resources or objects having
workflow attached).
Our customer's repository is also a WebDAV repository and the current
workflow state is captured as a WebDAV property of the document.
If the Repository interface within the repository block would be
extended with get/setProperties (maybe we should simply have another one
"RepoWithProps") I believe the same workflow engine could be connected
to any repository implementation attached to that interface.
The drawback to that approach is that other access paths to the repo are
not attached to the workflow (of course you can do things like routing
your WebDAV traffic through Cocoon).
On a side note, I believe in addition to components implementing the
Repository interface we could/should come up with a set of components
(like a WorkflowManager :-) sitting on top of that repository. But this
gets too much offtopic.
The workflow our customer has goes roughly like this:
------------ ------------- --------
|tobereviewed|------>|beingreviewed|------>|released|
------------ ------------- --------
/|\ | |
| | |
| \|/ \|/
-------------- ------------- ------
|beingprocessed|<--->|tobeprocessed|<------|online|
-------------- ------------- ------
/|\ | |
| \|/ |
| -------- |
--------------->|archived|<-------------
--------
The boxes represent states a particular document might be in and the
arrows are transitions allowed. Authorization is also taken into account
in a sense that there are 2 globally valid roles (like user and editor
:-) and each user must possess one of those. Some transistions are only
allowed by one of those roles (all this looks very similar to your use
cases - what surprise again :-). "tobeprocessed" might have a username
attached to it and "beingprocessed" always has a username attached to it
(the name of the user who put the document into the "beingprocessed"
state) and only this user is allowed to edit this document and to
transfer it into another state. There is another level of authorization
(such as who might create/delete and edit docs at particular repo
locations) implemented via WebDAV ACL.
We always capture the states as being properties of a document (that
means there is no such thing as a workflow instance). So a pending task
list for a user might simply be implemented by a DASL (or whatever query
language the particular repository implementation might implement) query
that goes like:
-give me all documents in "tobeprocessed" state
-give me all documents in "tobeprocessed" state with my name attached
-give me all documents in "tobereviewed" state
and doesn't have to be a concern of the workflow engine at all.
So what might such a WorkflowManager look like? Our WorkflowManager (and
I hereby propose to follow that path :-) is implemented as a Avalon
component with the following interface:
-setState(docURI, requestedState, user, optionalObject)
-getState(docURI)
-getAllowedActions(docURI, user)
-setRepo(repo)
I hope the general meaning of the parameters is clear (and the details
may be discussed later). "docURI" might be just an object identifier or
an object carrying things like doctype information (so that your second
precondition is met). "requestedState" might be a State object, an
Action object, an Event object, simply a string or whatever.
"optionalObject" in our case is string carrying a comment.
Such an interface might be high level enough to allow for plugging in
slightly different approaches.
WDYT?
Oh, one more thing that might be worth discussing first. I reasonate
with many of the things Stefano said, except the thing about connecting
workflow to flow (or to continuations). Maybe I'm just not getting the
picture (and I thought a lot about it) but I couldn't think of how
continuations make my life easier. Maybe that is because I don't think
about workflow as being instances of something (but this seemed to go
along with Stefano's thoughts). Now I'm not sure about that anymore ...
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Johan Stuyts wrote:
> Experience with workflow at Hippo Webworks
> ==========================================
>
> At Hippo we used OSWorkflow to implement a workflow solution in a demo.
> Below are our experiences.
>
> As people with different levels of experience are interested in workflow
> I will start with a (very) brief introduction to workflow.
>
> Workflow introduction
> ---------------------
> Very simply put workflow serves two purposes:
> - to determine who can do what at which time with an object;
> - to generate a list of pending tasks for users.
>
> An example of the first is that an editor (who) can only publish (do
> what) a document (an object) after a writer has asked for a review (at
> which time).
>
> The lists of documents to be reviewed is an example of a pending task
> list for an editor.
>
> Each object type can have its own specific workflow.
>
> The demo workflow
> -----------------
> The demo we created has a workflow for a basic document type, a web
> page. I have attached a diagram of it.
>
> A document gets created by a writer. The writer is not allowed to
> publish his document directly, he has to ask the editor for review.
>
> The editor can easily review documents because we generate a list of
> documents waiting for review. The editor can click on the document and
> can either approve or disapprove. If the document gets approved it is
> published on the public server.
>
> If the document gets disapproved the writer can not ask for a review
> without editing it first. Editing the document when it has been approved
> will bring the document back to the editing state too. After making his
> changes the user can ask for a review of the new version.
>
> Implementation
> --------------
> For the document repository we use Slide. For the workflow engine we
> used OSWorkflow. We connected these two using Slide interceptors.
>
> When a document is created the interceptor checks to see whether a
> workflow already exists. It does this by retrieving the workflow ID from
> a WebDAV property of the document. If it doesn't exist a new workflow is
> created in the workflow store.
>
> When our frontend retrieves the tree of documents, the interceptor will
> retrieve the workflow for each document. Looking at the role of the user
> the interceptor will determine which actions are enabled. The enabled
> actions (including their display text and activation URLs) are set in a
> WebDAV property of the document.
>
> For the generation of the pending task list we used the OSWorkflow query
> API to generate the documents which are in the waiting-for-review state.
> The approve and disapprove actions are passed to the frontend in the
> same way as the commands for a writer.
>
> Not all actions are directly shown in the menu, because the user invokes
> them implicitly. The edit action for example is invoked by the
> interceptor each time the user saves the document.
>
> Issues
> ------
> We encountered issues with both slides and OSWorkflow during the
> implementation.
>
> Before we used Slide, we used the Cocoon repository. The semantics of
> the repository interceptors and the Slide interceptors is not the same.
> With the repository interceptor we were able to add a property to the
> document in postStoreContent(...). In Slide we had to do this in
> preStoreContent(...).
>
> Apart from that the Slide interceptors work very well, but (in the
> version of Slide we used) they get called a lot. A single store of a
> document invoked preStoreContent(...) and postStoreContent(...) multiple
> times.
>
> OSWorkflow performed great too. The only disadvantage was the complexity
> of state machines that can be expressed. As you can see in the attached
> diagram nested states are used. OSWorkflow does not support these.
>
> Although the attached workflow does not contain parallel states, we
> think it might be needed for some document types. A newsletter for
> example follows the same workflow as the attached one. But parallel to
> this is a mailing workflow for sending it to the newsletter subscribers.
>
> In the mailing workflow the user can send a test email of the current
> version to himself. When he is satisfied he can send the final version
> to the newsletter subscribers. After this, he can neither send a test
> email nor send it to the subscribers.
>
> But what to do if a mistake in the newsletter is found after sending it
> to the subscribers? The subscribers won't be happy to receive another
> copy, so the mailing actions should stay blocked. But not correcting the
> newsletter on the website looks sloppy. Therefore the
> editing/reviewing/publishing workflow has to remain active.
>
> Workflow requirements
> ---------------------
> Building an effective and solid workflow solution requires two
> preconditions. Both are outside the scope of the workflow framework:
> - understandable role assignment (from a user's perspective) and simple
> role retrieval;
> - typed document repository. This is necessary to enable different
> document types having different workflows attached to them.
>
> When these two preconditions are met, the workflow framework must meet
> the following basic requirements:
> - the ability to specify under what conditions an action can be invoked.
> Authorization is considered a specific type of condition;
> - the ability to retrieve the actions which can be invoked by a
> particalur user at this moment;
> - the ability to query the workflow store for objects which are in a
> specific state and are relevant to the current user.
>
> The requirements on the main function of a workflow framework,
> state-machine evaluation, depend on the complexity of the use cases
> which need to be implemented.
>
> Although we implemented the workflow in our demo using OSWorkflow we
> were not completely satisfied. Some actions, edit and delete for
> example, should be available in more than one state. We had to promote
> these actions to global actions, and add conditions to these actions to
> check whether the workflow is in a valid state. Because of this creative
> coding the logic of the workflow moved out of its context and difficult
> to read from the workflow configuration.
>
> In our opinion a workflow framework supporting almost all constucts from
> UML state machines is needed to be able to build powerful, and still
> easy-to-understand solutions.
>
> Where to go next
> ----------------
> Our next goals are to make sure the two preconditions are met.
> Concurrently we will be creating workflow use-cases to determine how
> complex state machines need to be to implement these use cases.
>
> We are very interested in hearing about use cases and workflow-framework
> experiences from other people. We will update the existing page about
> workflow on the Cocoon Wiki
> (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow) with our experiences.
>
> Johan Stuyts
> Hippo Webworks
> http://www.hippo.nl/
> johan (at) hippo (dot) nl
>
> ------------------------------------------------------------------------
>