Managed Java XOM setup and lifecycle

To enable Rule Execution Server services on rulesets that are based on a Java™ execution object model (XOM), you can set up Java XOM management.

When a rule project is based on a Java execution object model (XOM), you can deploy the Java XOM resources and libraries that are attached to a ruleset.

Java XOM management adds the ruleset.managedxom.uris property. This property attaches Java XOM resources and libraries to a ruleset. The value of the ruleset.managedxom.uris ruleset property is a comma-separated list of URIs to JAR or ZIP files. Each URI must target a JAR or ZIP archive of classes and resources for the Java execution. Only URIs that use the resuri or reslib protocol are supported. For example, resuri://common-classes.jar/1.0,resuri://LoanValidation.jar.

The following diagram illustrates Java XOM management setup and usage:

After the ruleset.managedxom.uris property has been defined, you can deploy a XOM from Rule Designer, from the Rule Execution Server console, or by writing specific Ant tasks. You can also use the console and Ant tasks to manage the resulting resources and libraries.
Then, all the execution components can use the Java XOM and the execution of rulesets can be tested in the console.

Overview of the Managed Java XOM feature: how to use it and how to manage it

Runtime class loading

By default, rulesets get their Java XOM from the class loader of the client application. However, when you enable Java XOM management, the execution unit (XU) declares a new class loader to load the Java XOM resources for the ruleset. After this class loader is created, the ClassLoading event is logged to the log file at the INFO level. The resulting message informs you when the class loader of the client loads its classes (first or last). The message includes the list of loaded libraries and resources that are defined in the ruleset property. An example of this message is shown here:

\- /MyRuleApp/1.0/MyRuleset/1.0
   \- reslib://MyLibrary => reslib://MyLibrary/3.0
      +- reslib://Library1/1.0
      |   \- resuri://xom1.jar => resuri://xom1.jar/1.0
      \- reslib://Library2/1.0
         +- resuri://xom2.jar/1.0
         +- resuri://xom3.jar => resuri://xom3.jar/1.0
         +- resuri://xom4.jar/1.0
         \- resuri://xom5.jar/1.0

While the class loader is created for the managed XOM, the client class loader is used as the parent class loader for the newly created class loader. As a consequence, any identical class that is identified by the same package and same name and is present in both class loaders is taken into the client class loader first. You cannot reverse this behavior.

Lifecycle

Here is the process:

As a developer, after you create the Java XOM model and the rule project, and before the first synchronization to Decision Center, you must deploy the Java XOM to the persistence layer of the targeted Rule Execution Server instance, which manages the persistence layer of the execution units (XU). For decision services, set the Deploy the XOM option to Yes on the Overview tab of the deployment configuration. Then, click the Proceed to RuleApp deployment link or click the Proceed to RuleApp deployment button ().
Then, you can synchronize the rule project with Decision Center. After this synchronization, the business analysts can take over.
If you modify the Java XOM model, you must deploy the XOM to Rule Execution Server again and then synchronize it again with Decision Center.
Typically, these actions are not apparent to the business analyst, who might not be aware that a Java XOM is attached to the rule project: testing and simulation actions or ruleset deployment to the Rule Execution Server instance transparently binds the correct Java XOM.

Important: Use the same URL address to deploy the Java XOM to the targeted Rule Execution Server instance and in Decision Center. For example, do not use http://localhost:9080/res in Rule Execution Server and http://127.0.0.1:9080/res in Decision Center.

Persistence layer

You can store rulesets that have a managed Java XOM to the file system or to a database. You can store the managed Java XOM independently of the ruleset. As a consequence, you can work locally if your JAR files are too large for you to work from a database in a test environment.