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.
smime.p7s
Description: S/MIME Cryptographic Signature
