INT-1552 doc polishing

This commit is contained in:
Mark Fisher
2010-11-22 11:37:38 -05:00
parent 5c0f1ebb66
commit 66e9e98564

View File

@@ -6,48 +6,50 @@
<section id="claim-check-introduction">
<title>Introduction</title>
<para>
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.
</para>
<para>
<link href="http://www.eaipatterns.com/StoreInLibrary.html">Claim Check</link> 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 <link href="http://www.eaipatterns.com/StoreInLibrary.html">Claim Check</link> 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.
</para>
<para>
Spring Integration provides two types of Claim Check transformers - <emphasis>Incoming Claim Check Transformer</emphasis> and
<emphasis>Outgoing Claim Check Transformer</emphasis> as well as convenient namespace-based mechanism to configure them.
Spring Integration provides two types of Claim Check transformers: <emphasis>Incoming Claim Check Transformer</emphasis> and
<emphasis>Outgoing Claim Check Transformer</emphasis>. Convenient namespace-based mechanisms are available to configure them.
</para>
<section id="claim-check-in">
<title>Incoming Claim Check Transformer</title>
<para>
<emphasis>Incoming Claim Check Transformer</emphasis> - will transform incoming Message by storing it in the Message Store
identified by <code>message-store</code> attribute.
An <emphasis>Incoming Claim Check Transformer</emphasis> will transform an incoming Message by storing it in the Message Store
identified by its <code>message-store</code> attribute.
<programlisting language="xml"><![CDATA[<int:claim-check-in id="checkin"
input-channel="checkinChannel"
message-store="testMessageStore"
output-channel="checkoutChannel"/>]]></programlisting>
input-channel="checkinChannel"
message-store="testMessageStore"
output-channel="output"/>]]></programlisting>
In the above configuration the Message that is received on the <code>input-channel</code> will be persisted to the
Message Store identified with <code>message-store</code> 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 <code>output-channel</code>.
Message Store identified with the <code>message-store</code> 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 <code>output-channel</code>.
</para>
<para>
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 <emphasis>Outgoing Claim Check Transformer</emphasis>.
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 <emphasis>Outgoing Claim Check Transformer</emphasis>.
</para>
</section>
@@ -55,20 +57,22 @@
<title>Outgoing Claim Check Transformer</title>
<para>
<emphasis>Incoming Claim Check Transformer</emphasis> allows you to transform a Message from the Message with just a Claim Check
to the Message with the original content.
An <emphasis>Outgoing Claim Check Transformer</emphasis> allows you to transform a Message with a Claim Check payload
into a Message with the original content as its payload.
<programlisting language="xml"><![CDATA[<claim-check-out id="checkout"
input-channel="checkoutChannel"
message-store="testMessageStore"/>]]></programlisting>
input-channel="checkoutChannel"
message-store="testMessageStore"
output-channel="output"/>]]></programlisting>
In the above configuration the Message that is received on the <code>input-channel</code> has a Claim Check as a payload
and <emphasis>Outgoing Claim Check Transformer</emphasis> 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 <code>output-channel</code>.
In the above configuration, the Message that is received on the <code>input-channel</code> should have a Claim Check as its payload
and the <emphasis>Outgoing Claim Check Transformer</emphasis> 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
<code>output-channel</code>.
</para>
</section>
<para>
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.
</para>
<para>
@@ -76,9 +80,9 @@
</para>
<para>
<classname>org.springframework.integration.store.MessageStore</classname> is a strategy interface for storing and retrieving messages.
Spring Integration provides two convenient implementations of it. <classname>SimpleMessageStore</classname> - In memory Map-based
implementation (default, good for testing) and <classname>JdbcMessageStore</classname> - Implementation of <classname>MessageStore</classname>
that uses relational database via JDBC.
Spring Integration provides two convenient implementations of it. <classname>SimpleMessageStore</classname>: an in-memory, Map-based
implementation (the default, good for testing) and <classname>JdbcMessageStore</classname>: an implementation that uses a relational
database via JDBC.
</para>
</section>