Spring Integration - Spring Enterprise Recipes: A Problem Solution Approach - page 312

Building on an ESB Solution
Now that you know how you want to approach the integration, it's all about actually implementing it.
You have many choices in today's world. If the requirement is common enough, most middleware or
frameworks will accommodate it in some way. JEE, .NET, and others handle common cases very well:
SOAP, XMLRPC, a binary layer such as EJB or binary remoting, JMS, or a MQ abstraction. If, however,
the requirement is somewhat exotic, or you have a lot of configuration to do, then perhaps an ESB is
required. An ESB is middleware that provides a high level approach to modeling integrations, in the
spirit of the patterns described by EAI . The ESB provides and manageable configuration format for
orchestrating the different pieces of an integration in a simple high-level format.
Spring Integration, an API in the SpringSource Portfolio, provides a robust mechanism for modeling
a lot of these integration scenarios that work well with Spring. Spring Integration has many advantages
over a lot of other ESBs, especially the lightweight nature of the framework. The nascent ESB market is
filled with choices. Some are former EAI servers, reworked to address the ESB-centric architectures.
Some are genuine ESBs, built with that in mind. Some are little more than message queues with
adapters.
Indeed, if you're looking for an extraordinarily powerful EAI server (with almost integration with
the JEE platform and a very hefty price tag), you might consider Axway Integrator. There's very little it
can't do. Vendors such as TIBCO and WebMethods made their marks (and were subsequently acquired)
because they provided excellent tools for dealing with integration in the enterprise. These options,
although powerful, are usually very expensive and middleware-centric: your integrations are deployed
to the middleware.
Standardization attempts, such as JBI, have proven successful to an extent, and there are good
compliant ESBs based on these standards (OpenESB, and ServiceMix, for example). One of the thought
leaders in the ESB market is the Mule ESB, which has a good reputation; and is free/open source
friendly, community-friendly, and lightweight. These characteristics also make Spring Integration
attractive. Often, you simply need to talk to another open system, and you don't want to requisition
a purchase approval for middleware that's more expensive than some houses!
Each Spring Integration application is completely embedded and needs no server infrastructure.
In fact, you could deploy an integration inside another application, perhaps in your web application
endpoint. Spring Integration flips the deployment paradigms of most ESBs on their head: you deploy
Spring Integration into your application; you don't deploy your application into Spring Integration.
There are no start and stop scripts, and no ports to guard.
The simplest possible working Spring Integration application is a simple Java public static void
main() method to bootstrap a Spring context:
package com.apress.springenterpriserecipes.springintegration;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Main {
public static void main(String [] args){
String nameOfSpringIntegrationXmlConfigurationFile = args[0];
ClassPathXmlApplicationContext applicationContext = new
ClassPathXmlApplicationContext(
nameOfSpringIntegrationXmlConfigurationFile) ;
applicationContext.start();
}
}
You created a standard Spring application context and started it. The contents of the Spring
application context will be discussed in subsequent recipes, but it's helpful to see how simple it is. You
might decide to hoist the context up in a web application, an EJB container, or anything else you want.