cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Experience with workflow at Hippo Webworks
Date Tue, 09 Mar 2004 15:16:52 GMT
Johan Stuyts wrote:

> On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi 
> <> 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.


View raw message