Process versioning
objectiser Sep 2, 2009 5:41 AMODE supports versioning only when BPEL processes are deployed using its Deployment Web Service, as opposed to just placing the BPEL processes in the WEB-INF/processes folder directly.
This is because if we have a simple HelloWorld BPEL process and associated artifacts, the Deployment Web Service would place these artifacts in a folder under WEB-INF called HelloWorld-1. If that process is subsequently updated, the new version of the process would be placed in the folder HelloWorld-2. The artifacts for the previous version (HelloWorld-1) would still remain.
ODE does not persist any process definition artifacts, it relies on them being available within the filesystem.
With RiftSaw we currently support a different deployment approach, enabling the artifacts to be deployed using Eclipse WTP framework as a Jar, into the app server's deploy folder. However this is equivalent to placing the BPEL processes directly into the WEB-INF/processes folder - it only provides access to the latest version of the BPEL process, and therefore versioning is not supported.
The solution is to persist the BPEL artifacts associated with the different versions of a process. However this can be done in two ways:
1) Provide a web service, similar to the ODE deployment web service, that can deploy the BPEL artifacts directly into the database and ensure they are versioned appropriately.
2) Use the JBossAS deploy approach (as now), and use the hot deployment mechanism to update the database with the latest version.
The second option has a problem when we need to consider clustering, as the ODE deployment descriptor does not contain any version information. So imagine the scenario, where we have multiple JBossAS servers all clustered around a single ODE DB. Each server has the same BPEL process deployed into its deploy folder. Each server then attempts to store that process definition in the database.
Once one of the servers has stored the process definition, how do we stop the other servers all trying to 'update' that process. The only way is to have an understanding of whether the process now stored in the database is the same as the one just deployed to the server. This could possibly be achieved by comparing the BPEL process definitions, but its possible the change may be in one of the other artifacts (e.g. BPEL, XSD, XSL, etc).
The only reliable method might be to have a user defined version number included in the deployment descriptor - but this would require a change in the Eclipse ODE Deployment Descriptor editor to support the additional field.
So just to recap, option (1) deploys via web service direct into db, so avoids any issues related to multiple servers attempting to update the same process definition, and option (2) uses the same deployment approach as other JEE components, but may need an explicit user defined version to be added to the deployment descriptor.
One final thought - JOPR/JON has support for distributing JEE components to multiple servers, but not sure how it would deal with management of BPEL processes deployed via a web service. Possibly this means that deployment via a web service to db approach would be outside the management scope of a system like JON. Not sure if this is an issue or not?
Its possible that support for both deployment approaches would be the best answer? Thoughts?