Active object-oriented databases (AOODB) are a commonly accepted solution for smoothly capturing the frequently changing business policies of large enterprises [2]. By factoring out business policies from single applications and incorporating them into an AOODB, they are maintained in an application-independent manner, and may be imposed on all applications. One of the most prominent basic mechanisms of an AOODB system is an Event/Condition/Action rule (ECA rule), which allows for a localized specification of a business policy as opposed to spreading it over several applications. Monitoring events and conditions, ECA rules execute the corresponding action when the event occurs and the condition is true [8]. Extensions of the basic ECA paradigm allow a more flexible definition of rule execution points. For instance, in our research AOODB system TriGS the model is ECEA, which means another event may be awaited before the action is triggered [4, 9]. (TriGS stands for Triggersystem for GemStone, which is an active layer on top of the object-oriented database system GemStone.)
Unfortunately, AOODB designers are overtaxed with the expressive power and flexibility of existing active object-oriented models, especially with the options for mapping business policies onto ECA rules. Rather than provide guidelines on which business policies to put into the AOODB, existing techniques follow a top-down design approach—focusing on the graphical representation of rules at the conceptual level by integrating them into existing conceptual design models [12]. Logical AOODB design, including the transformation of a conceptual model into an AOODB schema, has been dealt with infrequently [1]. Learning from similar design problems in OO system development, we propose a bottom-up design approach. We introduce rule patterns in analogy to design patterns [3], describing sample rule patterns for specifying interaction policies in workflow applications. More extensive annotated examples written in TriGS code can be found at www.ifs.uni-linz.ac.at/ifs/research/ publications/papers01.html.
Using our approach to AOODB design necessitates two subtasks: specifying application classes, and identifying business policies, which are generally spread over different classes. Since the first subtask resembles traditional OO design, we use three model elements of the standard OO modeling language UML [11]: the class model for capturing the classes and their relationships, the statechart model for capturing the behavior of each class, and the interaction model for capturing the interactions between objects of different classes. The second subtask is more subtle, as several approaches exist for identifying business policies [7]. Instead of arbitrarily picking one approach, we extract business policies from the three models designed in the first subtask. For example, integrity constraints stated in the class model and interaction constraints stated in the interaction model are typical representatives of business policies, and thus candidates for being specified in terms of ECA rules.
When looking at rules specifying business policies, one may find components applicable to several applications, as well as specific to one application. In order to avoid the application designer having to repeatedly consider the common components of rules, and to support the adaption of rules to several applications, rule patterns are introduced. For example, consider business policies from a warehouse application and a bank application. The former states that when goods are removed from stock, the remaining stock is checked, and more is ordered if the stock has fallen below a given limit. The latter states that every time money is withdrawn from an account the balance is checked, and if overdrawn the bank charges are increased. A common formulation of these two policies in terms of a rule pattern is that as soon as a certain property’s value falls below a defined threshold some reaction must be undertaken. The property, the threshold, and the reaction are the parameters of the rule pattern constituting its application-specific components. Next to parameterization, composition makes rule patterns even more general and versatile than they could be otherwise. A rule pattern may be composed of several component rules and component patterns working together.
Figure 1 illustrates the process of working with rules and rule patterns. An AOODB design environment supporting this process is operational [10]. In the long run, rule patterns will be provided for each kind of business policy within a pattern library. Such a pattern library must be extensible, both by defining new patterns and specializing existing ones (see (1) in Figure 1). To use rule patterns within an application, designers must customize them by binding the parameters of a selected pattern on the basis of the particular application semantics. The system guides the designer through parameter binding by providing online help for each required parameter and by restricting the binding alternatives to those that do not contradict the specification of the underlying pattern (see Figure 3). Once all parameters are bound, a rule is automatically generated out of the rule pattern and stored in the rule base attached to the corresponding application (see (2) in Figure 1). Designers may still specify rules from scratch without using a pattern and store them directly within the appropriate rule base (see (3) in Figure 1). If a designer recognizes in retrospect that a specific design situation recurs and is worth being specified by a corresponding rule pattern, existing rules can be used for this abstraction process (see (4) in Figure 1).
We illustrate our approach using interaction rule patterns, which specify interaction policies between objects. They enhance sequential message passing, so interactions are specifiable in a concurrent OO environment based on multiple threads of control [6]. Although such interaction mechanisms are built-in primitives in some concurrent OO systems, they must usually be defined by the programmer. Following are descriptions of two interaction rule patterns: the abstraction from a single application-specific rule to a primitive rule pattern, and a composite rule pattern abstracting from more than one rule. We use a workflow management example to illustrate these interactive rule patterns. In workflow management, it is crucial to flexibly model the synchronization between concurrently executing activities [5].
A Primitive Rule Pattern. A primitive rule pattern known as “asynchronous interaction” frees the sender from having to check the receiver’s actual state or wait for the receiver to finish method execution. Of course, the receiver cannot satisfy the request before entering an appropriate prestate. The behavior of an object, including allowed states and state transitions, is specified in a statechart diagram [11], that defines the acceptability of the receiver concerning a specific request. For the sake of simplicity, we assume every object has an implicit multivalued instance variable state holding its actual state(s). Asynchronous interaction considerably increases concurrency since the sender just initiates the interaction. This is useful when the sender does not require a result from a delegated task.
Consider the example of a workflow application for a computerized reservation management system for a nationwide consortium of motels connected via a wide area network. Network nodes submit reservations to the consortium, which delegates these requests to the appropriate motels. To allow reservations to be concurrently submitted to the consortium, the consortium object asynchronously propagates the message tryRes from within the method newRes to all motels satisfying the user’s request stored within the reservation object, or resobj (see Figure 2). The notation of the sequence diagram in Figure 2a and of the statechart diagram in Figure 2b is based on the notation used in UML [11]. In Figure 2a, the sender object consortium and the receiver object motel are denoted by vertical bars. Time progresses from top to bottom of the lines. Solid lines designate active threads of control and dashed lines designate inactive threads of control. Arrows denote interactions between objects. Double-headed arrows denote 1:n interactions, when the consortium interacts with several motel objects at the same time. A possible sequence of states of the receiver object is also shown. These states belong to the statechart diagram of the class Motel in Figure 2b. Note we assume multiple threads of control since both the consortium object and the motel objects may be active at the same time. Multiple threads are necessary to ensure the receiver object motel is eventually transferred to the correct prestate for satisfying a certain request. Figure 2b shows the relevant part of the statechart diagram for class Motel. Note, activities within the states are omitted.
This asynchronous interaction policy is realized by a rule called async_tryRes depicted in Figure 3. (The code example of the rule as well as the one of the corresponding rule pattern may be downloaded from www.ifs.uni-linz.ac.at/ifs/research/publications/papers01.html.) Recall that rules in TriGS have the ECEA form instead of ECA, thus there is one event triggering condition evaluation (EC), and another event triggering action execution (EA). The TriGS expressions by which these events are specified are called condition event selector and action event selector, respectively.
The condition event selector of the rule async_tryRes identifies the interaction by specifying an event that is signaled every time a consortium object sends the message tryRes to a motel object from within the method newRes (see Figures 2a and 3). The condition is set to TRUE since asynchronous interaction allows the sender to proceed immediately after initiating a request, independent of the receiver’s state. However, the message should be processed by the motel object only when it is in state Idle (see Figure 2b). The action event selector thus checks transitions to the state Idle, in case the motel object is not already in that state. It also recognizes the motel object already entered the appropriate state Idle before the request of the triggering method tryRes occurred. The action of the rule replaces the normal sequential execution of the triggering method for executions within an asynchronous thread of control.
Realizing an interaction policy by using rules offers important advantages, but one major drawback exists. Since the policy of asynchronous interaction is not only used for the message tryRes, but also for other parts within our reservation example and for other application domains, those components of the rule remaining the same for any asynchronous interaction have to be specified repeatedly. To relieve the AOODB designer from this task, the application-dependent rule for asynchronous interaction is abstracted to an application-independent rule pattern for asynchronous interaction called Asynchronizer. This is done by factoring out the recurring components of the rule and explicitly specifying the formal parameters to be bound when applying the pattern. Once a rule pattern is defined, it can be easily applied by binding its parameters using a corresponding form. On the basis of this parameter binding, the system automatically generates a rule, and the AOODB designer does not have to be concerned with the complexity of the rule pattern and the generated rule alike. Figure 3 illustrates the approach of generating the asynchronous interaction rule out of the Asynchronizer rule pattern. Note actual parameters are shown on white background.
A Composite Rule Pattern. As mentioned previously, asynchronous interaction increases concurrency since the sender need not wait for any result. With pure synchronous interaction the sender awaits the result at the expense of concurrency, which is useful when the sender cannot proceed without the result. When the result of a request is not needed immediately but at some time in the future, an interaction policy called future synchronous or lazy wait has been defined [6], allowing the sender to continue execution concurrently with the receiver until a result is needed. Considering our running example, every time the user requests a new reservation from the User Interface object (UI), it sends the message newRes future synchronously to the consortium object. We assume the system allows the user at a terminal to request several reservations from one UI object concurrently, and the user wants to have the result automatically returned at some future point in time. Consequently, neither synchronous nor asynchronous interaction is desirable.
The solution here involves use of the rule pattern known as the “Future Synchronizer.” Unlike the Asynchronizer, which is based upon a single rule, the Future Synchronizer is a composite rule pattern abstracting from more than one rule. It consists of three primitive rule patterns as illustrated in Figure 4. The puzzle-like symbols denoting the parts of each rule pattern are meant to demonstrate that a rule pattern is not executable as such. The formal parameters have to be bound to actual values before an executable rule can be generated. The first component of the composite rule pattern is responsible for starting the interaction asynchronously, and thus resembles the Asynchronizer. The other two components named CatchResult and WaitForResult are responsible for “handshaking,” and transfer the result from the receiver to the sender. One of these two component patterns catches the result of the future synchronous interaction request as soon as the receiver is ready and puts it into a shared queue. The other component pattern blocks the sender until the requested result is available within the shared queue. Since the Future Synchronizer is a composite rule pattern, parameter binding is used across all three component patterns, and a formal parameter of the composite pattern may be used in all component patterns.
Our long-term goal is to support application designers with a comprehensive framework of rule patterns. So far, we have developed a basic framework of interaction rule patterns for workflow applications.
Lessons Learned
The proper design of rule-based applications is one of the most pressing open research problems in the AOODB area [2]. Our objective is to provide rule patterns for the bottom-up design of rule-based applications, learning from existing design experience and facilitating reuse. Our long-term goal is to support application designers with a comprehensive framework of rule patterns. So far, we have developed a basic framework of interaction rule patterns for workflow applications. For a detailed discussion, see www.ifs.uni-linz.ac.at/ifs/research/publications/papers01.html.
The concept of rule patterns is independent of the underlying active models. The basic idea of rule patterns can be applied to other AOODBs besides TriGS. Built with small resources, TriGS has some rough edges, in part because the underlying system could not be modified. Rule patterns can hide a lot of these rough edges, but most OO databases are less dynamic and less reflexive than GemStone. Their classes are not objects, for example. In such systems, it would be sensible to treat rules as static entities instead of objects. Besides the AOODBs, the concept of rule patterns is generally applicable whenever ECA rules are part of the underlying model, as with some relational database systems.
Rule patterns enable the traceability of requirements. Let us consider rules and rule patterns within the software life-cycle. During analysis, domain specialists state their requirements most naturally by means of business rules. Within design, rule patterns are identified to provide a generic specification of how rules found during analysis may be transformed to a more formal notation. The implementation phase comprehends parameter binding on the basis of the rules found during analysis followed by an automatic generation of the corresponding ECA rules. Since the concept of rules and rule patterns is used within each phase of the software life-cycle, traceability of frequently changing requirements throughout the whole software life-cycle is facilitated.
Low-level rule patterns can be abstracted to more application-oriented rule patterns. Interaction rule patterns may be classified as low-level implementation-oriented patterns since they provide basic interaction mechanisms, which are already built into some concurrent OO languages. In our room reservation example, we use an asynchronous interaction policy to search for an appropriate room in different motels. This is appropriate during peak season when rooms are hard to find, even though it necessitates the overhead of canceling remaining reservation requests once an appropriate room is found. Since the first motel will likely have a free room during the low season, here a more optimistic approach using synchronous interaction is more efficient. Following our bottom-up approach, it is natural to incorporate these lower-level patterns into a higher-level “seasonal reservation pattern,” responsible for selecting the seasonal interaction policy. This pattern could be further parameterized into a pattern in which the selection criterion for the respective interaction policy is also specified as parameter. The identification of further application-oriented patterns in the area of workflow management, such as patterns for agent selection and activity ordering, is part of ongoing work [5].
Rule patterns are useful in various application domains. As with design patterns, low-level rule patterns tend to be more widely applicable to different domains than high-level ones. The concept of rule patterns is suitable for any application domain in which active rules are used. Computer-aided manufacturing (CAM) systems are one area for which AOODBs are often proposed. Imagine a system consisting of many flexible manufacturing cells and other shop-floor machinery. A typical simple cell may have one computer-controlled machine tool, such as a lathe, drill, or mill, and one robot for moving workpieces to and from the machine. One conveyor brings workpieces to the cell, and another takes them from there after the machining. If the software controlling the cell depends on ECA rules for its main logic, one needs a large number of rules, even if possible error situations are ignored. Examples of rules include:
- When the in-conveyor brings in a workpiece, if the robot is idle and the machine unloaded, instruct the robot to move the workpiece to the machine.
- When the robot has successfully loaded the machine, instruct the machine to start work.
- When the machine has finished its cycle, if the robot is idle, instruct it to move the workpiece to the out-conveyor.
Normally, these rules must be written separately for each manufacturing cell. With rule patterns, they are written only once as a composite rule patterns, with machine, robot, in-conveyor, and out-conveyor parameters. In fact, a well-designed Cell class will have these as attributes, so the only actual parameter needed for instantiating this large rule pattern may be cell. In a real factory, we do not expect identical rules to be applicable to all manufacturing cells. Nevertheless, the general rule pattern for cells can be reused. New rules can be added for a particular cell, and rules instantiated from the pattern may also be overridden. To successfully apply rule patterns, they must include a proper design and development tool facilitating at least the four tasks depicted in Figure 1. Such a design environment based on our prototype AOODB system TriGS is operational [10]. Currently, we are extending the tool with debugging and animation facilities.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment