linking participants to workers
koen handekyn
from our point of view to be able to link participants to workers. it
would require though a small extension at the storage API though to be
able to implement it efficiently. is this something which was realized
in scope of the SWF modifications and hence might be coming up in
general. Or did you have an alternative approach when integrating SWF.
the key motivation that specific types of work represented by
participants are not everywhere available. we are aware that solution
patterns are available like : separating the specific type of work
into a subflow (subengine) - proxy the work to the location where the
capabilities are present - use an amqp bridge or something similar to
route the work to a specific place.
however, for expressiveness it would just make a lot of sense in some
case to be able to bind registration of a participant to specific
workers.
related as i've seen on the mailing list it also makes sense
John Mettraux
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
koen handekyn
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
John Mettraux
On Fri, Mar 23, 2012 at 06:20:45AM -0700, koen handekyn wrote:
>
> (...)
>
> 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.
Hello again,
I guess you are referring to "engine participants"
(http://ruote.rubyforge.org/part/engine_participant.html)
You could totally have multiple engines using each a different ruote-swf
storage (differentiated by task list (and it's just a transient name)).
> 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?
I'm not sure the generalization is needed; unless clearly demonstrated as
awkward, the current system (engine participants) may be used to have
workflows with different storage implementations communicating. For example,
the SWF backed engine could launch flows or segment of flows (they're not
that different) on an Redis backed engine and back.
I encourage you to explore what's available. If there really is a missing
concept, we'll have to clearly identify it and we'll then find an elegant
solution.
Best regards,