Hi Alex, Tammo, Thanks for the replies.
So I guess, we'll be first need to identify the exact mapping from the BPEL spec to a representation of a process instance in ODE across multiple versions, and thereby identify what's common to all, and what changes exist between multiple versions. Also, when creating the XML representation, IMHO we can make use of two strategies: 1. Create a universal XML format (which is as generic as possible) that is capable of working with multiple versions of ODE. 2. Create an XML format per version of ODE, and derive mappings from XML format A to XML format B. And if you need to work with multiple versions of ODE you need to apply a format translation. As we have discussed so far, and according to what I read in the project detail, it seems that we need something similar to option 1 above (I believe that I'm correct here). But, I also would like to know, that if the need to work with multiple versions of ODE is lesser when compared to the need of working with the same version of ODE, would option 2 be possible as well? And, as mentioned I will focus primarily on robustness, and then work towards making it efficient. Regarding the abstract base, yes it can vary according to the implementation. Also, by the way, I tried building two versions of ODE, from [1], and [2]. For me, [1] built successfully but not [2]. I will post to the list shortly about a few issues I had with [2]. Therefore, during the initial stages, am I to focus on an implementation for [1]? [1] http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X [2] http://svn.apache.org/repos/asf/ode/trunk Regards, Senaka On Wed, Feb 25, 2009 at 1:39 AM, Tammo van Lessen <[email protected]>wrote: > Hi Senaka, > > Senaka Fernando wrote: > > 1. Is this project aimed at making it possible to represent the process > > instances stored as binary streams on the database in XML format so that > it > > can be exchanged across multiple instances? > > Exactly, but in various flavors. One scenario could be to extract a > certain number of processes, together will all running process instances > from one node (ODE version X) and move it to another node (running the > same version X). Another scenario could be to move it to version X' or > even to version Y. That's why the binary format is not sufficient as the > internal object structure may change from version to version. Since the > underlying model is a de-facto standard, the range of possible changes > is quite limited. Thus, the XML format should be carefully designed to > be as generic as possible but also as meaningful (in a sense that some > things are fixed by the BPEL spec and somethings are allowed, like the > extensibility mechanisms of BPEL) as possible. > > > > 2. If so, are you looking forward to a efficient mechanism that can > > represent (importer-exporter system) the persistent content (including > > process models and instances) in XML format, along with a mechanism that > can > > move the content between multiple instances? > > Efficiency is not the main goal. It should be as robust as possible to > make migrations between ODE nodes (with the same and/or different > versions) possible. The easier the better :) I'm also pretty sure that > researchers are very interested in such an intermediate format, e.g. to > migrate a running instance of process model X to X' where X' is a > modified version of X. This opens a can of worms of course, but some > researchers like worms ;) > > Hm, Alex was faster than me, so I'm stopping here since Alex answered > the rest of your mail already ;) Your vita sounds great, however, at the > end of the day it's important to submit a compelling application to > Google/ASF. We're of course happy to assist you in this regard. > > Best, > Tammo > > -- > Tammo van Lessen - http://www.taval.de >
