An Execution and Transaction Model for Active, Rule

An Execution and Transaction Model for Active, RuleBased Component Integration Middleware1 Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich Arizona State University, Department of Computer Science, Tempe, AZ 85287-5406 USA {yingjin, s.urban, dietrich} @asu.edu

Abstract. The Integration Rules (IRules) project is investigating the use of active rules for supporting event-driven activity in applications involving distributed component integration. Integration rules respond to events that are raised during the execution of distributed transactions to evaluate conditions and trigger actions over distributed components that are implemented using the Enterprise Java Beans (EJB) component model. This paper presents the distributed architecture for the IRules environment and defines the execution and transaction model for the use of integration rules. The execution model includes traditional active rule coupling modes for immediate, deferred, and decoupled rule execution and also defines an asynchronous mode for concurrent rule and transaction execution. The flexible transaction model is used to allow integration rules, application transactions, and methods on EJB components to be executed as subtransactions within global distributed transactions. An execution scenario for the integration of EJB components is presented to illustrate the nested execution of rules and transactions for distributed component integration.

1

Introduction

Enterprise applications require access to data and software that are located in remote locations. Component infrastructures such as the Enterprise Java Beans (EJB) component model [1] and middleware solutions such as the Common Object Request Broker Architecture (CORBA) [2] are often used to publish the functionality of services, providing well-defined interfaces that allow access to relevant operations [3]. Although these component and middleware solutions provide a means for accessing distributed services, the development of enterprise applications can be a difficult process since most environments for distributed application development are lacking a rich semantic framework necessary to fully support the integration of distributed sources. In addition, most middleware tools only provide a flat transaction model for the execution of distributed transactions and procedural mechanisms for responding to events. As a result, event-based applications and transactions that require the execution of distributed components often required low-level knowledge of middleware programming and transaction control. 1This

research was supported by NSF Grant No. IIS-9978217

2

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

The Integration Rules (IRules) Project at Arizona State University (http://www.eas.asu.edu/~irules) is developing an intelligent middleware layer for a declarative rule-based approach to the integration of distributed components [4, 5, 6]. In the IRules environment, all components are assumed to be implemented as blackbox EJB components, where the source code cannot be modified and each component is unaware of its participation in the integration framework. Based on the concept of an active database rule [7], an integration rule consists of an event, a condition, and an action. An event describes an occurrence in the distributed environment that will cause an integration rule to be triggered. The condition of an integration rule is a query over distributed components, declaring the set of circumstances that must exist for the action of the rule to be processed. An action can then invoke a method on an EJB component or a distributed application transaction that defines logic for the execution of methods over several components. Through the support of the distributed rule execution engine that is provided by the IRules environment, the application environment can automatically respond to events from remote components by testing conditions over distributed components and invoking global transactions that execute over distributed sources. This paper presents the architecture of the IRules environment together with the execution and transaction model issues associated with the development of a middleware layer for the execution of integration rules. We first provide an overview of the IRules Definition Language [4, 6] for defining relationships between black-box EJB components, extending existing components with events, and defining integration rules and distributed transactions. We then elaborate on the middleware environment for the execution of integration rules and transactions. Integration rules adopt the same execution model features of centralized active rule systems, including the use of coupling modes between events, conditions, and actions. Integration rules expand on the use of decoupled rule execution mode and define a new asynchronous execution mode to better support the concurrent execution of integration rules. Due to constraints imposed by EJB container-managed transactions, we have leveraged the versatility of the Jini Connection Technology [8] to develop an execution environment that supports the nested execution of rules through the use of the flexible transaction model [9], where subtransactions on components are allowed to commit prior to the commit of the parent transaction. We illustrate the use of the transaction model in the nested execution of rules over the distributed components of an investment application. This event-based application scenario demonstrates the strength of the IRules approach, where the application logic is specified at a highlevel using the IRules Definition Language, with the rule-based middleware shielding the application developer from low-level execution issues. The rest of this paper is organized as follows. Section 2 surveys other work that is related to this research, while Section 3 provides a conceptual overview of the IRules approach to application integration [4, 6]. Section 4 elaborates on the rule-based middleware framework of the IRules environment, describing the IRules architecture and presenting the execution and transaction model of integration rules. Section 5 illustrates the execution of integration rules. Section 6 concludes the paper with a summary and a discussion of future work.

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 3

2

Related Work

The IRules project is based on the concept of event-condition-action (ECA) rules from active database systems [7, 10]. Active database systems extend traditional databases by supporting mechanisms to automatically monitor and react to events that are taking place either inside or outside of the database system itself using active rules. In an active database system, the rule execution model determines how a set of rules behaves at runtime. The most relevant execution model feature for this research is coupling modes. Coupling modes provide a way for rule definers to express transactional relationships between different parts of an active rule. The use of active rules has also been investigated in distributed environments. In [11], wrappers are added on top of distributed applications to add active capability. Wrapped applications can communicate in a CORBA environment by method invocations and service requests. Another CORBA-based system, C2offein [12], supports the decoupled coupling mode, with a comprehensive design of distributed event detection. The FRAMBOISE (FRAMework using oBject OrIented technology for Supplying active mEchanisms) project [13] is an object-oriented distributed framework formed by a toolbox to provide specific active database functionality such as event definition, event detection, and rule execution. In [14], the event, condition, and action services are combined using the notification service based on the publish/subscribe mechanism of X2TS [15]. The publish/subscribe mechanism of X2TS is based on the CORBA Notification Service. The IRules project extends our own past work with an active, deductive, objectoriented database language [16] to develop an active rule language for use in an object-based distributed environment. We have already investigated the IRules component framework needed to support IRules [6] and have developed an initial prototype of the IRules functionality [5]. Whereas the above distributed rule systems are based on CORBA, the IRules project is based on the EJB component model, using Jini for distributed computing [17] and providing support for nested rule processing. IRules also provides a more abstract framework than the OMG Activity Service [18] and the J2EE Activity Service [19] for event processing. Whereas the event services in [18, 19] provide a general-purpose event signaling mechanism to support a large variety of transaction models, IRules combines event and rule processing to provide a system that automatically handles transactional behavior for the distributed processing of nested rules and application transactions.

3

Overview of the IRules Approach to Application Integration

The IRules Definition Language (IRDL) provides the semantic base for component integration. The IRDL consists of four sub-languages: the Component Definition Language (CDL) for defining IRules components, the IRules Scripting Language (ISL) for describing application transactions, the Event Definition Language (EDL) for defining events, and the Integration Rule Language (IRL) for defining active rules.

4

3.1

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

CDL

IRules uses CDL to add a semantic layer on top of EJB components, including entity beans that provide persistence and session beans that provide application logic. This layer is the IRules wrapper layer, adding functionality for externalized relationships between components, event definitions, extents, and derived and stored attributes. To illustrate the use of CDL, consider an investment application with components distributed in four containers [5] as shown in Figure 1. The Portfolio container includes entity beans with data about current and past stock holdings for different accounts. The User container stores information about users and their accounts. The Stock container contains information about stocks and their current prices as entity beans. The PendingOrder container uses entity beans to store pending orders that are awaiting execution when certain market conditions are met. There is also a session bean associated with the Portfolio that implements the business logic of buying and selling stocks. Wrappers are represented in Figure 1 with names that have a prefix of IRules.

Fig. 1. The Investment Enterprise

Figure 2 shows the CDL definition of the PendingOrder component. CDL is based on the syntax of the Object Definition Language (ODL) of the Object Data Management Group (ODMG) [20]. CDL does not repeat methods and attributes of the blackbox component. Instead, a CDL definition enhances an existing component with IRules functionality. For example, the externalized relationship between PendingOrder component and Portfolio is defined as a bi-directional relationship: a PendingOrder is orderedBy a Portfolio, while a Portfolio orders a PendingOrder. The event afterNewPO is

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 5

also defined as an event to be raised after the create operation on PendingOrder. A complete CDL definition of the investment enterprise can be found in [6]. Component PendingOrder implements EntityBean (extent pendingOrders) { relationship Stock actUpon inverse Stock::pendingTrades; relationship Portfolio orderedBy inverse Portfolio::orders; event afterNewPO(pnId, portId, stockId, numOfShares, desiredPrice, action, actUpon, orderedBy) {method after create(pnId, portId, stockId, numOfShares, desiredPrice, action, actUpon, orderedBy);} }

Fig. 2. CDL of PendingOrder Component

3.2

ISL

To express application transactions, IRules uses the JACL Scripting Language [21]. JACL is a Java implementation of the Tool Command Language (TCL) [22]. Figure 3 illustrates two examples of IRules application transactions in ISL. The clientWantsToSellStock transaction is a request from a user to perform the function of placing an order to sell a stock. The transaction creates an order to sell a stock at a desired price, and then prints a report. The newInstance command is a JACL extension command. This extension is used to create a new instance of an EJB in a concise way. When the order is created, the event defined in Figure 4 is raised, triggering the integration rule newStockSellPendingOrder in Figure 5. The second application transaction in Figure 3, sellStockOnNewPO, describes the sequence of operations for selling stock using the session bean named PortfolioSessionBean. Application Transaction clientWantsToSellStock(String pnId, String portfolioId, String stockId, int numOfShares, float desiredPrice, String action, String actUpon, String orderedBy) { set pn [newInstance PendingOrder $pnId $portfolioId $stockId $numOfShares $desiredPrice $action $actUpon $orderedBy] printPendingOrderInfo $pn } Application Transaction sellStockOnNewPO(String stockId, float price, String portfolioId, int numOfShares, PendingOrder pn) { set session [newInstance PortfolioSessionBean] $session sellStock $stockId $price $portfolioId $numOfShares $pn setStatus "executed" printSellInfo $pn}

Fig. 3. ISL Example Application Transaction

3.3

EDL

There are several different types of IRules events. A method event is generated before or after the execution of a method on a component. An application transaction event is generated before or after the execution of an application transaction. An internal

6

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

event is an event generated by a black-box component. An external event is generated by sources external to the IRules environment. Method and internal events are specified using CDL as illustrated in Figure 2. Application transaction events and external events are expressed using EDL. Figure 4 shows an application transaction event definition in EDL. The key word “appTrans” identifies that the event is an application transaction event. event afterSellStockOnNewPO(stockId, price, portfolioId, numOfShares, pn) {appTrans after sellStockOnNewPO(stockId, price, portfolioId, numOfShares, pn)}

Fig. 4. Application Transaction Event

3.4

IRL

IRL is used to define integration rules. IRL is based on the traditional ECA rule format in active database systems. An integration rule includes an event, a condition, and an action. A condition includes a when clause for the Boolean condition to be checked and an optional define clause to declare explicit bindings to be passed to the action. The action can either be a method call to a component or an application transaction. The condition is optional in IRL, supporting the notion of event-action (EA) rules. Examples of IRL are shown in Figure 5. In the first rule, the event is signaled after creating a new instance of a pendingOrder component. The condition part will first check whether the pendingOrder intends to sell stock or not. If so, the condition defines a binding for the stock and the pendingOrder if a certain threshold is met. The action part iterates through the bindings and executes the sellStockOnNewPO application transaction to perform the functionality of selling stocks. The action part of the rule is the sellStockOnNewPO application transaction described in Figure 3, which raises two events. The first event is generated after the stock is sold but before the end of the transaction, allowing rules to be triggered in reaction to each sell operation. In particular, the scenario has an active rule stockBuyOnUpdateCash that allows a portfolio to exercise pending purchases when sufficient funds are available in the user’s account. An event is signaled after the action of sellStockOnNewPO is complete to trigger a rule billingToAccountOnSell. This rule sends billing information to the user. Both of these rules are shown in Figure 5.

4

Middleware for Integration Rules and Transactions

To support the IRules language framework, a distributed architecture and run-time environment was built for distributed rule and transaction processing. In this section, we first illustrate the Jini-based architecture of the IRules middleware. Then we present a global view of the IRules execution model with a detailed discussion of the IRules coupling modes. Finally, we present the IRules transaction model and transaction entities to illustrate transaction management for the execution environment.

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 7

create rule event condition

action

create rule event condition

action

create rule event action

newStockSellPendingOrder afterNewPO(pnId, portfolioId, stockId, numOfShares, desiredPrice, action, actUpon, orderedBy) immediate when action = "sell" define stockAndPendingOrder as select struct ( stk: s, newPo: pn ) from s in stocks, pn in pendingOrders where pn.id=pnId and pn.actUpon=s and desiredPrice p.buyThreshold decoupled from p in portfolioOnUpdate do buyStockOnUpdateCash(p) billingToAccountOnSell afterSellStockOnNewPO(stockId, price, portfolioId, numOfShares, pn) deferred from p in portfolios where p.portfolioId= portfolioId do setAccountBillingOnSell(stockId, price, portfolioId, numOfShares, p.accounted

Fig. 5. IRL Example

4.1

IRules Architecture

As an active system, the IRules architecture provides the functionality of event signaling, rule processing, and transaction management. The IRules project uses Jini Connection Technology as the primary distributed computing framework for implementing the architectural components, together with the Java Messaging Service (JMS) [23] to provide the messaging capabilities of the environment. The use of JMS within the IRules project is detailed in [24]. Figure 6 presents the Jini-based architecture of the IRules environment. The metadata manager, the rule manager, and the object manager are all designed as Jini services. The IRDL is compiled to produce EJB wrappers and metadata that describes components, rules, events and application transactions. Wrappers around existing EJB components provides IRules functionality for supporting externalized relationships between distributed components, extents, derived attributes, and stored attributes [6]. IRules wrappers also enhance existing components with events that can be generated before and/or after method calls on components. Other architectural components in-

8

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

terface with the metadata manager at run-time to retrieve information about components, events, transactions, and rules as defined by IRDL.

Fig. 6. IRules Architecture

The event handler receives and propagates events to the rule manager. Upon receiving an event, the rule manager queries the metadata to get rules triggered by the event. During the processing of the triggered rules, the rule manager interfaces with the object manager to create components, retrieve components, and invoke methods on components. The object manager abstracts the knowledge of remote method invocation on components from the IRules environment. During rule and transaction execution, the rule manager interfaces with the transaction manager to request transactional context for the execution of rules and application transactions. The transaction manager manages the IRules transactional environment by creating and controlling instances of the transaction entities that are presented in Section 4.3. The blocking-call mechanism of JavaSpaces [8] is used as a synchronization tool within the IRules architecture to suspend transactions in support of nested rule and transaction execution. 4.2

Coupling Modes of the Execution Model

Coupling modes in IRules can be expressed between the event and the condition (E-C coupling mode), or between the condition and the action (C-A coupling mode). Coupling modes can also be expressed between the event and the action (E-A coupling

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 9

mode) in EA rules. Integration rules supports four types of coupling modes: immediate synchronous, immediate asynchronous, deferred, and decoupled. Using the E-C coupling mode as an example, the immediate synchronous E-C coupling mode indicates that the condition of a rule must be evaluated immediately after the event is raised. The immediate coupling mode results in rule nesting since the triggering transaction suspends while the triggered rule executes as a subtransaction. The deferred E-C coupling mode postpones rule condition evaluation to the end of the top-level transaction of execution (i.e., the outermost transaction within which the event was raised). The decoupled mode causes the rule manager to start a new toplevel transaction for execution of the triggered rule, while allowing the transaction that triggered the rule to resume execution. The immediate synchronous, deferred, and decoupled modes have been investigated by traditional active databases. We have fully developed the use of the decoupled mode since it is useful for rule execution in a distributed environment. The immediate asynchronous mode is a new coupling mode that has been defined as part of this research. An immediate asynchronous rule is evaluated immediately after the occurrence of an event, but the triggering transaction that raised the event will not be suspended. The execution of the integration rule and the triggering transaction are therefore concurrent, thus achieving better performance over the synchronous mode for distributed execution. This mode can only be used when the rest of the operations of the current transaction do not depend on the results of the immediate rule. An integration rule can be triggered before or after an event happens. This feature is specified as before and after modifiers in the definition of an event. A deferred mode can only be used with a rule having an after modifier, since a deferred rule can only be executed after the event happens. An immediate mode can be used in a rule with either a before or after modifier. Rule execution before an event is reasonable only when an event generator can trap the occurrence of the operation associated with the event. Not all combinations of coupling modes are valid with the use of before and after modifiers. For example, the combination of an immediate synchronous E-C coupling mode with a deferred C-A coupling mode is not allowed for rules with an after modifier. If a C-A coupling mode is deferred, during the time interval after evaluating the condition and before performing the action, there may be a possible update of data that can cause the condition evaluation to no longer be true [25]. All four coupling modes are supported by EA rules with an after modifier. Rules with a before modifier, however, have a more restricted use of coupling modes, where the only coupling mode allowed is the immediate synchronous mode. 4.3

IRules Transaction Management

This section presents the distributed transaction management of the IRules system for integration rule execution. Section 4.3.1 will first discuss the selection of the flexible transaction model to overcome the limitations of the underlying EJB component model. Section 4.3.2 will then address the design of IRules transaction entities that support run-time behavior of rule and transaction processing.

10

4.3.1

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

Transaction Model

One issue for transaction processing in IRules is the design of a transaction model that is appropriate for the nested execution of rules over EJB components. In the nested transaction model [26], a subtransaction cannot release its results until its parent transaction commits. In contrast, the flexible transaction model [9] has a compensating mechanism that allows unilateral commit of subtransactions. Although the flexible transaction model avoids unnecessary waiting time by subtransactions, the flexible transaction model can be more time-consuming than the nested transaction model when compensating work is required in the case of transaction failure. The underlying component model constrains the selection of a suitable transaction model for IRules. In traditional databases, the transaction manager of the database controls when to release locks and when to update permanent storage. It is impossible to control black-box EJB components in such a manner due to the functionality of EJB containers. Each entity bean has an underlying relation in a relational database within a container, and each instance of the bean corresponds to a tuple in that relation. Entity beans can only be accessed with container-managed transactions, where the EJB container totally controls the transaction for method invocations of any entity bean. If the IRules transaction manager attempts to use a two-phase commit (2PC) protocol, the permanent storage can only be updated when all subtransactions are ready to commit. But with no notion of the parent-child hierarchy of outside transaction semantics for 2PC, the container is independently determining when to retrieve and update the database. Therefore 2PC is not appropriate for the IRules transaction model due to restrictions imposed by the underlying container-managed transactions. In contrast, the flexible transaction model is more suitable for integration rules since it allows unilateral commit of subtransactions. We assume a failure semantics where individual rules can abort without affecting the triggering transaction, which is one of the typically failure semantics in an active system [7]. The study of compensating actions for addressing system failure is a topic for future research. 4.3.2

Transaction Entities

IRules transaction entities are execution objects that encapsulate the transactional control for rules and application transactions. Figure 7 presents the inheritance hierarchy for transaction entity classes. All transaction classes inherit from the abstract class IRulesTransaction. There are four sub-classes of IRulesTransaction: ISLTransaction, NestedTransaction, TopLevelTransactionForEvent, and TopLevelTransactionForMethod. These four sub-classes are responsible for capturing the execution-time behavior of transaction processing under different circumstances within the IRules system. The superclass IRulesTransaction encapsulates the generic logic of transaction execution. IRulesTransaction uses two queues for managing relationships to rules triggered during the execution of the transaction. The asynList is the queue of immediate asynchronous rules triggered by the transaction and concurrently executing with the triggering transaction. A transaction cannot commit until triggered asynchronous rules finish executing. When a transaction is ready to commit, the status of the asynList is checked to see whether the transaction triggered asynchronous rules. If asynchronous rules are present, all asynchronous rules triggered by this transaction must commit be-

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 11

fore the next phase of processing for the transaction. After all asynchronous rules commit and if the transaction is not a top-level transaction, the transaction may commit. If the transaction is a top-level transaction, then deferred rules may be pending. The deferredList is the queue of deferred rules to be executed at the end of the top-level transaction. After all deferred rules commit, the top-level transaction may commit. IRulesTransaction deferredList : Queue asynList : Queue commit()

ISLTransaction appTran : ApplicationTransaction

NestedTransaction rule : ActiveRule

TopLevelTransactionForEvent internalOrExternalEvent : Event

TopLevelTransactionForMethod method : Method

Fig. 7. Transaction Hierarchy

The first subclass of IRulesTransaction shown in Figure 7 is ISLTransaction. ISLTransaction implements the transactional behavior of an application transaction. Within the IRules environment, an application transaction has two purposes. An ISLTransaction can be created as a top-level transaction that is started in response to user requests. An ISLTransaction can also be created as a subtransaction to execute the action part of an integration rule when the action is expressed as an application transaction. The second subclass of IRulesTransaction is NestedTransaction. The NestedTransaction class encapsulates the execution of a subtransaction. A NestedTransaction is created as the context of a nested rule. Since the processing of rules is wrapped by transactions, rule nesting behavior can be controlled by the execution of parent and child transactions. For example, suppose rule Rx triggers immediate synchronous rule Ry, and the transaction contexts of Rx and Ry are Tx and Ty, respectively. Since we want to let Rx suspend until Ry finishes (according to the immediate synchronous E-C coupling mode), we can control this behavior by suspending Tx until Ty commits. The third subclass of IRulesTransaction is TopLevelTransactionForEvent. The TopLevelTransactionForEvent is used to offer transactional context to handle responses to internal and external events. Internal and external events are detected outside of existing transaction contexts. As a result, a top-level transaction is started to process the rules triggered by an internal or external event. The fourth subclass is TopLevelTransactionForMethod and it applies to the specific case of a decoupled coupling mode when the action of the rule invokes a method of an EJB component. The decoupled coupling mode requires the action to be executed as a new top-level transaction. As previously explained, when an integration rule invokes an application transaction in the action part of a rule, the transaction manager starts a new ISLTransaction for the action. But when the action is expressed as a method of a component, a TopLevelTransactionForMethod is created to instantiate a transaction context for the decoupled action.

12

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

5

Execution Scenario of An Investment Application

Figure 8 illustrates the execution scenario of the investment example from Figures 2-5 using a notion that is based on UML activity diagrams. There are four transactions represented by four different swimlanes. These columns represent the different transaction contexts of the application transactions and rules. When a user invokes the clientWantsToSellStock application transaction, the transaction manager creates a top-level ISLTransaction (T1) to process the application transaction. The first script operation in clientWantsToSellStock generates an event named afterNewPO (e1) according to the CDL definition of PendingOrder in Figure 2. The event e1 triggers the rule newStockSellPendingOrder (R11) presented in the second column of Figure 8. Because the E-C coupling mode of R11 is immediate synchronous, the condition of R11 is evaluated immediately. T1 suspends until R11 completes. The synchronization bar below newPendingOrder represents the execution of immediate rule R11 within the context of subtransaction T11. As discussed in Section 4.3.2, T11 has the subtype NestedTransaction because it is used as the transaction context for processing a rule. The condition of R11 is evaluated in the second column. If the condition evaluation returns a non-null structure containing stocks and pending orders, then the action of R11 is performed using the structure as input bindings. Because of the immediate synchronous C-A coupling mode, the action is executed immediately. The action part of R11 is wrapped in an ISLTransaction named sellStockOnNewPO (T11a), which has four operations. The second operation sellStock is a method that generates an event afterSellStock (e2). The event e2 triggers rule stockBuyOnUpdateCash (R111) in the third column. Since the E-C coupling mode of R111 is immediate asynchronous, the condition of R111 is evaluated immediately. Moreover, the condition evaluation of R111 is concurrent with the execution of the triggering transaction T11a. If the condition evaluation of R111 returns a non-null set of portfolios, the action of R111 will be performed upon the set. Due to the decoupled C-A coupling mode, the action of R111 becomes a new top-level ISLTransaction named buyStockOnUpdateCash (T2) since the action is an application transaction. Once T2 is started in the fourth column, T111 resumes and commits. As shown in the second column, when the “set status” and “printInfo” operations of T11a finish executing, T11a is at the end of execution. At this time T11a waits until all the triggered asynchronous rules join. In this example, T111 joins T11. As shown in the second column, the completion of sellStockOnNewPO generates an event (e3) that triggers an EA Rule named billingToAccountOnSell (R112). Because the E-A coupling mode of R112 is deferred, R112 is scheduled to be executed at the end of the top-level transaction (T1). Subtransaction T11 finishes execution and commits. In the first column, the commit of T11 releases the suspension of T1. The last operation of T1, printInfo, is executed. Just before T1 commits, deferred rule R112 is processed. After R112 finishes executing, T1 commits.

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 13 T1: (Top-Level) Application Transaction: ClientWantsToSellStock

T11: (Sub of T1) rule R11: newStockSellPendingOrder

T111: (Sub of T11) T2: (Top-Level) rule R111: Application Transaction: stockBuyOnUpdateCash buyStockOnUpdateCash

New PendingOrder e1:aft

erNew PO E-C Im me dia te Synch ronou s

R11:: Evaluate Condition C-A Immediate Synchronous

R111:: Action T11a: sellStockOnNewPO new SessionBean sellStock

set Status

e2: a fterS ellSto ck E-C Imm edia A sy n te ch r o n ous R111:: Evaluate Condition

printInfo Join A

u syn R

les

CA

De co u

e3:afterSellStockOnNewPo E-C deferred Schedule deferred rule R112 (billingToAccountOnSell) to the end of T1

ple d

R111:: Action buystockOn UpdateCash

PrintInfo Process deferred rule R112

Fig. 8. Execution Scenario of The Investment Application

This example illustrates several important points about the IRules environment. First of all, integration rules provide a declarative means for responding to events. Whereas application transactions capture the main logic of component integration, integration rules allow the logic for responding to events to be separated from the procedural logic of application transactions. Furthermore, the transactional aspects in-

14

Ying Jin, Susan D. Urban, Amy Sundermier, and Suzanne W. Dietrich

volving the execution of integration rules are completely handled by the IRules middleware layer. Application integrators can then focus on the logic of application transactions and the declarative specification of integration rules, while the IRules execution environment handles the low-level details associated with transaction processing and the nested execution of rules. In addition, the coupling modes and transaction model for integration rules readily support the concurrent execution of rules and transactions through the use of the decoupled and asynchronous coupling modes.

6

Summary And Future Research

This paper has presented the Jini-based architectural design of the IRules environment, describing the execution and transaction model for using active rules in distributed component integration. The specific focus has been on decoupled and asynchronous modes for concurrent execution of integration rules and transactions as well as transaction issues for the nested execution of rules over distributed EJB components. The capabilities of the IRules environment can be used to enhance existing middleware tools for event-based application integration with advanced features for the use of active rule functionality as part of the application integration process. The compilers for IRDL that generate all of the necessary metadata and wrappers for rule execution [24, 27, 28] are near completion. The development of the architecture components shown in Figure 6 have also been completed and are currently being integrated into the integration rule execution algorithm. Whereas the current rule execution algorithm supports sequential execution of integration rules, our future research is revising the rule scheduling algorithm to support the concurrent execution of non-conflicting integration rules. Our future research will also evaluate the functionality and performance of the IRules system [17] and investigate compensating subtransactions for failure handling of integration rules and application transactions.

References 1. Enterprise JavaBeans Specification 2.0, Proposed Final Draft 2, 19 April (2001) 2. Object Management Group: The Common Object Request Broker, Architecture and Specification, Revision 2.3, December (1998) 3. Urban, S.D., Dietrich, S.W., Saxena, A., Sundermier, A.: Interconnection of Distributed Components: An Overview of Current Middleware Solutions. Journal of Computer and Information Sciences and Eng., Shah, J. (ed.), March (2001) 23-31 4. Urban, S.D., Dietrich, S.W., Na, Y., Jin, Y., Sundermier, A., Saxena, A.: The IRules Projects: Using Active Rules for the Integration of Distributed Software Components. Proc. of the 9th IFIP 2.6 Working Conf. on Database Semantics: Semantic Issues in E-Commerce Systems, Hong Kong, April (2001) 265-286 5. Urban S.D., Dietrich, S.W., Sundermier, A., Jin, Y., Kambhampati, S., Na, Y.: Distributed Software Component Integration: A Framework for Rule-Based Approach. Handbook of Electronic Commerce in Business and Society, Watson R., Lowery P., Cherrington, J. (eds), (2002) 395-421

An Execution and Transaction Model for Active, Rule-Based Component Integration Middleware 15 6. Dietrich, S.W., Urban, S.D., Sundermier, A., Na, Y., Jin, Y., Kambhampati, S.: A Language and Framework for Supporting an Active Approach to Component-Based Software Integration. Informatica, Vol. 25, No. 4 (2001) 443-454 7. Paton, N.W., Diaz, O.: Active Database Systems. ACM Computing Surveys, Vol. 31, No. 1 (1999) 3-27 8. Arnold, K. (ed.): The Jini Specifications. 2nd ed. Addison-Wesley (2000) 9. Jajodia S., Kerschberg, L.: Advanced Transaction Models and Architectures. Kluwer Academic (1997) 10. Widom, J., Ceri, S.: Active Database System. Morgan Kaufmann, California (1996) 11. Pissinou, N., Makki, K., Krishnamurthy, R.: An ECA Object Service to Support Active Distributed Object. Information Science (1997) 63-104 12. Koschel, A., Kramer, R.: Configurable Event Triggered Services for CORBA-based Systems. EDOC'98, San Diego, California, Nov. (1998) 306-318 13. Fritschi, H., Gatziu, S., Dittrich, R.: FRAMBOISE – an Approach to Framework-Based Active Database Management System Construction. Proc. of the 7th ACM Int. Conf. on Information and Knowledge Mgmt. (1998) 364-370 14. Cilia, M., Bornhovd, C., Buchmann, A.: Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments. CoopIS’01, Trento, Italy, (2001) 195-210 15. Liebig, C., Malva, M., Buchmann, A.: Integrating Notfications and Transactions: Concepts and X2TS Prototype. Proc. of the 2nd Int. Workshop on Eng. Distributed Objects, Univ. of California, Davis, USA, Nov., (2000) 194-214 16. Urban, S.D., Karadimce, A.P., Dietrich, S.W., Abdellatif, T.B., Chan, H.W.R.: CDOL: A Comprehensive Declarative Object Language. Data & Knowledge Eng. (1997) 67-11 17. Jin Y., Urban, S.D., Dietrich, S.W.: An Architecture and Execution Environment for Component Integration Rules. Proc. of the 9th Doctoral Consortium of CaiSE’02, Toronto, Canada (2002) 18. Object Management Group: Additional Structure Mechanisms for the OTS. January (2002) 19. Java Specification Requests. http://www.jcp.org/jsr/detail/95.jsp 20. Cattell, R.G.G., Barry, D.K. (eds.): The Object Data Standard: ODMG3.0. Morgan Kaufmann, (1999) 21. DeJong, M., Laird, C.: TCL+Java = A Match Made for Scripting. http://www.sunworld.com/sunworldonline/swol-11-jacl.html 22. Ousterhout, J.: TCL and the TK Toolkit. Addison-Wesley (1994) 23. Java 2 Platform Enterprise Edition Specification, version 1.3, Final release, July (2001) 24. Kambhampati, S.: An Event Service for a Rule-Based Approach to Component Integration. M.S. Thesis, Arizona State University, Dept. of Computer Sci. and Eng., to be completed Fall (2002) 25. Abdellatif, T.: An Architecture for Active Database Systems Supporting Static and Dynamic Analysis of Active Rules Through Evolving Database States. Ph.D. Dissertation, Arizona State Univ., Dept. of Computer Sci. and Eng. (1999) 26. Gray J., Reuter, A.: Transaction Processing: Concepts and Techniques. Morgan Kaufmann (1994) 27. Patil, R.H.: The Development of a Framework Supporting an Active Approach to Component Based Software Integration. M.S. Thesis, Arizona State Univ., Dept. of Computer Sci. and Eng., to be completed Fall (2002) 28. Peri, R.S.: Compilation of the Integration Rule Language, M.C.S. Report, Thesis, Arizona State University, Dept. of Computer Sci. and Eng., July 2002