Hi Aaron, I am interested in this work, it would be a great idea that you can put it somewhere on the github. ;-)
Regards Jeff On Fri, Mar 25, 2011 at 9:55 AM, Aaron Anderson <aander...@apache.org>wrote: > Hi Everyone, > > Sorry I missed the call earlier this week; due to the daylight savings time > change in the US I set my alarm clock for the wrong hour. > > Over the past few months in my spare time I have been working on a > prototype of an alternative BPEL engine architecture. I wasn't planing on > sharing anything publicly until the prototype was fully functional but this > conversation touched on one of the concepts I am exploring so I thought now > would be a good time to see if there is any interest in the work I have been > doing. > > Based on my experience with contributing to the Apache ODE and HISE > projects I noted the following improvements that I would like to see: > > 1) Support for modern dependency injection ( including JPA) > 2) Ability to run in multiple containers (JavaEE, SCA, > standalone) > 3) Event driven architecture > 3) Full support for a container provided JAXWS implementation (instead of > requiring AXIS/CFX) > 4) First class debugging support > 5) Seemless integration of extensions into the engine > 6) Retention of all source files (not compiled away) > > With these goals in mind I drew up this architecture that I have been > working towards: > > http://people.apache.org/~aanderson/Runtime.png > > In relationship to this conversation, the model I am investigating is > similar to Gary's BPEL based OModel where all artifacts are imported into a > repository and a build plan is invoked to generate an XML based executable, > comparable to a set of very high level Java byte code. For the most part > common instructions would be used in the model but where it is needed > instructions from an extension would be inserted. A runtime interpreter > would then step through these instructions using a XML schema namespace -> > Java instruction implementation mapping to actually execute the process. > > As far as progress goes, my prototype currently uses the Weld SE CDI > reference implementation as the container and I have completed eventing > support, JPA injection, and JMX CLI support. I am close to completing > repository import/export leaving compilation, interpretation, and > deployment. If the ODE project team finds any merit in the work I am doing I > would be happy to check the code into a new experimental branch for the > project or host it on github. > > As always, any feedback is warmly welcomed! > > Regards, > > Aaron > > > > > --- On Wed, 3/23/11, Shivaraj Tenginakai <tshiva...@gmail.com> wrote: > > From: Shivaraj Tenginakai <tshiva...@gmail.com> > Subject: Re: Evolvable OModel > To: "Gary Brown" <g...@pi4tech.com> > Cc: > dev@ode.apache.org > Date: Wednesday, March 23, 2011, 8:06 AM > > Also, if we can get this done - it would be possible to plug and play > multiple engines. Each engine may be optimized for a different use > case (for example, Long Running Processes vs. Short Processes). > > Thanks, > > Shivaraj > > > On Tue, Mar 22, 2011 at 9:50 PM, Gary Brown <g...@pi4tech.com> wrote: > > Agreed - just need to use a reference that remains stable across > > compilations, but still uniquely identifies the relevant node in the > > DAG. > > > > Regards > > Gary > > > > On Tue, Mar 22, 2011 at 3:43 PM, Shivaraj Tenginakai > > <tshiva...@gmail.com> wrote: > >> Way I have seen this implemented is that we need to > distinguish > >> between user state and ode state. ODE state represents the structure > >> of the DAG while the user state represents the value of the variables > >> and the position in the DAG . > >> > >> If we can achieve a clean separation between ODE state and user state, > >> then future evolution would become easy. > >> > >> Shivaraj > >> > >> > >> On Tue, Mar 22, 2011 at 8:42 PM, Tammo van Lessen <tvanles...@gmail.com> > wrote: > >>> Hi Shivaraj, hi Gary, > >>> > >>> yes and no: first, when compiling the process model, each OModel node > >>> contains a unique ID and this is currently a GUID. Thus, even if the > >>> BPEL code is unchanged, the OModel nodes will have different IDs after > >>> compilation. Second, these IDs > are used when serializing the runtime > >>> state. The JACOB soup keeps references to the OModel. When serializing > >>> the state, these references are replaced by placeholder objects that > >>> store the GUID of the original node to avoid serializing the whole > >>> OModel object graph. This is an optimization to save time and space. > >>> > >>> Tammo > >>> > >>> On 22.03.2011 15:35, Gary Brown wrote: > >>>> Hi Shivaraj > >>>> > >>>> As far as I am aware this issue is not related to state - only the > >>>> static representation of the business process. The OModel simply > >>>> represents a binary compiled version of the BPEL process definition. > >>>> So all I am suggesting is rather than store the binary version, we > >>>> store the xml version, compile on first load, and the end > result is an > >>>> up-to-date OModel, regardless of the age of the process instance. > >>>> > >>>> Regards > >>>> Gary > >>>> > >>>> On Tue, Mar 22, 2011 at 12:34 PM, Shivaraj Tenginakai > >>>> <tshiva...@gmail.com> wrote: > >>>>> Gary, > >>>>> > >>>>> Would it be possible to distinguish between execution optimization > and > >>>>> state? As long as state information can be derived from one version > to > >>>>> another, it should be fine to recompile (to achieve execution > >>>>> optimization). > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Shivaraj > >>>>> > >>>>> > >>>>> On > Tue, Mar 22, 2011 at 3:40 PM, Gary Brown <g...@pi4tech.com> wrote: > >>>>>> As discussed on the call today, we need a way to overcome the > >>>>>> constraints of the serialized OModel which is produced when > compiling > >>>>>> the BPEL process. > >>>>>> > >>>>>> Although a more flexible serialization mechanism may provide a > >>>>>> solution, as was also discussed, there will be cases where > additional > >>>>>> logic would be required to determine how an older representation > >>>>>> should be evolved into a new representation. > >>>>>> > >>>>>> Another approach would be to use the BPEL process (xml) directly, so > >>>>>> rather than using a binary representation > compiled in advance, the > >>>>>> runtime would simply load the BPEL DOM. > >>>>>> > >>>>>> If this required a change to the internal OModel mechanism, then it > >>>>>> may be more work than the proposed dynamic OModel idea, however if > we > >>>>>> simply took the approach of "compile on load", then we get away from > >>>>>> the issue, which is the persisted serialized form. We also no longer > >>>>>> require any specific migration logic to move from older versions of > >>>>>> the persisted representation (dynamic or not). > >>>>>> > >>>>>> So we could keep the existing OModel format, which can evolve as > >>>>>> required as long as the compiler is kept in step, and we should no > >>>>>> longer have any issues with long running > processes. > >>>>>> > >>>>>> This change could be introduced into the current 1.3.x trunk without > >>>>>> any backward compatibility issues. > >>>>>> > >>>>>> The only trade off is the speed difference between (1) loading the > >>>>>> compiled representation versus (2) parsing the XML & compiling the > >>>>>> BPEL process. If this would need to be performed multiple times in > the > >>>>>> same runtime, then a hash of the process could be used to cache the > >>>>>> compiled version so this is only performed once per process > >>>>>> definition. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> Regards > >>>>>> > Gary > >>>>>> > >>>>> > >>> > >>> -- > >>> Tammo van Lessen - http://www.taval.de > >>> > >> > > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
