diff --git a/spring-integration-reference/src/adapters.xml b/spring-integration-reference/src/adapters.xml deleted file mode 100644 index 4ecaa2403d..0000000000 --- a/spring-integration-reference/src/adapters.xml +++ /dev/null @@ -1,123 +0,0 @@ - - - - Adapters - -
- Introduction - - Spring Integration provides a number of implementations of the MessageSource - and MessageTarget interfaces that serve as adapters for interacting with - external systems or components that are not part of the messaging system. These source and target - implementations can be configured within the same channel-adapter element that we - have already discussed. Essentially, the external system or component sends-to and/or receives-from a - MessageChannel. In the 1.0 Milestone 6 release, Spring Integration includes - source and target implementations for JMS, Files, FTP, Streams, and Spring ApplicationEvents. - - - Adapters that allow an external system to perform request-reply operations across Spring Integration - MessageChannels are actually examples of the Messaging Gateway - pattern. Therefore, those implementations are typically called "gateways" (whereas "source" and "target" - are in-only and out-only interactions respectively). For example, Spring Integration provides a - JmsSource that is polled by the bus-managed scheduler, but - also provides a JmsGateway. The gateway differs from the source in that it is an - event-driven consumer rather than a polling consumer, - and it is capable of waiting for reply messages. Spring Integration also provides gateways for RMI and - Spring's HttpInvoker. - - - Finally, adapters that enable interaction with external systems by invoking them for - request/reply interactions (the response is sent back on a Message Channel) are typically called - handlers in Spring Integration, since they implement the - MessageHandler interface. Basically, these types of adapters can be - configured exactly like any POJO with the <service-activator> element. Spring Integration provides - RMI, HttpInvoker, and Web Service handler implementations. - - - All of these adapters are discussed in this section. However, namespace support is provided for many of them - and is typically the most convenient option for configuration. For examples, see - . - -
- -
- Mail Adapters - - Spring Integration currently provides support for outbound email only with the - MailTarget. This adapter delegates to a configured instance of Spring's - JavaMailSender, and its various mapping strategies use Spring's - MailMessage abstraction. By default text-based mails are created when - the handled message has a String-based payload. If the message payload is a byte array, then that will - be mapped to an attachment. - - - The adapter also delegates to a MailHeaderGenerator for providing the - mail's properties, such as the recipients (TO, CC, and BCC), the from/reply-to, and the subject. - message); -}]]> - The default implementation will look for values in the MessageHeaders with - the following constants defining the header names: - MailHeaders.SUBJECT -MailHeaders.TO -MailHeaders.CC -MailHeaders.BCC -MailHeaders.FROM -MailHeaders.REPLY_TO - - - A static implementation is also available out-of-the-box and may be useful for testing. However, when - customizing, the properties would typically be generated dynamically based on the message itself. The - following is an example of a configured mail adapter. - - - -]]> - -
-
- Web Service Adapters - - To invoke a Web Service upon sending a message to a channel, there are two options: - SimpleWebServiceHandler and - MarshallingWebServiceHandler. The former will accept either a - String or javax.xml.transform.Source as the message - payload. The latter provides support for any implementation of the Marshaller - and Unmarshaller interfaces. Both require the URI of the Web Service to be - called.simpleHandler = new SimpleWebServiceHandler(uri); - -marshallingHandler = new MarshallingWebServiceHandler(uri, marshaller); - - Either adapter can then be referenced from a service-activator element - that is subscribed to an input-channel. The endpoint is then responsible for passing the response to the - proper reply channel. It will first check for an "output-channel" on the service-activator and will - fallback to a RETURN_ADDRESS in the original message's headers. - - - For more detail on the inner workings, see the Spring Web Services reference guide's chapter covering - client access - as well as the chapter covering - Object/XML mapping. - -
-
- ApplicationEvent Adapters - - Spring ApplicationEvents can also be integrated as either a source or target for Spring - Integration message channels. To receive the events and send to a channel, simply define an instance of Spring - Integration's ApplicationEventSource (as with all source implementations, this can then - be configured within a "channel-adapter" element and automatically detected by the message bus). The - ApplicationEventSource also implements Spring's ApplicationListener - 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. - - - To send Spring ApplicationEvents, register an instance of the - ApplicationEventTarget class as the 'target' of a Channel Adapter (such configuration will - be described in detail in ). This target also implements Spring's - ApplicationEventPublisherAware interface and thus acts as a bridge between - Spring Integration Messages and ApplicationEvents. - -
- \ No newline at end of file diff --git a/spring-integration-reference/src/spring-integration-reference.xml b/spring-integration-reference/src/spring-integration-reference.xml index c6db4819fd..ff76591092 100644 --- a/spring-integration-reference/src/spring-integration-reference.xml +++ b/spring-integration-reference/src/spring-integration-reference.xml @@ -49,9 +49,9 @@ - + diff --git a/spring-integration-reference/src/ws.xml b/spring-integration-reference/src/ws.xml new file mode 100644 index 0000000000..14d3230047 --- /dev/null +++ b/spring-integration-reference/src/ws.xml @@ -0,0 +1,55 @@ + + + + Web Services Support + +
+ Outbound Web Service Gateways + + To invoke a Web Service upon sending a message to a channel, there are two options - both of which build + upon the Spring Web Services + project: SimpleWebServiceOutboundGateway and + MarshallingWebServiceOutboundGateway. The former will accept either a + String or javax.xml.transform.Source as the message + payload. The latter provides support for any implementation of the Marshaller + and Unmarshaller interfaces. Both require the URI of the Web Service to be + called. simpleGateway = new SimpleWebServiceOutboundGateway(uri); + + marshallingGateway = new MarshallingWebServiceOutboundGateway(uri, marshaller); + + + + For more detail on the inner workings, see the Spring Web Services reference guide's chapter covering + client access + as well as the chapter covering + Object/XML mapping. + +
+ +
+ Web Service Namespace Support + + To configure an outbound Web Service Gateway, use the "outbound-gateway" element from the "ws" namespace: + ]]> + To use Spring OXM Marshallers and/or Unmarshallers, provide bean references: + ]]> + + Most Marshaller implementations also implement the + Unmarshaller interface. When using such a Marshaller, only the "marshaller" + attribute is necessary. Even when using a Marshaller, you may also provide a reference for the + "request-callback". + + + + For either gateway type, the "message-factory" attribute can also be configured with a reference to any + Spring Web Services WebServiceMessageFactory implementation. + +
+ + \ No newline at end of file