You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Lance Waterman <la...@gmail.com> on 2006/08/08 15:54:50 UTC
Issue 10
Normalizing the deployment spec to the Ode trunk, it looks like the main
feature that needs to be added into the implementation is version support. I
plan to add in version support under issue 10 unless I hear otherwise.
Do folks have any input/thoughts on an Ode code style template ( note: I am
using the Eclipse IDE )?
Lance
Re: Code style
Posted by Matthieu Riou <ma...@gmail.com>.
And what about not truncating lines with more than 70 characters? Maybe
pushing the limit up to 120 characters? Like who has an editor opened with
only 70 characters width nowadays? Just one more on the pet peeve list :)
On 8/8/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> I use the "Java Convention" with 2 space indentation. The eclipse format
> seems to be nearly identical. I'm not against four spaces but I'm afraid
> it would mean that I'd have to upgrade to a wide-screen laptop :). Only
> pet peeve is ^M and tab.
>
> -mbs
> On Tue, 2006-08-08 at 08:25 -0700, Alex Boisvert wrote:
> > Re: Code style, I don't have a good template to share and I'd be very
> > interested in sharing one between all developers.
> >
> > Hey Maciej - do you use one? Seems like we're following your style so
> > it would be nice if you could set the standard. I'd also be curious to
> > know if you'd be amenable to switching to 4-space indentation (from the
> > current 2-space) which seems to be the norm in most Java projects.
> >
> > alex
> >
> >
> > Lance Waterman wrote:
> > > Normalizing the deployment spec to the Ode trunk, it looks like the
> main
> > > feature that needs to be added into the implementation is version
> > > support. I
> > > plan to add in version support under issue 10 unless I hear otherwise.
> > >
> > > Do folks have any input/thoughts on an Ode code style template ( note:
> > > I am
> > > using the Eclipse IDE )?
> > >
> > > Lance
> > >
> >
>
>
Re: Code style
Posted by Alex Boisvert <bo...@intalio.com>.
Ok, thanks for the clarification. I think it's important that we all
use the same format and that's why I was proposing something I thought
was more common. If 2-space indentation is also used widely, then I
don't have a concern.
Can you share your Eclipse code template style? Maybe we could place it
in SVN?
alex
Maciej Szefler wrote:
> I use the "Java Convention" with 2 space indentation. The eclipse format
> seems to be nearly identical. I'm not against four spaces but I'm afraid
> it would mean that I'd have to upgrade to a wide-screen laptop :). Only
> pet peeve is ^M and tab.
>
> -mbs
> On Tue, 2006-08-08 at 08:25 -0700, Alex Boisvert wrote:
>
>> Re: Code style, I don't have a good template to share and I'd be very
>> interested in sharing one between all developers.
>>
>> Hey Maciej - do you use one? Seems like we're following your style so
>> it would be nice if you could set the standard. I'd also be curious to
>> know if you'd be amenable to switching to 4-space indentation (from the
>> current 2-space) which seems to be the norm in most Java projects.
>>
>> alex
>>
>>
>> Lance Waterman wrote:
>>
>>> Normalizing the deployment spec to the Ode trunk, it looks like the main
>>> feature that needs to be added into the implementation is version
>>> support. I
>>> plan to add in version support under issue 10 unless I hear otherwise.
>>>
>>> Do folks have any input/thoughts on an Ode code style template ( note:
>>> I am
>>> using the Eclipse IDE )?
>>>
>>> Lance
>>>
>>>
>
>
>
Re: Code style
Posted by Maciej Szefler <mb...@intalio.com>.
I use the "Java Convention" with 2 space indentation. The eclipse format
seems to be nearly identical. I'm not against four spaces but I'm afraid
it would mean that I'd have to upgrade to a wide-screen laptop :). Only
pet peeve is ^M and tab.
-mbs
On Tue, 2006-08-08 at 08:25 -0700, Alex Boisvert wrote:
> Re: Code style, I don't have a good template to share and I'd be very
> interested in sharing one between all developers.
>
> Hey Maciej - do you use one? Seems like we're following your style so
> it would be nice if you could set the standard. I'd also be curious to
> know if you'd be amenable to switching to 4-space indentation (from the
> current 2-space) which seems to be the norm in most Java projects.
>
> alex
>
>
> Lance Waterman wrote:
> > Normalizing the deployment spec to the Ode trunk, it looks like the main
> > feature that needs to be added into the implementation is version
> > support. I
> > plan to add in version support under issue 10 unless I hear otherwise.
> >
> > Do folks have any input/thoughts on an Ode code style template ( note:
> > I am
> > using the Eclipse IDE )?
> >
> > Lance
> >
>
Re: Code style
Posted by Alex Boisvert <bo...@intalio.com>.
Re: Code style, I don't have a good template to share and I'd be very
interested in sharing one between all developers.
Hey Maciej - do you use one? Seems like we're following your style so
it would be nice if you could set the standard. I'd also be curious to
know if you'd be amenable to switching to 4-space indentation (from the
current 2-space) which seems to be the norm in most Java projects.
alex
Lance Waterman wrote:
> Normalizing the deployment spec to the Ode trunk, it looks like the main
> feature that needs to be added into the implementation is version
> support. I
> plan to add in version support under issue 10 unless I hear otherwise.
>
> Do folks have any input/thoughts on an Ode code style template ( note:
> I am
> using the Eclipse IDE )?
>
> Lance
>
Re: Issue 10
Posted by Maciej Szefler <mb...@intalio.com>.
Yep,
I think this a pretty big one, should have its own issue.
-mbs
On Tue, 2006-08-08 at 08:30 -0700, Alex Boisvert wrote:
> Considering that version support spans more than the deployment phase, I
> would suggest creating distinct and more specific issue(s) for tracking
> versioning aspects and link them to ODE-10 for cross-referencing when
> relevant.
>
> alex
>
>
> Lance Waterman wrote:
> > Normalizing the deployment spec to the Ode trunk, it looks like the main
> > feature that needs to be added into the implementation is version
> > support. I
> > plan to add in version support under issue 10 unless I hear otherwise.
> >
> > Do folks have any input/thoughts on an Ode code style template ( note:
> > I am
> > using the Eclipse IDE )?
> >
> > Lance
> >
>
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Alex,
inline ...
Lance
On 8/10/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Alex Boisvert wrote:
> > Maciej Szefler wrote:
> >> 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.
> >>
> > Personally, I still find this too restrictive. My proposal would be
> > to consider the version attribute as part of the process identifier --
> > effectively making two processes with the same name+namespace but with
> > different version identifiers completely unrelated from an
> > implementation standpoint. The deployment rules for two such
> > processes would be the same as if they did not share common
> > name+namespace.
>
> As further clarification, I think it should be a responsibility of the
> tooling around the engine to define/enforce a given deployment and
> activation policy.
I agree and I think Paul Brown had some thoughts around importing and
enforcing these policies within the deployment engine. A bit too agressive
for me but certainly worth thinking abount.
For instance, the tooling could automatically
> undeploy or retire previous versions of a process when deploying a new
> one. It could even automatically wipe out previous instances if I'm
> working in development mode (versus production).
>
> So I would prefer an approach where the engine provides general
> mechanisms for managing process versions and we leave it to the
> integration layer / tooling around the engine to define particular
> behavior related to lifecycle management.
I agree however I think there are some minimal requirements/policies that
the engine defines and I think to date I see those as restrictions 2 and 3
as defined by Maciej.
alex
>
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Alex Boisvert wrote:
> Maciej Szefler wrote:
>> 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.
>>
> Personally, I still find this too restrictive. My proposal would be
> to consider the version attribute as part of the process identifier --
> effectively making two processes with the same name+namespace but with
> different version identifiers completely unrelated from an
> implementation standpoint. The deployment rules for two such
> processes would be the same as if they did not share common
> name+namespace.
As further clarification, I think it should be a responsibility of the
tooling around the engine to define/enforce a given deployment and
activation policy. For instance, the tooling could automatically
undeploy or retire previous versions of a process when deploying a new
one. It could even automatically wipe out previous instances if I'm
working in development mode (versus production).
So I would prefer an approach where the engine provides general
mechanisms for managing process versions and we leave it to the
integration layer / tooling around the engine to define particular
behavior related to lifecycle management.
alex
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Alex,
Could you please walk through a couple of deployment/management scenarios
and talk about how/when process definition state changes ( "active",
"retired" ) explicitly vs. implicitly. I'm hoping this exercise will help me
understand this statement:
>>The deployment rules for two such processes
>>would be the same as if they did not share common name+namespace.
Given collisions ( see Maciej's restrictions 2 and 3 ) within the same
name+namespace ( at runtime ) I don't see how these can be the same at
deployment time.
Thanks,
Lance
On 8/10/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Maciej Szefler wrote:
> > 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.
> >
> Personally, I still find this too restrictive. My proposal would be to
> consider the version attribute as part of the process identifier --
> effectively making two processes with the same name+namespace but with
> different version identifiers completely unrelated from an
> implementation standpoint. The deployment rules for two such processes
> would be the same as if they did not share common name+namespace.
>
> alex
>
>
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Maciej Szefler wrote:
> 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.
>
Personally, I still find this too restrictive. My proposal would be to
consider the version attribute as part of the process identifier --
effectively making two processes with the same name+namespace but with
different version identifiers completely unrelated from an
implementation standpoint. The deployment rules for two such processes
would be the same as if they did not share common name+namespace.
alex
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
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 <mb...@intalio.com> 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 <bo...@intalio.com> 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
> > >
> > >
>
>
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
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 <mb...@intalio.com> 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 <bo...@intalio.com> 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
> > >
> > >
>
>
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
It sounds like you are asking the runtime to detect operation overloading
which seems complex and expensive ( if even doable ) to me. What happens
when there truely is an operation naming collision between versions?
Lance
On 8/10/06, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> If we make no assumptions on the commonality or evolution of interfaces
> between process versions, then routing should follow the same rules as
> for routing between different processes. Different process versions
> would be treated as different processes. Wouldn't we save ourselves
> some complexity by doing so?
>
> alex
>
>
> Maciej Szefler 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
> >
>
>
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
On 8/10/06, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> If we make no assumptions on the commonality or evolution of interfaces
> between process versions, then routing should follow the same rules as
> for routing between different processes. Different process versions
> would be treated as different processes. Wouldn't we save ourselves
> some complexity by doing so?
>
I like the idea that if I deploy a process, change it, deploy it again, the
engine is smart enough to automatically retire the old version, yet keep the
old definition accessible as long as instances exist, and as audit trail. I
could then look back at the history, roll back changes, etc.
A good deployment system for long running Java objects, wikis, versioned
control file systems and databases all work the same way. New version
replaces old one, old references point to old version.
There's great convenience in this feature, and great convenience in the
consistency.
Anything different requires extraordinary justification which I'm not
seeing, otherwise it's complex by virtue of surprise.
Assaf
alex
>
>
> Maciej Szefler 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
> >
>
>
--
CTO, Intalio
http://www.intalio.com
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
If we make no assumptions on the commonality or evolution of interfaces
between process versions, then routing should follow the same rules as
for routing between different processes. Different process versions
would be treated as different processes. Wouldn't we save ourselves
some complexity by doing so?
alex
Maciej Szefler 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
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Guys,
I sense the majority is veering towards a single lifecycle policy
enforced by the engine (i.e., automatically retiring older process
version when deploying a new one). I'm fine with that despite not being
my preference. A well-defined and understood policy is better than many
confusing ones. I don't want to drag the discussion any longer so I
suggest moving ahead with the finer details of that approach.
alex
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
> 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 <mb...@intalio.com> 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 <mb...@intalio.com> 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 <bo...@intalio.com> 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
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
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 <mb...@intalio.com> 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 <bo...@intalio.com> 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
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
On 8/9/06, Maciej Szefler <mb...@intalio.com> 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 <bo...@intalio.com> 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
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
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 <bo...@intalio.com> 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
> >
> >
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Alex,
see inline ...
Lance
On 8/9/06, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> Lance,
>
> Sorry for the late email, we had an email outage last night. If not
> sure if this is still relevant now given your earlier email exchanges
> with Assaf, but see my comments below to further clarify what I meant.
>
> Lance Waterman wrote:
> > I think what I hear you saying is that you want to be able to aggregate
> > several versions of a BPEL process into a single service interface. Such
> > that this aggregated service interface can serve as the interface for
> > several BPEL process versions. I understand this however, what do you
> > propose when the operation+endpoint are identical between process
> > versions?
> > How does the engine know which one to route to ( and I don't want to
> > require
> > a change to the client )?
>
> Not really. I simply want to be able to deploy and activate P(v1) and
> P(v2) simultaneously if they have no conflicting operation+endpoint
> tuples.
If I understand you here this does not seem to follow the conclusions from
the other thread ( see Assaf's reply ). So perhaps we need more input from
you on that thread.
This is a development convenience and also leaves the
> flexibility and responsibility to the author of the processes to define
> what a "version" means.
>
> The only real requirement that I see is for the engine to be able to
> detect conflicts during activation to prevent non-deterministic routing
> cases (see below).
>
> >
> > Say I change the signature of a Java class, do I need to change its
> name?
> >
> >
> > Alex, I think using Java as an analogy is a good way to convey
> > patterns/concepts however, when it's posted as a rhetorical question
> like
> > this I think it comes across a bit condescending. I'm sure that wasn't
> > your
> > intent but none the less it doesn't work for me. Now, to move forward
> > with
> > your analogy, if I were able to deprecate ( i.e. retire ) specific
> > operations - is that where you are going? Is this something that shows
> > up in
> > the service interface? Does the operation just stop working for
> > deprecated
> > operations?
> My apologies, Lance, I did not mean to offend.
No need, it was a silly comment on my part ( I would like to chalk it up to
time of day, work load and poor choice of inferences on my part )
To answer your questions, I do not see a need to deprecate/retire
> individual initiating operations within a process. I think a process
> should either be completely activated or completely retired, meaning
> that all of its initiating operations should be either enabled or
> disabled. And if one or more operation+endpoint conflicts with any
> other activated process (across all versions), the engine should prevent
> the activation of the process.
I'm not sure if this follows the current thread?
regards,
> alex
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Lance,
Sorry for the late email, we had an email outage last night. If not
sure if this is still relevant now given your earlier email exchanges
with Assaf, but see my comments below to further clarify what I meant.
Lance Waterman wrote:
> I think what I hear you saying is that you want to be able to aggregate
> several versions of a BPEL process into a single service interface. Such
> that this aggregated service interface can serve as the interface for
> several BPEL process versions. I understand this however, what do you
> propose when the operation+endpoint are identical between process
> versions?
> How does the engine know which one to route to ( and I don't want to
> require
> a change to the client )?
Not really. I simply want to be able to deploy and activate P(v1) and
P(v2) simultaneously if they have no conflicting operation+endpoint
tuples. This is a development convenience and also leaves the
flexibility and responsibility to the author of the processes to define
what a "version" means.
The only real requirement that I see is for the engine to be able to
detect conflicts during activation to prevent non-deterministic routing
cases (see below).
>
> Say I change the signature of a Java class, do I need to change its name?
>
>
> Alex, I think using Java as an analogy is a good way to convey
> patterns/concepts however, when it's posted as a rhetorical question like
> this I think it comes across a bit condescending. I'm sure that wasn't
> your
> intent but none the less it doesn't work for me. Now, to move forward
> with
> your analogy, if I were able to deprecate ( i.e. retire ) specific
> operations - is that where you are going? Is this something that shows
> up in
> the service interface? Does the operation just stop working for
> deprecated
> operations?
My apologies, Lance, I did not mean to offend.
To answer your questions, I do not see a need to deprecate/retire
individual initiating operations within a process. I think a process
should either be completely activated or completely retired, meaning
that all of its initiating operations should be either enabled or
disabled. And if one or more operation+endpoint conflicts with any
other activated process (across all versions), the engine should prevent
the activation of the process.
regards,
alex
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Alex,
inline ...
On 8/8/06, Alex Boisvert <boisvert@intalio.com > wrote:
>
>
> What is the benefit of forcing the service signature to be the same for
> a given process name? Is there a complexity aspect that I am
> missing? It seems like the engine is trying to enforce a specific
> policy instead of providing a flexible deployment mechanism.
I think what I hear you saying is that you want to be able to aggregate
several versions of a BPEL process into a single service interface. Such
that this aggregated service interface can serve as the interface for
several BPEL process versions. I understand this however, what do you
propose when the operation+endpoint are identical between process versions?
How does the engine know which one to route to ( and I don't want to require
a change to the client )?
Say I change the signature of a Java class, do I need to change its name?
Alex, I think using Java as an analogy is a good way to convey
patterns/concepts however, when it's posted as a rhetorical question like
this I think it comes across a bit condescending. I'm sure that wasn't your
intent but none the less it doesn't work for me. Now, to move forward with
your analogy, if I were able to deprecate ( i.e. retire ) specific
operations - is that where you are going? Is this something that shows up in
the service interface? Does the operation just stop working for deprecated
operations?
alex
>
> 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 <bo...@intalio.com> 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
> >>
> >>
> >
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
What is the benefit of forcing the service signature to be the same for
a given process name? Is there a complexity aspect that I am
missing? It seems like the engine is trying to enforce a specific
policy instead of providing a flexible deployment mechanism.
Say I change the signature of a Java class, do I need to change its name?
alex
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 <bo...@intalio.com> 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
>>
>>
>
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
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 <bo...@intalio.com> 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
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
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
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
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").
-mbs
On Tue, 2006-08-08 at 14:11 -0700, Alex Boisvert wrote:
> Ok, so maybe the wording was confusing so I'll give a concrete example
> or two to clarify.
>
> Say I deploy process P (v1) with initiating operation "foo" on endpoint
> "bar"
>
> I cannot redeploy a new version of P with the same operation and same
> endpoint unless P (v1) has been retired or undeployed.
>
> If I retire P (v1) and deploy a new P (v2) with the same operation and
> endpoint, then I cannot reactivate P (v1) unless P (v2) has been retired
> or undeployed.
>
> alex
>
>
> Maciej Szefler wrote:
> > Alex,
> > I don't think the following makes sense:
> >
> > On Tue, 2006-08-08 at 11:26 -0700, Alex Boisvert wrote:
> >
> >> New process definitions may "override" the initiating operations and
> >> endpoints of retired process definitions to provide transparent
> >> migration to existing service consumers. To prevent conflicts,
> >> deploying a process definition using the same initiating operation(s)
> >> and the same endpoint(s) of an already deployed process should fail.
> >> Similarly, retired processes could be re-activated if no process
> >> currently uses the same initiating operation(s) on the same endpoints.
> >>
> >
> > A new process version, should--in fact I think it must--have the same
> > initiating operations and endpoints. The new version of the process is
> > deployed in the server on exactly the same endpoints as the old. The
> > server manages the routing to make sure that the correct version of the
> > process receives the correct messages. This can be done fairly easily
> > and allows the "client" of the process to be completely oblivious to the
> > fact that a new version has been deployed: the client keeps sending
> > messages to the same BPEL engine endpoint.
> > -mbs
> >
> >
> >
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Ok, so maybe the wording was confusing so I'll give a concrete example
or two to clarify.
Say I deploy process P (v1) with initiating operation "foo" on endpoint
"bar"
I cannot redeploy a new version of P with the same operation and same
endpoint unless P (v1) has been retired or undeployed.
If I retire P (v1) and deploy a new P (v2) with the same operation and
endpoint, then I cannot reactivate P (v1) unless P (v2) has been retired
or undeployed.
alex
Maciej Szefler wrote:
> Alex,
> I don't think the following makes sense:
>
> On Tue, 2006-08-08 at 11:26 -0700, Alex Boisvert wrote:
>
>> New process definitions may "override" the initiating operations and
>> endpoints of retired process definitions to provide transparent
>> migration to existing service consumers. To prevent conflicts,
>> deploying a process definition using the same initiating operation(s)
>> and the same endpoint(s) of an already deployed process should fail.
>> Similarly, retired processes could be re-activated if no process
>> currently uses the same initiating operation(s) on the same endpoints.
>>
>
> A new process version, should--in fact I think it must--have the same
> initiating operations and endpoints. The new version of the process is
> deployed in the server on exactly the same endpoints as the old. The
> server manages the routing to make sure that the correct version of the
> process receives the correct messages. This can be done fairly easily
> and allows the "client" of the process to be completely oblivious to the
> fact that a new version has been deployed: the client keeps sending
> messages to the same BPEL engine endpoint.
> -mbs
>
>
>
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
Alex,
I don't think the following makes sense:
On Tue, 2006-08-08 at 11:26 -0700, Alex Boisvert wrote:
> New process definitions may "override" the initiating operations and
> endpoints of retired process definitions to provide transparent
> migration to existing service consumers. To prevent conflicts,
> deploying a process definition using the same initiating operation(s)
> and the same endpoint(s) of an already deployed process should fail.
> Similarly, retired processes could be re-activated if no process
> currently uses the same initiating operation(s) on the same endpoints.
A new process version, should--in fact I think it must--have the same
initiating operations and endpoints. The new version of the process is
deployed in the server on exactly the same endpoints as the old. The
server manages the routing to make sure that the correct version of the
process receives the correct messages. This can be done fairly easily
and allows the "client" of the process to be completely oblivious to the
fact that a new version has been deployed: the client keeps sending
messages to the same BPEL engine endpoint.
-mbs
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
>>The only requirement really
>>is that for the operations that are used by both the old version and the
>>new version, the signature of the operation must not change from version
>>to version.
Agreed, I'll change the wording to reflect this.
On 8/8/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> Lance,
>
> comments inline.
>
> On Tue, 2006-08-08 at 15:00 -0600, Lance Waterman wrote:
> > Alex,
> >
> > comments inline ...
> >
> > Lance
> >
> >
> > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > Lance,
> > >
> > > For consideration, I would like to briefly review the design that I
> had
> > > in mind for versioning in PXE. I think it's similar in spirit to what
> > > you describe in your deployment spec.
> > >
> > > First, each process definition would be identified by its fully
> > > qualified name (/name/ and /namespace/ attributes) and a version
> > > number. The process engine would manage the version number in a
> > > monotonically increasing fashion, meaning that each time a process is
> > > redeployed, the version number increases.
> >
> >
> > I don't understand the need for a version number that is managed by the
> > engine. I think a client may use whatever version scheme they use. We
> just
> > need to validate that the version identifier is unique at deployment
> time.
> The benefit of a version number is that all the processes versions can
> be easily grouped (since they all share the same process identifier).
> However, this does create a hierarchy that is from a technically
> perspective non-essential.
>
> > Process definitions may be either activated or retired. Activated
> > > processes are available for instantiation whereas retired processes
> may
> > > not be instantiated -- the initiating operations are effectively
> disabled.
> >
> >
> > I don't understand the need for this given the concept of "current"
> given
> > below.
> My understanding is that these two concepts are identical: current ==
> activated, not current == retired. I prefer the "current" terminology as
> it will not be confused with process activation, which occurs when the
> server starts up.
>
>
> > New process definitions may "override" the initiating operations and
> > > endpoints of retired process definitions to provide transparent
> > > migration to existing service consumers. To prevent conflicts,
> > > deploying a process definition using the same initiating operation(s)
> > > and the same endpoint(s) of an already deployed process should fail.
> > > Similarly, retired processes could be re-activated if no process
> > > currently uses the same initiating operation(s) on the same endpoints.
> >
> >
> > I agree with Maciej's comments on this and would like to add from the
> > deployment spec under sec 1.2.5:
> >
> > *CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
> > element ) for a process definition will require a new identifier ( i.e.
> > name/namespace ) within the definition repository. Versioning is not
> > supported across changes in the service interface and shall be enforced
> by
> > the deployment component.*
> >
> > I would like to make sure folks are okay with this as well.
> This requirement is too restrictive. A new process version could have
> additional interactions (partnerlinks/receives). Also, it could
> eliminate interactions. If you consider this as a routing problem, then
> this creates no difficulties for the engine. The only requirement really
> is that for the operations that are used by both the old version and the
> new version, the signature of the operation must not change from version
> to version.
>
> > In general I would like to define the concept of a "current" process
> > definition. The "current" process definition is the definition used by
> the
> > engine on an instantiating event. There could be instances running in
> the
> > engine that are using other versions of a process definition, however
> its
> > not possible to have multiple versions that are used for instantiating
> new
> > processes ( see Maciej's reply on endpoints ). Through management
> tooling a
> > client will identify the "current" process.
> >
> > Users would have different choices when it comes to managing version
> > > numbers. First, they can always use the name+namespace as with most
> > > XML-based specs. If they want to deploy multiple processes with the
> > > same name+namespace tuple, they could adopt the internal version
> numbers
> > > if they don't have anything better, or they could supply version
> > > information as meta-data when deploying the process definition. This
> > > meta-data could contain user-defined versioning tags, with values such
> > > as "myBranch-v2", or "Oct. 12th 2006". The PM API should support
> > > querying using both the internal version number and custom meta-data.
> > > Some of this is covered by
> > >
> > >
> http://pxe.intalio.org/confluence/display/PXE/BPEL+Management+API+Specification
> > > .
> >
> >
> > Again, I'm hesitant to come up with some internal scheme ( don't want
> the
> > runtime to start looking like a metadata repository ) but rather depend
> on
> > the client to come up with their own version number scheme ( i.e.
> > "myBranch-v2", or "Oct. 12th 2006" ).
> >
> > This design is relatively simple and does not account for migrating
> > > instances between process versions, which is a more complex topic that
> > > we should eventually discuss in relation with Jacob.
> > >
> > > Is this in line with your current thinking?
> > >
> > > alex
> > >
> > >
> > >
>
>
Re: Issue 10 / Versioning
Posted by Maciej Szefler <mb...@intalio.com>.
Lance,
comments inline.
On Tue, 2006-08-08 at 15:00 -0600, Lance Waterman wrote:
> Alex,
>
> comments inline ...
>
> Lance
>
>
> On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > Lance,
> >
> > For consideration, I would like to briefly review the design that I had
> > in mind for versioning in PXE. I think it's similar in spirit to what
> > you describe in your deployment spec.
> >
> > First, each process definition would be identified by its fully
> > qualified name (/name/ and /namespace/ attributes) and a version
> > number. The process engine would manage the version number in a
> > monotonically increasing fashion, meaning that each time a process is
> > redeployed, the version number increases.
>
>
> I don't understand the need for a version number that is managed by the
> engine. I think a client may use whatever version scheme they use. We just
> need to validate that the version identifier is unique at deployment time.
The benefit of a version number is that all the processes versions can
be easily grouped (since they all share the same process identifier).
However, this does create a hierarchy that is from a technically
perspective non-essential.
> Process definitions may be either activated or retired. Activated
> > processes are available for instantiation whereas retired processes may
> > not be instantiated -- the initiating operations are effectively disabled.
>
>
> I don't understand the need for this given the concept of "current" given
> below.
My understanding is that these two concepts are identical: current ==
activated, not current == retired. I prefer the "current" terminology as
it will not be confused with process activation, which occurs when the
server starts up.
> New process definitions may "override" the initiating operations and
> > endpoints of retired process definitions to provide transparent
> > migration to existing service consumers. To prevent conflicts,
> > deploying a process definition using the same initiating operation(s)
> > and the same endpoint(s) of an already deployed process should fail.
> > Similarly, retired processes could be re-activated if no process
> > currently uses the same initiating operation(s) on the same endpoints.
>
>
> I agree with Maciej's comments on this and would like to add from the
> deployment spec under sec 1.2.5:
>
> *CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
> element ) for a process definition will require a new identifier ( i.e.
> name/namespace ) within the definition repository. Versioning is not
> supported across changes in the service interface and shall be enforced by
> the deployment component.*
>
> I would like to make sure folks are okay with this as well.
This requirement is too restrictive. A new process version could have
additional interactions (partnerlinks/receives). Also, it could
eliminate interactions. If you consider this as a routing problem, then
this creates no difficulties for the engine. The only requirement really
is that for the operations that are used by both the old version and the
new version, the signature of the operation must not change from version
to version.
> In general I would like to define the concept of a "current" process
> definition. The "current" process definition is the definition used by the
> engine on an instantiating event. There could be instances running in the
> engine that are using other versions of a process definition, however its
> not possible to have multiple versions that are used for instantiating new
> processes ( see Maciej's reply on endpoints ). Through management tooling a
> client will identify the "current" process.
>
> Users would have different choices when it comes to managing version
> > numbers. First, they can always use the name+namespace as with most
> > XML-based specs. If they want to deploy multiple processes with the
> > same name+namespace tuple, they could adopt the internal version numbers
> > if they don't have anything better, or they could supply version
> > information as meta-data when deploying the process definition. This
> > meta-data could contain user-defined versioning tags, with values such
> > as "myBranch-v2", or "Oct. 12th 2006". The PM API should support
> > querying using both the internal version number and custom meta-data.
> > Some of this is covered by
> >
> > http://pxe.intalio.org/confluence/display/PXE/BPEL+Management+API+Specification
> > .
>
>
> Again, I'm hesitant to come up with some internal scheme ( don't want the
> runtime to start looking like a metadata repository ) but rather depend on
> the client to come up with their own version number scheme ( i.e.
> "myBranch-v2", or "Oct. 12th 2006" ).
>
> This design is relatively simple and does not account for migrating
> > instances between process versions, which is a more complex topic that
> > we should eventually discuss in relation with Jacob.
> >
> > Is this in line with your current thinking?
> >
> > alex
> >
> >
> >
Re: Issue 10 / Versioning
Posted by Matthieu Riou <ma...@gmail.com>.
More inlining...
I don't understand the need for a version number that is managed by the
> engine. I think a client may use whatever version scheme they use. We just
> need to validate that the version identifier is unique at deployment time.
>
It's always nice to have a default behaviour. So we can have an easy 80% of
cases where you just redeploy the same process and don't care what its
versio number will be.
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
I see, sorry for the confusion. For some reason I was trying to tie this
back to the active/retired discussion.
Lance
On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
>
> Lance,
>
> I'm pointing out that any restrictions we place on naming the process will
> bear no affect on the client. It doesn't make the client life easier, ror
> protect the client from breakage, but it could make development harder.
>
> Assaf
>
> On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
> >
> > Assaf,
> >
> > I'm not following all of this. My main goal here is not to break the
> > client
> > when a process is redeployed.
> >
> > Lance
> >
> >
> > On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> > >
> > > The client breaks when the endpoint changes, or the
> messages/operations
> > > accepted by the endpoint change.
> > >
> > > Whenever you deploy a new version -- same or different name, version
> > > number,
> > > tagged or not -- that accepts the same messages on the same endpoints,
> > the
> > > client does not perceive any difference. It still invokes the process
> > the
> > > same way, regardless of how the server chooses to refer to that
> process
> > > definition.
> > >
> > > However, changing the signature and changing the process name, breaks
> > the
> > > client. Because the client does not talk to the process, the client
> > talks
> > > to
> > > the service, and so changing the signature breaks the client. Changing
> > the
> > > process name is immaterial.
> > >
> > > A restriction that "if you change the signature you must change the
> > > process
> > > name" does not in any way protect the client from breaking, but makes
> > life
> > > incredibly hard for developers. It's like asking you to change the
> Java
> > > class name every time you change its signature. When you're writing
> > code,
> > > how often do you change signatures?
> > >
> > > Assaf
> > >
> > > On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
> > > >
> > > > Assaf,
> > > >
> > > > From a client application's perspective which of the three options
> > > > requires
> > > > a change in the way I send a message into the BPEL engine?
> > > >
> > > > Lance
> > > >
> > > >
> > > > On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> > > > >
> > > > > Reading through the BPEL spec, I get the impression that however
> you
> > > > > decide
> > > > > to name a process is meaningless. If you send a message to its
> > > > initiating
> > > > > activity it will start. If you send a message to the wrong
> endpoint,
> > > it
> > > > > won't.
> > > > >
> > > > > So clearly people who want to version processes need to take into
> > > > account
> > > > > that Bar replacing Foo on same instantiating activity, means Bar
> is
> > > the
> > > > > version you now use, not Foo. Which means you can get really
> > creative
> > > > with
> > > > > process names, like Order, OrderV1,
> > Order_V2_With_25%_More_Activities.
> > > > >
> > > > >
> > > > > But there are two requirements you can't solve with overriding and
> > > > naming.
> > > > >
> > > > > One, only very few people can actual design, deploy and forget.
> Most
> > > > > people
> > > > > go through some iterative process, so you end up deploying
> different
> > > > > iterations of the same process as you're working to get it to
> done.
> > > And
> > > > > naming each deployment, that's like saving every draft you write
> > under
> > > a
> > > > > different name.
> > > > >
> > > > > The source control approach is much better, it gives each version
> a
> > > > serial
> > > > > number and datetime stamp, so you can easily track changes and
> > > rollback.
> > > > > If
> > > > > you have some instance running, you know which process definition
> it
> > > > > belongs
> > > > > to: not the name, but the actual definition you pushed to the
> server
> > > > > before
> > > > > it was instantiated.
> > > > >
> > > > > (In some other development environments, deployment happens
> strictly
> > > > > through
> > > > > SVN and people in fact use the SVN version number to mark each
> > > release)
> > > > >
> > > > > Two, numbers and timestamps are fine but a burden when you do want
> > to
> > > > > track
> > > > > milestone releases, especially in production. So you want to
> > associate
> > > > > some
> > > > > meaningful name, usually related to that milestone, like "Release
> > 1",
> > > > > "Release 1.1", whatever. A tagging mechanism separate from the
> > process
> > > > > name
> > > > > has the benefit that you can clearly see its timeline, searching
> by
> > > > name,
> > > > > ordering by sequential version number, and displaying those tags.
> > > > >
> > > > > If tags sound familiar, source control does that as well.
> > > > >
> > > > >
> > > > > So I personally prefer a system whereby:
> > > > > 1. I can replace Foo with Bar because I decide Foo is a better
> name,
> > > and
> > > > > it's taking over Bar's role (same instantiation).
> > > > > 2. Or replace Foo with another Foo, and be able to see sequence of
> > > > > deployment using serial number/datetime I don't have to worry
> about.
> > > > > 3. Or affix a specific version label/tag.
> > > > >
> > > > > #1, I don't see that happening often, and you can always retire
> Foo
> > > and
> > > > > activate Bar.
> > > > >
> > > > > #2 is something the server already has to do in order to maintain
> > > > > instances
> > > > > using the old version, so just give me access to the sequence
> > > > > number/deployment timestamp.
> > > > >
> > > > > #3 is a really nice feature to have.
> > > > >
> > > > > Assaf
> > > > >
> > > > >
> > > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > > > >
> > > > > > Lance Waterman wrote:
> > > > > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > > > > >>
> > > > > > >> Lance,
> > > > > > >>
> > > > > > >> For consideration, I would like to briefly review the design
> > that
> > > I
> > > > > had
> > > > > > >> in mind for versioning in PXE. I think it's similar in
> spirit
> > to
> > > > > what
> > > > > > >> you describe in your deployment spec.
> > > > > > >>
> > > > > > >> First, each process definition would be identified by its
> fully
> > > > > > >> qualified name (/name/ and /namespace/ attributes) and a
> > version
> > > > > > >> number. The process engine would manage the version number
> in
> > a
> > > > > > >> monotonically increasing fashion, meaning that each time a
> > > process
> > > > is
> > > > > > >> redeployed, the version number increases.
> > > > > > >
> > > > > > >
> > > > > > > I don't understand the need for a version number that is
> managed
> > > by
> > > > > the
> > > > > > > engine. I think a client may use whatever version scheme they
> > use.
> > > > We
> > > > > > > just
> > > > > > > need to validate that the version identifier is unique at
> > > deployment
> > > > > > > time.
> > > > > > There is no strict need for a version number managed by the
> > > engine. I
> > > > > > think this idea came up when we wanted to simplify the
> management
> > > > > > interfaces and wanted to avoid the need for an extra
> user-provided
> > > > > > identifier if you already encoded version information in the
> > > > > > name+namespace. It made it easier to define and communicate the
> > > > > > "latest" process version.
> > > > > >
> > > > > > > I agree with Maciej's comments on this and would like to add
> > from
> > > > the
> > > > > > > deployment spec under sec 1.2.5:
> > > > > > >
> > > > > > > *CONSTRAINT: Any change in the service interface ( i.e. a new
> > > > > <receive>
> > > > > > > element ) for a process definition will require a new
> identifier
> > (
> > > > i.e
> > > > > .
> > > > > > > name/namespace ) within the definition repository. Versioning
> is
> > > not
> > > > > > > supported across changes in the service interface and shall be
> > > > > > > enforced by
> > > > > > > the deployment component.*
> > > > > > >
> > > > > > > I would like to make sure folks are okay with this as well.
> > > > > > Personally, I would be against this because it would mean that I
> > > > cannot
> > > > > > deploy a new process definition that implements additional
> > > interfaces
> > > > > > (among other things).
> > > > > >
> > > > > > I don't see the reason to bind together the notions of service
> > > > interface
> > > > > > and versioning.
> > > > > >
> > > > > >
> > > > > > > In general I would like to define the concept of a "current"
> > > process
> > > > > > > definition. The "current" process definition is the definition
> > > used
> > > > by
> > > > > > > the
> > > > > > > engine on an instantiating event. There could be instances
> > running
> > > > in
> > > > > > the
> > > > > > > engine that are using other versions of a process definition,
> > > > however
> > > > > > its
> > > > > > > not possible to have multiple versions that are used for
> > > > instantiating
> > > > > > > new
> > > > > > > processes ( see Maciej's reply on endpoints ). Through
> > management
> > > > > > > tooling a
> > > > > > > client will identify the "current" process.
> > > > > > I don't think we need to define the notion of a "current"
> > > process. I
> > > > > > think we only need to define which (unique) process provides an
> > > > > > instantiating (non-correlated) operation on a specific endpoint.
> > > > > >
> > > > > > alex
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > CTO, Intalio
> > > > > http://www.intalio.com
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > CTO, Intalio
> > > http://www.intalio.com
> > >
> > >
> >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
>
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
Lance,
I'm pointing out that any restrictions we place on naming the process will
bear no affect on the client. It doesn't make the client life easier, ror
protect the client from breakage, but it could make development harder.
Assaf
On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
>
> Assaf,
>
> I'm not following all of this. My main goal here is not to break the
> client
> when a process is redeployed.
>
> Lance
>
>
> On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > The client breaks when the endpoint changes, or the messages/operations
> > accepted by the endpoint change.
> >
> > Whenever you deploy a new version -- same or different name, version
> > number,
> > tagged or not -- that accepts the same messages on the same endpoints,
> the
> > client does not perceive any difference. It still invokes the process
> the
> > same way, regardless of how the server chooses to refer to that process
> > definition.
> >
> > However, changing the signature and changing the process name, breaks
> the
> > client. Because the client does not talk to the process, the client
> talks
> > to
> > the service, and so changing the signature breaks the client. Changing
> the
> > process name is immaterial.
> >
> > A restriction that "if you change the signature you must change the
> > process
> > name" does not in any way protect the client from breaking, but makes
> life
> > incredibly hard for developers. It's like asking you to change the Java
> > class name every time you change its signature. When you're writing
> code,
> > how often do you change signatures?
> >
> > Assaf
> >
> > On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
> > >
> > > Assaf,
> > >
> > > From a client application's perspective which of the three options
> > > requires
> > > a change in the way I send a message into the BPEL engine?
> > >
> > > Lance
> > >
> > >
> > > On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> > > >
> > > > Reading through the BPEL spec, I get the impression that however you
> > > > decide
> > > > to name a process is meaningless. If you send a message to its
> > > initiating
> > > > activity it will start. If you send a message to the wrong endpoint,
> > it
> > > > won't.
> > > >
> > > > So clearly people who want to version processes need to take into
> > > account
> > > > that Bar replacing Foo on same instantiating activity, means Bar is
> > the
> > > > version you now use, not Foo. Which means you can get really
> creative
> > > with
> > > > process names, like Order, OrderV1,
> Order_V2_With_25%_More_Activities.
> > > >
> > > >
> > > > But there are two requirements you can't solve with overriding and
> > > naming.
> > > >
> > > > One, only very few people can actual design, deploy and forget. Most
> > > > people
> > > > go through some iterative process, so you end up deploying different
> > > > iterations of the same process as you're working to get it to done.
> > And
> > > > naming each deployment, that's like saving every draft you write
> under
> > a
> > > > different name.
> > > >
> > > > The source control approach is much better, it gives each version a
> > > serial
> > > > number and datetime stamp, so you can easily track changes and
> > rollback.
> > > > If
> > > > you have some instance running, you know which process definition it
> > > > belongs
> > > > to: not the name, but the actual definition you pushed to the server
> > > > before
> > > > it was instantiated.
> > > >
> > > > (In some other development environments, deployment happens strictly
> > > > through
> > > > SVN and people in fact use the SVN version number to mark each
> > release)
> > > >
> > > > Two, numbers and timestamps are fine but a burden when you do want
> to
> > > > track
> > > > milestone releases, especially in production. So you want to
> associate
> > > > some
> > > > meaningful name, usually related to that milestone, like "Release
> 1",
> > > > "Release 1.1", whatever. A tagging mechanism separate from the
> process
> > > > name
> > > > has the benefit that you can clearly see its timeline, searching by
> > > name,
> > > > ordering by sequential version number, and displaying those tags.
> > > >
> > > > If tags sound familiar, source control does that as well.
> > > >
> > > >
> > > > So I personally prefer a system whereby:
> > > > 1. I can replace Foo with Bar because I decide Foo is a better name,
> > and
> > > > it's taking over Bar's role (same instantiation).
> > > > 2. Or replace Foo with another Foo, and be able to see sequence of
> > > > deployment using serial number/datetime I don't have to worry about.
> > > > 3. Or affix a specific version label/tag.
> > > >
> > > > #1, I don't see that happening often, and you can always retire Foo
> > and
> > > > activate Bar.
> > > >
> > > > #2 is something the server already has to do in order to maintain
> > > > instances
> > > > using the old version, so just give me access to the sequence
> > > > number/deployment timestamp.
> > > >
> > > > #3 is a really nice feature to have.
> > > >
> > > > Assaf
> > > >
> > > >
> > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > > >
> > > > > Lance Waterman wrote:
> > > > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > > > >>
> > > > > >> Lance,
> > > > > >>
> > > > > >> For consideration, I would like to briefly review the design
> that
> > I
> > > > had
> > > > > >> in mind for versioning in PXE. I think it's similar in spirit
> to
> > > > what
> > > > > >> you describe in your deployment spec.
> > > > > >>
> > > > > >> First, each process definition would be identified by its fully
> > > > > >> qualified name (/name/ and /namespace/ attributes) and a
> version
> > > > > >> number. The process engine would manage the version number in
> a
> > > > > >> monotonically increasing fashion, meaning that each time a
> > process
> > > is
> > > > > >> redeployed, the version number increases.
> > > > > >
> > > > > >
> > > > > > I don't understand the need for a version number that is managed
> > by
> > > > the
> > > > > > engine. I think a client may use whatever version scheme they
> use.
> > > We
> > > > > > just
> > > > > > need to validate that the version identifier is unique at
> > deployment
> > > > > > time.
> > > > > There is no strict need for a version number managed by the
> > engine. I
> > > > > think this idea came up when we wanted to simplify the management
> > > > > interfaces and wanted to avoid the need for an extra user-provided
> > > > > identifier if you already encoded version information in the
> > > > > name+namespace. It made it easier to define and communicate the
> > > > > "latest" process version.
> > > > >
> > > > > > I agree with Maciej's comments on this and would like to add
> from
> > > the
> > > > > > deployment spec under sec 1.2.5:
> > > > > >
> > > > > > *CONSTRAINT: Any change in the service interface ( i.e. a new
> > > > <receive>
> > > > > > element ) for a process definition will require a new identifier
> (
> > > i.e
> > > > .
> > > > > > name/namespace ) within the definition repository. Versioning is
> > not
> > > > > > supported across changes in the service interface and shall be
> > > > > > enforced by
> > > > > > the deployment component.*
> > > > > >
> > > > > > I would like to make sure folks are okay with this as well.
> > > > > Personally, I would be against this because it would mean that I
> > > cannot
> > > > > deploy a new process definition that implements additional
> > interfaces
> > > > > (among other things).
> > > > >
> > > > > I don't see the reason to bind together the notions of service
> > > interface
> > > > > and versioning.
> > > > >
> > > > >
> > > > > > In general I would like to define the concept of a "current"
> > process
> > > > > > definition. The "current" process definition is the definition
> > used
> > > by
> > > > > > the
> > > > > > engine on an instantiating event. There could be instances
> running
> > > in
> > > > > the
> > > > > > engine that are using other versions of a process definition,
> > > however
> > > > > its
> > > > > > not possible to have multiple versions that are used for
> > > instantiating
> > > > > > new
> > > > > > processes ( see Maciej's reply on endpoints ). Through
> management
> > > > > > tooling a
> > > > > > client will identify the "current" process.
> > > > > I don't think we need to define the notion of a "current"
> > process. I
> > > > > think we only need to define which (unique) process provides an
> > > > > instantiating (non-correlated) operation on a specific endpoint.
> > > > >
> > > > > alex
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > CTO, Intalio
> > > > http://www.intalio.com
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > CTO, Intalio
> > http://www.intalio.com
> >
> >
>
>
--
CTO, Intalio
http://www.intalio.com
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Assaf,
I'm not following all of this. My main goal here is not to break the client
when a process is redeployed.
Lance
On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
>
> The client breaks when the endpoint changes, or the messages/operations
> accepted by the endpoint change.
>
> Whenever you deploy a new version -- same or different name, version
> number,
> tagged or not -- that accepts the same messages on the same endpoints, the
> client does not perceive any difference. It still invokes the process the
> same way, regardless of how the server chooses to refer to that process
> definition.
>
> However, changing the signature and changing the process name, breaks the
> client. Because the client does not talk to the process, the client talks
> to
> the service, and so changing the signature breaks the client. Changing the
> process name is immaterial.
>
> A restriction that "if you change the signature you must change the
> process
> name" does not in any way protect the client from breaking, but makes life
> incredibly hard for developers. It's like asking you to change the Java
> class name every time you change its signature. When you're writing code,
> how often do you change signatures?
>
> Assaf
>
> On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
> >
> > Assaf,
> >
> > From a client application's perspective which of the three options
> > requires
> > a change in the way I send a message into the BPEL engine?
> >
> > Lance
> >
> >
> > On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> > >
> > > Reading through the BPEL spec, I get the impression that however you
> > > decide
> > > to name a process is meaningless. If you send a message to its
> > initiating
> > > activity it will start. If you send a message to the wrong endpoint,
> it
> > > won't.
> > >
> > > So clearly people who want to version processes need to take into
> > account
> > > that Bar replacing Foo on same instantiating activity, means Bar is
> the
> > > version you now use, not Foo. Which means you can get really creative
> > with
> > > process names, like Order, OrderV1, Order_V2_With_25%_More_Activities.
> > >
> > >
> > > But there are two requirements you can't solve with overriding and
> > naming.
> > >
> > > One, only very few people can actual design, deploy and forget. Most
> > > people
> > > go through some iterative process, so you end up deploying different
> > > iterations of the same process as you're working to get it to done.
> And
> > > naming each deployment, that's like saving every draft you write under
> a
> > > different name.
> > >
> > > The source control approach is much better, it gives each version a
> > serial
> > > number and datetime stamp, so you can easily track changes and
> rollback.
> > > If
> > > you have some instance running, you know which process definition it
> > > belongs
> > > to: not the name, but the actual definition you pushed to the server
> > > before
> > > it was instantiated.
> > >
> > > (In some other development environments, deployment happens strictly
> > > through
> > > SVN and people in fact use the SVN version number to mark each
> release)
> > >
> > > Two, numbers and timestamps are fine but a burden when you do want to
> > > track
> > > milestone releases, especially in production. So you want to associate
> > > some
> > > meaningful name, usually related to that milestone, like "Release 1",
> > > "Release 1.1", whatever. A tagging mechanism separate from the process
> > > name
> > > has the benefit that you can clearly see its timeline, searching by
> > name,
> > > ordering by sequential version number, and displaying those tags.
> > >
> > > If tags sound familiar, source control does that as well.
> > >
> > >
> > > So I personally prefer a system whereby:
> > > 1. I can replace Foo with Bar because I decide Foo is a better name,
> and
> > > it's taking over Bar's role (same instantiation).
> > > 2. Or replace Foo with another Foo, and be able to see sequence of
> > > deployment using serial number/datetime I don't have to worry about.
> > > 3. Or affix a specific version label/tag.
> > >
> > > #1, I don't see that happening often, and you can always retire Foo
> and
> > > activate Bar.
> > >
> > > #2 is something the server already has to do in order to maintain
> > > instances
> > > using the old version, so just give me access to the sequence
> > > number/deployment timestamp.
> > >
> > > #3 is a really nice feature to have.
> > >
> > > Assaf
> > >
> > >
> > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > >
> > > > Lance Waterman wrote:
> > > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > > >>
> > > > >> Lance,
> > > > >>
> > > > >> For consideration, I would like to briefly review the design that
> I
> > > had
> > > > >> in mind for versioning in PXE. I think it's similar in spirit to
> > > what
> > > > >> you describe in your deployment spec.
> > > > >>
> > > > >> First, each process definition would be identified by its fully
> > > > >> qualified name (/name/ and /namespace/ attributes) and a version
> > > > >> number. The process engine would manage the version number in a
> > > > >> monotonically increasing fashion, meaning that each time a
> process
> > is
> > > > >> redeployed, the version number increases.
> > > > >
> > > > >
> > > > > I don't understand the need for a version number that is managed
> by
> > > the
> > > > > engine. I think a client may use whatever version scheme they use.
> > We
> > > > > just
> > > > > need to validate that the version identifier is unique at
> deployment
> > > > > time.
> > > > There is no strict need for a version number managed by the
> engine. I
> > > > think this idea came up when we wanted to simplify the management
> > > > interfaces and wanted to avoid the need for an extra user-provided
> > > > identifier if you already encoded version information in the
> > > > name+namespace. It made it easier to define and communicate the
> > > > "latest" process version.
> > > >
> > > > > I agree with Maciej's comments on this and would like to add from
> > the
> > > > > deployment spec under sec 1.2.5:
> > > > >
> > > > > *CONSTRAINT: Any change in the service interface ( i.e. a new
> > > <receive>
> > > > > element ) for a process definition will require a new identifier (
> > i.e
> > > .
> > > > > name/namespace ) within the definition repository. Versioning is
> not
> > > > > supported across changes in the service interface and shall be
> > > > > enforced by
> > > > > the deployment component.*
> > > > >
> > > > > I would like to make sure folks are okay with this as well.
> > > > Personally, I would be against this because it would mean that I
> > cannot
> > > > deploy a new process definition that implements additional
> interfaces
> > > > (among other things).
> > > >
> > > > I don't see the reason to bind together the notions of service
> > interface
> > > > and versioning.
> > > >
> > > >
> > > > > In general I would like to define the concept of a "current"
> process
> > > > > definition. The "current" process definition is the definition
> used
> > by
> > > > > the
> > > > > engine on an instantiating event. There could be instances running
> > in
> > > > the
> > > > > engine that are using other versions of a process definition,
> > however
> > > > its
> > > > > not possible to have multiple versions that are used for
> > instantiating
> > > > > new
> > > > > processes ( see Maciej's reply on endpoints ). Through management
> > > > > tooling a
> > > > > client will identify the "current" process.
> > > > I don't think we need to define the notion of a "current"
> process. I
> > > > think we only need to define which (unique) process provides an
> > > > instantiating (non-correlated) operation on a specific endpoint.
> > > >
> > > > alex
> > > >
> > > >
> > >
> > >
> > > --
> > > CTO, Intalio
> > > http://www.intalio.com
> > >
> > >
> >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
>
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
The client breaks when the endpoint changes, or the messages/operations
accepted by the endpoint change.
Whenever you deploy a new version -- same or different name, version number,
tagged or not -- that accepts the same messages on the same endpoints, the
client does not perceive any difference. It still invokes the process the
same way, regardless of how the server chooses to refer to that process
definition.
However, changing the signature and changing the process name, breaks the
client. Because the client does not talk to the process, the client talks to
the service, and so changing the signature breaks the client. Changing the
process name is immaterial.
A restriction that "if you change the signature you must change the process
name" does not in any way protect the client from breaking, but makes life
incredibly hard for developers. It's like asking you to change the Java
class name every time you change its signature. When you're writing code,
how often do you change signatures?
Assaf
On 8/8/06, Lance Waterman <la...@gmail.com> wrote:
>
> Assaf,
>
> From a client application's perspective which of the three options
> requires
> a change in the way I send a message into the BPEL engine?
>
> Lance
>
>
> On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > Reading through the BPEL spec, I get the impression that however you
> > decide
> > to name a process is meaningless. If you send a message to its
> initiating
> > activity it will start. If you send a message to the wrong endpoint, it
> > won't.
> >
> > So clearly people who want to version processes need to take into
> account
> > that Bar replacing Foo on same instantiating activity, means Bar is the
> > version you now use, not Foo. Which means you can get really creative
> with
> > process names, like Order, OrderV1, Order_V2_With_25%_More_Activities.
> >
> >
> > But there are two requirements you can't solve with overriding and
> naming.
> >
> > One, only very few people can actual design, deploy and forget. Most
> > people
> > go through some iterative process, so you end up deploying different
> > iterations of the same process as you're working to get it to done. And
> > naming each deployment, that's like saving every draft you write under a
> > different name.
> >
> > The source control approach is much better, it gives each version a
> serial
> > number and datetime stamp, so you can easily track changes and rollback.
> > If
> > you have some instance running, you know which process definition it
> > belongs
> > to: not the name, but the actual definition you pushed to the server
> > before
> > it was instantiated.
> >
> > (In some other development environments, deployment happens strictly
> > through
> > SVN and people in fact use the SVN version number to mark each release)
> >
> > Two, numbers and timestamps are fine but a burden when you do want to
> > track
> > milestone releases, especially in production. So you want to associate
> > some
> > meaningful name, usually related to that milestone, like "Release 1",
> > "Release 1.1", whatever. A tagging mechanism separate from the process
> > name
> > has the benefit that you can clearly see its timeline, searching by
> name,
> > ordering by sequential version number, and displaying those tags.
> >
> > If tags sound familiar, source control does that as well.
> >
> >
> > So I personally prefer a system whereby:
> > 1. I can replace Foo with Bar because I decide Foo is a better name, and
> > it's taking over Bar's role (same instantiation).
> > 2. Or replace Foo with another Foo, and be able to see sequence of
> > deployment using serial number/datetime I don't have to worry about.
> > 3. Or affix a specific version label/tag.
> >
> > #1, I don't see that happening often, and you can always retire Foo and
> > activate Bar.
> >
> > #2 is something the server already has to do in order to maintain
> > instances
> > using the old version, so just give me access to the sequence
> > number/deployment timestamp.
> >
> > #3 is a really nice feature to have.
> >
> > Assaf
> >
> >
> > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > Lance Waterman wrote:
> > > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > > >>
> > > >> Lance,
> > > >>
> > > >> For consideration, I would like to briefly review the design that I
> > had
> > > >> in mind for versioning in PXE. I think it's similar in spirit to
> > what
> > > >> you describe in your deployment spec.
> > > >>
> > > >> First, each process definition would be identified by its fully
> > > >> qualified name (/name/ and /namespace/ attributes) and a version
> > > >> number. The process engine would manage the version number in a
> > > >> monotonically increasing fashion, meaning that each time a process
> is
> > > >> redeployed, the version number increases.
> > > >
> > > >
> > > > I don't understand the need for a version number that is managed by
> > the
> > > > engine. I think a client may use whatever version scheme they use.
> We
> > > > just
> > > > need to validate that the version identifier is unique at deployment
> > > > time.
> > > There is no strict need for a version number managed by the engine. I
> > > think this idea came up when we wanted to simplify the management
> > > interfaces and wanted to avoid the need for an extra user-provided
> > > identifier if you already encoded version information in the
> > > name+namespace. It made it easier to define and communicate the
> > > "latest" process version.
> > >
> > > > I agree with Maciej's comments on this and would like to add from
> the
> > > > deployment spec under sec 1.2.5:
> > > >
> > > > *CONSTRAINT: Any change in the service interface ( i.e. a new
> > <receive>
> > > > element ) for a process definition will require a new identifier (
> i.e
> > .
> > > > name/namespace ) within the definition repository. Versioning is not
> > > > supported across changes in the service interface and shall be
> > > > enforced by
> > > > the deployment component.*
> > > >
> > > > I would like to make sure folks are okay with this as well.
> > > Personally, I would be against this because it would mean that I
> cannot
> > > deploy a new process definition that implements additional interfaces
> > > (among other things).
> > >
> > > I don't see the reason to bind together the notions of service
> interface
> > > and versioning.
> > >
> > >
> > > > In general I would like to define the concept of a "current" process
> > > > definition. The "current" process definition is the definition used
> by
> > > > the
> > > > engine on an instantiating event. There could be instances running
> in
> > > the
> > > > engine that are using other versions of a process definition,
> however
> > > its
> > > > not possible to have multiple versions that are used for
> instantiating
> > > > new
> > > > processes ( see Maciej's reply on endpoints ). Through management
> > > > tooling a
> > > > client will identify the "current" process.
> > > I don't think we need to define the notion of a "current" process. I
> > > think we only need to define which (unique) process provides an
> > > instantiating (non-correlated) operation on a specific endpoint.
> > >
> > > alex
> > >
> > >
> >
> >
> > --
> > CTO, Intalio
> > http://www.intalio.com
> >
> >
>
>
--
CTO, Intalio
http://www.intalio.com
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Assaf,
>From a client application's perspective which of the three options requires
a change in the way I send a message into the BPEL engine?
Lance
On 8/8/06, Assaf Arkin <ar...@intalio.com> wrote:
>
> Reading through the BPEL spec, I get the impression that however you
> decide
> to name a process is meaningless. If you send a message to its initiating
> activity it will start. If you send a message to the wrong endpoint, it
> won't.
>
> So clearly people who want to version processes need to take into account
> that Bar replacing Foo on same instantiating activity, means Bar is the
> version you now use, not Foo. Which means you can get really creative with
> process names, like Order, OrderV1, Order_V2_With_25%_More_Activities.
>
>
> But there are two requirements you can't solve with overriding and naming.
>
> One, only very few people can actual design, deploy and forget. Most
> people
> go through some iterative process, so you end up deploying different
> iterations of the same process as you're working to get it to done. And
> naming each deployment, that's like saving every draft you write under a
> different name.
>
> The source control approach is much better, it gives each version a serial
> number and datetime stamp, so you can easily track changes and rollback.
> If
> you have some instance running, you know which process definition it
> belongs
> to: not the name, but the actual definition you pushed to the server
> before
> it was instantiated.
>
> (In some other development environments, deployment happens strictly
> through
> SVN and people in fact use the SVN version number to mark each release)
>
> Two, numbers and timestamps are fine but a burden when you do want to
> track
> milestone releases, especially in production. So you want to associate
> some
> meaningful name, usually related to that milestone, like "Release 1",
> "Release 1.1", whatever. A tagging mechanism separate from the process
> name
> has the benefit that you can clearly see its timeline, searching by name,
> ordering by sequential version number, and displaying those tags.
>
> If tags sound familiar, source control does that as well.
>
>
> So I personally prefer a system whereby:
> 1. I can replace Foo with Bar because I decide Foo is a better name, and
> it's taking over Bar's role (same instantiation).
> 2. Or replace Foo with another Foo, and be able to see sequence of
> deployment using serial number/datetime I don't have to worry about.
> 3. Or affix a specific version label/tag.
>
> #1, I don't see that happening often, and you can always retire Foo and
> activate Bar.
>
> #2 is something the server already has to do in order to maintain
> instances
> using the old version, so just give me access to the sequence
> number/deployment timestamp.
>
> #3 is a really nice feature to have.
>
> Assaf
>
>
> On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > Lance Waterman wrote:
> > > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > >>
> > >> Lance,
> > >>
> > >> For consideration, I would like to briefly review the design that I
> had
> > >> in mind for versioning in PXE. I think it's similar in spirit to
> what
> > >> you describe in your deployment spec.
> > >>
> > >> First, each process definition would be identified by its fully
> > >> qualified name (/name/ and /namespace/ attributes) and a version
> > >> number. The process engine would manage the version number in a
> > >> monotonically increasing fashion, meaning that each time a process is
> > >> redeployed, the version number increases.
> > >
> > >
> > > I don't understand the need for a version number that is managed by
> the
> > > engine. I think a client may use whatever version scheme they use. We
> > > just
> > > need to validate that the version identifier is unique at deployment
> > > time.
> > There is no strict need for a version number managed by the engine. I
> > think this idea came up when we wanted to simplify the management
> > interfaces and wanted to avoid the need for an extra user-provided
> > identifier if you already encoded version information in the
> > name+namespace. It made it easier to define and communicate the
> > "latest" process version.
> >
> > > I agree with Maciej's comments on this and would like to add from the
> > > deployment spec under sec 1.2.5:
> > >
> > > *CONSTRAINT: Any change in the service interface ( i.e. a new
> <receive>
> > > element ) for a process definition will require a new identifier ( i.e
> .
> > > name/namespace ) within the definition repository. Versioning is not
> > > supported across changes in the service interface and shall be
> > > enforced by
> > > the deployment component.*
> > >
> > > I would like to make sure folks are okay with this as well.
> > Personally, I would be against this because it would mean that I cannot
> > deploy a new process definition that implements additional interfaces
> > (among other things).
> >
> > I don't see the reason to bind together the notions of service interface
> > and versioning.
> >
> >
> > > In general I would like to define the concept of a "current" process
> > > definition. The "current" process definition is the definition used by
> > > the
> > > engine on an instantiating event. There could be instances running in
> > the
> > > engine that are using other versions of a process definition, however
> > its
> > > not possible to have multiple versions that are used for instantiating
> > > new
> > > processes ( see Maciej's reply on endpoints ). Through management
> > > tooling a
> > > client will identify the "current" process.
> > I don't think we need to define the notion of a "current" process. I
> > think we only need to define which (unique) process provides an
> > instantiating (non-correlated) operation on a specific endpoint.
> >
> > alex
> >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
>
Re: Issue 10 / Versioning
Posted by Assaf Arkin <ar...@intalio.com>.
Reading through the BPEL spec, I get the impression that however you decide
to name a process is meaningless. If you send a message to its initiating
activity it will start. If you send a message to the wrong endpoint, it
won't.
So clearly people who want to version processes need to take into account
that Bar replacing Foo on same instantiating activity, means Bar is the
version you now use, not Foo. Which means you can get really creative with
process names, like Order, OrderV1, Order_V2_With_25%_More_Activities.
But there are two requirements you can't solve with overriding and naming.
One, only very few people can actual design, deploy and forget. Most people
go through some iterative process, so you end up deploying different
iterations of the same process as you're working to get it to done. And
naming each deployment, that's like saving every draft you write under a
different name.
The source control approach is much better, it gives each version a serial
number and datetime stamp, so you can easily track changes and rollback. If
you have some instance running, you know which process definition it belongs
to: not the name, but the actual definition you pushed to the server before
it was instantiated.
(In some other development environments, deployment happens strictly through
SVN and people in fact use the SVN version number to mark each release)
Two, numbers and timestamps are fine but a burden when you do want to track
milestone releases, especially in production. So you want to associate some
meaningful name, usually related to that milestone, like "Release 1",
"Release 1.1", whatever. A tagging mechanism separate from the process name
has the benefit that you can clearly see its timeline, searching by name,
ordering by sequential version number, and displaying those tags.
If tags sound familiar, source control does that as well.
So I personally prefer a system whereby:
1. I can replace Foo with Bar because I decide Foo is a better name, and
it's taking over Bar's role (same instantiation).
2. Or replace Foo with another Foo, and be able to see sequence of
deployment using serial number/datetime I don't have to worry about.
3. Or affix a specific version label/tag.
#1, I don't see that happening often, and you can always retire Foo and
activate Bar.
#2 is something the server already has to do in order to maintain instances
using the old version, so just give me access to the sequence
number/deployment timestamp.
#3 is a really nice feature to have.
Assaf
On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Lance Waterman wrote:
> > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> >>
> >> Lance,
> >>
> >> For consideration, I would like to briefly review the design that I had
> >> in mind for versioning in PXE. I think it's similar in spirit to what
> >> you describe in your deployment spec.
> >>
> >> First, each process definition would be identified by its fully
> >> qualified name (/name/ and /namespace/ attributes) and a version
> >> number. The process engine would manage the version number in a
> >> monotonically increasing fashion, meaning that each time a process is
> >> redeployed, the version number increases.
> >
> >
> > I don't understand the need for a version number that is managed by the
> > engine. I think a client may use whatever version scheme they use. We
> > just
> > need to validate that the version identifier is unique at deployment
> > time.
> There is no strict need for a version number managed by the engine. I
> think this idea came up when we wanted to simplify the management
> interfaces and wanted to avoid the need for an extra user-provided
> identifier if you already encoded version information in the
> name+namespace. It made it easier to define and communicate the
> "latest" process version.
>
> > I agree with Maciej's comments on this and would like to add from the
> > deployment spec under sec 1.2.5:
> >
> > *CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
> > element ) for a process definition will require a new identifier ( i.e.
> > name/namespace ) within the definition repository. Versioning is not
> > supported across changes in the service interface and shall be
> > enforced by
> > the deployment component.*
> >
> > I would like to make sure folks are okay with this as well.
> Personally, I would be against this because it would mean that I cannot
> deploy a new process definition that implements additional interfaces
> (among other things).
>
> I don't see the reason to bind together the notions of service interface
> and versioning.
>
>
> > In general I would like to define the concept of a "current" process
> > definition. The "current" process definition is the definition used by
> > the
> > engine on an instantiating event. There could be instances running in
> the
> > engine that are using other versions of a process definition, however
> its
> > not possible to have multiple versions that are used for instantiating
> > new
> > processes ( see Maciej's reply on endpoints ). Through management
> > tooling a
> > client will identify the "current" process.
> I don't think we need to define the notion of a "current" process. I
> think we only need to define which (unique) process provides an
> instantiating (non-correlated) operation on a specific endpoint.
>
> alex
>
>
--
CTO, Intalio
http://www.intalio.com
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Lance Waterman wrote:
> On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
>>
>> Lance,
>>
>> For consideration, I would like to briefly review the design that I had
>> in mind for versioning in PXE. I think it's similar in spirit to what
>> you describe in your deployment spec.
>>
>> First, each process definition would be identified by its fully
>> qualified name (/name/ and /namespace/ attributes) and a version
>> number. The process engine would manage the version number in a
>> monotonically increasing fashion, meaning that each time a process is
>> redeployed, the version number increases.
>
>
> I don't understand the need for a version number that is managed by the
> engine. I think a client may use whatever version scheme they use. We
> just
> need to validate that the version identifier is unique at deployment
> time.
There is no strict need for a version number managed by the engine. I
think this idea came up when we wanted to simplify the management
interfaces and wanted to avoid the need for an extra user-provided
identifier if you already encoded version information in the
name+namespace. It made it easier to define and communicate the
"latest" process version.
> I agree with Maciej's comments on this and would like to add from the
> deployment spec under sec 1.2.5:
>
> *CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
> element ) for a process definition will require a new identifier ( i.e.
> name/namespace ) within the definition repository. Versioning is not
> supported across changes in the service interface and shall be
> enforced by
> the deployment component.*
>
> I would like to make sure folks are okay with this as well.
Personally, I would be against this because it would mean that I cannot
deploy a new process definition that implements additional interfaces
(among other things).
I don't see the reason to bind together the notions of service interface
and versioning.
> In general I would like to define the concept of a "current" process
> definition. The "current" process definition is the definition used by
> the
> engine on an instantiating event. There could be instances running in the
> engine that are using other versions of a process definition, however its
> not possible to have multiple versions that are used for instantiating
> new
> processes ( see Maciej's reply on endpoints ). Through management
> tooling a
> client will identify the "current" process.
I don't think we need to define the notion of a "current" process. I
think we only need to define which (unique) process provides an
instantiating (non-correlated) operation on a specific endpoint.
alex
Re: Issue 10 / Versioning
Posted by Lance Waterman <la...@gmail.com>.
Alex,
comments inline ...
Lance
On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Lance,
>
> For consideration, I would like to briefly review the design that I had
> in mind for versioning in PXE. I think it's similar in spirit to what
> you describe in your deployment spec.
>
> First, each process definition would be identified by its fully
> qualified name (/name/ and /namespace/ attributes) and a version
> number. The process engine would manage the version number in a
> monotonically increasing fashion, meaning that each time a process is
> redeployed, the version number increases.
I don't understand the need for a version number that is managed by the
engine. I think a client may use whatever version scheme they use. We just
need to validate that the version identifier is unique at deployment time.
Process definitions may be either activated or retired. Activated
> processes are available for instantiation whereas retired processes may
> not be instantiated -- the initiating operations are effectively disabled.
I don't understand the need for this given the concept of "current" given
below.
New process definitions may "override" the initiating operations and
> endpoints of retired process definitions to provide transparent
> migration to existing service consumers. To prevent conflicts,
> deploying a process definition using the same initiating operation(s)
> and the same endpoint(s) of an already deployed process should fail.
> Similarly, retired processes could be re-activated if no process
> currently uses the same initiating operation(s) on the same endpoints.
I agree with Maciej's comments on this and would like to add from the
deployment spec under sec 1.2.5:
*CONSTRAINT: Any change in the service interface ( i.e. a new <receive>
element ) for a process definition will require a new identifier ( i.e.
name/namespace ) within the definition repository. Versioning is not
supported across changes in the service interface and shall be enforced by
the deployment component.*
I would like to make sure folks are okay with this as well.
In general I would like to define the concept of a "current" process
definition. The "current" process definition is the definition used by the
engine on an instantiating event. There could be instances running in the
engine that are using other versions of a process definition, however its
not possible to have multiple versions that are used for instantiating new
processes ( see Maciej's reply on endpoints ). Through management tooling a
client will identify the "current" process.
Users would have different choices when it comes to managing version
> numbers. First, they can always use the name+namespace as with most
> XML-based specs. If they want to deploy multiple processes with the
> same name+namespace tuple, they could adopt the internal version numbers
> if they don't have anything better, or they could supply version
> information as meta-data when deploying the process definition. This
> meta-data could contain user-defined versioning tags, with values such
> as "myBranch-v2", or "Oct. 12th 2006". The PM API should support
> querying using both the internal version number and custom meta-data.
> Some of this is covered by
>
> http://pxe.intalio.org/confluence/display/PXE/BPEL+Management+API+Specification
> .
Again, I'm hesitant to come up with some internal scheme ( don't want the
runtime to start looking like a metadata repository ) but rather depend on
the client to come up with their own version number scheme ( i.e.
"myBranch-v2", or "Oct. 12th 2006" ).
This design is relatively simple and does not account for migrating
> instances between process versions, which is a more complex topic that
> we should eventually discuss in relation with Jacob.
>
> Is this in line with your current thinking?
>
> alex
>
>
>
Re: Issue 10 / Versioning
Posted by Alex Boisvert <bo...@intalio.com>.
Lance,
For consideration, I would like to briefly review the design that I had
in mind for versioning in PXE. I think it's similar in spirit to what
you describe in your deployment spec.
First, each process definition would be identified by its fully
qualified name (/name/ and /namespace/ attributes) and a version
number. The process engine would manage the version number in a
monotonically increasing fashion, meaning that each time a process is
redeployed, the version number increases.
Process definitions may be either activated or retired. Activated
processes are available for instantiation whereas retired processes may
not be instantiated -- the initiating operations are effectively disabled.
New process definitions may "override" the initiating operations and
endpoints of retired process definitions to provide transparent
migration to existing service consumers. To prevent conflicts,
deploying a process definition using the same initiating operation(s)
and the same endpoint(s) of an already deployed process should fail.
Similarly, retired processes could be re-activated if no process
currently uses the same initiating operation(s) on the same endpoints.
Users would have different choices when it comes to managing version
numbers. First, they can always use the name+namespace as with most
XML-based specs. If they want to deploy multiple processes with the
same name+namespace tuple, they could adopt the internal version numbers
if they don't have anything better, or they could supply version
information as meta-data when deploying the process definition. This
meta-data could contain user-defined versioning tags, with values such
as "myBranch-v2", or "Oct. 12th 2006". The PM API should support
querying using both the internal version number and custom meta-data.
Some of this is covered by
http://pxe.intalio.org/confluence/display/PXE/BPEL+Management+API+Specification.
This design is relatively simple and does not account for migrating
instances between process versions, which is a more complex topic that
we should eventually discuss in relation with Jacob.
Is this in line with your current thinking?
alex
Re: Issue 10
Posted by Lance Waterman <la...@gmail.com>.
Okay - I will submit a versioning design document to the Wiki for review.
Lance
On 8/8/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> I think the versioning changes will require an understanding of how the
> feature would be implemented -- a design reveiew. As for the scratch vs
> patch, scratch is called for when multiple developers are going to be
> involved in developing a feature.
> -mbs
> On Tue, 2006-08-08 at 10:45 -0600, Lance Waterman wrote:
> > Okay - I'll create a separate versioning document.
> >
> > I do think the scope of the versioning changes warrants some type of
> review.
> > Are you suggesting that each developer creates a scratch area or perhaps
> a
> > scratch area for a JIRA issue that has a large scope?
> >
> > How do folks want to handle this ( patch vs scratch )? How do other
> Apache
> > projects handle this?
> >
> > Lance
> >
> > On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > Lance Waterman wrote:
> > > > Will do. The current deployment spec does talk about the runtime
> > > > aspects of
> > > > versioning. From a documentation stand point do you think versioning
> > > > should
> > > > be broken out into a separate doc?
> > > Versioning often comes up on the top of the list of questions I get
> > > related to BPM, so from a user point of view I think it would be nice
> to
> > > have a separate document that introduces the concepts and presents the
> > > entire lifecycle picture, including deployment.
> > >
> > > > Note: Since this could be a pervasive change, I will submit a patch
> for
> > > > review prior to checking in.
> > > An idea: you could also create a temporary branch to make it easier to
> > > share, collaborate and merge/synchronize the code if you think the
> scope
> > > warrants it.
> > >
> > > alex
> > >
> > >
>
>
Re: Issue 10
Posted by Maciej Szefler <mb...@intalio.com>.
I think the versioning changes will require an understanding of how the
feature would be implemented -- a design reveiew. As for the scratch vs
patch, scratch is called for when multiple developers are going to be
involved in developing a feature.
-mbs
On Tue, 2006-08-08 at 10:45 -0600, Lance Waterman wrote:
> Okay - I'll create a separate versioning document.
>
> I do think the scope of the versioning changes warrants some type of review.
> Are you suggesting that each developer creates a scratch area or perhaps a
> scratch area for a JIRA issue that has a large scope?
>
> How do folks want to handle this ( patch vs scratch )? How do other Apache
> projects handle this?
>
> Lance
>
> On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > Lance Waterman wrote:
> > > Will do. The current deployment spec does talk about the runtime
> > > aspects of
> > > versioning. From a documentation stand point do you think versioning
> > > should
> > > be broken out into a separate doc?
> > Versioning often comes up on the top of the list of questions I get
> > related to BPM, so from a user point of view I think it would be nice to
> > have a separate document that introduces the concepts and presents the
> > entire lifecycle picture, including deployment.
> >
> > > Note: Since this could be a pervasive change, I will submit a patch for
> > > review prior to checking in.
> > An idea: you could also create a temporary branch to make it easier to
> > share, collaborate and merge/synchronize the code if you think the scope
> > warrants it.
> >
> > alex
> >
> >
Re: Issue 10
Posted by Lance Waterman <la...@gmail.com>.
Okay - I'll create a separate versioning document.
I do think the scope of the versioning changes warrants some type of review.
Are you suggesting that each developer creates a scratch area or perhaps a
scratch area for a JIRA issue that has a large scope?
How do folks want to handle this ( patch vs scratch )? How do other Apache
projects handle this?
Lance
On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Lance Waterman wrote:
> > Will do. The current deployment spec does talk about the runtime
> > aspects of
> > versioning. From a documentation stand point do you think versioning
> > should
> > be broken out into a separate doc?
> Versioning often comes up on the top of the list of questions I get
> related to BPM, so from a user point of view I think it would be nice to
> have a separate document that introduces the concepts and presents the
> entire lifecycle picture, including deployment.
>
> > Note: Since this could be a pervasive change, I will submit a patch for
> > review prior to checking in.
> An idea: you could also create a temporary branch to make it easier to
> share, collaborate and merge/synchronize the code if you think the scope
> warrants it.
>
> alex
>
>
Re: Issue 10
Posted by Alex Boisvert <bo...@intalio.com>.
Lance Waterman wrote:
> Will do. The current deployment spec does talk about the runtime
> aspects of
> versioning. From a documentation stand point do you think versioning
> should
> be broken out into a separate doc?
Versioning often comes up on the top of the list of questions I get
related to BPM, so from a user point of view I think it would be nice to
have a separate document that introduces the concepts and presents the
entire lifecycle picture, including deployment.
> Note: Since this could be a pervasive change, I will submit a patch for
> review prior to checking in.
An idea: you could also create a temporary branch to make it easier to
share, collaborate and merge/synchronize the code if you think the scope
warrants it.
alex
Re: Issue 10
Posted by Lance Waterman <la...@gmail.com>.
Will do. The current deployment spec does talk about the runtime aspects of
versioning. From a documentation stand point do you think versioning should
be broken out into a separate doc?
Note: Since this could be a pervasive change, I will submit a patch for
review prior to checking in.
Lance
On 8/8/06, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> Considering that version support spans more than the deployment phase, I
> would suggest creating distinct and more specific issue(s) for tracking
> versioning aspects and link them to ODE-10 for cross-referencing when
> relevant.
>
> alex
>
>
> Lance Waterman wrote:
> > Normalizing the deployment spec to the Ode trunk, it looks like the main
> > feature that needs to be added into the implementation is version
> > support. I
> > plan to add in version support under issue 10 unless I hear otherwise.
> >
> > Do folks have any input/thoughts on an Ode code style template ( note:
> > I am
> > using the Eclipse IDE )?
> >
> > Lance
> >
>
>
Re: Issue 10
Posted by Alex Boisvert <bo...@intalio.com>.
Considering that version support spans more than the deployment phase, I
would suggest creating distinct and more specific issue(s) for tracking
versioning aspects and link them to ODE-10 for cross-referencing when
relevant.
alex
Lance Waterman wrote:
> Normalizing the deployment spec to the Ode trunk, it looks like the main
> feature that needs to be added into the implementation is version
> support. I
> plan to add in version support under issue 10 unless I hear otherwise.
>
> Do folks have any input/thoughts on an Ode code style template ( note:
> I am
> using the Eclipse IDE )?
>
> Lance
>