You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Tammo van Lessen <tv...@gmail.com> on 2014/03/14 19:58:44 UTC
GSoC 2014 - OModel refactoring (was: CXF IL)
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 <fa...@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
Re: GSoC 2014 - OModel refactoring (was: CXF IL)
Posted by Fang Zhen <fa...@gmail.com>.
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 <tv...@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 <fa...@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 <tv...@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 <fa...@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
>
Re: GSoC 2014 - OModel refactoring (was: CXF IL)
Posted by Tammo van Lessen <tv...@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 <fa...@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 <tv...@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 <fa...@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
Re: GSoC 2014 - OModel refactoring (was: CXF IL)
Posted by Fang Zhen <fa...@gmail.com>.
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 <tv...@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 <fa...@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
>
Re: GSoC 2014 - OModel refactoring (was: CXF IL)
Posted by Tammo van Lessen <tv...@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 <fa...@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
Re: GSoC 2014 - OModel refactoring (was: CXF IL)
Posted by Fang Zhen <fa...@gmail.com>.
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