SOA complicated by ESB proliferation |
 |
By Rich Seeley, News Writer
17 Jul 2008 | SearchSOA.com |
|
|
Enterprise service bus (ESB) intermediation remains an issue despite the adoption of WS-* standards, argues John Michelsen, chief architect at iTKO Inc., the testing vendor specializing in service-oriented architecture (SOA).
|
|
|
|
|
They're finding that two or three different divisions of their company are using different ESBs from different vendors.
John Michelsen
chief architect, iTKO Inc.
|
|
|
|
|
|
|
|
|
|
"There's a whole space emerging among enterprise architects called ESB intermediation," he said. "They're finding that two or three different divisions of their company are using different ESBs from different vendors. Yet they're trying to build business processes across these ESBs. But the ESBs are designed to be their own center of the universe. How do you intermediate transactions across these ESBs?"
This leaves enterprise architects facing the problem of how to integrate the integration platform, said the architect for iTKO, which seeks to maintain a Switzerland-like neutrality and support testing for all the vendors in the SOA marketplace.
The problem has grown despite advances in Web services standards, which were supposed to provide interoperability for corporate IT environments where more than one vendor's ESB is in place, according to Michelsen. But it has not worked out that way, he said.
"There are hundreds of WS-* type standards," he said. "Every platform supports some subset of those, but even in claiming support there is variability in the way it's supported."
This is the inconvenient truth that enterprise architects run into when designing projects that cross different ESB implementations in a corporate IT environment, he said.
"I wish it was the case that I could write some software component completely independent of the platform it's running on and just deploy it anywhere in the world and magically have it work," Michelsen said. "But that is so far from reality."
In the most simplistic scenario the standards do support cross-vendor ESB integration with a minimum of customization, he said. But if any complexity is added to the mix, technically possible, becomes realistically problematic.
"As soon as it gets interesting – and interesting might be security requirements, business rule requirements, integration with governance engines or business process models – all of a sudden vendor-specific variability in how the standard is implemented cause people to get stuck," Michelsen said.
Not all WS-Security is created equal
When an architect looks at vendor data sheets for products from more than one vendor, it appears that everything will work together nicely, he said. In the spirit of SOA the architect should be able to select best-of-breed governance from one vendor, and a runtime engine from another.
"They all supposedly handle WS-Security," Michelsen noted. "So I should be able to bring those products into my environment and use WS-Security and I'll be fine, but in reality there are permutations of how you can use WS-Security, and those products are very unlikely to support them all the same way."
Currently this presents a problem for architects and developers that has to be solved with custom integration among the products that are supposed to be providing integration.
"That's not the right place for that to be done," Michelsen said. "Early on we had no choice, but as vendors consolidate we're getting better at it."
The iTKO architect said the problem is being alleviated to some extent by the recent mergers and acquisitions among SOA vendors, including Oracle Corp.'s purchase of BEA Systems Inc., and Progress Software Corp. buying Iona Technologies Inc.
With customers facing this problem, Oracle Corp.'s move to consolidate its own ESB with the one it acquired with its purchase of BEA Systems Inc. is a "good strategic move," Michelsen said.
He sees this consolidation as a necessary function of maturity within the industry. In the case of Oracle's melding its ESB with the technology from BEA, the SOA architect technically has fewer product choices, but the result is that pragmatically an integration problem has been solved by that vendor merger, he said.
|
|
|
|
