[rules-users] Minimizing Drools Flow Persistence when choreographing services

[rg64]

I am considering using Drools Flow to choreograph services in an automated
processing system I am building. The proposed Drools Flow-based
"choreography service" as well as most of the other services in the
environment consume requests from transactional JMS queues. In this
architecture, I would like to reduce Drools Flow persistence-related i/o by
embedding session-state in the JMS messages whenever possible instead of
writing it to the persistent store.

My current thought is to use Apache Camel to implement a custom, async
WorkItemHandler that would somehow override the default RDBMS-based
persistence operations and instead marshal and unmarshal the process info
state to/from the transactional JMS message alongside with the rest of the
payload. Other Drools Flow wait states, such as joins, human tasks, etc.
which are encountered much less frequently in our environment would ideally
continue to use the traditional RDBMS-based persistence mechanism.

What are your thoughts about this approach? Is it reasonable? Do hooks exist
that allow the persistence mechanism to be conditionally overridden
depending on the type of wait state?

BTW, since you have already integrated Apache Camel with the Drools engine
itself, would it make sense to provide an out-of-the-box Apache Camel
WorkItemHandler to tighten the integration of Apache Camel with the Drools
Flow module? If the community is interested and I move forward with this
approach, I might consider contributing an Apache Camel WorkItemHandler.

Thanks in advance,

/Ron 
-- 
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Minimizing-Drools-Flow-Persistence-when-choreographing-services-tp1410791p1410791.html
Sent from the Drools - User mailing list archive at Nabble.com.