Alex, inline ...
Lance On 8/10/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Alex Boisvert 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. As further clarification, I think it should be a responsibility of the tooling around the engine to define/enforce a given deployment and activation policy.
I agree and I think Paul Brown had some thoughts around importing and enforcing these policies within the deployment engine. A bit too agressive for me but certainly worth thinking abount. For instance, the tooling could automatically
undeploy or retire previous versions of a process when deploying a new one. It could even automatically wipe out previous instances if I'm working in development mode (versus production). So I would prefer an approach where the engine provides general mechanisms for managing process versions and we leave it to the integration layer / tooling around the engine to define particular behavior related to lifecycle management.
I agree however I think there are some minimal requirements/policies that the engine defines and I think to date I see those as restrictions 2 and 3 as defined by Maciej. alex
