I'm currently reviewing a business process that spans manual and system tasks and I want a workflow engine to manage it. I was using Jawe to model the workflow and create the basic XPDL. (We do not have web services so I assume BPEL is not an option - right?). In our workflow there is a split that occurs and it is important that processing across the various split flows happens concurrently.
The plan was to use Enhydra Shark, but from my reading it appears that Shark does not create it's own threads so how can it do concurrent processing? Has anyone added this capability to Shark? Does anyone know a workflow engine that will do this sort of concurrent processing (and therefore have a internally managed thread pool of some sort)?
Kontinuum does I believe but it is not open source.
Parallel Split should use Concurrent Threads
Posted byAnonymous Userat
2006-06-06 04:36 AM
You have a very good point, if you model parallelism in your workflow, why should you accept anything less from the engine? With JOpera (www.jopera.org) you can even scale out the engine over a cluster of computers if you run out of threads on a single machine.
I'm currently reviewing a business process that spans manual and system tasks and I want a workflow engine to manage it. I was using Jawe to model the workflow and create the basic XPDL. (We do not have web services so I assume BPEL is not an option - right?). In our workflow there is a split that occurs and it is important that processing across the various split flows happens concurrently.
The plan was to use Enhydra Shark, but from my reading it appears that Shark does not create it's own threads so how can it do concurrent processing? Has anyone added this capability to Shark? Does anyone know a workflow engine that will do this sort of concurrent processing (and therefore have a internally managed thread pool of some sort)?
Are you sure you fully understand what you need ?
concurrent processing != java threads.
Replies to this comment
Kontinuum does I believe but it is not open source.
You have a very good point, if you model parallelism in your workflow, why should you accept anything less from the engine? With JOpera (www.jopera.org) you can even scale out the engine over a cluster of computers if you run out of threads on a single machine.
Replies to this comment