Rule Execution Server supports synchronous execution patterns and asynchronous messaging through the Java™ Message Service 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 (<InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-<appserver>.jar) that are used to reference the XU.
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 (<InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-ejb3-<appserver>.jar) that are used to reference the XU.
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 (<InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-ejb3-<appserver>.jar) that are used to reference the XU.
Asynchronous calls (remote or local): Use a message-driven rule bean (MDB).
A client module must embed the execution components (<InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-mdb-<appserver>.jar) that are used to reference the XU.
Stateless asynchronous execution, in Java SE and in Java EE POJO modes only.
A client module must embed the execution components (<InstallDir>/executionserver/applicationservers/<appserver>/jrules-res-session-<appserver>.jar) that are used to reference the XU.
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, then add them to the working memory 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 can 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 using the IlrContext API inside IRL.
Asynchronous messaging using the Java Message Service API
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.
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 using a JMS queue or topic:
The following figure shows how to get output parameters using a JMS queue or topic:
Using the JMS API, you can choose between various implementation of messaging systems. Because the API supplies a Publish-and-Subscribe Model as well as 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 actually synchronous or asynchronous.