Runtime versioning

[Matthieu Riou <ma...@offthelip.org>]

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

Re: Runtime versioning

[Matthieu Riou <ma...@offthelip.org>]

Hi,

I'm finally getting there, all tests are passing on my branch so I'm ready
for a merge to trunk. Let me know if you have something pending and you'd
like me to wait, otherwise expect a big commit in the coming days. Hopefully
I haven't lost anything that happened since then but a quick sanity checks
of your latest development after the merge could be a good idea to double
check.

Cheers,
Matthieu

On Tue, Jul 29, 2008 at 3:20 PM, Matthieu Riou <ma...@offthelip.org>wrote:

> 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
>