Sounds good so far - keep up the good work :) Regards Gary
On Fri, Mar 25, 2011 at 3:11 PM, Aaron Anderson <[email protected]> wrote: > HI Gary, > > I agree 100% that all of our immediate focus should be on enhancing ODE 1.X > and the prototype that I have envisioned is still months from completion. > With the OModel discussion I thought it would be an opportune time to discuss > ODE's future directions. At this point I was only looking for high level > design critiques so that I don't go off on a tangent the project team does > not approve of. > > Regards, > > Aaron > > --- On Fri, 3/25/11, Gary Brown <[email protected]> wrote: > > From: Gary Brown <[email protected]> > Subject: Re: Evolvable OModel > To: [email protected] > Cc: "Kurt Westerfeld" <[email protected]>, [email protected] > Date: Friday, March 25, 2011, 4:53 AM > > Hi Kurt > > I agree with your point - however I believe that was the goal of > Aaron's second bullet, so that his engine does not need to worry about > integration. > > Aaron - the project sounds interesting, and would definitely be worth > making public (probably github is the best choice for now though). > > From my perspective, the short/medium term focus must be on ODE 1.x to > provide the best solution possible based on the current architecture. > > However when it comes time to look at significant performance > improvements, etc, then this would usually involve some significant > change in architecture, with the associated requirement for migration > from older versions. It would be good at this stage to have some > alternatives :) > > Regards > Gary > > On Fri, Mar 25, 2011 at 2:25 AM, Kurt Westerfeld <[email protected]> > wrote: >> About the container, I would hope that Servicemix would continue to be a >> full-fledged citizen in the mix (excuse the pun). In fact, I wonder if it >> shouldn't be emphasized more, since it has connections to anything one would >> ever want in terms of sending/receiving messages to external systems. It >> seems to me that the ODE should focus more on tooling and debugging support >> instead of working on integration, since it is quite possible to leave that >> to a product which is dedicated to that purpose (ie. Servicemix, CXF and >> Camel). >> >> Thoughts? >> >>>>> Aaron Anderson <[email protected]> 3/24/2011 6:55 PM >>> >> 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 <[email protected]> wrote: >> >> From: Shivaraj Tenginakai <[email protected]> >> Subject: Re: Evolvable OModel >> To: "Gary Brown" <[email protected]> >> Cc: >> [email protected] >> 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 <[email protected]> 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 >>> <[email protected]> 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 <[email protected]> >>>> 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 >>>>>> <[email protected]> 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 <[email protected]> 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 >>>>> >>>> >>> >> >
