[CONF] Apache Camel > Camel 3.0 - Message Store

[confluence]

Camel 3.0 - Message Store Page edited by Christian Ohr Changes (5) ... h3. Summary ... In Camel 2.x a *Message Store* is not a "first class citizen" in the sense of a primary architectural concept, which can be applied consistently whereever needed. Camel 3.0 should introduce a unified, generic, pluggable Message Store that consolidates the different approaches and allows to similarly parameterize persistence to various EIP patterns. It should be usable independently of EIP patterns as well. Implementations would handle the mapping to the underlying persistence layer, which can be InMemory, RDBMS, NoSQL-based etc. Side note: Spring Integration provides a [corresponding concept|http://static.springsource.org/spring-integration/reference/htmlsingle/#message-store]. h3. List of proposed features {note:title=Work in progress} At some time we probably need to assign priorities as to what is indispensable for Camel 3.0 and what could be delivered in a later patch release {note} * Ability to temporarily store exchanges for the following EIPs: ** Aggregator, Multicast, RecipientList, Splitter : alternative to AggregationRepository, making it eventually obsolete ... * Flexibility to specify what should be stored (e.g. what exchange- and message properties) and in which format (e.g. object serialization, JSON) * Possibility to filter what exchanges should be stored (using a predicate) * Polling Consumer to randomly access a message store * Producer ... Full Content Work in progress The page intends to collect all ideas and proposals around the idea of a Message Store as a architectural concept in Camel. No implementation has started yet. You can participate by sharing your input here or post it to the dev mailing list. For the initial brainstorming on the dev mailing list, please check this thread. From the Camel 3.0 ideas page (+1: hadrian, claus) We should make this EIP easier to use for end users, but offering a better public API. And also have a pluggable message store, with filters that can filter what should be stored. As well pluggable marshallers so people can marshal data from Exchange into a format the message store can store (BLOB, XML, JSon etc.). A Message Store could provide transparent persistence to various EIP patterns (or used directly). Implementations would handle the mapping to the underlying database or file system or NoSQL or memory or whatever. Message Store implementations are already there in various places, using different approaches, like in Stream Caching (only file system), AggregationRepository or IdempotentRepository. A Message Store is requested for in other places like Reliable stream resequencing (CAMEL-949) or Persistent Dead Letter Queue (CAMEL-4575). Summary In Camel 2.x a Message Store is not a "first class citizen" in the sense of a primary architectural concept, which can be applied consistently whereever needed. Camel 3.0 should introduce a unified, generic, pluggable Message Store that consolidates the different approaches and allows to similarly parameterize persistence to various EIP patterns. It should be usable independently of EIP patterns as well. Implementations would handle the mapping to the underlying persistence layer, which can be InMemory, RDBMS, NoSQL-based etc. Side note: Spring Integration provides a corresponding concept. List of proposed features Work in progress At some time we probably need to assign priorities as to what is indispensable for Camel 3.0 and what could be delivered in a later patch release Ability to temporarily store exchanges for the following EIPs: Aggregator, Multicast, RecipientList, Splitter : alternative to AggregationRepository, making it eventually obsolete Streaming Resequencer (CAMEL-949) Stream Caching Ability to store exchanges for a defined period of time Idempotent Consumer Dead Letter Queue (CAMEL-4575) Ability to permanently store exchanges (e.g. for audit trails) 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 in which format (e.g. object serialization, JSON) Possibility to filter what exchanges should be stored (using a predicate) Polling Consumer to randomly access a message store Producer Examples Change Notification Preferences View Online | View Changes | Add Comment