Execution and management stacks
The execution, management, and monitoring stacks are similar for Java™ SE and Jakarta EE but the packaging and lookup mechanisms differ.
- Java SE and Jakarta EE runtime environments
- Java SE and Jakarta EE management environments
- Client development and deployment cycles
The following figure shows the execution stack and the management and monitoring stacks. They are similar for Java SE and Jakarta EE.

However, the Java SE and Jakarta EE stacks differ in the packaging and lookup mechanisms.
Because Rule Execution Server is supported in Java SE, developers can use rule sessions to execute ruleset archives outside an application server. Developers can also deploy RuleApps directly to the JDBC-compliant database or file system by running either a res-write Ant task or in the Rule Execution Server console. For details about the rule session API, see ilog.rules.res.session.
The certified web container to run the management stack in Java SE is Tomcat. Tomcat provides the minimum set of facilities to handle the stack: JMX, JNDI, and JDBC data source handling. You can also deploy the management stack on a Jakarta EE application server. With the management stack, users can both rely on the infrastructure for storing and deploying ruleset archives and execute rules in a pure Java SE environment.
Rule execution tests over the Rule Execution Server console run through the execution unit (XU) directly.
The following table shows the Java SE or Jakarta EE modes of the deployed stacks.
| Mode | Execution Stack | Management Stack |
|---|---|---|
| Java SE | Use classpath-executionserver.xml and classpath-engine.xml to set the JAR files for Java SE execution. | Non applicable |
Use the res-write Ant task to deploy rulesets. Use the res-write-xom Ant task to deploy Java XOM resources |
||
| Java SE with management support | Use classpath-executionserver.xml and classpath-engine.xml to set the JAR files for Java SE execution. Optional deployment of jrules-ssp-<appserver>.ear and jrules-res-htds<platform>.ear. For Tomcat:DecisionService.war |
jrules-res-management<platform>.war. For Tomcat:res.war. |
| In this configuration, no execution statistics are available
and, by default, no hot ruleset update. You can flush the connection pool by calling the
IlrManagementSession#invalidate(ilog.rules.res.model.IlrPath) method on the ruleset. Restriction: Do not use the res-write Ant task because it might
desynchronize the Rule Execution Server
console from changes to the data source.
If you activate the TCP/IP management mode of the Rule Execution Server console, you can monitor execution unit (XU) instances that are not running in the same Java virtual machine (JVM) as the console. |
||
| Java SE with management and monitoring support | Use classpath-executionserver.xml and classpath-engine.xml to set the JAR files for Java SE execution. Package the execution stack as a web application. Optional deployment of jrules-ssp-<appserver>.ear and jrules-res-htds<platform>.ear. For Tomcat:DecisionService.war |
jrules-res-management<platform>.war (res.war for Tomcat) in the same JVM. |
| Full management capabilities. | ||
| Jakarta EE application-scoped | jrules-res-xu-<platform>.rar packaged inside an EAR file. Optional deployment of jrules-ssp-<appserver>.ear and jrules-res-htds<platform>.ear (DecisionService.war for Tomcat). |
One management EAR on a Jakarta EE application server. |
In this configuration, Rule Execution Server is limited to the application in which it is packaged. When you
use such embedded deployment, bear in mind the following points:
|
||
| Jakarta EE server-scoped | jrules-res-xu-<platform>.rar deployed on an application server. Optional deployment of jrules-ssp-<appserver>.ear and jrules-res-htds<platform>.ear. (DecisionService.war for Tomcat) |
One management EAR on a Jakarta EE application server. |
| Full management capabilities. |