ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Yu <jeff.yuch...@gmail.com>
Subject Re: Evolvable OModel
Date Fri, 25 Mar 2011 09:57:57 GMT
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 <aanderson@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 <tshivaraj@gmail.com> wrote:
>
> From: Shivaraj Tenginakai <tshivaraj@gmail.com>
> Subject: Re: Evolvable OModel
> To: "Gary Brown" <gary@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 <gary@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
> > <tshivaraj@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 <tvanlessen@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
> >>>> <tshivaraj@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 <gary@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

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