ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Brown <g...@pi4tech.com>
Subject Re: Evolvable OModel
Date Tue, 22 Mar 2011 16:20:35 GMT
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
>>
>

Mime
View raw message