Eric Newcomer, IONA Technologies
Web services were initially intended for use over the Internet, but have gained adoption inside the firewall instead. Many of the WS-* specifications focus on adding into HTTP and the Web architecture capabilities that were avoided on purpose in order to achieve the scale necessary to support the world wide Web.
Today the enterprise software industry is moving more slowly toward standardization than the Web, and the costs remain prohibitively high for creating new applications and modernizing existing applications. These costs affect virtually all industries and government agencies because IT, although by itself only about 10% of a country’s GDP spending, represents the lubrication that drives most of the economy.
Open, standards-based software is key to cutting cost on emerging business opportunities, many of which depend upon enterprise software systems, including such applications as global banking, multimedia and mobile Web, efficient hard goods manufacturing, energy exploration, and so on. The daily costs of doing business without enterprise software standards are quickly becoming greater than the cost would be of imposing them.
However, industry factors such as competition and entrenched vested interests tend to slow such standardization and likely require external forces to be brought to bear, similar to what happened during the standardization of interchangeable parts. Henry Ford leaned hard on his suppliers in order to achieve the mass production of automobiles through the assembly of interchangeable parts from multiple suppliers.
The commercial, industrial, and social benefits of the standardization of the Web of documents is well understood, but the next, perhaps more significant frontier, is the standardization necessary for the Web of services for enterprise computing, which remains at a very early stage.
Good software standards specify interfaces and protocols, not the underlying technology of the software itself.
Web services specifications, starting with SOAP 1.1 in early 2000, seem like the best candidates to date for standardizing enterprise software. WSDL defines the interface and SOAP defines the protocol. Both are applications of XML, which is independent of underlying software execution environment technology.
Like XML, the SOAP and WSDL specifications were designed with extensibility in mind, and for compatibility with multiple existing communications protocols and data formats already in use within the enterprise, thus creating a kind of interface/interoperability overlay to existing and new software technology environments. And in fact this capability has been proven with the relatively widespread adoption of both WSDL and SOAP among software vendors and customers alike.
However the approach taken by SOAP defined an almost “hermetic” envelope designed to contain all information necessary to process its contents. Other messaging systems will associate a message with externally managed metadata instead, for example some of the uses of “plain” XML over HTTP.
As the SOAP and WSDL approach evolved during the past 5-6 years, more and more features and functionality typically associated with enterprise computing has been added. In particular capabilities such as security, reliability, transactionality, addressing, policy, management, advanced messaging, metadata management, and so on have been proposed, largely in response to customers who told vendors “if you want me to deploy that new stuff it has to be just as secure, reliable, etc. as the old stuff.”
But can it really be said that the goal of enterprise software standardization has been achieved through SOAP and WSDL? Has the cost of assembling software components from multiple suppliers been significantly reduced, or the efficiency of connecting software systems from multiple suppliers? Has the time it takes to modernize existing systems been reduced?
Or has the adoption of Web services specifications tended to be adapted towards extending and enhancing existing vendor technologies more than toward meeting the goals of industry standardization?
The original target for SOAP was for use as an XML protocol over the Internet, as evidenced by the name of the W3C working group established to progress it. However today it seems that SOAP and WSDL and WS-* specifications are being used for applications inside the enterprise rather than between enterprises. Even in this successful area of Web services adoption, the interpretation and significance of WS-* tends to vary considerably from product to product, and application to application.
Within the enterprise existing applications rely on existing system software, which typically is developed and engineered to a different set of architectural constraints than the Web, and traditionally was developed and deployed using a single vendor’s software system. The Web architectural constraints (described in Fielding’s by now famous thesis) are there to ensure scalability on a worldwide level. Many existing enterprise software technologies were designed for use in bespoke applications with a finite, and usually predetermined, number of users, and for deployment using a specific technology.
Inside the firewall and outside the firewall, if you will, are often very different environments, and while most, if not all, modern businesses have a Web presence only those enterprises designed specifically for Web-based commerce have a coherent IT environment.
That is, most businesses and government agencies that predate the Web have IT environments that also predate the Web, and typically are built using what one might call (at least in comparison to the Web architecture) tightly-coupled software technology.
The architecture behind the “Web of documents” (aka the World Wide Web of HTTP, URI, and HTML) is an unqualified success. Businesses that have grown up with the Web such as Amazon.com, eBay, Yahoo, MSN, and others have successfully deployed large scale back end systems to process hundreds of thousands of transactions daily.
Businesses that did not initially design their systems using the scalability constraints inherent in the Web architecture often struggle to achieve good integration with the Web, with each other, and even with systems inside different departments of the same company. Until recently, software systems and applications were just not developed using any coherent or consistent architecture.
The question remains whether a system such as Web services proposes – basically of an overlay or “veneer” across existing systems will be sufficient to resolve the issues resulting from the stovepipe development of legacy (i.e. pre-Web) environments.
Meanwhile Web based initiatives such as “Web 2.0” including interactive GUIs, software as a service, and mashups have grown in popularity. Many of its proponents also propose extending the Web architecture for use in enterprise systems as an alternative to Web services.
If the problem is that Web services are unsuited for use on the Web because they have violated the constraints of the Web architecture in order to deliver on customer requirements for feature parity with existing systems (which were built without the necessity or opportunity to consider those constraints), it may be an indication that the right use for Web services is to veneer or bridge to existing systems rather than build new ones.
A hybrid approach to the problem may be best. Let the Web do what it does, and evolve and grow naturally. Over time existing IT systems may be replaced using Web technologies, but in the short term the investments in existing systems are too large to consider wholesale replacement. It just isn’t economically feasible for business and government to completely rewrite and redesign everything they have, especially when it is delivering value.
Web services specifications can be improved or refocused to define an interface between the Web and existing enterprise systems. That’s what Web services tend to be good at, anyway – interfacing and mapping to existing enterprise system features and functionality.
The promise of service oriented architecture (SOA) is that application functionality will be developed and deployed more and more as a set of reusable services, and less and less as individual applications. As businesses move toward this model and align IT operations more closely and coherently with business goals they will need standards to put in place. Web services specifications are the best suited for this environment since they can provide the interface and interoperability solution for any existing enterprise software technology.
The issue then becomes how to marry or bridge the two worlds – how to best join the world of the Web (and Web oriented businesses) with the world of the past, with the world of the traditional, existing technologies on which a majority of enterprises depend.
It appears that the industry has a requirement for a specific solution for a “REST-SOA” bridge to bring these two worlds together more effectively than current efforts have achieved to date.
The W3C, as stewards of the Web, is in a unique position to help lead the industry toward such a hybrid solution. The W3C could play an essential role in developing guidance and best practices information for how service oriented enterprise systems can be exposed and exported to REST-oriented Web based applications.