diff --git a/docs/src/reference/docbook/claim-check.xml b/docs/src/reference/docbook/claim-check.xml index 026e2a38fe..585d65249c 100644 --- a/docs/src/reference/docbook/claim-check.xml +++ b/docs/src/reference/docbook/claim-check.xml @@ -6,48 +6,50 @@
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 + In the earlier sections we've covered several Content Enricher type components that help you deal with situations where a + message is missing a piece of data. We also discussed Content Filtering which lets you remove data items from a message. + However there are times when we want to hide 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. + need to access certain headers, so carrying the large Message payload through each processing step may cause performance degradation, + may produce a security risk, and may make debugging more difficult. - 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. + The Claim Check pattern describes a mechanism that allows you + to store data in a well known place while only maintaining a pointer (Claim Check) to where that data is located. You can pass that + pointer around as a payload of a new Message thereby 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 a Claim Check in your mailbox and + would have to go to the Post Office to claim your actual package. Of course it's also the same idea as baggage-claim on a flight + or in a hotel. - + - 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. + Spring Integration provides two types of Claim Check transformers: Incoming Claim Check Transformer and + Outgoing Claim Check Transformer. Convenient namespace-based mechanisms are available 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. + An Incoming Claim Check Transformer will transform an incoming Message by storing it in the Message Store + identified by its message-store attribute. ]]> + input-channel="checkinChannel" + message-store="testMessageStore" + output-channel="output"/>]]> 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. + Message Store identified with the message-store attribute and indexed with generated ID. That ID is the + Claim Check for that Message. + The 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. + 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 an Outgoing Claim Check Transformer.
@@ -55,20 +57,22 @@ 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. + An Outgoing Claim Check Transformer allows you to transform a Message with a Claim Check payload + into a Message with the original content as its payload. ]]> + input-channel="checkoutChannel" + message-store="testMessageStore" + output-channel="output"/>]]> - 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. + In the above configuration, the Message that is received on the input-channel should have a Claim Check as its payload + and the Outgoing Claim Check Transformer will transform it into a Message with the original payload by simply + querying the Message store for a Message identified by the provided Claim Check. It then sends the newly checked-out 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. + Although we rarely care about the details of the claim checks as long as they work, it is still worth knowing that + the current implementation of the actual Claim Check (the pointer) in Spring Integration is a UUID to ensure uniqueness. @@ -76,9 +80,9 @@ 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. + Spring Integration provides two convenient implementations of it. SimpleMessageStore: an in-memory, Map-based + implementation (the default, good for testing) and JdbcMessageStore: an implementation that uses a relational + database via JDBC.