Hi everyone, in the past I came several times across situations that required the one or other kind of Message Store. I noticed that in Camel this doesn't seem to be a "first class citizen" in the sense of a primary architectural concept, which can be applied consistently whereever needed.
In short, it might make sense to have a unified, generic, pluggable Message Store (probably more of an "Exchange store") in Camel that consolidates the different approaches and allows to similarly parameterize persistence to various EIP patterns, and can be used independently of EIP patterns as well. Implementations would handle the mapping to the underlying database or file system or NoSQL or whatever. It seems that Spring Integration provides something corresponding (http://static.springsource.org/spring-integration/reference/htmlsingle/#message-store). Message Store implementations are already used by Camel in various places, although using different approaches : * Stream Caching (only file system) * AggregationRepository (used for splitters, multicasts etc., but the interface is not specific at all to aggregation use cases) * IdempotentRepository Message Store is requested for in other places: * Reliable stream resequencing (CAMEL-949) * Persistent Dead Letter Queue (CAMEL-4575) And there might be other areas (seda, bam) that might benefit as well. Maybe generalizing the AggregationRepository is a way to go forward. Side note: The OeHF IPF platform (which is built on top of Camel and partly extends it to the health care domain) has something called a "Flow Manager" (http://www.openehealth.org/display/ipf2/Flow+management) that is used for tracking exchanges while they are processed or after processing is done, thereby being able to re-insert them into the route. Not that I consider this being a shining example, but it shows that message stores make sense outside their implicit use in EIP processors as well. Looking forward to your opinions! regards Christian
