Rule Patterns for Designing Active Object-Oriented ... - Semantic Scholar

JOHANNES KEPLER UNIVERSITÄT LINZ INSTITUT FÜR INFORMATIK ABTEILUNG FÜR INFORMATIONSSYSTEME

o.Univ.-Prof. Dipl.-Ing. Mag. Dr. G e r t i K a p p e l

Rule Patterns for Designing Active Object-Oriented Database Applications

G. Kappel S. Rausch-Schott W. Retschitzegger email: {gerti, stefan, werner}@ifs.uni-linz.ac.at

Technical Report TR-07/95

© 1995

Altenbergerstraße 69, A-4040 Linz, Austria - Tel.: (+43) 732 / 2468-879 - Fax: (+43) 732 / 2468-9308 email: [email protected] - http://www.ifs.uni-linz.ac.at/home.html

Rule Patterns for Designing Active Object-Oriented Database Applications G. Kappel, S. Rausch-Schott, W. Retschitzegger Institute of Computer Science, Department of Information Systems University of Linz, AUSTRIA email: {gerti, stefan, werner}@ifs.uni-linz.ac.at

Abstract. Active object-oriented database systems (AOODBSs) have become widely recognized for smoothly capturing the context-dependent and time-dependent organizational knowledge of large enterprises, also known as business policies. However, not least since the remarkable panel at the RIDE'94 workshop on active database systems [Wido94] the design issue of AOODBS applications is known as one of the most pressing open research problems. This is largely because of the expressive power and flexibility of existing active object-oriented data models together with a lack of design guidelines on how to apply these models. Learning from analogous problems in object-oriented system development and borrowing their solution metaphor we introduce rule patterns as generic rule-based solutions for realizing business policies. The advantages of rule patterns are their predefined, reusable, and dynamically customizable nature allowing the designer to reuse existing experience for building AOODBS applications. The paper introduces the general notion of rule patterns and illustrates the approach by exemplary describing rule patterns for interaction modeling in workflow applications based on AOODBSs.

Keywords and Phrases: active object-oriented database design, rule patterns, advanced database applications (workflow management)

1. Introduction Active Object-Oriented Database Systems (AOODBSs) are able to immediately react to different events whose order and time of occurrence are not always predictable. Knowledge stored inside the database system determines when and how to react [Diaz91]. The representation of this knowledge is generally based on Event/Condition/Action rules (ECA rules) [Daya88]. Hence, the database system is able to monitor the situation represented by an event and by one or more conditions and to execute the corresponding action(s) when the event occurs and the condition(s) evaluate(s) to true. AOODBSs are especially useful for realizing information systems which must be able to flexibly adapt to changing requirements. Prominent representatives of such systems are workflow systems [Elli95, Garc94, Shet93, Kapp95ab]. Those aspects of workflow systems which are subject to frequent changes and, therefore, have to be kept flexible are often referred to as "business policies". Business policies typically capture context-dependent and time-dependent organizational knowledge. They may be based on ethics, law, culture and organizational commitments by either prescribing a certain action or by constraining the set of possible actions [Herb95, Odel94, Schr95]. AOODBSs provide ECA rules for an explicit, localized, and transparent specification of business policies. This is in sharp contrast to pure object-oriented systems, where business policies are mapped to some methods or parts thereof, and thus business knowledge is mixed with code realizing the intended functionality of methods [Schr95]. With ECA rules, on the one hand, reusability of methods and thus of classes is enhanced since they no longer contain application specific policies. On the other hand, reusability of the policy itself is enhanced, since it is encapsulated within rules. The unit of reusability may be the rule itself as well as any component of the rule, i.e., event, condition, and action. Reusable units can be found more easily since they are no longer hidden and distributed over different methods. In addition, by encapsulating the frequently changing parts of an application within rules points of changes can be easier localized. Changing a rule or components thereof is done locally without affecting other rules or classes. In some AOODBSs, rules support object reification, i.e., behavior is specified as data and interpreted by an engine at runtime. Thus, it is possible to change or extend -1-

system behavior dynamically by merely modifying existing rules or defining new rules. There exist different approaches aiming at the integration of active concepts with object-oriented database systems [Anwa93, Chak90, Coll94, Diaz91, Gal95, Gatz91, Gatz95, Geha92, Kotz93, Mede91]. They mainly differ in the expressive power of their event specification languages, in the integration of the rule model with the underlying object-oriented model, and in approaches for terminating rule execution. In general, the designer is confused with the power of the provided concepts and the huge amount of possibilities for implementing a certain application. Up to now little work has been done dealing with this problem of designing AOODBS applications. Existing work mainly focuses on categorizing application areas for rules [Herb94] and on the graphical representation of rule modeling. The latter approaches try to incorporate concepts for the specification of rules into conceptual design models such as extended ER-models [Petr94, Nava92] and object-oriented models [Bich94, Grot94, Rubi94]. We take a step further in the direction of supporting the design of AOODBS applications. Learning from analogous design problems in object-oriented system development and borrowing their solution metaphor rule patterns are introduced in analogy to design patterns [Alex77, Coad95, Copl95, Gamm94, Pree95]. Rule patterns provide templates for an easy specification of business policies. They both categorize rules according to different types of business policies, and at the same time provide an abstraction mechanism for specifying rules in an application independent manner. Introducing rule patterns as a means for designing AOODBS applications is the main contribution of this paper. The remainder of this paper is organized as follows: Section 2 identifies business policies being part of an AOODBS application and introduces the general notion of rule patterns. Section 4 illustrates the approach by exemplary describing rule patterns for interaction modeling in workflow applications based on AOODBSs. To make the paper self-contained, Section 3 introduces the active object-oriented model underlying rule patterns. Section 5 points to ongoing research. Due to understandability the paper only discusses some rule patterns within a small fraction of a real world example. A more complete list of rule patterns together with their application to a fully-fledged running example is shown in the appendices.

2. Designing Active Object-Oriented Database Applications The task of designing AOODBS applications is comprised of two subtasks. Firstly, the objects of the application have to be specified. And secondly, the business policies, which in general are spread over different objects, have to be identified. Since the first subtask resembles traditional object-oriented modeling [Booc94, Embl92, Jaco95, Rumb91] and object-oriented database application design [Kapp91] we build on existing work for specifying the objects at hand. The second subtask is more subtle. There exist several approaches for classifying and thus identifying business policies [Herb94, Odel94, Schr95]. Instead of arbitrarily picking one of them we extract business policies out of the object-oriented models designed in the first subtask. Then we describe the basic nature of rule patterns used for representing business policies and show how to work with them.

2.1 Identifying Business Policies Designing an object-oriented application comes up to describing three perspectives of the system [Embl92, Rumb91]. Firstly, the object model capturing the object classes and their relationships, secondly, the dynamic model capturing the behavior of each object class, and thirdly, the interaction model capturing the interactions between objects of maybe different object classes. Business policies may be identified within each of these models. As an aid to identifying business policies heuristic knowledge and organizational knowledge is applied, which may differ from one organization to the other.

-2-

(1) Business policies within the object model The object model defines attributes and relationships for each object class in order to express the possible states of an object of that class, and it defines methods for changing these states. Additionally integrity constraints may be stated ensuring validity of data by restricting the states an object may take (static constraints) as well as the possible state changes (dynamic constraints) [Ceri94, Gert93, Gref94, Urba92]. These integrity constraints typically represent points of frequent changes and thus capture business policies within the object model. (2) Business policies within the dynamic model The dynamic model specifies the life cycle of the objects of an object class, i.e., the allowed sequences of abstract states and transitions between them, by means of a state transition diagram or derivations thereof [Hare88, Rumb91]. We deliberately use the term abstract state instead of the more general term state. An abstract state is explicitly specified by means of the object’s behavior instead of the values of its attributes and relationships. A state transition diagram implicitly specifies some business policy. In particular, if an object receives a message as specified within an interaction diagram (see below) the object decides on the basis of the actual abstract state defined in its state transition diagram if it is ready to respond to this message. As soon as the object is ready to accept the message, it changes its state according to the life cycle specification and executes the corresponding method. We call this kind of business policy acceptability constraint. We assume objects may receive messages concurrently, i.e., objects are active entities having their own thread of control (cf. inter-object-concurrency [Nier93]). In contrast, in sequential object-oriented systems objects are passive entities. Upon acceptance of a message the corresponding method is executed synchronously within the sender’s thread of control. After having finished the method the sender is reactivated and continues execution. (3) Business policies within the interaction model The interaction model specifies the interaction between both, active and passive objects to reach a common task, often referred to as use case [Jaco95]. The preferred representation technique for interaction models are interaction diagrams. An interaction diagram specifies a sequence of interactions, i.e., messages sent from a certain sender within a certain method context to one ore more receivers. The business policies in this model are reflected in message ordering, receiver selection, synchronization modes and real time constraints [Bran93, Booc94, Embl92]. Message ordering and receiver selection determine which message has to be sent next to which receiver object(s). The synchronization mode defines how objects involved in an interaction are synchronized with each other, whereas real time constraints specify begin, maximum duration, and end of an interaction.

2.2 Rule Patterns for Realizing Business Policies Rule patterns for realizing the above mentioned business policies are introduced in analogy to design patterns in object-oriented system development. Design patterns are "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context" [Gamm94]. In contrast, rule patterns are descriptions of rules, predefining certain event/condition/action-pairs. However, rule patterns and design patterns have in common that both are intended to give some guidance for how a problem can be solved by using the concepts of an underlying model. This is the active object-oriented model in case of rule patterns, and the pure object-oriented model in case of design patterns. Both approaches also try to facilitate reusable designs. In case of rule patterns, these reusable designs are abstract means to capture a certain kind of business policy in a generic and thus application independent manner. The rule designer is relieved from the task to capture business policies into rules again and again. Generally, rule patterns consist of predefined parts and of parameterized parts. Consequently, in -3-

order to map a certain kind of business policy to a rule pattern, parts independent from particular applications as well as parts specific to particular applications have to be identified. The parameters vary according to the different kinds of policies. When a rule is created by means of a rule pattern, these parameters are bound according to the desired usage of the rule. As a prerequisite for describing rule patterns in detail in Section 4 we illustrate a possible design environment based on rule patterns and their underlying model beforehand. For each kind of business policy identified within the object model, the dynamic model and the interaction model rule patterns are provided. These patterns are all stored as first-class objects within a library organized as a set of dictionaries. Of course, we are far from claiming that our set of rule patterns is complete. Consequently, this rule library must be extensible by both, defining new patterns and specializing existing ones (cf. ① in Figure 1). At the same time, it should be possible to easily reuse existing patterns or parts of them. In order to use rule patterns within an application, they have to be customized by the application designer. This is done by binding the parameters of a selected pattern on the basis of the application semantics. The system guides the application designer during the process of 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 (cf. Figure 6). Once a rule has been fully and correctly specified, it can be automatically generated and stored into the rule base attached to the corresponding application (cf. ② in Figure 1). ③

③

RuleBase 1

Pattern Library

Definition of new rule patterns by factoring out ④

Integrity Patterns

② Message Ordering Patterns

③

RuleBase 2

④ Receiver Selection Patterns

Definition of new rules from scratch

RuleBase 3

② Sync Patterns

④ Real-Time Patterns

②

Application of rule patterns

User-Defined Patterns

①

Definition of new rule patterns from scratch

Figure 1. Working with Rule Patterns

Furthermore, it should still be possible to specify rules without using a pattern and to store them directly within the appropriate rule base (cf. ③ in Figure 1). This is normally done for rules without reusability in mind. If sometimes later an application designer recognizes that a specific design situation recurs and thus is worth to be specified by a corresponding rule pattern, existing rules can be used for this abstraction process (cf. ④ in Figure 1).

3. The Underlying Model We define rule patterns on the basis of an AOODBS called TriGS (=Trigger system for GemStone) [Kapp94a]. Like most active systems, TriGS is designed according to the ECA paradigm [Daya88]. Rules and its components are implemented as first-class objects allowing both the definition and modification of rules during run time. Figure 2 shows the basic structure for specifying rules in TriGS using the Backus-Naur Form (BNF). The symbols ::= [ ] are meta symbols belonging to the BNF formalism.

-4-

::=

DEFINE RULE AS ON /* IF THEN /* [WAIT UNTIL] [ON ] /* EXECUTE [INSTEAD] /*

Condition event selector */ Condition part */ Action event selector */ Action part */

Figure 2. BNF of an ECA Rule in TriGS

The event part of a rule is represented by a condition event selector (Cesel) and an optional action event selector (Aesel) determining the events (e.g., a machine breakdown) which are able to trigger the rule’s condition and action, respectively. Triggering a rule’s condition, i.e., an event corresponding to the Cesel is signalled, implies that the condition has to be evaluated. If the condition evaluates to true, and an event corresponding to the Aesel is also signalled, the rule’s action is executed. If the Aesel is not specified, the action is executed immediately after the condition has been evaluated to true. By default, the thread of control signalling the condition triggering event is not blocked while the triggered rule is waiting for the action triggering event to occur. Blocking can be specified by the keyword WAIT UNTIL. In TriGS, any message sent to an object may signal a message event. Furthermore, TriGS supports time events, external events, and composite events similar to the approach described in SNOOP [Anwa94]. For each event, a guard, i.e., a predicate over the event’s parameters similar to masks in ODE [Geha92], may be specified, which further restricts the events able to trigger a condition or action, respectively. The condition part of a rule is specified by a boolean expression, possibly based on the result of a database query (e.g., are there some scheduled jobs on the damaged machine?). The action part is specified again in terms of messages (e.g., display all jobs scheduled on the damaged machine and reschedule them on another machine). Considering message-based rules, the keyword INSTEAD allows to specify that the action should be executed instead of the method corresponding to the message triggering the condition. TriGS has been implemented on top of the object-oriented database system GemStone1 [Serv94] as part of a larger EC ESPRIT project. The GemStone data model is based on the OPAL2 programming language, which is a derivate of Smalltalk-80. For an in-depth discussion of TriGS we refer to [Kapp94ab, Kapp95c]. Special features of TriGS necessary for understanding the forthcoming rule patterns are described on the fly.

4. Synchronization Rule Patterns It would be far beyond the space of this paper to specify rule patterns for all business policies identified in Section 2.1. Our primary application domain of AOODBSs are workflow systems [Kapp95ab], and it is crucial for workflow systems to flexibly model the synchronization between the involved activities. Thus, in the following we restrict our discussion to rule patterns for business policies capturing different synchronization modes. These rule patterns are called synchronization rule patterns. Synchronization rule patterns are some kind of interaction structure abstraction similar to the already well known data structure abstractions (e.g. classification, association, aggregation, and generalization/specialization) and to control structure abstractions (e.g. sequence, condition, and iteration). The idea of explicitly specifying object interactions is also applied by contracts [Helm90, Holl92] and composition filters [Aksi93]. Contracts differ from synchronization rule patterns mainly in that they do not address concurrency issues. Both, contracts and composition filters are situated within the area of object-oriented programming languages whereas rule patterns provide means to design active object-oriented database systems. Before exemplary describing three synchronization rule patterns in detail, we give an overview of the kinds of synchronization we want to realize and illustrate the common structure of the corresponding synchronization rule patterns. 1 2

GemStone is a registered trademark of Servio Corporation OPAL is a trademark of Servio Corporation

-5-

4.1 Synchronization Modes As shown in Table 1, we support eight modes of synchronization differing in how the sender of a message synchronizes with the receiver according to the following two issues: (1) Begin of Interaction Concerning the begin of an interaction, both, the acceptability of the receiver (cf. Section 2.1) and what has to be done if the receiver is not immediately ready to satisfy the request has to be specified. In this case, there exist four different possibilities: • The sender waits until the receiver accepts (cf. "Timeout = ∞" in Table 1). • The sender waits for the receiver for a certain time interval "x". If timeout occurs an exception is raised (cf. "Timeout = x"). • The sender does not wait for the receiver. Rather, an exception is raised immediately (cf. "Timeout = 0"). • The sender does not wait until the receiver accepts, but rather continues execution immediately after sending the message (cf. "Asynchronous"). (2) End of Interaction Considering the end of an interaction, it has to be specified whether the sender is blocked until the receiver has finished execution (cf. column "Synchronous") or it is not blocked (cf. column "Asynchronous"). Concerning the latter, the sender may wait for the result of the receiver at some future point in time (cf. column "Future Synchronous"). In our model an asynchronous begin of interaction excludes a synchronous end of interaction. Similarily, a synchronous begin of interaction excludes a future synchronous end of interaction. End of Interaction Begin of Interaction Timeout = ∞

Synchronous

Timeout = x

Synchronous Blocking

Asynchronous

Future Synchronous

Synchronous Start S

Blocking with Timeout

Synchronous Start with Timeout

not applicable

not applicable

S

Balking

Balking Asynchronous not applicable

Timeout = 0 Asynchronous Asynchronous

not applicable

Future Synchronous F

Table 1: Synchronization Modes

4.2 Common Structure of Synchronization Rule Patterns Synchronization rule patterns all have an event part defining that the rule should be triggered by message passing identifying the interaction. For some synchronization modes, the condition of the corresponding rule patterns has to check the acceptability for the specific message (cf. acceptability constraint within the dynamic model). Note, that although some business policies are spread over the -6-

interaction model and the dynamic model they are mapped to different parts of a single rule pattern. The action of these rule patterns is responsible for both, synchronizing the start of the interaction depending on the acceptability and for blocking versus non blocking execution of the requested method. In the following, we define common components of synchronization rule patterns which are used repeatedly within the rule patterns described in Section 4.3 and in Appendix A. (1) Interaction Identification Independent of the synchronization mode, the user has to identify the interaction for which the rule must be applied. Since in object-oriented systems objects communicate by exchanging messages, synchronization rules are always triggered by message passing. Figure 3 shows a sender object interacting with a receiver object by sending a message within the context of a sender method. Sender object and receiver object are denoted as vertical bars. Time progresses from top to bottom of the lines. Solid lines designate active threads of control and dashed lines designate inactive, i.e., blocked threads of control within the same object. Black arrows denote synchronous begin or synchronous end of interaction between objects. The notation is based partly on the notation for event-trace diagrams of OMT [Rumb91], and on the interaction diagram notation of OSA [Embl92] and will be used in the forthcoming subsections, too. sender

receiver Legend:

sender method

message

... active thread of control ... inactive thread of control ... blocking interaction

(result) Figure 3. Interaction Identification

The condition event selector of any synchronization rule pattern is defined as follows. Note that parameters of the pattern are enclosed within angle brackets: DEFINE EVENT SELECTOR InteractionSel AS PRE (, , , ).

For the parameters and classes as well as objects may be specified. In case of classes being specified, a rule containing that event selector is triggered whenever the is sent from/to any instance of the class specified for the / parameter. The keyword PRE denotes that the rule is triggered before the requested method corresponding to is executed. All parameters of the InteractionSel are optional. If both, sender and receiver objects and methods are specified, the rule is attached to one specific interaction. If the same rule shall be applied for more than one interaction, some or even all of the parameters can be left unspecified. For example, if it is irrespective from which method is sent, is not specified and the rule is triggered whenever the specified sends to . (2) Interaction Acceptability As stated in Section 4.1, synchronization rules occasionally have to check whether the receiver is ready, i.e., in the correct abstract state. For sake of simplicity, we assume that every object has an implicit multi-valued instance variable state holding its actual abstract state(s). This instance variable is automatically updated by defining a rule for each transition defined in the life cycle diagram of the object. The actual abstract state of the receiver (Cesel.receiver.state) is checked by the condition part of synchronization rule patterns. It investigates if the actual abstract state equals one of the requested prestate(s) of the transition corresponding to the incoming message: DEFINE CONDITION InvalidState AS Cesel.receiver.state { AND Cesel.receiver.state }*

-7-

The keyword Cesel references the parameters of the event triggering the condition of the rule, like the receiver (receiver) of the message that triggered the condition, and the triggering time (time), to mention just a few. For some synchronization modes the defining rules have to wait until the receiver reaches one of the prestates of the transition corresponding to the incoming message. This is specified in the Aesel of the corresponding rule patterns. The following Aesel specifies that the action should be triggered after one of the methods corresponding to a transition leading to a specific state has been executed. Since one distinct message may be used as event for different transitions, occasionally the state which has been set by the transition has to be checked within a guard enclosed in square brackets of the corresponding Aesel: DEFINE EVENT SELECTOR Tran2Accept AS (POST(Cesel.receiver, ) [’[’Cesel.receiver.state == ’]’]) { OR (POST(Cesel.receiver, ) [’[’Cesel.receiver.state == ’]’]) }*

4.3 Exemplary Synchronization Rule Patterns We will now describe synchronization rule patterns for the three synchronization modes Blocking, Asynchronous, and Future Synchronous (cf. Table 1) in detail. For a description of the remaining synchronization modes stated in Table 1 we refer to Appendix A. Some patterns specify a single rule template, others specify several rule templates working together to realize the desired semantics of the rule pattern at hand. 4.3.1 The Blocking Rule Pattern Problem: Since we assume a concurrent object-oriented system as the underlying model, message passing in contrast to sequential systems - may be synchronous or asynchronous. Synchronous execution of a receiver method is still needed in case that the sender needs the result at once. The receiver object has to ensure that it is in the right state for satisfying a certain request. This is achieved by explicitly accepting a sent message. The semantics of blocking corresponds to a remote procedure call and is shown within the interaction diagram in Figure 4. Grey arrows denote requests from other senders to the receiver, enabling the receiver object to accept the requested message from the sender by making the transition to the correct abstract state (cf. synchronization point in Figure 4). sender

receiver

synchronization point

Legend: ... active threads of control ... inactive thread of control ... blocking interactions

Figure 4. Blocking Interaction

Solution: A Blocking rule pattern extends the semantics of sequential message passing by explicitely specifying that the sender has to wait for the receiver being in the appropriate abstract state. The latter is checked by the condition part of the Blocking rule pattern. If the receiver is not in the correct abstract state, the triggering thread of control, i.e., the sender, is blocked (cf. keyword WAIT UNTIL) until the correct abstract state is reached. In this case the rule immediately returns control to the requested method since it has an empty action (cf. NIL). One benefit of using this rule is the fact that the sender does not have to check for the right state of the receiver periodically (polling) since reaching the ap-8-

propriate state is signalled by the receiver instead. DEFINE RULE r_blk_ AS ON InteractionSel DO IF InvalidState THEN WAIT UNTIL ON Tran2Accept EXECUTE NIL. /* go on with execution of the requested method */

Remember, that we assume multiple threads of control in the sense that either the receiver object has its own thread of control, or another thread of control besides the triggering thread of control accesses the passive receiver object. This is necessary since the receiver object has to receive one or more messages assuring that it eventually reaches the correct abstract state. Otherwise, the rule would wait forever. The application of the Blocking rule pattern requires the binding of actual values to the parameters within Cesel, condition, and Aesel. Example: To increase the understanding of the proposed rule patterns, we illustrate each pattern on the basis of a running example. A full specification and explanation of the example including object diagram, interaction diagram and state transition diagrams as well as all rules realizing the intended synchronization modes on the basis of the proposed rule patterns can be found in Appendix B and Appendix C, respectively. The example is a typical workflow application realizing a computerized motel reservation management system. This system allows to manage reservations for a nationwide consortium of motels connected via a wide area network, such as Internet. Reservation transactions can be submitted to the consortium from any node within the network concurrently by using a web-browser-like interface. The consortium is responsible for delegating requests to the appropriate motels and transferring results back to the user interface. Each motel manages rooms grouped into different categories. A customer is able to make new reservations and change or delete existing ones. In order to be able to check the availability of rooms for a certain reservation request, a motel has to retrieve a list of rooms from the Category object corresponding to the desired room category stored within the reservation object (resObj). For this task, the Motel object interacts with the Category object by sending the message getRooms synchronously, blocking until the result is available (cf. Figure 5).

tryRes (resObj)

Motel

Category

getRooms

Legend: ... active thread of control ... inactive thread of control

(roomList)

... blocking interaction

Figure 5. Blocking Interaction Between Motel and Category

For the realization of this business policy a rule can be easily derived from the Blocking rule pattern by defining its parameters using a corresponding form. On the basis of this parameter binding the system automatically generates a rule. Figure 6 illustrates the approach of generating a blocking interaction business rule out of the Blocking rule pattern. Note, that in all forthcoming rules actual parameters are shown in bold type. The Cesel of this rule identifies the interaction by defining a pre message event which is signalled every time a Motel object sends the message getRooms to a Category object from within the method tryRes:resObj. The condition checks if the category object is in the appropriate abstract state for responding to getRooms. In our example, it compares for state Idle. For the state transition diagram for class Category specifying its acceptability we refer to Appendix B. The Aesel is specified as disjunction of three simple post message event selectors leading to the state Idle. -9-

DEFINE RULE r_blk_Motel_getRooms_Category AS ON PRE(Motel,tryRes:resObj,Category,getRooms) DO IF Cesel.receiver.state "Idle" THEN WAIT UNTIL ON POST (Cesel.receiver, getRooms) OR POST (Cesel.receiver, addRoom:room) OR POST (Cesel.receiver, removeRoom:room) EXECUTE NIL.

Figure 6. Parameter Binding for a Blocking Rule Pattern

4.3.2 The Asynchronous Rule Pattern Problem: If a sender does not need the result(s) of a method requested from some receiver, concurrency may be improved by asynchronously communicating with the receiver. In this case, there is no need to synchronize with the receiver at all. From the sender’s point of view no check for the receiver´s state is necessary, and the sender does not have to wait for the receiver to finish method execution. The receiver may process the request as soon as having entered the appropriate state. Asynchronous interaction is denoted by a flash arrow in Figure 7. sender

receiver Legend:

synchronization point

... active threads of control ... asynchronous interaction ... blocking interaction

Figure 7. Asynchronous Interaction

Solution: The Asynchronous rule pattern is not only responsible for checking the acceptability of the receiver but also for making the interaction asynchronous. In contrast to Blocking, the action responsible for the latter has to be executed not only if the receiver reaches the correct abstract state after the interaction has been started, i.e. after the rule has been triggered. Rather, it has to be executed also if the receiver is already in the correct abstract state. Therefore, the condition of the rule pattern is set to TRUE. Furthermore, the Asynchronous rule pattern does not block the triggering thread of control while waiting for the receiver’s correct abstract state, i.e., no WAIT UNTIL is specified. The Aesel consists of two parts. The first part specifies events leading to the correct abstract state (cf. Tran2Accept). The second part of the Aesel ensures that the action is triggered immediately in case that the receiver is already in the appropriate abstract state by defining a sequence of events (cf. sequence operator ";"). This sequence specifies that any event leading to the correct abstract state (cf. Tran2Accept) followed by any event triggering the condition (cf. InteractionSel) should trigger the action of the rule. Note that this sequence event may start to occur before the condition of the rule is triggered. The action of the rule starts the execution of the receiver’s method within an asynchro- 10 -

nous thread of control (cf. keyword ASYNC) instead of the synchronous execution within the triggering thread of control (cf. keyword INSTEAD). To ensure that the rule is not triggered by that method invocation again, the action additionally deactivates the rule before sending the message to the receiver (deactivateFor:) and reactivates it afterwards (activateFor:). DEFINE RULE r_async_ AS ON InteractionSel IF TRUE THEN ON Tran2Accept OR (Tran2Accept;InteractionSel) EXECUTE INSTEAD ASYNC r_async_ deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver r_async_ activateFor: (Cesel.sender, Cesel.receiver).

Example: Continuing with our running example, the Consortium object asynchronously propagates the message tryRes to all motels satisfying the user’s request stored within the resObj, quits its current thread of control and gets ready for further requests (cf. abstract state Idle in Figure 20). newRes (resObj)

Consortium tryRes (resObj)

Motel

Legend: ... active thread of control ... asynchronous interaction (one to many)

Figure 8. Asynchronous Interaction Between Consortium and Motel

Following the corresponding rule pattern to construct the rule, it is necessary to bind the parameters for Cesel, Aesel, and action. In order to reduce complexity and increase understandability, we describe the automatically generated rules for the remaining rule patterns step by step, refraining from illustrating the correponding forms. The Cesel of the exemplary rule identifies the interaction by a pre message event e_Cons_tryRes_Motel which is signalled every time a Consortium object sends the message tryRes:resObj to a Motel object from within newRes:resObj (cf. also Figure 8). DEFINE EVENT SELECTOR e_Cons_tryRes_Motel AS PRE(Consortium, newRes:resObj, Motel, tryRes:resObj).

The interaction should be accepted by the motel only if it is in state Idle. Thus, the Aesel specifying the acceptability is defined by a composite event selector consisting of four simple message event selectors representing alternative transitions leading to the state Idle: DEFINE EVENT SELECTOR e_Motel_new AS POST(Cesel.receiver, CLASSMETHOD new). DEFINE EVENT SELECTOR e_Motel_notify AS POST(Cesel.receiver, notify:availability for:tID from:room). DEFINE EVENT SELECTOR e_Motel_reserve AS POST(Cesel.receiver, reserve:resObj). DEFINE EVENT SELECTOR e_Motel_tryRes AS POST(Cesel.receiver, tryRes:resObj).

To construct the composite Aesel, these event selectors are connected by OR operators and the sequence operator (;) according to the rule pattern. The guard ensures that, if the event e_Motel_new is signalled the newly created object (left.left.retVal) is identical to the condition triggering object (right.receiver). Note, that, a composite event selector is stored as a tree and its components can be recursively accessed by the keywords left and right. DEFINE EVENT SELECTOR e_Motel_Idle AS e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes OR ((e_Motel_new OR e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes) ; PRE(Consortium, newRes:resObj, self, tryRes:resObj)) [left.left.retVal=right.receiver].

- 11 -

After binding the message tryRes:resObj to the parameters of the action of the rule pattern, the rule is fully specified: DEFINE RULE r_async_Cons_tryRes_Motel AS ON e_Cons_tryRes_Motel DO IF TRUE THEN ON e_Motel_Idle EXECUTE INSTEAD ASYNC r_async_Cons_tryRes_Motel deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver tryRes: resObj r_async_Cons_tryRes_Motel activateFor: (Cesel.sender, Cesel.receiver).

4.3.3 The Future Synchronous Rule Pattern Problem: If a message is sent asynchronously, it is assumed that the sender does not need any result of the requested method. However, often the result of a certain request is needed at least sometime in the future. Using synchronous interaction ensures that the sender waits for the result but at the expense of concurrency. For this reason, many concurrent object-oriented models [Nier93, Toko87] suggest a further synchronization mode called future synchronous (denoted as a flash arrow with the symbol F). This synchronization mode is different to asynchronous interaction in that the sender will wait for the result of the receiver method sometime in the future, if it isn't already available. Until that point in time, the sender is able to continue execution concurrently with the receiver (cf. Figure 9). Some models [Toko87] even allow to explicitly check the availability of the result. This further increases flexibility since the sender may then decide to perform some other tasks while still waiting for the result, or it might even choose an alternative task to execute. sender F

receiver

Legend: ... active threads of control

synchronization point

... inactive thread of control

F

wait for result

... future sync. interaction ... blocking interaction

Figure 9. Future Synchronous Interaction

Solution: The Future Synchronous pattern consists of three rule templates. The first rule template is responsible for asynchronous interaction and resembles the Asynchronous rule pattern (cf. Section 4.3.2). The other two rule templates are responsible for realizing "handshaking", i.e., for transferring the result from the receiver to the sender. For the specification of this rule pattern, several assumptions concerning the underlying object model have been made. Firstly, an object responds to a message as soon as it is in the correct abstract state for that message. If two messages of the same type are received the object responds in the order of arrival. Secondly, it is assumed that the triggering thread of control raises an explicit event e_getResult(receiver,message) signalling that it needs the result of the requested method. The parameters of the explicit event have to be provided by the sender. Together with the implicit parameter Cesel.sender, i.e., the sender object, they uniquely identify the interaction for which the result is required. Finally, the asynchronous transfer of the result is synchronized via a shared data structure, i.e., a queue called ResultQueue. The rules check whether the result is already available (cf. method resultAvailableFor), read the result as soon as available, remove the corresponding element from the queue, and return the result to the triggering thread of control (cf. keyword RETURN below). Note that the two rule templates have complementary conditions.

- 12 -

DEFINE RULE R_GetResult_ AS ON e_getResult (receiver, message) IF ResultQueue resultAvailableFor(Cesel.sender,receiver,message) THEN EXECUTE RETURN (ResultQueue dequeue(Cesel.sender,receiver,message)). DEFINE RULE R_WaitForResult_ AS ON e_getResult (receiver, message) IF NOT ResultQueue resultAvailableFor(Cesel.sender,receiver,message) THEN WAIT UNTIL ON POST (receiver, message) EXECUTE RETURN (ResultQueue dequeue(Cesel.sender,receiver,message)).

Example: Considering our running example, every time the user requests a new reservation from the UI, the user interface object sends the message newRes future synchronously to the Consortium object, thus creating another thread of control within the Consortium object. For the sake of this example, we assume that, firstly, the system does not allow the user to request several reservations from one UI object concurrently, and secondly, that the Consortium - which only delegates reservation requests to Motels and sends answers from the Motels back to the UIs - is able to handle requests from different UIs concurrently. Consequently, the interaction between UI and Consortium is neither asynchronous nor synchronous. In case of asynchronous interaction, the user would be able to send further requests to the UI before having received the result of the pending request. In case of synchronous interaction, the UI would expect the result as soon as the Consortium returns control, and thus, the Consortium would have to be blocked until the result of the request is available.

newRes (resObj)

UI

Consortium newRes (resObj) Legend:

F

... active threads of control ... inactive thread of control

(resObj’, state)

F ... future sync. interaction

Figure 10. Future Synchronous Interaction Between UI and Consortium

As mentioned before, the Future Synchronous rule pattern realizes future synchronous interaction by a set of three rule templates. The first rule template is responsible for starting the interaction asynchronously and is constructed by binding the appropriate parameters for Cesel, Aesel and action analogously to the rule in Subsection 4.3.2. The Cesel of this rule identifies the interaction by a pre message event which is signalled every time a UI object sends the message newRes:resObj to a Consortium object from within newRes:resObj: DEFINE EVENT SELECTOR e_UI_newRes_Cons AS PRE(UI, newRes:resObj, Consortium, newRes:resObj).

The interaction should be accepted by the Consortium only if it is in state Idle. Thus, the Aesel specifying the acceptability is defined by a composite event selector consisting of three simple message event selectors representing alternative transitions leading to the state Idle: DEFINE EVENT SELECTOR e_Cons_new AS POST(Cesel.receiver, CLASSMETHOD new). DEFINE EVENT SELECTOR e_Cons_notify AS POST(Cesel.receiver, notify:availability for:tID from:motel with:room). DEFINE EVENT SELECTOR e_Cons_newRes AS POST(Cesel.receiver, newRes:resObj).

To construct the composite Aesel, the specified event selectors are connected by OR operators and the sequence operator, according to the Asynchronous rule pattern. Analogously to the asynchronous rule in Section 4.3.2, the guard ensures that, if the event e_Cons_new is signalled the newly created - 13 -

object (left.left.retVal) is identical to the condition triggering object (right.receiver): DEFINE EVENT SELECTOR e_Cons_Idle AS e_Cons_notify OR e_Cons_newRes OR ((e_Cons_new OR e_Cons_notify OR e_Cons_newRes) ; PRE(UI, newRes:resObj, self, newRes:resObj)) [left.left.retVal=right.receiver].

After binding the message newRes:resObj to the parameters of the action of the rule template the rule is fully specified: DEFINE RULE r_async_UI_newRes_Cons AS ON e_UI_newRes_Cons DO IF TRUE THEN ON e_Cons_Idle EXECUTE INSTEAD ASYNC r_async_UI_newRes_Cons deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver newRes: resObj r_async_UI_newRes_Cons activateFor: (Cesel.sender, Cesel.receiver).

The other two rule templates belonging to the Future Synchronous rule pattern are responsible for waiting for the result and retrieving it. Since they are not parameterized they are left unchanged and may be used as such with any future synchronous rule.

5. Conclusion Similar to design patterns supporting the pure object-oriented design, we introduce rule patterns supporting the design of active object-oriented database applications. Rule patterns not only facilitate reusable but also maintainable designs of information systems since rules can be created and modified at runtime. In this paper, we presented the general notion of rule patterns and introduced a number of patterns realizing higher level interaction semantics within the realm of workflow applications based on active object-oriented database systems. The proposed pattern catalogue, of course, is far from being complete, but should illustrate the basic idea. The parts of a workflow system which should be reusable and maintainable are called business policies. Future work will include the development of additional rule patterns for business policies other than interaction policies introduced in this paper, and the further implementation of a design environment for AOODBSs based on rule patterns. In the long run, designers of AOODBS applications should not be concerned with decisions on how a recurring design problem is realized by using objects and rules. They should rather be able to compose their applications out of a framework of predefined parameterized rule patterns.

References [Aksi93]

M. Aksit, K. Wakita, J. Bosch, L. Bergmans, A. Yonezawa, Abstracting Object Interactions Using Composition Filters, Proc. of the ECOOP’93 Workshop on Object Based Distributed Programming, R. Guerraoui, O. Nierstrasz, M. Riveill (eds.), Springer LNCS 791, Kaiserslautern, July 1993

[Alex77]

C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, S. Angel, A Pattern Language, Oxford University Press, New York, 1977

[Anwa93]

E. Anwar, L. Maugis, S. Chakravarthy, A new Perspective on Rule Support for Object-Oriented Databases, Proc. of the ACM-SIGMOD Int. Conference on Managment of Data, SIGMOD Record, 22 (2), pp. 99108, June 1993

[Anwa94]

E. Anwar, S. Chakravarthy, S.-K. Kim, V. Krishnaprasad, Anatomy of a Composite Event Detector, Proc. of the 20th Int. Conference on Very Large Data Bases (VLDB’94), Santiago, Chile, 1994

[Bich94]

P. Bichler, M. Schrefl, Active Object-Oriented Database Design Using Acitve Object/Behavior Diagrams, Proceedings RIDE’94, 4th Int. Workshop on Research Issues in Data Engineering, J. Widom, S. Chakravarthy (eds.), Houston, 1994

[Booc94]

G. Booch, Object-Oriented Analysis and Design (second edition), Benjamin/Cummings, 1994

[Bran93]

H. Branding, A. Buchmann, T. Kudrass, J. Zimmermann, Rules in an Open System: The REACH Rule Sys- 14 -

tem, Rules in Database Systems, C.J. van Rijsbergen (ed.), Springer, Edinburgh, 1993 [Ceri94]

S. Ceri, R. Manthey, Chimera: A Model and Language for Active DOOD Systems, Proc. of the 2nd Int. East/West Database Workshop, J. Eder, L.A. Kalinichenko (eds.), Springer, Klagenfurt, Austria, Sept. 1994

[Chak90]

S. Chakravarthy, S. Nesson, Making an Object-Oriented DBMS Active: Design, Implementation, and Evaluation of a Prototype, Proc. of the Int. Conference on Extending Database Technology (EDBT), Venice, Springer LNCS 416, pp. 393-406, March 1990

[Coad95]

P. Coad, D. North, M. Mayfield, Object Models - Strategies, Patterns & Applications, Yourdon Press Computing Series, Prentice Hall, 1995

[Coll94]

C. Collet, T. Coupaye, T. Svenson, NAOS - Efficient and modular reactive capabilities in an Object-Oriented Database System, Proc. of the 20th Int. Conference on Very Large Data Bases (VLDB), Santiago, Chile, 1994

[Copl95]

J.O. Coplien, D.C. Schmidt (eds.), Pattern Languages of Program Design, Addison-Wesley, 1995

[Daya88]

U. Dayal et al., The HiPAC Project: Combining Active Databases and Timing Constraints, ACM SIGMOD Record, 17 (1), pp. 51-70, March 1988

[Diaz91]

O. Diaz, N. Paton, P. Gray, Rule Management in Object Oriented Databases: A Uniform Approach, Proc. of the 17th Int. Conference on VLDB, Barcelona, pp. 317-326, 1991

[Dohe93]

M. Doherty, J. Peckham, V.F. Wolfe, Implementing Relationships and Constraints in an Object-Oriented Database Using a Monitor Construct, Rules in Database Systems, C.J. van Rijsbergen (ed.), Edinburgh, 1993

[Elli95]

C.A. Ellis, K. Keddara, Dynamic Change within Workflow Systems, to appear in: Proc. of the ACM SIGOIS Conference on Organizational Computing Systems, Milpitas, California, August, 1995

[Embl92]

D.W. Embley, B.D. Kurtz, S.N. Woodfield, Object-Oriented System Analysis - A Model-Driven Approach, Yourdan Press, 1992

[Gal95]

A. Gal, O. Etzion, Maintaining Data-Driven Rules in Databases, IEEE Computer, January 1995

[Gamm94]

E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Series, 1994

[Garc94]

H. Garcia-Molina, K. Salem, Services for a Workflow Management System, IEEE Bulletin of the Technical Committee on Data Engineering, 17 (1), March 1994

[Gatz91]

S. Gatziu, A. Geppert, K.R. Dittrich, Integrating Active Concepts into an Object-Oriented Database System, Proc. of the 3rd Int. Workshop on Database Programming Languages, Nafplion, 1991

[Gatz95]

S. Gatziu, Events in an Active Object-Oriented Database System, PhD, Kovac, 1995

[Geha92]

N.H. Gehani, H.V. Jagadish, O.Shmuheli, Composite Event Specification in Active Database Systems, Proc. of the 18th Int. Conference on VLDB, August 1992

[Gepp95]

A. Geppert, K.R. Dittrich, Specification and Implementation of Consistency Constraints in Object-Oriented Database Systems: Applying Programming-by-Contract, Proc. of GI-Conference on Database Systems for Office, Technology and Science (BTW), Dresden, March 1995

[Gert93]

M. Gertz, U.W. Lipeck, Deriving Integrity Maintaining Triggers from Transition Graphs, 9th Int. Conf. on Data Engineering (DE’93), IEEE Computer Society Press, Vienna, 1993

[Gref94]

P.W.P.J. Grefen, R.A. de By, P.M.G. Apers, Integrity Control in Advanced Database Systems, IEEE Bulletin of the Technical Committee on Data Engineering, 17 (2), June 1994

[Grot94]

T. Grotehen, K.R. Dittrich, Erweiterung konzeptueller Objektmodelle für den Entwurf aktiver Systeme, Technical Report, Zürich, 1994

[Hare88]

D. Harel, On Visual Formalisms, Communications of the ACM, 31 (5), May 1988

[Helm90]

R. Helm, I.M. Holland, D. Gangopadhyay, Contracts: Specifying Behavioral Compositions in Object-Oriented Systems, Proc. of the conjoint OOPSLA/ECOOP Conference, ACM Press, pp. 169-180, Ottawa, Canada, 1990

[Herb94]

H. Herbst, G. Knolmayer, T. Myrach, M. Schlesinger, The specification of business rules: a comparison of selected methodologies, Methods and Associated Tools for the Information System Life Cycle, A.A. Verrijn-Stuart and T.W. Olle (eds.), North-Holland, IFIP 1994

[Herb95]

H. Herbst, A Meta-Model for Business Rules in Systems Analysis, 7th Int. Conf. on Computer Aided Sys- 15 -

tems Engineering (CAiSE), J. Iivari, K. Lyytinen, M. Rossi (eds.), Springer LNCS 932, Jyväskylä, Finland, June 1995 [Holl92]

I.M. Holland, Specifying reusable components using Contracts, Proc. of ECOOP92, O. Lehrmann Madsen (ed.), Springer LNCS 615, 1992

[Hull87]

R. Hull, R. King, Semantic Database Modelling: Survey, Applications, and Research Issues, ACM Com puting Surveys 19 (3), September 1987

[Jaco95]

I. Jacobson, M. Eriksson, A. Jacobson, The Object Advantage - Business Process Reengineering with Object Technology, Addison-Wesley, 1995

[Kapp91]

G. Kappel, M. Schrefl, Object/Behavior Diagrams, Proc. of the 7th Int. Conference on Data Engineering, pp. 530-539, Kobe, Japan, April 1991

[Kapp94a]

G. Kappel, S. Rausch-Schott, W. Retschitzegger, S. Vieweg, TriGS - Making a Passive Object-Oriented Database System Active, Journal of Object-Oriented Programming (JOOP), July-August, 1994

[Kapp94b]

G. Kappel, S. Rausch-Schott, W. Retschitzegger, Beyond Coupling Modes - Implementing Active Concepts on Top of a Commercial ooDBMS, Int. Symposium on Object-Oriented Methodologies and Systems (ISOOMS), Springer LNCS 858, 1994

[Kapp95a]

G. Kappel, B. Pröll, S. Rausch-Schott, W. Retschitzegger, TriGSflow - Active Object-Oriented Workflow Management, Proc. of the 27th Hawaiian Int. Conf. on System Sciences (HICSS’95), 1995

[Kapp95b]

G. Kappel, S. Rausch-Schott, W. Retschitzegger, Workflow Management based on Objects, Rules and Roles, IEEE Bulletin of the Technical Committee on Data Engineering, 18 (1), March, 1995

[Kapp95c]

G. Kappel, S. Rausch-Schott, W. Retschitzegger, A M. Tjoa, S. Vieweg, R. Wagner, Active Object-Oriented Database Systems For CIM Applications, in: V. Marik (ed.), CIM-Textbook (TEMPUS-Project), Springer LNCS, (in print), 1995

[Kapp95d]

G. Kappel, S. Rausch-Schott, W. Retschitzegger, Rule Patterns for Designing Active Object-Oriented Database Applications, Technical Report, Dept. of Information Systems, University of Linz, June 1995

[Kilo94]

H. Kilov, J. Ross, Information Modeling - An Object-Oriented Approach, Prentice Hall Object Series, 1994

[Kotz93]

A. Kotz-Dittrich, Adding Active Functionality to an Object-Oriented Database System - a Layered Approach, Proc. of GI-Conference on Database Systems for Office, Technology and Science (BTW), Braunschweig, W. Stucky, A. Oberweis (eds.), Springer-Verlag, pp. 54-73, March 1993

[Mede91]

C. B. Medeiros, P. Pfeffer, Object Integrity Using Rules, 5th European Conf. on Object-Oriented Programming (ECOOP’91), P. America (ed.), Springer LNCS 512, pp. 219-230, 1991

[Meye92]

B. Meyer, Eiffel - The Language, Prentice Hall, 1992

[Nava92]

S.B. Navathe, A. Tanaka, S. Chakravarthy, Active Database Modeling and Design Tools: Issues, Approach and Architecture, IEEE Bulletin of the Technical Committee on Data Engineering, 15 (1-4), December 1992

[Nier93]

O. Nierstrasz, Composing Active Objects, in: G. Agha, P. Wegner, A. Yonezawa, Research Directions in Concurrent Object-Oriented Programming, MIT Press, 1993

[Odel94]

J.J. Odell, Specifying requirements using rules, Journal of Object-Oriented Programming (JOOP), 6 (2), 1994

[Peck88]

J. Peckham, F. Maryanski, Semantic Data Models, ACM Computing Surveys, 20 (3), September 1988

[Petr94]

I. Petrounias, P. Loucopoulos, A Rule-Based Approach for the Design and Implementation of Information Systems, 4th Int. Conf. on Extending Database Technology (EDBT’94), M. Jarke, J. Bubenko, K. Jeffery (eds.), Springer LNCS 779, UK, March 1994

[Pree95]

W. Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995

[Rumb91]

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, 1991

[Rubi94]

K.S. Rubin, P. McClaughry, D. Pellegrini, Modeling rules using Object Behavior Analysis and Design, Object Magazin, June 1994

[Schr95]

M. Schrefl, G. Kappel, Modelling Object Behavior: To use methods or rules or both? Workshop “Semantics in Databases”, Prague, 1995

[Serv94]

Servio Corporation, Gemstone User Manuals Version 4.0, July 1994 - 16 -

[Shet93]

A. Sheth, M. Rusinkiewicz, On Transactional Workflows, IEEE Bulletin of the Technical Committee on Data Engineering, 16 (2), June 1993

[Toko87]

M. Tokoro, A. Yonezawa (eds.), Object-Oriented Concurrent Programming, MIT Press, 1987

[Urba92]

S.D. Urban, A.P. Karadimce, R.B. Nannapaneni, The Implementation and Evaluationof Integrity Maintenance Rules in an Object-Oriented Database, Proc. of the 8th Int. Conf. on Data Engineering (DE’92), 1992

[Wido94]

J. Widom, S. Chakravarthy (eds.), Proceedings RIDE’94, Fourth Int. Workshop on Research Issues in Data Engineering, Houston, 1994

- 17 -

Appendix A: Synchronization Pattern Catalogue We will now describe the remaining synchronization rule patterns for the synchronization modes introduced in Section 4.1 in detail. (1) The Blocking with Timeout Rule Pattern Problem: In contrast to Blocking, if the receiver is not in the correct abstract state, the sender waits for the correct state no longer than a specified time period (timeout-interval). In case that the receiver does not enter the appropriate state within this period, an exception is raised. The designer has to specify the exception method, i.e., the actions to be taken when the timeout is signalled. He/she may specify, for example, to do nothing, to try an alternative interaction, or to return a certain value to the sender. The semantics of Blocking with Timeout is shown in the interaction diagram in Figure 11. Fig. 11a shows the case where the receiver enters the appropriate state before timeout is reached, Fig 11b depicts a timeout scenario. a) sender

receiver

sender

b)

receiver

synchronization point timeout

Legend:

exception raised

... active threads of control

timeout

... blocking with timeout interaction

... inactive thread of control

... blocking interaction

Figure 11. Blocking with Timeout Interaction

Solution: Similar to Blocking, the condition part of a Blocking with Timeout rule pattern checks the abstract state of the receiver. The Aesel is different in that it blocks the triggering thread of control until either the receiver object enters the appropriate state or timeout is reached. For this purpose, the first part of the Aesel is a relative time event selector specifying an interval starting at the condition triggering point in time (Cesel.time) and ending some timeout value later (Cesel.time+) within which the event Tran2Accept may not occur (NOT Tran2Accept). The second part of the Aesel (Tran2Accept) monitors the case that the correct state is reached. Within the action, first it is checked whether timeout or the correct state has been reached. This is done by checking which part of the disjunctive composite Aesel (cf. keyword Aesel) actually triggered the action. If timeout has been reached without the receiver being in the correct state (i.e., the first part of the Aesel is fulfilled), the receiver method is not executed (INSTEAD) and an exception is raised. If the receiver reaches the desired state first (i.e., the second part of the Aesel - Tran2Accept - is fulfilled), the requested method is executed synchronously. Analogous to the Asynchronous rule pattern, the rule is deactivated and reactivated within the action to prevent recursive triggering of the rule. DEFINE RULE r_toBlk_ AS ON InteractionSel DO IF InvalidState THEN WAIT UNTIL ON REL(Cesel.time, , NOT Tran2Accept) OR Tran2Accept EXECUTE INSTEAD IF Aesel.left.time NIL THEN /* i.e. timeout already triggered */

- 18 -

ELSE r_toBlk_ deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver r_toBlk_ activateFor: (Cesel.sender, Cesel.receiver) ENDIF.

(2) The Balking Rule Pattern Problem: In contrast to Blocking and Blocking with Timeout, if the receiver is not in the correct abstract state, the sender does not wait but rather raises an exception. Again, the designer has to specify the exception method. The interaction diagram in Figure 12a shows a scenario, where the receiver is in the appropriate state when the request is sent, Figure 12b shows the case where the receiver is not ready and thus balks the request. a)

sender

receiver

b)

sender

receiver

exception raised

Legend:

... active threads of control

... balking interaction

... inactive thread of control

... blocking interaction

Figure 12. Balking Interaction

Solution: The condition of Balking checks if the receiver is in the correct abstract state. If not, a corresponding rule does - in contrast to blocking rules - not wait until the correct abstract state is reached. It rather skips execution of the receiver method, raises an exception, and returns control to the triggering thread immediately. In case that the rule check recognizes a correct receiver state, the action part of the rule is not executed, and control is returned to the triggering thread which then executes the receiver method. DEFINE RULE r_balk_ AS ON InteractionSel DO IF InvalidState THEN EXECUTE INSTEAD .

(3) The Synchronous Start Rule Pattern Problem: The Synchronous Start rule pattern is similar to Blocking as the sender has to wait until the receiver is in the correct abstract state. If the correct state is reached, sender and receiver are allowed to continue execution in parallel, i.e., the sender does not have to wait for the receiver’s result (cf. Figure 13). Synchronous Start is used in cases where the sender has to be sure that the receiver is able to process the request, but has no need to get the result back.

- 19 -

sender

receiver Legend:

S

... active threads of control

synchronization point

... inactive thread of control

S

... synchronous starting interaction ... synchronous interaction

Figure 13. Synchronous Start

Solution: Similar to Blocking, the Synchronous Start rule pattern specifies to block the triggering thread of control until the receiver is in the correct abstract state. This is signalled by the first part (Tran2Accept) of the composite Aesel. As soon as the receiver reaches the specified state, the action part of the rule pattern specifies to start the receiver‘s method within an asynchronous thread of control. The second part of the Aesel (Tran2Accept;InteractionSel) ensures that the action is triggered immediately if the receiver is already in the appropriate state when sending the request. DEFINE RULE r_syncStart_ AS ON InteractionSel DO IF TRUE THEN WAIT UNTIL ON Tran2Accept OR (Tran2Accept;InteractionSel) EXECUTE INSTEAD ASYNC r_syncStart_ deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver r_syncStart_ activateFor: (Cesel.sender, Cesel.receiver).

(4) The Synchronous Start with Timeout Rule Pattern Problem: Similar to Synchronous Start, Synchronous Start with Timeout specifies to wait for the correct abstract state of the receiver, but only as long as a specified timeout-interval. If the correct state is reached, sender and receiver are allowed to continue execution in parallel, i.e., the sender does not have to wait on the request’s result. a)

sender

S

receiver

wait for begin

exception raised

... active threads of control

S

receiver

S

synchronization point

timeout

Legend:

sender

b)

timeout

... sync. starting interaction with timeout ... blocking interaction

... inactive thread of control

Figure 14. Synchronous Start with Timeout Interaction

The semantics of Synchronous Start with Timeout is shown in the interaction diagram in Figure 14. Fig. 14a shows the case, where the receiver enters the appropriate state before timeout is reached, Fig. 14b depicts a timeout scenario.

- 20 -

Solution: In contrast to Synchronous Start, rules corresponding to this rule pattern only wait for a specified time period for the receiver‘s correct state. The rule pattern looks exactly the same as the pattern for Blocking with Timeout, except that, if the receiver reaches the desired state first (i.e., the second part of the Aesel - Tran2Accept OR Tran2Accept;InteractionSel - is fullfilled) the requested method is executed within an asynchronous thread of control. Furthermore, in this case the rule is deactivated before method execution and reactivated afterwards. DEFINE RULE r_toSyncStart_ AS ON InteractionSel DO IF TRUE THEN WAIT UNTIL ON REL(Cesel.time, , NOT Tran2Accept) OR Tran2Accept OR (Tran2Accept;InteractionSel) EXECUTE INSTEAD IF Aesel.left.time NIL THEN /* i.e. timeout already triggered */ ELSE ASYNC r_toSyncStart_ deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver r_toSyncStart_ activateFor: (Cesel.sender, Cesel.receiver) ENDIF.

(5) The Balking Asynchronous Rule Pattern Problem: As with the Balking rule pattern, if the receiver is not in the correct abstract state, the sender does not wait, but rather raises an exception. If the receiver is ready, however, this time the requested method is executed asynchronously (cf. Figures 15a and 15b). a)

sender

receiver

b)

sender

receiver

exception raised

Legend:

... active threads of control

... balking asynchronous interaction

... inactive thread of control

... blocking interaction

Figure 15. Balking Asynchronous Interaction

Solution: The Balking Asynchronous rule pattern consists of two rule templates. The first rule template corresponds to pure Balking. It monitors the case that the receiver is not in the correct abstract state and if triggered raises an exception instead of executing the triggering method (for the rule pattern we refer to Subsection (2) above). The second rule template monitors the complementary case, i.e. a correct receiver state, and starts the requested method asynchronously after deactivating the rule. After execution has been finished, the rule is reactivated. DEFINE RULE r_balkAsync_ AS ON InteractionSel DO IF NOT InvalidState THEN EXECUTE INSTEAD ASYNC r_balkAsync_ deactivateFor: (Cesel.sender, Cesel.receiver) Cesel.receiver r_balkAsync_ activateFor: (Cesel.sender, Cesel.receiver).

- 21 -

Appendix B: Description of the Running Example Within this section we give a full description of the running example used for the application of rule patterns throughout Section 4.3. As stated above, the example is situated in the area of workflow systems, realizing a computerized motel reservation management system. In the following, this system is described by means of an object model, an interaction model and a dynamic model. (1) Object Model The object model shown in Figure 16 illustrates the classes, attributes, methods and associations [Rumb91] representing our computerized motel reservation management system. This system allows to manage reservations (cf. class Reservation in Figure 16) for a nationwide consortium of motels (Consortium) connected via a wide area network, e.g. internet. Reservation transactions can be submitted to the consortium from any node within the network concurrently by using a web-browser-like interface (UI). The consortium is responsible for delegating requests to the appropriate motels (Motel) and transfering results back to the user interface. Each motel manages rooms (Room) grouped into different categories (Category). A customer (Customer) is able to make new reservations and change or delete existing ones. UI

Consortium

Motel

newRes(resData) cancelRes(resData) changeRes(resData) display(resObj,state)

name openRequests

name address

selectMotels(criteria) newRes(resObj) notify(state,tID,motel,room)

tryRes(tID,resObj) notify(state,tID,room) reserve(resObj)

Category Customer

Reservation

name adress

arrivalDate departureDate

Room

price equipement

checkAvail(tID,interval)

getRooms addRoom(room) removeRoom(room)

$new(resObj)

Legend:



.... cardinality 0 or more



.... association

Figure 16. Object Model

(2) Interaction Model The interaction model shown in Figure 17 illustrates interactions between objects of the above classes necessary to make a new room reservation. The notation is partly based on the notation for event-trace diagrams of OMT [Rumb91], and partly on the interaction diagram notation of OSA [Embl92]. To start a new reservation transaction, the customer has to select the transaction type "newRes" from the main menu in order to get a reservation request form. The customer then has to fill out the form, providing his/her identification and the demanded reservation data (several criteria for the desired motel, room category, arrival date and departure date). External objects such as Customer always communicate in an asychronous manner with the system by sending signals from input devices ,like a keyboard, and receiving signals via some output device, e.g. a screen. In this case, the Customer sends the signal OkButton(resData) denoting a reservation request. The UI-object creates a reservation object resObj for each reservation transaction, and initializes it with the reservation data and - 22 -

a newly generated id tID. Afterwards, it propagates the message newRes future synchronously to the Consortium object, thus creating another thread of control within the Consortium object. We assume firstly, that the system does not allow the user to request several reservation transactions from one UIobject concurrently, and secondly, that the Consortium - which only delegates reservation requests to motels and sends answers from the motels back to the UIs - is able to handle requests from different UIs concurrently. Consequently, the interaction between UI and Consortium can neither be done simply asynchronous, nor synchronous. In case of asynchronous interaction, the user would be able to send further requests to the UI before having received the result of the actual request. In case of synchronous interaction, the UI would expect the result as soon as the Consortium returns control, and thus, the Consortium would have to be blocked until the result of the request is available. Customer

UI

Consortium

Motel

Category

Room Reservation

"new" (resForm) OkButton (resData)

newRes (resObj) F

selectMotels (motelCategory) (motelList)

TO motels IN motelList

tryRes (resObj)

getRooms (roomList)

TO rooms IN roomList notify (tID,motel,room,state) (resObj’, state)

checkAvail (tID,interval)

notify (tID,room,state)

(resObj’, state) reserve(resObj’)

Legend:

.... asynchronous interaction

F

new (resObj’)

.... one2one object interaction .... one2many object interaction

.... future synchronous interaction .... many2one object interaction .... blocking interaction .... active thread of control .... object2class interaction

.... inactive thread of control

Figure 17. Interaction Model for a "New Reservation" Transaction

In order to receive a list of appropriate motels, the Consortium object performs a synchronous interaction sending selectMotels to itself. After storing the tID of the actual reservation transaction, the Consortium object asynchronously propagates the message tryRes to all these Motels, quits its current thread of control and gets ready for further requests (cf. abstract state Idle in Figure 20). After - 23 -

a Motel has checked whether a Room is available or not, it notifies the Consortium (notify) about its result. The parameter tID is used by the Consortium to associate the answer from the Motel with one of the open requests. As soon as the Consortium has received a positive answer from any Motel or a negative one from every Motel, it provides the result (resObj, state) to the UI-object, waiting for it due to its future synchronous mode. In case of a positive answer, the Consortium additionally tells the Motel to fix the reserveration (asynchronous reserve message) which in turn asynchronously requests the creation of a new Reserveration object. A Motel object handles tryRes requests in a way similar to a Consortium object handling newRes requests. After synchronously retrieving a list of Rooms for the given Category from the corresponding Category object, it asynchronously requests from each of these rooms to check its availability for a certain interval. The Motel object quits its thread of control afterwards, and handles notify requests analogous to the Consortium. (3) Dynamic Model The dynamic model specifies allowed state transitions for each object class, in this way constraining interactions between objects. It consists of several state-transition diagrams. Figures 18 to 22 show only those state transition diagrams used for deriving the appropriate synchronization rules. The notation is based on [Rumb91].

displayMenu "new" NewRes

"change" ChangeRes

"cancel"

"exit"

Legend:

State activity

.... state .... initial state

CancelRes

.... final state event

.... transition

Figure 18. State Transition Diagram for UI

Figure 18 shows a state transition diagram for the user interface (UI). Depending on the selected type of transaction (cf. events "new", "change", and "cancel" in the figure), the UI enters one of the states NewRes, ChangeRes, and CancelRes, respectively. Figure 19 shows a subdiagram for the state NewRes, specifying a sequence of substates ranging from EnteringResData to Processing to Displaying. NewRes OkButton (resData) EnteringResData

Processing create resObj newRes (resObj)

Displaying display (resObj,state)

Figure 19. State Transition Subdiagram for NewRes

The state transition diagrams for Consortium and Motel resemble each other in that both of them represent continuous loops. Moreover, both have a state Idle as the only state in which they are allowed to react to events, i.e. incoming messages. While in this state, the object has no active thread of control, i.e. the corresponding process is either put to sleep or killed on entering the state. - 24 -

UI

notify (...) [ tID not in openRequests ]

F

LookingForMotels

notify (...) [ state == available & tID in openRequests ]

newRes (resObj)

selectMotels (...) add (tID, motelList) to open requests

reserve (resObj) timeout (tID) [tId in openRequests]

Motel

(resObj, state)

Removing2 remove tID from open requests

State activity

[more open requests]

remove tID from open requests

(resObj, state)

notify (...) [ state == not available & tID in openRequests ]

UI

Motel

[no more open requests] CheckingOpenRequests checkOpenMotelRequests (tID)

.... state .... initial state

event

F

Motel

F

Legend:

Removing1

Idle

tryRes (...)

UI

Motel

Sender

Receiver

.... Sender class signalling input event event

.... Receiver class receiving output event

.... transition

Figure 20. State Transition Diagram for Consortium

When one of the events newRes, notify, or timeout occurs, the state Idle is left. In the case of notify, guards specify which transition to take place: For example, concerning the state transition diagram for class Consortium, if a notify message for an open request (cf. guard [tID in openRequests]) is received, and the state indicates that the motel has a room available, the consortium enters the state Removing1, where the tID is removed from the list of open requests. Thus, each further notification concerning the same request (cf. notify with guard [tID not in openRequests]) leads to a dummy transition from state idle to idle, since nothing but the acceptance of this message has to be done. When the state Removing1 is left, the Consortium signals an output event, i.e. sends message reserve, to the corresponding motel and provides the result for the message newRes sent future synchronously from the UI (cf. also Figure 20).

- 25 -

Reservation reserve (resObj)

Consortium

LookingForRooms getRooms (...) add (tID, roomList) to open requests

notify (tID, room, state) [ state == available & tID in openRequests ]

tryRes (resObj)

notify (...) Consortium Remove2 remove tID from open requests

Remove1

Idle notify (...) notify (...) [ tID not in openRequests ]

checkAvail (...) Room

Room

new (resObj)

timeout (tID) [tId in openRequests] [more open requests]

notify (tID, room, state) [ state == not available & tID in openRequests ]

remove tID from open requests

Consortium

Room

[no more CheckingOpenRequests open requests] checkOpenRoomRequests (tID) Figure 21. State Transition Diagram for Motel

Figure 22 shows the state transition diagram for class Category. According to it, an object of class remains in state Idle until receiving one of the requests getRooms, addRoom, and removeRoom. Upon these requests, the object changes its state to Selecting, Adding, or Removing, respectively, performs the desired task, and returns to state Idle. Category

Adding add room to this category

removeRoom (room)

addRoom (room)

Idle

remove room from this category getRooms

Selecting get list of rooms for this category Figure 22. State Transition Diagram for Category

- 26 -

Removing

Appendix C: Putting Rule Patterns to Work In the following we give a list of all remaining synchronization rules used for realizing the interaction specified within the interaction model of the example described in Appendix B. Note that the recursive interaction selectMotels within the class Consortium needs not to be realized by a rule (cf. Section 2.1). Some rules use event selectors already defined in Section 4.3 and are therefore not repeatedly defined. (1) Asynchronous Interaction: notify from Motel to Consortium DEFINE RULE r_async_Motel_notify_Cons AS ON PRE(Motel, notify:availability for:tID from:room, Consortium, notify:status for:tID from:motel with:room) DO IF TRUE THEN ON e_Cons_notify OR e_Cons_newRes OR ((e_Cons_new OR e_Cons_notify OR e_Cons_newRes) ; PRE(Motel, notify:availability for:tID from:room, self,notify:status for:tID from:motel with:room)) [left.left.retVal=right.receiver] EXECUTE INSTEAD ASYNC Cesel.receiver notify:status for:tID from:motel with:room.

(2) Asynchronous Interaction: reserve from Consortium to Motel DEFINE RULE r_async_Cons_reserve_Motel AS ON PRE(Consortium, notify:status for:tID from:motel with:room, Motel, reserve:resObj) DO IF TRUE THEN ON e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes OR ((e_Motel_new OR e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes) ; PRE(Consortium, notify:status for:tID from:motel with:room, self, reserve:resObj)) [left.left.retVal=right.receiver] EXECUTE INSTEAD ASYNC Cesel.receiver reserve: resObj.

(3) Asynchronous Interaction: checkAvail from Motel to Room DEFINE RULE r_async_Motel_checkAvail_Room AS ON PRE(Motel,tryRes:resObj, Room,checkAvail:interval for:tID) DO EXECUTE INSTEAD ASYNC Cesel.receiver checkAvail:interval for:tID.

(4) Asynchronous Interaction: notify from Room to Motel DEFINE RULE r_async_Room_notify_Motel AS ON PRE(Room,checkAvail:interval for:tID,Motel,notify:availability for:tID from:room) DO IF TRUE THEN ON e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes OR ((e_Motel_new OR e_Motel_notify OR e_Motel_reserve OR e_Motel_tryRes) ; PRE(Room,checkAvail:interval for:tID, self,notify:availability for:tID from:room)) [left.left.retVal=right.receiver] EXECUTE INSTEAD ASYNC Cesel.receiver notify:availability for:tID from:room.

(5) Asynchronous Interaction: new from Motel to Reservation DEFINE RULE r_async_Motel_new_Reservation AS ON PRE(Motel,reserve:resObj, Reservation,CLASSMETHOD new:resObj) DO IF TRUE THEN EXECUTE INSTEAD ASYNC Reservation new:resObj.

- 27 -