ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shivaraj Tenginakai <tshiva...@gmail.com>
Subject Re: Evolvable OModel
Date Tue, 22 Mar 2011 12:34:21 GMT
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
>

Mime
View raw message