ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <boisv...@intalio.com>
Subject Re: Issue 10 / Versioning
Date Tue, 08 Aug 2006 21:25:48 GMT
Lance Waterman wrote:
> On 8/8/06, Alex Boisvert <boisvert@intalio.com> wrote:
>>
>> Lance,
>>
>> For consideration, I would like to briefly review the design that I had
>> in mind for versioning in PXE.  I think it's similar in spirit to what
>> you describe in your deployment spec.
>>
>> First, each process definition would be identified by its fully
>> qualified name (/name/ and /namespace/ attributes) and a version
>> number.  The process engine would manage the version number in a
>> monotonically increasing fashion, meaning that each time a process is
>> redeployed, the version number increases.
>
>
> I don't understand the need for a version number that is managed by the
> engine. I think a client may use whatever version scheme they use. We 
> just
> need to validate that the version identifier is unique at deployment 
> time.
There is no strict need for a version number managed by the engine.  I 
think this idea came up when we wanted to simplify the management 
interfaces and wanted to avoid the need for an extra user-provided 
identifier if you already encoded version information in the 
name+namespace.  It made it easier to define and communicate the 
"latest" process version.

> I agree with Maciej's comments on this and would like to add from the
> deployment spec under sec 1.2.5:
>
> *CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
> element ) for a process definition will require a new identifier ( i.e.
> name/namespace ) within the definition repository. Versioning is not
> supported across changes in the service interface and shall be 
> enforced by
> the deployment component.*
>
> I would like to make sure folks are okay with this as well.
Personally, I would be against this because it would mean that I cannot 
deploy a new process definition that implements additional interfaces 
(among other things).

I don't see the reason to bind together the notions of service interface 
and versioning.


> In general I would like to define the concept of a "current" process
> definition. The "current" process definition is the definition used by 
> the
> engine on an instantiating event. There could be instances running in the
> engine that are using other versions of a process definition, however its
> not possible to have multiple versions that are used for instantiating 
> new
> processes ( see Maciej's reply on endpoints ). Through management 
> tooling a
> client will identify the "current" process.
I don't think we need to define the notion of a "current" process.  I 
think we only need to define which (unique) process provides an 
instantiating (non-correlated) operation on a specific endpoint.

alex


Mime
View raw message