ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject GSoC 2014 - OModel refactoring (was: CXF IL)
Date Fri, 14 Mar 2014 18:58:44 GMT
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

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.



On Thu, Mar 13, 2014 at 4:17 PM, Fang Zhen <fangzhenzyou@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message