Documentation updates

This commit is contained in:
Mark Fisher
2008-10-21 22:28:03 +00:00
parent fddd8792d5
commit 59b580b76c
6 changed files with 181 additions and 30 deletions

View File

@@ -80,7 +80,19 @@ PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel
PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel);
endpoint.setTrigger(new IntervalTrigger(30, TimeUnit.SECONDS));</programlisting>
Likewise, other polling-related configuration properties may be specified:
Spring Integration currently provides two implementations of the <interfacename>Trigger</interfacename>
interface: <classname>IntervalTrigger</classname> and <classname>CronTrigger</classname>. The
<classname>IntervalTrigger</classname> is typically defined with a simple interval (in milliseconds), but
also supports an 'initialDelay' property and a boolean 'fixedRate' property (the default is false - i.e.
fixed delay):
<programlisting language="java">IntervalTrigger trigger = new IntervalTrigger(1000);
trigger.setInitialDelay(5000);
trigger.setFixedRate(true);</programlisting>
The <classname>CronTrigger</classname> simply requires the cron expression (see the Javadoc for details):
<programlisting language="java">CronTrigger trigger = new CronTrigger("*/10 * * * * MON-FRI");</programlisting>
</para>
<para>
In addition to the trigger, several other polling-related configuration properties may be specified:
<programlisting language="java">
PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel);

View File

@@ -0,0 +1,20 @@
<?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">
<chapter id="applicationevent">
<title>Spring ApplicationEvent Support</title>
<para>
Spring Integration also provides support for inbound and outbound <classname>ApplicationEvents</classname>.
To receive events and send to a channel, simply define an instance of Spring Integration's
<classname>ApplicationEventInboundChannelAdapter</classname>. This class in an implementation of Spring's
<interfacename>ApplicationListener</interfacename> interface. By default it will pass all received events as
Spring Integration Messages. To limit based on the type of event, configure the list of event types that you want
to receive with the 'eventTypes' property.
</para>
<para>
To send Spring <classname>ApplicationEvents</classname>, create an instance of the
<classname>ApplicationEventPublishingMessageConsumer</classname> and register it within an endpoint. This
implementation of the <interfacename>MessageConsumer</interfacename> interface also implements Spring's
<interfacename>ApplicationEventPublisherAware</interfacename> interface and thus acts as a bridge between
Spring Integration Messages and <classname>ApplicationEvents</classname>.
</para>
</chapter>

View File

@@ -1,43 +1,99 @@
<?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">
<chapter id="resources">
<title>HttpInvoker</title>
<chapter id="httpinvoker">
<title>HttpInvoker Support</title>
<section id="http-intro">
<section id="httpinvoker-intro">
<title>Introduction</title>
<para>
HttpInvoker is a Spring-specific remoting option that essentially enables Remote Procedure Calls (RPC) over HTTP.
In order to accomplish this, an outbound representation of a method invocation is serialized using standard Java
serialization and then passed within an HTTP POST request. After being invoked on the target system, the method's
return value is then serialized and written to the HTTP response. There are two main requirements. First, you
must be using Spring on both sides since the marshalling to and from HTTP requests and responses is handled by
the client-side invoker and server-side exporter. Second, the Objects that you are passing must implement
<interfacename>Serializable</interfacename> and be available on both the client and server.
</para>
<para>
While traditional RPC provides <emphasis>physical</emphasis> decoupling, it does not offer nearly the same degree
of <emphasis>logical</emphasis> decoupling as a messaging-based system. In other words, both participants in an
RPC-based invocation must be aware of a specific interface and specific argument types. Interestingly, in Spring
Integration, the "parameter" being sent is a Spring Integration Message, and the interface is an internal detail
of Spring Integration's implementation. Therefore, the RPC mechanism is being used as a
<emphasis>transport</emphasis> so that from the end user's perspective, it is not necessary to consider the
interface and argument types. It's just another adapter to enable messaging between two systems.
</para>
</section>
<section id="http-outbound">
<title>Outbound HttpInvoker</title>
<section id="httpinvoker-inbound">
<title>HttpInvoker Inbound Gateway</title>
<para>
To receive messages over http you need to use an <classname>HttpInvokerInboundGateway</classname>. Here is an
example bean definition:
<programlisting language="xml"><![CDATA[<bean id="inboundGateway" class="org.springframework.integration.httpinvoker.HttpInvokerInboundGateway">
<property name="requestChannel" ref="requestChannel"/>
<property name="replyChannel" ref="replyChannel"/>
<property name="requestTimeout" value="30000"/>
<property name="replyTimeout" value="10000"/>
</bean>]]></programlisting>
Because the inbound gateway must be able to receive HTTP requests, it must be configured within a Servlet
container. The easiest way to do this is to provide a servlet definition in <emphasis>web.xml</emphasis>:
<programlisting language="xml"><![CDATA[<servlet>
<servlet-name>inboundGateway</servlet-name>
<servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>
</servlet>]]></programlisting>
Notice that the servlet name matches the bean name.
<note>
If you are running within a Spring MVC application and using the BeanNameHandlerMapping, then the servlet
definition is not necessary. In that case, the bean name for your gateway can be matched against the URL
path just like a Spring MVC Controller bean.
</note>
</para>
</section>
<section id="httpinvoker-outbound">
<title>HttpInvoker Outbound Gateway</title>
<para>
</para>
<para>
To configure the outbound gateway write a bean definition like this:
<programlisting language="xml"><![CDATA[]]>
</programlisting>
To configure the <classname>HttpInvokerOutboundGateway</classname> write a bean definition like this:
<programlisting language="xml"><![CDATA[<bean id="outboundGateway" class="org.springframework.integration.httpinvoker.HttpInvokerOutboundGateway">
<property name="replyChannel" ref="replyChannel"/>
</bean>]]></programlisting>
The outbound gateway is a <interfacename>MessageConsumer</interfacename> and can therefore be registered with
either a <classname>PollingConsumerEndpoint</classname> or <classname>SubscribingConsumerEndpoint</classname>.
The URL must match that defined by an inbound HttpInvoker Gateway as described in the previous section.
</para>
</section>
<section id="http-inbound">
<title>Inbound HttpInvoker</title>
<para>
To receive messages over http you need to use a <classname>TODO</classname>. This gateway can be configured like this
<programlisting language="xml"><![CDATA[]]>
</programlisting>
</para>
</section>
<section id="http-namespace">
<title>HttpInvoker namespace support</title>
<section id="httpinvoker-namespace">
<title>HttpInvoker Namespace Support</title>
<para>
Spring Integration provides an "httpinvoker" namespace and schema definition. To include it in your
configuration, simply provide the following URI within a namespace declaration:
'http://www.springframework.org/schema/integration/httpinvoker'. The schema location should then map to
'http://www.springframework.org/schema/integration/httpinvoker/spring-integration-httpinvoker-1.0.xsd'.
</para>
<para>
To configure the inbound gateway you can choose to use the namespace support for it. The following code snippet shows the different configuration options that are supported.
<programlisting language="xml"><![CDATA[]]></programlisting>
<programlisting language="xml"><![CDATA[<httpinvoker:inbound-gateway id="inboundGateway"
request-channel="requestChannel"
request-timeout="10000"
expect-reply="false"
reply-timeout="30000"/>]]></programlisting>
<note>
A 'reply-channel' may also be provided, but it is recommended to rely on the temporary anonymous channel
that will be created automatically for handling replies.
</note>
</para>
<para>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound HttpInvoker gateway.
<programlisting language="xml"><![CDATA[]]></programlisting>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration for an outbound HttpInvoker gateway. Only the 'url' and 'request-channel' are required.
<programlisting language="xml"><![CDATA[<httpinvoker:outbound-gateway id="outboundGateway"
url="http://localhost:8080/example"
request-channel="requestChannel"
request-timeout="5000"
reply-channel="replyChannel"
reply-timeout="10000"/>]]></programlisting>
</para>
</section>
</chapter>

View File

@@ -217,12 +217,7 @@
The most convenient way to configure Source and Target adapters is by using the namespace support. The
following examples demonstrate the namespace-based configuration of several source, target, gateway,
and handler adapters:
<programlisting language="xml"><![CDATA[<jms-source id="jmsSource" connection-factory="connFactory" destination="inQueue"/>
<!-- using the default "connectionFactory" reference -->
<jms-target id="jmsTarget" destination="outQueue"/>
<httpinvoker-gateway id="httpSource" name="/some/path" request-channel="httpInvokerInput"/>
<programlisting language="xml"><![CDATA[<httpinvoker-gateway id="httpSource" name="/some/path" request-channel="httpInvokerInput"/>
<httpinvoker-handler id="httpTarget" channel="httpInvokerOutput" url="http://somehost/test"/>

View File

@@ -4,6 +4,69 @@
<chapter id="router">
<title>Message Routing</title>
<section id="router-implementations">
<title>Router Implementations</title>
<para>
Since content-based routing often requires some domain-specific logic, most use-cases will require
Spring Integration's options for delegating to POJOs using the XML namespace support and/or Annotations.
Both of these are discussed below, but first we present a couple implementations that are available
out-of-the-box since they fulfill generic, but common, requirements.
</para>
<section id="router-implementations-payloadtyperouter">
<title>PayloadTypeRouter</title>
<para>
A <classname>PayloadTypeRouter</classname> will send Messages to the channel as defined by payload-type
mappings.
<programlisting language="xml"><![CDATA[<bean id="payloadTypeRouter" class="org.springframework.integration.router.PayloadTypeRouter">
<property name="payloadTypeChannelMap">
<map>
<entry key="java.lang.String" value-ref="stringChannel"/>
<entry key="java.lang.Integer" value-ref="integerChannel"/>
</map>
</property>
</bean>]]></programlisting>
</para>
</section>
<section id="router-implementations-recipientlistrouter">
<title>RecipientListRouter</title>
<para>
A <classname>RecipientListRouter</classname> will send each received Message to a statically-defined
list of Message Channels:
<programlisting language="xml"><![CDATA[<bean id="recipientListRouter" class="org.springframework.integration.router.RecipientListRouter">
<property name="channels">
<list>
<ref bean="channel1"/>
<ref bean="channel2"/>
<ref bean="channel3"/>
</list>
</property>
</bean>]]></programlisting>
</para>
</section>
<note>
The router implementations share some common properties, such as "defaultOutputChannel" and "resolutionRequired".
If "resolutionRequired" is set to "true", and the router is unable to determine a target channel (e.g. there is
no matching payload for a PayloadTypeRouter and no "defaultOutputChannel" has been specified), then an Exception
will be thrown.
</note>
</section>
<section id="router-namespace">
<title>The &lt;router&gt; element</title>
<para>
The "router" element provides a simple way to connect a router to an input channel, and also accepts the
optional default output channel. The "ref" may provide the bean name to one of the implementations described
above:
<programlisting language="xml"><![CDATA[<router ref="payloadTypeRouter" input-channel="input1" default-output-channel="defaultOutput1"/>
<router ref="recipientListRouter" input-channel="input2" default-output-channel="defaultOutput2"/>]]></programlisting>
Alternatively, the "ref" may point to a simple Object that contains the @Router annotation (see below), or the
"ref" may be combined with an explicit "method" name. When specifying a "method", the same behavior applies as
described in the @Router annotation section below.
<programlisting language="xml"><![CDATA[<router input-channel="input" ref="somePojo" method="someMethod"/>]]></programlisting>
</para>
</section>
<section id="router-annotation">
<title>The @Router Annotation</title>
<para>
@@ -33,5 +96,8 @@ public List&lt;String&gt; route(Foo payload) {...}</programlisting>
public List&lt;String&gt; route(@Header("orderStatus") OrderStatus status)</programlisting>
</para>
</section>
<note>
For routing of XML-based Messages, including XPath support, see <xref linkend="xml"/>.
</note>
</chapter>

View File

@@ -52,7 +52,9 @@
<xi:include href="./file.xml"/>
<xi:include href="./jms.xml"/>
<xi:include href="./rmi.xml"/>
<xi:include href="./stream.xml"/>
<xi:include href="./httpinvoker.xml"/>
<xi:include href="./stream.xml"/>
<xi:include href="./event.xml"/>
<xi:include href="./xml.xml"/>
<xi:include href="./security.xml"/>
<xi:include href="./samples.xml"/>