Section 26.2. A WORKFLOW APPLICATION EXAMPLE

26.2. A WORKFLOW APPLICATION EXAMPLE

Let us take as a case study a workflow application involving synchronization, scheduling, authorization, and logging aspects. Workflow management arises from automating well-structured, repetitive processes [2]. A flexible and scalable implementation of workflow systems typically requires the modeling of components such as processes, roles, activities, assignments, and resources in terms of independent distributed objects. Here, aspects can naturally provide workflow adaptation mechanisms, representing different strategies to control process execution and resource management.

The functionality required for our example can be informally described as follows. The application defines a workflow model for structured documents, with different users having access to these documents. Users can play different roles (e.g., supervisor, editor, or auditor), and each role has set its own permissions for operations on the documents. During its lifecycle, a document typically goes through a number of predefined states, such as edition, approval, and publishing. State transitions are ruled by events. Therefore, specific tasks may be activated in response to particular event conditions. Initially, a document is empty, waiting for editing. As the editor adds information to the document following certain standards, the document is sent to the auditor for approval. If the auditor considers the document contents relevant to the system, it is marked as ready for distribution. If so, every user potentially interested in this type of document is notified about the event. If not, the document is sent back to the editing phase for revision. However, the auditor may reject the document if defective. In addition, a supervisor can review documents at any time and decide about their status. After certain period of time, some documents may become useless or require modifications. In such cases, a new version of the document is generated. As a result, the old version of the document is no longer available. Old documents are temporarily stored as items pending deletion and are eventually removed from the system. For simplicity, we suppose a supervisor can read, write, or check documents; an editor is only allowed to read or write some documents, and an auditor can read or check other documents.

The aspects identified in the workflow application are

Concurrency. Concurrency deals with synchronization and scheduling issues, controlling document reading and writing from different user sessions. The concurrency aspect also chooses the next reader or writer when a blocking operation completes.

Authorization. Authorization refers to the security policies regarding document handling. Only authorized users can perform particular operations on specific documents. This aspect is closely related to concurrency because a failure in the authorization process should abort any further user activity, making unnecessary synchronization and scheduling mechanisms.

Logging. Logging records security exceptions. Every unsuccessful authorization attempt activates the logging aspect to record the user's subsequent actions.

In the following sections, we describe each of the phases developers/designers go through in implementing the workflow application using Smartweaver. Our example uses the Aspect-Moderator framework (AMF) [6, 7] as its underlying AOP mechanism, briefly described in the next section.

26.2.1. The Aspect-Moderator Framework

The AMF is a design approach extending the object model, which provides support for a cluster of cooperating objects and their aspect behaviors. A specially designated component called moderator takes the place of the weaver, coordinating the interaction between functional components and aspects. The moderator controls both the activation order and the actual activation of aspects. The approach introduces the concept of aspect bank, where the moderator of a cluster may initially collect all the required aspects and then decide about the integration policies [6] (see Figure 26-2).

Figure 26-2. The Aspect-Moderator framework, extracted from [6].

A proxy object controls the access to the class functionality. This proxy object uses the factory pattern to create aspect objects for each method of the functional component to be associated with some aspects. Aspects are first-class abstractions, and on creation, they are registered with the aspect moderator. Within the proxy, each participating method is guarded by a pre-activation and post-activation phase. These phases are implemented in the aspect moderator. During the former phase, the proxy intercepts requests for access to the functional components and calls the moderator to evaluate all required aspects.

If the pre-activation phase returns successfully, then the proxy calls the actual participating method. Once this execution is complete, the proxy initiates the post-activation phase and again calls the moderator to evaluate the associated aspects. The aspect moderator class is extensible in order to make the overall system adaptable to the addition of new aspects. The framework deals with the weaving of aspects and components at runtime, allowing dynamic composition of aspects with functional components, and thereby avoiding code transformation.