ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiger Gui <tigergui1...@gmail.com>
Subject Re: Draft version of "Refactor OModel and provide intelligent migration feature for Apache ODE" project proposal
Date Wed, 04 Apr 2012 08:35:42 GMT
Hi Tammo,

I have added project schedule and about me sections for my proposal and
submit it GSoC melange system, you can find the proposal details here[1],
and we can keep improving it before April 6th, only 2 days left. If you
have any suggestions about it, please tell me, hope we can get an
acceptable proposal :-)

Thank you

[1]
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tigergui/41002

2012/4/4 Tammo van Lessen <tvanlessen@gmail.com>

> Hi Tiger,
>
> thanks for your proposal. I'll need to read it more thoroughly, I'll
> come back to you tomorrow. But what is missing is a rough schedule
> with defined milestones. This is something other applications provide
> and are helpful and necessary for the ranking and also for measuring
> your progress. It would be great if you could add a project plan.
>
> Thanks,
>  Tammo
>
> On Fri, Mar 30, 2012 at 10:11, Tiger Gui <tigergui1990@gmail.com> wrote:
> > Hi all,
> >
> > I have drawed up draft version of GSoC 2012 project "Refactor OModel and
> > provide intelligent migration feature for Apache ODE" project proposal,
> you
> > guys can find the details here[1].
> >
> > This is only initial idea of Tammo and me, if you guys have any good
> advises
> > about this project, let's discuss here, and i will update the proposal
> > according to the discussion result. As GSoC's student application period
> > will close on April 6, we have still a week to improve the proposal.
> Thank
> > you all :-)
> >
> > [1]
> >
> http://code.google.com/p/tigergui-proposal-temp/wiki/Dynamic_OModel?ts=1333094366&updated=Dynamic_OModel
> >
> >
> >
> > ===============Refactor OModel and provide intelligent migration feature
> for
> > Apache ODE====================
> >
> > Introduction
> >
> > Apache ODE (Orchestration Director Engine) executes business processes
> > written following the WS-BPEL standard. It talks to web services, sending
> > and receiving messages, handling data manipulation and error recovery as
> > described by your process definition. It supports both long and short
> living
> > process executions to orchestrate all the services that are part of your
> > application.
> >
> > Current ODE's OModel 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. We want to create a GSoC project
> to
> > refactor OModel to provide intelligent migration feature for ODE.
> >
> > Details Description
> >
> > Current ODE OModel Design
> >
> > Let's begin with Apache ODE's architectural:
> >
> > 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).
> >
> > 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 (Compiled Process Definitions part in the diagram, and we can
> > see OBase implements interface java.io.Serializable, and all the OModel
> > classes are the sub-class of OBase).
> >
> > ODE runtime module can load a compiled BPEL model(the .cbp file in local
> > disk) by de-serialize the .cbp file back into OModel classes.
> >
> > 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.
> >
> > Where Is The Problem
> >
> > Once you read OModel's serializer and de-serializer methods in class
> > org.apache.ode.bpel.o.Serializer:
> >
> > public void writeOProcess(OProcess process, OutputStream os) throws
> > IOException {
> >
> >         DataOutputStream out = new DataOutputStream(os);
> >
> >         out.write(MAGIC_NUMBER);
> >
> >         out.writeShort(format);
> >
> >         out.writeLong(compileTime);
> >
> >         out.writeUTF(process.guid);
> >
> >         out.writeUTF(process.targetNamespace);
> >
> >         out.writeUTF(process.processName);
> >
> >         out.flush();
> >
> >         ObjectOutputStream oos = new CustomObjectOutputStream(os);
> >
> >         oos.writeObject(process);
> >
> >         oos.flush();
> >     }
> >
> > public OProcess readOProcess() throws IOException,
> ClassNotFoundException {
> >
> >
> >         ObjectInputStream ois = new
> CustomObjectInputStream(_inputStream);
> >
> >         OProcess oprocess;
> >         try {
> >
> >             oprocess = (OProcess) ois.readObject();
> >
> >         } catch (ClassNotFoundException e) {
> >
> >             throw new IOException("DataStream Error");
> >
> >         }
> >         return oprocess;
> >
> >    }
> >
> > You will find 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.
> >
> > 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 is a problem because BPEL processes and their instances are
> potentially
> > long-running,they usually 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. We need a good solution to address
> > that problem.
> >
> > What Shall We Do To Solve This Problem
> >
> > This project want to solve this problem, we will change .cbp file's
> format
> > and use a brand new serialize solution to keep compatibility. After
> > investigate possible approaches, we would like to use JSON to represent
> > OModel(It means new .cbp file will be JSON format). About the above
> example,
> > the old JSON format .cbp file can be de-serialized into the new OProcess
> > class with a special migrate condition description string.
> >
> > Json Format
> >
> > Jackson is actually a JSON processor (JSON parser + JSON generator)
> written
> > in Java. Beyond basic JSON reading/writing (parsing, generating), it also
> > offers full node-based Tree Model, as well as full OJM (Object/Json
> Mapper)
> > data binding functionality. More important, it has good performance, even
> > faster than Java's built-in means.
> >
> > So we decided to use Json format file store OModel's serialize result,
> and
> > Jackson 2.0 is the potential solution to reading/writing OModel instance
> > from/to Json format .cbp file.
> >
> > We can use Jackson to store attributes of Current OProcess class to Json
> > format file like this:
> >
> >         Map<String,Object> userData1 = new HashMap<String,Object>();
> >
> >         userData1.put("owner", process.getOwner());
> >
> >         userData1.put("name", process.getName());
> >
> >         userData1.put("targetNameSpace", process.targetNamespace);
> >
> >         userData1.put("processName", process.processName);
> >
> >         userData1.put("children", process.getChildren());
> >
> >
> >         ObjectMapper mapper = new ObjectMapper();
> >
> >         StringWriter sw = new StringWriter();
> >
> >         org.codehaus.jackson.JsonGenerator gen;
> >
> >         try {
> >                 gen = new JsonFactory().createJsonGenerator(sw);
> >
> >                 mapper.writeValue(gen, userData1);
> >
> >                 gen.close();
> >                 String json = sw.toString();
> >
> >                 System.out.println(json);
> >
> >         } catch (IOException e) {
> >
> >                 e.printStackTrace();
> >         }
> >
> > The target json file will be:
> >
> > {"targetNameSpace":"http://ode/bpel/unit-test
> ","name":"HelloWorld2","processName":"HelloWorld2"}
> >
> > But not all the OModel instance can be serialized only using Jacksons
> mixin
> > feature, we have to extend Jackson and would probably need to write
> custom
> > (de)serializers for WSDL4J etc.
> >
> > OModel Migrate Mechanism
> >
> > Here we use a simple example proposed by my potential mentor Tammo van
> > Lessen to describe the migrate mechanism.
> >
> > Simple 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.
> >
> > Migrate Solution
> >
> > Suppose the old version of OProcess is stored in following format:
> >
> > {"targetNameSpace":"http://ode/bpel/unit-test
> ","name":"HelloWorld2","processName":"HelloWorld2"}
> >
> > and the corresponding new version of OProcess's json .cbp file will be:
> >
> > {"name":"HelloWorld2","namespace":"{
> http://ode/bpel/unit-test}HelloWorld2"}
> >
> > 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
> or
> > just re-use some existing JSON migrate DSL.
> >
> > This migrate DSL may be the most important part of this project. In this
> > simple demo, maybe looks like this:
> >
> > {
> >    "from":{
> >
> >       "name":"$value0",
> >
> >       "targetNameSpace":"$value1",
> >
> >       "processName":"$value2"
> >
> >    },
> >    "to":{
> >
> >       "name":"$value0",
> >
> >       "namespace":"{$value1}$value2"
> >
> >    }
> > }
> >
> > Use $value to represent migrate attribute values.
> >
> > Domain-specific language(DSL)
> >
> > Once we update OModel, and want to migrate the old version to new
> version.
> > If we have both the old version Json format .cbp file and the specificed
> > migrate rule, we can get the new version Json format .cbp file, then
> load as
> > new OProcess object, finish the migrate job easily.
> >
> > We are still survey for exist tools like XSLT, working on JSON Trees. If
> can
> > not find such a tool, have both the old OModel and the new OModel, we can
> > write a tool to generate migrate DSL string.
> >
> > 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.
> >
> >
> > --
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message