Hi Tammo,
To your example, it is a special condition, migrate from String to QName.
But in actual situation, we may does not the *FROM* class and the *TARGET*
class at all( maybe it is QName -> String migrate operation next time). We
must design a detailed migrate mechanism confirm the success of transform
from *ANY* type of source object to *ANY* type of target object. I am
thinking about the solution, in my initial idea, we can consider any object
as JSON format data, for example:
String:
Map<String,Object> userData1 = new HashMap<String,Object>();
userData1.put("OModel_name", new String("OModel_part"));
JSON format data generated by Jackson writeObject:
{"OModel_name":"OModel_part"}
QName:
Map<String,Object> userData2 = new HashMap<String,Object>();
userData2.put("OModel_name", new QName("OModel_namespaceURI",
"OModel_part", "OModel_prefix"));
JSON format data generated by Jackson writeObject:
{"OModel_name":"{OModel_namespaceURI}OModel_part"}
The migrate job is transform from one JSON to another JSON in a specific
rule, We should consider how to define the migrate description language.
Maybe re-use some existing JSON migrate DSL? This migrate DSL may be the
most important part of this project. Just a simple demo, may be looks like
this:
{"from":{"OModel_name":"$value1"},"to":{"OModel_name":"{OModel_namespaceURI}$value1"}}
Use $value to represent migrate attribute values.
Once we update OModel, if we specific the migrate rule, we can finish the
migrate job easily. Of course, we must specific the migrate rule for
different version change, such as v1.0->v1.1, v1.1->v1.2 and v1.0->v1.2.
2012/3/23 Tammo van Lessen <tvanles...@gmail.com>
> Hi Tiger,
>
> yes, that's good summary. In addition to that I'd like to see a simple
> mechanism that can then deal with such deviations of the model. Let me
> create an artificial example: OProcess stores currently
> targetNamespace and processName as Strings. Now imagine we change
> OProcess so that it stores a QName instead. When loading an old
> OModel, the QName field would be null and there would be the two
> String field in the "unknown fields" map. Now I'd love to have some
> migration code that kicks in, takes the string fields, creates a
> QName, assigns it to the field and removes the unneeded String fields
> from the map. This code is of course tailormade for each purpose, but
> I'd like to have some concepts (in form of a guideline/docs) and API,
> as well as some magic that uses e.g. a version number per OModel or
> OModel class in order to find out whether of potential migration is
> needed or not.
>
> Also, the devil is in the details. When using Jackson for instance,
> you would probably need to write custom (de)serializers for WSDL4J
> etc. Some stuff can be done using Jacksons mixin feature, some other
> stuff can't. If you think the package is too easy, we can easily
> extend it to a similar refactoring of the serialization code of the
> Jacob state ;)
>
> And yeah, I think Jackson is the right tool, although I'd prefer the
> binary represenation of JSON :)
>
> Best,
> Tammo
>
> On Thu, Mar 22, 2012 at 12:57, Tiger Gui <tigergui1...@gmail.com> wrote:
> > Hi Tammo,
> >
> > After the past dozens hours of survey, i found this project is not so
> hard.
> > This is my understanding about this project, if there is something wrong,
> > please let me know :-)
> >
> > ODE Compiler compile and create OModel instances(such as
> > OProcess,OAssign,OInvoke etc) from .bpel, .wsdl and deploy files. Then it
> > can use Java Object Serializable technology to serialize OModel objects
> > into a .cbp file (We can see OBase implements interface
> > java.io.Serializable, and all the OModel classes are the sub-class of
> > OBase).
> >
> > And ODE runtime module can load a compiled BPEL model(a .cbp file in
> local
> > disk) by de-serialize the .cbp file back into OModel classes.
> >
> > The problem is that OModel class structure will change along with ODE's
> > developing, for example, there are these attributes in current OProcess:
> > public final String version;
> > public OConstants constants;
> > public String uuid;
> > public String targetNamespace;
> > public String processName;
> > public OScope procesScope;
> > After ODE Compiler serialize it into .cbp file, the .cbp file will
> include
> > these 6 attributes for OProcess instance. One day, we add another
> attribute
> > for OProcess class, for example:
> > pubic String newAttribute;
> >
> > If we try to de-serialize the old .cbp file into the new OProcess class,
> we
> > will get a error.
> >
> > This project want to solve this problem, we will change .cbp file's
> format
> > and use a brand new serialize solution to keep compatibility. If we want
> to
> > use JSON to represent OModel, new .cbp file will be JSON format. In this
> > example, the old JSON format .cbp file can be de-serialized into the
> > new OProcess class, just will a null attribute "newAttribute", but no
> error
> > occur.
> >
> > This is my understanding, am i right ?
> >
> > BTW, compared with other existing libraries for JSON, Jackson is really
> the
> > best one. If we decide to use JSON to represent .cbp file, it is the best
> > choice :-)
> >
> > 2012/3/19 Tammo van Lessen <tvanles...@gmail.com>
> >
> >> Hi Tiger(?),
> >>
> >> thanks for your interest in this project. I consider this a very
> >> interesting project, also since it is crucial to make ODE more agile
> >> and makes it possible to add new features without affecting backward
> >> compatibility. Please ask any questions and take your time to file a
> >> detailed application for GSoc. I'm happy to help you through the
> >> process.
> >>
> >> Here are some details about the OModel and what the problem is:
> >>
> >> When a BPEL process is deployed to ODE, it first runs through the
> >> compiler, which parses the BPEL file into a BPEL Object Model (BOM),
> >> which basically aims at abstracting from different BPEL versions (1.1,
> >> 2.0 draft, 2.0 final). Then the compiler compiles the BOM into the
> >> OModel, which is then stored as .cbp file using Java's built-in
> >> serialization. The compiler does some optimizations, like translating
> >> <receive> into a <pick> with a single <onMessage>, which is
> >> semantically equivalent and thus simplifies the runtime navigator
> >> (since it does not need to implement <receive>). Also, it assigns
> >> every single element a unique ID within this process model.
> >>
> >> When a process instance is executed, the navigator operates on the
> >> OModel, i.e. it is loaded from disk into memory during execution and
> >> is unloaded afterwards, depending on hydration/dehydration policies to
> >> reduce the memory footprint. The execution state of the OModel keeps
> >> in-memory references to the OModel, but when the state is persisted,
> >> it does not store a copy of the OModel but only the IDs mentioned
> >> above. When the state is loaded, the IDs are looked up and replaced by
> >> proper references.
> >>
> >> The problem with the current OModel is that it has a static structure
> >> and is serialized using Java's built-in mechanisms, which are not very
> >> tolerant against class changes and could even struggle with JDK
> >> upgrades. This is a problem because BPEL processes and their instances
> >> are potentially long-running, i.e. they may run over years. Thus, a
> >> serialized OModel should survive ODE and JDK upgrades. Our problem is
> >> that even simple changes (that are needed to implement new features or
> >> even to fix some bugs) break backward compatibility in the OModel.
> >> There are a couple of cumbersome ways to deal with that, but we need a
> >> better solution to address that problem. The OModel resides in the
> >> bpel-obj module in the SVN.
> >>
> >> My suggestion is to duplicate the OModel and refactor it to a dynamic
> >> or semi-static model. This model is then exclusively used by the
> >> navigator. The old OModel remains untouched, so that old OModels (.cbp
> >> files) can be loaded and then migrated in a stop-the-world approach to
> >> the new model.
> >>
> >> I spend a couple of hours to investigate possible approaches and
> >> finally found Jackson 2.0 [1] as a potential solution. Jackson is
> >> actually a JSON framework that supports flexible databindings, but it
> >> turns out that its fast as hell, even faster than Java's built-in
> >> means. In addition, it provides a binary serialization protocol
> >> (Smile), that is even faster and smaller, also it can kind of optimize
> >> the data by storing duplicate strings only once and replacing further
> >> occurrences by a reference. Since in our case only read performance is
> >> important, this makes it a good candidate. It also provides a
> >> semi-static binding, which means that data that cannot be mapped to an
> >> object's field are put into a Map [2]. This might be useful to make
> >> the new OModel more evolveable: If there is unknown data in the map, a
> >> model migrator could start and transform this data into the new format
> >> if needed.
> >>
> >> Some more requirements and considerations can be found here [3].
> >>
> >> I hope that gives you an overview about the problem and the scope of
> >> the project. Could you briefly tell us a bit more about you, your
> >> experience with ODE and Java for instance? If you don't want to make
> >> this publicly available on the mailing list, feel free to contact me
> >> directly.
> >>
> >> Thanks,
> >> Tammo
> >>
> >> [1] http://wiki.fasterxml.com/JacksonHome
> >> [2]
> http://www.innoq.com/blog/me/blog/2012/03/05/semistatic-json-binding/
> >> [3]
> >>
> https://github.com/vanto/ode-omodel-jackson-experiments/blob/master/README.md
> >>
> >> On Mon, Mar 19, 2012 at 15:16, Tiger Gui <tigergui1...@gmail.com>
> wrote:
> >> > Hi All,
> >> >
> >> > I used ODE as BPEL engine before, and be interested in the GSoC 2012
> >> > project "Dynamic OModel: Refactor OModel and provide migration"[1]. I
> >> read
> >> > ODE's source code before, but not very familiar with its OModel
> module,
> >> so
> >> > can anyone tell me where should i start with OModel's details ? Is
> there
> >> > any materials which can help me understand OModel's design and
> implement
> >> > very quickly?
> >> >
> >> > Thank you very much
> >> >
> >> >
> >> > [1] https://issues.apache.org/jira/browse/ODE-912
> >> > --
> >> > Best Regards From Tiger Gui
> >> > --------------------------------------
> >> > Open source is some kind of life attitude
> >>
> >>
> >>
> >> --
> >> Tammo van Lessen - http://www.taval.de
> >>
> >
> >
> >
> > --
> > Best Regards From Tiger Gui
> > --------------------------------------
> > Open source is some kind of life attitude
>
>
>
> --
> Tammo van Lessen - http://www.taval.de
>
--
Best Regards From Tiger Gui
--------------------------------------
Open source is some kind of life attitude
