[
https://issues.apache.org/jira/browse/ODE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tammo van Lessen resolved ODE-912.
----------------------------------
Resolution: Fixed
> [GSoC] 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
> Assignee: Tammo van Lessen
> Labels: gsoc2014
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
