ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Backward compatibility of compiled processes and live instances
Date Wed, 14 Nov 2007 14:41:04 GMT
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