This chapter covers
21Say hello to Spring Integration
Message<String> message =
MessageBuilder.withPayload("World").build();
channel.send(message);
} }
Running that code produces “Hello World” in the standard output console. That’s pretty simple, but it would be even nicer if there were no direct dependencies on Spring Integration components even on the caller’s side. Let’s make a few minor changes to eradicate those dependencies.
First, to provide a more realistic example, let’s modify the HelloService interface so that it returns a value rather than simply printing out the result itself:
package siia.helloworld.gateway;
public class MyHelloService implements HelloService {
@Override
public String sayHello(String name) { return "Hello " + name;
} }
Spring Integration handles the return value in a way that’s similar to the Spring JMS support described earlier. You add one other component to the configuration, a gate-way proxy, to simplify the caller’s interaction. Here’s the revised configuration:
<beans:beans
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.springframework.org/schema/integration"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/
➥ spring-integration.xsd">
<gateway id="helloGateway"
service-interface="siia.helloworld.gateway.HelloService"
default-request-channel="names"/>
<channel id="names"/>
<service-activator input-channel="names" ref="helloService"
method="sayHello"/>
<beans:bean id="helloService"
class="siia.helloworld.gateway.MyHelloService"/>
</beans:beans>
Note that the gateway element refers to a service interface. This is similar to the way the Spring Framework handles remoting. The caller should only need to be aware of an interface, while the framework creates a proxy that implements that interface. The proxy is responsible for handling the underlying concerns such as serialization and
22 CHAPTER 1 Introduction to Spring Integration
remote invocation, or in this case, message construction and delivery. You may have noticed that the MyHelloService class does implement an interface. Here’s what the HelloService interface looks like:
package siia.helloworld.gateway;
public interface HelloService { String sayHello(String name);
}
Now the caller only needs to know about the interface. It can do whatever it wants with the return value. In the following listing, you just move the console printing to the caller’s side. The service instance would be reusable in a number of situations.
The key point is that this revised main method now has no direct dependencies on the Spring Integration API.
package siia.helloworld.gateway;
import org.springframework.context.ApplicationContext;
import
org.springframework.context.support.ClassPathXmlApplicationContext;
public class HelloWorldExample {
public static void main(String args[]) {
String cfg = "siia/helloworld/gateway/context.xml";
ApplicationContext context = new ClassPathXmlApplicationContext(cfg);
HelloService helloService =
context.getBean("helloGateway", HelloService.class);
System.out.println(helloService.sayHello("World"));
} }
As with any Hello World example, this one only scratches the surface. Later you’ll learn how the result value can be sent to another downstream consumer, and you’ll learn about more sophisticated request-reply interactions. The main goal for now is to provide a basic foundation for applying what you’ve learned in this chapter. Spring Integration brings the enterprise integration patterns and the Spring programming model together. Even in this simple example, you can see some of the characteristics of that programming model, such as IoC, separation of concerns, and an emphasis on noninvasiveness of the API.
1.5 Summary
We covered a lot of ground in this chapter. You learned that Spring Integration addresses both messaging within a single application and integrating across multiple applications. You learned the basic patterns that also describe those two types of interactions.
Listing 1.3 Hello World revised to use a Gateway proxy
23 Summary
As you progress through this book, you’ll learn in much greater detail how Spring Integration supports the various enterprise integration patterns. You’ll also see the many ways in which the framework builds on the declarative Spring programming model. So far, you’ve seen only a glimpse of these features, but some of the main themes of the book should already be clearly established.
First, with Spring’s support for dependency injection, simple objects can be wired into these patterns. Second, the framework handles the responsibility of invoking those objects so that the interactions all appear to be event-driven even though some require polling (control is inverted so that the framework handles the polling for you). Third, when you need to send messages, you can rely on templates or proxies to minimize or eliminate your code’s dependency on the framework’s API.
The bottom line is that you focus on the domain of your particular application while Spring Integration handles the domain of enterprise integration patterns. From a high-level perspective, Spring Integration provides the foundation that allows your services and domain objects to participate in messaging scenarios that take advantage of all of these patterns.
In chapter 2, we dive a bit deeper into the realm of enterprise integration. We cover some of the fundamental issues such as loose coupling and asynchronous mes-saging. This knowledge will help establish the background necessary to take full advantage of the Spring Integration framework.
24