Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <404B10AB.1060505@s-und-n.de>
Date: Sun, 07 Mar 2004 13:08:11 +0100
From: Guido Casper <gcasper@s-und-n.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Experience with workflow at Hippo Webworks
References: <opr4ecnkt5xee7wx@naomi> <4048FCCD.5030803@apache.org>
 <404A1F0D.5000700@s-und-n.de> <404A8863.7020401@apache.org>
In-Reply-To: <404A8863.7020401@apache.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

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