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-Flo... Sent from the Drools - User mailing list archive at Nabble.com.