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