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