Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ode Wiki" for change notification.
The following page has been changed by MatthieuRiou: http://wiki.apache.org/ode/Jacob ------------------------------------------------------------------------------ 1. Concurrency. By rolling up these concerns in the framework, the implementation of the BPEL constructs can be simpler by limiting itself to implementing the BPEL logic and not the infrastructure necessary to support it. + + The approach we'll take in this tutorial is looking at examples first, then we'll explain the different concepts and the rational behind those. But feel free to jump to the [#rational] or [#concept] sections directly if you rather read the other way around. = Walking through examples = @@ -231, +233 @@ Finally, when the while condition becomes false, it notifies its parent channel. The sequence then goes to our last activity: reply. As expected, the reply replies, just sending the variable content and notifying its parent for completion. The sequence has no more children to execute so it also notifies its own parent, which is the process. We then just declare the process to be completed and that's it! We're done! = Rationale behind the model = + [[Anchor(rational)]] Let's start from the most classical example of all: @@ -453, +456 @@ So Jacob constructs help us in breaking the execution stack. = Main Jacob Concepts = + [[Anchor(concepts)]] == Channels == @@ -505, +509 @@ * if channels are invoked, the message will be saved to match against a new ML, * if a new ML instance is created, it will be submitted to the VPU that will try to match it against a channel invocation. + The VPU is also responsible for persisting its internal state. So when an execution stops (for example our process has reach a receive) the VPU state is serialized and saved for later reuse. This logic can be seen in [http://svn.apache.org/repos/asf/incubator/ode/scratch/pxe/bpel-runtime/src/main/java/com/fs/pxe/bpel/runtime/RuntimeContextImpl RuntimeContextImpl].execute(). + There's one more thing that should be mentioned here. Reactions (and hence Abstractions) don't "stay" in the VPU queues. They just get popped, executed and that's it. So if an abstraction must last more than one execution, it should simply fork itself. This explains why in our Sequence example already pasted above we see the line: {{{#!java
