Alex, comments inline ...
Lance 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. 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. 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. 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
