Hi Zhen, good summary! They key point is indeed the migration. I see basically two points. 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. This is why I thought a JSON-like model would fit best, because this can be tweaked much easier e.g. with regex, treewalkers etc. Also a migration from the old model to the new model could be done by loading the old OModel, serializing it to JSON, applying a complicated function X on it and loading it then in the new mode. So far the theory :)
Luckily, the dao and database is not affected by this refactoring as the omodel is stored in the file system. The jacob runtime model keeps references to the OModel, but these references are being replaced by ids when the state is persisted and are replaced back when it is loaded, so the components that need to be touched is basically bpel-obj (the model itself of course), the compiler (because it fills the mode and the interface of the model may change during the refactoring) and the runtime (because it reads the model and if the interface has changed, it needs to be tweaked as well). 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. WDYT? Best, Tammo On Thu, Mar 13, 2014 at 4:17 PM, Fang Zhen <fangzhenz...@gmail.com> wrote: > Hi All, > I have noticed OModel serialization issues before. The only problem is that > OModel refactoring is not so important at my point when use ODE. So I did > not think it over and somewhat ignored it. However, I'm still interested in > it. I think I could work on it, and here I'd like to talk about my > understanding on the issue. > > In my view, OModel gives a compiled representation of BPEL elements. The > OModel objects are serialized for permanent store and exchange. It relies > on java serialization mechanism which is not flexible enough, so problem > occurs when we need evolve the existing OModel classes or new OModel > classes or share objects in cluster. > The candidate new serialization solutions are mainly in two ways. First, we > could store a Map<String, Object> and wrap all data that is currently > stored in field in this Map. And the java serialization mechanism can still > be used. Another way is that we employ a new serialization mechanism like > Jackson. > Another important problem is that how we can migrate to the new OModel. And > as Tammo says, is the most difficult part. Roughly thinking, it involves > many sub-projects like compiler, store, dao and underlying database. But I > konw little about the details. > This is my preliminary understanding on OModel refactor. Hoping for > suggestions and corrections. > Should we open a new thread for OModel refactor topic? > > Thanks, > Zhen > -- Tammo van Lessen - http://www.taval.de
