Yes sure. But at this is an important requirement for me, I prefer to
talk about it first :)
Distributed systems design is a different subject. Different constraints,
different solutions.
Announcements would certainly be an interesting way to decouple Workflow from other parts of the system.
Yes an important design decision.
I���d like to have an incomingMessageBox for each user and eventually transform these message in concrete action (user i/o) ? Or dispatch in JobQueues (each user being a distant worker thread). Again, the distinction between Scheduler and BPEngin is fuzzy to me.
Does it make sense to you ?Yes, it does :) What I've asked myself (out of curiosity) is whether you want to have
- a dedicated instance for executing workflows
- a distributed workflow with autonomous synchronisation (parts of a workflow could run on every uses instance, others would need to be executed through agreement)
- a partially distributed workflow with one or more managing nodes that control the core steps (e.g. you could designate parts of a workflow as independant)
I���m not really sure what I want :) .I think the 3 are possible/interesting. What I don���t want is a centralized approach (if it exists, it has to be a very special case).My project is about having autonomous personnel systems. My system have a priori several nodes (one application per device). It���s a decentralized (federated/distributed) network of nodes.My system interact (exchange information basically through messages) with other species having an equivalent node-based system.All is about keeping version history of the information (yes it looks like GIT that I try not to use ^^ - GITHUB could probably be a special kind of node BTW).So I was thinking that one of the exchanged �� messages �� type could be �� activations �� sent by someone responsible of the workflow. So :At first, I want each personal system to have the BP Engine and be able to execute workflow alone (personal routine, planification, suggestions, ���) => normal usageSoon, it becomes distributed, for instance if the person have several devices that share the system and the activations.And if we consider interactions with other persons (and organisations which are group of persons), then we quickly have distributed (or partially distributed) workflows.Not crystal clear I guess :-)This is a subject I���d like to propose a PhD on. I try to convince a web dev company to develop such a distributed organizational tool but��� no positive answer for now). I need to push more !So I give it a try by mysel and here we are.To better respond to you question, here is a simple use case I imagine:- I���m the responsible of the workflow execution.- When I assign a task A to someone (or an organization, or something like a smart object), I delegate the realization and then it would be a special case of SubWorkflow that is distant.1) once activated, I send a special message to the other personal system.+ deadline/metadata + interaction contracts (do I only wait or can I see the actual progression ? To which level?)2) I wait.��� I'm able to ask for the realization status, a degree of completion,������ Depending on the contract (level of agreement), I can have more or less right on seing the realization but that's not the point here. First, I want to delegate and have information about the realization degree (+eventual bad event that could have arose)3) I received the completion message + eventual document, artefacts, summarized information (note that the system respect privacy by defaults - all exchange is under control).4) my workflow continuesSo it���s a bit of a distributed workflow under a central control node but with distributed sub-workflows. It seems doable without too much effort. Maybe declaring DistantSubFlow and having proper history (using messaging functionalities to get status update)But again, quickly, that would be very interesting to consider several managing nodes (I guess another PHD on itself for this one).