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 :-)
------------ ------------- -------- |tobereviewed|------>|beingreviewed|------>|released| ------------ ------------- -------- /|\ | | | | | | \|/ \|/ -------------- ------------- ------ |beingprocessed|<--->|tobeprocessed|<------|online| -------------- ------------- ------ /|\ | | | \|/ | | -------- | --------------->|archived|<------------- --------
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 :-).
Guido
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 mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -------------------------------------------------
