Workflow management systems have become a popular technique for automating processes in many domains, ranging from high-level business process management to low-level web service orchestration. A workflow is created by dividing a process into different activities, and by specifying the ordering in which these activities need to be performed. This ordering is called the control flow perspective, as it describes how control flows between the activities. Typically, control can be split into several branches and joined at a later time. This allows specifying parallelism and choice.
Realistic workflows consist of several concerns, which are connected in order to achieve the desired behavior. However, if all of these concerns need to be specified in a single, monolithic workflow specification, it will be hard to add, maintain, remove or reuse these concerns. Although most workflow languages allow decomposing workflows into sub-workflows, this mechanism is typically aimed at grouping activities instead of facilitating the independent evolution and reuse of concerns. Moreover, a workflow can only be decomposed according to one dimension with this construct, and concerns that do not align with this decomposition end up scattered across the workflow and tangled with one another. Such concerns are called crosscutting concerns, and this problem has given rise to aspect-oriented programming for workflows.
The goal of our approach is to facilitate independent evolution and reuse of all workflow concerns. This can be accomplished by improving the modularization mechanisms offered by the workflow language. We propose an approach called Unify which provides a set of workflow-specific modularization mechanisms that can be readily employed by a wide range of existing workflow languages. Unify advocates specifying each workflow concern as a separate module. These modules are then composed using versatile connectors, which specify how the concerns are connected. The main contributions of Unify are the following:
- Existing research on modularization of workflow concerns is aimed at only modularizing crosscutting concerns, or at only modularizing one particular kind of concern, such as monitoring. Unify, on the other hand, aims to provide a uniform approach for modularizing all workflow concerns.
- Existing aspect-oriented approaches for workflows are fairly straightforward applications of general aspect-oriented principles, and are insufficiently focused on the concrete context of workflows. Unify improves on this by allowing workflow concerns to connect to each other in workflow-specific ways, i.e., the connector mechanism supports a number of dedicated control flow patterns.
- Unify is designed to be applicable to a wide range of concrete workflow languages. This is accomplished by defining its connector mechanism in terms of a general base language meta-model.
- Unify defines a clear semantics for both the workflow concerns and their connections. This facilitates the application of existing workflow verification techniques.
- Unify provides a meta-model and an implementation which enables the introduction of new patterns and connectors as they arise. Moreover, Unify can be implemented using multiple strategies. For example, it does not require a modified workflow engine.
Padus is our first experiment in the context of modularizing workflow concerns. It is an aspect-oriented extension to BPEL, which allows modularizing crosscutting concerns in separate aspects. More information about Padus is available on a dedicated page.
Unify is our second experiment in the context of modularizing workflow concerns. It is a framework for uniform modularization of all workflow concerns, be they regular or crosscutting. More information about Unify is available on a dedicated page.