Part I: It's a Web Services World
By Annrai O'Toole
In the previous article, I wrote about why SOAP and Web Services are important technologies and how they will impact the way in which we build applications. This article is dedicated to a deeper discussion of Web Services. A taxonomy is provided that explains how Web Services are being used, and therefore, what functionality is required by Web Services Platforms to support this functionality.
The Web Services Spectrum
While many people agree that Web Services is a hot new technology, very few are sure about the exact definition of Web Services or the types of problems that can be solved by Web Services. Beyond agreeing that Web Services are defined using WSDL, are accessible using SOAP, and registered using UDDI, very little else is agreed upon. Of course, this is a natural state of affairs for two reasons: first, WSDL, SOAP, and UDDI are powerful and flexible technologies that can support a very wide set of use cases, and secondly, we are in the early days of the Web Services World.
There is a wide variety of use for Web Services. One set of users sees Web Services as a very simple Internet technology that can be used to replace some of the existing Internet screen-scraping techniques. Rather than trawling a site and pulling data from pages based on an implicit understanding of how that data is formatted, a SOAP interface can provide an explicit well-formed interface to that data. These users see SOAP as a convenient protocol that offers little or nothing in the way of guarantees or quality of service, and in fact believe that minimal SOAP implementation can meet all their needs. These users do not perceive Web Services as a new programming environment, rather as a useful adjunct to their existing collection of Web tools. For these users, the key to success is a wide variety of tools designed for mainstream developers that makes Web Services as easy to use as FrontPage.
The other end of the spectrum is defined by a set of users who see Web Services as a new distributed computing environment. These users come from a J2EE, CORBA, or COM heritage and are familiar with all of the usual technologies associated with distributed computing. They see natural extensions to Web Services as including support for stringent security, asynchronous messaging, and message logging and auditing. These users would like to introduce a whole new set of APIs and programming paradigms that would elevate Web Services to a new rich and complex development environment. Tools will also be important to this group, although the emphasis will be on productivity rather than simplicity and user-friendliness.
Naturally, neither of these two extremes provides a likely path for the evolution of Web Services. As usual, the truth is somewhere in the middle. In order to understand this point in greater detail, it is necessary to define a taxonomy of possible Web Services usage.
The Web Services Taxonomy
When thinking about Web Services, it is useful to divide them into two major use cases: behind the firewall and on the Internet. Cape Clear terms these as "IntraWebs" and "InterWebs". In both cases, there are the same core sets of technologies. However, each has slightly different requirements.
Some Web Services will only ever be used inside the firewall. In fact, much of the early usage for Web Services is inside the firewall. Web Services provide a solution to one of the most pressing information process problems: application integration. Over the last few years, companies have invested in a variety of application-integration solutions. From integration brokers based on messaging technologies through custom developed "connectors" to packaged applications, a whole slew of techniques have tried and, in nearly all cases, come short of the mark. With the advent of Web Services, there is a simpler solution based on XML and standard Web protocols.
In thinking about Web Services as an application-integration solution, you can refer to the online video demonstration application on Cape Clear's Web site, which features Microsoft PowerPoint being integrated with a useful Web Service: the California traffic conditions.
There are several useful observations from this simple demonstration. First, what may have once been an expensive integration project involving complex, expensive, and proprietary software is now something that almost anyone can do. Secondly, and more importantly, the reason that this integration is possible is because Microsoft now includes a default application integration stack (that is, the Microsoft SOAP Toolkit) in the Windows operating system.
The importance of this default SOAP stack is hard to over-emphasize. For many years, all previous attempts at application integration have included a Windows integration solution. In each case, these were bridges that different companies developed to link Windows-based applications with other non-Windows applications. Examples have included solutions from BEA, IONA, NEON, and Tibco. These solutions had to be installed and configured on the Windows client and always suffered from difficulties, because they were external entities to the Windows platform. In many ways, it was analogous to the period before Microsoft included a TCP/IP stack in Windows. When you had to buy an external TCP/IP stack for Windows, it was always very difficult and cumbersome to install it on the Windows machine. Then, when Microsoft bundled a TCP/IP stack in Windows, it created a revolution: the Internet. The inclusion by Microsoft of a default and ubiquitous application-integration stack will have a similar impact on the way in which applications are tied together. Other vendors will eventually include a SOAP plug-in with their products, which will increase the usefulness of Web Services Platforms.
In fact, Cape Clear believes that Web Services and IntraWebs will drive down significantly the cost of application integration in the enterprise and will supersede all previous integration solutions. Web Services commoditize the syntactic levels of application integration, because they provide a common and ubiquitous application-integration stack.
Copyright 2001, Cape Clear. Reprinted by permission.
FOR MORE INFORMATION: