On Wed, Oct 24, 2012 at 8:46 AM, Bengt Rodehav <[email protected]> wrote: > I think this is an excellent idea. We're using Camel as the basis for our > integration platform and a message store is a mandatory component. We need: > > - To store all message traffic in order to have an audit trail. Both > successful and failed exchanges. > - To provide a certain level of manual retry. That is to get the original > message from the store and feed it back in the originating route. > - Flexibility to specify what should be stored (e g what exchange- and > message properties) and also filter what exchanges should be stored. > > Currently we have implemented our own message store but it requires us to > adapt the routes to make this happen. A more generic way of handling this > would be terrific. >
The Message History EIP is scheduled for overhaul/improvement in Camel 3.0. And in this light we will look at a message store API as well. > /Bengt > > 2012/10/24 Willem jiang <[email protected]> > >> There is a lots of way to implement to Message store. >> Option1. If we treat is a first class of Camel, we could build up a set of >> API to let aggregator or tracer to use. As it is common usage that we need >> to store the exchange persistently, It make sense to provides such kind of >> API in Camel as a first class. +1 to provide this kind of API in Camel 3.x. >> >> Option2. We can also leverage the already exits camel components such as >> polling consumer or camel-JPA components to implement a such Message store. >> I think IPF shows us a good way to go. In this way we don't need to wait >> for the New API from Camel, it could be good solution for Camel 2.x. >> >> Maybe it is a good time for us to think about Camel 3.0 again. >> >> Any thoughts? >> >> Willem >> >> -- >> Willem Jiang >> >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Web: http://www.fusesource.com | http://www.redhat.com >> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) >> (English) >> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) >> Twitter: willemjiang >> Weibo: willemjiang >> >> >> >> >> >> On Wednesday, October 24, 2012 at 9:43 AM, Hadrian Zbarcea wrote: >> >> > Hi Christian, >> > >> > You are correct about the fact that a Message Store is missing (kinda). >> > There are a few components that support a message store implementation >> > of sorts, as you mentioned. You are also correct that it should be a >> > first class citizen. >> > >> > Practically, an endpoint that supports a polling consumer is a message >> > store. What is actually missing is random access via a polling consumer. >> > A message store would then work atop any endpoint that supports random >> > retrieval (polling). That would create the opportunity to cleanup a bit >> > the pollEnrich implementation as well. >> > >> > My $0.02, >> > Hadrian >> > >> > >> > On 10/23/2012 07:18 AM, Christian Ohr wrote: >> > > 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 >> > >> >> >> >> -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
