Position Paper for W3C Workshop on Web services Rael Dornfest, O'Reilly & Associates In a JavaOne keynote[1] titled "The Network Really is the Computer," Tim O'Reilly articulated much of what's interesting and obvious about the emerging loosely coupled archicture now knows an Web services. I want to talk about the implications for that marvelous aspect of the fundamental UNIX design: the pipe, and its ability to connect small independent programs so that they could collectively perform functions beyond the capability of any of them alone. What is the equivalent of the pipe in the age of the web? First Web "Services" The explosion of CGI scripting in the mid to late nineties saw the Unix command-line make its way to the Web browser's address field in the form of a URL-line command, replete with arguments. The URL became a primitive remote procedure call (RPC). Anyone able to string together a few lines of Perl was effectively a Web service provider. Now while some were explicitly creating such services, the majority were not, in fact, intended as such at all. They were dynamically generated Web pages meant for eyeballs, not automated retrieval. Yet they were being screen-scraped, parsed, their information extracted and re-used -- subverted, really. Ad Hoc APIs The recombinant possibilities proved interesting enough for some providers of dynamic content to make explicit, even document the interfaces (APIs) to their fledgling services. The O'Reilly Network, for example, comprehensively documented the URL-line API for our Meerkat Open Wire Service[2]. Still others were programmed to and documented by 3rd parties; classic examples are the Finance::Quote::Yahoo and WWW::Search Perl modules[3] which indulge in the bounty that Yahoo! Finance and the various Web search engines have to offer. But screen scraping is no easy job and requires constantly keeping in step with the slightest design change in the source Web site. What was needed was a separation of presentation and content. XML and RPC The next generation of Web services is being built on XML, specifically RPCs using XML serialization. Currently this means XML-RPC and SOAP. Developers may now build more comprehensive, reliable applications on these loosely-coupled services. While still a primitive star-model, with the application at hand calling out to these various services individually, SOAP has the capability of stringing together or piping input and output for more interesting outcomes. Calls to Action Web services have preserved much of the ad hoc nature of their URL-line ancestors while moving toward greater reliability, interoperability, and standard APIs. While efforts to provide more guidance and structure are, on the whole, a good thing, we must take care not to stifle the creative recombination and "ad hoc'ism" which have taken Web services so far. Also, with various companies competing to provide _the_ Web Services framework, we need to remain true to open standards. There's been some grumbling about such issues as Microsoft's role in the furtherance of SOAP and UDDI's qualification as an "open standard." About O'Reilly & Associates O'Reilly & Associates[4] is the premier information source for leading-edge computer technologies. We communicate the knowledge of experts through our books, conferences, and web sites. The O'Reilly Network[5] is the online source for open and emerging technologies. O'Reilly will be holding its second Peer-to-Peer and Web Services conference[6], September 17-20, 2001 in Washington, DC. [1] http://www.oreillynet.com/pub/a/network/2000/06/09/java_keynote.html [2] http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html [3] http://search.cpan.org/search?mode=module&query=yahoo [4] http://www.oreilly.com [5] http://www.oreillynet.com [6] http://conferences.oreilly.com/p2p/call_fall.html