In complex integrations, the ESB is often blamed when things slow down. Moreover, it may not deliver on SOA's promise of greater services reusability, if it is not configured correctly.
Among ESB development challenges cited by respondents to the 2011-2012 SearchSOA.com Readership Challenges & Priorities Survey, complexity leads the way, cited as a challenge by 77% of respondents. That's followed by performance at 65% and maintenance at 53%.
We asked about ESB performance issues recently while speaking with Lee Ackerman about SoaML design. Ackerman, CTO with The Emphasys Group, said building the right services in the right way can only follow from a service design that achieves the right level of granularity of services. As with EJBs or other component types, he said, you pay a price when you go over the wire.
"If you have built a bunch of services and you put them into an ESB and they don't perform well, you may have goofed on the design," said Ackerman. He pointed to policies for configuring the ESB as a sign of trouble areas.
"If you are at a point where the policies are overly complex within the ESB, it is a sign you have to look at the services you have designed to make sure they are the right services, that the granularity is correct, and that they have the right responsibilities," he said.
This performance advice is echoed by Jeff Bradshaw, CTO, Adaptris. Overly large messages and application logic are issues too, he adds.
"Sometimes, when getting thousands of messages per second, when there are big messages, things slow down," said Bradshaw. "Then it becomes a question of the logic you embody within the ESB. It is very important to make sure you are using the ESB for the right things."
"The ESB should be all about mediation logic and getting the message from here to there. It is about making sure it is in the right format. It is more mediation logic than anything else," said Bradshaw.
Take care with ESB and application logic
“When you start putting application logic in the ESB, in my opinion, that is a wrong pattern, and that’s where an ESB gets a bad name. If you want to write an application, then you use an application server,” he said. “Don’t host it in the ESB container.”
Bradshaw admonishes development teams to remember that ESBs are basically integration tools. The ESB is “all about mediation logic, not about application logic,” he emphasizes.
We are all familiar with the notion of using the right tool for the right job. The adage has application in integration.
“Some of the larger consulting companies will try and use an ESB for everything, and put all the logic inside the ESB,” asserts Bradshaw. Application logic should be put in an application server that “can scale much more,” he said.
When digging into the ESB design issue, Bradshaw looks at data governance and XSLT, a popular choice for transforming XML.
“All of the ESBs on the market today use XSLT for transformation of XML. The problem is you will find developers tend to begin coding business logic into those XSLTs,” he said. “There lies the problem.”
Over time, code such as this is more likely to break and, as has been observed in the past by SOA viewers, these breaks are hard to track, especially in the face of multiple versioning.
This is one of those issues that can threaten SOA’s and ESB’s reputations with operations people. When the break is in a typical software stack, operations people have a better chance of uncovering the bug.
“When it is SOA, the problem tends to be random. People put the logic in really random places, and it’s hard to track,” said Bradshaw.
This was first published in April 2012