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 Wed, 09 Aug 2006 00:23:21 GMT
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 <arkin@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 <lance.waterman@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 <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
> > >
> > >
> >
> >
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>
>

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