You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Gui XunHu (JIRA)" <ji...@apache.org> on 2013/03/16 08:38:13 UTC
[jira] [Commented] (ODE-912) [GSoC] Dynamic OModel: Refactor OModel
and provide migration
[ https://issues.apache.org/jira/browse/ODE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604149#comment-13604149 ]
Gui XunHu commented on ODE-912:
-------------------------------
Hi Tammo,
Is this project available for GSoC 2013? I am really interested in it, if it is available this year, i will prepare proposal for it and discuss with you about the details. My mail address is gui.xunhu@gmail.com, please let me know the answer, thanks :-)
> [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: gsoc2013
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira