Deployment architecture
To manage the rule execution environment, you package rulesets into RuleApps and you make the XOM accessible to the rule engine.
If you need simultaneous execution of several rulesets, automatic ruleset updates, or transaction management, you must use a managed rule execution environment.
Rule Execution Server is the module for executing rules in a managed environment. You can deploy Rule Execution Server as a centralized service that runs multiple rulesets on the requests of multiple clients. It provides various execution components for developers to integrate rule execution into enterprise applications.
Rule Execution Server is based on a modular architecture that can be deployed and run as a set of Java™ SE-compliant Plain Old Java Objects (POJO) or within a fully Jakarta EE-compliant application server. It provides web-based management through JMX tools, logging, and debugging integration. It packages the rule engine as a Jakarta EE Connector Architecture (JCA) resource adapter. The execution unit (XU) resource adapter implements JCA interactions between the application server and the rule engine.
Choosing the right architecture for managed execution
When choosing the right architecture for managed rule execution, you must decide whether you run rules on Java SE, on an application server, or as a web service. When defining the software architecture of your application and fitting rule execution into this architecture, you must make some trade-offs. The following table provides some examples:
| Problem | Solution |
|---|---|
| To avoid frequent network usage during rule execution | Instantiate the engine close to the data that it is processing, in as many nodes of the software architecture as you can. |
| To deploy the same decision to more than one application | Take benefit of the independence of transparent decision services and use an architecture that is based on a centralized Service-Oriented Architecture (SOA). |
| For batch processing and guaranteed delivery | Use POJO or JSE. |
| For scalable online transaction systems | Use a clustered Rule Execution Server and remote rule session EJBs for load balancing. |
The following figure shows the architecture of a managed application.
Decision Server supports several third-party Business Process Management (BPM) systems and SOA development tools. For more information, go to the IBM® support pages.
Managing execution in Java SE
When you run a ruleset in Java SE, you develop an execution component that handles Java SE requests between the application and Rule Execution Server. If your application and Rule Execution Server console do not run on the same Java virtual machine (JVM), you must use the TCP/IP management mode of the console to manage execution unit instances.
The following figure shows how a ruleset is run in Java SE.
For web-based applications, it is better to have the rule engine in the same JVM as the servlet container to help minimize the need for expensive object serialization between the JVM that hosts the servlet container and the JVM that hosts the rule engine.
Managing execution in an application server (Jakarta EE)
When you run a ruleset in Java EE, you can use a POJO rule session.
The following figure shows how to run a ruleset in Jakarta EE.
Synchronous calls to a decision service from a local client use the POJOs. POJOs are useful for their simpler packaging and deployment.
- The number of request threads
- The size of JCA pools
- The use of native input/output or pure Java input/output
- The pool reclamation policy
- The data replication strategy for clustered deployments
If your application and Rule Execution Server console do not run on the same application server or cluster, you must use the TCP/IP management mode of the console to manage all of the Execution Units (XU).
See the documentation of your application server for specific information related to your environment.
Executing rulesets as a web service
When you expose a ruleset as a web service, your application is typically remote. Requests to Rule Execution Server are carried by the HTTP protocol. You develop a transparent decision service to handle requests between the application and Rule Execution Server. Rule Designer provides tools for generating transparent decision services.
The following figure shows a transparent decision service environment.
You can implement the servlet with a hosted transparent decision service (HTDS) provided by Decision Server.
- Controlling access to the implementation rules for a service.
- Providing an audit trail for all implementation changes.
- Reporting at the business level.
- Monitoring rulesets at run time if they implement a transparent decision service.