Hi all, Hi Tammo, My Gsoc proposal for OModel refactoring and migration has been accepted, I have started working on it. I have pulled the git repo of ODE and imported into Eclipse which I prefer to use for development. The next step is reading source code along with BPEL-WS spec to understand old OModel design and BPEL itself. And contribute patches if possible. AFAIK, source code, documentation on ODE site and BPEL spec would the main documentation that I can refer. And if we have any code style guideline and requirements?
And here is my schedule (from my proposal): 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. Any comments and feedback on documentation, schedule and any other suggestions would be appreciated. Thanks, Zhen 2014-03-20 21:52 GMT+08:00, Tammo van Lessen <tvanles...@gmail.com>: > Hi Zhen, > > I think the proposal ist just fine. Please also add a section explaining > how much time you can spend and if there other (conflicting) assignments > during the gsoc schedule. Besides of that I'm happy to see the proposal > submitted. > > Thanks, > Tammo > > > On Wed, Mar 19, 2014 at 3:28 PM, Fang Zhen <fangzhenz...@gmail.com> wrote: > >> 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 >>> >> >> > > > -- > Tammo van Lessen - http://www.taval.de >
