Defining the ESB

The ESB Solution

Fortunately, there are patterns and tools that can be used to manage, and even eliminate, the three challenges just discussed. Implementing patterns of reliable communication is the first step towards a robust distributed software system. Arguably, the most important part of a distributed software system is its communication infrastructure. It's therefore no coincidence that many of the advances in modern software architecture and development have centered on service-oriented architecture (SOA), enterprise messaging systems, and platform-neutral data structures and protocols. Examples of technologies in these areas are web services, the Java Message System (JMS), eXtensible Markup Language (XML), and the Simple Object Access Protocol (SOAP), respectively.

Smart people know that breaking a large problem into smaller pieces helps to solve the associated problem; the same principal applies to software. Therefore, the decomposition of software functionality into XML or SOAP-based web services is the second step towards a robust distributed software system. The resulting services can then be used together, in varying combinations, to solve even more problems than just the ones that inspired their creation.

Finally, the integration and proper orchestration of these services is the third step towards a robust distributed software system. Possessing, or having unlimited access to, any number of software services is useless if there is no reasonable way to aggregate them into a cohesive application. Patterns and standards for service integration and orchestration are a must.

So far I've identified three high-level patterns, or principals, that provide for robust distributed software: reliable communication; a service-oriented architecture; and service orchestration. Additionally, a tool is needed to enable these principals -- one that helps to reduce the complexity and costs associated with distributed software systems by implementing the three patterns just discussed. This tool is the Enterprise Service Bus. The ESB is both a tool and a software framework that helps you to create, deploy, and orchestrate (and communicate between) service components in a distributed system.

An enterprise service bus is a framework that consists of many capabilities from which you can pick and choose. You may decide to use only portions of the ESB feature-set (and to ignore others) perhaps out of necessity, or as a way of migrating existing software to it. The ESB can best be described as having these characteristics. It:

• Provides a reliable messaging infrastructure
• Enables SOA-based system development
• Is XML-based
• Supports web service standards (such as SOAP)
• Is platform independent
• Supports data transformation and routing services
• Enables service orchestration
• Supports transactions and security
• Integrates with existing standards, frameworks, and legacy systems

Serving as a visual summary, Figure 2 illustrates the issues and challenges I've discussed related to distributed-software development. Writing code to communicate over varying communication protocols directly with systems of differing architectures, and dealing with data in different formats, is costly and non-reusable.

Figure 2: Legacy distributed applications might contain custom code to communicate over various protocols, such as FTP, TCP/IP, UDP. EDI, and so on. With no standard data form, structure, or protocol, security and reliability needs to be built into each integration solution.

The cost of integrating new partner organizations may outweigh the benefits the partner may otherwise bring to the application, and more importantly, end-users.

Figure 3 is a revised version of Figure 2, but now with the ESB added along with the services it manages. With the ESB in the picture, you can begin to envision distributed application development and deployment differently. No longer are the communication lines between disparate systems hard-coded; you can orchestrate and aggregate services and applications in various ways, and change them, without modifying your code. This is a true paradigm shift compared to the classic client-server architecture in the previous diagram.

Figure 3: The enterprise service bus helps to eliminate the often duplicated work that goes into building reliable, secure, and expandable SOA-based distributed applications. It also helps you and your partners to cost-effectively integrate applications and services.

With the ESB, adapters connect disparate software, enterprise messaging systems can be leveraged, and services can be integrated without writing a single line of associated code. This lets you focus on the construction of services and their associated business logic and not on the costly chores that go into building a robust distributed system -- the ESB eliminates them. That solves the complexity issue.

The ESB provides authentication and authorization services, as well as secure channels for component communication, thus solving most security issues. It has the added benefit of ensuring that security is implemented consistently across all services and components that use the ESB.

Furthermore, the ESB performs these services flawlessly, end to end, through its built-in reliable messaging backbone. Because of this, reliability is virtually guaranteed to components built on the ESB. Additionally, the messages themselves, and the act of sending those messages, are normalized. This means that regardless of the initial form of the data you are sending between systems, and the form of communication a particular system is designed to use, the ESB transforms those messages and adapt various protocols to work together.