Just change the subject to discuss on one point. => How make workflow application (in one image) delegate activation (and/or subworkflow) to another image.
>> 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. I don’t really agree. Of course you’re right but I see little interest in having a process engine in a centralized manner (today is more about decentralized solution than ever and we have smalltalk heritage about message passing). Because, in centralized workflow, complexity is the proper use of the tool. You work in a decentralized world with a centralized tool. You have to plug to existing IS through mails, sms, REST API or whatever… All workflow systems I’ve seen (I’m not expert though) are that way and quite boring to use by the way… Then, we enter the real of model transformation so as to be interoperable. Whereas I kind of like the concepts, I find it’s like programming in C vs. in Smalltalk fo information exchange… Slow, couter intuitive, web based most of the time… So to come back to the subject, to me, to have a powerful workflow engine, one has first to consider actors on several applications hence images (at starts). Of course several actors on the same image can be interesting, so doing it first has sense. To me, but I know I see things superficially (I’m not a programmer), we could have something quite simple that does the job. Of course it raises questions like we had with Max. I copy below as my response (see PS). But to sumup, the simple version I need will be one person runs a workflow in a RootFrame. Then he has activities he is responsible but I can delegate some other. It’s possible to have subworkflows (but again associated to him or an actor in the image). We could « just add » the possibility to activate a distant step (or a distant subworkflow). Me (Alice) ask someone else (Bob) to do an activity (a step). Here is how I see it: -My process activate this task (image Alice). I send a signal, a message to the appropriate actor (image of Bob). I just wait until I receive other signals (progression metadata, resources, deliverables…). Of course cancelling an activation is useful there as Bob can never answer. - I (image Alice) have not a lot of responsibility except waiting. - An interesting option would be to be able to ping for completion. -The distant image manager (and scheduler) receive a signal, a message so that a step has to be done. -Bob does the job on its own. Send progressively elements (eventually). He has to send at least when the job is over (eventually devliverables as documents, informations, …). The key to me is to consider systems that are distributed (decentralized actually) not in computer terms but in human terms… It changes everything as less complex. Look at workflow right now, it only allows manual completion of activations (step being realized)…. So it’s basically a human clicking on a button to tell the system the activity is over ! I would prefer having this functionality in a distributed/decentralized manner than having workflow more powerful in a centralized manner. So to me we need to extend and reify better the possibility to delegate and clicks on buttons (regarding questions) and of course in a decentralized manner. I hope you understand what I mean. I hope too not being to naive about such a design. But to me, we need two basic building blocks to provide what I (we?) need: - the possibility to inform to someone or to a group (wait no response - but eventually information on status like reception, first reading, complete reading) - the possibility to request someone or to a group (I wait for a response) Don’t hesitate to criticize, discuss, I’m all ears ;-) Cheers, Cédrick PS: The discussion about this point with Max >> 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 usage > Soon, 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 continues > > So 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).
