Lance, Looks like I may have difficulty following myself. You are correct, #1 would be too restrictive.
-mbs On Thu, 2006-08-10 at 07:50 -0600, Lance Waterman wrote: > 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 > > > > > > > >
