Execution unit (XU)

The execution unit (XU) is a resource adapter for Java™ EE Connector Architecture (JCA) 1.5. The XU handles the low-level aspects of ruleset execution and collaborates with the server to manage resources.

The XU communicates with the rule engines and collaborates with the resource adapter container. It manages resources through services such as work management, connection management, lifecycle management, and resource adapter configuration.

The XU offers support for the classic rule engine and the decision engine, and provides extra services:

Pooling of the rule engines
Ruleset sharing
XML or BOM conversion of the ruleset parameters
Generation of the ruleset execution trace
Monitoring and logging

When the XU is deployed as a Java EE resource adapter in an application server, the resources are managed by the application server.

When a Java SE rule session is used, the XU manages the resources by itself, and uses its own resource adapter container.

The application server or application client invokes the XU to execute rulesets with either the classic rule engine or the decision engine.

Rulesets for use with the classic rule engine and rulesets for use with the decision engine can share a single XU instance for their execution.

Resource management

The XU collaborates with the resource adapter container to manage resources.

Connection management

The capability of pooling connections is important to create a scalable application environment, particularly when large numbers of clients access the underlying rule engines. Each stateful rule session uses a dedicated XU connection, which can be reused. Each XU connection is associated to a dedicated rule engine and a ruleset. The rulesets are shared between XU connections. By default, the rulesets are removed from the cache when they are no longer referenced by a connection, and their maximum idle time is reached. The XU then has to read the ruleset from the persistence layer instead. The resource adapter container implements the connection pooling strategy and reuses, removes, or creates connections. For more information, see Managing the XU timeout policy.

Transaction management

A transaction is a set of operations that must be either committed all together or not committed at all to maintain data consistency and integrity.

The XU does not provide transaction management itself. However, it does not prevent the execution of a ruleset from registering a transaction resource into the transaction scope. Typically, database operations that are triggered by the execution of a ruleset can use transactions even if the XU does not support transactions.

Lifecycle management

The XU lifecycle is managed by the resource adapter container.

Work management

The XU uses the work manager that is provided by the resource adapter container. Therefore, the application server can pool threads efficiently and have more control over its runtime environment. The management plugin uses work instances for asynchronous execution and asynchronous parsing.

Packaging and deployment

The XU is a stand-alone deployable unit that is packaged as a resource adapter archive file (RAR) for all supported Java EE application servers. You can embed the XU RAR file into an EAR file, like any Java EE connector.

The path to the RAR file is <InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-xu-<version>.rar. For Java SE, a JAR file named jrules-res-execution.jar is provided in the <InstallDir>/executionserver/lib directory.

Note: To uncompress the XU RAR, use a ZIP tool.

XU capabilities

The XU retrieves rulesets and provides scalability.

Configuration management

You can modify the behavior of the XU by changing its configuration properties.

For Java EE sessions, the configuration properties of the XU are defined in the META-INF/ra.xml file of the .RAR artifact.

For Java SE sessions, you can change the configuration properties of the XU by API or by adding a configuration file in the application class path. Pass the XU configuration during the initialization of the session factory. You cannot change the configuration of the XU after the factory is initialized.

Context pooling

All cache entries are linked to the JCA pool. All the XU resources are managed indirectly by the application server. Each rule engine is linked to an Service Provider Interface (SPI) connection, which is cached by the application server in the JCA pool. A ruleset is shared and kept in memory until no JCA connection references it. At the end of an execution session, the server can put the SPI connection back into the JCA pool. In this case, the associated rule engine is reset and ready for another execution.

Rulesets and rule engines are not preloaded before the first execution. The application server pools the connections according to the characteristics of the pool, which are defined in the application-server specific descriptor or in the administration console. By default, the maximum size of the connection pool for Java SE is 10.

Restriction: You cannot change the size after you have set the initial value. You cannot change the maximum size of the connection pool after the XU starts.

Shared rulesets

A ruleset can be shared by several rule engines. Likewise, any number of rulesets can be shared by more than one application so long as the classes used in the rules are available to each application. All dynamic classes are attached to the ruleset and are therefore made available directly to the XU. All Java classes are passed to the XU by the rule session class loader, which is by default the application class loader.