diff --git a/spring-integration-reference/src/samples.xml b/spring-integration-reference/src/samples.xml
index e890cfbbfe..5e8e81ef87 100644
--- a/spring-integration-reference/src/samples.xml
+++ b/spring-integration-reference/src/samples.xml
@@ -1,15 +1,18 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
 <appendix id="samples">
+
   <title>Spring Integration Samples</title>
-	<para>
-	Starting with the current release of Spring Integration the <emphasis>samples</emphasis> are distributed as independent Maven-based projects 
-	(<ulink url="http://maven.apache.org/">http://maven.apache.org/</ulink>) to minimize the setup time.
-	Since each project is also an Eclipse-based project, they could be imported as is using "Import existing project wizard". 
-	If you prefer other IDE, configuration should be very trivial, since a special Maven profile was setup to download all the 
-	required dependencies required by all samples.
-	Detailed instructions on how to run samples provided in README file located in the <emphasis>samples</emphasis> directory of the main distribution. 
-	</para>
+
+	<note>
+		Starting with the current release of Spring Integration the <emphasis>samples</emphasis> are distributed as independent
+		Maven-based projects (<ulink url="http://maven.apache.org/">http://maven.apache.org/</ulink>) to minimize the setup time.
+		Since each project is also an Eclipse-based project, they can be imported as is using "Import existing project wizard". 
+		If you prefer another IDE, configuration should be very trivial, since a special Maven profile was setup to download all
+		of the required dependencies for all samples. Detailed instructions on how to build and run the samples are provided in
+		the <code>README.txt</code> file located in the <emphasis>samples</emphasis> directory of the main distribution.
+	</note>
+
   <section id="samples-cafe">
     <title>The Cafe Sample</title>
     <para>
@@ -31,7 +34,7 @@
       The <classname>Order</classname> object may contain multiple <classname>OrderItems</classname>. Once the order
       is placed, a <emphasis>Splitter</emphasis> will break the composite order message into a single message per
       drink. Each of these is then processed by a <emphasis>Router</emphasis> that determines whether the drink is hot
-      or cold (checking the <classname>OrderItem</classname> object's 'isIced' property). Finally the
+      or cold (checking the <classname>OrderItem</classname> object's 'isIced' property). The
       <classname>Barista</classname> prepares each drink, but hot and cold drink preparation are handled by two
       distinct methods: 'prepareHotDrink' and 'prepareColdDrink'. The prepared drinks are then sent to the Waiter where
       they are aggregated into a <classname>Delivery</classname> object.
@@ -195,16 +198,10 @@
     }
 }]]></programlisting>
     </para>
-    <para>
-      To run this demo, go to the "samples" directory within the root of the Spring Integration distribution. On
-      Unix/Mac you can run 'cafeDemo.sh', and on Windows you can run 'cafeDemo.bat'. Each of these will by default
-      create a Spring <interfacename>ApplicationContext</interfacename> from the 'cafeDemo.xml' file that is
-      in the "spring-integration-samples" JAR and hence on the classpath (it is the same as the XML above). However, a
-      copy of that file is also available within the "samples" directory, so that you can provide the file name as a
-      command line argument to either 'cafeDemo.sh' or 'cafeDemo.bat'. This will allow you to experiment with the
-      configuration and immediately run the demo with your changes. It is probably a good idea to first copy the
-      original file so that you can make as many changes as you want and still refer back to the original to compare.
-    </para>
+    <tip>
+      To run this sample as well as 8 others, refer to the <code>README.txt</code> within the "samples" directory
+      of the main distribution as described at the beginning of this chapter.
+    </tip>
     <para>
       When you run cafeDemo, you will see that the cold drinks are initially prepared more quickly than the hot drinks.
       Because there is an aggregator, the cold drinks are effectively limited by the rate of the hot drink preparation.
@@ -233,17 +230,16 @@
       then you will notice that occasionally it throttles the input by forcing the task-scheduler (the caller) to invoke
       the operation.
     </para>
-    <para>
+    <note>
       In addition to experimenting with the poller's concurrency settings, you can also add the 'transactional'
-      sub-element. If you want to explore the sample in more detail, the source JAR is available in the "src"
-      directory: 'org.springframework.integration.samples-sources-1.0.0.jar'.
-    </para>
+      sub-element and then refer to any PlatformTransactionManager instance within the context.
+    </note>
   </section>
 
   <section id="samples-xml-messaging">
     <title>The xml messaging sample</title>
     <para>
-    	The xml messaging sample in <package>org.springframework.integration.samples.xml</package> illustrates how to use 
+    	The xml messaging sample in the <package>org.springframework.integration.samples.xml</package> illustrates how to use 
     	some of the provided components which deal with xml payloads.  The sample uses the idea of processing an order for books
     	represented as xml.   
     </para>
@@ -284,7 +280,6 @@
      xsl-resource="classpath:org/springframework/integration/samples/xml/bigBooksSupplierTransformer.xsl"/>
 ]]></programlisting>    	 
     </para>
-  </section>
-  
+  </section> 
   
 </appendix>
\ No newline at end of file
diff --git a/spring-integration-reference/src/service-activator.xml b/spring-integration-reference/src/service-activator.xml
index 40fdb04c2a..79d53f1195 100644
--- a/spring-integration-reference/src/service-activator.xml
+++ b/spring-integration-reference/src/service-activator.xml
@@ -34,33 +34,37 @@
       "output-channel" was provided in the endpoint configuration:
       <programlisting language="xml">&lt;service-activator input-channel="exampleChannel" output-channel="replyChannel"
                    ref="somePojo" method="someMethod"/&gt;</programlisting>
-      If no "output-channel" is available, it will then check the Message's <literal>RETURN_ADDRESS</literal> header
+      If no "output-channel" is available, it will then check the Message's <literal>REPLY_CHANNEL</literal> header
       value. If that value is available, it will then check its type. If it is a
       <interfacename>MessageChannel</interfacename>, the reply message will be sent to that channel. If it is a
       <classname>String</classname>, then the endpoint will attempt to resolve the channel name to a channel instance.
       If the channel cannot be resolved, then a <classname>ChannelResolutionException</classname> will be thrown.
     </para>
     <para>
-     The argument in the service method could be either a Message or an arbitrary type. If the later one, then it will be assumed that it is a Payload source,
-      which will be extracted from the message and injected into such service method. This is generally the recommended approach as it follows and promotes
-      a POJO model when working with Spring Integration.
-    Since v1.0.3 of Spring Integration, the service method does not require to have an argument at all, which means you can now implement event-style Service Activators,
-    where all you care about is an invocation of the service method not worrying about the contents of the message. Think of it as a NULL JMS message. An example use-case for such implementation 
-    could be a simple counter/monitor of messages deposited on the input channel.
+      The argument in the service method could be either a Message or an arbitrary type. If the latter, then it will
+      be assumed that it is a Message payload, which will be extracted from the message and injected into such service
+      method. This is generally the recommended approach as it follows and promotes a POJO model when working with Spring
+      Integration. Arguments may also have @Header or @Headers annotations as described in <xref linkend="annotations"/>
     </para>
+    <note>
+       Since v1.0.3 of Spring Integration, the service method is not required to have an argument at all, which means you
+       can now implement event-style Service Activators, where all you care about is an invocation of the service method,
+       not worrying about the contents of the message. Think of it as a NULL JMS message. An example use-case for such an
+       implementation could be a simple counter/monitor of messages deposited on the input channel.
+    </note>
     <para>
-    Using a "ref" attribute is generally recommended if custom Service Activator handler implementation can be reused in other <code>&lt;service-activator&gt;</code> definitions. However
-if custom Service Activator handler implementation has to be scoped to a concrete definition of the <code>&lt;service-activator&gt;</code>, starting with v1.0.3, Spring Integration supports
-inner bean definitions for custom Service Activator handlers within the <code>&lt;service-activator&gt;</code> element:
-<programlisting language="xml"><![CDATA[<service-activator id="testServiceActivator" input-channel="inChannel" 
+      Using a "ref" attribute is generally recommended if the custom Service Activator handler implementation can be reused
+      in other <code>&lt;service-activator&gt;</code> definitions. However if the custom Service Activator handler implementation
+      should be scoped to a single definition of the <code>&lt;service-activator&gt;</code>, you can use an inner bean definition:
+<programlisting language="xml"><![CDATA[<service-activator id="exampleServiceActivator" input-channel="inChannel" 
 						output-channel = "outChannel" method="foo">
-		<beans:bean class="org.foo.TestServiceActivator" /> \
+		<beans:bean class="org.foo.ExampleServiceActivator"/>
 </service-activator>]]></programlisting>
     </para>
     <note>
     <para>
-    Using both "ref" attribute and inner handler definition in the same <code>&lt;service-activator&gt;</code> configuration
-    is not allowed, as it creates an ambiguous condition and will result in Exception being thrown 
+    Using both the "ref" attribute and an inner handler definition in the same <code>&lt;service-activator&gt;</code>
+    configuration is not allowed, as it creates an ambiguous condition and will result in an Exception being thrown.
     </para>
     </note>
   </section>