Alex, Could you please walk through a couple of deployment/management scenarios and talk about how/when process definition state changes ( "active", "retired" ) explicitly vs. implicitly. I'm hoping this exercise will help me understand this statement:
The deployment rules for two such processes would be the same as if they did not share common name+namespace.
Given collisions ( see Maciej's restrictions 2 and 3 ) within the same name+namespace ( at runtime ) I don't see how these can be the same at deployment time. Thanks, Lance On 8/10/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Maciej Szefler wrote: > I propose that we do not put too many restrictions on what a new version > of a process looks like. It only needs to enforce the following rules: > 1. A service exposed in version n, must also be exposed in version n+1 > 2. An operation used in version n, must have the same signature in > version n+1 > 3. A data type used in version n, must have the same definition in > version n+1. > Personally, I still find this too restrictive. My proposal would be to consider the version attribute as part of the process identifier -- effectively making two processes with the same name+namespace but with different version identifiers completely unrelated from an implementation standpoint. The deployment rules for two such processes would be the same as if they did not share common name+namespace. alex
