Execution Unit (XU)

SPI system-level contracts

By plugging into an application server, the XU collaborates with the server to provide the following connector system-level contracts. Together, these contracts form a Service Provider Interface (SPI).

Connection management contract

The capability of pooling connections is important to create a scalable application environment, particularly when large numbers of clients access the underlying rule engine. This contract enables application servers to pool connections to an underlying rule engine and application components to connect to the rule engine.

Transaction management contract

This contract links the XU and the transaction manager of the application server. 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 supports only local transactions. An application server can thus manage only resources that are local to the XU. A local transaction involves only one non-XA resource and requires that all participating application components execute within one process. Local transaction optimization is specific to the resource manager and does not affect the Java EE application. In other words, simple rule sessions have no transaction boundary of their own and therefore do not define a new context for the XU transaction. As a consequence, the calling transaction can use only the XU local transaction resource.

Note:

Transaction management is not provided for the server ports supported by JRules V7. For more information, see the transaction.support attribute in res-setup.

Security contract

This contract is established by the Rule Execution Server execution components. It provides secure access to the XU to protect its resources.

JCA system-level contracts

The Java EE Connector Architecture (JCA) defines the following set of system-level contracts:

Transaction Inflow contract

Using a Transaction Inflow contract, resource adapters propagate imported transactions to an application server.

Lifecycle Management contract

Using a Lifecycle Management contract, application servers manage the lifecycle of a resource adapter.

Work Management contract

Using a Work Management contract, resource adapters can operate and an application server can pool threads efficiently and have more control over its runtime environment. Based on this contract, the XU supports asynchronous execution and asynchronous parsing.

For more information about Java EE Connector Architecture, see the Java EE Connector Architecture download page and The J2EE Connector Architecture's Resource Adapter article.

XU capabilities

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. The RAR file contains the XU and the persistence layer. You can embed the XU RAR file into an EAR file, like any Java EE connector.

The XU reads the ruleset from the persistence layer whenever the application server removes a cache entry from the JCA connection pool. The application server administrator can force the server to flush the pool or the server can choose to remove pool entries, based on resource constraints.

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.

The XU retrieves rulesets and provides scalability through the following capabilities:

Global management

The XU provides an application server standard and global resource management.

Context pooling

All cache entries are linked to the JCA pool. All the XU resources are managed indirectly by the application server. Each instance of IlrContext is linked to an SPI connection, which is cached by the application server (the JCA pool). IlrRuleset objects are shared and kept in memory until no more IlrContext objects are based on it. At the end of an execution session, the server can decide to put the SPI connection back into the JCA pool. In this case, the associated IlrContext object is reset and ready for another execution.

IlrRuleset and IlrContext objects 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 through the administration console. By default, the maximal 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 up.

Shared rulesets

A common ruleset is shared by several rule engines. Likewise, any number of rulesets are shared from any application so long as the classes used in the rules are available. 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.

You can modify the behavior of the Execution Unit by setting configuration properties. See Setting the XU configuration property.

You can also retrieve the XU memory usage for a specific ruleset. See Retrieving the XU memory usage.