You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Johan Stuyts <jo...@hippo.nl> on 2004/03/16 11:16:55 UTC

Response to workflow

I'm glad to see a healthy discussion about workflow. Here are my responses 
to multiple posts.

Scope
-----
I still think the scope of the project is the first thing that must be 
decided upon before discussing which solution is the best. There are lots 
of options here and covering them all is impossible.

The scope I am interested in is (see the worfklow page on the Wiki):
- a solution for developers;
- although initially we were planning on using workflow for document 
management (object lifecycle), we might need a solution which can be used 
to implement more general processes too;
- whether a general workflow instance can be attached to a single object 
is questionable. A generalized workflow will involve many 
documents/objects (some of which will only be used by that workflow 
instance). I think that in a generalized workflow framework the workflow 
instance itself must be an object with which the developer interacts 
directly instead of the workflow instance being hidden.

I really would like to see more use cases appearing from which we can pick 
a set to implement using different technologies. I will add more use cases 
in the near future.

Standards
---------
Thank you Andreas for putting up the list with standards. We can use these 
for input and reflection upon our decisions.

Conforming to standards is an honourable goal and it has its pros and 
cons. Pros:
- make use of available tools;
- people outside of Cocoon are probably more interested;
- no reinvention of the wheel. The standards are complex because they were 
defined by people with a lot of experience in the field. Chances are that 
if you start out small you end up with the same complexity after several 
years.

Cons:
- it's not easy to use for simple use cases. A period of learning is 
unavoidable;
- huge effort to build a compliant solution.

Interface
---------
The interface provided by Guido makes things more concrete, but, although 
I like state machines very much, I think too much terminology of state 
machines is in the interface.

Also the interface assumes there will only be changes from one state to 
another state, but in concurrent state machines and generalized workflow a 
single trigger can cause multiple state changes including forking and 
syncing.

I think the scope needs to be clearer before we can start thinking about 
the interface. Otherwise it might change too often as more requirements 
are added.

Implementation
--------------
In my opinion no particular technology, e.g. Flow, must be a requirement 
for a workflow implementation. I thought the workflow provider would be an 
Avalon service. This makes it accessible from everywhere and usable 
outside Cocoon.

Conclusion
----------
IMHO there should be more consensus about what is needed and what is 
feasible in a relatively short time, e.g. half a year to a year.

I think building a generalized workflow based on a standard is too 
ambitious. Leaving out some more complex constructs decreases usability. 
It might be an option to choose a (proper) subset of a standard with which 
a large percentage (definitely more than 80%. Having to resort to another 
solution in one of four situations is not acceptable) of use cases can be 
implemented.

-- 
Johan Stuyts, Software Department
Hippo Webworks
Grasweg 35
1031 HW Amsterdam
The Netherlands
Tel  +31 (0)20 6345173
Fax +31 (0)20 6345179
johan(at)hippo(dot)nl / www.hippo.nl