Hi guys,
A little heads up on what I (try to) work on, starting with a short recap
(for eventual newcomers).
We've had a pending issue in our trunk that has made us unavailable to
release (outside of the 1.X branch) because it basically breaks backward
compatibility for running instances and compiled process format. So if we
released what we have right now, people would basically have 2 problems:
* They would have to recompile all their redeployed process definitions (a
bit annoying)
* They would have to delete all their running instances and restart them
(definitely annoying for long running instances).
The origin of the break in this case is the introduction of atomic scopes
[1] to add support for transactions. This change impacted runtime classes
that are part of every instance state and the compiled process definition.
The change itself is not necessarily relevant though, I'm just using it to
illustrate the fact that any significant runtime change will expose us to
backward compatibility headaches (simpel, *cough*) if we don't change things
a bit.
So what I'm doing (continuing a work started by Maciej) is adding support
for several parallel versions of the core runtime (not everything, just the
things that get in the state). We would have a runtime core v1 (should be
extracted from the 1.X branch), a v2 (the current trunk) and more coming,
all of those able to run in parallel depending on which version the process
has been deployed on. Something like:
runtime-repo/src/main/java/org/apache/ode/bpel/rtrep/v1/{ASSIGN,INVOKE,OAssign,OInvoke,...}.java
runtime-repo/src/main/java/org/apache/ode/bpel/rtrep/v2/{ASSIGN,INVOKE,OAssign,OInvoke,...}.java
runtime-repo/src/main/java/org/apache/ode/bpel/rtrep/v3/{ASSIGN,INVOKE,OAssign,OInvoke,...}.java
In the future, if we have a modification that's susceptible of changing the
persisted runtime state, we will just roll a new version of those core
runtime classes.
Practically what this means is introducing a new set of interfaces as a
contract between the transient part of the runtime and the rest. Engine on
one side, runtime and OModel on the other. In terms of modules, the impact
is mostly going to be localized in bpel-runtime, bpel-obj and bpel-compiler
(just because it uses the OModel). Changes at the IL level should be
minimal.
I've started a new branch for this called rtver but don't expect it to be
stable before a little while. I'll break everything in there, do some
compatibility tests and then merge back to trunk when everything's ready.
Wish me good luck ;)
Cheers,
Matthieu
[1] http://ode.apache.org/atomic-scopes-extension-for-bpel.html
