 | Level: Intermediate Greg Flurry (flurry@us.ibm.com), Senior Technical Staff Member, IBM
Rachel Reinitz (rreinitz@us.ibm.com), Distinguished Engineer, IBM
27 Sep 2007 In this article, Part 2 in a series,
find out why IBM® believes the enterprise service
bus (ESB) architectural pattern
provides tremendous value when adopting a Service-Oriented Architecture (SOA).
Authors Greg Flurry and Rachel Reinitz share insights and best practices related to SOA, the ESB, SOA entry
points, connectivity, and more gained from their extensive experience on many
successful SOA client projects that employed an ESB. Also, see how committed IBM is
to ESB by learning more about its family of products that implement the ESB pattern:
WebSphere® Message Broker, WebSphere Enterprise Service Bus, and WebSphere
DataPower® Integration Appliance XI50.
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
|
Interpretation of Bobby Woolf's article,
"ESB-oriented architecture: The wrong approach to adopting SOA"
Bobby's article has generated a lot of buzz. Unfortunately, it gave some readers the impression that
IBM no longer values the ESB. As described in this article, nothing is further from the truth.
In the past, Bobby Woolf worked with a few clients who didn't follow the
best practices outlined in this article. These clients designed and implemented
ESBs without, or unaligned with, a roadmap for adopting SOA. Not surprisingly,
they were unsuccessful. Luckily, these clients represent a
minority; most clients
design and implement an ESB with a roadmap, and in the context of one or
more SOA projects, where the ESB architecture and product selection are driven
by requirements across multiple projects and often different lines of business.
This article simply suggests following
the best practice of developing an ESB in the context of a roadmap defining the
adoption plan that will achieve the desired business goals. Here are some
examples from the article:
- "A project based on ESB-oriented architecture needs to be made into one
based on SOA to help ensure that it successfully
delivers business value." This echoes the assertion that the connectivity
entry point, like any entry point, must be chosen as part of an overall SOA
roadmap that delivers business value.
- "Implying that the services are irrelevant says that the applications using the
bus are irrelevant, how the applications use the bus is irrelevant, and the
application integration requirements (much less business requirements) are
irrelevant." This also echoes the assertion that the ESB must not be deployed
in a vacuum, but as part of an overall SOA roadmap.
- "An ESB by itself produces no business value. An ESB is a means to an end,
not the end itself," and, "ESB-oriented architecture is inherently flawed in
that it builds connectivity no one might ever want to use. The business does
not derive additional value until systems connect to each other and are
working together." If a business bought an ESB product and installed it
with no expectation to ever use it to connect services, does the ESB provide
any value? Most likely not. This is common sense. These statements once
again reinforce the fact that an ESB, or any other approach to SOA adoption,
must be part of an overall roadmap that identifies business value and how to
achieve it.
- The excerpts "develop an ESB as part of developing the SOA" and "Do not
build an ESB by itself; build it as part of an SOA" are both simplified
restatements of the best practice with respect to the SOA entry points.
Is it possible to misuse an ESB and, thus, fail to derive business value? Yes,
in the same way it's possible to misuse any architectural pattern or product in
SOA or any other endeavor by failing to follow best practices. Finally, does
Bobby's article contradict IBM's position that the ESB is fundamental to SOA?
No. In fact, the article simply suggests that success in SOA adoption derives
from the use of the ESB in the context of an SOA roadmap.
We'd like to hear from you! Read Bobby's article,
and let us know what you think.
|
|
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.
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:
-
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.
-
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.
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.
 |
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.
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:
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.
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.
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
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
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. |
Rate this page
| |
