How to use EJB3.0 to invoke a rule set running on Res

Rule Execution Server (RES) is a component of the IBM ODM product suite that manages and executes a ruleset in a distributed environment. RES can be deployed as a centralized service to respond to requests from multiple clients and execute multiple rule sets at the same time. It provides a variety of rule execution components that allow users to choose the right execution mode and integrate the business rule management system into http://www.aliyun.com/zixun/aggregation/13760.html "> Enterprise Applications." RES is based on a modular architecture that can be deployed and run as a set of Java SE POJO objects, and can be deployed and run on an application server that is fully compatible with Java EE, encapsulating the rule engine as a JCA resource adapter-an execution unit (XU) resource adapter. The JCA interaction between the application server and the rule engine is implemented by the XU resource adapter to manage the rule engine, load the rule set, and pass the calling parameters and execution results of the business rules between the business application and the rule engine.

Figure 1. RES Component Structure

RES supports the following execution modes:

Local invocation of non-jave EE containers: Business applications need to invoke jave se rule execution Component (<ODM product installation directory >/executionserver/lib/jrules-res-execution.jar), build Java SE Rule session to complete calls to the business rule set and to package the rule execution component Jrules-res-execution.jar and business applications together. Non-transactional local calls within the Jave EE container: Business applications need to invoke POJO Rule execution components (<ODM product installation directory >/executionserver/applicationservers/<appserver>/ Jrules-res-session-<appserver>.jar), establishes the POJO rule session to complete the call to the business rule set, and needs to execute the component Jrules-res-session-<appserver >.jar and business applications are packaged together to deploy the runtime and specify a JNDI mapping of rule execution components to XU at deployment time. Jave EE containers Local calls that support transaction control on internal rule sessions: Business applications need to invoke EJB Rule execution components (<ODM product installation directory >/executionserver/applicationservers/< Appserver>/jrules-res-session-ejb3-<appserver>.jar) to complete the call to the business rule set and to perform the component jrules-res-session- <appserver>.jar and business applications are packaged together to deploy the runtime and specify a JNDI mapping of rule execution components to XU at deployment time. In the next section, this article will give you a detailed description. Jave EE containers A remote invocation that supports transaction control on the internal rule session: Business applications need to invoke EJB Rule execution components (<ODM product installation directory >/executionserver/applicationservers/< Appserver>/jrules-res-session-ejb3-<appserver>.jar) to complete the call to the business rule set. In the next section, this article will give you a detailed description. Remote or local asynchronous calls within the Jave EE container: business shouldInvoke the message Driven MDB Rule Execution component (<ODM product installation directory >/executionserver/applicationservers/<appserver>/ Jrules-res-session-mdb-<appserver>.jar), the user needs to install and configure the MDB rule execution component on the Jave EE server running res jrules-res-session-mdb-< Appserver>.jar and specifies the JNDI mapping of the rule execution component to the XU at installation time. Web service based remote invocation: RES also supports the generation of a Web service based rule invocation service for rule sets, which enables users to invoke the rule set directly using HTTP Request by generating decision services for the rule set on the RES server side.

The execution of a business rule can also be divided into a session-state rule call and a rule call without session state, depending on the rule session state established by the rule Execution component invocation rule set:

Stateless rule session: The rule session does not hold any execution data and rule engine status in two consecutive rule executions. In a stateless rule session, a business application passes a rule set input parameter to the rule engine and returns the execution result to the business application in the form of a rule set output parameter. Stateless rule sessions usually do not directly modify the working memory area of the rule engine.

Stateful rule session: A Save Rule Engine state is executed for rules in the current rule session and provides direct access to the rule engine's working memory area. In stateful rule sessions, business applications can either transfer business objects through the rule set parameters with the rule engine, or directly access the working memory area of the rule engine and insert or extract business objects into the working memory area.