The enterprise service bus is commonly viewed as a single middleware software package that connects to the majority of, or all business applications within an organisation.

<a href=

Andrei Migatchev - Chief Technology Officer at Magix Integration" src="http://www.iweek.co.za/images/stories/2010/AndreiMigatchev.png" />The ESB facilitates data exchange between these applications. It commonly includes data transformation facilities, as well as various
adapters and connectors to enable connectivity to business applications and/ or their API technology stack.

Integration interfaces are then designed and deployed to this middleware software platform. More often than not, these interfaces follow the same principles as point-2-point interfaces, but use the functionality
of a middleware hub. Although this introduces a signifi cant improvement to the integration capability of an organisation, as well as providing a certain degree of standardisation to the data exchange, it still allows for business logic to reside in the middleware layer.

This architecture also allows for the middleware component to participate as an actor in the integration flows, triggering business events and providing business services within the middleware layer.

Topology of such architecture is commonly referred to as hub and spokes, which is one of the integration designs of a broader enterprise application integration (EAI) discipline. For the purposes of service-enablement of business applications, such fl exibility of a middleware platform is not required, and often creates more issues than it resolves. This is especially apparent once business logic creeps into the middleware layer from the application layer.

SOA offers a more flexible and efficient approach to EAI. A minimum requirement for successful SOA
deployment is an event-driven messaging engine with a service catalogue. Application services contain the business logic for data manipulation and processing once a message is received from any other service; however they delegate message transformation and routing to the service bus. These processes are abstracted from business services, which in essence only need to “know” how to put a message on a service bus for a specifi c recipient.

Beyond this, ESB software infrastructure also provides other support functions, such as service authentication and authorisation, channel confi dentiality, transaction handling, logging and monitoring, message prioritisation and performance throttling.

With this strict, standardsbased, minimalistic approach, ESB architecture enables an organisation to leverage easier adoption of requirements
changes. It enables scalability from a contained, application-centric deployment, to an enterprise wide
adoption of a distributed service bus or federated ESBs. Furthermore, the lack of a centralised rules-engine allows the interfaces to be confi gured, rather than developed or coded.

For the services that do not contain message-processing logic, such as legacy applications that rely on a single mechanism of data entry, a process broker can be introduced, coupled into the service bus.

Multiple ESBs can be introduced to combat the difficulty of maintaining a single middleware software
platform across the entire range of communication protocols, formats and technologies used within the organisation. More often than not enterprise business applications come with their own middleware subsystem, which has native connectivity and message transformation with the host application,  exposing its functionality as services.

However, multiple ESBs should always be federated, creating a single instance of a virtual ESB, rather than work in isolation from each other. Choosing and designing a correct ESB architecture for a specific SOA deployment within an organisation is a difficult process and is best achieved with an iterative  approach. Building a simple, yet robust and fl exible foundation is the first step in the process. This step will determine the success of SOA initiative in the organisation.