|
Friday May 25 2001 Why Open Source Developers Should Care About Web Services Changing the software distribution paradigm again Web Services have the potential to be a radically disruptive technology, both for traditional proprietary software makers and Open Source hackers. To understand why Web Services are important, we must look at how hardware platforms are changing. There seems to be movement away from traditional PCs to single purpose specialized devices that can run multiple applications, the Sony Playstation and the Palm Pilot are examples of this kind of device. More importantly, both of these devices and others like them have network capabilities. Since nobody likes the administrative overhead of installing and maintaining locally hosted applications, the idea of renting software becomes particularly appealing to both businesses and casual home computer users. In a world in which Big Business buys software functionality from a 'cyber-bazaar' of Web Services, vendor branding is going to become increasingly irrelevant. Operating System vendors will have a particularly difficult time in this environment, since it is the applications that run on those systems that consumers are interested in. If an application will run equally well on two different Operating Systems, then hardware vendors will be increasingly attracted to Open Source UNIX variants. Web Services in Sixty Seconds Web Services are a kind of Lingua Franca for application components. They are a way for programs on one machine to use the resources of another machine by, for example, making remote procedure calls (RPC). Although binary RPC has been around for decades, Web Services encode their conversations in XML and most commonly talk across the ubiquitous web protocol, HTTP. In this way, Web Services are far easier to understand and debug than traditional RPC. Because every language that wants to communicate with a Web Service must 'speak' XML, clients written in one language can make Web Service requests to servers written in a different language. Even more interesting is that operating system distinctions are also greatly diminished. There are two main dialects of Web Services, SOAP and XML-RPC. Although both can perform RPC, SOAP is object oriented and stateful while XML-RPC is procedural and stateless, this means that a SOAP Web Service can consist of several objects, and each of these objects handles RPC calls for that user, allowing the object to store information about the user between requests to the service. An XML-RPC service, on the other hand, handles all requests in isolation, and doesn't store information between requests. An example of an XML-RPC application would be a read-only Web Service interface to a proprietary database. Since no transactions are needed in this application, the limitations of XML-RPC are irrelevant. SOAP might be a better choice for distributing application logic across several machines. It is likely that each SOAP message would need to remember the application state in order to know which task to perform next. Large companies like Microsoft and IBM are very interested in making SOAP the standard Web Service protocol, but XML-RPC has been adopted by a few languages recently, such as PHP and Perl. Another advantage is that the XML-RPC specification is complete, where as the SOAP equivalent isn't. To try and avoid hassle in the future, work is being done right now to make these protocols interoperate seamlessly. Application Components Although Web Services are still in their infancy, it isn't hard to imagine a future where applications get much of their functionality from Web Service components. A simple example of this might be a dictionary Web Service that contains every known word from every language and has definitions and pronunciation guides to boot. Obviously, this is far too much information to install on a local workstation for most users. However, this dictionary might be an interesting Web Service to word processor manufacturers. When a new word enters the lexicon, for example, "bioinformatics", the dictionary service maintainers simply add this to the database and every word processor application using this service. Web Services can greatly ease the burden of application administrators by creating these 'automatic' updates. Unlike the first generation of web sites, Web Service providers will almost certainly have to charge for usage. If Microsoft Word were to use this dictionary service, how much bandwidth would that service consume? Given the large user base of Word, several dozens of millions of megabits of Internet connectivity could easily be filled during the weekdays. If the mythical dictionary service is successful, there would be a market for Web Service work-alikes. It is possible that an application will have the ability to get competing Web Service bids and automatically choose the cheapest one. In fact, there is a protocol designed to help locate and catalog Web Services just for this scenario. The Universal Description, Discovery, and Integration (UDDI) protocol works somewhat like a web search engine in that it collects Web Service descriptions into registries, which are searchable through a Web Service interface. If applications run on platform agnostic Web Services, operating systems will become much less important. Most users only care about applications, not the system that hosts it. If 'killer' applications become available on open source UNIX variants, operating system vendors will have an increasingly tough time finding customers. Where's the Open Source? Although many Open Source Web Service libraries exist for many languages (C, Perl, Java), the Open Source community has not fully embraced Web Services in application development. There are some signs that this is changing, for instance, both of the most popular Open Source desktop environments, KDE and Gnome, are developing Web Service hooks that will allow those environments to be fully scriptable from a Web Service client. Maybe one problem Open Source developers have with Web Services is that the code responsible for actually implementing a service is rarely on the machine requesting it. This separation of code and functionality greatly reduces the incentive to look at the underlying source code. Worse still, there is no Open Source license (like the GPL or BSD license) that adequately covers Web Services. This means that applications might freely blend Open Source services with closed source services. Certainly, the application user will not be aware of the difference. A Problem of Bandwidth One last ingredient in the Web Service stew is network bandwidth. Web Services are slow compared to traditional local function invocations because a call and response have to go over the network. If Web Services dominate the construction of new applications, a wide network pipe will be needed to support even a small workgroup. To date, there isn't a defined system of caching Web Services. If mission critical applications depend on Web Services, bandwidth providers will have a far greater influence on a user's desktop experience than ever before. Since no no-cost venture has been able to effectively deliver high-speed Internet access, ISPs could be in for a huge windfall. It is tempting for Open Source developers to look at Microsoft's marketing blitz surrounding .NET and scoff. Unfortunately for them, Microsoft is positioning itself for the future. Because only descriptions of Web Services are needed in order to use them, Web Services greatly reduces the need for vendor-supplied libraries to be installed on local workstations. A Web Service aware application will become a small shell of a program that contains display logic. Where does this leave the Open Source community? It won't be hard to create Open Source work-alike applications to access the same services that the closed source version does, but is that the point? The Open Source movement is about the freedom to play with code as if it were a box of Lego; Web Services just might take the most interesting parts away. |