Software ESBs
The concept of the Enterprise Service Bus has emerged from the popular message buses of the Enterprise Application Integration world. With EAI as part of their heritage and with enterprise class messaging and a well-developed software development life cycle, the software ESBs boast the following advantages.

• Flexibility: They support extremely complex integration patterns. They not only have standards-based connectivity, but also the ability to expose business functions in a legacy or packaged application as a reusable service. Their support for emerging standards is usually stronger and accelerated in a timetable.
• Strong software development life cycle: The software ESBs usually include an integrated development environment with strong debugging, tracing abilities, and integration with source control environments. The deployment of new message flows for software ESBs can be part of the overall software development process.
• Efficient interoperability with architectural tools: To illustrate this point, let’s look at Service Component Architecture (SCA), which is a model for building systems using the SOA approach. With SCA, software ESBs may have the ability to consume the Service Assembly Models (SAM) created by architects to model services integration. SCA is a language independent mechanism to compose and deploy service networks.

Figure 1: A Service Assembly Model

• Tight integration with service registries and repositories: This makes it possible to introduce strong governance in deploying message flows as well as the automated service dependency associations.

Figure 2: Service dependencies through a meta-data repository

• Virtualized environments: One of the strongest advantages of the software ESB is its ability to take advantage of the virtualization wave that is sweeping data centers to make effective use of physical hardware and to reduce operational costs.

The software ESB approach comes with drawbacks too. It is unable to process XML at wire speed; it lacks the gatekeeping functions and depends on hardware for its setup. The use of a hardware appliance as a co-processor for the ESB can alleviate the limitation of wire speeds.

The Reference Architecture
From the discussion in the previous section, it should be clear that a hardware appliance is well suited for simple, high traffic, repeatable, brokering operations. It will perform the gatekeeping functions as an edge gateway. On the other hand, the software ESB fits well in providing service brokering, complex message processing, and comprehensive integration functionality.

 

Key Takeaways
Coming back to the title of the article, what do we get for our SOA – a hardware appliance or a software ESB? The answer is the usual: "It depends!"

You may start with the software ESB when service brokering and integration is the primary driving factor for a project, especially when services use is internal within an organization. For a smaller deployment in an organizational unit, it is possible to stick with just a software ESB, with the more traditional network firewalls providing the missing gatekeeping functions.

Start with the hardware appliance when perimeter security is a concern, the service consumers are in the extranet or a different organization, and the services have already been enabled for reuse. For small organizations where integration needs are very simple, it might suffice for service brokering as well. Ultimately the lack of the appliance's flexibility and an inability to support complex integration patterns will result in experiencing the need for a software ESB.

The hardware appliance is a perfect gatekeeper at the perimeter while the software ESB is a perfect services broker. A full-blown infrastructure will typically deploy a hardware appliance–based solution at the perimeter with a software ESB doing service mediation, routing, protocol bridging, and services/application integration. Eventually for a fully baked SOA, both the appliances and software ESBs will play important and distinct roles.

It should also be noted that because of the stove-piped organizational structures in a lot of companies, federated ESBs will be inevitable. There could be a distinct ESB deployed for each organization or application domain. Not only can the ESBs be from different vendors, they could easily be a mix and match of hardware appliances and software ESBs in this federation.