ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Syntax of links in simPEL
Date Mon, 09 Jun 2008 21:38:55 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!
>

Yes, by design :) We've learned enough from BPEL to know that all constructs
aren't necessarily so great. So if make them more usable, why not? I don't
think we should keep things we know suck.


>
> > 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;
> > }
>
>
> [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?
>

Ah yes, sorry, I wrote that too quickly, ignore the join condition as I
wrote it.


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

Correct.


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

Not really, I try to have in mind a language that would be nice by itself,
regardless of the bytecode in which it's going to be compiled into. While
trying to have the limitations of the bytecode not leak too much in the
language,


>
>
> How are you going to implement joins in Apache ODE? How does that affect
> BPEL processes?
> Is there a different navigation for simPEL processes?
>


Ok, let's see with an example that I hope will be better than the last one:

parrallel {
  a;
  if (...) {
    signal(first);
  } else {
    signal(second);
  }
} and {
  c;
  join(first);
  d;
} and {
  join(second);
  e;
} and {
  join(first, second, "$first or $second");
  f;
} and {
  join(first, second, "$first and $second");
  g;
}

When reading this code, what I expect is the following:

   - a and c will always get executed
   - if the test gets into the first signal, d and f will be executed, e
   won't
   - if the test gets into the second signal, e and f will be executed, d
   won't
   - g will never get executed (with a smart enough compiler, the whole
   branch could even be removed)

The next step is to see which BPEL translation will comply with those
expectations. I think this one would work:

<flow>
  <links>
    <link name="first"/>
    <link name="second"/>
  </links>
  <sequence>
    <a/>
    <if>
      <condition>...</condition>
      <empty>
        <sources><source linkName="first"/></sources>
      </empty>
      <else>
        <empty>
          <sources><source linkName="second"/></sources>
        </empty>
      </else>
    </if>
  </sequence>

  <scope>
    <faultHandlers>
      <catch faultName="bpel:joinFailure"><empty/></catch>
    </faultHandlers>
    <sequence>
      <c/>
      <empty>
        <targets><target linkName="first"/></targets>
      </empty>
      <d/>
    </sequence>
  </scope>

  <scope>
    <faultHandlers>
      <catch faultName="bpel:joinFailure"><empty/></catch>
    </faultHandlers>
    <sequence>
      <empty>
        <targets><target linkName="second"/></targets>
      </empty>
      <e/>
    </sequence>
  </scope>

  <scope>
    <faultHandlers>
      <catch faultName="bpel:joinFailure"><empty/></catch>
    </faultHandlers>
    <sequence>
      <empty>
        <joinCondition>$first or $second</joinCondition>
        <targets><target linkName="first"/></targets>
        <targets><target linkName="second"/></targets>
      </empty>
      <f/>
    </sequence>
  </scope>

  <scope>
    <faultHandlers>
      <catch faultName="bpel:joinFailure"><empty/></catch>
    </faultHandlers>
    <sequence>
      <empty>
        <joinCondition>$first and $second</joinCondition>
        <targets><target linkName="first"/></targets>
        <targets><target linkName="second"/></targets>
      </empty>
      <g/>
    </sequence>
  </scope>
</flow>

I hope I haven't done too many mistakes, it's hard to get a long BPEL
fragment right :) Note that this is kind of the brute force approach, some
of the branches could be optimized by a smarter compiler to use
suppressJoinFailure instead of catching. There are also cases where the
links source and target could be carried by the preceding, following or
parent activity instead of creating an empty.

Cheers,
Matthieu


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message