getting on board the enterprise service bus

3
April 2007 15 Published by the IEEE Computer Society O ne of the biggest challenges facing businesses today is getting their diverse appli- cations, often built on dif- ferent platforms, to work together when necessary. For exam- ple, a purchase order generated via a company’s e-commerce application might need to query a customer-loy- alty database to determine whether the buyer has done enough business in the past to merit special pricing or handling. To accomplish this, companies must implement effective applica- tion integration flexibly, quickly, and easily. Businesses initially turned to man- ual integration and then enterprise application integration (EAI) but subsequently have focused on ser- vice-oriented architectures. To lever- age SOAs’ benefits effectively, companies are beginning to use an approach known as the enterprise service bus, offered by a growing number of large and small vendors. ESB is the middleware glue that holds an SOA together and enables communication between Web-based enterprise applications. “Fundamentally,” said Larry Fulton, senior analyst with Forrester Research, “ESB provides the connec- tivity between service requestors and service providers, physically convey- ing the requests and the responses.” Proponents say ESB offers advan- tages over earlier application-inte- gration approaches, such as ease and flexibility of use and ready scalabil- ity to larger deployments. However, ESB also faces challenges, such as implementation costs and complex migration and management. DRIVING FORCES Enterprises often must provide employees, suppliers, customers, and partners with on-demand ser- vices and information culled from various data sources. To do this, they must be able to combine the capa- bilities of their many applications, including some legacy programs. This type of integration became an important issue in the mid-to-late 1980s, said Fulton, when businesses began deploying software that helped management by combining information from disparate data- generating applications. Initially, companies had to manu- ally integrate applications so that they could work together. However, this required considerable time and expense, and it worked only for the applications that were manually linked. Adding additional applica- tions required more effort. EAI According to Fulton, organiza- tions began using EAI in the late 1980s. EAI systems can use a hub-and- spoke architecture in which applica- tions send messages via adapters to centrally located message and inte- gration brokers, noted Wayne Kernochan, senior IT analyst for market research firm Illuminata. The integration broker is the system’s “brains,” handling tasks such as data transformation and message routing. In a bus-like EAI architecture, disparate source applications send messages via a central “pipe” to receiving applications. The system contains software adapters and inte- gration engines at all nodes, thereby distributing the intelligence. EAI enables automatic, machine- to-machine communications. How- ever, Fulton explained, it works via point-to-point interfaces, which orga- nizations must define and build one at a time, between applications. As companies use more applications to provide additional services, the amount of integration work required mushrooms, and managing the sys- tem becomes increasingly difficult. In addition, the integrated appli- cation sets are not reusable for other purposes. SOA Companies began implementing SOAs, which use EAI technology for integration, in the mid-to-late 1990s. An SOA enables flexible connec- tivity and communication among applications by representing each as a service with an interface that lets them communicate readily with one another. Like EAI, SOA can use Web services to allow standards-based applications to interact over the Internet. This enables machine-to- machine communication, speeding the application-interaction process and eliminating the need for human intervention. Standardized Web-services inter- faces include XML for data descrip- Getting on Board the Enterprise Service Bus Sixto Ortiz Jr.

Upload: s

Post on 22-Sep-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

April 2007 15P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

I N D U S T R Y T R E N D S

O ne of the biggest challengesfacing businesses today isgetting their diverse appli-cations, often built on dif-ferent platforms, to work

together when necessary. For exam-ple, a purchase order generated via acompany’s e-commerce applicationmight need to query a customer-loy-alty database to determine whetherthe buyer has done enough businessin the past to merit special pricing orhandling.

To accomplish this, companiesmust implement effective applica-tion integration flexibly, quickly, andeasily.

Businesses initially turned to man-ual integration and then enterpriseapplication integration (EAI) butsubsequently have focused on ser-vice-oriented architectures. To lever-age SOAs’ benefits effectively,companies are beginning to use anapproach known as the enterpriseservice bus, offered by a growingnumber of large and small vendors.

ESB is the middleware glue thatholds an SOA together and enablescommunication between Web-basedenterprise applications.

“Fundamentally,” said LarryFulton, senior analyst with ForresterResearch, “ESB provides the connec-tivity between service requestors andservice providers, physically convey-ing the requests and the responses.”

Proponents say ESB offers advan-tages over earlier application-inte-gration approaches, such as ease and

flexibility of use and ready scalabil-ity to larger deployments.

However, ESB also faces challenges,such as implementation costs andcomplex migration and management.

DRIVING FORCESEnterprises often must provide

employees, suppliers, customers,and partners with on-demand ser-vices and information culled fromvarious data sources. To do this, theymust be able to combine the capa-bilities of their many applications,including some legacy programs.

This type of integration became animportant issue in the mid-to-late1980s, said Fulton, when businessesbegan deploying software thathelped management by combininginformation from disparate data-generating applications.

Initially, companies had to manu-ally integrate applications so thatthey could work together. However,this required considerable time andexpense, and it worked only for theapplications that were manuallylinked. Adding additional applica-tions required more effort.

EAIAccording to Fulton, organiza-

tions began using EAI in the late1980s.

EAI systems can use a hub-and-spoke architecture in which applica-tions send messages via adapters tocentrally located message and inte-gration brokers, noted WayneKernochan, senior IT analyst formarket research firm Illuminata. Theintegration broker is the system’s“brains,” handling tasks such as datatransformation and message routing.

In a bus-like EAI architecture, disparate source applications sendmessages via a central “pipe” toreceiving applications. The systemcontains software adapters and inte-gration engines at all nodes, therebydistributing the intelligence.

EAI enables automatic, machine-to-machine communications. How-ever, Fulton explained, it works viapoint-to-point interfaces, which orga-nizations must define and build oneat a time, between applications. Ascompanies use more applications toprovide additional services, theamount of integration work requiredmushrooms, and managing the sys-tem becomes increasingly difficult.

In addition, the integrated appli-cation sets are not reusable for otherpurposes.

SOACompanies began implementing

SOAs, which use EAI technology forintegration, in the mid-to-late 1990s.

An SOA enables flexible connec-tivity and communication amongapplications by representing each asa service with an interface that letsthem communicate readily with oneanother.

Like EAI, SOA can use Web services to allow standards-basedapplications to interact over theInternet. This enables machine-to-machine communication, speedingthe application-interaction processand eliminating the need for humanintervention.

Standardized Web-services inter-faces include XML for data descrip-

Getting on Boardthe EnterpriseService BusSixto Ortiz Jr.

16 Computer

I N D U S T R Y T R E N D S

However, as an organization grows,the addition of more applications andservices could overwhelm a singlemessaging broker. This led to devel-opment of ESB’s bus-like architecture.

ESB software vendors include CapeClear Software, Fiorano Software,Progress Software, and PolarLake.Some large vendors—such as IBMand Oracle—are also entering themarketplace. Open source offeringsinclude Bostech’s ChainBuilder ESBand LogicBlaze’s FUSE.

The 411 on the ESBThe ESB, which runs via software

that can be loaded onto desktop com-puters or servers, provides an SOA’sconnectivity infrastructure to enablecommunications between applica-tions running on different platforms,written in different programming lan-guages, and using different program-ming models, said Craggs.

The ESB functions like a softwareversion of a PC’s traditional hard-ware bus, moving data along a com-mon pipe between applications,according to Illuminata’s Kernochan.The integration engines are distrib-uted throughout this architecture, atthe computers that host the ESB soft-ware, rather than located in a centralbroker.

An ESB lets one application senddata to another by first accessing itvia a locator and then sending it amessage.

tion; HTTP for message transfer; theSimple Object Access Protocol(SOAP) for message exchange; theWeb Services Description Language(WSDL) for service description; andthe Universal Description, Discovery,and Integration (UDDI) protocol forpublishing and discovering services,said Jim Rivera, Cape Clear Soft-ware’s vice president of productmanagement.

SOAs can also work with propri-etary interfaces to communicatewith legacy systems

Unlike EAI, SOA lets companiesreuse the services they create—viathe integration of multiple applica-tions—in more than one businessprocess without additional pro-gramming.

In essence, SOA sets up a reposi-tory of these services, which busi-ness-process developers can discovervia Web services protocols.

This reusability is what makesSOA so useful for helping companiesaccomplish their business goals andneeds, stated Steve Craggs, the pres-ident of Saint Consulting and the vicechair of the Integration Consortium(www.integrationconsortium.org)industry group.

BOARDING THE BUSInitially, SOAs were configured in

a hub-and-spoke architecture, work-ing via a central broker that providesthe system’s intelligence.

The ESB handles the transfor-mation of data formats; routing; message acceptance, processing, androuting; and the sending of multiplemessages at the same time.

Elements. At its most basic, anESB architecture consists of threeelements, according to Craggs.

Mediation services automaticallyhandle functions—like applicationmapping and intelligent routing—necessary to get Web services—suchas an e-commerce application and a customer-loyalty database—towork together to perform businessprocesses.

The services also allow informa-tion transfer between applicationsby taking data in the format of asending application and convertingit to one compatible with a receivingapplication.

These function via basic adaptersthat work with standard environ-ments such as Web services and theJava Connector Architecture. Addi-tional adapters connect to otherenvironments, such as SAP’s IDoc(intermediate document) data struc-ture. This is important for legacysoftware that wasn’t built to com-municate automatically with otherapplications.

Adapters work via preprogrammeddata-format-mapping information.Without them, developers wouldhave to manually code or use customdevelopment tools to create connec-tions to applications, said KevinClugage, product director for OracleFusion Middleware. “That wouldadd unnecessary complexity,” henoted.

Messaging protocols enable com-munication between servicerequesters and providers. ProgressSoftware’s Sonic ESB, for example,supports about 200 open and pro-prietary messaging protocols,including Web services, the JavaMessage Service, e-mail, FTP, and IBM’s Customer InformationControl System, said Hub Vander-voort, chief technology officer ofProgress’ Enterprise InfrastructureDivision.

20060

100

Reve

nue

(mill

ions

of U

S do

llars

)

200

300

400

500

600

2007 2008 2009 2010 2011 2012 2013Source: WinterGreen Research

Figure 1.The worldwide enterprise-service-bus market will grow steadily, doubling

between this year and 2012, according to WinterGreen Research.

April 2007 17

Capabilities. ESBs’ programmingmodel provides a rich abstraction ofboth the application and the inter-face. Thus, a business-process archi-tect need not worry about the codingnecessary to connect applications orresources but instead can just utilizean automated ESB service, explainedChristopher Vavra, product man-ager for IBM’s WebSphere ESB.

ESBs can be centrally managedand thus can perform integrationthroughout an organization’s infra-structure.

Fiorano CEO Atul Saini notedthat ESBs offer additional importantcapabilities such as making sure amessage is formatted correctly, find-ing the most resource-efficient wayto perform tasks, providing redun-dancy in case of failure, and loggingevents or errors.

For security, ESBs typically utilizeauthorization and authentication tolimit application access to those withpermission.

ESBs also conduct some of theauditing and monitoring necessaryto ensure applications perform asspecified by service-level agreementsbetween customers and vendors.

AdvantagesWhen ESB integrates applications,

it configures the services for reuse inother situations. Over time, a systemcan end up with many such tools,making them useful in numerous sit-uations.

Via ESB, SOA systems can per-form application integration onceand then automatically reuse theintegration services whenever neces-sary. This keeps business-processdevelopers from having to manuallyrecode the services each time inte-gration takes place, as is the casewith EAI.

By providing a standardized, auto-mated way for programs to exchangeinformation, ESB makes expandingexisting services easier than withEAI, Craggs noted. The architec-ture’s decentralization lets companiesadd applications to a service incre-mentally, when and where needed.

Because an ESB has no single, central messaging broker but in-stead distributes messaging servicesaround a network, it can betteraccommodate growth in an organi-zation’s activities and eliminates thepotential bottleneck or point of fail-ure that a single broker represents,Craggs explained.

ROADBLOCKS FOR THE BUSBecause ESB does work previously

performed by humans, the host sys-tem may need additional or morepowerful hardware to handle theextra processing.

Learning to use an ESB optimallytakes time, so organizations don’talways realize a return on invest-ment for the first few projects.

According to Forrester’s Fulton,some potential users don’t adoptESB because of confusion aboutwhether they should purchase simi-lar Business Process Managementproducts instead.

And some companies are delayingadoption because they must decidebetween the numerous ESB productshitting the market now.

Moreover, migrating from today’sEAI-based integration infrastruc-tures to a more SOA-centricapproach can be challenging. Forexample, large-scale ESB implemen-tations can be time-consuming andexpensive, and they can entail com-plex management and high consul-tancy costs, said Rob Hailstone,software-infrastructure practice di-rector for the Butler Group, a mar-ket research firm.

I ndustry observers say the ESBmarket is starting to take off. Thetechnology has demonstrated its

benefits, and companies are movingbeyond pilot implementations,according to Fulton.

For the next five years, SOAs, andthus ESB, should remain the dominantapplication-integration approach, pre-dicted Illuminata’s Kernochan.

In fact, as Figure 1 shows, Winter-Green Research, a market analysisfirm, predicts the global ESB marketwill grow from $203.8 million thisyear to $494.4 million in 2013.

Very large organizations—pri-marily in finance, telecommunica-tions, and government—have beenthe first to implement ESBs, said theButler Group’s Hailstone. However,he said, with more ESB vendors—aswell as a couple of open sourceproducts—in the market, prices arestarting to fall, which should makethe technology more accessible bymidsized organizations.

“Companies will initially strugglewith what functionality should beconfigured into their ESBs and whatreally belongs elsewhere,” saidFulton. “But at the end of the day,IT organizations embracing SOA ona large scale will certainly embraceESB as well.” ■

Sixto Ortiz Jr. is a freelance technologywriter based in Spring, Texas. Contacthim at [email protected].

Editor: Lee Garber, Computer,[email protected]

RReenneeww yyoouurr IIEEEEEE CCoommppuutteerr SSoocciieettyy

mmeemmbbeerrsshhiipp ttooddaayy!!

www.ieee.org/renewal