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 Sat, 07 Jun 2008 17:33:39 GMT
On Sat, Jun 7, 2008 at 5:12 AM, Oliver Kopp
<oliver.kopp@iaas.uni-stuttgart.de> wrote:
> Hi Matthieu,
>> 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.
> Yes, true.
>> Hence it should be fixed because it's ambiguous. Is that right?
> Yes, that's 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.
> With the same semantics. Only different names.
> --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.  Having an expression that combines both, and handling the
link and variable parts separately in the engine, is also possible.

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

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.

So I'm wondering what part of this is different semantics and what
part is just syntactic sugar.


> [quoting from your other mail]
>> And if I think in terms of signal and join, it only really makes sense
>> if the entire sequence is skipped. And that's what people are used to
>> in most imperative languages (somewhat like a specialized break).
>> Now for the implementation in BPEL (our poor man's bytecode), I can
>> think of a few ways to encode that behavior.
> How does your example translate to BPEL? And how are you thinking of a
> mapping from BPEL to simPEL?

> I assume the following: (shortened syntax)
> <flow>
>  <links>l1</links>
>  <sequence>
>    put-pizza-in-oven;
>    pizza-cooked <sources>diner-ready-to-consumption</sources>;
>  </sequence>
>  <sequence>
>    <targets>diner-ready-to-consumption</targets>
>    <repeatUntil>
>      Determine-beer.temperature;
>      <condition>beer.temperature < 10c</condition>
>    </repeatUntil>
>    get-beer-in-fridge;
>    drink-beer;
>  </sequence>
> </flow>
> I could not use a join conditions, since BPEL only allows links as the only
> variables in join conditions.
> --cut--
> [SA00073] The expression for a join condition MUST be constructed using only
> Boolean operators and the activity's incoming links' status values.
> --end--
> If BPEL had to support that, another expression language for the join
> condition has to be used. Even though, that is still a violation of SA00073.
> Even BPEL-J does not allow one to put arbitrary Java-code in the join
> condition:
> --cut--
> BPEL only allows the XPath expressions that are within join conditions to
> access link status.
> The XPath cannot access BPEL variables or any other aspect of the process
> state. The same
> restriction applies to snippets used within join conditions. The snippets
> expressions can only
> access the Boolean parameters that represent the status of incoming links.
> ---end--
>> 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.
> That means, your process is stalled as long as the beer isn't cold enough.
> That's OK for your example, but it is not in-line with BPEL
> dead-path-elimination (DPE) semantics. In contrast to your intended join
> semantics, a join in BPEL is evaluated as soon as the status of the incoming
> links is clear. If the join evaluates to false, the activity is skipped
> (suppressJoinFailure=true). If one does NOT want the activity to be skipped,
> but a fault to be thrown, suppressJoinFailure has to be set to "false".
> I think, you are aware of that. For those, who read my E-Mail to here and
> want to read more on DPE:
> Curbera, Francisco; Khalaf, Rania; Leymann, Frank; Weerawarana, Sanjiva:
> Exception Handling in the BPEL4WS Language. In: BPM 2003
> http://www.springerlink.com/content/yhjyaccdf9g4e0q3/
>> Or did I completely misunderstood what you were saying?
> We have to runtime semantics in mind:
> I have pure BPEL semantics in mind. And I assume, you have some
> BPMN-semantics in mind.
> How are you going to implement joins in Apache ODE? How does that affect
> BPEL processes?
> Is there a different navigation for simPEL processes?
>> Are you afraid of people making too many typos? ;)
> Ah, you're right :)
>> Actually without
>> writing anything about it we're already number 5 on Google
> Yesterday, I got the same result. Today it was not on the first hundred
> results. Maybe I did a typo? ;)
> Maybe, "simBPEL" is the language to use for BPEL semantics and "simPEL" is
> the language for "enhanced" joins and different execution semantics. :-))
> Cheers,
> Olly

View raw message