The Internet groupware services—HTTP, SMTP, and NNTP—manifest themselves to users as browsers, mailreaders, and newsreaders. Because these same services can be driven by scripts that speak simple ASCII request/response protocols over TCP/IP sockets, interactive and batch modes are two sides of the same coin.
We’ve already seen a number of examples of this duality. In Chapter 8, we used web-client scripting to intercept and process the output of the Microsoft Index Server. In Chapter 9, we used a news server as a discussion component and a mail server as a message dispatcher. In Chapter 10, we saw another kind of duality—a Java servlet both provided a web API, used by other programs to import and export calendar data, and consumed a web API provided by a “todo” server.
We think of the Internet as a library of documents, but it’s also a library of software components. Some are microcomponents , like the Perl modules that you’ll download from CPAN if you decide to try out some of the examples in this book. Others are macrocomponents such as AltaVista, Yahoo!, or any Internet (or intranet) site that offers services accessible to browsers and scripts alike by way of a web API. Web sites are scriptable components just because they are web sites. And they’re made of microcomponents and macrocomponents that can exploit a rich assortment of other components, both local and remote, to do their work. The Internet makes distributed, component-based computing not just easy, but almost automatic—like breathing.
Industry pundits have long predicted the advent of an object Web , a global network of distributed software objects. “The network is the computer,” said Sun Microsystems’ chairman and CEO Scott McNealy. Depending on whom you talked to, the technology that would make that vision real was Java, or CORBA, or DCOM, or directory services. As it turns out, none of these technologies has yet fundamentally altered what the Internet could already do pretty well—namely, connect people to other people and to data using simple, easy-to-understand protocols.
What does all this mean to you as a developer of Internet and intranet groupware applications? Two things. First, you should aggressively exploit the existing library of Internet-based components. Second, you should realize that your own applications are also components, use them as such, and look for easy ways to make them more useful in that role.
The methods I advocate in this book will seem, to some people, radical in their reliance on homegrown, scripted software. Why glue together Internet components with scripts when you could buy a shrink-wrapped commercial package that will simply provide the groupware solution you need? If you can do that, you should. There’s nothing noble about doing it yourself, and where effective alternatives exist, it’s foolish to try.
Reasonable people will differ about the extent to which commercial groupware solutions do, in fact, exist. Most would agree, though, that Lotus Notes and Microsoft Exchange don’t solve all your groupware problems right out of the box. They’ve got to be customized, because group communication is wildly idiosyncratic. There’s no such thing as a turnkey groupware system. No matter what, you’re going to have to write some code if you want to make groupware work in your organization.
If you buy that argument, then try this one. The object Web isn’t waiting for next-generation technologies to arrive. It’s already happening, embodied in the best practices surrounding existing Internet tools and applications. The Internet way of building software has become the de facto standard, and it challenges the old “build versus buy” equation. Conventional wisdom says that you shouldn’t build your own applications and components, because they’ll be slow, unreliable, and nonreusable. In fact, although homegrown solutions can suffer these ills, they need not. The same best practices that brought us the object Web, ahead of schedule and below the radar screen, can help you build, automate, test, monitor, and manage groupware solutions.