Web services: Is it CORBA redux?
Sonic Software executive Gordon Van Huizen warns that the future of Web services is in real jeopardy--though not for the reasons many might initially think.
Valid concerns, to be sure, but concerns that will be addressed. The gradual, evolutionary approach that the Web services community has shown toward standards is more likely to create a successful end result than that of the massive B2B standards frameworks that have come before. The Web was built upon simple--and incomplete--standards. And despite the fallout of wacky business models, the Web represents the single most significant development in information exchange since Gutenberg.
Still, the future of Web services is indeed at risk--though not for the reasons that many people think. The two things that could actually kill Web services adoption are improper Web service implementations and lack of planning for successful launches.
The correct use of SOAP
Web services can be implemented in basically two ways--either by exposing an application interface as a Web service or as a "document-based" Web service. One is not as good as the other. In fact, the former, commonly referred to as RPC (Remote Procedure Call) Web services, has flaws that could turn Web services into this decade's CORBA (Common Object Request Broker Architecture).
In RPC-style Web services, an existing object's method calls are mapped to Web service interfaces by generating WSDL (Web Services Description Language). This mapping allows an object to be invoked
| Unfortunately, RPC-style Web services are fundamentally flawed as an integration approach. |
Can you imagine a business scenario where rooms full of salespeople wait silently on the phone for hours until prospects give them their attention? That's precisely how RPC-style Web services work. The calling application waits for a response from the service it seeks to invoke.
Worse still is the problem of service availability. In the world of business computing, things like scheduled downtime, system failures and network outages are the reality. RPC-style Web services can't cope with such intermittent behavior.
RPC-style Web services are quite easy to develop and very well supported by today's Web services tools. Consequently, they are currently the most prevalent approach to Web services. Unfortunately, RPC-style Web services are fundamentally flawed as an integration approach.
The alternate approach of document-based Web services, also known as "messaging style" Web services, provides several capabilities that make it more viable.
• Abstract interactions--This is incredibly important for the consumption and maintenance of Web services. For a service to be successful, it must be readily understood by people other than the original developer. In messaging-style Web services, the interface is a self-describing XML (Extensible Markup Language) business document, as opposed to a literal representation of an application's object architecture. It is much easier for a consumer to efficiently process a self-describing document than to decipher a number of fine-grained objects, methods and their meanings.
• Asynchronous processing-messaging-style interactions decouple the invocation of a Web service from the provided response. The calling application doesn't passively wait for a response from the service, but reacts to the response whenever it comes in. Messaging-style Web services also provide resiliency as an inherent capability of the interaction model, naturally insulating applications from system and network outages.
• Ease of maintenance--It's easier to deal with new document versions that contain additional document fields rather than with the ripple effect of changing fine-grained application interfaces. In the latter case, a simple change can break a whole chain of calling applications. Documents simply provide a better form of insulation between the conversing applications.
| A Web service-enabled application is not unlike a computer with a network connection: It's the beginning of the story. |
For Web services to be successful, it must be implemented using a messaging-style approach. If we fail to make this architectural transition, widespread adoption and integration through Web services will be stalled.
Bring 'em on
During this formative period of Web services development, many are focusing on how to simply create Web services and get two of them to talk. The real challenge is to manage a number of Web services across a distributed enterprise. This requires infrastructure.
A Web service-enabled application is not unlike a computer with a network connection: It's the beginning of the story. A computer network requires Ethernet routing, switching, network management and network security. Similarly, Web services installations will require a scalable software infrastructure that offers directory services, SOAP routing, service management and pluggable security across the enterprise. Enterprises that fail to plan for this will not be able to fulfill the promise of Web services as its adoption grows.
Web services offers a great deal of promise as a next-generation integration technology. But building a Web service using the wrong techniques can render it utterly useless in the long run. And not adequately preparing an organization--and its infrastructure--for a world of Web services can result in unfulfilled promises.
Certainly there are additional areas where Web services must mature and evolve, but if we don't start with the right underlying model and adequately support its release, it will never get the chance.