Introduction

IBM's stance on the ESB is—and always has been—that it plays a fundamental role as an architectural pattern within the SOA. ESB is an important entry point to successful SOA adoption and is a key success factor in any service-oriented solution. In fact, as part of its commitment to the ESB in SOA, IBM offers three strategic products that implement the ESB pattern.

Part 1 of this series describes how the Enterprise Service Bus (ESB) architectural pattern fits within the IBM SOA Foundation and how the ESB relates to other parts of the foundation.

This article covers the following topics:

• The value that a well-designed, well-implemented ESB can provide to a service-oriented solution
• Some best practices to follow when designing and implementing an ESB
• IBM's commitment to the ESB as part of SOA

ESB as it relates to SOA

The IBM SOA Foundation white paper describes IBM's holistic approach to delivering the value of SOA. The SOA Foundation's reference architecture (Figure 1 shows the Logical Model View) has ESB at its core. The description of the reference architecture states that "the presence of an ESB is fundamental to simplifying the task of invoking services." Though the white paper was published in late 2005, that premise has only been strengthened over time by our experiences with clients adopting SOA.

Part 1 of this series shows that the ESB is a key architectural pattern within the larger architectural pattern called SOA. The ESB, acting as an intermediary, supplies loosely coupled connectivity between the participants in service interactions and, thus, provides the backbone of an SOA. As an intermediary, the ESB performs service virtualization to mediate the differences between service requesters and service providers, and offers aspect-oriented connectivity to act as an enforcement point for SOA policies, such as management and security. The loose coupling permits a clean separation of concerns (temporal, technological, and organizational) between the parts in a solution to enable flexibility and agility in both business processes and IT systems.

Some benefits of the loose coupling enabled by the ESB, including those inherent in service virtualization and aspect-oriented connectivity (these are described in detail in Part 1 of this series), are:

• The requester and provider don't have to agree on the message format, message transport, or even the target address.
• A request message can be processed by any of multiple providers without explicit identification of the provider by the requester. This routing can be based on the appropriate version, quality of service, or other metrics.
• Existing requesters can be connected, without change, to new providers.
• Existing providers can be exposed, without change, to new requesters.
• Changes can be made to requesters without impacting providers or made to providers without impacting requesters.
• Cross-cutting aspects of a solution, such as security and management, can be added, enforced, or reinforced by the ESB.
• New levels of dynamic behavior can be achieved, because the ESB can enforce policy in real time for each interaction between requester and provider.

ESB as an SOA entry point

Adopting SOA all at once can be a daunting task. IBM has identified five SOA entry points that provide guidance on how to get started with SOA incrementally. Incremental adoption lets your business pursue SOA in a manner and at a pace that best suits your needs. Why do we identify five entry points? The simple reason is that one size doesn't fit all; businesses differ in their maturity level and specific needs, and what works for one may not work for another. The five entry points are based on the approaches that have led to successful implementation of SOA for our clients. There are two classes of entry points:

• Business-centric entry points — people, information, and processes — let you get started with an approach focused on the fundamental assets of your enterprise.
• IT-centric entry points — connectivity and reuse — allow you to lay the technical groundwork for SOA.

As you might anticipate from the SOA Foundation white paper, connectivity means using an ESB to "simplify your IT environment with a more secure, reliable, and scalable way to connect within and beyond your business." IBM believes that the ESB, while definitely an IT-centric approach to SOA, delivers "real business value on its own, [and] is a core building block for future SOA initiatives." A key question (addressed below) in this article is how you can best use an ESB to form the building block for future SOA initiatives, and how you can get the maximum business value through the connectivity entry point.

There are several ways to leverage the connectivity entry point. Sometimes clients already have some services defined in their environment (maybe via partners), though directly connected; this leads to lack of flexibility and increased management costs. Inserting an ESB into such an environment offers the immediate benefits of loose coupling, described above. Further, the presence of the ESB sets the stage for future work to define additional services, create additional reuse opportunities, support new channels for reuse, lower management costs, and derive more agility.

Customers are often aware of the value of the ESB and are eager to begin realizing benefits from it, but they don't yet have services defined in their environments. We've seen two successful techniques employed that help elicit benefits from the ESB in this situation. Clients frequently use a hybrid of the reuse and connectivity entry points. They identify the functions or applications they need to connect as services (requesters or providers). In parallel, they insert the ESB into the architecture to provide the desired loose coupling between the new service requesters and providers. An important factor in the popularity of a hybrid approach is the conversion and transformation capabilities of ESB products. Such capabilities make it possible to use the same ESB product as a form of adapter to expose functions or applications in a more reusable form and to offer the desired service virtualization and aspect-oriented connectivity. The key to success here is to start modestly, exposing a few services and developing the corresponding mediations, but within an architecture designed for the entire eventual scope in mind.

Some clients insert an ESB to establish the desired direction for connectivity in the organization, even though initially there are no identified services to connect. In this case, the ESB is part of an overall reference architecture for the organization; the reference architecture provides an architectural direction mandating loosely coupled connectivity for all services (requesters and providers) that are eventually created as part of the solution. The ESB is the preferred mechanism for implementing that loose coupling. Adopting an ESB in effect eliminates the potential for the insidious growth of direct connectivity in the solution. The keys to success here are:

• Adoption of a reference architecture that mandates and illustrates the use of the ESB.
• Consideration of the entire eventual scope of the solution, enabling the best choice of an ESB product.
• Strong governance as the solution evolves to ensure leveraging the ESB to connect new services (requesters and providers) introduced into the solution.

Back to top

Best practices for SOA entry points

There are a set of best practices that are strongly recommended by IBM for any SOA adoption. The most important element of these is the establishment of a roadmap defining an adoption plan that achieves the desired business goals and implement that roadmap incrementally (see the Resources section for a link to "Service Oriented Architecture: An Introduction for Managers"). There are two important parts to the roadmap:

1. A strategic vision, a business and IT statement of direction (including a reference architecture and governance plan) that can be used as a guideline for decision making, organizational buy-in, and standards adoption.
2. A set of project plans that define implementation projects to meet immediate and future needs of the current business drivers.

Such a roadmap lets you implement SOA incrementally to return business value at each project step.

You should identify the best SOA entry point for your business early in the execution of the roadmap. You should choose that entry point based on the requirements derived from your overall strategic vision and current level of SOA maturity. The entry point may or may not be connectivity; it may be a hybrid as described above. Connectivity, however, is a common entry point, because so many clients have an immediate need to connect requesters to providers and want the benefits of the loose coupling the ESB provides. IBM provides an online tool, the Business Value Analyzer, to help you select an SOA entry point.

Another best practice is to establish a governance framework to ensure that your organization follows the roadmap (see Resources for a link to "SOA Governance and Service Lifecycle Management"). The increased flexibility and cross-organizational nature that SOA facilitates requires that organizations establish a governance framework to implement active decision making, accurate tracking, improved serviceability, and better communication. Effective governance helps achieve your enterprise's business goals by adding value while balancing risk and return.

As suggested above, incremental adoption of SOA is the key to success. IBM recommends starting with a pilot project that:

• Addresses a well-understood, significant, but not critical business need.
• Implements some key aspect of the reference architecture (perhaps the ESB and a set of example services, providers, and requesters, which illustrate its use).
• Requires an achievable stretch beyond current capabilities.
• Builds SOA skills.
• Acts as a pilot for adopting SOA governance and new service life cycle management processes.
• Results in something that you'll put into production and that will deliver return on investment.

The separation of concerns possible with SOA lets even a pilot project introduce SOA in a way that allows building expertise and verifies the business value, but doesn't disrupt major operations.

Back to top

Best practices for the connectivity SOA entry point

Beyond the SOA best practices, there are others more specific to the ESB:

• Adopt ESB only when it makes sense in your roadmap. For example, if your SOA entry point is business centric, you can defer loose coupling via the ESB, even though the ESB is included in your reference architecture.
• Architect the ESB and make your ESB product selection based on your reference architecture and a realistic set of requirements across the complete set of project plans. We say realistic because you should focus on what you'll need in the next few years; by the time you get beyond that time scale, the products and requirements will have changed. Considering only immediate requirements, and especially ignoring the anticipated needs of the service requesters and providers, can result in the selection of a less-than-optimal ESB product. You must obviously live within corporate constraints, such as yearly funding cycles and budgets, but at the same time you want to align your short-term purchases and decisions with a longer-term (three-to-five year) goal in mind.
• Consider ESB federation as appropriate. Larger, heterogeneous enterprises often appear as a federation of somewhat autonomous domains based on lines of business or functional or governance areas. In such environments, some services may be shared or reused within only a single domain, while others may be shared or reused throughout the enterprise. In these situations, we recommend some form of ESB federation that matches the needs of the domain federation. ESB federation allows different ESB products to be used in different domains, enabling an optimal match between domain requirements and product capabilities. The roadmap and reference architecture should provide guidelines, and even options, for product selection for any given domain to ensure enterprise-wide optimization. We further recommend using a federated service registry and repository to assist enterprise-wide management and governance of reusable services.

Back to top

Do you need an ESB to be successful with SOA?

The previous sections showed that it's possible to start a successful SOA journey with the ESB. The other four entry points don't require an ESB to begin the journey. IBM believes, however, that the vast majority of mature service-oriented solutions, no matter what the entry point, will include an ESB to maximize the agility and flexibility desired from SOA. Thus, while your initial projects may not include an ESB, the ESB should be part of the reference architecture in your long-term business and IT roadmap to achieve a successful SOA. Without the agility and flexibility supplied by an ESB, you can find it difficult and costly to manage your solution in the face of the inevitable need for change.

Does this mean you don't have a true SOA in place until you have all of your architecture components, including an ESB, in place? There's no right or wrong answer to this question, and many opinions exist. To some degree it doesn't matter—what matters is that you incrementally deliver more and more value to your business as you implement new SOA projects and as your solution matures according to your roadmap.

Our clients seem to agree. Virtually all of our customers who adopt SOA start with or eventually use an ESB in their solutions and derive significant IT and business value from the flexibility and agility the ESB enables.

Back to top

IBM's ESB product family

Indicative of the importance IBM places on ESB and its commitment to the ESB is how we fulfill the promise of the SOA Foundation with products. IBM offers a family of three products that implement the ESB architectural pattern:

• IBM WebSphere® Message Broker, a mature product, has implemented the pattern for many years.
• IBM WebSphere Enterprise Service Bus, available since 2005, was designed specifically to implement the pattern in a standards-focused environment.
• IBM WebSphere DataPower Integration Appliance XI50, available since 2006, encapsulates the pattern in the form of an easily deployed and managed appliance.

Why three products? Once again, one size doesn't fit all. All three products implement the ESB pattern but emphasize specific features to make them better suited for specific situations. You'll find many articles on developerWorks and many IBM Redbooks® written to support the use of these products in service-oriented solutions.

Back to top

Conclusion

This article has reinforced IBM's continued belief that the ESB is a fundamental architectural pattern within the larger pattern called SOA. You've read about how an ESB contributes to the business value derived from SOA and how the ESB is an important entry point to successful SOA adoption—so important that IBM now offers three strategic products in the SOA Foundation portfolio that implement the pattern.

Be sure to check out Part 3 in this series, which covers four approaches to implementing a canonical message model (CMM) in an ESB.

Acknowledgements

The authors would like to thank the following individuals for their help with this article: Kyle Brown, Andre Tost, Bobby Woolf, and Stuart Jones.

Resources

Learn

• Read "Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution" (developerWorks, Apr 2007), the first installment in this series.
  
  
• Check out Bobby Woolf's article, "ESB-oriented architecture: The wrong approach to adopting SOA" (developerWorks, Aug 2007).
  
  
• Read the developerWorks WebSphere Developer Technical Journal series Building an Enterprise Service Bus using WebSphere ESB.
  
  
• Visit the developerWorks WebSphere Message Broker zone.
  
  
• Visit the developerWorks WebSphere Enterprise Service Bus zone.
  
  
• "Service Oriented Architecture: An Introduction for Managers" [PDF] describes SOA and a version of the adoption roadmap.
  
  
• "SOA Governance and Service Lifecycle Management" describes the important of governance in SOA.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
  • Get started on SOA with WebSphere's proven, flexible entry points
  • SCA/SDO: To drive the next generation of SOA
  • SOA reuse and connectivity
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs, including the following SOA and Web services-related blogs:
  • Service Oriented Architecture -- Off the Record with Sandy Carter
  • Best Practices in Service-Oriented Architecture with Ali Arsanjani
  • WebSphere SOA and J2EE in Practice with Bobby Woolf
  • Building SOA applications with patterns with Dr. Eoin Lane
  • Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
  • Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
  • SOA, ESB and Beyond with Sanjay Bose
  
  

About the authors

Greg Flurry is a senior technical staff member in the IBM Enterprise Integration Solutions group. His responsibilities include working with customers on service-oriented solutions and advancing the IBM service-oriented products.

Rachel Reinitz is a Distinguished Engineer with IBM Software Services for WebSphere, focusing on Web services. Rachel consults with customers and ISVs on how SOA and Web services can be used to achieve their business and technical objectives. She developed IBM's Advanced Web Services Training course and is a frequent conference presenter. Rachel is also an IBM Academy Member and an experienced eXtreme Programming coach who has used XP practices for four years. She lives in the Bay Area in California and enjoys hiking, socializing, and international travel.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• ESB as it relates to SOA
• ESB as an SOA entry point
• Best practices for SOA entry points
• Best practices for the connectivity SOA entry point
• Do you need an ESB to be successful with SOA?
• IBM's ESB product family
• Conclusion
• Acknowledgements
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Webcast: WebSphere Message Broker: Converting Maps to ESQL using Support Pac IA9Y
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere Message Broker

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers