AN EVENT PROCESSING SYSTEM FOR RULE-BASED COMPONENT INTEGRATION Susan D. Urban, Sunitha Kambhampati, Suzanne W. Dietrich, Ying Jin, Amy Sundermier Department of Computer Science and Engineering Arizona State University Tempe, Arizona USA
[email protected] [email protected]
Keywords:
active rules, event specification, event processing, component integration
Abstract:
The Integration Rules (IRules) project has developed an environment in which active rules, known as integration rules, are used together with transactions to provide an event-driven, rule-based approach to the integration of black-box components. This paper presents the event processing system that supports the use of integration rules over components. The event processing system is composed of the language framework for the specification of different types of events, an event generation system for generating event instances, and an event handler for communicating the occurrence of events to the integration rule processor. The language framework supports the enhancement of EJB components with events that are generated before and after the execution of methods on components. Since integration rules support an immediate coupling mode and execute in the context of nested transactions, a synchronization algorithm has been developed to coordinate the execution of immediate integration rules with the execution of methods on components. The synchronization algorithm makes it possible to suspend and resume distributed application transactions to accommodate the nested execution of integration rules with an immediate coupling mode.
1
INTRODUCTION
Distributed component technology standards address the need for well-known interfaces and middleware for discovering and integrating software components into applications (COM/DCOM, 2003; OMG, 1998; WSA, 2002; J2EE, 2003). Implementing distributed applications when components reside on multiple servers, however, can be a difficult task that often results in procedural, hard-coded solutions. The application integrator must not only understand the semantics for mediating the interactions between the components, but must also be skilled in the technical details associated with distributed event and transaction processing techniques. The Integration Rules (IRules) project at Arizona State University has responded to the need for more flexible and declarative middleware technology by applying active rule processing technology to the area of software component integration (Urban et al., 2001). Active database technology enhances traditional database technology with the ability to monitor and react to circumstances that are relevant to an application (Widom and Ceri, 1996). The IRules project is extending the use of active rules to
distributed components, providing a middle-tier, rule processing framework for the integration of distributed black-box software components. The current prototype implementation supports the Enterprise JavaBeans (EJB) (EJB, 2001) component model, with future plans to include support for other component models. The IRules project provides an environment in which active rules, known as integration rules, are used together with transactions to provide an eventdriven, rule-based approach to component integration. When an event is generated in the IRules environment, an integration rule is triggered to test a condition expressed as a query over distributed components. A successful condition evaluation may invoke additional methods on components in the action part of an integration rule. Integration rules therefore provide a declarative and distributed rule processing mechanism for responding to events in a distributed environment, thereby separating the logic associated with reactive behavior from the main application logic expressed within distributed transactions. One of the challenges of developing the IRules environment has been the design and
implementation of the event processing system that supports the execution of integration rules (Kamphampati, 2003). The event processing system is composed of a language framework for the specification of several different types of events, an event generation system for generating instances of each event type, and an event handler for communicating events to the integration rule processor. The IRules language allows for the definition of events that are detected before and after the execution of methods on components and the execution of distributed application transactions. The language framework also supports the specification of events that are generated and published by the internal logic of black-box components as well as events that are generated by sources external to IRules. To coordinate events with transactional behavior in the IRules environment, we have developed wrappers that serve as proxies for EJB components (Patil, 2003). All method calls are routed through the wrappers. The wrappers are responsible for generating events before and after method execution. The wrappers are also capable of suspending methods to support the nested execution of triggered rules with an immediate coupling mode. A synchronization algorithm uses semaphores implemented with JavaSpaces (Freeman et al., 1999) operations as a distributed communication mechanism. The synchronization algorithm coordinates the execution of application transactions with the nested execution of integration rules before and after the execution of methods on EJB components. Our research provides an original approach to enhancing black-box components with event generation techniques, addressing issues for control of transactional scope, event handling, and suspension and resumption of activities in component-based integration architectures. These issues are described as future directions within the Business Process Execution Language specification (BPEL4WS, 2002), a standard choreography language for integrating Web Services. The techniques described within this paper, although currently implemented using Java technology, are applicable to other component models and integration languages as well. The remainder of this paper is structured as follows. Section 2 provides an overview of the IRules environment. Section 3 presents the language framework for the specification of IRules events. The event handling component of the IRules environment is presented in Section 4. Section 5 provides an overview of the synchronization algorithm for coordinating method execution with rule execution. Our work is discussed in the context
of related work in Section 6. The paper concludes with a summary in Section 7.
2
OVERVIEW OF IRULES
Figure 1 provides a high-level view of the functionality of the IRules environment. As shown in Figure 1, EJB components are organized into distributed containers, where each component was purchased or created independently of components in other containers. This specific example illustrates an Investment application from (Urban et al., 2001), consisting of four different containers with purchased software components: a Portfolio container, a Pending Order container, a Stock container, and an Account container. Although the containers in Figure 1 are independent black-box containers that know nothing about the existence of the other containers, the IRules semantic framework supports the definition of externalized relationships (Rumbaugh, 1987) between such containers. These relationships are shown in Figure 1 by lines between components in different containers. For example, the externalized relationship between Stock and Pending Order represents the type of stock that is associated with a pending buy or sell order. Externalized relationships are managed by IRules wrappers around existing EJB components. In addition to externalized relationships, IRules wrappers add other functionality to EJB components, such as extents, derived attributes, stored attributes, and events (Dietrich et al. 2001). Application logic is captured through the use of application transactions together with integration rules. Integration rules have been derived from active rules in active database technology (Widom and Ceri, 1996), providing an Event-ConditionAction (ECA) rule form as well as an Event-Action (EA) rule form for responding to events. As shown in Figure 1, when an application transaction executes a method such as Operation k on an EJB component, an event can be generated that triggers the execution of integration rules. These events are referred to as method events and can be generated before or after the execution of a method on a component. Integration rules may also be triggered by internal events, application transaction events, or external events. Internal events are events that were defined within a black-box component before the component joined the IRules environment. Application transaction events are events that can be generated before or after the execution of an application transaction. External events are events that are generated from sources outside of the IRules environment.
The structure of an integration rule is also shown in Figure 1. When an integration rule is triggered by an event, the rule may execute a when condition that is expressed as a simple query over the event object and its parameters. If the condition evaluation is true, then an OQL-based (Cattell and Barry, 2000) define statement allows for the named specification of bindings using a query over the distributed components of the environment. The action of the rule may refer to these bindings when invoking a method of a component or an application transaction. The rule-based approach to component integration within the IRules environment is expressed using the IRules Definition Language (IRDL) (Dietrich et al., 2001; Urban et al. 2001). IRDL consists of four sub-languages: the Component Definition Language (CDL) for describing components and defining the method and internal events associated with that component, the IRules Scripting Language (ISL) for describing application transactions, the Event Definition
Application Transaction Event t ri
generate
gg
er
s
Application Transaction Begin Operation1 ... Operation k ... Operation n End
generate
Language (EDL) for defining external and application transaction events, and the Integration Rule Language (IRL) for defining integration rules that respond to events. In the current version of IRDL, ISL is based on the JACL (DeJong and Laird, 2003) scripting language, which is a Java implementation of the Tool Command Language (TCL) (Ousterhout, 1994). The IRules execution environment is a Jini-based architecture that supports the execution of events, rules, and application transactions over distributed EJB components (Jin et al., 2002). Architectural components include the rule manager for controlling the execution of rules, the transaction manager for the management of transactions, the object manager for providing abstract access to the underlying components of the system, the metadata manager for storing the integration semantics as extracted from the compilation of an IRDL schema, and the event handler for processing events. The Java Messaging Service (JMS) (JMS, 1999) provides asynchronous event notification.
Integration Rule: create rule ruleName event eventName(event Param eters) [on componentNam e com ponentVariable] condition [eaCoupling] when conditionSpecification [define bindingsNam e as select from [where ]] action [caCoupling] [from [where ]] do action Execute Operation on EJB
Account Container
triggers
Integration Rule Stock Container
IRulesAccount
IRulesStock
Account
Stock
Execute operation on EJB
Externalized Relationships PendingOrder Container
Portfolio Container
IRulesPendingOrder
IRulesPortfolio Portfolio
PendingOrder generate
generate
triggers
Integration Rule
External Event
Method Event
Internal Event
Integration Rule triggers
Figure 1. Purchased Components
3
IRULES EVENT DEFINITION
The subsections that follow illustrate the specification of each type of event supported in the IRules environment.
3.1 Event Specification in CDL Method and internal events are expressed using CDL since they are associated with component definitions. The syntax of CDL is based on the syntax of the ODMG Object Definition Language (ODL) (Cattell and Barry, 2000). Using the Investment example introduced in Section 2, Figure 2 shows an example of describing a portion of the Stock component to the IRules environment, which includes the definition of a method event. The event specification is composed of an event name and a list of parameters, followed by curly braces that enclose the definition of the details of the event. The method keyword defines the type of the event, while the before keyword is an event modifier, indicating that the event is raised before the execution of the method. The keyword after can be used to define an event raised after the execution of a method. The name and type of the method parameters are also specified. The names of the method parameters in CDL allow for naming the attributes that are to be propagated as parameters to the IRules event. component Stock implements EntityBean (extent stocks) { ……… event beforeSetPrice(newPrice) {method before setPrice(double newPrice);}} Figure 2. Example of a Method Event
Figure 3 presents the stockBuy rule as an example of an integration rule that is triggered in response to the beforeSetPrice method event. The condition part of the rule includes an OQL-like query expressed over the distributed components of the environment. The when condition checks whether the new price of the stock is less than the current stock price. The action part of the rule does a buy transaction for the stocks that are currently pending. When an EJB component joins the IRules environment, it is possible that the black-box component is capable of generating and publishing events as part of its internal logic. The IRules environment refers to these events as internal events and allows the use of internal events in the integration process. Since internal events are
associated with components, these events are defined as part of CDL. create rule stockBuy event beforeSetPrice(NewPrice) on stock S condition immediate when NewPrice > S.price action immediate from Pn in S.pendingTrades where S.price
