Below we give a schematic overview of workflow process modelling and execution research areas from the perspective of the literature review:
Ontologies – Semantic Web
Workflow
Process
Models
UML BPMN FBPML B P E L 4 W S OWL-S T r a n s f o r m a t i o n s / m a p p i n g sExecution Frameworks
Figure 2.22: Rich picture of the Workflow Technology area
Specifically, as shown in Figure 2.22 there are two basic layers, namely modelling and execution layer. With regard to modelling layer, there are workflow modelling languages that capture busi- ness processes and create high-level visual process models. The workflow modelling languages reviewed in this Chapter were IDEF0, EPC, IDEF3, BPMN, XPDL, BPDM, and UML 2 ADs. Regard- ing the execution layer, we have reviewed BPEL4WS, OWL-S, and WSMX. Execution frameworks are able to define the low-level execution semantics for the processes that will be eventually exe- cuted by an execution engine. At this point, semantic web community with OWL-S and WSMX promote the use of ontologies, elaborating processes with semantics, in order to enable auto- matic discovery, composition, and execution of processes with little or even no human interven- tion.
Recent research approaches have defined mappings between the two layers trying to reduce the gap between them. The mappings we have reviewed were UML to BPEL4WS, BPMN to BPEL4WS and FBPML to OWL-S. These mappings try to address the existence of two different representa- tions for high-level models and execution semantics, finding common constructs and concepts in order to provide an automatic mechanism of translating modelling languages to execution ones
Completeness, i.e. the mapping is only applicable to UML/BPMN/FBPML models that fulfil certain requirements.
Automation, i.e. they are not capable of producing target code without requiring human intervention to identify patterns in the source model.
Readability, i.e. the produced target code is not always understandable by humans; e.g., the produced BPEL4WS code due to automatic translation via the mappings becomes too complicated and often rather unreadable, obstructing refinement [52].
The main limitations we have identified in the literature in respect with our research objectives are as follows:
1. IDEF0 and IDEF3 are the only modelling languages that have formal semantics defined in its specification. The rest of modelling languages are either not formalized at all or have some proprietary formalization efforts trying to define some formal semantics but still are not finalized and not widely accepted. Absence of formalization results to ambiguous models that cannot be automatically checked for consistency and completeness.
2. There is no modelling language efficiently handling process change, in terms of quick ad- aptation of an existing model. Specifically, all process modelling languages we have re- viewed explicitly sequence activity flow in a way that the final model includes a set of hard-connected activities. In case a modeller needs to add, change, or remove an activ- ity, he has to find all the dependent activities and update them accordingly. It is obvious that in small and medium-sized models this would work but large scale and complex models would be very difficult to maintain.
3. Process modelling languages with lot of constructs may be more complete and accurate but at the same time require significant amount of training and access to technical re- sources in order to create models without errors.
4. Process modelling languages make no assumptions about the implementation of a proc- ess, thus they miss critical information for the execution logic needed by execution frameworks.
5. Process execution frameworks do not define graphical representation of processes nor provide any particular design methodology.
6. Process execution frameworks rely on either XML language or ontologies for the descrip- tion of processes and their execution logic. Those that use XML cannot describe complex relationships and inheritance among activities in a process, while those using ontologies are difficult to learn and result to large descriptions that are difficult to read and write. 7. Business rules are mainly encoded at the execution layer using traditional programming
constructs such as if-then-else, cases, while, etc. and this makes maintenance of process models and execution semantics even more difficult when process needs to be changed.
8. Although there are some proposals for mappings, common practice is still managing high- level modelling and low-level execution descriptions manually, creating difficulties in maintaining consistency between the two.
9. There is a lack an integrated modelling approach that could effectively represent high- level models and low-level execution semantics, supporting both layers of modelling in a smooth and consistent way.
Table 2.3 recapitulates the main limitations.
Table 2.3: Main limitations identified in the literature
Finally, we reviewed two enabling disciplines for our research, namely Systems Theory and Con- straint-based reasoning. Systems Theory has some enabling characteristics that can help us inte- grate high-level process descriptions and low-level workflow execution semantics into a unified format. On the other hand, constraint-based reasoning has some enabling characteristics that can help us effectively express and reason about business rules that capture nonlinear relationships in workflow processes and address changing conditions.
Modelling Languages
No Formal semantics (EPC, BPMN, XPDL, BPDM, UML2 ADs)
Sequencing activity flow (EPC, IDEF3, BPMN, XPDL, BPDM, UML2 ADs) Lots of modelling constructs - significant amount of training and access to tech- nical resources needed (BPMN)
No execution semantics (IDEF0, EPC, IDEF3, BPDM,UML2 ADs) Execution Frameworks
No graphical representation
Sequence business rules with traditional programming constructs Mappings (UML to BPEL4WS, BPMN to BPEL4WS, FBPML to OWL-S)