ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Issue 10 / Versioning
Date Tue, 08 Aug 2006 22:03:43 GMT
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

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