Avoiding Vendor Lock-In
With the sprawling nature of SOA, and the immaturity of some SOA-related standards, vendors want to reel you into their proprietary world.
InfoWorld — Although most SOA bottlenecks relate to governance, some are technological. The biggest hazard is a lack of maturity in some standards necessary to create a reliable, available SOA—giving vendors the opportunity to lock in customers through the use of proprietary technologies.
A number of Web services standards for integrating and orchestrating communication among services are well established and well understood, such as SOAP, XML, and WS-Security. Even when the standards are in place, however, vendors may implement or interpret things differently.
“The vendors all say they’re following the standards, but when you look closely, they have their own versions of those standards,” notes Unisys’s Young. In some cases, that’s an intentional act by a vendor to support its own products, such as IBM’s use of WS-SRR for service registration in its WebSphere middleware, which is not compliant with standard UDDI registries, notes analyst Manes. Although IBM does deliver some registry information in UDDI format for use by other vendors’ tools, IBM’s own tools don’t use UDDI, she notes, in essence making IT maintain two approaches or go with an IBM-only one for simplicity. SAP also promotes its own interfaces, she notes, but not to the exclusion of others and not at the infrastructure level.
In other cases, such as policy management and event processing, no mature standards exist, so vendors come up with their own approaches to fill the void. “There’s a danger that proprietary details will find their way into the service architecture, leading to vendor lock-in,” cautions consultant Thomas Erl. Even if IT avoids this problem, it ends up having to integrate the different expressions of its service policies across tools using transformation technology. “That can become a bottleneck,” he warns.
One approach is to not embed policies in tools but to treat them as centrally available services, says Momentum SI’s Vazquez, so you avoid a web of point-to-point integrations that is hard to manage. For example, if you store policies centrally in a webMethods or Systinet registry for use at design time, you may also make them available to be consumed at runtime by other tools. But such design-time registries don’t publish to a runtime broker such as Actional’s, introducing synchronization issues, he notes.
Erl suggests another approach: using XML to apply a standard set of schemas to data as essentially a runtime transformation service. “But this requires a consistent application of the design standard, both within projects ands across project domains, Erl notes.
Ultimately, Vazquez expects these issues to fall away, as vendors mature their technologies and agree on standards. Already, two new standards to help normalize the way service-based applications are created, SCA (service component architecture) and SDO (service data objects), have broad industry backing and momentum. And Microsoft's recently released WCF (Windows Communication Foundation) rolls up a stack of Web services protocols in various stages of maturity and should help establish them as de facto, widely adopted standards.
Galen Gruman is contributing editor at InfoWorld.
