james_kobielus
Contributor

Web services standards need to mature before SOA can really take off

How-To
Oct 10, 20053 mins

Web services standards need to mature before SOA can really take off.

Companies today can implement a limited form of SOA in traditional middleware environments, such as Common Object Request Broker Architecture and Distributed Complement Object Model .

However, those pre-Web services SOA implementations are tightly coupled to the native object models, methods and APIs of particular operating and application platforms. Consequently, changes to the underlying, tightly coupled platforms can disrupt interoperability with consuming services.

Web services are the first middleware and development environment that can truly be called platform-agnostic. Web services enable more complete service virtualization, abstraction, loose coupling and reuse than any prior environment. Web services are the preferred environment for thoroughgoing SOA.

The problem is that critical Web services standards have not yet been finalized, ratified or adopted broadly by vendors and users. According to a recent IDG Research Services Group survey, IT professionals ranked incomplete and immature Web services standards as one of the top inhibitors of SOA implementations in their companies.

The Web services stack like SOA is a work in progress. It is not yet a full-featured alternative to older object-brokering and message-oriented middleware protocols. And it is not a unified set of specifications under single authorship, management or governance, and probably never will be. It is being defined by diverse organizations, including Organization for the Advancement of Structured Information Standards, the World Wide Web Consortium and various vendor partnerships.

In addition, there is considerable industry disagreement and rivalry regarding which specifications should prevail in many areas, such as federated identity, reliable messaging, event notification and transactions.

Even in functional areas where the industry has already converged on standards, it might take years before most vendors have implemented those standards in their products and have worked through the interoperability issues associated with diverse implementation of agreed-upon standards.

Factoids
To realize the nirvana of SOA everywhere, the following, at minimum, must happen:

SOAP, the principal Web services middleware protocol, must be implemented natively in all new application development and integration projects.

WSDL, the principal Web services API, must be used to expose the functionality of new applications, and to wrap existing services, applications, operating platforms and other resources as Web services.

UDDI, the principal Web services registry environment, must be implemented throughout your application infrastructure and all WSDL and other service metadata and policies must be published to those registries.

Until such time as the industry converges on universal, comprehensive, stable Web services standards in various functional layers, Web services — as a complete SOA stack — will remain immature.

Hold the bus

But that doesn’t mean you can’t implement SOA. Sharing and reuse still can proceed in a heterogeneous infrastructure. To address this stubborn reality, a flexible enterprise service bus (ESB ) infrastructure can provide “impedance matching” between diverse standards, versions and implementations.

ESB products come from a broad range of middleware vendors, including Cape Clear Software, Fiorano Software, IBM, Iona, Sonic Software, Systinet, Tibco Software and webMethods. Depending on the vendor and product, ESB products provide any and all of the following features for a robust SOA infrastructure:

  • Wrap legacy environments with WS-* interfaces, thereby supporting legacy integration.

  • Provide any-to-any interoperability through integration brokers, which provide orchestration, transformation and routing services among distributed services, applications, data repositories and other resources.

  • Support content-aware monitoring and enforcement of performance, security and other enterprise policies pertaining to Web services traffic.

  • Support the request-response, event-driven and method-invocation message flows among distributed services.

  • Support reliable messaging, transactional coordination and other robust interaction patterns.

  • Support hub-and-spoke, decentralized and peer-to-peer message exchange patterns.