Enterprise Integration Zone is brought to you in partnership with:

I like software - reading, tinkering, designing, coding. I have been doing so for 20 years or so and I would not mind continuing this for foreseeable future. Fortunately for me, this is my profession as well and I have managed to get paid for this for some 14 years now. Although I do not have any strong bias for any business domain, I have been working with some pretty big names in the finance domain and you might get a hint of that from my entries. Partha is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Spring Integration with Gateways

  • submit to reddit
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"  
 <int:channel id="inputChannel"></int:channel>  
 <int:channel id="outputChannel">  
  <int:queue capacity="10" />  
 <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>  
 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;  
public class HelloWorld1Test {  
 private final static Logger logger = LoggerFactory  
 Greetings greetings;  
 public void test() {  
  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.


That's it for this article. Happy coding.
Published at DZone with permission of Partha Bhattacharjee, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)