Hi Assaf,
>> --cut: http://ode.apache.org/bpel-simplified-syntax-simbpel.html---
>> The signal and join instructions are here to model links,
>> --end--
>>> Signal says when something is done, join says when we should hold
>>> until something is done.
>> This is a semantics different from BPEL!
>>> 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;
>>> }
>
> That depends no what the semantics of the beer (or was it speech?)
> condition is. In terms of blocking, DPEs, etc, there's added
> complexity in handling anything but boolean join expressions. Joining
> only when the beer gets cold is a tricky proposition.
>
> But joining when dinner is ready, and then reading the variable and
> deciding what to do next, that's easy. BPEL can do that, but in BPEL
> you'll have, in addition to the join condition, also an if/else
> statement.
What is put in the else statement?
With your reading, the BPEL code of the second sequence of statements in the
above example is
<sequence>
<if>
<targets>diner-ready</targets>
<condition> beer.temperature < 10c </condition>
get-beer-in-fridge;
</if>
drink-beer;
</sequence>
And if that is translated to simPEL (and no pattern-recognition-magic is
done), it looks like follows:
join(diner-ready);
if (beer.temperature < 10c) {
get-beer-in-fridge;
}
drink-beer;
Or did I get something wrong?
One implication is that the signal statement is bound to the activity before
and join to the activity after.
E.g.:
parallel {
a;
signal(l1);
b;
join(l1);
c;
}
translates to:
<flow>
<sequence>
<a>
<sources>l1</sources>
</a>
<b>
<c>
<targets>l1</targets>
</c>
</sequence>
</flow>
> The point of Simpel is to make it easier to write processes. If we
> insist on one-to-one mapping to BPEL syntax, we're limiting how well it
> can do that, we should be open to syntactic sugars and other
> simplifications.
Syntactic sugar is fine with me. As long as it can be translated to BPEL :).
And that BPEL can be fully translated to simPEL.
I'm currently thinking of simPEL profiles. Such as "strict" and "lax":
"strict" insits on a (close) 1:1 mapping to BPEL. "lax" allows all
simplifications... (which may generate a bunch of activities / eventhandlers
/ ... in a mapping to BPEL)
> So whenever I look at an example like this, my first question is:
> would anyone want to do that often enough that it should be considered
> into the syntax? If not, we have better things to worry about.
>
> If yes, are we taking existing BPEL semantics and applying them in
> more interesting ways, or inventing new semantics? Inventing new
> semantics has the downside that it takes considerable time, and could
> easily confuse people moving between the two languages. Doing
> syntactic sugar on top of existing semantics, not that hard.
Fully agree.
> So I'm wondering what part of this is different semantics and what
> part is just syntactic sugar.
Me too. - I think, it depends on whether the usage of arbitrary variables in
join conditions have blocking semantics (as in WS-CDL a blocking workunit)
or not (as the translation to <if> suggests).
Cheers,
Olly
