Applications, User Interfaces, and Servers in the Soupby Andy Oram
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.
Experiences with Current Web Services
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.
Pages: 1, 2