ODE 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?
IMO, if retaining symmetry in both approaches becomes too much of an overhead (based on the problems you listed above) I would say we drop option 2.
This is not a BPEL specific problem.
what I fear is that we will have N different "webservice" deployment methods (drools, jbpm, bpel, <take your pick>).
I think keeping the simple deploy I think shuold be considered for development at least.
Can OSGi help out here? Can we deploy multiple versions of same bpel jar process (jar).
I think the web service based approach is sufficient as long as it solves the versioning problem and can be used from Eclipse environment. Much like jBPM has a web console process deployment option along with process deployment from the IDE.
I don't believe it is a requirement or even a benefit to deploy process definition as Java / JEE artifacts. Process definitions are not Java code and don't belong on the App server classpath.
I also don't see it as a problem that BPEL, jBPM, and Drools Flow would all have different deployment methods. Process deployment is a proprietary after all.
This was an option I had considered, although not sure how well it fits with the JEE deployment model to have multiple jars for the same BPEL deployment in the deploy folder.
Each Jar would need to still be differentiated by some form of user defined version - which could be supported by the Eclipse deployer (i.e. user defines the version in the deployment descriptor, and the Eclipse WTP based deployer packages up the jar with the version in the jar name?).
I guess if there needs to be two different versions of the same web service, or ESB service, they would be resident in the same deploy folder, but with different deployment unit names and endpoint references.
So this could be an alternative to the database approach - what do others think?
Just to clarify, my response was to Kurt - responses overlapped.
Jeff - I think the JEE deployment approach is useful for dev/testing purposes, when other JEE components are involved, but in general I don't feel comfortable trying to define a versioning mechanism around it.
My preference would be some central repository solution - however not sure how such a solution would work with admin of a production JBossAS environment - e.g. using JON.