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
>