cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <>
Subject Re: Response to workflow
Date Tue, 16 Mar 2004 14:49:56 GMT
Johan Stuyts wrote:
> 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.

Well, the same can be said about CMSs or many other things. Does that 
mean there is no simple solution?

It very much depends how your code evolves when meeting new 
requirements. In Open Source things might be different. If you start 
complex, chances are higher that no community appears and the code ends 
up unused and unmaintained.

Maybe your complex problem might be partitioned into several simpler 
ones. But if you start by throwing a complex solution at it you might 
never find out.

Let me give you an example. Taking my workflow again :-)

  ------------         -------------         --------
  ------------         -------------         --------
      /|\                    |                  |
       |                     |                  |
       |                    \|/                \|/
  --------------       -------------         ------
  --------------       -------------         ------
      /|\                    |                  |
       |                    \|/                 |
       |                 --------               |

There is a problem (likely to be present in almost any workflow) that 
you probably would call: parallel (or nested) states. If a document goes 
from "online" into "tobeprocessed", it continues to be online. The 
solution I took is (of course :-) simple. Besides a "state" property 
there is a second property "live-state" that gets set to "online" by the 
OnlineAction and gets set to "offline" by the ArchivedAction. The 
workflow engine (or the state objects for that matter) itself is not 
aware of it as the "live-state" property is only evaluated by a separate 
scheduler process.

Now I can imagine people jumping up: "Hey that must be modeled in our 
diagram". But I don't want to. This does neither my communication nor my 
development process any good.

I appreciate the fact that rule engines and the like are starting to 
blur the line between developer and user. However I think that such 
needs might be solved by a simple solution on top of another simple 
solution. That would make them easier to maintain and evolve.

> 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.

I think the scope won't get much clearer by just discussing (but I may
be wrong and my scope being just too limited :-).

> Otherwise it might change too often as more requirements 
> are added.

But that's perfectly fine. Nobody pushes us to settle on the interfaces
prematurely. I prefer starting small and refactor if the need emerges
(there shouldn't be many people not knowing that by now so I shut up
now on that issue :-).


> 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.

Guido Casper
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5
D-33100 Paderborn

View raw message