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
-~----------~----~----~----~------~----~------~--~---
