Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC02FECCAE@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: <dev@cocoon.apache.org>
Date: Tue, 9 Mar 2004 14:06:21 -0600
Subject: RE: Experience with workflow at Hippo Webworks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-SEF-FD9E3BCC-24E9-4B6F-96E-FFC4B78D445A: 1
content-class: urn:content-classes:message
Thread-Topic: Experience with workflow at Hippo Webworks
Thread-Index: AcQF6Y9I+dvT/sZlSHKWyLAv+d5svgAJpX/A
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Stefano Mazzocchi <stefano@apache.org> writes:

<snip/>

> > This won't be easy in state machines either, but I think it=20
> is possible=20
> > if you store state paths. When the workflow instance is=20
> read by a new=20
> > workflow definition, the definition matches the paths to his states.
>=20
> You can call it whatever you want but a "state" in a FSM and a=20
> "continuation" in a script are exactly the same thing, they need to=20
> contain the same amount of data to be able to resort the execution.
>=20
> The problems in replicating one across containers will be the same=20
> problems in replicating the other.

Hmm, I don't think so.  A FSM (in general) and a continued script are in
not isomorphically equivalent in CS terms, so there can be no
equivalence between the maintenance of state and the maintenance of a
continuation.  However, for practical purposes, I would agree, they need
to contain more or less the same information.  However, given the
limitations of a FSM the continuation can contain a more information
than a FSM (even with a extended state as described) can hold; the
continuation can hold dynamically crated information where as a
traditional FSM cannot.

> >>> Furthermore, there exists what is called "ad-hoc"=20
> worklows, where a
> >>> user, depending on its rights, can modify the workflow=20
> for a particular
> >>> instance. An example of this is when a document has to be=20
> published that
> >>> contains highly technical material. The editor may want to add an
> >>> additional step in the workflow for the document to be=20
> validated by a
> >>> technical expert, which doesn't happen in normal cases.
> >>>
> >>> In that situation, asking a user to write a new version=20
> 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?
> >>
> >=20
> > I think the option to request review by a technical expert=20
> should be=20
> > programmed explicitly by the developers too. Instead of=20
> just 'publish'=20
> > and 'disapprove', the editor can also invoke 'request=20
> technical review'.
>=20
> No matter what, an editor is not going to write neither FSM or script=20
> code. And even if you throw something like Oracle Workflow at him, he=20
> will hire somebody else to do it.

My focus is the business analyst; we expect them to model business
processes.  We hope for the modeling to hit the point where it hits the
90% point for implementing work flow without developer assistance...

> >> Let's compare apples to apples here: we are not discussing how the
> >> workflows should be edited, but how they are going to=20
> impact our system
> >> and how we are going to build them.
> >>
> >> there are several solution on the table and at least two=20
> architecturally
> >> orthogonal questions:
> >>
> >>   1) should the workflow engine have direct data control?
> >=20
> >=20
> > For me the data should reside in the document/object to which the=20
> > workflow instance :) is attached. The only information stored in a=20
> > workflow instance is (possibly) an identifier which can be used to=20
> > locate the document/object.
> >=20
> > The actual implementation of the conditions and the actions=20
> that get=20
> > executed on certain events should not be in the workflow=20
> definition, but=20
> > should be separate. The workflow definition only references these=20
> > separate implementations. The implementations get passed=20
> the identifier=20
> > of the document/object when invoked, so they can retrieve the=20
> > document/object to do their work.
> >=20
> >>   2) should the workflow engine deal with procedural=20
> scripts or finite
> >> state machines directly?
> >>
> >=20
> > State machine junkie talking: state machines. I see state=20
> machines as a=20
> > different way of programming than procedural, and think=20
> that coding them=20
> > using procedural code will be more difficult. The=20
> conditions and actions=20
> > which connect the workflow instance to the environment it=20
> is running in=20
> > are procedural, and that's why I program these in Java (in=20
> our demo).
>=20
> Finite state machine represent a way to program declaratively.=20

Still thinking on this one, not sure it's really true?  Given the
limitations of a FSM I don't think it can be?

> This=20
> requires normally a higher level of abstraction and, for example, it=20
> could be identified as the reason why Lisp and friends, although the=20
> most powerful programming languages, didn't take off.
>=20
> You see the same problem emerging in XSLT (XSLT is, in fact,=20
> a Lisp-like=20
> language with an XML syntax, being the direct descendant of=20
> DSSSL): it's=20
> hard to find people that can write XSLT. They are a special=20
> cast. They=20
> are scarce. This translated on the market as: they cost more!
=20
We've had the XSLT skill set discussion before. I agree, but in our
case, we just don't expose the XSLT directly to the business analysts
even if they are using our modeling tools to build them under the
covers;  I can't imagine a business analyst writing Schematron directly,
four of them have created over 1000 Schematron templates using a GUI
provided by our system...

> FSM are harder to program for web applications, I still don't see why=20
> they should be easier to program for workflows.
>=20
> Probably I need an example here to really appreciate the two=20
> complexities side by side.

Well I probably don't need to repeat my biases to Stephano, but once
more: you need a Turing complete language to write work flow in.  You
need to be able to dynamically modify any given work flow instance.
FSM's can't do this, perhaps some other forms of state machines can do
this, but now you're heading into CS esoteria.  Let's use the machinery
that Cocoon already ships with...