Sunday, 04 August 2013 20:55

Change Support Feature FF1: Version Control

To support changes at the process type level, version control for process schemes is needed. In case of long-running processes, in addition controlled migration of already running instances from the old to the new process schema version is often required when conducting a schema change at the process type level. If no version control is provided, either the process designer will have to manually create a copy of the process schema to be changed or the original schema will be overwritten. In the latter case, running instances can either be withdrawn from the run-time environment (Design Choice F1[1]) or they remain associated with the modi ed schema (Design Choice F1[2]). Depending on current instance execution state and on how changes are propagated to instances progressed too far, missing version control can lead to inconsistent states and in the worst case to deadlocks or severe other run-time errors. Schema S has been modi ed by adding activities X and Y. Regarding instance I1 this change is uncritical as I 1 has not yet entered the changed region. However, instance I 2 would be in an inconsistent state afterwards as instance schema and execution history do not match.

FF01 1

By contrast, if a PAIS provides explicit version control three support features can be di erentiated: running process instances remain associated with the old schema version, while new instances will be created based on the new schema version. This approach leads to the co-existence of process instances belonging to di erent schema versions. Alternatively, for a (selected) collection of already running process instances a controlled migration to the new process schema version is supported.

FF01 2

Design Choice F1[3] is shown in Fig. 18b where already running instances I1, I 2 and I 3 remain associated with schema S1, while new instances (I 4, I 5) are created from schema S 0 (co-existence of process instances of di erent schema versions). By contrast, Design Choice F1[5] illustrates the controlled migration of selected instances. Only those instances (I1 and I 2) are migrated to the new schema version which are compliant with S0. Thereby, I1 can be migrated without any state adaptations, whereas for I 2 the newly inserted Activity X has to be enabled instead of Activity B. Instance I 3 remains running according to S since it is non-compliant with S0. If instance migration is accomplished in an uncontrolled manner (i.e., it is not restricted to compliant process instances) inconsistencies or errors will result (Design Choice F1[4]). Nevertheless, we treat the uncontrolled migration of process instances as a separate design choice since this functionality can be found in existing systems.

FF01 3

Read 1089 times

Get the Book!

book cover small