diff --git a/docs/src/reference/docbook/claim-check.xml b/docs/src/reference/docbook/claim-check.xml index 67d6da2174..026e2a38fe 100644 --- a/docs/src/reference/docbook/claim-check.xml +++ b/docs/src/reference/docbook/claim-check.xml @@ -5,7 +5,81 @@
Introduction + + In the earlier sections we've covered several Content Enricher type components that helps you deal with situations where a + message is missing a piece of data. We also discussed Content Filtering which lets you remove uninteresting data items from a message. + However there are times when we want to remove some data temporarily. For example; In a distributed system we may receive a + Message with a very large payload. Some intermittent message processing steps may not need access to this payload and some may only + need to access parts of the payload so carrying the large Message through each processing step may cause performance degradation + and makes debugging harder. + + + Claim Check pattern describes mechanism that allows you + to store data in a well known place while only maintaining a pointer (Claim Check) to where that data is and pass such + pointer around as a payload of a new Message allowing any component within the message flow to get the actual data as soon as + it needs it. This approach is very similar to the Certified Mail process where you'll get Claim Check in your mailbox and + would have to go to the Post Office to claim your actual package or mail. + + + + Spring Integration provides two types of Claim Check transformers - Incoming Claim Check Transformer and + Outgoing Claim Check Transformer as well as convenient namespace-based mechanism to configure them. + + +
+ Incoming Claim Check Transformer + + + Incoming Claim Check Transformer - will transform incoming Message by storing it in the Message Store + identified by message-store attribute. + + ]]> + + In the above configuration the Message that is received on the input-channel will be persisted to the + Message Store identified with message-store attribute and indexed with generated ID. That ID is the Claim Check for that Message. + This Claim Check will also become the payload of the new (transformed) Message that will be sent to the output-channel. + + + + Now, lets assume that at some point you do need access to the actual Message. You can of course access the Message Store + manually and get the contents of the Message or you can use the same approach as before except now you will be transforming + the Claim Check to the actual Message by using Outgoing Claim Check Transformer. + +
+ +
+ Outgoing Claim Check Transformer + + + Incoming Claim Check Transformer allows you to transform a Message from the Message with just a Claim Check + to the Message with the original content. + ]]> + + In the above configuration the Message that is received on the input-channel has a Claim Check as a payload + and Outgoing Claim Check Transformer will transform it into an original Message by simply querying the + Message store for a Message identified by a Claim Check provided and sending the new Message to the output-channel. + +
+ + Although we rarely care about the protocol of the claim checks as long as they work, but it is still worth knowing that current + implementation of the actual Claim Check (the pointer) in Spring Integration is UUID to ensure uniqueness. + + + + A word on Message Store + + + org.springframework.integration.store.MessageStore is a strategy interface for storing and retrieving messages. + Spring Integration provides two convenient implementations of it. SimpleMessageStore - In memory Map-based + implementation (default, good for testing) and JdbcMessageStore - Implementation of MessageStore + that uses relational database via JDBC. +