Maciej, Earlier in this thread you stated:
This requirement is too restrictive. A new process version could have additional interactions (partnerlinks/receives). Also, it could eliminate interactions.
I took this to mean item 1 in your restriction list here would not be a restriction. I just want to make sure I'm following you correctly. Thanks, Lance On 8/9/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Lance, Let me clarify here. We do not have a notion of "process interface" except in the sense that the process exposes a number of services with various portTypes. Changes to this "interface" will be common, and versioning should permit it. Imagine the prototypical BPEL scenario: a reservation process. Assume I've created the bare minimum implementation. My process only has one partner link, implementing one port type, with only one operation, "reserve". I deploy this process and expose my partnerlink as service "foo:reservationService". I tell the world, and clients start calling "foo:reservationService".reserve to make reservations. Now I want to add a "cancel" method to my portType. If I do this, the "interface" of the process changes, but it doesn't matter. Those old clients that have not been informed of the change can still operate under their old assumption that there is no "cancel" method, they continue to call "foo:reservationService".reserve. I should be able to deploy this new process as a "version" of the old. In this instance the externally observable behavior of the process has not changed to the old clients. 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. -maciej On Tue, 2006-08-08 at 16:18 -0600, 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 <[EMAIL PROTECTED]> 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 > > > >
