Introduction

State-of-the-art IT integration is the implementation of Service-Oriented Architectures (SOAs) using web services technologies, and many excellent descriptions of their benefits and practice are available (see Resources). More recently, the concept of an Enterprise Service Bus (ESB) has been expressed as a key component of the SOA infrastructure (see Resources). However, it is important to clarify whether the ESB is a product, technology, standard, or something else. In particular, is the ESB something that can be built today, and if so, how?

This article describes the ESB as a set of infrastructure capabilities implemented by middleware technology that enable an SOA. The ESB supports service, message, and event-based interactions in a heterogeneous environment, with appropriate service levels and manageability. A variety of capabilities required to achieve this are summarized and categorized. However, not all are required in every situation in which an ESB can deliver value.

This article identifies a set of minimum capabilities that fulfill the most basic needs for an ESB consistent with the principles of SOA. Identifying these minimum capabilities allows you to identify which existing technologies to use to implement an ESB supporting an SOA. By considering how the requirements of a specific situation define the need for additional capabilities, you can then choose the most appropriate implementation technology for that situation.

I will define a set of ESB scenarios in SOA capturing common starting points for ESB or SOA implementation in following articles. The solution patterns, in turn, provide guidance for choosing appropriate implementation technologies.

As the uses to which an ESB solution is put evolve and mature, the capabilities required of it will also evolve. Similarly, the availability and capability of explicit ESB products will also mature. In the final article of this series, I will therefore consider a roadmap for SOA and ESB adoption to guide the initial use of ESB capabilities and technologies, and illustrate options for a gradual approach.

Back to top

The role of the ESB within an SOA

While I will not discuss the definition of SOA in depth (see Resources), it is useful to summarize here the principles that most descriptions of SOA agree with:

• The use of explicit implementation-independent interfaces to define services.
• The use of communication protocols that stress location transparency and interoperability.
• The definition of services that encapsulate reusable business function.

Figure 1 illustrates these principles. Note that while web services technology is an excellent match to these principles, it is not the only technology consistent with them.

In order to implement an SOA, both applications and infrastructure must support SOA principles. Enabling an application for SOA involves the creation of service interfaces to existing or new functions, either directly or through the use of adaptors. Enabling the infrastructure, at the most basic level, involves provision of the capabilities to route and deliver service requests to the correct service provider. However, it is also vital that the infrastructure supports the substitution of one service implementation by another with no effect to the clients of that service. This requires not only that the service interfaces be specified according to SOA principles, but also that the infrastructure allows client code to invoke services in a manner independent of the service location and the communication protocol involved. Such service routing and substitution are amongst the many capabilities of the ESB.

The ESB supports these service interaction capabilities, and provides the integrated communication, messaging, and event infrastructure to enable them. Thus, it combines the major enterprise integration patterns in use today into a single entity. The ESB provides an infrastructure for an SOA consistent with the needs of the enterprise, to provide suitable service levels and manageability, and to operate in a heterogeneous environment.

The remainder of this article will discuss this role of the ESB in SOA, including the capabilities it provides beyond basic routing and transport, as described in a capability model for the ESB below. The remainder of this article will discuss this role of the ESB in SOA, including the capabilities it provides beyond basic routing and transport, as described in the section capability model for the ESB below.

The structure of the ESB

The ESB is sometimes described as a distributed infrastructure, and contrasted against other solutions, such as message brokering technologies, commonly described as hub-and-spoke. However, this is a false distinction. Two different issues are being addressed: the centralization of control, and the distribution of infrastructure. Both ESB and hub-and-spoke solutions centralize control of configuration, such as the routing of service interactions, the naming of services, and so forth. Similarly, both solutions might deploy in a simple centralized infrastructure, or in a more sophisticated, distributed manner. Figure 2 illustrates this point.

Of course, different technologies will have different constraints on the physical deployment patterns they support -- some might be suited to very widespread distribution to support integration over large geographical areas, while others might be more suited to deployment in localized clusters to support high-availability and scalability. Matching the requirements for physical distribution to the capabilities of candidate technologies is an important aspect of ESB design. Also important is the ability to incrementally extend the initial deployment to reflect evolving requirements, to integrate additional systems, or to extend the geographical reach of the infrastructure.

I should also position the ESB in relation to other components in the SOA infrastructure, in particular, the Service Directory, Business Service Choreography, and Business-to-Business (B2B) Gateway components. Since the SOA principles above do not strictly require these components, let's treat them as optional components. Figure 3 shows an SOA indicating the relationship of these components to the ESB.

The ESB requires some form of service routing directory in order to route service requests. However, an SOA might also have a separate business service directory, which, in its most basic form, might be a design-time service catalog used to achieve reuse of services across the development activities of an organization. The vision of web services places a UDDI directory in the role of both the business service directory and service routing directory roles, thus enabling the dynamic discovery and invocation of services. Such a directory might be viewed as part of the ESB; however, until such solutions become common, the business service directory is likely to be separate from the ESB.

The role of the Business Service Choreographer is to compose business processes from several business services; it will, therefore, invoke services through the ESB, and then expose the business process as other services available to clients, again through the ESB. However, its role in choreographing business processes and services identifies the Business Service Choreographer, a business workflow technology, as separate from the ESB, an infrastructure technology.

Finally, the role of a B2B Gateway component is to make the services of two or more organizations available to each other in a controlled and secure manner. It is useful to view such components as connected to the ESB, but not part of it. While gateway technologies exist that provide capabilities suitable for implementing both B2B Gateway components and the ESB, the purpose of the B2B Gateway component separates it from the ESB. Indeed, this purpose might require additional capabilities, such as partner relationship management, that would not be part of an ESB and not necessarily supported by ESB technologies.

A capability model for the ESB

Table 1 summarizes and categorizes some of the ESB capabilities identified in existing literature (see Resources). While some are quite basic, others, such as autonomic or intelligent capabilities, represent significant steps towards an On Demand operating environment. It is important to recognize that most current ESB scenarios require only a subset of these capabilities within a subset of these categories. The minimum capabilities required for an ESB implementation are considered in the section The minimum capability ESB Implementation for SOA below.

Many of these capabilities can be implemented either using proprietary technologies, or through the use of open standards. However, the various technology candidates for ESB implementation might vary considerably in their performance, scalability, and availability characteristics, as well as in the ESB capabilities and open standards they support. Because of this, and the fact that some of the relevant standards are recent or still emerging, many critical decisions in implementing the ESB today are concerned with the trade-off between more mature, proprietary technologies and less mature open-standard support.

In this series of articles, I will not discuss each of these capability categories in detail. Rather, I will focus on those that drive decisions between different approaches to adopt or implement an ESB. In particular, in the next section, I will discuss what constitutes the minimum capabilities that an ESB requires in order to support an SOA.

The minimum capability ESB implementation for SOA

If only a subset of the capabilities identified earlier are relevant to most SOA scenarios, we can ask: what constitutes the minimum set of capabilities that are required in order to implement an ESB? In order to do this, consider the most commonly agreed elements of the ESB definition:

• The ESB is a logical architectural component that provides an integration infrastructure consistent with the principles of SOA.
• SOA principles require the use of implementation-independent interfaces, communication protocols that stress location-transparency and interoperability, and service definitions that are relatively coarse-grained and encapsulate reusable function.
• The ESB might be implemented as a distributed, heterogeneous infrastructure.
• The ESB provides the means to manage the service infrastructure and the capability to operate in the distributed, heterogeneous environment of today.

Table 2 illustrates the minimum ESB capabilities defined from those principles.

Note that these minimum capabilities do not require the use of particular technologies, such as EAI middleware, web services, J2EE, or XML. The use of those technologies is very likely, as they fit the requirements well, but it is not mandatory. Conversely, the minimum capabilities are nearly, but not wholly, fulfilled by the simple use of SOAP/HTTP and WSDL:

• URL addressing and the existing HTTP and DNS infrastructure provide a "bus" infrastructure with routing services and location transparency.
• SOAP/HTTP supports the Request-Response messaging paradigm.
• The HTTP transport protocol is widely available.
• SOAP and WSDL are an open, implementation-independent service messaging and interfacing model.

However, this basic use of SOAP/HTTP and WSDL is really just point-to-point integration, and does not fulfill some key capabilities required of an ESB:

• No administration capability to control service addressing and naming exists. Service names are controlled individually by each adaptor, and service routing control is dispersed between the addresses invoked by service clients, the HTTP infrastructure, and the service names assigned to adaptors.
• While dependent on implementation details, this approach does not tend to facilitate the substitution of service implementations; service requester code (perhaps generated by development tools) will often bind directly to specific service provider implementations through specific protocols at specific addresses. Substituting one service implementation for another will require changes to and redeployment of the application code.

Of course, further capabilities are required in many or even most scenarios, and will become increasingly common. In particular, the following types of requirements are likely to lead to the use of more sophisticated technologies, either now or over time:

• Quality of Service and Service Level capabilities.
• Higher level SOA concepts, for example service choreography, directory, transformations, and so forth.
• On Demand operating environment requirements, such as Management and Autonomic capabilities as well as Infrastructure Intelligence capabilities.
• Truly heterogeneous operation across multiple networks, multiple protocols, and multiple domains of disparate ownership.

Back to top

Security issues affecting the ESB

I won’t directly address security requirements here; however, they are likely to be important to the choice of ESB technology. For example, if no authentication or authorization of service requests is required, the choice of technology can be very broad. More likely, if some level of security is required, it is important to assess what style of security will be acceptable. For example:

1. Is security in the communications infrastructure acceptable, for example, in the use of Secure Socket Layer mutual authentication between EAI middleware servers, or in the use of the HTTPS protocol?
2. Is individual, point-to-point security acceptable between participating systems, or is an end-to-end model required? For example, is there a need to propagate client identity through intermediate systems such as brokers to the end-providers of service implementations?
3. Is security in the application layer acceptable, for example, can the client code perform basic HTTP authentication with a userid and password, or can it pass such information to the service as application data?
4. Is compliance to a security standard security, such as Kerberos or WS-Security, required?

While all of these approaches are possible, the industry direction is towards standards-compliant security (for example, WS-Security) features supported by infrastructure and middleware. However, these standards are relatively recent, and product support for them is still emerging rather than established, particularly where interoperability is concerned. Thus, one priority of any ESB architecture should thus be to establish the security requirements as early as possible, so that they can be included in the choice of implementation technology.

Back to top

Summary

In this article, I have discussed the most common principles of SOA, and how they relate to web services technology. Based on these principles, I have described a need for an infrastructure component that provides a routing capability to allow services to interact with each other, as well as to support substitution of one service implementation by another. These capabilities are among those implemented by an ESB.

The ESB provides a distributed infrastructure while maintaining centralization of control, requiring some form of service routing directory and perhaps a business service directory as well. The Business Service Choreographer invokes services from the ESB and then exposes processes as new services through the ESB.

The many capabilities of the ESB include provisions for:

• Communications
• Service interactions
• Integration
• Quality of services
• Security
• Service level
• Message processing
• Management and autonomic services
• Modeling
• Infrastructure intelligence

From these diverse capabilities, I defined the minimum capabilities to establish an ESB as providing for communication, integration, and service interactions.

In the next part of this series, I will discuss the common scenarios, the relevant solution patterns for these scenarios, and will look at the most common issues affecting these scenarios.

Back to top

Acknowledgements

This article would not exist without the discussions the author has been involved in with the following people, all of whom contributed to the ideas and thinking behind it: Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren, Daniel Sturman, Scott Cosby, Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf, Ken Wilson, Mark Endrei, Norbert Bieberstein, Chris Nott, Alan Hopkins, and Yaroslav Dunchych.

Resources

• For more details on Enterprise Service Bus, see "Understand Enterprise Service Bus scenarios and solutions in service-oriented architecture" Part 2 and Part 3 (developerWorks, 2004).
  
  
• To learn how Web Services technologies provide the compelling foundation for implementing Web Service-oriented architectures, read Web Service-Oriented Architecture - The Best Solution to Business Integration by Annrai OToole.
  
  
• Check out the article SOA - Save Our Assets by Lawrence Wilkes at CBDI Forum (subscription required).
  
  
• Patterns: Service-oriented Architecture and Web Services Redbook, SG24-6303-00, April 2004, Endrei M., et al.
  
  
• Read about "Migrating to a service-oriented architecture, Part 1" (developerWorks, December 2003) and "Migrating to a service-oriented architecture, Part 2" (developerWorks, December 2003).
  
  
• Visit LooselyCoupled.com for a list of Enterprise Service Bus links.
  
  
• The original Gartner article defining the Enterprise Service Bus requires a subscription, but can be found by searching their site, and is entitled Predicts 2003: Enterprise Service Buses Emerge, published, 9th December 2002, by Roy W. Schulte.
  
  
• Examine the IBM Patterns for e-business website.
  
  
• The material used in this article is from the forthcoming Redbook, Patterns: Implementing an SOA using an Enterprise Service Bus, SG24-6346-00, Draft, Martin Keen, et al.
  
  
• Find additional SOA and web services technology resources on the developerWorks SOA and web services technology zone.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• The role of the ESB within an SOA
• Security issues affecting the ESB
• Summary
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers