Hi Matthieu,
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
On Sat, Jun 7, 2008 at 5:12 AM, Oliver Kopp
[EMAIL PROTECTED] 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
Hi Alex,
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.
Is it fair to say that signal() is like a BPEL empty with a target,
and join() is like an
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
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
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
On Thu, Jun 5, 2008 at 5:12 PM, Matthieu Riou [EMAIL PROTECTED]
wrote:
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.
Is it fair to say that
