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
