Services are now a fixture of computing, whether it's local to a single system or on a network. Two parallel innovations, component models and the Internet, have propelled software designers to break up applications into clients and servers -- sometimes multiple, cascading servers.
Many of us sense that the next stage of components, involving Web services, will shake up applications even more. And recently, it's started to look as if the application, once the central fixture of computer use, would dissolve into a soup of servers, application fragments, and user interfaces. This article attempts to convey the flavor of this soup in some palatable fashion.
Many pundits in computing have already tried to reorient the public with prophesies about far-reaching changes in the roles of applications and services. So let me start by summarizing what has been predicted:
Components (a further formalization of object orientation) will dominate application development.
XML, by undergirding a wealth of standardized data exchanged formats in each field, will lead to a formal separation between data formats and presentation.
Application Service Providers (whose first attempt to establish a place in the software industry in the '90s imploded) will flourish once more through the standardization of Web services.
Future commercial success for software developers, and for Microsoft in particular, will come from providing more services in place of standalone applications.
Grid computing (distributed computing in the manner of SETI@home) will tie in with Web services to provide computing power on demand, like electricity.
Since each claim has been debated and defended persuasively by others, I will not try to elaborate on them but rather, will draw on the terms of the debate to lay out a possible direction for applications.
To a large extent, the standalone application is already dissolving. Many people are used to doing everything from a single platform; for instance, you may have viewed and even edited a spreadsheet in your browser. And I hate to admit it, but the antitrust flap over Microsoft's integration of desktop and browser obscured the simple and obvious fact that it makes sense to integrate them. The free KDE desktop does much the same thing by integrating the file manager and browser.
Let's not get distracted by the superficial results of historical accidents. The choice of a browser as a locus for all activity, like the choice of port 80 for new services and of HTTP as a communications platform, was an arbitrary convenience. These possess no characteristics that make them the natural basis for applications, any more than English is the natural basis for international scientific communication. The provision of SOAP over JMS instead of HTTP represents at least a hint that HTTP itself will no longer remain the only game in town. Browsers will either keep up or recede in importance.
So let's add in a few new trends to see where applications are going.
The first trend is far-reaching customization. The Mozilla project, which exposes every possible element of its interface to change through XUL, probably leads the pack. I am disturbed that Apple recently shut off the previous capability to tweak the Macintosh desktop; this is going in the wrong direction altogether. I forgive them because of their work on what may be of much more historical importance in the development of interfaces: a simple voice-activation interface described in an article by Jon Udell. But Microsoft has also been quite bold in providing an API to its Office suite that makes it easy to add customized functions, menu items, and even whole new taskbars.
Following Microsoft's stated strategy, this API turns familiar applications into delivery vehicles for Web services. Masses of people have experienced this effect by downloading the Google plug-in to the Internet Explorer browser.
The plug-in displays a little text box into which you can type a search term. The search term is sent to Google and the browser displays the results. The activities are seamless and neat, and you save a little time by dispensing with the need to visit http://www.google.com. Still, you sense that you are running a separate service (Google) within your hosting application (Internet Explorer).
To stretch our perceptions of what Web services could be, let's look at two products in the relatively new area of peer-to-peer collaboration. This type of software first caught the public's eye in the form of Ray Ozzie's company Groove.
Collaboration tools show users the same documents in the same state regardless of what systems they are on, make networks practically disappear, and let people feel like they're sharing a single window into a single application. These products feature workspaces that might not exist physically in any particular location, but appear to users as sets of windows that multiple collaborators can work in simultaneously. Collaborators form self-chosen communities and can enter their workspace from anywhere, unconstrained by the layout of local area networks or movement between work, home, and mobile devices.
Microsoft's SharePoint shows a tentative move beyond the old "update ... transfer ... update ... transfer" model," toward more flexible kinds of collaboration tools that make a document or conversation appear to all participants in a workspace at once. I have recently tried demonstration versions of two collaboration tools, Groove and Tenix from the data Corporation (small "d"), and have learned something from each.
Groove was my first exposure to the potential for deep integration. The product feels like instant messaging (in fact, messaging is one of the tools it offers) but it extends the immediacy of instant messaging to just about anything you can do on a desktop.
A simple example of using Groove is for two people to edit a document together. Starting collaboration requires a single deliberate act: putting the document into the Groove workspace. But after that, my colleagues and I can edit and see each other's changes as we go along, an immediate and unmediated experience.
When I tried Groove back in early 2001, I joked that it would become significant when multiple users could use it to simultaneously edit a Microsoft Word document. And that's precisely what Groove proceeded to do! They integrated Word into Groove, thereby allowing Groove-style collaboration within the framework of Word. Since Groove Workspace 2.0, the company has provided real-time editing and viewing capabilities for Word documents, and real-time viewing of PowerPoint presentations.
It's important to point out that Groove achieved this level of integration by using Microsoft's public, published APIs. True, it was about this time that Microsoft invested in Groove, and then incorporated some of Groove's functions into the Microsoft packages known as MyServices, and even the SharePoint mentioned earlier. But their vice president of marketing communications, Richard Eckel, assures me Groove didn't get entry to Microsoft products through special back doors; they just did a breathtaking riff on the open theme of Microsoft's newest business model.
The buzz around SOAP and Web services has now led Groove to generalize this kind of integration. They are providing SOAP interfaces to their APIs, along with WSDL and other open standards, so that Groove's powerful features and collaboration components -- such as presence, contacts, workspaces, and workspace tools such as files, discussions, and calendars -- can be called as services by other applications.
Groove Web services radically change the whole relationship between Groove, applications, and users. The old way of using the product was to run a special Groove interface (the Transceiver) and pick out tools offered by it. Third parties who wanted to take advantage of Groove's benefits had to write tools that would be incorporated into the Transceiver.
Soon there will be another option: users will start up a third-party application that supports Groove-style collaboration by making the appropriate calls to Groove SOAP interfaces. The folks at Groove Networks like to call this the "powered by Groove" model, and look forward to making the use of Groove workspaces as simple as "saving to a G drive" (that is, the workspace will be available like any other storage on the system).
Another significant benefit to the Web services interface is that it lets customers design CGI forms or other interfaces of their own into Groove. And Groove can then be enjoyed by users who don't run the Groove client on their own systems, whether because they can't install the software, or don't run Windows, or have other constraints. A Groove Development Kit (GDK) for Web Services, scheduled to appear by the end of this year, could broaden the product's appeal to developers who want to beef up their applications with collaboration capabilities, as well as developers intimidated by the previous Groove development environment.
So Groove taught me a lot about the future of the application. But what really punctuated my equilibrium was a demo copy of Tenix. It doesn't contain Groove's incredibly sophisticated synchronization, and therefore doesn't let users do things simultaneously, like edit a file together. But the degree of integration of Tenix into Office and the desktop is eye-opening.
You can pull down a menu in most Office products and save a document to a Tenix workspace, where it's available to all of your colleagues wherever they are in the world, or send it in peer-to-peer fashion to a single colleague. In an upcoming version of Tenix (to be released in the first quarter of 2003), you will be able to right-click on anything on your Explorer desktop and save it to a workspace.
At this point, I find it hard to say whether I am running Word with an embedded Tenix service or running Tenix with an embedded Word service. We begin to sense the dissolution of the standalone application.
According to Dan Gagnier, director of business development for Tenix, you may be more likely to encounter a Tenix salesperson than a Groove salesperson if you live in Canada, the U.K., or Europe. Tenix's use is growing among legal, banking, and accounting firms in those countries and Tenix has won a strong foothold through a deal with the Canadian Bar Association.
Tenix developers are very conscious of standards, in order to maximize portability. Ryan Duffield, director of application development, estimated that the software is "90 percent ported" to the Macintosh already, because they follow standards. They use SOAP for as much communication as they can, along with AES and triple DES encryption.
Once an Office application is integrated with Groove or Tenix, the same component breakdown of the Office model that allowed integration actually allows the application to fade into the background. Theoretically, a SOAP request could be sent to Excel and it will return results, without a user ever feeling he or she has run Excel. And that observation leads to possibilities for the next stage in services and applications.
A recent article by Larry Lange claims as "Myth No. 1" that "Web Services Is A Revolution." Well, nobody could love cynicism more than me (because to love something to such an extent would disqualify one from being a cynic), but I'm just about convinced that Web services do represent a revolution.
Perhaps not Web services as they are properly called, using HTTP and port 80 and SOAP. Perhaps not the commercial utopia of seamless online shopping through heavyweight infrastructure elements such as UDDI or ebXML. But something component-based and widely distributed, related to what I've seen in the collaboration environments I just described. They can use CORBA for all I care. That's, in fact, the technology behind Bonobo, the component foundation of the GNOME desktop.
As said by Jack Ozzie, brother of Ray Ozzie and vice president of developer services at Groove Networks, "Web services was imagined for back-end computers processing car orders. But when you bring it to the desktop, it really opens up possibilities."
The reason I see the innovations of Groove and Tenix as qualitatively different from the simple Google service mentioned near the beginning of this article is that Google merely embeds one distinct application in another, whereas Groove and Tenix embed entirely new ways of working with the computer and the network.
Where are we heading? Every aspect of an application becomes componentized and offers its own protocol. The user is left with an astonishingly thin user interface layer accessing all of these servers. Servers are nested within other servers.
The application -- mainstay of the computer field for some 50 years, preceding the operating system, the network, the programming language, the command line, and just about every other aspect of computing -- almost disappears. What is left is a framework that handles the contacts between the user interface, the local operating system, and the network.
The profound degree of integration that third-party collaboration products have achieved with Microsoft Office shows the power of components and Web services. Without sharing source code, different companies have created an interface so seamless that you couldn't tell it's made of separate products.
This should be a wake-up call to free software developers, because easy integration has always been a trump card in the Free Software Movement. I am one of many people, for instance, who spends their whole day within the Emacs editor, running a dozen different programs within its framework and enjoying its powerful interface for cursor movement and text manipulation with each application. Well, Groove and Tenix show that proprietary application developers can play the same game. In fact, the flexibility provided by Microsoft in its libraries and component interfaces is cited by two Harvard Business School professors as its chief competitive advantage.
But I don't have the patience here to get hung up on a debate between free and proprietary software. A deeper lesson comes from watching the evolution of the cursor movement and the text-editing capabilities I mentioned as the great strength of Emacs. People liked this interface so much that it got integrated in the bash shell (the primary user interface to all programs) and then, through the Readline library, into countless other free software programs.
Superficially, the Readline example looks simply like developers imitating a popular look and feel and taking advantage of code reuse. But I see something more significant: the interface elements people like most about Emacs have become abstract from the Emacs application and have taken on a life of their own.
It's not hard to envision a totally different relationship, at this point, between a user interface and an application. The application reduces to DLLs, components, and SOAP interfaces. The user interface is something the user can tack on.
The importance of components is illustrated by its choice as the cover feature in a recent issue (October 2002) of the Communications of the ACM. The stories focus on using components to build large back-end support systems, a worthy topic for this engineering journal. But it's unfortunate that nothing is said about the possible impact of the components on user interfaces, even though the other major set of articles in that issue concerns user interfaces.
(Do not confuse the user interfaces I talk about here with the interfaces to components, which are a completely different matter and have a very limited purpose. Component interfaces define the methods called, the parameters passed, and a few other aspects like object properties and perhaps pre- or post-conditions.)
The popularity of PDAs and cell phones, along with attempts to develop easy-to-use voice and audio interfaces, strain our current state of the art in user interfaces. Perhaps improvements on the back end -- Web services -- can free us to find creative solutions on the surface.
Point and click looked very appealing in an earlier age, back in the '80s or so. As applications and users alike became more sophisticated, point-and-click options burgeoned into information overload.
The invention of cascading menus came in the nick of time, rescuing us from an unmanageably huge number of application options. But after a few years, even cascading menus were not enough to hold back the flood, and we were saved again by the invention of tabbed dialog boxes. In each case, users learned to accept new user interface elements in order to be able to manage mega-applications.
And even so, one could argue that option overload still afflicts us. Darn it, here's a Web page that requires Java to work. Do I enable it through the Security tab of the Settings item of the Properties submenu of the File menu, or through the Applications tab of the Security item of the Options submenu of the Tools menu?
Browsers (whose user interface model is already ten years old -- the approximate age of the NCSA Mosaic browser) have very neat navigational functions for Web pages. But a few Back, Forward, and Print buttons are probably not enough for the richer, more flexible applications to come.
So we may be ready for another revolution in user interfaces on the same order as the GUI. But perhaps instead of dazzling, richer interfaces, we could go in the direction of minimal user interfaces that expand and contract to match the service being offered, customized to the user's preferences.
The latter direction seems to be the natural direction components and Web services are heading. A vague Microsoft announcement about a project code-named XDocs suggests a new approach to generating interfaces linked directly to some kinds of XML schemas.
If the new computing environment de-emphasizes full-scale applications and elevates the interchange of data among services, user interfaces have to change radically. Essentially, we should make it as easy as possible for users to request and redirect data flows, and to hook up components. This is a very different idea of "user interface" from the one we've inherited from the early '80s.
Current user interface designers have accomplished some impressive translations of complex computer concepts into visual terms every user can grasp. Take, for instance, the concept of "a variable that can take on one of a limited set of specified values." That concept is represented in the C language as an enum. In user interfaces, it is elegantly represented by drop-down lists and radio buttons. As another example, the simple checkbox is a visual representation of the programming concept known as a Boolean.
We need similar visual metaphors, easy to grasp quickly and manipulate in rich combinations, for such concepts as piping output to another program, setting up filters, and launching programs upon the reception of particular events.
Perhaps a future version of Windows will contain a My Interface feature, which lets you set keystrokes, functions, and other aspects of your interaction with services.
Spending is down and venture capital is tight for the moment, but innovation in computing is not dead. We are being buffeted by paradigm-shifting possibilities in the forms of new devices, new protocols (often running on top of the highest layer in the OSI model, just as SOAP runs over the HTTP layer), and new demands by users. I believe we will see not only major changes in applications, user interfaces, and servers, but a basic reconceptualization of what is an application, a user interfaces, or a server.
Andy Oram is an editor for O'Reilly Media, specializing in Linux and free software books, and a member of Computer Professionals for Social Responsibility. His web site is www.praxagora.com/andyo.
Return to Policy DevCenter
Copyright © 2009 O'Reilly Media, Inc.