SOA vs EAI vs ESB

This post aims to bring clarity to terms EAI, ESB, SOA and provide a clear distinction.

SOA : Service Oriented Architecture
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.
I read a definition which is as follows :
"SOA is a loosely-coupled architecture designed to meet the business needs of the organization using services."

and in another definition some one says that

A Service Oriented Architecture is a structural style to establish information needs of a organization based on services.

See Something confuses here.In both the definition it is said that SOA is a style - loosely-coupled (which is a characteristic) versus structural style (architectural style would be better). There is difference here in business needs versus information needs, which is not quite the same. Business need can be having insight in how business is running in total or being flexible (agile) in running business processes. Information need can also be insight in how business is run in total and having services to provide this.

Now read this definition
"SOA is an enterprise architecture style, not an application architecture style." by Anne Thomas Manes from Burton group.

SOA is an architecture style, definitions above are right. and the reality is SOA is an architecture la style, where services play an important role, hence they are the building blocks to create a SOA.

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.

EAI : Enterprise Application Integration
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.

• HUB/SPOKE
  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 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.
  
• BUS
  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
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 two fold, 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.
Conclusion
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.