Hi again John, ok for the previous considerations I understand and agree with you. And also I'm sure that the current is the first implementation so you will add much more features in the near future....
The last question. Another thing that lead me to design the schema as I proposed. But since I'm not completely sure that the motivation is strongly founded please give me your opinion( other's are very welcome too, of course ). When in step process the participant replies, following subprocess is invoked by the engine with an apply method call and this starts the new subprocess, i.e. we are going down in the execution tree( please correct me if I'm wrong, because I'm not sure that the concept of execution tree may be applied here... ). Now being within another step when calling the next subprocess/step we still move down into the execution tree. Now this is is not completely clear to me but it seems that we continue going down in the exec tree until the "final_step(s)" where we get out of all the nestings, in a rather similary way to what happens in recursive functions. What I was asking myself was: suppose you have a control process, which runs forever without exiting ( continuos monitoring processes may have such requirement ), if we continue indefinitely to walk the tree in the down direction don't we risk to create very deep execution trees, and having "stack" problems? Indeed if I'm not completely wrong is it possible to experience slowings expecially on functions that work on feis since they tend to become (very) long strings of dot separated integers. My idea about the state-transition working mode was to build things such that the "goto" expressions, insead of transferring the control to the next state using the apply method, call the state-transition's reply method and then the dispatch to the next state was performed by the state-transition calling the appy method of the designed next state, but in this case we are doing this at the state-transition context, now within the current state's context. My idea was that such working mecha should keep the exec tree quite flat, or if not, at least his deepness is due only to the process definition schema, not to the workitem process execution "real path". I'm not completely sure than my considerations track an existing problem or instead the Ruote internal working mode already prevents this issue, so I ask as usual... Thanks again Tomaso On Fri, May 9, 2008 at 11:28 AM, John Mettraux <[EMAIL PROTECTED]> wrote: > > On Fri, May 9, 2008 at 4:28 PM, Tomaso Tosolini > <[EMAIL PROTECTED]> wrote: > > On Fri, May 9, 2008 at 3:04 AM, John Mettraux <[EMAIL PROTECTED]> > wrote: > >> > >> ( > http://github.com/jmettraux/ruote/commit/0a3dd6115304a5c57f88323d1c2a2f0051a6feff > ) > >> (branch "step_expression"). > > > > Yes, i saw it: yesterday after posted here i went on github ans saw thay > you > > committed the new branch four minutes before... perhaps this is a new > form > > of workflow mind synchronisation :) > > :) > > > >> In a single stroke, you have a link between a state (a participant > >> pointed at via the "part" parameter subprocess parameter) and a > >> transition (a call to a subprocess whose name is held in the "next" > >> field). > > > > I liked it too, and so i tried to study it quite deeply. I noticed that > in > > the first commit you included the concept of "outcomes", already > described > > in the TTP post. > > Yes, I'd like to constrain the possible outcomes if necessary, as > things in a participant are quite out of control for the engine. > > > >> Another nicety, there is no <if> or <case> implied (that was one of > >> the constraint derived from Keith Swenson BPMN diagram (can't remember > >> if he is the author though)). > > > > Here i was thinking about situations like: > > > > activity1, when complete > > if ${x} >= 15 activity2 > > elsif ${y} == 'W_Ruote' activity3 > > else activity4 > > > > It is possible to gain the same things also in the step based arch, but > > either one has to redesign the step to include the if expression stuff > > or one must have thong hidden within the participant expression: in the > > activity1 the "last" operations should be > > > > if ${x} >= 15 > > set_field :next, "activity2 > > elsif ${y} == 'W_Ruote' > > set_field :next, "activity3 > > else > > set_field :next, "activity4 > > > > There is nothing wrong in this, only that the <on state="..."> [decision] > > </on> mecha seemed a little more expressive to me, expecially when > compared > > to the latter step strategy that hides things in participant "activity". > I'm > > not so sure that the step strategies i described before are the only ones > > possible so please let me know if there are others, i'd like to have a > > comprehensive knowledge about that matter, it is quite important also for > > me.... > > OK, with the "step" expression (as found in the step_expression branch > and not the one in the trouble ticket blog post), you'd rather embed > this branching in an "outcome" subprocess, and have the branches being > call to participants or subprocesses (or steps) directly. > > (with a bit of ${indirection} it could be reused among steps) > > It also gives you the opportunity to write this logic (which can be > tedious) in a Participant (in Ruby). > The participant could also be a call to a thing like a decision > service (a rule engine). > > > > >> I think that my approach is not very verbose and it leverages the > current > >> Ruote. > > > > I agree 100%: your approach has no impact in the current Ruote and brings > > new good functionality. > > > > After reading the last things i start thinking that that step method is > > similar to another design that i considered aside the proposed one: > > > > what changes is that one should put into each state expression the > > instruction about next state(s) selection. > > > > <state name=""> > > <activity_part> > > </activity_part> > > > > <transition_part or "were to go when done"> > > </transition_part> > > </state> > > > > > > I preferred not to choose this because the idea of a complete separation > of > > the states(that resemble the operative nuclei within the process) from > the > > transitions(that are the coordination of the operations) seemed me more > > elegant from a formal point of view and, but i'm not sure about this, > more > > safe when process schema become large. > > Somehow, when an outcome is a subprocess, you get that separation (see > above when discussing hiding an if in a surbprocess). > > > There is an advanced concept in Ruote : the "listen" expression ( > http://openwferu.rubyforge.org/expressions.html#exp_listen ) > > It's used to listen to particpant events, it can listen across process > boundaries. Whereas the "step" expression uses participant names and > subprocesses names as "state name", the "listen" expression just goes > for the participant name (and it's more of an observer). > ( http://jmettraux.wordpress.com/2007/05/29/listen/ ) > > > "step" could represent an easy way for people translating > state-transition representation to Ruote (though it will make my life > harder with ruote-fluo http://github.com/jmettraux/ruote-fluo) > > > Thanks for this excellent thread of discussion. I have to get back to > this "step" and add tests for the outcomes and default concepts. Maybe > you have further suggestions and critique. > > > Best regards, > > -- > John Mettraux - http://jmettraux.wordpress.com > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
