thanks for the quick response. i share your vision on what i would call 'omnipotent' workers let me be clear. this should be the 'default' for easy scalability indeed.
for your info our use case is a document processing platform where some steps require some specific capabilities like a hardware signing module (for pdf signing) or require a specific OS (like windows for the unfortunate case where we correctly need to convert a docx to pdf), these are the 'exceptions' on the rule. and as mentioned there are solutions available that make sense. we are looking forward to route-swf because it might give us an easy nicely integrated 'solution'. An other reasoning we had is that another angle on it is that it basically boils down to having multiple 'stores' in one 'engine' / 'dashboard' and linking participants to a 'store' within an engine. in the swf mapping a store would than map to a task list and for existing stores it would just point to seperate stores. This would give a more integrated feel to the engine participants. another use case for this, just for information is the following : for the overal workflow we want the workflow state to be persistent. so a sql or nosql store makes a lot of sense for those. but for specific subparts of the flow the intermedia state is not really that important (if it fails, we just do it all over again). a redis store would make a lot of sense there for example. as said today we can do it through multiple engines with engine participants but for expressiveness also here the possibility to link participants to 'stores' and workers to 'stores' within one 'engine' seems to make sense. but also here it might be that your ruote-swf generalization to ruote might give an opening? regards koen handekyn On Mar 23, 1:21 pm, John Mettraux <[email protected]> wrote: > Hello Koen, > > welcome to ruote's mailing list. > > Ruote-swf won't have an "out-of-the-box" way to link a specific participant > to a given activity worker. However it would be easy to specify a task list > in the participant configuration and to modify the ruote-swf storage decision > worker to pass the activity task on a specific task list (polled by a given > activity worker). > > I have to say, for better scaling I tend to favour architectures where there > is a single class of workers (in the ruote-swf case, a single class of > decision workers and a single class of activity workers). So that scaling is > easy, you just add a new worker, you don't have to think about what kind of > special worker you want to add. I understand some use cases might require > different architectures... > > (as you might have guessed, ruote-swf separates workflow operations from > participant operations (decision workers vs activity workers respectively)) > > Kind regards, > > -- > John Mettraux -http://lambda.io/processi -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
