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 22:40:44 GMT

What is the benefit of forcing the service signature to be the same for 
a given process name?   Is there a complexity aspect that I am 
missing?   It seems like the engine is trying to enforce a specific 
policy instead of providing a flexible deployment mechanism.

Say I change the signature of a Java class, do I need to change its name?


Lance Waterman wrote:
> I think if P(v1) and P(v2) have different operation+endpoint then P(v2)
> should be a new process definition ( name/namespace ) and not a new 
> version.
> It seems like P(v2) is trying to define a new interface for P(v1). What
> happens if P(v1) and P(v2) do have the same operations and both are 
> active?
> I think in the typical use case we are trying to solve ( i.e. the 
> client app
> is not required to change )..
> Lance
> On 8/8/06, Alex Boisvert <boisvert@intalio.com> wrote:
>> Maciej Szefler wrote:
>> > I think that clarifies it, and also suggests that our terminology 
>> is not
>> > the best. The things that is confusing is that the retired 
>> processes are
>> > not "inactive". Lance's 'current' is better in this respect, but 
>> has no
>> > good opposite (perhaps "legacy").
>> >
>> Retired only means that you cannot create new instances -- existing
>> instances remain active and are allowed to complete normally.  This
>> terminology is already used in other widely available process engines
>> and that's why I've been using it.
>> Again, I don't understand why we need the concept of "current" since you
>> only need to define which process is logically hooked to a given
>> operation+endpoint for routing purposes.
>> Or said another way, I don't understand why you could not have P (v1)
>> and P (v2) both activated at the same time if they do not share the same
>> operation+endpoints.
>> alex

View raw message