On Tue, Feb 3, 2009 at 1:43 PM, Keisuke Yamane <[email protected]> wrote: > > Thank you for your quick response!
Hi Keisuke, you're welcome. before answering, let's agree on a common vocabulary (http://openwferu.rubyforge.org/glossary.html) : * a process definition * is a document (or a data structure) describing a way of automating a [business] process * a process instance * is a running 'automation' of a [business] process, created on the base of a process definition (usually). > I clearly understood about the ways for changing definition. I have explained you how to change a running process instance. Changing a [process] definition is easy, you change the document (or the data structure) that the process definition *is*. What I have explained you is how to substitute the DNA (http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%AA%E3%82%AD%E3%82%B7%E3%83%AA%E3%83%9C%E6%A0%B8%E9%85%B8) of a running process instance. Changing a [process] definition is simply like modifying DNA before it is used to build a living cell (process instance). Sorry for the biological images. > But small questions are occurred again. > > You wrote: > >>> In-flow process modification is not that easy ;) Most of the time it's >>> better to have dynamic processes (and sub-processes) than dynamically >>> modifying processes. > > What do you mean "dynamic processes"? Is it different with > "dynamically modifying processes"? > Is it the other feature of Ruote? Sometimes there is no need to modify a process instance on the fly, you can simply make it dynamic. A static process : <sequence> <participant ref="alpha" /> <participant ref="bravo" /> </sequence> This example always goes from "alpha" to "bravo", very static. More dynamic : <sequence> <set field="final_participant" value="bravo" /> <participant ref="alpha" /> <participant ref="${f:final_participant} /> </sequence> In this example, it goes from "alpha" to "bravo" except if the participant alpha changed the value of the field "final_participant" to the name of another participant. This is not limited to participants : <sequence> <set field="final_stage" value="http://documents.example.org/process_definitions/default_final_stage.xml"; /> <participant ref="alpha" /> <subprocess ref="${f:final_stage} /> </sequence> Here, a subprocess is launched, and the participant alpha may choose yet another subprocess. Let's focus on subprocesses and step back to static a bit : <sequence> <participant ref="alpha" /> <subprocess ref="http://documents.example.org/process_definitions/default_final_stage.xml"; /> </sequence> Is this really static ? Yes, no ? It depends. If the sub process definition (the document) at http://documents.example.org/process_definitions/default_final_stage.xml changes you have achieved some dynamicity. Here the URL is rather simple, but you can point to a version control system (which replies with the latest version) or you could point to a web application and the returned process definitions are potentially always different... More info at : http://openwferu.rubyforge.org/expressions.html#exp_subprocess http://openwferu.rubyforge.org/patterns.html http://openwferu.rubyforge.org/expressions.html#exp_eval ... > And also I have a fundamental question about workflow engine > frameworks include Ruote. > > I assume that almost all engines can import XPDL or BPEL, Ruby DSL > ;-)... and store it in memory object. It means "In-flow process > modification is not that easy ;)". Storing "in-memory" is OK for very short lived process instances. But usually workflow engines want to run process instances that live a long time (hour, day, week, month), so a persistence mechanism is a must. In-flow process [instance] modification is not easy (but it's not necessarily hard). It's simply not a "common" task. If you have to do it too often, it could mean your process definitions (and hence the process instances) are not agile enough. And then, there are questions like "should the modification affect only 1 instance or all the instances coming from that process definitions ?" With "dynamic processes" "in-flight" modifications are coming from the inside, while with "process instances dynamically modified", changes are coming from the outside. > But if the process definitions are stored in RDB, will it be more easy > changing processes (of course, we can change only not started tasks.) > and easy permanentizing? Storing process definitions in a database is OK. I guess you meant storing the runtime data / process instances in a relational database. > The RDB structure will be simple, like below. > > Graph Table > ------------------------------------------- > id task_id parent_task_id > 1 1 0 > 2 2 1 > 3 2 3 > 4 3 1 > 5 4 2 > ... > > If there are any suggestion about the reasons why workflow engines > usually NOT store digraph structure in RDB table, please let me know. It depends on the workflow engine architecture / implementation (for instance, Ruote behaves like an interpreter and not like a state machine driver). I don't understand where you want to go with this digraph idea. Do you want to implement it by yourself ? It's somehow not a bad idea. I use "decision participants / tables" to make my processes more dynamic (http://jmettraux.wordpress.com/2008/01/28/rufus-decision-csv-decision-tables/ http://jmettraux.wordpress.com/2007/10/12/decision-accumulation/ or http://jmettraux.wordpress.com/2007/08/06/ruby-decision-table-quickstart/) It's not reading a database table but a CSV file (or a google spreadsheet) to modify [dynamically] the flow of a process. > Sorry, I know this is stupid question because I have not studied any > computer science.. Please don't worry about asking questions. I probably learn more from your questions than your learn from my answers. Are you a business analyst ? Best regards, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruote (OpenWFEru) users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
