We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

First Look

(Display Name not set)

IBM's Three-Tier Approach to ESBs

Vote 0 Votes

Listen to the entire 16:26 podcast Download file

New Update: 9/25/2007
IBM article adds more on this podcast's themes
     Agenda and Resources

1. Entry Points to SOA

2. ESB's Crucial Role

3. Breaking the "Rat's Nest" of Point-to-Point  Coding Between Applications

4. Case Studies:
  a)WebSphere ESB
  b)WebSphere Message Broker

5. WebSphere DataPower's Unique Capabilities

6. Where to Start and What to Choose

Learn more about ESB best practices at IBM's Web Site

Read a complete transcript of the podcast here.

Replay Leif Davidsen's  earlier "Leverage the Value of Existing IT Investments with SOA Reuse and Connectivity webinar on ebizQ.net

Note: Leif Davidsen will respond to comments posted below.

Leif Davidsen will regularly respond to any comments posted below.

IBM’s Worldwide Product Marketing Manager for WebSphere Application Integration Leif Davidsen sees five entry points that enable the IT infrastructure changes that lets organizations embark on the road to SOA.

“Three of them are business focused – people, process and information and how the business might reflect those parts of itself in SOA,” Davidsen says. “And then we have two more technical entry points, reuse and connectivity.

ESBs vs. 'Rat's Nests'
"We position an ESB very strongly at the heart of SOA ... fundamentally, in the connectivity entry point for SOA is the thought of an ESB connecting applications and services together.” Davidsen said. However, “what many businesses today tend to have is a real rat’s nest of connectivity links between their existing applications."

And the drawbacks of building point-to-point hard coupled links between and more and more interface logic into the applications themselves includes:

--Swamping  the actual business logic that the application is actually there to perform and increasing the cost of changing or maintaining that application.

-- Introducing the potential for errors or fragility.

--Rendering the applications almost completely unusable in an SOA environment.

“You want to then reuse them as services, where services are actually trying to get to the core business logic itself rather than be interested in the specific way in which they are invoked in terms of an application interface,” Davidsen says.

Untangling the Rat's Nest

He went on to detail IBM’s three-tiered approach to letting an ESB provide a completely decoupled infrastructure allowing a business to make use of the actual core business logic where all interface layers were defined and managed and maintained within the ESB layer and not in the applications themselves.

At the simplest level, an ESB can meet a company’s specific business needs by leveraging the decoupled connectivity that IBM’s WebSphere MQ transport layer has provided between applications for more than 12 years.

“It really provides much more intelligence in terms of routing the information between applications and services and also transforming and performing intelligent processing based on the content of the flow, based on awareness of each application that’s actually both sending and receiving the information," Davidsen noted.

Case Studies: Banking, Auto Leasing and Media

"So there’s all sorts of different ways in which you can use ESBs throughout your business today," Davidsen said, before detailing actual case studies by a wide range of companies.

“What’s always been encouraging has been that these customers span both the globe in terms of where they’re running their businesses and in terms of the different industries that they exist and successfully perform in,” Davidsen said. They include:

Grohe -- The supplier of premium fittings for bathrooms and kitchens faucets and showers uses SAP for their ERP systems, but were finding it labor-intensive to connect their other business-critical applications to their SAP system. But they were able to us IBM’s advanced Enterprise Service Bus product -- WebSphere Message Broker – to reduce the connection time by up to 84%.

--HypoVereinsbank:  “Their line of business, they were finding, they were stuck in a silo mentality in terms of only wanting to connect to their own applications, which obviously restricts their growth capability," Davidsen said. "So they wanted to implement an ESB to allow them to move to a much more component-based building block model for their business, allowing their services to be more widely used across their business.

--Auto Leaser Ubench: “They’re using very innovative technology -- wireless telemetry devices -- in their leased auto fleets that allow them to offer capabilities such as automatically detecting when services or maintenance is required and sending that back to the other value chain suppliers across their leasing business to arrange that," Davidsen said.

“And then there are other companies, like a media company, VRT, who wanted to put in place an ESB to connect their digital and tape-based media assets for both faster, efficient storage and retrieval of those assets," Davidsen said.

VRT, Davidsen noted, “is actually using one of our other ESB products, WebSphere ESB, that’s ideally designed for service-based integration. They had built an almost completely Web services based infrastructure and the data types, the metadata, were all easily describable in terms of XML and sort of more open data structures, so they could use WebSphere ESB to provide the intermediation between the different applications and data types.

DataPower: An Advanced Solution

Another company, digital rights manager Macrovision, was running WebSphere ESB at the heart of their process server and had an e-commerce front end to their business.

"They actually implemented the third ESB product that we have, the WebSphere DataPower XI50 Integration Appliance to front end and offload the traffic flowing from their e-commerce site, handling all of the Web services and XML data types to their back office and process server implementations," Davidsen said. "That allows them to speed up those applications and that process server layer, so that they don’t overload it with the heavy processing involved with XML .

"The DataPower application device is a very different sort of ESB; it’s sort of unique within IBM," Davidsen said.

What to Choose and Where to Start

“We believe that it will be much more difficult to really meet our customer needs by building a single ESB that tried to do everything, because those customers that needed a simpler product would probably be overwhelmed,” Davidsen said. “And it’s like if you tried to cut these things back too much, you’re going lose some of the capability and flexibility and scalability that many of our really large enterprise customers find that they need.

“What we find in terms of the implementation model is that businesses would typically implement a particular ESB from our portfolio for a particular departmental or project needs as part of an overall ESB strategy, in the full knowledge that any combination of these ESBs would work together. So you can have WebSphere ESB connected to WebSphere Message Broker, or DataPower connecting to either of those two,” Davidsen said.

For much more on the topic – and more case studies – listen to the full podcast.



Could you throw some light on how ESB conceals of point-to-point connectivity between applications from the conventional stove-pipe implementations?


Good question Manik. One of the problems of point-to-point connectivity is that as applications change, and additional applications wish to connect, then the application logic itself can be overwhelmed by all the connectivity interfaces and logic that needs to be defined within each application to cater for each different point-to-point connection.

The idea of the ESB is to simplify the interfaces required within an application for connectivity. Instead of individual definitions for each connectivity point, a single connection can be defined to the ESB. Then within the ESB itself there can be access definitions, and data descriptions for each application connected. This both reduces the overall number of connections that must be defined, and allows them to be defined within a tool that is specifically built for such a purpose, rather than embedding connectivity definitions throughout a business application, making it overly complex and hard to maintain.

With connectivity being cleanly defined and maintained within an ESB, the business functions of the application are now more suitable and available for reuse, and additional benefits can be achieved such as better management and monitoring of the information flowing around the business, simply by using features in the ESB, rather than by adding new functions to each application.

Leif Davidsen
Reuse and Connectivity Lead
SOA and WebSphere Marketing
IBM Software Group

Dear Leif,

This blurb in a recent InfoWorld SOA newsletter did pique my interest


I found this little goodie today from IBM, I had to read it twice. "An increasingly common request from clients is to complete a project that
does not use service-oriented architecture (SOA) as a whole, but instead implements only an enterprise service bus (ESB) architecture. Such an
ESB-oriented architecture is ...(the rest of the entry is at: http://newsletter.infoworld.com/t?ctl=19451A8:1889439CFAFB27F1F9D189C290

Leif, how does this relate to your own view of about ESB's role in SOA?
--Ron Taggirt


Thanks for the question Ron. The infoworld article is referring to a very interesting piece written by one of IBM's customer architects - Bobby Woolf. The article has been widely read and much commented on since its publication. It uses ESBs as a specific example of a key IT problem, which is that of adopting technology without specific goals and intended longer term value. The article which can be found here: http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/index.html
is well worth the read - and you may notice a sidebar giving further comments about it by some of our other architects and technical specialists, who will be writing a follow-on article further addressing this key point about the importance of ESBs as a fundamental part of an SOA and the value they contribute to the business.

Leif Davidsen
Reuse and Connectivity Lead
SOA and WebSphere Marketing
IBM Software Group

Join ebizQ producer Krissi Danielson for interviews with the innovators, movers and shakers behind emerging enterprise software solutions.Have a solution that qualifies? E-mail Krissi at krissi (at)ebizq.net

Krissi Danielson

Krissi Danielsson is a podcast producer with ebizQ and contributor to ebizQ's SaaSWeek site. View more

Recently Commented On