Dynamic OModel: Refactor OModel and provide migration
-----------------------------------------------------
Key: ODE-912
URL: https://issues.apache.org/jira/browse/ODE-912
Project: ODE
Issue Type: Improvement
Components: BPEL Compilation/Parsing, BPEL Runtime
Reporter: Tammo van Lessen
Fix For: 1.4
The OModel is currently not evolveable. It heavily relies on Java
serialization, which tends to fail on backward compatibility, which in turn
means we are very restricted regarding changes on that compiled model without
losing binary compatibility. This is however important for long-running
processes, which is a somewhat crucial feature.
What we need is a mechanism that enables us to maintain backward compatibility
but also to be able to enhance the model (e.g. for extension activities,
BPEL4People, or simply bug fixing). In the experimental branch, Matthieu added
OModel versioning, which means we can run different OModels in parallel (along
with a respective version of the runtime code). The drawback of this approach
is that each non-binary-compatible change to the most recent but released
OModel version will force us to create a new version, which is code duplication
of the OModel + Runtime code.
Here is my proposal: Address the issue on a different level of abstraction.
Instead of using simple fields in serializable classes, we could just store a
Map<String, Object> and wrap all data that is currently stored in field in this
Map. This means, even if we add new keys/fields, the structure of the class
will not change, thus serialization will not be affected. Another benefit of
this would be that the extension activity support can be more sophisticated:
the compiler part of an extension would be capable to add extension specific
information directly to the OModel,
and the runtime part can directly access that. The downside is a slightly
larger memory/serialization footprint (we are now storing Strings instead of
the field number).
In my opinion, this approach could solve our problems with the current OModel,
implementing such a new model is not too hard, though boring task. The most
difficult part is providing a migration from the old to the new OModel.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
