Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 209.85.161.173 as permitted sender)
Message-ID: <508747C4.10008@gmail.com>
Date: Tue, 23 Oct 2012 21:43:32 -0400
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Message Store
References: 
 <CAEhQ+88+B-7Tmq7SAD0XUzmzTRXAFPVOCwfQHr62NiY170su8g@mail.gmail.com>
In-Reply-To: 
 <CAEhQ+88+B-7Tmq7SAD0XUzmzTRXAFPVOCwfQHr62NiY170su8g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>