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
