This paper aims to bring clarity to terms EAI, ESB, SOA and provide a clear distinction. Also this paper would discuss architecture options available for enterprise integration and what these options are most suitable for. Finally this paper would address the discussions we have seen in various forums about whether EAI is going to be replaced by SOA or ESB.


Service oriented architecture is approach to have software resources in an enterprise available and discoverable on network as well defined services. Each service would achieve a predefined business objective and perform discrete units of work. The services are independent and do not depend on the context or state of the other services. They work within distributed systems architecture.

Earlier SOA used COM or ORB based on CORBA specifications and recent SOA stress on web services using standard description (WSDL), discovery (UDDI) and messaging (SOAP).Service oriented architecture may or may not use web services but yes web services provide a simple way towards service oriented architecture albeit with the age old security and reliability limitations.


Enterprise application integration is a business need to make diverse applications in an enterprise including partner systems to communicate to each other to achieve a business objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves. I have seen people saying that EAI is a thing of past now SOA is here, it is just like saying “transportation is a thing of past now road is here”.

EAI comprises of message acceptance, transformation, translation, routing, message delivery and business process management. Usually messages transportation is asynchronous but for a business need it can be synchronous as well. There are two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.

[caption id=”attachment_167” align=”alignleft” width=”150” caption=”HUB/SPOKE”]HUB/SPOKE[/caption]


Hub/Spoke architecture uses a centralized broker (Hub) and adapters (Spoke) which connect applications to Hub. Spoke connect to application and convert application data format to a format which Hub understands and vice versa. Hub on the other hand brokers all messages and takes care of content transformation/translation of the incoming message into a format the destination system understands and routing the message. Adapters take data from source application and publish messages to the message broker, which, in turn, does transformation/translation/routing and passes messages to subscribing adapter which sends it to destination application(s). Having a single Hub makes system with this architecture easy to manage but scalability takes a hit. At some point of time as number of messages increase, scalability gets dependent on hardware. Having a bigger box to scale application has never been an ideal solution so to overcome this limitation most vendors have incorporated the concept of federated hub and spoke architecture in which multiple hubs can be present; each hub would have local metadata and rules as well as global metadata. Changes to global rules and metadata are automatically propagated to other EAI vs. SOA vs. ESB hubs. Federated hub spoke architecture alleviates scalability issue while central management of multiple hubs makes this architecture easy to manage and brings down support cost.

[caption id=”attachment_170” align=”alignleft” width=”150” caption=”Bus”]Bus[/caption]


Bus architecture uses a central messaging backbone (bus) for message propagation. Applications would publish messages to bus using adapters. These messages would flow to subscribing applications using message bus. Subscribing applications will have adapters which would take message from bus and transform the message into a format required for the application. Key difference between hub/spoke and bus topology is that for the bus architecture, the integration engine that performs message transformation and routing is distributed in the application adapters and bus architecture requires an application adapter to run on the same platform as the original applications. Since adapters have integration engine and run on same platform on which source and target applications run, this scales much better and is complex to maintain compared to hub/spoke topology.

ESB:Enterprise service bus is an infrastructure to facilitate SOA. It gives API which can be used to develop services and makes services interact with each other reliably. Technically ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from various services and application which are linked to ESB.Current EAI landscape is seeing many vendors who offer enterprise service bus and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based implementations which have been there in market for quite a long time now. Actually there is not much difference between ESB and proprietary buses except for a few subtle ones. Main difference between ESB and proprietary bus implementation is of cost which is significantly low for ESB. Reason for this cost difference is twofold, first proprietary bus offers lot of built in functionalities as a suit of product which need to be developed for ESB implementations based on business requirement, second most proprietary buses use some proprietary formats to enhance the performance and that increases the cost. ESB on the other hand is usually standard based, so it is a tradeoff between performance and cost between proprietary bus and ESB. Main advantage of ESB is that it costs much less then hub/spoke or bus based product suits and that it is standard based.


Following table give a quick comparison of hub/spoke, bus based product suits and ESB. Also all these three architectures can be service oriented depending on implementation which is reflected in this comparison.

Evaluation Bus Architecture

Hub Architecture

Evaluation Bus Architecture

Proprietary bus based product suit


Installation Effort

Less installation effort compared to solutions with bus architecture




Easy to maintain because of central HUB

Complex Administration depending on integration

Complex Administration depending on integration










Mostly standard basedbut may useproprietary internal formats

Mostly standard basedbut may useproprietary internal formats

Standard Based


Can be Implemented as SOA


SOA brings cost effective, reusable and low lead time solutions to an organization but EAI and SOA are both going to coexist. Web services alone as SOA can not handle the complex,secure and SLA based applications of an enterprise currently and unless we see a technological break through it is going to remain that way.Enterprise service bus would enable low cost integration and would be used by companies with limited IT resources and environments that involve a handful of systems and moderate transaction volumes. Packaged EAI solutions would have SOA as basic tenet and would continue to be used for large scale integration by companies having huge number of diverse system and high transaction volumes. Next generation EAI solutions would use more and more of SOA to provide reliable, secure, low cost and flexible solutions.


  • SOA brings cost effective, reusable and low lead time solutions to an organization but EAI and SOA are both going to coexist.
  • SOA is more than web services, in fact web services alone cannot handle the complex, secure and SLA based applications of an enterprise.
  • Enterprise service bus would enable low cost integration and would be used by companies with limited IT resources
  • Packaged EAI solutions in future would have SOA as basic tenet and would continue to be the prime choice for large scale integration.
    From an Article published on internet

Cloud computing infrastructure tech&solution provider:

  • 3Tera - AppLogic grid OS used as cloud computing platform by service providers and enterprises
  • Appistry - Cloud computing middleware - Enables easily scalable cloud computing in the enterprise.
  • Cassatt - Cassatt Active Response platform enables administrators to set policies to power physical and virtual servers safely on and off and pool their computing resources.
  • CloudHan - Cloud tech and infrastructure consultant, in China.
  • CloudScale Networks - Cloud enabler. Currently in private ALPHA only
  • Joyent - Cloud Infrastructure (Accelerators), and consulting for developers and enterprise.
  • nScaled, Inc - Cloud related services such as Migrations, Deployment, Planning, Consulting
  • Q-layer - provides software for data centers that enables cloud computing, support VSAN, VLAN, VPDC, currently support VMware ESX.
  • Skytap - IaaS service optimized for QA, Training, Demo, and Ops Testing. Supports VMware, Xen hypervisors & Windows, Linux & Solaris OS guests.
  • Webscale Solutions - IT Strategy and Consulting on Cloud computing. Specialize in ROI investigations of CC. a CC provider evaluation framework and Enterprise Cloud Roadmap development.

Cloud computing infrastructure provider:

  • Agathon Group - Cloud provider. Services include highly available VPS, virtual private datacenters and ready-to-use LAMP stacks. Self-service ordering. Custom development and managed services available.
  • Amazon Web Services - Amazon EC2/S3 (Hardware-a-a-S & Cloud Storage)
  • CohesiveFT - CohesiveFT Elastic Server Factory - Webservice for assembling full application stacks (contextualization, custom apps, middleware, on top of base configs) with deployment to many virtual and cloud environs.
  • ElasticHosts - UK-based instant, on-demand servers in the cloud
  • Flexiscale - Another instant provisioner of web servers with some advanced features like auto-scaling coming soon.
  • GoGrid - instant, on-demand servers offering "control in the cloud". Deploy Windows/Linux servers via web-interface in minutes
  • GridLayer - Cloud Provider. A service by Layered Technologies that delivers Virtual Private Datacenters and virtual private servers from grids of commodity servers
  • LayeredTechnologies - Cloud Provider. provider of on-demand hosting and cloud and utility computing solutions through its brand GridLayer
  • ReliaCloud - Deployed within a robust and resilient virtualization environment and architected to maximize uptime and performance. Free benefits include high availability, load balancing, robust APIs, and persistent servers.
  • Mosso - Rackspace’s cloud hosting service
  • Newservers - Instant provisioning of web servers either Windows or Linux
  • Plura Processing - On-demand infrastructure for high-performance computing

Cloud computing Paas provider:

  • Aptana Cloud - Elastic Elastic Application Cloud™ featuring fully stacked and integrated PHP app engines, Ajax/Jaxer app engines, and soon Ruby on Rails app engines – ready to use and ready to scale as you need it.
  • Bungee Connect - Provides end to end tools and systems required to develop, deploy and host web applications (Platform as a Service)
  • Coherence - Oracle Coherence Data Grid for EC2 and other cloud platforms
  • -’s application development platform (PaaS)
  • GigaSpaces - middleware for the cloud, "cloudware"
  • Google AppEngine - (PaaS)Now support python
  • Heroku - Ruby on Rails in their Cloud
  • Morph Labs - Fully managed, open, elastically-scalable, end-to-end deployment and delivery platform for Ruby on Rails and Java (Jetty, JRuby, Groovy and Grails) web applications. Leverages AWS, but completely abstracts details and complexities from developers.
  • Intuit Partner Platform (IPP) - Platform as a Service (PaaS) from Intuit.
  • Qrimp - An AJAX based PaaS
  • RightScale - RightScale provides a platform and expertise that enable companies to create scalable web applications running on Amazon’s Web Services that are reliable, easy to manage, and cost less
  • Stax - Java Platform as a Service

Cloud computing based service provider:

  • CAM Solutions - Monitoring-as-a-Service(TM)
  • CloudStatus- CloudEnabler. Real-time performance trending of cloud infrastructure (currently AWS).
  • DATASiSAR - Cloud Computing technology based consulting & IT Services provider
  • Kaavo‘s IMOD is an easy to use online application. Cloud Computing Made Easy.
  • Microsoft Mesh
  • Nasstar - SaaS provider. Business grade Hosted Desktop service, UK market leaders.
  • Nirvanix - Cloud Storage
  • TrustSaaS - uptime monitoring and alerting service (‘SaaS Weather Report’) for Software as a Service (SaaS) run by an independent third party.
  • UtilityStatus - Utility Computing Platform for SaaS charged in elapsed CPU time running on EC2.

Semantic computing Cloud service provider:

  • ThoughtExpress - Generic Enterprise Management Service based in semantics supported by semantic computing cloud to perform enterprise information processing to deliver: BPM, BI, enterprise modelling & semantic human interface without the need to program.

Cloud Security Consultants and Overlay Network Providers
CohesiveFT - CohesiveFT’s VPN-Cubed products are virtual firewallls, switches, hubs, and routers that are used to build overlay networks in clouds, across clouds, and to connect enterprise data centers to public clouds.
Cloud End-Points:

  • XPack - a dedicated cloud end-point from Moderro Technologies. A solid-state, power-saving, VESA mountable desktop appliance with custom desktop environment designed for web applications.

Cheat sheet for your reference when you add libraries to your projects, this reference should avoid redundant jars from your projects

Following files are in the spring framework package.




It contains the entire Spring framework including everything in the other JAR files also.


It contains the core Spring container and its utilities.


It contains the bean Spring container and JavaBeans support utilities.


It contains Spring’s AOP framework, source-level metadata support, AOP Alliance interfaces etc.,


It contains application context, validation framework, JNDI, templating support and scheduling.


It contains DAO support and transaction infrastructure.


It contains the JDBC support.


It contains JMX support, JCA support, scheduling support, mail support and caching support.


It contains the web application context, multipart resolver, Struts support, JSF support and web utilities.


It contains the framework servlets, web MVC framework, web controllers and web views.


It contains remoting support, EJB support and JMS support.


It contains iBATIS SQL Maps support, Apache OJB support, TopLink support and JDO support.


It contains Hibernate 2.1 support, Hibernate 3.x support.


It contains JNDI mocks, Servlet API mocks and JUnit support.



The Core package is the most fundamental part of the framework and provides the IoC and Dependency Injection features. The basic concept here is the BeanFactory, which provides a sophisticated implementation of the factory pattern which removes the need for programmatic singletons and allows you to decouple the configuration and specification of dependencies from your actual program logic.

The Context package build on the solid base provided by the Core package: it provides a way to access objects in a framework-style manner in a fashion somewhat reminiscent of a JNDI-registry. The context package inherits its features from the beans package and adds support for internationalization (I18N) (using for example resource bundles), event-propagation, resource-loading, and the transparent creation of contexts by, for example, a servlet container.

The DAO package provides a JDBC-abstraction layer that removes the need to do tedious JDBC coding and parsing of database-vendor specific error codes. Also, the JDBC package provides a way to do programmatic as well as declarative transaction management, not only for classes implementing special interfaces, but for all your POJOs (plain old Java objects).

The ORM package provides integration layers for popular object-relational mapping APIs, including JPA, JDO, Hibernate, and iBatis. Using the ORM package you can use all those O/R-mappers in combination with all the other features Spring offers, such as the simple declarative transaction management feature mentioned previously.

Spring’s AOP package provides an AOP Alliance-compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code implementing functionality that should logically speaking be separated. Using source-level metadata functionality you can also incorporate all kinds of behavioral information into your code, in a manner similar to that of .NET attributes.

Spring’s Web package provides basic web-oriented integration features, such as multipart file-upload functionality, the initialization of the IoC container using servlet listeners and a web-oriented application context. When using Spring together with WebWork or Struts, this is the package to integrate with.

Spring’s MVC package provides a Model-View-Controller (MVC) implementation for web-applications. Spring’s MVC framework is not just any old implementation; it provides a clean separation between domain model code and web forms, and allows you to use all the other features of the Spring Framework.