ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Syntax of links in simPEL
Date Fri, 06 Jun 2008 02:20:23 GMT
On Thu, Jun 5, 2008 at 5:12 PM, Matthieu Riou <matthieu@offthelip.org> wrote:
> On Thu, Jun 5, 2008 at 5:20 AM, Oliver Kopp <
> oliver.kopp@iaas.uni-stuttgart.de> wrote:
>
>> Hi,
>>
>> We have thought about the syntax of links. As we understand, join and
>> signal
>> belong to the previous element.
>>
>> Assume following example:
>>
>> parallel {
>>  a;
>>  b;
>>  signal(b-to-X);
>> } and {
>>  join(b-to-X);
>>  c;
>>  d;
>> } and {
>>  e;
>>  signal(e-to-f);
>>  f;
>>  join(e-to-f);
>> }
>>
>> The link b-to-X connects b and the sequence s2, which contains c and d.
>> The link e-to-f connects e and f in the sequence s3, which contains e and
>> f.
>>
>> The link b-to-X is NOT sourcing from sequence s1, which contains a and d.
>> However, it can be understood like that, because it is the last statement
>> in
>> the sequence.
>>
>> The link b-to-X is NOT targeted at c. However, it can be understood as is,
>> because first links are joined and then an activity is executed. I.e., join
>> on b-to-X and then execute c. - In the above example both interpretations
>> lead to the same execution. But if there is a join condition put on the
>> join(b-to-X), then it is not the same semantics: Assume join(b-to-X,
>> false()), then in the above example, c and d are both not executed, since
>> the join condition of the sequence evaluates to false(). If the other
>> interpretation is assumed, c does not get executed, but d: The sequence is
>> enabled and only c joins on the incoming links.
>>
>
> I'm not sure I'm completely following so please forgive me if I'm off base
> and feel free to correct me. My understanding of what you're saying is that
> the way one could understand the snippet above is not the way it actually
> is. Hence it should be fixed because it's ambiguous. Is that right?
>
> However, when I read your explanation, you're interpreting everything in
> terms of links, sourcing and targeting. What we have here aren't links, we
> have a signal construct and a join construct. Signal says when something is
> done, join says when we should hold until something is done.

What happens if it's not done?  In BPEL link is set to false and the
join condition throws a fault, which would stop the remainder of the
sequence from happening.  So far no difference.

But you can also suppress the fault, so the activity that depends on
something happening is skipped, but the rest of the flow continues.
Now it matters what's being skipped: the entire sequence or just the
first activity in that sequence?

Assaf

> In  that light
> I don't think one would get mislead. So if I just change labels in your
> example:
>
> parallel {
>  put-pizza-in-oven;
>  pizza-cooked;
>  signal(diner-ready);
> } and {
>  join(diner-ready, "beer.temperature < 10c");
>  get-beer-in-fridge;
>  drink-beer;
> }
>
> I won't drink my beer as long as the diner's ready and even when it's ready,
> I still won't drink it if it's not freshed. I don't think one would expect
> drink-beer to execute if both conditions aren't satisfied.
>
> Or did I completely misunderstood what you were saying?
>
>
>> We have following different proposals: The syntax is inspired by LaTeX,
>> where optional arguments can be put in square braces "[...]"; We do not
>> want
>> to use additional curly braces "{...}" to have the links distinguishable of
>> "real" arguments.
>>
>> 1. Proposal: Our favorite. Reflecting the execution order.
>> [join(...)]? activity [signals]?;
>>
>> parallel {
>>  a;
>>  b [signal(b-to-X)];
>> } and [join(b-to-X)] {
>>  c;
>>  d;
>> } and {
>>  e [signal(e-to-f)];
>>  [join(e-to-f)] f;
>> }
>>
>> 2. Proposal: Everything before the activity.
>>
>> [join(...)?, signals?]? activity;
>>
>> parallel {
>>  a;
>>  [signal(b-to-X)] b;
>> } and [join(b-to-X)] {
>>  c;
>>  d;
>> } and {
>>  [signal(e-to-f)] e;
>>  [join(e-to-f)] f;
>> }
>>
>> 3. Proposal: Everything after the activity. (As it is now, but with
>> brackets).
>>
>> Activity [join(...)?, signals?]?;
>>
>> parallel {
>>  a;
>>  b [signal(b-to-X)];
>> } and {
>>  c;
>>  d;
>> } [join(b-to-X)] and {
>>  e [signal(e-to-f)];
>>  f [join(e-to-f)];
>> }
>>
>> What do you think?
>>
>> BTW, could we name simPEL "simBPEL" to enable googling for it? :-) (And
>> doesn't describe sim(B)PEL *B*usiness Processes? :))
>>
>
> Are you afraid of people making too many typos? ;) Actually without writing
> anything about it we're already number 5 on Google so I'm not too worried
> about Googleability (I'm so going to get sued for trademark on this one).
>
> http://www.google.com/search?hl=en&q=simpel&btnG=Google+Search
>
> Matthieu
>
>
>>
>> Cheers,
>>
>> Olly, Tammo
>>
>>
>>
>



-- 
CTO, Intalio
http://www.intalio.com

Mime
View raw message