Hi Tammo, I think I'm clear of what and how the project is to do on the whole. My proposal is attached. Hoping your feedback on anything :-).
Thanks, Zhen 2014-03-18 21:14 GMT+08:00 Tammo van Lessen <tvanles...@gmail.com>: > Hi Zhen, > > good analysis. As I side mark, actually java serialization can deal with > the addition of new fields, however, we sometimes even had difficulties > with that as well. I agree, if the new OModel provides the flexibility, > plugin mechanisms for compiler and runtime would be needed for extensions > like BPEL4People. Some time ago I developed (basic) support for extension > activities (which is now hibernated in some branch, waiting for the new > OModel basically ;)) and struggled with exactly this problems. Although its > possible to add hooks to compiler and runtime for plugins, there was no way > to let the plugin extend the OModel. If the OModel can support this, this > would be very good. From a design perspective, I think it could be solved > like that: Reimplement the OModel based on maps and provide basically two > APIs. One low-level-API which wraps the map and allows plugins to add new, > plugin related, perhaps prefixed fields. The other API provides basically > convenient access to the fields needed by the core runtime, eg following to > what the current OModel provides. The serialization however should be based > on JSON (or smile). Since for the JSON representation it doesn't matter if > the data is backed by fields or a map, it could be possible to keep the > mismatch between a JSON serialization of the old OModel and the new OModel > as small as possible. > > Regarding the migrations within the OModel, we could add a version > attribute and give all OModel classes the possibility to migrate. For > instance we could check if the version of loaded model is older than the > version of the implementation and then call a migrate()-function > recursively on the OModel. Each class could then decide whether it needs to > migrate something or not. > > WDYT? > > Are you already in the process of composing a proposal? If I'm not mistaken > there are only a couple of days left, so if you like to get my feedback > before it would be good to discuss that soonish :) > > Best, > Tammo > > > > > On Sat, Mar 15, 2014 at 3:41 PM, Fang Zhen <fangzhenz...@gmail.com> wrote: > > > Hi Tammo, > > > > > For the migration from old omodels one approach would be to create a > copy > > > of the OModel in a different package, do the refactoring there and > change > > > the compiler and the runtime to point to the new OModel. > > > When an old cbp-file is found, it is loaded to the old OModel, is then > > migrated to the > > > new OModel (using that mysterious function X) and is then written back > to > > a > > > file in order to complete the migration. > > I think the approach and the Function X for migration are both very > > practical. I need to go into the source code for more details. > > > > > First the migration from the old model to the new model. Second the > > > migration from the new model to newer models. The goal of the project > is > > to > > > make the second point as hazzlefree as possible. > > I'd like to talk on a little more on the compatibility and migration > > topics. I think it somewhat more sophisticated than I originally thought. > > > > The current OModel models BPEL entity to corresponding java Object, e.g. > > whole process to OProcess. When the ODE is running, it watchs certain > > directory (WEB-INF/processes/) for new deployment. If umcompiled .bpel > > found, it will read the .bpel into BOM objects and then serialize them > into > > .cbp file. When processes are invoked, the runtime load cbps and runs the > > processes. > > In my view, the OModel can be divided into two parts, serialization > > mechanism and java representation mechanism, when BPEL evolves, I think > two > > types of compatibility should be considered in migration. > > For example, we want to support new elements in a process: > > <bpel:process> > > ... > > <b4p:humanInteractions> > > ... > > <b4p:humanInteractions> > > ... > > </bpel:process> > > > > First, serialization compatibility > > In our OProcess implementation, there are no fields corresponding to the > > new elements. Then we implement a new version of OProcess with new > elements > > as new fields. The new versions are not compatible to the old one under > > java serialization, which means old version binary cannot be > de-serialized > > to new version runtime objects. Then we need run different OModels in > > parallel. And as a result, duplicated run-time code. If we use JSON-like > > serialize mechanism, deserialize-compatible will be easier. And I think > > JSON-like serialize mechanism is able achieve serialize/deserialize > > compatibility without change java representation mechanism of > OModel(using > > simple fields in serializable classes of bpel-obj). > > Second, java representation compatibility > > In some cases like bugfix, the serialization compatibility seems > > sufficient, but does not in many cases. If we decide to support > BPEL4People > > extension, java representation of OModel will change, like new fields or > > classes. Then compiler and run-time needs to change to adapt. It could > > adapt to new model in ideal conditions. But I think it's impossible that > > it's complete compatible when BPEL evolves. We need to design java > > representation mechanism, compiler and runtime carefully to make changes > > needed as few as possible. Further, if BPEL4People are supported, is it > > possible to disable it since I don't need the feature and enable it will > > waste resources? I think a plugin mechanism for compiler and runtime > might > > be an option. I haven't go into source code of these components, I've no > > idea if it's practical... > > > > In my opinion, the former compatibility could be achieved almost once for > > all by a JSON-like or ther flexible serialize mechanism, and it will > bother > > little in later migrations. But the latter one are beyond OModel and > exists > > in every migration. What we could do is do best to reduce migration cost. > > It may involve more than OModel refactor, but compiler and runtime to > some > > degree. > > Hoping I made myself clear. > > > > Thanks, > > Zhen > > > > > > -- > Tammo van Lessen - http://www.taval.de >
Apache GSoC 2014 Proposal -- ODE OModel refactoring and migration ================================================================= This proposal is for [ODE-912: Refactor OModel and provide migration][1]. Abstract ------- This proposal is aimed at refactor the OModel for ODE project. Current OModel is not evolveable. When BPEL evolves, new version of OModel objects fail on backward compatibility and compiler/runtime is not flexible enough to the OModel changes like new extension support. I propose JSON serialization and extension plugin mechanism for them respectively. It will reduces work needed for later migrations. Background ----------- The current OModel maps BPEL entity to corresponding java Object, e.g. whole process to OProcess. When the ODE is running, it watchs certain directory (WEB-INF/processes/) for new deployment. If source .bpel found, it will read the .bpel into BOM objects and then serialize them into .cbp file. When processes are invoked, the runtime load cbps and runs the processes. But 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. As a result, we need to refactor the OModel and migrate the project from the older one. Design ------ Migration during refactoring mainly involves three components: Bpel-obj, the java representation of OModel and serialization mechanism; compiler, which compile .bpel into OModel representation; and runtime, which reads the model. If the OModel interface changed, compiler and runtime needs to be adapted as well. The goal of OModel refactoring is to make future migrations as hazzlefree as possible. More precisely, we need to design the OModel as well as compiler and runtime carefully to achieve flexiblity and configurability in future OModel evolutions. ###serialization migration### Current serialization mechanism relies on java serialization, which tends to fail on backward compatibility sometimes, e.g. when version of serialized class is considered, the solution is complicated. So, I'd like to employ JSON for serialization, which will provide backward compatibility more easily, e.g. with regex, treewalkers etc. As for migrations from current OModel to new OModel, we could provide a migrateLegacy() function which load the old OModel and serialize it to new OModel. Regarding the migrations within the new OModel, we could add a version attribute and give all OModel classes the possibility to migrate. For instance we could check if the version of loaded model is older than the version of the implementation and then call a migrate()-function recursively on the OModel. Each class could then decide whether it needs to migrate something or not. ###compiler and runtime migration### If we decide to support extensions like BPEL4People, java representation of OModel will change, like new fields or classes. Then compiler and run-time needs to change to adapt. It could adapt to new model in ideal conditions. But it's impossible that it's complete compatible when BPEL evolves. I think a configurable plugin mechanism will fit this. We can add extension hooks for compiler, runtime and the OModel. As for plugin support of OModel, it could be solved like that: We could reimplement the OModel based on maps, which is store a Map<String, Object> and wrap all data that is currently stored in field in this Map and provide basically two APIs. One low-level-API which wraps the map and allows plugins to add and access new, plugin related, perhaps prefixed fields. The other API provides basically convenient access to the fields needed by the core runtime. Since for the JSON representation it doesn't matter if the data is backed by fields or a map, it could be possible to keep the mismatch between a JSON serialization of the old OModel and the new OModel as small as possible. Approach -------- 1. Read source code and documentation to understand the design of old model, compiler and runtime. 1. Decide java representation of OModel and serialization mechanism. 1. Create a copy of the OModel in a different package, do the refactoring there. 1. Change compiler and runtime to adapt to new OModel. It will involves some refactoring as well. 1. Implement migrateLegacy() that migrates old serialized objects to new OModel objects. Deliverables ------------ 1. Refactored OModel, that is refactoring of sub-project ode-bpel-obj. 1. Adapted compiler and runtime based on sub-project ode-bpel-compiler and ode-bpel-runtime. 1. Documentations. Schedule -------- * 22 April - 18 May Read source code and documentation. * 19 May - 18 June Refactoring OModel. * 19 June - 18 July Change compiler and runtime to adapt to new OModel. * 19 July - 11 Aug Migrate from old OModel to new OModel. * 12 Aug - 19 Aug Scrub code, write tests, improve documentation. About me -------- To be done... [1]: https://issues.apache.org/jira/browse/ODE-912 "[GSoC] Dynamic OModel: Refactor OModel and provide migration"
