ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Anderson <aander...@apache.org>
Subject Re: Evolvable OModel
Date Fri, 25 Mar 2011 15:11:28 GMT
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.



--- On Fri, 3/25/11, Gary Brown <gary@pi4tech.com> wrote:

From: Gary Brown <gary@pi4tech.com>
Subject: Re: Evolvable OModel
To: dev@ode.apache.org
Cc: "Kurt Westerfeld" <kwesterfeld@novell.com>, aanderson@apache.org
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

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 :)


On Fri, Mar 25, 2011 at 2:25 AM, Kurt Westerfeld <kwesterfeld@novell.com> 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 <aanderson@apache.org> 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
> 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>
>>>> 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
>>>>>> state? As long as state information can be derived from one version
>>>>>> 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
>>>>>>> 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,
>>>>>>> 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
>>>>>>> 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
>>>>>>> the issue, which is the persisted serialized form. We also no
>>>>>>> require any specific migration logic to move from older versions
>>>>>>> the persisted representation (dynamic or not).
>>>>>>> So we could keep the existing OModel format, which can evolve
>>>>>>> required as long as the compiler is kept in step, and we should
>>>>>>> longer have any issues with long running
> processes.
>>>>>>> This change could be introduced into the current 1.3.x trunk
>>>>>>> any backward compatibility issues.
>>>>>>> The only trade off is the speed difference between (1) loading
>>>>>>> compiled representation versus (2) parsing the XML & compiling
>>>>>>> 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
>>>>>>> compiled version so this is only performed once per process
>>>>>>> definition.
>>>>>>> Thoughts?
>>>>>>> Regards
> Gary
>>>> --
>>>> Tammo van Lessen - http://www.taval.de

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