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. It runs on a J2EE application server. Rule Execution Server can be deployed as a centralized service, executing multiple rulesets on the requests of multiple clients. It provides a variety of execution components to allow developers to easily integrate rule execution into enterprise applications.

Rule Execution Server is based around a modular architecture that can be deployed as a set of J2SE compliant Plain Old Java Objects (POJOs), hosted using Apache Tomcat, or run within a full J2EE compliant application server. It provides Web-based management, management through JMX tools, logging, and debugging integration.

Rule Execution Server provides a packaging of the rule engine as a Java Connector Architecture (J2C) resource adapter. The Execution Unit (XU) resource adapter implements the J2C interactions between the application server and the rule engine.

Packaging Rulesets for Deployment

In order to be deployed, rulesets need to be packaged into RuleApps. A RuleApp is a deployable management unit. It can contain one or more rulesets. Each ruleset in a RuleApp can be invoked using a ruleset path. The ruleset path is the entry point for clients to access the business logic encapsulated in a RuleApp.

In Rule Studio, you create a RuleApp project to specify the rulesets contained in a RuleApp.

You can also create RuleApps using the Rule Execution Server Console, Rule Team Server, or an Ant task.

Managing Rule Engines and Rulesets

In a managed rule execution environment, rule engines are made available by an Execution Unit (XU). The XU is a resource adapter that manages rule engines and loads rulesets, and passes data between the application and the rule engine. The XU creates several rule engine instances and pools them.

The XU handles the low-level details of ruleset execution, such as pooling or multithreaded processing. It also provides management access to its resources and manages hot deployment, that is, it receives notification of new versions of the ruleset in the RuleApp storage (persistence layer). Rule Execution Server includes an implementation of the XU that can be used in any J2SE-compliant JVM.

Making the XOM Accessible to the Rule Engine

The XOM is deployed to the enterprise application and made accessible to the rule engine. The way the rule engine accesses the XOM is different depending on whether it is a Java XOM or an XML XOM. If your XOM is based on Java classes, you package it into your application and deploy it along with the application. At runtime, your application classloader makes the XOM objects available to the rule execution environment. If your XOM is based on XML Schema, you deploy the XSD or WSDL to your client application. The XML Schema also packaged into the ruleset archive and therefore deployed with the RuleApp.

Choosing the Right Architecture for Managed Execution

While choosing the right architecture for managed rule execution, you decide whether you execute rules on J2SE, on an application server, or as a Web service. When defining the software architecture of your application, and fitting rule execution in this architecture, you will need to make some trade-offs.

For example, to avoid frequent network usage during rule execution, you may want to instantiate the engine close to the data it is processing, in as many nodes of the software architecture as you can. You may also want to exploit the independence of decision services and use an architecture based on a centralized Service-Oriented Architecture (SOA), in which case you need to make a trade-off between manageability and performance.

You can choose from a wide variety of integration schemes to deploy JRules. The implementation of the business service is embodied in the business rules for the service, allowing you to deploy the same decision service as a Plain Old Java Object (POJO) within one application and as a J2EE Java Message Service (JMS) message-driven bean (MDB) within another application.

Deploying Rulesets to a J2SE Environment

When you deploy a ruleset to a J2SE environment, your application and Rule Execution Server must run on the same JVM. You develop an execution component that handles J2SE requests between the application and Rule Execution Server.

For applications that are Web-based it is better to have the rule engine in the same JVM as the Servlet container. This sometimes minimizes the need for expensive object serialization between the JVM hosting the Servlet container and the JVM hosting the rule engine.

Deploying Rulesets to an Application Server (J2EE)

When you deploy a ruleset to an application server, the application can be remote, in which case you use an EJB or MBD rule session to handle requests between the application and Rule Execution Server. If you application is local, you use a POJO rule session or use the local interface to an EJB.

Synchronous invocation of a decision service from a remote client can be accomplished using the stateful or stateless EJB. Synchronous invocation of a decision service from a local client can be accomplished using the local interfaces of the stateful or stateless EJB, or using the POJOs. EJBs are useful for their remote client access capabilities as well as support for declarative transaction and security descriptors. POJOs are useful for their simpler packaging and deployment, and for use outside the EJB container.

Applications that require asynchronous invocations of decision services may use the Message-Driven Bean (MDB), which provides a scalable means to invoke rulesets where high-latency or high peak-load is expected.

In general, you must tune the J2EE application server for the deployed application and the expected peak or average load. This includes settings like:

Refer to the documentation of your application server for specific information related to your environment.

Deploying Rulesets as a Web Service

When you deploy a ruleset as a Web service, your application is typically remote and requests to Rule Execution Server are done through HTTP. You develop a transparent decision service to handle requests between the application and Rule Execution Server. JRules provides tools for generating transparent decision services.

JRules provides tools that can help with key SOA governance challenges, such as controlling access to the implementation rules for a service, providing an audit trail for all implementation changes, business level reporting, as well as runtime monitoring of the rulesets that implement a transparent decision service.

Related Concepts

Related Tasks