Although enterprise service busses (ESBs) are not new, they can continue to be a nexus for confusion. After many...
years and many implementations, what they do, how they do it and whether specific products can help create a SOA are all still matters of contention.
Chris Harding, a forum director for SOA and client computing at The Open Group, argues that there isn’t always clarity regarding the nature of ESBs. On the Internet, he points out, there is TCP, which is standardized and central to everything. There is nothing similar on the enterprise software stack for ESBs. “All you have is a good common understanding of what an ESB does, but you don’t have the tightly defined interfaces. It is a much looser thing,” he says.
According to Harding, when people talk about ESBs, the key thing they want is the ability to exchange messages using the ESB as a messaging bus. “To that basic vision can be added many other things in terms of transforming the messages, in terms of your ability to combine services and even as a composition engine, but the core is the transmission of messages.”
Historically, Harding says a lot of discussion once focused on whether an ESB is essential for SOA. “In a theoretical sense, the answer is no,” he says. Instead, SOA requires a service-oriented approach to your architecture, the definition of components as services, the identification of service definitions and the loose coupling of those services, he explains.
However, notes Harding, when organizations implement loose coupling for the exchange of messages between services, they often find that an ESB as a means of message exchange is the crucial part of their service-oriented architecture.
Ken Vollmer, an analyst at Forrester research, says ESBs handle the interactions between different components, creating and routing services, and even providing orchestration.
“ESB is the plumbing that enables someone to implement SOA effectively,” he adds.
Implementing that broad architectural vision is another matter. Vollmer says a good starting point is an architectural reference model. “There has been broad agreement since the first talk about ESBs that they should include an architecture layer, a connection layer, a mediation layer and an orchestration layer,” he says.
Citing a recent Forrester report, “The ESB Reference Architecture Model,” Vollmer says that several ESB components must work together to provide the basic ESB framework to deliver availability (typically, through clustering), federation (to support interoperation of ESBs), a topology (such as a hub-and-spoke structure) and extensibility (so that customers can add capabilities on their own).
ESBs are an illustration of service orientation, which is still “a different way of doing things” for many organizations. “People used to write point integration but with ESB, you should be able to create and then reuse code in different ways,” he says. Getting over that idea of having to develop everything from scratch is crucial – and then using an ESB to help implement SOA can make life easier. “But developers still like to write code, and that can be a problem,” he adds.
Vollmer says one of the main challenges in implementing an ESB is making sure you have the right product before you buy it. If throughput is a key requirement, test the product on your site before you buy it. “Don’t buy a pig in a poke,” he says.
According to Vollmer, implementing an ESB isn’t usually that difficult. He says the degree of challenge depends significantly on the skill level of the people involved with an ESB. “It is not simple to implement, but we are way beyond the bleeding edge stage; ESBs have been around for 8-10 years so vendors have made them much easier to work with,” he says. “Therefore,” he adds, “implementing an ESB would not significantly challenge a well-organized IT department.”
Vollmer says Forrester has interviewed 20 companies that recently implemented ESBs and no areas emerged as particularly burdensome. “More than anything, it is a different way of doing integration,” he adds. However, he notes, when problems did surface during initial implementations, about 80 percent of them seemed to be architecture related and the balance – only about 20 percent – were linked to tuning issues.
“From my theoretical perspective, the thing that interests me the most about ESBs is how easy it is to port your services from one ESB to another,” adds Hardy.