ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Backward compatibility of compiled processes and live instances
Date Wed, 14 Nov 2007 20:00:41 GMT
Hi Zubin,

Interesting paper although it touches on a related but different subject,
which is how to design and version process definitions themselves.

The article doesn't discuss how you upgrade from Websphere Process Server
6.1 to (hypothetically) version 7, or 8, or 9...   Ideally, you just stop
version 6, install version 7 and restart.  Under the cover, however, the
engine must be designed to handle older instances as-is, or migrate them to
its newer internal model if its data model changed.

In our case, we want people who are running process instances on Ode 1.1 to
be able to painlessly upgrade to 2.0.  But what about migrating live process
instances from 1.1 to (hypothetically) 3.0, or 4.0, or 5.0 in 6-8 years?
Will that be supported?   If so, how?   There are the questions we're trying
to answer.

alex


On 11/14/07, Zubin Wadia <zwadia@gmail.com> wrote:
>
> Just to contribute, this is the IBM perspective on it:
>
>
> http://www3.software.ibm.com/ibmdl/pub/software/dw/wes/pdf/0602_brown-wps_versioning_dynamicity.pdf
>
> Cheers,
>
> Zubin.
>
>
> On 11/14/07, Alex Boisvert <boisvert@intalio.com> wrote:
> >
> > Hi devs,
> >
> > We gathered at ApacheCon this week and yesterday discussed the thorny
> > issue
> > of long-term process instance compatibility.  The question, to put it
> > succinctly, is how to continue the execution of live instances of
> process
> > definitions compiled on previous versions of Ode into future versions of
> > the
> > software, despite changes and improvements to the engine.
> >
> > After discussing several alternatives, we are proposing the following,
> >
> > 1) For identification and tracking, we would encode an O-model version
> > number in the compiled BPEL process files;  existing .cbp files with no
> > version are assumed to be version 1.
> >
> > 2) We would keep and maintain different versions of the process
> definition
> > model concurrently in the source tree.   Each version would be kept in a
> > separate module with different package names to avoid name collision
> > during
> > serialization/deserialization, as well as to support concurrent class
> > loading in the same engine.   It would be possible to compile processes
> > into
> > a specific O-model version by selecting which compiler version to use.
> >
> > 3) For convenience, we would bundle together the "
> > org.apache.ode.bpel.runtime" package, the O-model and the compiler into
> a
> > single module.  This would simplify comparing and tracking changes
> between
> > versions.   (This would require some refactoring to handle compile
> > dependencies)
> >
> > 4) The latest version of the O-model in trunk would always be considered
> > under development and "unstable".  In other words, fair game for
> > modification.  Only after an official release would this model be
> > supported
> > with respect to forward-compatibility, and at that point we would
> "freeze"
> > this version and create a new one for future development.   By default,
> > the
> > engine would compile processes using the latest stable version.
> >
> > 5) At this point in time, version 1 is embodied by the O-model currently
> > in
> > the 1.1 branch, and version 2 is what's under development in the trunk
> > now.
> > We would therefore merge back the O-model from the 1.1 branch into the
> > trunk
> > to support both concurrently.
> >
> > 6) To keep the number of supported O-model versions to a manageable
> level,
> > we anticipate to release new O-model versions every 6 months to a
> > year.  The
> > actual frequency would depend on developer and user interest, as well as
> > the
> > type of changes required for new features.  To strike a balance between
> > backward compatibility and enhancements/progress, the project would
> > concurrently maintain and provide support -- on the same Ode server
> > instance
> > -- for a "window" of O-model versions covering approx. 2 years
> [1].  It's
> > anticipated that commercial vendors will be encouraged to provide
> > longer-term support ;)   Older O-model versions would be supported on
> > older
> > versions of the server for a longer period, based on community
> involvement
> > and interest.
> >
> > Feedback and questions are very welcome!
> >
> > Alex, Assaf, Maciej, Matthieu
> >
> > [1] We generally recommend breaking down long-running processes into
> > shorter
> > ones in order to support agile process improvement and change.  It's
> also
> > wise to consider modeling long-running process instances as persistent
> > external entities, as this approach generally offers higher levels of
> data
> > and state manageability ( c.f. External Variables).
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message