On Thu, Jun 5, 2008 at 7:20 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 5:12 PM, Matthieu Riou <[EMAIL PROTECTED]>
> wrote:
> > On Thu, Jun 5, 2008 at 5:20 AM, Oliver Kopp <
> > [EMAIL PROTECTED]> 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?
>
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.
Matthieu
>
> 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
>
