<<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).
"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.>>
You can read this at:
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1321663,00.html?track=NL-110&ad=651140&asrc=EM_NLN_4061167&uid=5532089
Gervas
