From 74b574e6cf303b08bbd35d3e7836dfe217b45715 Mon Sep 17 00:00:00 2001 From: Mark Fisher Date: Mon, 3 Nov 2008 15:26:10 +0000 Subject: [PATCH] Updated consumer class names in doc --- spring-integration-reference/src/endpoint.xml | 91 +++++++++---------- spring-integration-reference/src/overview.xml | 10 +- 2 files changed, 49 insertions(+), 52 deletions(-) diff --git a/spring-integration-reference/src/endpoint.xml b/spring-integration-reference/src/endpoint.xml index ae9756511c..b9041aa8b0 100644 --- a/spring-integration-reference/src/endpoint.xml +++ b/spring-integration-reference/src/endpoint.xml @@ -24,20 +24,24 @@ ApplicationContext, it more closely resembles Spring's own MessageListener containers. -
- Message Consumer +
+ Message Handler - Spring Integration's MessageConsumer interface is defined as follows: - public interface MessageConsumer { + Spring Integration's MessageHandler interface is implemented by many of the + components within the framework. In other words, this is not part of the public API, and a developer would not + typically implement MessageHandler directly. Nevertheless, it is used by a Message + Consumer for actually handling the consumed Messages, and so being aware of this strategy interface does help in + terms of understanding the overall role of a consumer. The interface is defined as follows: + public interface MessageHandler { - void onMessage(Message<?> message); + void handleMessage(Message<?> message); } Despite its simplicity, this provides the foundation for most of the components that will be covered in the following chapters (Routers, Transformers, Splitters, Aggregators, Service Activators, etc). Those components - each perform very different functionality with the Messages they receive, but the requirements for actually + each perform very different functionality with the Messages they handle, but the requirements for actually receiving a Message are the same, and the choice between polling and event-driven behavior is also the same. - Spring Integration provides two endpoint implementations that "host" these callback-based consumers and allow + Spring Integration provides two endpoint implementations that "host" these callback-based handlers and allow them to be connected to Message Channels.
@@ -47,39 +51,35 @@ Because it is the simpler of the two, we will cover the Event-Driven Consumer endpoint first. You may recall that the SubscribableChannel interface provides a subscribe() - method and that the method accepts a MessageConsumer parameter (as shown in + method and that the method accepts a MessageHandler parameter (as shown in ): -subscribableChannel.subscribe(messageConsumer); +subscribableChannel.subscribe(messageHandler); - Since a consumer that is subscribed to a channel does not have to actively poll that channel, this is an - Event-Driven Consumer, and the corresponding endpoint "container" class provided by Spring Integration accepts a - MessageConsumer and a SubscribableChannel: - MessageConsumer consumer = new ExampleConsumer(); + Since a handler that is subscribed to a channel does not have to actively poll that channel, this is an + Event-Driven Consumer, and the implementation provided by Spring Integration accepts a + a SubscribableChannel and a MessageHandler: + SubscribableChannel channel = (SubscribableChannel) context.getBean("exampleSubscribableChannel"); -SubscribableChannel channel = (SubscribableChannel) context.getBean("exampleSubscribableChannel"); - -SubscribingConsumerEndpoint endpoint = new SubscribingConsumerEndpoint(consumer, channel); +EventDrivenConsumer consumer = new EventDrivenConsumer(channel, exampleHandler);
Polling Consumer - Spring Integration also provides a PollingConsumerEndpoint, and it can be instantiated in + Spring Integration also provides a PollingConsumer, and it can be instantiated in the same way except that the channel must implement PollableChannel: - MessageConsumer consumer = new ExampleConsumer(); + PollableChannel channel = (PollableChannel) context.getBean("examplePollableChannel"); -PollableChannel channel = (PollableChannel) context.getBean("examplePollableChannel"); - -PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel); +PollingConsumer consumer = new PollingConsumer(channel, exampleHandler); - There are many other configuration options for the polling endpoint. For example, the trigger can be provided: + There are many other configuration options for the Polling Consumer. For example, the trigger can be provided: -PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel); +PollingConsumer consumer = new PollingConsumer(channel, handler); -endpoint.setTrigger(new IntervalTrigger(30, TimeUnit.SECONDS)); +consumer.setTrigger(new IntervalTrigger(30, TimeUnit.SECONDS)); Spring Integration currently provides two implementations of the Trigger interface: IntervalTrigger and CronTrigger. The IntervalTrigger is typically defined with a simple interval (in milliseconds), but @@ -94,35 +94,35 @@ trigger.setFixedRate(true); In addition to the trigger, several other polling-related configuration properties may be specified: -PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel); +PollingConsumer consumer = new PollingConsumer(channel, handler); -endpoint.setMaxMessagesPerPoll(10); +consumer.setMaxMessagesPerPoll(10); -endpoint.setReceiveTimeout(5000); - A polling consumer may even delegate to a Spring TaskExecutor and +consumer.setReceiveTimeout(5000); + A Polling Consumer may even delegate to a Spring TaskExecutor and participate in Spring-managed transactions. The following example shows the configuration of both: -PollingConsumerEndpoint endpoint = new PollingConsumerEndpoint(consumer, channel); +PollingConsumer consumer = new PollingConsumer(channel, handler); TaskExecutor taskExecutor = (TaskExecutor) context.getBean("exampleExecutor"); -endpoint.setTaskExecutor(taskExecutor); +consumer.setTaskExecutor(taskExecutor); PlatformTransactionManager txManager = (PlatformTransationManager) context.getBean("exampleTxManager"); -endpoint.setTransactionManager(txManager); - The examples above show dependency lookups, but keep in mind that these endpoints will most often be configured +consumer.setTransactionManager(txManager); + The examples above show dependency lookups, but keep in mind that these consumers will most often be configured as Spring bean definitions. In fact, Spring Integration also provides a - FactoryBean that creates the appropriate endpoint type based on the type of + FactoryBean that creates the appropriate consumer type based on the type of channel, and there is full XML namespace support to even further hide those details. The namespace-based configuration will be featured as each component type is introduced. - Interestingly, many of the MessageConsumer implementations are also capable of - generating reply Messages. As mentioned above, sending Messages is trivial when compared to the Message - reception. Nevertheless, when and how many reply Messages are sent - depends on the consumer type. For example, an Aggregator waits for a number of Messages to - arrive and is often a downstream consumer for a Splitter which may generate multiple - replies for each Message it consumes. When using the namespace configuration, you do not strictly need to know + Many of the MessageHandler implementations are also capable of generating reply + Messages. As mentioned above, sending Messages is trivial when compared to the Message reception. Nevertheless, + when and how many reply Messages are sent depends on the handler + type. For example, an Aggregator waits for a number of Messages to arrive and is often + configured as a downstream consumer for a Splitter which may generate multiple + replies for each Message it handles. When using the namespace configuration, you do not strictly need to know all of the details, but it still might be worth knowing that several of these components share a common base - class, the AbstractReplyProducingMessageConsumer, and it provides a + class, the AbstractReplyProducingMessageHandler, and it provides a setOutputChannel(..) method. @@ -134,8 +134,8 @@ endpoint.setTransactionManager(txManager); Throughout the reference manual, you will see specific configuration examples for endpoint elements, such as router, transformer, service-activator, and so on. Most of these will support an "input-channel" attribute and many will support an "output-channel" attribute. After being parsed, these endpoint elements produce an instance - of either the PollingConsumerEndpoint or the - SubscribingConsumerEndpoint depending on the type of the "input-channel" that is + of either the PollingConsumer or the + EventDrivenConsumer depending on the type of the "input-channel" that is referenced: PollableChannel or SubscribableChannel respectively. When the channel is pollable, then the polling behavior is determined based on the endpoint element's "poller" sub-element. For example, a simple interval-based poller with a 1-second interval would be @@ -162,7 +162,7 @@ endpoint.setTransactionManager(txManager); ]]> - The polling threads may be executed by any instance of Spring's TaskExceutor + The polling threads may be executed by any instance of Spring's TaskExecutor abstraction. This enables concurrency for an endpoint or group of endpoints. As a convenience, there is also namespace support for creating a simple thread pool executor. The <thread-pool-task-executor/> element defines attributes for common concurrency settings such as core-size, max-size, and queue-capacity. Configuring @@ -179,13 +179,10 @@ endpoint.setTransactionManager(txManager); queue-capacity="20" keep-alive-seconds="120"/> ]]> - If no 'task-executor' is provided, the endpoint's consumer will be invoked in the caller's thread. Note that the + If no 'task-executor' is provided, the consumer's handler will be invoked in the caller's thread. Note that the "caller" is usually the MessageBus' task scheduler. Also, keep in mind that the 'task-executor' attribute can provide a reference to any implementation of Spring's TaskExecutor interface by specifying the bean name. The thread pool elements is simply provided for convenience. - - The poller accepts a few other configuration attributes... -
\ No newline at end of file diff --git a/spring-integration-reference/src/overview.xml b/spring-integration-reference/src/overview.xml index d785e7b5d5..b3d8740834 100644 --- a/spring-integration-reference/src/overview.xml +++ b/spring-integration-reference/src/overview.xml @@ -180,7 +180,7 @@
- Message Transformer + Transformer A Message Transformer is responsible for converting a Message's content or structure and returning the modified Message. Probably the most common type of transformer is one that converts the payload of the Message from one @@ -190,7 +190,7 @@
- Message Filter + Filter A Message Filter determines whether a Message should be passed to an output channel at all. This simply requires a boolean test method that may check for a particular payload content type, a property value, the @@ -208,7 +208,7 @@
- Message Router + Router A Message Router is responsible for deciding what channel or channels should receive the Message next (if any). Typically the decision is based upon the Message's content and/or metadata available in the Message Headers. @@ -224,7 +224,7 @@
- Message Splitter + Splitter A Splitter is another type of Message Endpoint whose responsibility is to accept a Message from its input channel, split that Message into multiple Messages, and then send each of those to its output channel. This @@ -234,7 +234,7 @@
- Message Aggregator + Aggregator Basically a mirror-image of the Splitter, the Aggregator is a type of Message Endpoint that receives multiple Messages and combines them into a single Message. In fact, Aggregators are often downstream consumers in a