Hi Tammo, Yeah, my name is Tiger :-)
Thank you for your detailed explanation about ODE's OModel design. I know this project aims to re-factor OModel for ODE, and you describe the necessity and importance. Now i will go deep into ODE's source code and try to make clear of it structure, start file a detailed GSoC project proposal for this project. During this process, i will post my questions here to discuss with you guys if i am in case of doubt. Helping we can work together to finish an excellent GSoC project this summer :-) Thank you 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
