It's a bird, it's a plane, it's a bus -- an Enterprise Service Bus!
In a world where Web services-based technologies are the heroes of application development, ESB is grabbing headlines.
But while vendors have variously detailed visions of Superman-like grandeur, the technology signals one of the most significant milestones in Web services' evolution.
Variously called ESB or message broker, the technology uses Web services and message queuing to facilitate the development of flexible, SOA (services-oriented architectures).
The term ESB, while not fully embraced in all circles, is originally attributed to a report by Gartner. The technology uses industry-standard specifications such as SOAP or JMS (Java Message Service) to create loosely coupled architectures based on interfaces and flexible programming requirements. In this paradigm, applications are merely services, not the monolithic, difficult-to-integrate systems of the past.
Gartner analyst Jess Thompson said in a report that ESB is "a class of integration software that came to market in 2002 and is intended to support the deployment of Web services. An ESB combines messaging, basic transformation, and content-based routing."
Mark Bauhaus, vice president of Java Web services at Sun Microsystems, observes that ESB has evolved from message-queuing technology, which was originally point-to-point in nature. "Now it's started to take on some of the Web services using XML," he said.
It's therefore not surprising that the pundits increasingly refer to ESB as a method of making application integration simpler and cheaper, particularly for smaller organizations.
Opportunities are emerging as companies of all sizes increasingly view mainstream EAI technologies as too expensive. This standards-based approach to service-oriented architectures is gaining favor over competing methodologies such as CORBA, Java, or Cobol-based integration, observes Rob Hailstone, an analyst at IDC.
Yet ESB's road to corporate stardom is no rose-petal-covered path. Before it reaches a significant level of maturity, the industry must resolve fundamental debates such as the correct definition and notion of what ESB should achieve.
For example, emerging vendors have embraced ESB, with Sonic going so far as naming a product Enterprise Service Bus.
On the other hand, IBM and Microsoft don't view ESB as a specific product, choosing instead to concentrate on the notion of a SOA.
"I think about (SOA) as a mindset evolution for IT about the way (to) architect solutions," says Steven VanRoekel, director of Web services marketing at Microsoft. "There will be different sets of guidelines on how to think about writing applications really as a service instead of as a point solution to make them extensible for the future," says Steve Holbrook, IBM program director of emerging e-business standards.
"In many ways (service-oriented architectures are) parallel to the Web. (They) allow us to have a Web-like relationship between companies across the Internet," Holbrook adds.
IBM touts its MQ Series as a nonstandard way to perform asynchronous messaging in service-oriented architectures. "We're actively involved in updating MQ Series to work in a services-oriented architecture environment," and support Web services, Holbrook explains.
But it must work quickly at that task. Integrator Northrop Grumman Mission Systems is migrating a Department of Defense system from MQ Series to a JMS backbone as the foundation of an ESB, switching to Sonic's ESB product.
"It just gives us more capabilities," says Jon Johnson, chief engineer at Northrop Grumman. "A lot of what we had to (customize), build, and maintain in the past is now something out-of-the-box."
ESB is used to extract data from legacy systems to enable information access without the need to replace systems, both Sonic and Johnson report. Grumman's deployment is intended to enable integration and interoperability of legacy, "stovepipe" systems allowing for defense command and control operations to exchange data or make data available to a wider audience.
Sonic augments its use of Web services with asynchronous messaging in its enterprise service-bus architecture, with each service definition kept in a common directory. A global communications management infrastructure also is used.
Path to seamless integration
Yet even the gung-ho ESB executives at Sonic concede these are early days.
"The technology is still pretty new and we're still working on solidifying the first couple generations of products that are using enabling protocols," said Gordon Van Huizen, vice president of product management at Sonic Software.
IBM's Holbrook adds that standards in areas such as reliable messaging still need to evolve for Web services-based architectures to catch on in greater volumes.
David Clarke, executive vice president of product strategy at Cape Clear, based in San Mateo, Calif., gives the issue some perspective.
"ESB is an attempt by the industry and the analysts to try to tie down the key things you need in a Web-services platform," Clarke said. For enterprises such as Pacific Life, a US insurance company, that clarity is essential.
The company's experience illustrates the core opportunity for the ESB in the future. Pacific Life plans to implement a Web services-based ESB to eliminate complicated mainframe programming required to make policy information more accessible to users.
Pacific Life plans to use Cape Clear's CapeConnect product plus Inner Access technology, which will expose CICS Cobol transactions as Web services, says Cort Klein, system architect at Pacific Life.
The company hopes its new Web services-based methodology will improve the current system in which Pacific Life must link to mainframe data via TCP/IP before undertaking labor-intensive processes.
These processes include inputting parameters into a Cobol copy book and serializing the marshalling and translation back and forth, Klein says.
"With Web services, all that code is generated automatically. We've done proofs of concept where it works quite nicely," Klein explains.
This seamless integration of data highlights what Gartner's Thompson says will be another driver of ESB technology development: composite applications.
In composite applications, the user sees a single application but behind the scenes the application actually is made up of components of individual, stand-alone applications.
"It costs less than one-tenth what the integrator broker does," about $8,000 to $10,000 as opposed to a $125,000 broker, Thompson explains.
As such, ESB presents "a better iteration of how to implement a service-oriented architecture," says Cape Clear's Clarke. "It turns out that Web services is a very good way to define these services, these contracts, in a way that is very implementation-neutral because most historical attempts to define this service-oriented architecture have been very tightly coupled with a particular implementation approach," such as CORBA or DCE (Distributed Computing Environment)."
ESBs, IDC's Hailstone adds, require at least a standards-based message capability. Message routing is needed for transforming message content and some level of security may be needed for filtering, he says.
Looking down the road, the other component of this discussion under close scrutiny will be the use of Java in SOAs.
Java Messaging Service has been prominent in ESBs, Hailstone said. "(JMS is important) to the extent that I've not seen any product that claims to call itself an ESB that doesn't use Java messaging," he says.
An application server is not a good option for running an ESB since it may be too clumsy for the task at hand, Hailstone claims.
Application-server heavyweight BEA Systems not surprisingly argues otherwise. "The application server has a central role in (an ESB)," said Byron Sebastian, vice president and general manager of WebLogic Workshop and WebLogic Portal at BEA. "It provides core components of the Web services standards and it provides the JMS."
Yet, regardless of application-server debate, analysts expect big things from the technology. IDC analyst Sally Hudson wrote in a March 2003 report that ESB "will revolutionize IT and enable flexible and scalable distributed computing for generations to come."
When it comes to the development of loosely coupled enterprise applications, Sebastian offers a more realistic perspective of ESB's role. "Most people are using a Web services interface either alone or in combination with a service bus," he said.