Lance Waterman wrote:
On 8/8/06, Alex Boisvert <[EMAIL PROTECTED]> 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
