The restrictions I proposed are not intended to be a help to the user. They are intended to ensure that a reasonable implementation is possible. Requirements 2 and 3 are there because you should know what the message type of the received message is before you do the version routing: your communication channel is likely going to be hard-coded to the same binding for all versions (i.e. you are listening on the same URL for all versions), and you need to apply correlation logic before you know what version the message is targeting). So it makes sense that all version would need to have the same message format. -mbs
On Wed, 2006-08-09 at 17:50 -0700, Assaf Arkin wrote: > 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
