Execution patterns

Rule Execution Server supports synchronous execution patterns and asynchronous messaging through the Java™ Message Service (JMS) API.

Synchronous execution patterns include stateless and stateful rule sessions. If you use a message listener, you can set up asynchronous messaging.

Rule Execution Server supports the following execution patterns:
  • Local access outside a Java EE container: Use Java SE rule sessions and package the <InstallDir>/executionserver/lib/jrules-res-execution.jar file inside your application.
  • Local access, with or without transaction control: Use Plain Old Java Objects (POJO).

    A client module must embed the execution components that are used to reference the XU: <InstallDir>/executionserver/lib/jrules-res-session-java.jar

  • Local access with transaction control at the rule session level: Use the local interface of a stateful or stateless EJB rule session.

    A client module must embed the execution components that are used to reference the XU: <InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-ejb3-<appserver>.jar

  • Remote access with transaction control at the rule session level: Use the remote interface of a stateful or stateless EJB rule session.

    A client module must embed the execution components that are used to reference the XU: <InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-ejb3-<appserver>.jar

  • Asynchronous calls (remote or local): Use a message-driven rule bean (MDB).

    A client module must embed the execution components that are used to reference the XU: <InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-mdb-<appserver>.jar

Synchronous execution patterns

Synchronous patterns of execution behave differently in stateless rule sessions and stateful rule sessions. See Rule sessions for details.

Stateless rule sessions

With stateless rule sessions, you can set input (in) parameters and get output (out) parameters. See IlrStatelessSession.

A stateless rule session can pass objects as input parameters, and then add them to the working memory by using a rule task initial action. Likewise, a stateless rule session can retrieve objects from the working memory in a final action and pass them as output parameters. At the end of the execution, the content of the working memory might be modified.

Stateful rule sessions

With stateful rule sessions, you can set input (in) parameters, get output (out) parameters, and access the working memory. See IlrStatefulSession.

You can change the state of a Java SE, POJO, or EJB component by inserting and updating objects in the working memory or retracting objects from it. To do so, you have to work with stateful sessions.
Note: You can also set parameter values and update the working memory by using the IlrContext API inside IRL.

Asynchronous messaging by using the Java Message Service API

By using session beans, you can send and receive Java Message Service (JMS) messages synchronously, but not asynchronously. To receive messages asynchronously, use a message listener. A message-driven bean is an example of a message listener.

Note: A message-driven rule bean is not stateful and there is no public API on the client side.

From a requester’s point of view, asynchronous messaging means that one process or thread sends a message to a destination and expects no reply.

From a consumer’s point of view, asynchronous messaging means to receive a message and not send a reply immediately to the sender. The sender can rely on features such as guaranteed delivery to make sure that the message arrives.

The following figure shows how to set input parameters by using a JMS queue or topic:

Shows how to set input parameters by using a JMS queue or topic

The following figure shows how to get output parameters by using a JMS queue or topic:

Shows how to get output parameters using a JMS queue or topic

By using the JMS API, you can choose between various implementations of messaging systems. Because the API supplies both a Publish-and-Subscribe Model and a Point-to-Point Model, vendors now usually implement both standards. Because both standards are available, it is easier for you to implement the best messaging solution for your case. This choice is essential because it is not always obvious to distinguish what is synchronous or asynchronous.