Seeing the recent blog by Van Alst reminded me how low tech process versioning is. As he points out, it requires careful implementation of the processes, to avoid having long running process instances that may cause difficulties when trying to upgrade either the business process, or the infrastructure on which that process is running.
His suggested approach is to implement those BPEL processes, that would normally be long running, as event/message driven processes that can optionally utilise short running BPEL processes. However the disadvantage is the complexity that may be introduced to accommodate the potentially large number of business process versions that need to be supported. Each new version of the business process needs to accommodate existing running process instances that may be at various stages in the event driven implementation. However suitable tooling could be provided to help manage this.
The typical process versioning techniques currently used are:
1) Active processes should continue to use the same process definition (e.g. BPEL) version, while new process instances would use the most recent version.
2) Terminate all currently active processes – this seems a bit extreme, and can only really work if all systems involved have a way to undo or back out the work already done, and then replay the transaction on the new business process.
3) Migrating the process – although some simple changes can be handled using this approach, it can be very difficult to achieve without introducing errors. This is because the control structure of a process may change, or new variables may be added that cannot be initialised 'after the fact'.
So options (2) and (3) may be suitable in rare cases, but they are not a general solution.
The problem with option (1) is that a business process may be changed while a business process instance (or transaction) has not 'touched' all of the BPEL process definitions involved. For simplicity, if we assume a business process is comprised of two BPEL process definitions, A and B – if a business process instance X starts with process A, and waits for some duration (i.e. may be awaiting user input), and in the meantime the business process is updated in such a way that the interface between process definitions A and B are changed. When process instance X restarts in process definition A, and attempts to interact with process definition B, it would fail. This is because process definition B has not previously been involved in business transaction X, and therefore the BPEL engine managing process definition B would not be aware that it needs to actually direct the interaction to an older version of process definition B.
Could process governance provide another solution to this problem?
Understanding what behaviour a service provides, and what behaviour a service requires from other services, may provide the basis for ensuring the appropriate versions of each service work together correctly to deliver a particular version of the overall business process. This means that when one service wants to interact with another service, it should invoke the process definition version that meets its behavioural requirements, and not necessarily the one that is the most recent version.
The other way in which behaviour could be of use is to help determine whether a new version of a particular process definition (i.e. BPEL) is backward compatible with an active process instance associated with an older version of the process definition. If this is the case, then it may be easy to migrate the process instance to a newer process definition, and thus enable the business process instance as a whole to evolve – however this would be subject to the backward compatibility constraint.
So in summary:
First approach is to make each component of the process as simple and short lived as possible, to avoid having to worry about issues related to versioning those components. The system runs using the most up-to-date version of each component, and the complexity in dealing with changes in a business process are managed by the glue between the tasks – the rules that govern how the results of one task are used to trigger one or more other tasks.
The second approach doesn't place restrictions on the long running nature of the individual services, but instead provides a way in which multiple versions of a business process can run simultaneously, and evolve within certain constraints to newer versions of the service components.
The main point is that a business process and the resulting service designs should not be defined with versioning in mind. As far as possible, this needs to be handled as part of a SOI. In the case of the second approach, this can be handled as part of the governance capabilities, by controlling the specific versions of services that are used based on the required behaviour.
