Author: vanto
Date: Fri Nov 23 17:57:59 2012
New Revision: 1413002
URL: http://svn.apache.org/viewvc?rev=1413002&view=rev
Log:
markup fix.
Modified:
ode/site/trunk/content/jacob.mdtext
Modified: ode/site/trunk/content/jacob.mdtext
URL:
http://svn.apache.org/viewvc/ode/site/trunk/content/jacob.mdtext?rev=1413002&r1=1413001&r2=1413002&view=diff
==============================================================================
--- ode/site/trunk/content/jacob.mdtext (original)
+++ ode/site/trunk/content/jacob.mdtext Fri Nov 23 17:57:59 2012
@@ -1,38 +1,39 @@
-Title: Jacob
+Title: JaCOb
+
<a name="Jacob-Introduction"></a>
-### Introduction
+## Introduction
-Ode's BPEL implementation relies on the JACOB framework to implement the BPEL
constructs. The framework provides the mechanism necessary to deal with two key
issues in implementing BPEL constructs:
+ODE's BPEL implementation relies on the JaCOb (Java Concurrent Objects)
framework to implement the BPEL constructs. The framework provides the
mechanism necessary to deal with two key issues in implementing BPEL constructs:
1. Persistence of execution state.
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 the
[#rational](#rational.html) of Jacob and its [#concepts] first. Then we'll
illustrate with one complete [example|#examples]. But if you're a reverse
reader, you can also decide to start with the [example|#example1].
+The approach we'll take in this tutorial is looking at the
[#rational](#rational.html) of JaCOb and its [#concepts] first. Then we'll
illustrate with one complete [example](#examples). But if you're a reverse
reader, you can also decide to start with the [example](#example1).
<a name="Jacob-Rationalebehindthemodel"></a>
-### Rationale behind the model
+## Rationale behind the model
Let's start from the most classical example of all:
-{code:java}
-void process(order) {
- billingService.bill(order.billing);
- shippingService.ship(order.product, order.shipping, self);
- shipping = receive("shipping")
- order.customer.send(shipping.details);
-}
+ :::java
+ void process(order) {
+ billingService.bill(order.billing);
+ shippingService.ship(order.product, order.shipping, self);
+ shipping = receive("shipping")
+ order.customer.send(shipping.details);
+ }
- It's Java like pseudo code that works extremely well, unless:
-
- # You fail somewhere in the middle and the customer has to order a
second time.
- # Your have too many waiting threads and the VM crashes.
-
- So you change it to:
+It's Java like pseudo code that works extremely well, unless:
+
+* You fail somewhere in the middle and the customer has to order a second time.
+* Your have too many waiting threads and the VM crashes.
+
+So you change it to:
- {code:java}
+ :::java
void process(order) {
billingService.bill(order.billing);
shippingService.ship(order.product, order.shipping, self);
@@ -46,34 +47,34 @@ void process(order) {
That's almost better, but still has a lot of points of failure, where you're
not sure if you actually billed the customer and shipped the product or not. So:
-{code:java}
-void process(order) {
- billingService.bill(order.billing);
- continue("part2");
-}
+ :::java
+ void process(order) {
+ billingService.bill(order.billing);
+ continue("part2");
+ }
-void part2() {
- shippingService.ship(order.product, order.shipping, self);
- listenOn("shipping", part2);
-}
+ void part2() {
+ shippingService.ship(order.product, order.shipping, self);
+ listenOn("shipping", part2);
+ }
-void part2(shipping) {
- order.customer.send(shipping.details);
-}
+ void part2(shipping) {
+ order.customer.send(shipping.details);
+ }
-
- You're just fracturing the code with two primitives: _continue_ which lets
you persist state and go to the next one, and _listenOn_ which lets you persist
state and wait for an external event.
-
- Fracturing the code also addresses concurrency of execution even if you
only have one thread. For example you could have a large number of 'process'
calls to bill and ship an order. As we've broken down the whole treatment into
several small parts, we can control when these separate parts actually get
called and executed. And we're free to order them.
-
- Let's say we have a small process doing in a sequence:
+
+You're just fracturing the code with two primitives: *continue* which lets you
persist state and go to the next one, and *listenOn* which lets you persist
state and wait for an external event.
+
+Fracturing the code also addresses concurrency of execution even if you only
have one thread. For example you could have a large number of 'process' calls
to bill and ship an order. As we've broken down the whole treatment into
several small parts, we can control when these separate parts actually get
called and executed. And we're free to order them.
+
+Let's say we have a small process doing in a sequence:
1. Invoke
2. Receive
3. Wait
4. Invoke
- If we have 2 parrallel executions of this process and implement it in a
simple way we'd have:
+If we have 2 parrallel executions of this process and implement it in a simple
way we'd have:
1. Invoke1
2. Receive1
@@ -84,7 +85,7 @@ void part2(shipping) {
7. Wait2
8. Invoke2
- However if we break down the code as shown above by introducing a "middle
man" (or stack) and do not allow activities to directly call each other (or do
not have the activity directly calling the sequence that directly calls the
next activity) we could well obtain the following:
+However if we break down the code as shown above by introducing a "middle man"
(or stack) and do not allow activities to directly call each other (or do not
have the activity directly calling the sequence that directly calls the next
activity) we could well obtain the following:
1. Invoke1
5. Invoke2
@@ -95,15 +96,15 @@ void part2(shipping) {
4. Invoke1
8. Invoke2
- From a client standpoint, we've achieved concurrency of execution even
with one thread.
-
- Next step is adding links, fault handling/termination, compensation and
event handlers and seeing that continue/listenOn is all you need. The last step
is just adding implementation details.
+From a client standpoint, we've achieved concurrency of execution even with
one thread.
+
+Next step is adding links, fault handling/termination, compensation and event
handlers and seeing that continue/listenOn is all you need. The last step is
just adding implementation details.
- h3. Jacob Example
+## JaCOb Example
- Consider the issue of persistence. Imagine a simplified and naive
implementation of the BPEL constructs <sequence>, <wait>, and <empty>:
+Consider the issue of persistence. Imagine a simplified and naive
implementation of the BPEL constructs ```<sequence>```, ```<wait>```, and
```<empty>```:
- {code:java}
+ :::java
class Sequence extends Activity {
/** From BPEL Definition */
OSequence def;
@@ -133,19 +134,18 @@ void part2(shipping) {
}
-The above is the "natural" implementation of the constructs in the Java
language. However, this implementation has some serious and obvious problems:
the <wait> may specify a duration of days in which case a system failure during
those days of waiting would mean that the process execution state would be
lost. It would be nice to replace Thread.wait() in the Wait class with some
sort of "suspend" operator that would save the execution state to disk.
+The above is the "natural" implementation of the constructs in the Java
language. However, this implementation has some serious and obvious problems:
the ```<wait>``` may specify a duration of days in which case a system failure
during those days of waiting would mean that the process execution state would
be lost. It would be nice to replace Thread.wait() in the Wait class with some
sort of "suspend" operator that would save the execution state to disk.
However there are practical issues to "suspending" to disk. At the point we
wish to suspend, the call stack looks like:
-{code:java}
-Sequence.run()
-Wait.run()
+ :::java
+ Sequence.run()
+ Wait.run()
+In order to save the process to disk, we need to end the current thread of
control which means popping both stack frames. To do this we have no choice but
to require the implementation of Wait and Sequence to "cooperate" with this
requirement thereby greatly complicating the implementation of those
constructs. This also means that the "natural" implementation model cannot be
used directly.
- In order to save the process to disk, we need to end the current thread of
control which means popping both stack frames. To do this we have no choice but
to require the implementation of Wait and Sequence to "cooperate" with this
requirement thereby greatly complicating the implementation of those
constructs. This also means that the "natural" implementation model cannot be
used directly.
-
- JACOB aims to solve this problem by providing an alternate "natural" model
that allows execution state to be suspended ''without cooperation from the
implementation classes''. The idea in JACOB is to flatten the call stack and
rely on explicit communication channels to handle control flow. We now consider
a simplified JACOB representation of our three BPEL activities:
+JaCOb aims to solve this problem by providing an alternate "natural" model
that allows execution state to be suspended ''without cooperation from the
implementation classes''. The idea in JaCOb is to flatten the call stack and
rely on explicit communication channels to handle control flow. We now consider
a simplified JaCOb representation of our three BPEL activities:
- {code:java}
+ :::java
class Empty {
OEmpty def;
@@ -230,37 +230,37 @@ Wait.run()
}
-So Jacob constructs help us in breaking the execution stack.
+So JaCOb constructs help us in breaking the execution stack.
<a name="Jacob-MainJacobConcepts="></a>
-### Main Jacob Concepts =
+## Main JaCOb Concepts =
<a name="Jacob-Channels"></a>
-#### Channels
+### Channels
As briefly demonstrated above, channels are interfaces used for communication
between activities in ODE engine. There are several types of channels like
TerminationChannel, ParentScopeChannel or CompensationChannel (their respective
purpose should be obvious from their name). Some basic channels are provided to
all activities when they're created to allow them to interact with their
environment. When an activity wants to notifies its parent that it has
terminated for example, it just calls its parent TerminationChannel (see the
Empty example above).
-Don't look for channels implementations because there are none. Channels
implementation is provided through a dynamic proxy (see
[ChannelFactory](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/ChannelFactory.java).createChannel()
and
[ChannelFactory](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/ChannelFactory.java).ChannelInvocationHandler
for more). That's one of the levels of decoupling between invocation and
actual execution in Jacob.
+Don't look for channels implementations because there are none. Channels
implementation is provided through a dynamic proxy (see
[ChannelFactory](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/ChannelFactory.java).createChannel()
and
[ChannelFactory](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/ChannelFactory.java).ChannelInvocationHandler
for more). That's one of the levels of decoupling between invocation and
actual execution in JaCOb.
<a name="Jacob-JacobObject/JacobRunnable"></a>
-#### JacobObject / JacobRunnable
+### JacobObject / JacobRunnable
-If you don't care much about the details, the bottom line is: a
[JacobObject](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobObject.java)
and an
[JacobRunnable|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobRunnable.java]
are just a method implementation. This method gets executed when the
abstraction is executed.
+If you don't care much about the details, the bottom line is: a
[JacobObject](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobObject.java)
and an
[JacobRunnable](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobRunnable.java)
are just a method implementation. This method gets executed when the
abstraction is executed.
-A JacobObject is meant to be a closure. From Wikipedia: "A closure combines
the code of a function with a special lexical environment bound to that
function (scope). Closure lexical variables differ from global variables in
that they do not occupy the global variable namespace. They differ from object
oriented object variables in that they are bound to functions, not objects.".
Normally closures aren't supported in Java so
[JacobObject](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobObject.java)
tries to feel that gap. But it's not a true closure anyway, which makes thing
easier. Closures in Jacob are statically coded, whereas in most languages
supporting closures these are dynamic. So basically in Jacob, a closure is
expected to implement some methods and provides other utility methods to
manipulate channels and replicate itself.
+A JacobObject is meant to be a closure. From Wikipedia: "A closure combines
the code of a function with a special lexical environment bound to that
function (scope). Closure lexical variables differ from global variables in
that they do not occupy the global variable namespace. They differ from object
oriented object variables in that they are bound to functions, not objects.".
Normally closures aren't supported in Java so
[JacobObject](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobObject.java)
tries to feel that gap. But it's not a true closure anyway, which makes thing
easier. Closures in JaCOb are statically coded, whereas in most languages
supporting closures these are dynamic. So basically in JaCOb, a closure is
expected to implement some methods and provides other utility methods to
manipulate channels and replicate itself.
[JacobRunnable](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobRunnable.java)
is just a JacobObject that requires the implementation of only one method:
run(). As ''all activities inherit from
[JacobRunnable](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/JacobRunnable.java)
they're all supposed to implement their main processing in this run() method.
Their initialization occur in their respective constructors.
<a name="Jacob-MethodLists(MLs)"></a>
-#### Method Lists (MLs)
+### Method Lists (MLs)
-ML classes can be seen as the other end of a channel. Only they're not invoked
directly when one calls a channel method, but only once the Jacob engine has
popped the channel invocation from its internal stack (again you can see how
the execution stack gets broken here).
+ML classes can be seen as the other end of a channel. Only they're not invoked
directly when one calls a channel method, but only once the JaCOb engine has
popped the channel invocation from its internal stack (again you can see how
the execution stack gets broken here).
Usually MLs implementations in ODE are inlined because it's just easier to
declare them in the activities run() method. For example if you look at the
Sequence example shown above you'll see something like:
-{code:java}
+ :::java
void run() {
- ...
+ ...
// create an object to wait for the "completed()" notification
// from the child activity.
object(new CompletionChannelML(childCompletionChannel)) {
@@ -274,38 +274,37 @@ Usually MLs implementations in ODE are i
}
- The object method here is inherited from !JacobObject and is just a way to
hand our ML to Jacob. So that the Jacob runtime can match it with an incoming
channel message later on.
+The object method here is inherited from !JacobObject and is just a way to
hand our ML to JaCOb. So that the JaCOb runtime can match it with an incoming
channel message later on.
- h4. VPU and ExecutionQueue
+## VPU and ExecutionQueue
- The
[VPU|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/JacobVPU.java]
is where all the Jacob processing is occuring. When a JacobObject is injected
inside the VPU, it's actually registered as a
[Continuation|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/soup/Continuation.java],
which is just wrapping the JacobObject with the method to call on the
JacobObject to execute it (in our case always the run() method as we're only
dealing with JacobRunnable instances).
-
- The
[ExecutionQueue|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/soup/ExecutionQueue.java]
(and its implementation
[FastExecutionQueueImpl|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/FastExecutionQueueImpl.java])
is just a container for all the artifacts managed by the VPU (mostly channels
and reactions) to organize them in queues where artifacts can be pushed and
popped. It also records some execution statistics.
-
- So the VPU main processing is just dequeuing a reaction from the soup and
executing it by calling its abstraction's run() method (remember that the
reaction just wraps an abstraction). That's all (check
[JacobVPU|http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/JacobVPU.java].execute(),
you'll see that I'm not lying). However when the JacobRunnable (usually an
activity) gets executed the following things can happen:
-
- * if other abstractions (usually other activities) are created, they will
be appended to the reaction queue,
- * if new channels are created, they will be saved for later usage,
- * 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](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/JacobVPU.java)
is where all the JaCOb processing is occuring. When a JacobObject is injected
inside the VPU, it's actually registered as a
[Continuation](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/soup/Continuation.java),
which is just wrapping the JacobObject with the method to call on the
JacobObject to execute it (in our case always the run() method as we're only
dealing with JacobRunnable instances).
+
+The
[ExecutionQueue](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/soup/ExecutionQueue.java)
(and its implementation
[FastExecutionQueueImpl](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/FastExecutionQueueImpl.java))
is just a container for all the artifacts managed by the VPU (mostly channels
and reactions) to organize them in queues where artifacts can be pushed and
popped. It also records some execution statistics.
+
+So the VPU main processing is just dequeuing a reaction from the soup and
executing it by calling its abstraction's run() method (remember that the
reaction just wraps an abstraction). That's all (check
[JacobVPU](http://svn.apache.org/repos/asf/ode/trunk/jacob/src/main/java/org/apache/ode/jacob/vpu/JacobVPU.java).execute(),
you'll see that I'm not lying). However when the JacobRunnable (usually an
activity) gets executed the following things can happen:
- 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
[RuntimeContextImpl|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/RuntimeContextImpl].execute().
+* if other abstractions (usually other activities) are created, they will be
appended to the reaction queue,
+* if new channels are created, they will be saved for later usage,
+* 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.
- There's one more thing that should be mentioned here. Continuations (and
hence JacobRunnables) 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:
+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
[RuntimeContextImpl](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/RuntimeContextImpl).execute().
- {code:java}
- instance(new SequenceChildRunner(currentChild+1));
+There's one more thing that should be mentioned here. Continuations (and hence
JacobRunnables) 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
+ instance(new SequenceChildRunner(currentChild+1));
-This simple adds a new !ChildRunner that will monitor the next child
completion. If you browse ODE's activities code you will even find things like
instance(this) which directly enqueues a new instance of the same Jacob
abstraction.
+This simple adds a new !ChildRunner that will monitor the next child
completion. If you browse ODE's activities code you will even find things like
instance(this) which directly enqueues a new instance of the same JaCOb
abstraction.
<a name="Jacob-Walkingthroughexamples"></a>
-### Walking through examples
+## Walking through examples
<a name="Jacob-While"></a>
-#### While
-
+### While
+ :::xml
<process name="while1"
targetNamespace="http://ode/bpel/unit-test";
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/";
@@ -348,19 +347,18 @@ This simple adds a new !ChildRunner that
</sequence>
</process>
+Everything starts with a receive. So our entry point here in our JaCOb-focused
discussion is going to be
[BpelProcess](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/BpelProcess.java).PartnerLinkMyRoleImpl.inputMsgRcvd().
The code that matters to us now is the following (executed when a message is
targeted at a createInstance receive):
-Everything starts with a receive. So our entry point here in our Jacob-focused
discussion is going to be
[BpelProcess](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/BpelProcess.java).PartnerLinkMyRoleImpl.inputMsgRcvd().
The code that matters to us now is the following (executed when a message is
targeted at a createInstance receive):
-
-{code:java}
-BpelRuntimeContextImpl instance = createRuntimeContext(newInstance, new
PROCESS(_oprocess), messageExchange);
-...
+ :::java
+ BpelRuntimeContextImpl instance = createRuntimeContext(newInstance, new
PROCESS(_oprocess), messageExchange);
+ ...
// run the vpu
instance.execute();
- If you check the code executed by !BpelRuntimeContextImpl constructor
you'll see among other things the following:
+If you check the code executed by !BpelRuntimeContextImpl constructor you'll
see among other things the following:
- {code:java}
+ :::java
if (PROCESS != null) {
vpu.inject(PROCESS);
}
@@ -368,23 +366,22 @@ BpelRuntimeContextImpl instance = create
The process itself get injected. When executed,
[PROCESS](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PROCESS.java)
just instantiates a scope to control the execution of its child activity and
starts listening on compensation and completion channel. From the process we go
to a scope, then our main sequence and finally our receive.
-Receives are just mapped to a pick onMessage so its Jacob implementation
should be looked for in
[PICK](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PICK.java).
The
[PICK](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PICK.java)
is just about isolating the right correlations and selecting a message for it,
then waiting for the message. In our createInstance case we'll be more
interested in the following code, located in
[BpelRuntimeContextImpl|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/BpelRuntimeContextImpl.java].select()
(and called by PICK):
+Receives are just mapped to a pick onMessage so its JaCOb implementation
should be looked for in
[PICK](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PICK.java).
The
[PICK](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PICK.java)
is just about isolating the right correlations and selecting a message for it,
then waiting for the message. In our createInstance case we'll be more
interested in the following code, located in
[BpelRuntimeContextImpl](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/BpelRuntimeContextImpl.java).select()
(and called by PICK):
-{code:java}
-if (_instantiatingMessageExchange != null && _dao.getState() ==
ProcessState.STATE_READY) {
- for (int i = 0 ; i < correlators.size(); ++i) {
- CorrelatorDAO ci = correlators.get(i);
- if (ci.equals(_dao.getInstantiatingCorrelator())) {
- inputMsgMatch(pickResponseChannelStr, i, _instantiatingMessageExchange);
- return;
- }
- }
-}
+ :::java
+ if (_instantiatingMessageExchange != null && _dao.getState() ==
ProcessState.STATE_READY) {
+ for (int i = 0 ; i < correlators.size(); ++i) {
+ CorrelatorDAO ci = correlators.get(i);
+ if (ci.equals(_dao.getInstantiatingCorrelator())) {
+ inputMsgMatch(pickResponseChannelStr, i,
_instantiatingMessageExchange);
+ return;
+ }
+ }
+ }
+Which just happens to call something like:
- Which just happens to call something like:
-
- {code:java}
+ :::java
vpu.inject(new JacobRunnable() {
public void run() {
PickResponseChannel responseChannel = importChannel(responsechannel,
PickResponseChannel.class);
@@ -395,60 +392,57 @@ if (_instantiatingMessageExchange != nul
That's where things really start. When injected, this abstraction just calls
the response channel for our receive. The other side of this channel is
implemented as a ML in the
[PICK](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/PICK.java):
-{code:java}
-object(false, new PickResponseML(_pickResponseChannel) {
- public void onRequestRcvd(int selectorIdx, Object msgex) {
- ...
- ActivityInfo child = new ActivityInfo(genMonotonic(),
onMessage.activity, _self.self, _self.parent);
- instance(createChild(child,_scopeFrame,_linkFrame));
- }
-});
+ :::java
+ object(false, new PickResponseML(_pickResponseChannel) {
+ public void onRequestRcvd(int selectorIdx, Object msgex) {
+ ...
+ ActivityInfo child = new ActivityInfo(genMonotonic(),
onMessage.activity, _self.self, _self.parent);
+ instance(createChild(child,_scopeFrame,_linkFrame));
+ }
+ });
+This method just does what a receive needs to do (like variable and
correlation initialization) and creates a new child. When dealing with a real
pick, this child would be the onMessage activity, however in the case of a
receive, this is an empty activity. So when does our receive completes? Well,
when the child completes. As you can see on the child constructor, we're
passing the same ParentScopeML that we've been provided. So when the child
completes, the receive's parent is notified which means to our receive doesn't
need to do it itself. And an empty immediately completes:
- This method just does what a receive needs to do (like variable and
correlation initialization) and creates a new child. When dealing with a real
pick, this child would be the onMessage activity, however in the case of a
receive, this is an empty activity. So when does our receive completes? Well,
when the child completes. As you can see on the child constructor, we're
passing the same ParentScopeML that we've been provided. So when the child
completes, the receive's parent is notified which means to our receive doesn't
need to do it itself. And an empty immediately completes:
-
- {code:java}
+ :::java
_self.parent.completed(null, CompensationHandler.emptySet());
-
The parent sequence gets notified almost immediately after the onRequestRcvd()
methods finishes.
Now how does our sequence gets the control back? Well, once again, let's look
at the ML, the other side of the channel. As one of the most important job of
the VPU is matching channels invocations and MLs, we'll get to the
[sequence](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/SEQUENCE.java)
by its ParentScopeML implementation:
-{code:java}
-class SEQUENCE extends ACTIVITY {
- ...
- private class ACTIVE extends BpelJacobRunnable {
- ....
- public void run() {
+ :::java
+ class SEQUENCE extends ACTIVITY {
...
- object(new ParentScopeML(_child.parent) {
- public void compensate(OScope scope, SynchChannel ret) {
- _self.parent.compensate(scope,ret);
- instance(ACTIVE.this);
- }
+ private class ACTIVE extends BpelJacobRunnable {
+ ....
+ public void run() {
+ ...
+ object(new ParentScopeML(_child.parent) {
+ public void compensate(OScope scope, SynchChannel ret) {
+ _self.parent.compensate(scope,ret);
+ instance(ACTIVE.this);
+ }
- public void completed(FaultData faultData, Set<CompensationHandler>
compensations) {
- HashSet<CompensationHandler> comps = new
HashSet<CompensationHandler>(_compensations);
- comps.addAll(compensations);
- if (faultData != null || _terminateRequested || _remaining.size() <=
1) {
- _self.parent.completed(faultData, comps);
- } else /* !fault && ! terminateRequested && !remaining.isEmpty */ {
- ArrayList<OActivity> remaining = new
ArrayList<OActivity>(_remaining);
- remaining.remove(0);
- instance(new SEQUENCE(_self, _scopeFrame, _linkFrame, remaining,
comps));
- }
+ public void completed(FaultData faultData,
Set<CompensationHandler> compensations) {
+ HashSet<CompensationHandler> comps = new
HashSet<CompensationHandler>(_compensations);
+ comps.addAll(compensations);
+ if (faultData != null || _terminateRequested ||
_remaining.size() <= 1) {
+ _self.parent.completed(faultData, comps);
+ } else /* !fault && ! terminateRequested && !remaining.isEmpty
*/ {
+ ArrayList<OActivity> remaining = new
ArrayList<OActivity>(_remaining);
+ remaining.remove(0);
+ instance(new SEQUENCE(_self, _scopeFrame, _linkFrame,
remaining, comps));
+ }
+ }
+ }));
}
- }));
+ }
+ ...
}
- }
- ...
-}
+The method that will get executed is of course the completed() method. It
simply completes if a fault has been thrown, a termination has been requested
and if no child activities remain. Being of an optimistic nature, we'll check
what happens when everything goes just fine. In this second case a remaining
activity is removed and the
[SEQUENCE](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/SEQUENCE.java)
abstraction itself is reinstantiated. Which leads us to what the
[SEQUENCE](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/SEQUENCE.java)
does:
- The method that will get executed is of course the completed() method. It
simply completes if a fault has been thrown, a termination has been requested
and if no child activities remain. Being of an optimistic nature, we'll check
what happens when everything goes just fine. In this second case a remaining
activity is removed and the
[SEQUENCE|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/SEQUENCE.java]
abstraction itself is reinstantiated. Which leads us to what the
[SEQUENCE|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/SEQUENCE.java]
does:
-
- {code:java}
+ :::java
public void run() {
final ActivityInfo child = new ActivityInfo(genMonotonic(),
_remaining.get(0),
@@ -462,60 +456,60 @@ As you can see, it just instantiates the
Continuing to the next step, we've just instantiated an abstraction for the
[while](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/WHILE.java)
in our example process, as it's the next child of the sequence. So what
happens there?
-{code:java}
- public void run() {
- boolean condResult = false;
- try {
- condResult = checkCondition();
- } catch (FaultException fe) {
- _self.parent.completed(createFault(fe.getQName(),
_self.o),_compHandlers);
- return;
- }
- if (condResult) {
- ActivityInfo child = new ActivityInfo(genMonotonic(),
- getOWhile().activity,
- newChannel(TerminationChannel.class),
newChannel(ParentScopeChannel.class));
- instance(createChild(child, _scopeFrame, _linkFrame));
- instance(new WAITER(child));
- } else /* stop. */ {
- _self.parent.completed(null, _compHandlers);
+ :::java
+ public void run() {
+ boolean condResult = false;
+ try {
+ condResult = checkCondition();
+ } catch (FaultException fe) {
+ _self.parent.completed(createFault(fe.getQName(),
_self.o),_compHandlers);
+ return;
+ }
+ if (condResult) {
+ ActivityInfo child = new ActivityInfo(genMonotonic(),
+ getOWhile().activity,
+ newChannel(TerminationChannel.class),
newChannel(ParentScopeChannel.class));
+ instance(createChild(child, _scopeFrame, _linkFrame));
+ instance(new WAITER(child));
+ } else /* stop. */ {
+ _self.parent.completed(null, _compHandlers);
+ }
}
- }
- Now you should be getting more familiar with that sort of code. First step
is evaluating the
[while|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/WHILE.java]
condition. If it turns out it's true, then a child abstraction gets created as
well as a WAITER to follow its execution. The WAITER implementation is again
pretty straightforward:
+Now you should be getting more familiar with that sort of code. First step is
evaluating the
[while](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/WHILE.java)
condition. If it turns out it's true, then a child abstraction gets created as
well as a WAITER to follow its execution. The WAITER implementation is again
pretty straightforward:
- {code:java}
- private class WAITER extends BpelJacobRunnable {
+ :::java
+ private class WAITER extends BpelJacobRunnable {
private ActivityInfo _child;
private boolean _terminated;
WAITER(ActivityInfo child) {
- _child = child;
+ _child = child;
}
public void run() {
- object(false, new TerminationML(_self.self) {
- public void terminate() {
- _terminated = true;
- _child.self.terminate();
- instance(WAITER.this);
- }
- }.or(new ParentScopeML(_child.parent) {
- public void compensate(OScope scope, SynchChannel ret) {
- _self.parent.compensate(scope,ret);
- instance(WAITER.this);
- }
- public void completed(FaultData faultData,
Set<CompensationHandler> compensations) {
- _compHandlers.addAll(compensations);
- if (_terminated || faultData != null)
- _self.parent.completed(faultData, compensations);
- else
- instance(WHILE.this);
- }
- }));
+ object(false, new TerminationML(_self.self) {
+ public void terminate() {
+ _terminated = true;
+ _child.self.terminate();
+ instance(WAITER.this);
+ }
+ }.or(new ParentScopeML(_child.parent) {
+ public void compensate(OScope scope, SynchChannel ret) {
+ _self.parent.compensate(scope,ret);
+ instance(WAITER.this);
+ }
+ public void completed(FaultData faultData,
Set<CompensationHandler> compensations) {
+ _compHandlers.addAll(compensations);
+ if (_terminated || faultData != null)
+ _self.parent.completed(faultData, compensations);
+ else
+ instance(WHILE.this);
+ }
+ }));
}
- }
+ }
Termination and compensation aren't doing anything really interesting.
Completion, just like for the sequence, re-instantiates the
[WHILE](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/runtime/WHILE.java)
abstraction. And that's how we get our loop, by re-instantiating the main
WHILE abstraction (again evaluating the condition and creating a child if it's
true).
