Burton: IBM SOA registry/repository competes with UDDI |
 |
By Rich Seeley, News Writer
19 Apr 2007 | SearchWebServices.com |
|
|
The IBM WebSphere Service Registry and Repository (WSRR) 6.0.1 is a classic good news, bad news story, according to a newly published Burton Group Inc. report.
|
|
|
|
|
The fact of the matter is that IBM wants enterprises to adopt WSRR and abandon UDDI.
Anne Thomas Manes
Research Director, Burton Group
|
|
|
|
|
|
|
|
|
|
There is solid technology in the registry/repository, according to Anne Thomas Manes, Burton research director and author of the report, "IBM WebSphere Service Registry and Repository v6.0.1," published this past week. "WSRR supports a number of compelling features, including an open content model, customizable lifecycle management processes, and tight integration with other IBM WebSphere products," she writes.
However, she faults the IBM product for not directly supporting Universal Description, Discovery and Integration (UDDI), which she describes as "the principal industry standard for SOA registries." For this reason, she concludes that "WSRR is inappropriate for use as a runtime registry in enterprises that don't exclusively use WebSphere products in their SOA infrastructure."
Manes finds some UDDI support in WSRR because it is built on WebSphere Application Server (WAS) v6.1, which includes what she describes as a "bare bones" implementation of the latest UDDI 3.0 standard from OASIS. But while IBM promises enhanced support for UDDI in an upcoming release in this quarter, she does not believe Big Blue's heart is in UDDI.
"UDDI is clearly not a strategic priority for IBM," Manes writes. "The fact of the matter is that IBM wants enterprises to adopt WSRR and abandon UDDI."
While she acknowledges that WSRR works well within a WebSphere-based implementation of SOA, she sees heterogeneous environments as problematic.
"The problem with IBM's strategy is that SOA is by default a multiplatform endeavor," Manes writes. "Few enterprises have the luxury of maintaining a single-vendor environment."
For SOA implementations, the Burton report describes the "typical large enterprise" using multiple language platforms, including Java, .NET, Ruby, C++, and COBOL, and multiple enterprise service buses from vendors such as SAP AG and Tibco. This typical IT shop also uses SOA infrastructure products and packaged applications from vendors like Oracle.
"None of these third-party products integrates with WSRR," Manes warns her readers.
She finds Big Blue's registry/repository strategy curious, because IBM along with Microsoft, which also has its own homegrown approach to SOA, were founders of UDDI.org, along with Ariba Inc. However, the efforts by those three vendors to establish a global directory system for Web services transactions did not catch on, Manes said. UDDI.org was eventually subsumed by OASIS when it took over development of the directory standard.
However, moving beyond UDDI has not hurt IBM sales and marketing, Manes acknowledges in her report, because of the company's large installed base for WebSphere, for which she find WSRR well suited.
"IBM has been able to establish a leading position in the SOA registry and governance market with a non-standard offering because of the dominance of the WebSphere superplatform," Manes writes. "WSRR v6.0 was released in September 2006, and IBM was able to close more than 40 customer deals in the remaining 65 days of 2006. Market clout has its advantages. In a very short period of time, WSRR has achieved second place in the rapidly growing SOA governance market, following Hewlett-Packard and its Systinet family of products."
Despite her criticism of the lackluster support for UDDI, Manes concludes that WebSphere shops will find WSRR appealing because it enhances the capabilities of the IBM platform for SOA. Organizations with a mix of WebSphere and other vendor products, might consider using WSRR along with a UDDI-compliant registry, but might be better off with a vendor neutral implementation of UDDI, she suggests.
Finally, she counsels: "Organizations that don't use WebSphere products should look elsewhere."
|
|
|
|
