diff --git a/spring-integration-reference/src/core-api.xml b/spring-integration-reference/src/core-api.xml deleted file mode 100644 index 3079fa1d79..0000000000 --- a/spring-integration-reference/src/core-api.xml +++ /dev/null @@ -1,175 +0,0 @@ - - -
- MessageHandler - - So far we have seen that generic message objects are sent-to and received-from simple channel objects. Here is - Spring Integration's callback interface for handling the Messages: - public interface MessageHandler { - Message<?> handle(Message<?> message); -} - The handler plays an important role, since it is typically responsible for translating between the generic - Message objects and the domain objects or primitive values expected by business - components that consume the message payload. That said, developers will rarely need to implement this interface - directly. While that option will always be available, we will soon discuss the higher-level configuration options - including both annotation-driven techniques and XML-based configuration with convenient namespace support. - -
- -
- MessageBus - - So far, you have seen that the PollableChannel provides a - receive() method that returns a Message, the subscribable - MessageChannels invoke one or more subscribers directly, and the MessageHandler - provides a handle() method that accepts a Message. - However, we have not yet discussed how messages get passed from a channel to a handler. As mentioned earlier, - the MessageBus provides a runtime form of inversion of control, and one of the primary - responsibilities that it assumes is connecting the channels to the handlers. It also connects MessageSources and - MessageTargets to channels (thereby creating Channel Adapters), and it manages the scheduling of polling - dispatchers. Ultimately, every MessageHandler should be invoked as if it is an event-driven consumer, and this - works fine when the handler's input source is a SubscribableSource. However, the - bus creates and manages these polling dispatchers so that even when handlers receive input from a - PollableSource, they will still behave as event-driven consumers. - - - The MessageBus is an example of a mediator. It performs a number of roles - - mostly by delegating to other strategies. One of its main responsibilities is to manage registration of the - MessageChannels and endpoints, such as Channel Adapters - and Service Activators. It recognizes any of these instances that have been defined - within its ApplicationContext. - - - The message bus handles several of the concerns so that the channels, sources, targets, and Message-handling - objects can be as simple as possible. These responsibilities include the lifecycle management of - message endpoints, the activation of subscriptions, and the scheduling of dispatchers (including - the configuration of thread pools). The bus coordinates all of that behavior based upon the metadata provided - in bean definitions. Furthermore, those bean definitions may be provided via XML and/or annotations - (we will look at examples of both configuration options shortly). - - - The bus is responsible for activating all of its registered endpoints by connecting them to channels within - its registry, and if necessary scheduling a poller so that the endpoint can be event-driven even when connected - to a channel that requires polling. For example, the poller for an outbound Channel Adapter - will poll the referenced "channel", and the poller for a Service Activator will poll the - referenced "input-channel". If that "channel" or "input-channel" is subscribable rather than pollable, the bus - will simply activate the subscription. The important point is that the endpoint itself does not need to know - whether its source is pollable or subscribable. - -
- -
- MessageEndpoint - - As described in , there are different types of Message Endpoint, such - as the Channel Adapter (inbound or outbound) and the Service Activator. - Spring Integration provides many other components that are also endpoints, such as Routers, - Splitters, and Aggregators. Each endpoint may provide its own specific metadata so that the - MessageBus can manage its connection to channels and its poller (if necessary). - - - The scheduling metadata is provided as an implementation of the Schedule interface. - This is an abstraction designed to allow extensibility of schedulers for messaging tasks. Currently, there are two - implementations: PollingSchedule and CronSchedule. The former has - a period property, and the latter has a cronExpression. The polling - schedule may be configured based on throughput expectations and/or the type of MessageSource - (e.g. file-system vs. JMS). - - - While the MessageBus manages the scheduling of the pollers, it is often beneficial to have multiple task - executors with different concurrency settings for an endpoint or group of endpoints. This provides more control - over the number of threads available for each receive-and-handle unit of work and depending on the type of - task executor, may also enable dynamic adjustments. When the MessageBus - activates an endpoint, it will create and schedule the poller for that endpoint based on the endpoint's - configuration. This will be described in more detail in . - -
- -
- MessageSelector - - As described above, each endpoint is registered with the message bus and is thereby subscribed - to a channel. Often it is necessary to provide additional dynamic logic to - determine what messages the endpoint should receive. The MessageSelector - strategy interface fulfills that role. - message); - -}]]> - A MessageEndpoint can be configured with a selector (or selector-chain) - and will only receive messages that are accepted by each selector. Even though the interface is simple - to implement, a couple common selector implementations are provided. For example, the - PayloadTypeSelector provides similar functionality to Datatype Channels - (as described in ) except that in this case the type-matching can be done - by the endpoint rather than the channel. - (123))); -assertFalse(selector.accept(new GenericMessage(someObject)));]]> - Another simple but useful MessageSelector provided out-of-the-box is the - UnexpiredMessageSelector. As the name suggests, it only accepts messages that have - not yet expired. - - - Essentially, using a selector provides reactive routing whereas the Datatype Channel - and Message Router provide proactive routing. However, selectors accommodate additional - uses. For example, a PollableChannel's 'purge' method accepts a selector: - channel.purge(someSelector); - There is a ChannelPurger utility class whose purge operation is a good candidate for - Spring's JMX support: - ChannelPurger purger = new ChannelPurger(new ExampleMessageSelector(), channel); -purger.purge(); - - - Implementations of MessageSelector might provide opportunities for reuse on - channels in addition to endpoints. For that reason, Spring Integration provides a simple selector-wrapping - ChannelInterceptor that accepts one or more selectors in its constructor. - MessageSelectingInterceptor interceptor = - new MessageSelectingInterceptor(selector1, selector2); -channel.addInterceptor(interceptor); - -
- -
- MessagingGateway - - Even though the MessageExchangeTemplate is fairly straightforward, it does not hide the - details of messaging from your application code. To support working with plain Objects instead of messages, - Spring Integration provides SimpleMessagingGateway with the following methods: - public void send(Object object) { ... } - -public Object receive() { ... } - -public Object sendAndReceive(Object object) { ... } - -public void receiveAndForward() { ... } - It enables configuration of a request and/or reply channel and delegates to an instance of the - MessageMapper and MessageCreator strategy - interfaces. - SimpleMessagingGateway gateway = new SimpleMessagingGateway(); -gateway.setRequestChannel(requestChannel); -gateway.setReplyChannel(replyChannel); -gateway.setMessageCreator(messageCreator); -gateway.setMessageMapper(messageMapper); -Object result = gateway.sendAndReceive("test"); - - - - Working with Objects instead of Messages is an improvement. However, it would be even better to have no - dependency on the Spring Integration API at all - including the gateway class. For that reason, Spring - Integration also provides a GatewayProxyFactoryBean that generates a proxy for - any interface and internally invokes the gateway methods shown above. Namespace support is also - provided as demonstrated by the following example. - ]]> - Then, the "fooService" can be injected into other beans, and the code that invokes the methods on that - proxied instance of the FooService interface has no awareness of the Spring Integration API. The general - approach is similar to that of Spring Remoting (RMI, HttpInvoker, etc.). - -
- \ 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 6b7ae0893b..af05d04a81 100644 --- a/spring-integration-reference/src/spring-integration-reference.xml +++ b/spring-integration-reference/src/spring-integration-reference.xml @@ -47,7 +47,7 @@ - + diff --git a/spring-integration-reference/src/transformation.xml b/spring-integration-reference/src/transformer.xml similarity index 100% rename from spring-integration-reference/src/transformation.xml rename to spring-integration-reference/src/transformer.xml