Spring Integration with Gateways

This is the second article of the series on Spring Integration. This article builds on top of the first article where we introduced Spring Integration.

Context setting

In the first article, we created a simple java application where

1. A message was sent over a channel, 
2. It was intercepted by a service i.e. POJO and modified. 
3. It was then sent over a different channel
4. The modified message was read from the channel and displayed. 

However, in doing this - keeping in mind that we were merely introducing the concepts there - we wrote some Spring specific code in our application i.e. the test classes. In this article we will take care of that and make our application code as insulated from Spring Integration api as possible. 

This is done by, what Spring Integration calls gateways. Gateways exist for the sole purpose of abstracting messaging related "plumbing" code away from "business" code. The business logic might really not care whether a functionality is being achieved be sending a message over a channel or by making a SOAP call. This abstraction - though logical and desirable - have not been very practical, till now. 

It is probably worth having a quick look at the Spring Integration Reference Manual at this point. However, if you are just getting started with Spring Integration, you are perhaps better off following this article for the moment. I would recommend you get your hands dirty before returning to reference manual, which is very good but also very exhaustive and hence could be overwhelming for a beginner.

The gateway could be a POJO with annotations (which is convenient but in my mind beats the whole purpose) or with XML configurations (can very quickly turn into a nightmare in any decent sized application if unchecked). At the end of the day it is really your choice but I like to go the XML route. The configuration options for both styles are detailed out in this section of the reference implementation. 

Spring Integration with Gateways

So, let's create another test with gateway throw in for our HelloWorld service (refer to the first article of this series for more context). Let's start with the Spring configuration for the test. 

File: src/test/resources/org/academy/integration/HelloWorld1Test-context.xml

 
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
 xmlns:int="http://www.springframework.org/schema/integration"
 xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
http://www.springframework.org/schema/integration 
http://www.springframework.org/schema/integration/spring-integration-2.1.xsd">

 <int:channel id="inputChannel"></int:channel>

 <int:channel id="outputChannel">
  <int:queue capacity="10" />
 </int:channel>

 <int:service-activator input-channel="inputChannel"
  output-channel="outputChannel" ref="helloService" method="greet" />

 <bean id="helloService" class="org.academy.integration.HelloWorld" />

 <int:gateway service-interface="org.academy.integration.Greetings"
  default-request-channel="inputChannel" default-reply-channel="outputChannel"></int:gateway>

</beans>

In this case, all that is different is that we have added a gateway. This is an interface called org.academy.integration.Greetings. It interacts with both "inputChannel" and "outputChannel", to send and read messages respectively. Let's write the interface.

File: /src/main/java/org/academy/integration/Greetings.java

 
package org.academy.integration;

public interface Greetings {
 public void send(String message);

 public String receive();

}

And then we add the implementation of this interface. Wait. There is no implementation. And we do not need any implementation. Spring uses something called GatewayProxyFactoryBean to inject some basic code to this gateway which allows it to read the simple string based message, without us needing to do anything at all. That's right. Nothing at all.

Note - You will need to add more code for most of your production scenarios - assuming you are not using Spring Integration framework to just push around strings. So, don't get used to free lunches. But, while it is here, let's dig in.

Now, lets write a new test class using the gateway (and not interact with the channels and messages at all). 

File: /src/test/java/org/academy/integration/HelloWorld1Test.java

 
package org.academy.integration;

import static org.junit.Assert.*;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HelloWorld1Test {

 private final static Logger logger = LoggerFactory
   .getLogger(HelloWorld1Test.class);

 @Autowired
 Greetings greetings;

 @Test
 public void test() {
  greetings.send("World");
  assertEquals(greetings.receive(), "Hello World");
  logger.debug("Spring Integration with gateways.");
 }

}

Our test class is much cleaner now. It does not know about channels, or messages or anything related to Spring Integration at all. It only knows about a greetings instance - to which it gave some data by .send() method - and got modified data back by .receive() method. Hence, the business logic is oblivious of the plumbing logic, making for a much cleaner code.

Now, simply type "mvn -e clean install" (or use m2e plugin) and you should be able to run the unit test and confirm that given string "World" the HelloWorld service indeed returns "Hello World" over the entire arrangement of channels and messages.

Again, something optional but I highly recommend, is to run "mvn -e clean install site". This - assuming you have correctly configured some code coverage tool (cobertura in my case) will give you a nice HTML report  showing the code coverage. In this case it would be 100%. I have blogged a series on code quality which deals this subject in more detail, but to cut long story short, it is very important for me to ensure that whatever coding practice / framework I use and recommend use, complies to some basic code quality standards. Being able to unit test and measure that is one such fundamental check that I do. Needless to say, Spring in general (including Spring integration) passes that check with flying colours.

Conclusion

That's it for this article. Happy coding.

Suggested further reading ...
Here are the links to earlier articles in this series:

1. Hello World with Spring 3 MVC
2. Handling Forms with Spring 3 MVC
3. Unit testing and Logging with Spring 3 
4. Handling Form Validation with Spring 3 MVC
5. Introducing Spring Integration 

These are excellent material that I can recommend:

1. Getting started with Spring Integration
2. Sample codes with Spring Integration 
3. Spring Integration - Session 1 - Hello World
4. Spring Integration - Session 2 - More Hello Worlds

If you want to get in touch, you can look me up at Linkedin or Google + .