Web 2.0 and New Approaches to Software

Web 2.0 is about more than the technology and coding.

• By Peter Varhol
• 09/01/2006

It has become passé to speak of a "next generation" anything in software. But there is a clear lineage between the current trends in Web application development, often called Web 2.0, and the origins of Web-based information. At the same time, the technologies behind Web 2.0 herald an entirely new vision of Web applications that are sophisticated, highly responsive, interactive, scalable, personalized, and even participatory.

The technologies are largely well-established, even if development tools employing them remain nascent. How can a set of relatively unsophisticated scripting languages along with standard client and server technologies provide us with an entirely new class of applications?

Because it is not just about the technology.

Web 2.0 is primarily a misnomer; this might easily be considered the third generation of the Web. The first, in the sunrise of the Web, was simply static pages with little or no user interaction beyond page navigation. While a novelty at first, it was a newness that quickly wore off, as Web pages were little better than books or pamphlets.

The next generation could possibly be considered the first of the Web application. Using technologies such as CGI, ASP, and JSP, you wrote applications that took user input and dynamically created unique Web pages based on that input. A few lines of HTML formatted the page and placed static items (and even that could be done dynamically), and everything else was generated on the fly. Personalization was born.

You were familiar with the disadvantages of this generation of Web applications. Because every action went back to the server (and executed some code or queried a database), Web applications were almost always slower than a rich client counterpart. And browser-rendered controls were less visually attractive and lacked features that were taken for granted on other applications.

At the same time, however, you enjoyed the advantages of Web applications. Much of the infrastructure already existed, so coding them tended to be easier and faster. The client side was the browser, which made things much easier for you as developers. There was no need to develop client-side code beyond a few lines of HTML, which was often done by graphic designers anyway. And there was little need to worry about supporting multiple clients. Once again, any variation among the browsers was ignored when possible or handled by the HTML writers when not.

Life was pretty good for you and your fellow Web developers. It was not so good for the users of your applications.

In the meantime, more Web application development tools came into being. Perhaps the most significant of these tools was the XMLHttpRequest object. This API, created by Microsoft in Internet Explorer 5, provides for a way to send XML data (as well as other formats such as JSON or plain text) to and from a browser using HTTP, in effect establishing an independent connection between client and server. This API can be used by JavaScript or other scripting language to make requests and provide a flow of data without having to reload the page itself.

This was one of the keys that made Ajax a useful technology. While it is not a standard object in the sense that it has not been defined in a public specification, it has been broadly implemented across browsers, and its use has become common.

Single-vendor approaches have also gained popularity, with perhaps the best known being Adobe's Flex platform. Even though Flex is a single-vendor solution, and requires a plug-in on the browser, it has gained a surprising amount of interest and use. This attests to the growing popularity of approaches that improve the user experience of browser-based applications.

Ajax and related technologies do just that. But there is more to Web 2.0 than just fast interaction using Ajax technologies.

The Principles
How do you create a Web 2.0 application that qualifies as Web 2.0? There are few hard and fast rules. Not having a certain characteristic is not necessarily disqualifying, and having all of the characteristics doesn't automatically qualify your application. But in general, there are a few definitive ways that a Web 2.0 application should work.

You can look at Web 2.0 from the standpoint of community, business, and technology. This means that Web 2.0 is as much of a cultural innovation as a technical one. In fact, it is difficult to separate the technology from softer characteristics. You can build an application that uses the requisite technologies, but without the community and business aspects integrated into the application concept, you don't have a Web 2.0 application.

One characteristic of designing for community is greater levels of interaction. Ajax enables a good portion of that interaction, by speeding up responses and making the application flow smoother. And there are an increasing number of controls that enable Ajax activity within the user interface. But fast data transfer between client and server doesn't automatically qualify an application as a Web 2.0 one.

From a design standpoint, the Representational State Transfer (REST) design pattern predominates. REST provides for a style that emphasizes simplicity and scalability through a consistent approach to using resources in an application.

Interaction also means that users can contribute in ways where they might not have had the opportunity in the past. Some of the most interesting applications let users share their experiences and contribute worthwhile information so that it is available to the community. For example, the dealer for your new car may not know how to fix a particularly subtle problem, but you can bet there is an owner somewhere in the world who has encountered it before you, and has found a solution. By encouraging the sharing of user information through technology and application design, everyone benefits.

Interaction can be so valuable that it becomes more personalized, and enables the user to participate in the application rather than simply use it. This user need is being addressed by mash-ups. A mash-up, the combination of data and interfaces from two or more applications, provides a unique view into a problem that is not available through any single application. There are few commercial mash-ups, because they tend to be produced for small niche needs, but the major Web application providers, such as Google and Microsoft, provide platforms for building such applications.

From the business standpoint, Web 2.0 applications have the potential to better serve existing constituents, as well as the opportunity to acquire new users and customers. One of the best-known of the business paradigms is that of the "long tail," in which an online business, with a virtual shop and often-unlimited electronic inventory, can afford to serve smaller segments and even individual needs without additional expense. Amazon, for example, has a virtual inventory of millions of titles, whereas a brick-and-mortar bookstore can only stock a few thousand.

In many cases, this long tail approach turns out to be quite lucrative. There remains some question as to just how much business is done in some circumstances, but it remains an intriguing business model and one that is readily accessible through Web 2.0 applications.

The Architecture Pattern
As mentioned above, commonly associated with the Web 2.0 trend is the REST design pattern. REST, described by Roy Fielding in his 2000 doctoral dissertation, offers several principles for architecting Web-based distributed systems. These principles are intended to provide guidelines for good application design and development, but tend to be pretty radical for those who have significant experience building traditional Web application.

In REST applications, functionality and state are defined as resources. That means that you have effectively abstracted both into a location, rather than a more specific definition. Further, these resources are addressable through a single mechanism, usually the Universal Resource Identifier (URI).

There is a single interface for transferring state between resources, which consists of operations and content types. The operations on these resources are small in number and well-defined. They frequently use the common HTTP operations of GET, POST, PUT, and DELETE.

Last, REST relies on a stateless protocol. Any state retained by the server must be modeled as a resource. The message plus any such retained state is enough for the resource to perform its task unambiguously.

The simplicity and consistency of that result from applying these architecture patterns have the potential to improve application performance and make them more scalable. Despite the abstraction of functions and state into resources, REST applications tend to have better execution characteristics than many other designs.

Web 2.0 doesn't require REST designs, and REST can be used on non-Rich Internet Applications. But the REST principles offer the advantages of scalability and simplicity for applications that usually require manual coding efforts. And REST often fits in with the design strategies of such applications in general, such as the abstraction of resources in URI Web locations.

The Application Types
Clearly the most common technology associated with Web 2.0 is Ajax. There are a growing number of Ajax applications available on the Internet, starting with Google Maps. More custom enterprise applications using Ajax are appearing, thanks to a growing collection of commercial user controls employing the technology.

Other Google applications, such as Gmail and Calendar, use these techniques to provide a combination of speedy interaction with users and the convenience of Internet-based data storage. While they are not new or groundbreaking applications, they provide a taste of what is possible with Ajax technologies.

In retrospect, Web businesses such as Amazon, EBay, and Google also provide the business basis for the next generation of Web applications. They effectively use the principles of user interaction and participation, while offering platforms for custom development and extension of their core businesses. In Google's case, the concept of search has been reinvigorated and is undergoing substantial innovation at just the time when users need better and more flexible search facilities.

Last, Microsoft's Windows Live Local shows how traditional business applications might morph onto the Web. Windows Live (currently in beta) includes online implementations of search, Office, Messenger, and other business and personal applications. Microsoft's Virtual Earth, which is entirely Web-based and doesn't require a browser plug-in, provides an online API for writing mapping applications and mash-ups.

Getting There
If you're interested in writing Web 2.0 applications, you should start with the technology. Ajax development tools and controls are emerging onto the market, making development easier and faster than it has been using manual methods. Also start practicing the REST pattern in application design; it will pay off on all of your applications, not just the Web 2.0 ones.

As implied earlier, you have to integrate technology with community and business innovations in order to have a valid Web 2.0 application concept. Without the community and business innovation, you might have a useful application, but you almost certainly lack an application that dramatically changes your business.

That is the key to Web 2.0. Not the technology, which is by itself not particularly innovative. The innovation is how that technology is applied to problems in business and society. In other words, it is not enough to write a Web application that uses Ajax, REST design, and scripting languages; it is about using these technologies in pursuit of innovation.

Web 2.0 applications require participation from beyond developers, to both users and management. The best ideas might come from the users, or from business line professionals who are close to the customers' point of view. It is unlikely that any valid Web 2.0 application can be classified by the standard software product categories you use today.

If you can describe your application using the language of today's applications, you have missed the point. To paraphrase former Supreme Court Justice Potter Stewart, who wrote that he couldn't describe pornography but knew it when he saw it, it may not be possible to fully describe Web 2.0, but you will know it when you see it.

About the Author
Peter Varhol is Editor-in-Chief of FTPOnline.