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.
There's an issue whereby some changes to signature of the service break if
you need to simulatenously route to old and new versions. It's not in any
way unique to process engine, it's a problem that exists in any system that
routes messages from the same channel to different receivers based on the
content of the message.
Out of all the possible solutions, my preference is to keep services intact
from the moment they are established. As a result you're not enforcing
anything, or creating any code to detect mismatches. New versions that are
not backward compatible break, and just like signatures in Java objects, you
detect that by testing.
That allows you, for example, to change datatypes and signatures as long as
you retain backward compatibilty. It lets you version data types using the
XML model of versioning by extension and derivation.
Assaf
On 8/10/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
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
--
CTO, Intalio
http://www.intalio.com
