These days, an increasing number of SOA integrations have an enterprise service bus (ESB) powering them. But experts say that using an ESB may not be necessary at all for SOA – and that in some cases, it can do more harm than good.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Often viewed as a middleware version of the Swiss Army Knife, ESBs can provide message queuing, translate between data formats, orchestrate or intelligently route messages, and more. Its versatility can also be its downfall – it can make integrations even more complex, and it becomes the scapegoat for bottlenecks and performance issues, even when the problem lies elsewhere. In fact, ESBs aren’t even necessary in most SOA developments, according to experts.
ESBs have been very common in SOA implementations, said Thomas Erl, president of Acitura Education. “It's quite convenient in that [ESBs] can establish a really powerful layer of middleware that can perform utility centered functions in a centralized location, such as transformation, mediation, and various types of broker capabilities,” he said. But ESBs can be hazardous, indicated Erl, if they don’t mesh with an overall plan.
An ESB simplifies designing and building software in the form of interoperable services, but it is not a hard requirement for SOA, said Asankha Perera, founder and CTO of Adroit Logic. In fact, ESBs can also be used in non-SOA environments, such as simplifying traditional enterprise application integration (EAI), integrating with trading partners over the internet, or as a security gateway, he said.
Other experts agree that ESBs are not necessary for SOAs, but they have their place. According to Rob Daigneau, director of Server Applications at Blue Metal Architects, there are three core functions of an ESB: message routing, message translation, and protocol translation and transport mapping, with less of a need to use ESBs for protocol translation in the past few years.
ESBs are best used when there are “many-to-many” sorts of dependencies, Daigneau said. If the ESB is only facilitating a message center where the message is always being sent to the same receiver, “then all you've got is a really complex and expensive piece of software infrastructure in the middle. It’s an improper use of the bus,” he said.
Perera noted that ESBs are particularly useful for routing many messages at high throughput. This includes routing to back end services for processing, transformation, logging, management, monitoring, caching, throttling and security validation, he said.
Daigneau pointed to a university payment system, which would require processing payments from different banks using different payment methods – a “many-to-many” approach. “That’s the right situation to use ESB,” he said. “The ESB provides a layer of interaction between the centers and receivers so that couplings are lessened to some degree.”
The ESB would facilitate message routing to the appropriate destination, as well as translation, since the banks that receive and process payments may have different message structures. Banks are unlikely to change their message structures, and any university trying to route payment without an ESB would have to understand all the message structures of all the banks it was using, he said. “The bus makes it so they don't have to connect to each of the message receivers and write specifically to the message structure. …The bus is responsible to look at the message and say who this is for, and before it routes the message to the appropriate destination, it will translate it to the required format,” Daigneau added.
ESBs can cut both ways – if they’re misused, they can end up being an expensive, useless piece of middleware. The trouble begins when ESBs are used as a Band-Aid solution, without regard to the strategic, long-term goals of the business organization or the IT organization. Using ESBs comes down to two things: understanding the ESB and the goals of the IT enterprise, Erl said.
One of the ways to understand the ESB is to have at least three vendors build a proof-of-concept (POC) using a realistic scenario from the business, said Perera. “Usually ESB vendors offers such a POC free of charge, so it’s an opportunity to try out different ESBs without incurring costs, and to see each ESB in actual use, ” he added.
Ultimately, knowing what the ESB needs to do and looking at long-term strategic goals is key to any successful implementation. “We need to understand the target state within our own IT enterprises that we are planning to achieve. …From that target state, we have criteria that we define and we apply to whatever vendor products, technologies, and tools we decide to make part of our SOA project,” Erl said.
Otherwise, ESBs purchased by organizations can be misused and require a lot of time to configure. In cases where the company doesn’t know why it wants an ESB, “customers waste a lot of their time trying to fit each of their business problems into a manner solvable by the ESB,” Perera said. “Another related issue is when an ESB always converts each message into some internal format. …Sometimes the business use cases does not require such conversions, persistence, or payload transformation, and any such additional conversions only affects the performance, complexity, and overhead of using an ESB,” he added.
Another best practice is, once in place, to standardize the ESB’s use, said Erl. “A worst practice is the counterpart to that where it’s just installed into an IT enterprise for open usage, not regulated and allowing any project team to just work with its feature set to whatever extent it wants to, where some may use it and others may not,” he said.
What is your take on ESBs? Do you have questions for a reporter to ask? Let us know.