ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Issue 10 / Versioning
Date Tue, 08 Aug 2006 23:19:45 GMT
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 <arkin@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 <lance.waterman@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 <arkin@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 <boisvert@intalio.com> wrote:
> > > >
> > > > Lance Waterman wrote:
> > > > > On 8/8/06, Alex Boisvert <boisvert@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message