]
Daniel Bevenius closed JBESB-644.
---------------------------------
Resolution: Done
Checked into trunk with revision : 20696
Add support for both stateless and stateful RuleServices
--------------------------------------------------------
Key: JBESB-644
URL:
http://jira.jboss.com/jira/browse/JBESB-644
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Content Based Routing
Reporter: Jeff DeLong
Assigned To: Daniel Bevenius
Fix For: 4.4
The current JBossRuleRouter (which currently implements the RuleService) uses
StatefulSessions in a Stateless way. Which is fine in most cases). JBossRulesRouter
creates a new workingMemory (StatefulSession), asserts facts, and should (although it does
not currently, disponse of the workingMemory - See also JBESB-642. ).
JBoss Rules support StatelessSessions. The need to dispose of workingMemory is eliminated
if StatelessSessions are used. StatelessSession have some limitations compared to
Stateful, but are designed for instance, for rule applications deployed as web services,
where basically a single method needs to transfer all the data, create the workingMemory,
assert the data (as a single object or list of objects) and fire the rules. CBR can be
thought of as a stateless service. A single Message object is asserted into working
memory, and the rules are fired. Many rule application will be like this.
However, some rule applications are truly stateful. For example, the rules accumulated
facts with specific attribute values over time and then fired when a certain number was
reached. These types of services would require that the workingMemory not be re-created
with the receipt of each message, and disposed of after the rules have fired, but have a
long-lived working memory that gets added to over time. The current JBossRulesRouter
cannot support truly stateful services because it creates a new workingMemory with each
message. Truly stateful interactions would require a way to identify the stateful session
/ working memory that a message is for, and also when to finally dispose of it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: