An Evaluation of Distributed Computing Options for a Rule-Based Approach to Black-Box Software Component Integration *

Transcription

1 An Evaluation of Distributed Computing Options for a Rule-Based Approach to Black-Box Software Component Integration * Susan D. Urban, Akash Saxena, Suzanne W. Dietrich, and Amy Sundermier Department of Computer Science and Engineering Arizona State University Tempe, AZ s.urban@asu.edu dietrich@asu.edu Abstract This paper presents an evaluation of distributed object computing technology and the manner in which such tools can be used to construct a distributed framework for active rule processing. The results are presented in the context of the Integration Rules (IRules) project, which is investigating the middle-tier, rule processing technology necessary for the use of declarative, active rules in the integration of distributed, black-box components. Assuming the use of Enterprise Java Beans (EJBs) for component interfaces, we provide an evaluation of the event and transaction processing features of CORBA compared to the same capabilities using Jini Connection Technology. Through the simulation of integration rules, we identify the event and transaction processing issues that must be considered in the construction of distributed architectures for the interconnection of EJB components. The results of this investigation are being used to develop a generalpurpose, distributed rule processing architecture for integration rules within the IRules project. 1. Introduction Recently, the focus in software development has shifted from the implementation of monolithic, stand-alone systems to the development of more collaborative solutions that involve the interconnection of distributed software components. To support these changes, distributed computing tools based on object-oriented concepts have evolved rapidly over the last few years. Component integration is typically achieved by hard coding the business logic that binds software components together. This hard-coding approach to business logic is often inflexible and does not always support the need for rapid prototyping of distributed applications. There is a strong need to develop a semantic layer on top of such tools to deal with the challenging requirements of applications built from distributed software components. The Integration Rules (IRules) project ( is investigating the middle-tier, rule processing technology necessary for the use of declarative, active rules in the integration of distributed, black-box software components [21]. Integration rules are based on the concept of active rules from active database technology [24], where an active rule is also known as an Event-Condition-Action (ECA) rule. Using the ECA rule paradigm, when an event occurs, a rule associated with this event is triggered. If the condition of the rule evaluates to true, then the action associated with the rule is executed. Unlike traditional active rules, integration rules are designed for the interconnection of distributed components developed using the Enterprise Java Beans (EJB) component model [5]. The ultimate goal of the IRules project is to build a general-purpose rule processor for integration rules. Developing such an environment, however, requires an understanding of the features and limitations of distributed computing tools, as well as an understanding of how these different tools can potentially be used together with EJBs. The research presented in this paper is an evaluation and comparison of current distributed computing technology in the context of the distributed rule processing needs of the IRules project. As a precursor to the actual development of the integration rule processor, the results described in this paper simulate the functionality that is envisioned for the IRules environment through the development of two different prototypes: one based on the use of the Common Object Request Broker Architectures (CORBA) [17] and one based on the use of Jini Connection Technology [12]. Each prototype was evaluated based on criteria that was established with respect to event and transaction processing needs. The event processing criteria evaluates messaging on aspects such as the type of messaging model supported, the data types that can be encapsulated in message objects, quality of service parameters, constraints on message objects, and the level of integration with the EJB model. The transaction services are evaluated using criteria such as the level of transaction control provided by the service, the level of compatibility with EJB components, support for nested * This research was supported by NSF Grant No. IIS

2 transactions, propagation of the transaction context, constraints on transaction participants, and the level of control over transaction semantics. The remainder of the paper is structured as follows. Section 2 provides an overview of relevant technology as well as other research projects for distributed rule processing. A stockbroker example is introduced in Section 3 to motivate the type of distributed rule processing environment that we are investigating. Section 4 presents a base architecture for the prototypes presented in the paper, together with the Jini and CORBA prototypes. An evaluation of the two prototypes is presented in Section 5. The paper concludes in Section 6 with a discussion of future research directions. 2. Relevant Technology and Related Work CORBA is a distributed object architecture and specification from the Object Management Group (OMG) that allows heterogeneous objects to interoperate across networks [17]. Clients request services from remote servers using the Interface Definition Language (IDL) to provide a language-independent way of defining interfaces. The backbone of CORBA is the Object Request Broker (ORB) that manages the tasks of locating objects and passing requests, events, and data to and from remote objects. The CORBA specification defines system-level services packaged with IDL specified interfaces [17, 18]. The specific services of interest to this research are the naming service, the event service, and the transaction service. Distributed computing options based on the use of Java include Enterprise Java Beans (EJB) [5, 6], the Java Messaging System (JMS) [13] and the Java Transaction Service (JTS) [14]. The EJB specification defines a server-side component model for Java, providing for the separation of business logic and low-level implementation details. The EJB component model facilitates this division through the use of objects and containers. Objects can either be entity or session beans, where an entity bean is used to represent a database or persistent business object and a session bean is used to provide transient, per-client, session-based services. Entity and session beans are encapsulated inside of containers that provide business logic in a secure, transactionally aware, and persistent server component. JMS is an API for accessing enterprise messaging systems. JMS facilitates the development of business applications that asynchronously send and receive critical business data and events. JTS specifies the implementation of a Java transaction manager that can be used by application servers to build transactional Java applications. Internally, JTS implements the Java mapping of the OMG OTS 1.1 specification. The JTS API (JTA) specifies an architecture for building transactional application servers and defines a set of interfaces for various components of this architecture. Jini Connection Technology provides simple mechanisms that enable software components to plug together without any planning, installation, or human intervention [4, 12]. Each software component provides services that other components in the community may use. Jini provides a lookup service that runs on the network that these software components are using for connection. All services that join the distributed community must register with the lookup service. JavaSpaces is a Jini service that facilitates building distributed applications [7]. A JavaSpace is a logical space that holds various Java objects from participating distributed components that share information by writing objects to the space and reading objects of interest that some other components may have put into the space. The Jini transaction services are used to provide a two-phase commit protocol that can be used by objects that wish to perform multi-operation and/or multi-space updates atomically within the scope of a transaction. Several research projects have investigated the use of rules in distributed environments. In [2], a CORBA-based framework known as CEDaR (Composite Event Detection and Rule Execution) for composite events and rules in a distributed, heterogeneous environment is introduced. In [19], Pissinou and Vanapipat proposed a reactive multidatabase architecture (RIMM) that separates user/client services from the provider/server services, through the use of intelligent agents and rule processing. Pissinou et al. [20] give a detailed description of an OMG-based rule service to support active distributed objects. In the ARION project [22], active mechanisms are being used to support data warehousing systems. In the FRAMBOISE project [8], a comprehensive construction system is used to provide a sophisticated, distributed active database mechanism. The Distributed Information System described in [1, 15, 16] is a CORBA-based system composed of an event history, an event detection component, a rule system, and an action execution component. None of these projects have investigated the use of the Java-based tools described above or the CORBA transaction service 3. The Stockbroker Application This section presents a stockbroker application to motivate the type of distributed rule processing environment that we are investigating. The stockbroker application provides users with the capability to manage portfolios, monitor stock values, and trade stocks. The example consists of three primary components: the UserServer component, the PortfolioServer component, and the StockExchangeServer component.

3 Each component provides an interface defining the methods that can be executed on the components. In addition, we assume that components can raise events to signal various conditions to the IRules environment. In particular, events can be raised before or after the invocation of a method or to signal changes in the internal state of a component. These events are used within application transactions to trigger rules that check application constraints or initiate other activities. To illustrate these concepts, consider the pseudocode for the buystock transaction shown in Figure 1. This transaction performs the task of buying a stock and updating the user portfolio. An invocation is made to the PortfolioServer to retrieve the instance of the portfolio named Akash. Before updating the portfolio to buy ten units of the stock identified by MFST, the rule shown in Figure 2 is triggered to make sure that the user has enough cash to complete the transaction. If the cash value passes the constraint test, the updateholding method is executed and an event is raised to signal the completion of the update action. The rule in Figure 3 is then triggered by this event to bill the user for the trade activity. We assume a simplified rule execution model where events raised before the execution of a method trigger rules that are executed immediately as subtransactions. Events raised after the execution of a method or as a result of a state change trigger rules that are executed as separate transactions. 4. Architectural Prototypes This section provides an overview of two prototypes that were investigated as part of this research. Section 4.1 addresses the common architectural aspects of both prototypes. The transaction model for active rules in the IRules environment is addressed in Section 4.2, followed by descriptions of the Jini and CORBA prototypes in Sections 4.3 and 4.4, respectively. 4.1 The Base Architecture Figure 4 illustrates the base architecture for our work. To maintain a uniform interface for accessing any component that is deployed in the IRules environment, every component that participates in the IRules framework is represented by an EJBProxy wrapper. When the wrapper is activated, it assumes that the component has already been deployed into a container and that the integrator knows the name with which the component was deployed. The wrapper performs tasks such as registering the component with the distributed framework, introspecting the component that the wrapper represents, and managing extents of components. The Business Logic Repository (BLR) shown in Figure 4 holds metadata about the entire distributed community that is formed by the components deployed in the IRules environment. This metadata includes component interface information, business application transactions such as the buystock transaction in Figure 1, and integration rules such as those shown in Figures 2 and 3. Eventually, application transactions and integration rules will be stored using the declarative language framework that is being investigated as part of the IRules project [21]. Currently, transactions and rules are simulated through the use of Java code. An IRules client allows users to invoke the application transactions of the environment. A multi-threaded rule evaluator is associated with the BLR, containing the code for the transactions and rules and executing the rules that are triggered in the environment. Events are a critical part of the IRules environment as they are used to trigger the rules that have been defined for the application. In the IRules environment, only wrappers and EJB components are permitted to raise events. Communication is carried out using event channels that are created by a wrapper for each component that is deployed in the IRules environment. As part of the startup procedure, a wrapper automatically registers the name of the event channel with the BLR and the BLR can in turn become a subscriber to this event channel, thus serving as the single global component that is a subscriber to all event channels in the system. Other data structures that are common to each prototype are the IRules message format and the IRules binding structure. The IRules message format provides a way to format events that are raised in the system. The IRules binding structure maintains metadata about the components of the environment. 4.2 Transaction Issues in IRules Transactions are an essential requirement for rule processing in the IRules environment. To implement transactions over distributed components, there is a need to use a standardized distributed transaction manager with capabilities for two-phase commit protocol. Since the components that are used in each prototype are EJB components, the following discussion is made in the context of transaction functionality that is available for the EJB component model. EJB components provide either programmatic (beanmanaged) or declarative (container-managed) transaction control. Since components form a part of a larger distributed community, there is the need to initiate an outer global transaction that is controlled by the IRules environment. An individual EJB transaction forms a small part in the entire transaction and hence must be controlled by the client. This approach requires the use of bean-managed transactions that allow clients to control transaction boundaries.

4 BEGIN buystock ASSIGN userportfolio = EXECUTE(PortfolioServer.activateComponentInstance ( Akash )) ASSIGN stockunits = LITERAL(10) ASSIGN tradetype = LITERAL(1) /* 1 indicates a buy transaction, 0 indicates a sell transaction */ EXECUTE userportfolio.updateholding( MSFT,stockUnits, 05/12/ :00,tradeType) END Figure 1: buystock Application Transaction Pseudocode EVENT BEFORE UPDATEHOLDING ACTION BEGIN constraintcashenough ASSIGN userportfolio = EXECUTE(PortfolioServer.activateComponentInstance ( Akash )) ASSIGN localasset = EXECUTE(StockExchangeServer.activateComponentInstance ( MSFT )) ASSIGN stockvalue = EXECUTE(localAsset.getAssetValue()) ASSIGN stockunits = LITERAL(10) ASSIGN moneyneeded = EXECUTE(stockUnits * stockvalue) ASSIGN moneyavailable = EXECUTE(userPortfolio.getPortfolioAmount()) ASSIGN moneyavailable = EXECUTE(moneyAvailable 1000) // User needs to maintain a minimum balance of $1000 COND moneyneeded >= moneyavailable ACTION SETRESULT(ABORT) ELSE SETRESULT(CONTINUE) ACTION END Figure 2: Integration Rule Pseudocode for Cash Constraint Check on Portfolio EVENT EVT_HOLDINGUPDATED OR EVT_NEWHOLDINGADDED ACTION BEGIN updateuserbilling ASSIGN user = EXECUTE(UserServer.activateComponentInstance (Message.userName)) ASSIGN stockvalue = Message.AssetPrice ASSIGN stockunits = Message.AssetUnits ASSIGN billdollaramount = EXECUTE(assetValue * assetunits) EXECUTE (user. recordtradedata(message.tradetimestamp,billdollaramount)) ACTION END Figure 3: Integration Rule Pseudocode to Bill User When a Portfolio is Updated Traditional EJB applications that use client demarcated transactions do so within the implementation of the code inside of the component or by obtaining a transaction context in the client code and completing operations involving all components within the same thread of execution, terminating the transaction in a commit or abort. EJB components use the JTA to provide the transaction functionality and coordinate the two-phase commit over all of the operations that are invoked within the scope of an active transaction. Once a transaction is initiated on the client side, all of the operations must be completed within the same thread of execution, otherwise the transaction context is lost. In the IRules environment, EJB components are referred to at an abstract level and the meta operations defined using EJB operations never use componentspecific code. A wrapper that represents the EJB component in the IRules environment is the sole client and the wrapper executes requests from IRules clients to invoke methods that require the execution of EJB operations. Control is therefore distributed and operations are not executed in a single thread of execution, thus making JTA insufficient to provide transactional capabilities to the IRules environment. As a solution to this issue, outer-level client transactions are used in tandem with JTA to implement a hybrid transaction model that uses either Jini or CORBA transactions (depending on the prototype) to initiate the outer transaction at an IRules client location and JTA to enforce sub-transaction integrity when the wrapper executes an operation on an EJB component. The subtransaction on the component that is invoked by the wrapper must be committed or aborted before control is returned to the rule executor since the transactional context is lost when the thread that started the transaction terminates without completing the transaction. Furthermore, an EJB operation cannot participate in concurrent transactions.

5 IRules Clients Business Logic Repository Multi Threaded Rule Evaluator EVENT CHANNELS Messaging System Wrapper EJB Wrapper EJB Wrapper EJB Figure 4: Base Architecture for the IRules Prototypes The result of a client transaction can be decided by observing the results of the individual EJB subtransactions that were completed under the client transaction. The voting policy can be tailored to suit the needs of the application. The policy adopted for the prototypes described in this paper is of an all-ornothing type, where all sub-transactions must succeed for the client transaction to commit. If one subtransaction aborts, the wrapper needs to go through all of the EJB sub-transactions and undo the effects of each transaction. Note that the EJB transactions have already either committed or aborted and thus there is a need to include compensating operations as in the open nested transaction model [9] to undo the effects of the EJB subtransaction that must be rolled back due to the rollback of the parent transaction. 4.3 The Jini Prototype Table 1 provides an overview of the specific technology used within the Jini prototype. The Jini lookup service and JavaSpaces play a central role in the interconnection of components within the environment. Wrappers are implemented as Jini services whose adapters implement the EJBProxy interface that is used by all clients to interact with components. Upon startup, the first task that a wrapper performs is to register the component name in the Jini lookup service. Once a wrapper has registered itself, it begins the task of introspecting the EJB component that it represents. During the introspection process, the wrapper gathers information about the operations that the component supports so that the information can be stored using the IRules binding structure into the distributed repository that is managed by JavaSpaces. JavaSpaces provides a built-in, distributed sharing space into which various components may insert data. JavaSpaces also provides a feature to query the collection of data that it maintains, thus eliminating the need to develop such services as part of a separate metadata server. Although Jini and JavaSpaces provide the foundation for lookup services and metadata management, the use of events and transactions in Jini required further analysis. Jini supports a remote event notification model that is an extension of the traditional Java event model comprised of listeners and publishers. It is possible to implement a messaging subsystem for the IRules environment using just the Jini event subsystem. There is no standard, however, for interaction between EJB components and events in Jini. Sun Microsystems, in particular, advises using a JMS compliant messaging product together with EJB components. JMS provides support for the publish/subscribe model of communication, with complete decoupling between event publishers and subscribers. This model is more appropriate for distributed rule processing than the pointto-point messaging of Jini. JMS also provides a filtering capability so that subscribers can further qualify the specific types of messages they are interested in receiving. The ability to support different types of message objects as well as the load balancing feature also make JMS a more appealing choice for a messaging service than the Jini event service.

6 The Jini transaction service provides a basic two-phase commit protocol, leaving the semantics of the two-phase commit for the application to implement. This feature provides the capability to coordinate a distributed transaction across components. Whenever a wrapper encounters a new Jini transaction context from a client transaction, the wrapper creates an internal registration of the Jini transaction using an internal data structure. Using this data structure, the wrapper records all EJB sub-transactions that are completed under the scope of the Jini transaction. When the Jini transaction reaches a decision point and conducts a two-phase commit over all its participants, the wrappers that were part of the Jini transaction are required to vote on the outcome of the Jini transaction. 4.4 The CORBA Prototype An overview of the technology used in the CORBA prototype is shown in Table 2. This prototype builds on the CORBA 2.3 specification [17] for distributed computing using the naming, transaction, and event services of CORBA. The Inprise Visibroker 4.0 ORB [10] was used as the CORBA product and the Inprise Application Server 4.0 [11] was used as the EJB server for this implementation. Each wrapper in the system is implemented as a CORBA server that implements the EJBProxy interface. When a wrapper is started, it first introspects the EJB component that it is connected to and bundles the information about its operations into the IRules binding structure objects that are then uploaded into the BLR. In the absence of a service such as JavaSpaces, the BLR functions as the metadata repository in addition to its functions of serving application transactions. The BLR is the first component to be started in the CORBA prototype, registering itself with the CORBA naming service. The BLR also loads the application transactions for use by the clients. Since the BLR is now taking on the added function of handling metadata requests from the IRules environment, the global rule evaluator is implemented as a separate CORBA server. The CORBA event service was used as the messaging system for the CORBA prototype. The CORBA event service was not designed to operate with EJB components. As a result, the use of the CORBA event service was more difficult than the use of JMS in the Jini prototype. Each component contains code that makes it a publisher on the event channel. Since the event channel is created by the wrapper, the wrapper also becomes a publisher on the event channel that it creates. Only the wrapper or the component that it represents may raise events on an event channel owned by the component. For objects to be passed over the event channel, the event object that is created must be a CORBA object and must be declared to the CORBA environment. Inserting the necessary code to create CORBA event objects into an EJB component is a non-standard approach. Although the event service of CORBA proved to be difficult in combination with the use of the EJB model, the strength of the CORBA prototype is found in the use of the CORBA transaction model, where propagation of the transaction is integrated with EJB components. Since a CORBA-based EJB container was used, the CORBA transaction service extends to the wrappers and the EJB components. The CORBA prototype uses the same transaction model as in the Jini prototype, where subtransactions do not share information and EJB operations are executed as JTA transactions that run to completion. The wrapper maintains a registry of active transactions and operations completed. CORBA, however, provides complete transaction service as opposed to just a coordination protocol as supported by Jini. Since a common underlying transaction specification is used in CORBA and in the EJB model, the parent transaction can keep track of the sub-transactions that are completed under it. Similar to the Jini prototype, the CORBA transaction model for application transactions and integration rules also requires the use of compensating transactions to handle failures. System Component Technology Used Black Box Components Enterprise Java Beans (EJB). Distributed Lookup / Directory Jini Lookup Service, searching by attribute. Distributed Interface Repository Jini JavaSpaces, tuple space containing specification of remote objects. Distributed Transactions Jini Distributed Transaction services in tandem with JTA for EJB operations. Event Subsystem Java Messaging System (JMS) publish/subscribe model and object messages. Table 1: Jini Prototype System Components with Integration Technology Used System Component Technology Used Black Box Components Enterprise Java Beans (EJB). Distributed Lookup / Directory CORBA Naming Service, search by semantic name. Distributed Interface Repository BLR IRules Component, standalone CORBA server. Distributed Transactions CORBA Distributed Transaction services. Event Subsystem CORBA Event Services using publish/subscribe model. Table 2: CORBA Prototype System Components with Integration Technology Used

7 5. Evaluation This section presents an evaluation of the event and transaction aspects of each prototype. With respect to event issues, the IRules distributed framework requires the use of a messaging system to support asynchronous message passing during the execution of active rules. It is critical that the messaging service that is recommended for the final architecture be a solution that is extensible and integrates well with all aspects of the IRules framework, especially with the use of EJB software components. The messaging system should also provide features such as message storing, message filtering, and reliable message delivery. In addition, the messaging system s ability to exchange data across messages is also important since it is desirable to exchange rich application objects via messages between components. With respect to transaction issues, rules executed in the IRules framework must execute within the scope of a transaction. The CORBA transaction service has only recently become available and therefore the research projects that have been reviewed have not made use of this feature. Past research projects on distributed rules have also not investigated the Jini transaction service or the Java transaction service. An important criterion is how well each transaction service supports the needs of rule processing in a distributed framework. Other criteria are concerned with the level of transaction support provided by the services as well as the extensibility of the transaction services and its ability to interact with EJB components. The ability to propagate transaction contexts across application boundaries is especially important. Table 3 presents a comparison of the features offered by each of the event services that were evaluated in the Jini and the CORBA prototypes. The CORBA event service and the JMS were actually used in the implementation of the prototypes. The Jini event service was considered for evaluation purposes but it was not used in any of the implementations. The CORBA event service and JMS both support the pull/push model of messaging. In addition, JMS supports a point-to-point model of messaging known as Queues. Queues may be implemented in the CORBA event service as a special case of a single subscriber/publisher over an event channel. Jini distributed events only support the point-to-point communication model. The CORBA event service allows the exchange of arbitrary data objects over its event channels but it requires all of these objects to be CORBA objects. This requirement imposes additional overhead on the part of the event publishers and recipients of the event object. Publishers must be capable of generating CORBA objects that encapsulate the message. Recipients must be capable of deciphering a CORBA object by using some decoding mechanism. In a purely Java environment using EJB components, the process of generating and deciphering CORBA objects is unnecessary overhead. The Jini distributed event mechanism allows generic Java objects to be exchanged within a Jini environment. This approach is similar to the Java event mechanisms implemented in a distributed environment. However, a limitation of the Jini distributed event mechanism is that all participants need to be Jini objects which is similar to the requirement imposed by the CORBA event service. With the use of the EJB model for software components, a more flexible solution is required for the IRules environment. The JMS service provides maximum flexibility in terms of participants and objects that can be exchanged via the JMS service. JMS allows event objects to hold any type of data. JMS also imposes no restrictions on the participants of the service. The participants may be CORBA objects, Jini objects, or Java objects. This is the most desirable configuration for the IRules framework as it allows room for expansion under the messaging system and does not restrict the implementation to a single object technology. The CORBA event service as specified in the CORBA 2.3 specification does not allow the user to set any Quality of Service (QoS) parameters such as delivery time, message hold time, and guarantee of delivery. Also, the CORBA event service does not provide any filtering mechanisms whereby filters may be applied to message streams by message consumers to restrict the messages that flow into the consumers event channel. The CORBA 3.0 specification [23] defines the CORBA Notification service that supercedes the CORBA event service and provides features such as message filtering and ability to specify QoS parameters. Although the notification service is more advanced than the CORBA event service, it is not yet integrated completely with existing CORBA products and the limitation that all participants must be CORBA objects still exists. JMS, on the other hand, provides basic event channel filtering services and also allows specification of QoS parameters for message delivery guarantees and the time for which messages may be held on the event channels for consumers. The Jini distributed event mechanism has no notion of QoS or message filtering. Out of the three event services evaluated in this paper, JMS integrated the best with the EJB black-box components in terms of changes required to get the components to operate with JMS and the flexibility of the messaging solution in the context of the IRules framework. The CORBA event service did not integrate well with EJB components as it required extensive code changes that were specific to enabling the components to exchange CORBA event objects. JMS integrated well with the EJB components with minimal changes required

8 by the components to be JMS aware. In addition, JMS is being incorporated into the EJB 2.0 specification with special event driven enterprise beans. Based on the analysis of the evaluation results, JMS provided the most flexible and compatible messaging solution. The IRules environment required transaction control that would allow a transaction to span multiple distributed locations within the same transaction scope. Since the architecture uses various distributed technologies, the transaction service had to be compatible with the technologies that made up the IRules framework, namely CORBA, Jini, and EJB technologies. For this reason, a transaction model based on the open nested transaction model was used in both the prototype implementations. The constant requirement in both implementations was JTS. Table 4 outlines the differences between the CORBA transaction service, the Jini transaction service, and JTS. The following discussion will primarily compare the CORBA transaction service to the Jini service since the choice between these two services is the most critical for transaction processing in the IRules framework. The major difference between CORBA and Jini transactions is that the CORBA transaction service provides complete transaction control as opposed to the Jini transaction control protocol that only provides the basic two-phase coordination protocol. The Jini transaction service only notifies the transaction participants of the various stages of the transactions while leaving the semantics of the transactions to the participants. The CORBA transaction service provides a transaction service in a conventional sense by handling resource management, two-phase protocol coordination, and rollbacks/commits. The CORBA transaction service provides guidelines for participants so that their state can be controlled by the transaction service when commits or rollbacks occur. The CORBA transaction service also allows databases to participate in transactions directly. The Jini transaction service is more flexible in terms of configuring a custom transaction control as it provides the tools to build a custom transaction service. This is useful in the IRules environment where a traditional transaction control service cannot be used directly. The CORBA transaction service can be customized, but it requires building workarounds for the transaction service. IRules components mimic the CORBA Resource object and register themselves as data dependent objects with state information that causes the transaction manager to notify the IRules objects with all the notifications during the two-phase commit protocol. Thus, every component that is deployed into the IRules distributed environment always participates in a transaction through its corresponding IRules wrapper. Transaction propagation was essential as IRules transactions span multiple components. Transactions that are initiated in the client must propagate to the server components and all operations that are initiated from the start of the transaction in the client to the completion of the process should use the same transaction context. CORBA provides explicit and implicit modes of transaction context propagation. The prototypes in this research used the explicit transaction propagation mode. The implicit transaction mode associates itself with the thread on which the CORBA request is sent. Implicit propagation was not used as it imposed restrictions on the addition of participants into the transaction as the transaction progressed. Explicit transaction propagation allows access to the transaction context object directly and facilitates querying the context object. The transaction context interface is used to add more participants to the transaction and to get information about the transaction itself that the IRules component uses to track the transaction. In Jini, only explicit propagation was possible. The Jini transaction context allowed the addition of participants using the context and provided information to identify the Jini transaction. Evaluation Category CORBA Event Service Java Messaging Service Jini Distributed Events Supports the pull/push mode of Supports the pull/push mode and Supports point-to-point Messaging Mode messaging. point-to-point messaging. distributed events. Data types that can be passed Supports multiple types that can Java objects (Rich Objects) can on event channels are of a be used to pass data in the be passed in the distributed Message Data Types generic data type that must be distributed environment. environment. type cast on receiver side. Quality Of Service Constraints on Message Objects Integration With CORBA 3.0, supports quality of service parameters, such as delivery constraints. Requires objects that are passed on the event channel to be CORBA objects. Does not integrate well with EJB components since events must be CORBA objects. Supports configuration of various delivery options. Java objects are encapsulated in one of the five data types and are passed in an event. Integrates with EJB components and is being incorporated into the EJB 2.0 specification. Table 3: Messaging System Comparison Does not support configuration of quality of service parameters. Java objects may be passed in an event. Does not integrate with EJB components. Can only use Jini objects.

9 In summary, the CORBA transaction service and the Jini transaction services are both viable options for implementation of the IRules transaction model. The Jini transaction service is more flexible in terms of giving the implementor complete control over the meaning of a transaction. The CORBA transaction service is a more mature and strict specification, where IRules components had to mimic specific behavior to be allowed to participate in a CORBA transaction. Both services support only flat transactions and they both only allow either CORBA participants or Jini participants respectively to utilize the transaction service. Based on our evaluation results, we developed a third prototype that demonstrated the use of the CORBA transaction service together with JMS as an event service for EJB components. This third prototype provides a more viable solution for combining global CORBA transactions with events generated from EJB components. The Jini transaction service, however, still provides an advantage with respect to custom development of a transaction model for distributed rule execution. 6. Summary and Future Directions This paper presented an evaluation of current distributed object computing technology and the manner in which such tools can be used to construct a distributed framework for active rule processing. Our results indicate that JMS is the most viable alternative to use as a messaging system for communication with software and data sources represented using the EJB component model. The CORBA transaction model also provides a more complete transaction service when compared to the Jini transaction service, while the Jini transaction service provides the greatest amount of flexibility for the custom development of an execution model for distributed rules. Although JMS is a clear winner in our evaluation of messaging systems, the choice between the use of CORBA and the use of Jini as the final framework for a general rule processor is still in question. The complete execution model for the IRules environment is still under investigation. As indicated by the prototypes presented in this paper, the execution model must support some form of nested or open nested transaction model with compensating transactions to handle failure. We are also investigating issues with respect to detached coupling modes for rules as well as synchronous versus asynchronous execution of rules. The Jini framework may therefore provide more flexibility for developing a transaction model that supports the full range of features that are needed to support these execution model features. In addition to development of the execution model for integration rules, we are also developing a declarative language framework for the expression of application transactions and integration rules [21]. Evaluation Category CORBA Transaction Service Java Transaction Service Jini Transaction Service Provides complete transaction Based on the CORBA Only provides a coordination Transaction Control service with two-phase commit transaction service framework (communication) Levels and resource management. specifications. for two phase commit protocol. Compatibility With EJB Component Model Nested Transaction Availability Control Over Transaction Semantics Flexibility Of Service As A Building Block To Build Hybrid Transaction Protocol Transaction Context Propagation Constraints On Transaction Participants Scalability Data Integrates with EJB components when a CORBA-based EJB container is used. Nested transactions specified but not yet widely available. Transaction semantics are predefined. Provides less flexibility in terms of building transactional systems over the service. Transaction service targeted for EJB components. Nested transactions not yet available. Transaction semantics are predefined based on CORBA OTS. Provides less flexibility in terms of building transactional systems over the service Does not integrate with EJB components. Nested transactions not yet available. Transaction semantics are left up to the user. Provides maximum flexibility for designing a custom transaction environment. Explicit or implicit propagation. Explicit or implicit propagation. Explicit propagation. Can be used only with CORBA participants/objects. Can be used with EJB operations as participants. Designed and deployed for Designed to handle enterprise scalability and high volume application loads and is a applications. scalable solution. Table 4: Transaction Services Comparison Can be used with Jini compliant participants. No scalability data exists to compare with CORBA transaction services.

10 References: [1] G. Bultzingsloewen, A. Koschel, and R. Kramer, Active Information Delivery in a CORBA-based Distributed Information System, Proc. of the 1 st Int. Conf. on Cooperative Information Sys. (CoopIS'96), Belgium, Jun , [2] S. Chakravarthy and R. Le, ECA Rule Support for Distributed Heterogeneous Environments, Proc. of the Int. Conf. on Data Eng., Orlando, [3] CORBA Services, Object Management Group ( Dec [4] W. Edwards, Core Jini, Prentice Hall, [5] Enterprise Java Beans Specification 1.1, Nov. 24, [6] Enterprise Java Beans Specification 2.0, May 31, [7] E. Freeman, S. Hupfer, and K. Arnold, JavaSpaces: Principles, Patterns, and Practice, Addison-Wesley, [8] H. Fritschi, S. Gatziu, and K. Dittrich, FRAMBOISE An Approach to Framework-Based Active Database Management Construction, Proc. of the 7 th Int. Conf. on Information and Knowledge Mgmt., Washington, D. C., [19] N. Pissinou and K. Vanapipat, Active Database Rules in Distributed Database Systems: A Dynamic Approach to Solving Structural and Semantic Conflicts in Distributed Database Systems, Computer Sys. Science and Eng., vol. 1, 1996, pp [20] N. Pissinou, K. Makki, and R. Krishnamurthy, An ECA Object Service to Support Active Distributed Objects, Informatics and Computer Science, 1997, pp [21] S. D. Urban, S. W. Dietrich, Y. Na, Y. Jin, A. Sundermier, and A. Saxena, "The IRules Project: Using Active Rules for the Integration of Distributed Software Components," Proc. of the 9 th IFIP 2.6 Working Group on Database Semantics, Hong Kong, Apr [22] A. Vavouras, S. Gatziu, K. Dittrich, Incremental Refreshment of Data Warehouses: The SIRIUS Approach, Proc. of the Advanced Database Symposium, Tokyo, [23] S. Vinoski, New Features for CORBA 3.0, Communications of the ACM, vol. 41, no. 10, 1998, pp [24] J. Widom and S. Ceri, Active Database Systems: Triggers and Rules for Advanced Database Processing, Morgan Kaufmann Publishers, San Francisco, [9] J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, San Mateo, CA, [10] Inprise Visibroker 4.0, [11] Inprise Application Server 4.0, [12] Jini Architecture Specification 1.01, Nov. 1999, [13] Java Message Service 1.01, Oct. 5, 1998, [14] Java Transaction Service, Dec 01, 1999, [15] A. Koschel and R. Kramer, Configurable Event Triggered Services for CORBA-based Systems, Proc. of the 2 nd Int. Enterprise Distributed Object Computing Workshop, San Diego, [16] A. Koschel and P. Lockemann, Distributed Events in Active Database Systems: Letting the Genie Out of the Bottle, Data and Knowledge Eng., vol. 25, 1998, pp [17] Object Management Group: The Common Object Request Broker, Architecture and Specification, Revision 2.3, Dec [18] Object Management Group: CORBAservices: Common Object Services Specification, Updated Revision, Dec