This bandwagon's a bus and all walk of vendors positioning in the SOA market have jumped on it over the last few years.
The bus, of course, is the enterprise service bus (ESB) and as it has gained momentum as a key element in a service-oriented architecture. The market has expanded from the domain of startup specialists to integration and infrastructure players and platform vendors as well as the open source community. According to a recent Gartner Dataquest report, the ESB market expanded more significantly in 2005 than any other application integration and middleware segment, with 160.7% revenue growth.
In addition, Cambridge, Mass.-based Forrester Research expects to see 67% of firms with 40,000-plus employees implement SOA this year and found that 83% of firms are using SOA for internal integration. These trends will help drive adoption of ESBs, according to Forrester in its recent Forrester Wave: Enterprise Service Bus, Q2 2006.
According to Forrester and other industry experts, many organizations implement an ESB as an entry point to SOA, but they all caution that an ESB is only one piece of an enterprisewide SOA and there are alternatives to consider.
"The real question is, how can an ESB help with a SOA implementation plan, which is the challenge a lot of enterprises face," said Jason Bloomberg, a senior analyst at ZapThink LLC in Waltham, Mass. "Companies need to think through a plan, identify the business problem, figure out how to build services, then figure out the infrastructure. They may or may not need an ESB."
Today, though, many enterprises do start with an ESB, which Forrester principal analyst Ken Vollmer describes as a straightforward way to get started with SOA and typically a less costly route to application integration than integration-centric business process management (BPM) suites. Vollmer identifies three types of ESB vendors: pureplays, those with roots in enterprise application integration (EAI) and platform players. In addition, there is a handful of open source ESBs to choose from, both standalone and as part of SOA platforms. Also, vendors like Microsoft and SOA Software Inc., for instance, don't offer ESBs per se, but do have ESB-like functionality with their offerings.
According to Forrester, an ESB typically includes communication infrastructure; request routing and version resolution (mediation); transformation and mapping; service orchestration, aggregating and process management; transformation management; security; quality of service; service registry and metadata management; extensibility for message enrichment; monitoring and management; and support for the service life cycle.
The early ESB market, which was based on Web services standards, stole some thunder from the EAI market, which was saddled with proprietary technology. "If you look back five years, the ESB vendors were putting the hurt on application integration vendors," Vollmer said. "But the EAI vendors moved up the stack by adding more advanced BPM features and they've adopted the same standards as ESBs. You could say now that integration-centric BPM could commoditize the ESB market to some extent."
But by far the biggest change in the ESB market, he said, is "you find more and more larger vendors adding either a standalone ESB, like IBM and BEA, or including those features in basic integration suites, like Tibco and WebMethods and Oracle. Over time, I believe standalone ESBs will gradually be consumed by the larger vendors and become more basic infrastructure technology," Vollmer said.
A maturing market
As the larger vendors have added ESB capabilities to their offerings, the pureplays have broadened their capabilities as well. "Look at Sonic Software," said Bloomberg. "They're still leading with their ESB product, but Progress Software [Sonic's corporate parent] has reorganized. It's significant that Progress has realized SOA is more than ESB. They have the Neon legacy integration, they have XML tooling. SOA requires a lot of different pieces. Sonic's leading standalone ESB product is really not standalone anymore. Companies want a more comprehensive solution."
According to Kelly Emo, product marketing manager for San Jose, Calif.-based BEA Systems Inc.'s AquaLogic Service Bus, "Expectations are changing as customers become more mature in their approach and implementation of SOA. One of the biggest changes is the expectation that ESB plays a critical role in the overall service lifecycle. They're interested in a service integration backbone, but having it be a participant, from designing, discovering, integrating and managing services. A lot of requirements come to us about integrating what the bus knows about services in the registry/repository."
Today a small percentage of customers specifically ask for an ESB, said Ashish Mohindroo, senior product director for Oracle Fusion Middleware, at Redwood Shores, Calif.-based Oracle Corp. However, said Mohindroo, "the majority will come in saying they're trying to move toward SOA and they need something lightweight to do the transformation and routing. But the more we explore ESBs, they realize it's just a small component in moving toward SOA. You also need orchestration, security, monitoring, and governance."
ESBs are just one type of SOA intermediary; other types are Web services management products, XML gateways, pureplay mediators like SOA Software and Apache Synapse, and platforms, according to Anne Thomas Manes, vice president and research director at Midvale, Utah-based Burton Group Inc.. She believes ESBs are best suited for complex aggregation and transformation of data, legacy access and orchestration. "I don't typically recommend using an ESB for mediation, they're more in the platform category," she said. "I typically recommend an XML gateway or Web services management product. Both have stronger security mediation."
According to ZapThink's Bloomberg, "A key part of the SOA infrastructure has to do with the intermediary capability for loose coupling of services. If your existing middleware can't do that, bring in some intermediary. If you have the need for additional integration infrastructure, get an ESB. If you already have that infrastructure you can use an intermediary, like SOA Software's Network Director. The question is, do I need messaging infrastructure in addition to intermediary capabilities?"
Oracle's Mohindroo agrees that there are alternatives. "Some customers don't need a pure ESB environment. There are emerging standards [like WS-Reliable Messaging]. So if you don't have too many services or systems to interoperate, you can get away without an ESB and make do with an orchestration engine, say Oracle BPEL Process Manager. You can connect services and define the flow. We have several customers today that leverage that, who don't have those requirements that a typical ESB would provide."
Manes anticipates that as XML gateway providers add more ESB functionality into their boxes and once those boxes support WS-Reliable Messaging and routing of events and more complex integration, "I don't see a whole lot of value in the ESB as an intermediary." Where she expects to see the ESB evolve, and continue to have a role, is as a platform.
Oracle's Mohindroo agrees. "With ESBs, think next-generation messaging bus. After you connect [the systems] what do you do? The ESB becomes part of the platform to access these different services. Most companies are looking toward the ability to build flexible infrastructure. Think of the ESB as an entry point."
What Oracle, IBM, BEA and other platform players are hoping, is the ESB entry point will lead to adoption of an SOA platform. "What we're seeing is a big adoption of the SOA platform, which naturally leans to a bigger platform provider," said Mohindroo. "We're seeing customers ask for an end-to-end SOA platform, for technological reasons, but second, for what kind of support we can provide. All those aspects become really critical when you talk about SOA infrastructure."
Open source vendor JBoss, now part of Red Hat Inc., is the latest platform provider to throw its hat into the ring with its JBoss Enterprise Service Bus, now in beta. And IBM, which also entered the ESB market later than some of its competitors, has two ESBs: WebSphere ESB, and WebSphere Message Broker, which the company has repositioned as an advanced ESB.
"We have had our Message Broker in the market for a long time. September of last year ESBs became hot, that's when we introduced WebSphere ESB and the Message Broker portfolio," said Sandy Carter, IBM vice president for SOA and WebSphere. Carter said WebSphere ESB is suited for organizations looking for Web services connectivity and Message Broker is for those organizations that also need integration with non-SOA environments.
"ESB is at the heart of our reference architecture for SOA," Carter said. "Having a strong ESB, we believe, adds tremendous value to what you have in the marketplace. The power of SOA is not just to do new things, but you can integrate what you have in your environment, and reuse it, and have a high quality of service. The way to get this is through this ESB layer. We believe it's a real powerful part of the SOA story."
Emphasis on "part of the story" according to most observers.
BEA's Emo said that ESB capability should be a factor in choosing an SOA solution, "but on a broader basis. The best recipe for looking at SOA is to look at your lifecycle needs. It's important to have the core features of an ESB, but not in a vacuum."
"What we're seeing from ESB vendors as well as consultants building SOA solutions, is that the bloom is off the ESB rose," said Bloomberg. "Clearly the role of ESB is no longer thought of as a key piece of SOA infrastructure, but rather one piece of many moving parts to get SOA to work."