ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pradeep G (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ODE-912) [GSoC] Dynamic OModel: Refactor OModel and provide migration
Date Thu, 03 May 2012 13:22:50 GMT

     [ https://issues.apache.org/jira/browse/ODE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Pradeep G updated ODE-912:

    Comment: was deleted

(was: A comment with security level 'jira-users' was removed.)
> [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
>              Labels: gsoc2012
>             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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message