Generic Workflow Products?
After applying Zope to a couple of in-house projects (which turned out pretty well, thank you), I've started to come to the realization that many applications boil down to workflow management. A job comes in, attributes get set, things get attached to it, and it gets passed from person to person (to machine, in some cases) as it flows through the system. I guess to start out it would need the following: -- user classes -- job creation -- job attributes, with protection from view and modification depending on user classes -- multiple job queues, with access control, and some sort of priority. Queues may end up being implemented simply by having a job state, sequence number, and priority, and moving from one queue to another would just be changing the state. -- job timeouts for escalation, -- e-mail "ticklers" and notification -- job routing based on attributes and actions. -- some sort of api other then HTTP/HTML for external programs to access jobs, perform actions, and update jobs. -- Extra Credit: Graphical workflow editor. -- (what else am I missing) Sounds like a job for Zope, doesn't it. Basically I've implemented a couple of systems like this, either classic database-driven or z-class driven. But I'm tired of re-inventing the wheel. It would be nicer if systems like this could be implemented at the "workflow logic" level rather than the Zclass level. IE a set of ZClasses or Product classes that implemented workflow systems. Is there such a thing? Has anyone worked on such a thing? Any ideas how to implement such a thing? I've got a couple of modifications to an existing system coming up, which sounds like just the excuse I need for a total rewrite :) -- cary
Cary O'Brien wrote:
After applying Zope to a couple of in-house projects (which turned out pretty well, thank you), I've started to come to the realization that many applications boil down to workflow management. A job comes in, attributes get set, things get attached to it, and it gets passed from person to person (to machine, in some cases) as it flows through the system.
I guess to start out it would need the following:
-- user classes -- job creation -- job attributes, with protection from view and modification depending on user classes -- multiple job queues, with access control, and some sort of priority. Queues may end up being implemented simply by having a job state, sequence number, and priority, and moving from one queue to another would just be changing the state. -- job timeouts for escalation, -- e-mail "ticklers" and notification -- job routing based on attributes and actions. -- some sort of api other then HTTP/HTML for external programs to access jobs, perform actions, and update jobs. -- Extra Credit: Graphical workflow editor. -- (what else am I missing)
Sounds like a job for Zope, doesn't it. Basically I've implemented a couple of systems like this, either classic database-driven or z-class driven. But I'm tired of re-inventing the wheel. It would be nicer if systems like this could be implemented at the "workflow logic" level rather than the Zclass level. IE a set of ZClasses or Product classes that implemented workflow systems.
Is there such a thing? Has anyone worked on such a thing? Any ideas how to implement such a thing?
I've got a couple of modifications to an existing system coming up, which sounds like just the excuse I need for a total rewrite :)
Check out some of the recent work on the PTK list, its building the infrastructure you need to implement plugabble workflows. Kapil
After applying Zope to a couple of in-house projects (which turned out pretty well, thank you), I've started to come to the realization that many applications boil down to workflow management. A job comes in, attributes get set, things get attached to it, and it gets passed from person to person (to machine, in some cases) as it flows through the system. I guess to start out it would need the following: -- user classes -- job creation -- job attributes, with protection from view and modification depending on user classes -- multiple job queues, with access control, and some sort of priority. Queues may end up being implemented simply by having a job state, sequence number, and priority, and moving from one queue to another would just be changing the state. -- job timeouts for escalation, -- e-mail "ticklers" and notification -- job routing based on attributes and actions. -- some sort of api other then HTTP/HTML for external programs to access jobs, perform actions, and update jobs. -- Extra Credit: Graphical workflow editor. -- (what else am I missing) Sounds like a job for Zope, doesn't it. Basically I've implemented a couple of systems like this, either classic database-driven or z-class driven. But I'm tired of re-inventing the wheel. It would be nicer if systems like this could be implemented at the "workflow logic" level rather than the Zclass level. IE a set of ZClasses or Product classes that implemented workflow systems. Is there such a thing? Has anyone worked on such a thing? Any ideas how to implement such a thing? I've got a couple of modifications to an existing system coming up, which sounds like just the excuse I need for a total rewrite :) -- cary There are several workflow activites within Zope that I know of: PTK has and "implicit" workflow support for moving documents in a review process. Unfortunately workflow hangs off of the documents from what I saw of its design patterns. Not a good design if a workflow step involves multiple documents and the execution of applications on data. Several Zope sites have some kind of workflow for what they do. There is a mesh healing (CAD/CAM) Zope based application service provider (ASP) that comes to mind. There is an standards based (WFMC -- workflow management coalition, www.wfmc.org) Zope product that really has seen no progress since early this year - see openflow.sourceforge.net You might consider marrying a workflow engine like Staffware's to Zope. This marriage may be easier if they support SWAP (simple workflow access protocol see www.ics.uci.edu/~ietfswap). Staffware has indicated that they will (are) supporting SWAP. We are a company, vPatch, that is building web-based workflow that can run apps for the oil and gas industry. Our current system uses tclets to display workflow graphically, but we are going to Java. It would be nice to work on a good set of (standards based) design patterns for workflow and implement them in Zope. In my mind these patterns would consider pluggable workflow engines like Staffware's using SWAP. Yours in workflow, Albert Boulanger aboulanger@vpatch.com
Sounds like a job for Zope, doesn't it. Basically I've implemented a couple of systems like this, either classic database-driven or z-class driven. But I'm tired of re-inventing the wheel. It would be nicer if systems like this could be implemented at the "workflow logic" level rather than the Zclass level. IE a set of ZClasses or Product classes that implemented workflow systems. Is there such a thing? Has anyone worked on such a thing? Any ideas how to implement such a thing? I've got a couple of modifications to an existing system coming up, which sounds like just the excuse I need for a total rewrite :) -- cary There are several workflow activites within Zope that I know of: PTK has and "implicit" workflow support for moving documents in a review process. Unfortunately workflow hangs off of the documents from what I saw of its design patterns. Not a good design if a workflow step involves multiple documents and the execution of applications on data. Several Zope sites have some kind of workflow for what they do. There is a mesh healing (CAD/CAM) Zope based application service provider (ASP) that comes to mind. There is an standards based (WFMC -- workflow management coalition, www.wfmc.org) Zope product that really has seen no progress since early this year - see openflow.sourceforge.net You might consider marrying a workflow engine like Staffware's to Zope. This marriage may be easier if they support SWAP (simple workflow access protocol see www.ics.uci.edu/~ietfswap). Staffware has indicated that they will (are) supporting SWAP. We are a company, vPatch, that is building web-based workflow that can run apps for the oil and gas industry. Our current system uses tclets to display workflow graphically, but we are going to Java. It would be nice to work on a good set of (standards based) design patterns for workflow and implement them in Zope. In my mind these patterns would consider pluggable workflow engines like Staffware's using SWAP. Yours in workflow, Albert Boulanger aboulanger@vpatch.com
There is an standards based (WFMC -- workflow management coalition, www.wfmc.org) Zope product that really has seen no progress since early this year - see openflow.sourceforge.net
Correct. OpenFlow was a bit stopped, for two reasons: 1) we here at Icube had undergone acquisition, so it was a bit complicated to follow on the project itself; 2) we have started from WfMC, which was good for defining the interfaces but was a bit bad for designing a real system. Hopefully we can start to work again after the end of this month. More news hopefully to come. Paolo -- Paolo Bizzarri - Responsabile Marketing Icube Srl Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: p.bizzarri@icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588
aboulanger@vpatch.com wrote:
After applying Zope to a couple of in-house projects (which turned out pretty well, thank you), I've started to come to the realization that many applications boil down to workflow management. A job comes in, attributes get set, things get attached to it, and it gets passed from person to person (to machine, in some cases) as it flows through the system.
I guess to start out it would need the following:
-- user classes -- job creation -- job attributes, with protection from view and modification depending on user classes -- multiple job queues, with access control, and some sort of priority. Queues may end up being implemented simply by having a job state, sequence number, and priority, and moving from one queue to another would just be changing the state. -- job timeouts for escalation, -- e-mail "ticklers" and notification -- job routing based on attributes and actions. -- some sort of api other then HTTP/HTML for external programs to access jobs, perform actions, and update jobs. -- Extra Credit: Graphical workflow editor. -- (what else am I missing)
Sounds like a job for Zope, doesn't it. Basically I've implemented a couple of systems like this, either classic database-driven or z-class driven. But I'm tired of re-inventing the wheel. It would be nicer if systems like this could be implemented at the "workflow logic" level rather than the Zclass level. IE a set of ZClasses or Product classes that implemented workflow system.
-- cary
There are several workflow activites within Zope that I know of:
PTK has and "implicit" workflow support for moving documents in a review process. Unfortunately workflow hangs off of the documents from what I saw of its design patterns. Not a good design if a workflow step involves multiple documents and the execution of applications on data.
The PTK has been undergoing radical changes as of late. Its worth taking another look at as the current design is much more supportive of alternative workflow designs.
Several Zope sites have some kind of workflow for what they do. There is a mesh healing (CAD/CAM) Zope based application service provider (ASP) that comes to mind.
also the Xen Zope Product (not on zope.org, where i forget) Kapil
Kapil Thangavelu <kthangavelu@earthlink.net> wrote: The PTK has been undergoing radical changes as of late. Its worth taking another look at as the current design is much more supportive of alternative workflow designs. Disclamer: This is my gleaming -- I could be off. I have done a keyword search on the Zope-PTK list for workflow to understand the recent discussion on workflow design within PTK. It seems to me that workflow is tied to strongly with documents in the design plan. In the model of workflow being discussed there, documents march through workflow steps. What if a workflow step is a computation and requires multiple data sources to be done? Instead, a workflow step needs to have an explicit representation with data items (documents) associated with it having some kind of version info associated with them. This need comes from the use cases that I deal with in setting up workflow for science and engineering computation. For a good review of workflow requirements see: http://www.ics.uci.edu/pub/endeavors/docs/AdvancedWorkflow.pdf It would be nice if the workflow system understood how to act in a distributed way, like what SWAP, (an XML based protocol -- think webdav for workflow -- for distributing workflow) is trying to do: http://www.ics.uci.edu/~ietfswap/swap-prot.txt and the later work, Wf-XML by WFMC. This in turn is based on early WFMC's efforts. See the workflow & internet white paper and reference model at: http://www.aiim.org/wfmc/finalwp.pdf http://www.aiim.org/wfmc/standards/docs/tc003v11.pdf There are models (some UML) contained within that would be useful to use as guides for patterns for workflow I believe. Yours in workflow, Albert Boulanger aboulanger@vpatch.com
albert boulanger wrote:
Kapil Thangavelu <kthangavelu@earthlink.net> wrote:
The PTK has been undergoing radical changes as of late. Its worth taking another look at as the current design is much more supportive of alternative workflow designs.
Disclamer: This is my gleaming -- I could be off. I have done a keyword search on the Zope-PTK list for workflow to understand the recent discussion on workflow design within PTK. It seems to me that workflow is tied to strongly with documents in the design plan. In the model of workflow being discussed there, documents march through workflow steps. What if a workflow step is a computation and requires multiple data sources to be done? Instead, a workflow step needs to have an explicit representation with data items (documents) associated with it having some kind of version info associated with them. This need comes from the use cases that I deal with in setting up workflow for science and engineering computation.
For a good review of workflow requirements see:
http://www.ics.uci.edu/pub/endeavors/docs/AdvancedWorkflow.pdf
i haven't had time to read through the links, although i will once i get some more of that mystical free time stuff, but i wanted to clarify about PTK workflows. most of the existing workflow structs in PTK were doc based with simple workflows, but there has been a concerted effort to refactor PTK into Singleton objects which give abilities to all objects vs. the old method of inheritance for abilities. In this scenario workflow objects can be plugged into the architecture. Another item that gives support for complex workflows is the event/subscriber/publisher system being developed right now. check out the later half of the PTK archives for August to get some more background. if you want to influence the project, now is the time, make your voice/needs heard. Cheers Kapil
i haven't had time to read through the links, although i will once i get some more of that mystical free time stuff, but i wanted to clarify about PTK workflows. most of the existing workflow structs in PTK were doc based with simple workflows, but there has been a concerted effort to refactor PTK into Singleton objects which give abilities to all objects vs. the old method of inheritance for abilities. In this scenario workflow objects can be plugged into the architecture. Another item that gives support for complex workflows is the event/subscriber/publisher system being developed right now. check out the later half of the PTK archives for August to get some more background. if you want to influence the project, now is the time, make your voice/needs heard. One place to start would be to have a look at openflow.sourceforge.net. This Zope based workflow system is based on WFMC's reference model. It does not have everything you would want but it is a good start. Once reason to be looking a WFMC is that such an implementation would allow integration with existing workflow systems such as Staffware's. SWAP and the newer WFMC XML wrapping would also be worth considering as they would be like XML-RPC for workflow which would enhance interoperability. There is a need to execute a workflow box which would exec a app associated with the box on data -- this data not being just one doc in a members PTK folder but a suite of data for the step. There is opportunity for a Zope based system to be the web publishing side of existing workflow systems, like Staffware's. Staffware's white paper on how they will do web-based workflow begged for a solution like Zope. Staffware is one of the better workflow systems that includes the ability to execute programs within workflow. Certainly for usecase analysis one could look at existing packages like Staffware. For events, one might consider adopting some of the "webwise" event system standards coming out. I have not followed these closely, but I know they exist. One reason to do so is that this would enhance interoperability with external packages that also adopt standards. Regards, Albert Boulanger aboulanger@vpatch.com
i haven't had time to read through the links, although i will once i get some more of that mystical free time stuff, but i wanted to clarify about PTK workflows. most of the existing workflow structs in PTK were doc based with simple workflows, but there has been a concerted effort to refactor PTK into Singleton objects which give abilities to all objects vs. the old method of inheritance for abilities. In this scenario workflow objects can be plugged into the architecture. Another item that gives support for complex workflows is the event/subscriber/publisher system being developed right now. check out the later half of the PTK archives for August to get some more background. if you want to influence the project, now is the time, make your voice/needs heard. Here are two useful diagrams from WFMC's white paper, "Workflow and Internet: Catalysts for Radical Change" ( http://www.aiim.org/wfmc/finalwp.pdf ). The first is a diagram of WFMC's reference model. The second is a diagram of workflow concepts. http://www.zope.org/Members/aboulang/wfmc1.gif and http://www.zope.org/Members/aboulang/wfmc2.gif Regards, Albert Boulanger aboulanger@vpatch.com
participants (5)
-
aboulanger＠vpatch.com -
albert boulanger -
Cary O'Brien -
Kapil Thangavelu -
Paolo Bizzarri