Introducing the ESB

This page introduces WSO2 ESB in the following sections:

Overview

An enterprise service bus (ESB) is a software architecture construct that enables communication among various applications. Instead of having to make each of your applications communicate directly with each other in all their various formats, each application simply communicates with the ESB, which handles transforming and routing the messages to their appropriate destinations.

An ESB provides its fundamental services through an event-driven and standards-based messaging engine (the bus). Thanks to ESB, integration architects can exploit the value of messaging without writing code. Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards. As with a Service-Oriented Architecture (SOA), an ESB is essentially a collection of enterprise architecture design patterns that is now implemented directly by many enterprise software products.

WSO2 ESB is a fast, light-weight, and versatile enterprise service bus. It is 100% open source and released under the Apache License v2.0. Using WSO2 ESB you can perform a variety of enterprise integration patterns (EIPs), including filtering, transforming, and routing SOAP, binary, plain XML, and text messages that pass through your business systems by HTTP, HTTPS, JMS, mail, etc.

Distributed Computing Evolution

ESBs are part of an evolution of distributed computing. Early distributed computing involved pure point-to-point communication between systems. This was the simple, obvious way to create complex applications from distributed components. This is actually a reasonable solution when there are a small number of applications that need to work together. However, the number of point-to-point communications grows proportional to the square of the number of applications in the enterprise. This becomes unmanageable for a large enterprise.

The late 90's saw the rise of Enterprise Application Integration (EAI) products. These aimed to allow enterprises to scale beyond the limitations caused by point-to-point integration solutions. The typical solution used a hub-and-spoke architecture. This is a solution still in use by many enterprises today. In a hub-and-spoke EAI, all communication is routed through a central hub. The number of point-to-point communications scales linearly with the number of enterprises, so this is a great improvement over point-to-point architectures. However, the hubs become bottlenecks in the system.

ESBs can be thought of as the next step in the logical progression described above. The ESB acts as a message broker to all applications in the enterprise. It allows for more granular, base functions to be exposed with orchestration provided as needed. This greatly improves the flexibility of the system and allows for more rapid and cheaper adaptation to changes.

ESB in Context of SOA

Here is a list of functionality in an ESB runtime that encourage SOA:

• Message routing and distribution. The applications should not have hard-coded destinations for messages or services. The ESB can help in two ways:
  • by supporting virtualization (mapping logical destinations to real destinations) and
  • by supporting event architectures, where the publisher does not need to know about the subscribers.
• Management- The ESB should provide a common set of management capabilities which give a common view of all services and endpoints. This includes:
  • alerting,
  • statistics,
  • audit and
  • logging.
• Excellent support for the Web architecture - ESBs should encourage good use of HTTP and the Web architecture. Support for HTTP proxying and caching.
• XML performance- If an ESB is going to help manage and route XML messages then it has to do it with minimum overhead. It certainly has to be much more scalable and per formant than the applications it talks to. Fundamentally this promotes two key technical requirements:
  • non-blocking IO (meaning that the ESB must not block while waiting for applications to respond) and
  • Streaming XML (meaning that the ESB can send XML through without having to create a large in-memory buffer and fully parse every message).

• Security Control - Managing distributed security is one of the hardest problems in SOA and augmenting application security with a set of central security controls is often an essential component in an enterprise infrastructure.