From bb5e5dbdf14f380685dff996496305b766a0f446 Mon Sep 17 00:00:00 2001 From: Mark Fisher Date: Mon, 22 Nov 2010 18:46:08 -0500 Subject: [PATCH] INT-1552 doc polishing --- .../reference/docbook/service-activator.xml | 34 ++++++++++--------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/docs/src/reference/docbook/service-activator.xml b/docs/src/reference/docbook/service-activator.xml index b8aabd9f4e..37bc0898f3 100644 --- a/docs/src/reference/docbook/service-activator.xml +++ b/docs/src/reference/docbook/service-activator.xml @@ -33,28 +33,30 @@ "output-channel" was provided in the endpoint configuration: <service-activator input-channel="exampleChannel" output-channel="replyChannel" ref="somePojo" method="someMethod"/> - If no "output-channel" is available, it will then check the Message's REPLY_CHANNEL header + If no "output-channel" is available, it will then check the Message's replyChannel header value. If that value is available, it will then check its type. If it is a MessageChannel, the reply message will be sent to that channel. If it is a String, then the endpoint will attempt to resolve the channel name to a channel instance. If the channel cannot be resolved, then a ChannelResolutionException will be thrown. + It it can be resolved, the Message will be sent there. This is the technique used for Request Reply messaging + in Spring Integration, and it is also an example of the Return Address pattern. 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, @Headers annotations as described in + Integration. Arguments may also have @Header or @Headers annotations as described in - 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, + The service method is not required to have any arguments at all, which means you + can 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. Using a "ref" attribute is generally recommended if the custom Service Activator handler implementation can be reused in other <service-activator> definitions. However if the custom Service Activator handler implementation - should be scoped to a single definition of the <service-activator>, you can use an inner bean definition: + is only used within a single definition of the <service-activator>, you can provide an inner bean definition: @@ -68,30 +70,30 @@ - Service Activators and Spring Expression Language (SpEL) + Service Activators and the Spring Expression Language (SpEL) - Since Spring Integration 2.0 Service Activators can also benefit from SpEL ()http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html - in several ways. + Since Spring Integration 2.0, Service Activators can also benefit from SpEL + (http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html). - First, you may now invoke any bean method without pointing to this bean via ref attribute or including it as an - inner definition. For example: + For example, you may now invoke any bean method without pointing to the bean via a ref attribute or including it as an + inner bean definition. For example: + expression="@accountService.processAccount(payload, headers.accountId)"/> ]]> - In the above configuration instead of injecting 'accountService' using ref or as inner bean we are simply using @beanId - notation and invoking a method which takes the type compatible with Message payload. - + In the above configuration instead of injecting 'accountService' using a ref or as an inner bean, + we are simply using SpEL's @beanId notation and invoking a method which takes a type compatible with Message payload. We + are also passing a header value. As you can see, any valid SpEL expression can be evaluated against any content in the Message. For simple scenarios your Service Activators do not even have to reference a bean if all logic can be encapsulated - by such expression. + by such an expression. ]]> - In the above configuration our service logic is to simply multiply the payload value by 2 and SpEL lets us handle it relatively easy. + In the above configuration our service logic is to simply multiply the payload value by 2, and SpEL lets us handle it relatively easy.