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
