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.
Given those restrictions, would it be possible to use the server for development, since signatures change a lot during development? What about signatures that remain the same, yet break the expected behavior? I'm worried that we're trying to force a practice onto the implementation, thereby creating an implementation that doesn't validate anything, but limits your ability to actually use it. What do people who implement services in any other tool (Axis, Tuscany, etc) do? Is this really a problem unique to BPEL? Assaf -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 > > > >
-- CTO, Intalio http://www.intalio.com
