On 8/10/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
Assaf, I agree with you and this is how I would set up a deployment policy ( if someone were to ask me to ) however, I think Alex's point is that process definition policy should be enabled by ODE and not necessarily enforced by ODE ( see gun pointed at own foot ). The only policies that I think ODE must enforce are those listed by Maciej:
I agree with this principle, when it comes to the basics of deploying processes. But if we want to have the convenience of history of versions of the same thing, then we're asking for restrictions. We're essentially asking the process engine to keep track of one version that replaces another out of convenience, so it's reasonable that the deployment policy would replace one version with another. If on the other hand we want to create a new naming mechanism out of tuples of namespace, name and number, I don't see justification for that. QNames are an infinite naming space already, flexible enough and work the same way across the entire stack. Let's just keep to what works. Assaf
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. Thoughts? Lance On 8/9/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > I don't see it that way. > > If I wanted to deploy Foo side by side with Bar, I would create a process > Foo and a process Bar, with distinct names that may differ only in version > number. > > If I'm deploying Foo for the third time (v3), it's because I'm replacing > Foo(v2), itself replacing Foo(v1). And the element of least surprise is > that > new version is activated, while old version is retired. Consistently. > > Otherwise, I accidentally change the endpoints in Foo(v3), and all my test > > cases keep working even though they should be failing, because Foo(v3) is > wrong, but Foo(v2) is still active. > > Assaf > > On 8/9/06, Alex Boisvert <[EMAIL PROTECTED] > wrote: > > > > > > Sorry Lance, I still disagree. > > > > I think the engine should allow simultaneous deployment and activation > of: > > > > P(v1) with operation "foo" on endpoint "bar" > > P(v2) with operation "foo" on endpoint "baz". > > > > or > > > > P(v1) with operation "foo" on endpoint "bar" > > P(v2) with operation "foz" on endpoint "bar". > > > > These are just two examples but they illustrate what I consider a valid > > use-cases. > > > > alex > > > > > > Lance Waterman wrote: > > > So if I understand correctly you are saying there should only be one > > > "active" process definition at any given point in time? From the > > example; > > > when P.v2 is deployed it is implied that P.v1.A becomes inactive and > any > > > messages targeted at P.v1.A would fail to route within the engine. > > > > > > If the above statement holds true with everyone then I think we are in > > > agreement and we need to decide on a naming convention for these > process > > > definition states. > > > > > > I have been using the convention "current" and I think Maciej > suggested > > > "legacy" for the converse ( I would suggest "deprecated" as an > > > alternative > > > ). > > > > > > I think Alex prefers the terms "active" and "retired"? > > > > > > Thoughts? > > > > > > Lance > > > > > > > -- > CTO, Intalio > http://www.intalio.com > >
-- CTO, Intalio http://www.intalio.com
