ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: Issue 10 / Versioning
Date Tue, 08 Aug 2006 21:21:04 GMT

comments inline.

On Tue, 2006-08-08 at 15:00 -0600, Lance Waterman wrote:
> Alex,
> comments inline ...
> Lance
> 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.
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
> >
> >
> >

View raw message