Starting around the 1960s, mainframe applications, whose users gained access through punch cards and lsater terminals (or terminal emulations), formed the first stage of software applications. The "green screen" terminals (the monochrome monitors of most terminals and early PCs) provided a text-based user interface for interacting with the server-side application. Obviously a text-based user interface doesn't allow for rich interactivity such as drag and drop or instant feedback while the user types. Furthermore, terminal applications can't provide the best responsiveness, as the user input always has to be processed on the server before the user can get feedback.

From a cost effectiveness perspective, mainframe applications are often criticized for spiraling maintenance costs that are the result of a vicious circle of lack of documentation and the inability to upgrade. Applications had to be developed for the specific operating system that the application needed to be deployed on, possibly resulting in an even larger code base depending on the number of supported operating systems.

As the personal computer became more popular, people began to have computing power on or under their desks. With this revolution came the change from a command-line UI to a more desktop-like UI, resulting from the WIMP (windows, icons, menus, and pointer device) model invented at Xerox PARC in the 1970s. Although the early adoptions by Apple and later Microsoft were poor, they allowed developers to create applications featuring richer interaction with the user. The graphical power of desktop machines helped applications become more user friendly by providing better visual feedback. However, these applications still required centralized data storage and processing, therefore needing to interact with a central server, hence the term client/server.

In terms of cost effectiveness, things didn't improve much, for in addition to the server side of the software, a client side also had to be developed. And as the requirements for the client side usually dictated support for more than just one OS, development and maintenance costs grew even worse. Another cost-increasing factor was that because the software didn't run in one central place but on numerous individual machines, a new version of the software required an update to all the machines that it was installed on.

At the same time that software applications were developed on or around a central server, the Internet and the Web were becoming more popular and more widespread. The Web was originally meant as a platform to allow people to share information by publishing documents and cross-referencing them using hyperlinks. As usage of the Web became more widespread, more and more people started having software on their computers that could interact with this document structure. The web browser provided common functionality, such as going back and forward through the navigation history and bookmarking certain pages for later retrieval. But the main advantage was that instead of software vendors needing to create specific versions of their applications for different operating systems, they had this huge installed base at their disposal. If only they could tap into that!

In order to understand the next steps in the evolution of the software application, we have to look in little more detail at the structure and inner workings of the Web. Web browsers render documents formatted using the Hypertext Markup Language (HTML) (http://www.w3.org/HTML). They find the document that the user wants using a uniform resource locator (URL) (http://www.w3.org/Adressing) and use a Hypertext Transfer Protocol (HTTP) (http://www.w3.org/Protocols) request to retrieve the document from a remote web server.

This is an important concept of the Web: all documents actually reside on one or more web servers, and the web browser (the client) retrieves the document from the server. It then reads the HTML document, applies the formatting rules defined in the file (as discussed later), and renders it on screen for the user to read.

The enormous popularity of the Web is largely due to the fact that it's unique; there's only one Web, wherever you go and whatever platform you use. Moreover, the Web is defined by a handful of vendor-neutral industry standards that are laid down and managed by bodies such as the World Wide Web Consortium (W3C) (http://www.w3.org) and the Internet Engineering Task Force (IETF) (http://www.ietf.org). That has prevented individual vendors, such as Microsoft, from taking over the Web by adding proprietary extensions. The Web only works because people agree on the standards that browsers can implement and that content providers and application developers can adhere to. Not only HTML, but other standards such as Cascading Style Sheets (CSS) (http://www.w3.org/Style/CSS), Document Object Model (DOM) (http://www.w3.org/DOM), Scalable Vector Graphics (SVG) (http://www.w3.org/Graphics/SVG), and Portable Network Graphics (PNG) (http://www.w3.org/Graphics/PNG) have contributed to the Web's success. Most of these standards will be discussed in the course of this book.

Instead of just using the Web to serve static HTML documents to users, someone came up with the idea of letting users request a dynamically generated document. That way, for instance, the user could take advantage of the (already installed) web browser to review real-time statistics or personalized content. This is where the web application was born. A web application is an application that resides on a central server and can be accessed by users through web browsers that they already have.

From a cost effectiveness perspective, this is a great way to develop software applications. You develop and deploy the applications once, and instead of having to install client applications on every user's machine, the clients already have all the necessary software preinstalled. Also, when you develop a new version of your application, you just replace the central version, and because clients interact with that central version, they will automatically receive the new version.

However, from a richness point of view, things went back to the mainframe days. Instead of having the rich user experience of the desktop application, allowing multiple means of interaction, responsiveness, and visual feedback, things went back to the issue-a-command-and-wait interaction model. Every action in a web application results in a call to the server to generate the next page or document. Therefore, as a client, you issue a command by clicking on a link or submitting a form, and then you might have to wait hundreds of milliseconds or even seconds for the entire page/document to return from the server. In the meantime, you have no way to interact with the application.

Even though there's an obvious setback in terms of usability, the greatly improved cost effectiveness has made web applications today's most popular type of software application.

Although web applications have become the de facto standard for developing software applications, they're mostly used to develop general-purpose, publicly available applications. Still, numerous applications that depend heavily on rich user interaction to accomplish certain day-to-day tasks are developed as client/server applications. The reason for this is obvious, as the Web and its document-centric approach don't allow for rich user interaction. Imagine a spreadsheet-like web application, where every time you enter or modify data in a cell, you have to wait for the entire page to reload with recalculated values. This is even worse when the communication between client and server goes over a public network, typically leading to higher latency between requests and responses. Having too much latency for direct feedback might lead to an unresponsive application, and is therefore not suited to performing a person's everyday job. Therefore these kinds of applications, up until recently, remained in the client/server domain, leveraging the capacities of a truly rich application, but still carrying the burden of being targeted at different environments.

This is where Ajax comes in to solve this issue by allowing developers to create user-friendly applications and still reap the benefits of being able to deploy applications on the Web.

In order to understand the main difference between Ajax's and the typical applications that were developed before Ajax, we have to look closer at how users interact with web applications. Figure 1-2 illustrates this for a typical web application. The user starts off by requesting a web page. The server processes the request and sends the result back to the browser, where it's subsequently rendered for the user. A typical web application then allows the user to do only a limited number of things. The user can provide input data by using form widgets (clicking on a link or button to submit the information), or by requesting a new page. The result of either action is that the user has to wait for the server to return a response. Meanwhile, the user can no longer use the application. This is called a synchronous interaction model. All user interaction halts until the server returns with a response, and only then can the user continue to use the application.

Figure 1-2. The interaction model of a typical web application

Although this model is acceptable for browsing through web pages (say, at a news site), it's unacceptable for more day-to-day applications, like our earlier spreadsheet example. In the case of a spreadsheet application, modifying a value and then having to wait for the server to return the recalculated outcome of a formula is unacceptable. First of all, you want to continue interacting with the spreadsheet while the result of the action is recalculated. But even more importantly, you also want to avoid having to receive and (re)render the entire page. This provides extra overhead because the server has to regenerate the entire page, the entire page is sent over the network, and the browser has to render the entire page again.

It would be so much better if we could update only the relevant cells in the spreadsheet. This is where the asynchronous model comes into play, taking away the gaps in the interaction and allowing the user to continue interacting with the application while previous actions are handled by the server. This model is shown in Figure 1-3.

The problem with the interaction shown in Figure 1-3 is that it breaks the classic Web model of HTTP requests for HTML pages, whose simplicity is one of its greatest strengths. The way to do this without losing more than we gain is by introducing an Ajax engine, a layer between the user interaction and the server communication. This engine runs inside the browser and delegates actions to the server while also handling the results. Because the engine dispatches calls to the server and pushes results to the user, the user can continue to interact with the application in the meantime. Because the engine adheres to the same standards, the Web model remains intact.

Figure 1-3. The interaction model of an Ajax application

To implement this asynchronous model, we need a way to send requests to the server asynchronously, without having to do a page refresh. As already mentioned, the Web was originally meant for linking documents together and navigating between them. Therefore, the Web and its standards don't directly support Ajax-style operations. However, developers are creative people, and if there's a way, it will be used to get the job done. It turned out that there was a way to do these asynchronous calls from the browser, only not in a browser-independent manner. Microsoft Internet Explorer ships with a built-in ActiveX control (XmlHttpRequest) that could be used to make an asynchronous call. Mozilla/Firefox contains its own similar mechanism, conveniently also called XmlHttpRequest, only implemented as a native object. Both mechanisms are similar in the way you use them. This allowed developers to apply this asynchronous model in applications that work in most browsers. This quickly made Ajax quite popular.

JavaScript is a scripting language created by Brendan Eich when he was working at Netscape. Originally it was named Mocha and later LiveScript, but renamed JavaScript around 1995. Although the name suggests otherwise, the language is quite different from the Java programming language, although they share a common ancestor in the C syntax. JavaScript was probably named after the Java language as a marketing move that was part of a strategic alliance between Sun Microsystems and Netscape. Some say they used Java in the name to give JavaScript the allure of being the new "hot" web programming language. It's mostly because of the support in Netscape that JavaScript became the most widely supported scripting language in browsers. Microsoft started off with its own dialect called JScript, but later switched to supporting JavaScript. In 1996, JavaScript was submitted for standardization, resulting in the ECMAScript specification with JavaScript as one of its implementations, others being ActionScript (heavily used by Adobe) and JScript, which is still used for Microsoft's Active Scripting.

JavaScript is a dynamic, weakly typed, prototype-based language with first-class functions. It supports the structured programming syntax of C, including loops, switch statements, and so on. One exception is that it doesn't support block-level scoping.

In order to get a better idea of JavaScript, let's look at Listing 1-1, which shows a simple HTML page that uses JavaScript to display an alert to the user with a value that the user has supplied in an input field.

<html>
    <head>
        <title>JavaScript sample</title>

        <script type="text/javascript">
           function handleButtonClick() {
                var input = document.getElementById('query'),
                alert('Query: ' + input.value);
            }
        </script>
    </head>
    <body>
        Query:
        <input id="query" type="text" value=""/>
        <button onclick="handleButtonClick()">Show</button>
    </body>
</htm>

The JavaScript fragment in Listing 1-1 looks much like Java, and it's easy to understand what the code is trying to achieve. However, you should also note the subtle differences, such as the variable and function declarations. Luckily, as you'll see in the remainder of this chapter, you don't need to know much more about JavaScript if you want to develop RIAs using GWT.

However, if you want more information about JavaScript, try the JavaScript 1.5 User's Guide (http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide), Beginning JavaScript with DOM Scripting and Ajax: From Novice to Professional by Christian Heilmann (Apress, 2006), and Pro JavaScript Techniques by John Resig (Apress, 2006).

Extensible Markup Language (XML) has become popular in the developer world as a means of transferring data in a language-neutral manner. Basically, a markup language is a language that employs tags to describe how its content is to be structured, laid out, or formatted. For instance, the sample XML fragment in Listing 1-2 describes the structure of a menu.

<?xml version="1.0" encoding="UTF-8"?>
<menu>
    <item id="1">
        <description>
           A menu item
        </description>
    </item>
    <item id="2">
        <description>
            Another menu item
        </description>
    </item>
</menu>

As you can see, the information in Listing 1-2 is structured in a hierarchical way. XML is a simplified form of the Standard Generalized Markup Language (SGML). Both SGML and XML are meta-markup languages, allowing you to define your own markup languages. One application of SGML is HTML, as depicted in Figure 1-4. Listing 1-3 shows some textual content marked up using HTML.

<div>

    <h1>New version of GWT released</h1>
    <p>
        Last night, word reached us that a new version of the hugely popular
        application development framework by Google<sup>TM</sup> is released.
        <br>
        More information:
        <a href="http://code.google.com/webtoolkit">
            http://code.google.com/webtoolkit
        </a>
    </p>
    <p>Sept. 21, 2008</p>
</div>

Basically, HTML provides a set of predefined tags that developers can use to add markup information to content. Note that in HTML, you can't use your own tags. So for instance, changing the h1 tag to name would result in the interpreter either failing or just ignoring it.

This is where XML comes in: it allows you to define your own tags. XML allows different ways to describe your document structure by means of schemas. Different schema languages exist for XML, including the Document Type Definition (DTD), which provides a limited set of functionality, and the more powerful XML Schema. But as these document descriptions are optional, you can easily do without them. So the content from Listing 1-3 could be expressed using XML as shown in Listing 1-4.

<newsitem>
    <name>New version of GWT released</name>
    <description>
        Last night, word reached us that a new version of the
        hugely popular application development framework by
        Google<sup>TM</sup> is released.
    </description>
    <link>http://code.google.com/webtoolkit</link>
    <date>Sept. 21, 2008</date></Para>
</newsitem>

If you compare Listings 1-4 and 1-3, you'll note that XML adds much more semantic value to the text. As its name spells out, XML is a markup language. But unlike HTML, which uses markup for a single well-defined purpose, XML is also a language for defining markup languages. It adds semantic value by describing the content within the tags. Still, one could write an interpreter that uses the semantic information described by the tags and use that to format the information to the user.

Although it may seem so, HTML is not an extension of XML. This is because in contrast to XML, HTML allows for single tags: opening tags with no closing tags, such as the <br> in Listing 1-3. This is allowed in SGML but not in XML; in XML, each opening tag should have a corresponding closing tag or it should be an empty tag: it should be either <br></br> or <br/>. In order for HTML to be more easily validated and accessible for more devices and platforms, Extensible Hypertext Markup Language (XHTML) recently has become popular. This combines the set of tags defined in HTML with the stricter syntax of XML, allowing for easier validation and interpretation. Figure 1-4 gives an overview of all the markup languages we've discussed so far.

Before we look at XML and more specifically how it's used in Ajax, let's digress for a moment. As mentioned earlier, the Web works because of standards. One of these standards is the Document Object Model (DOM): see http://www.w3.org/DOM/. This platform- and language-neutral interface allows programs and scripts to dynamically access and update the content, structure, and style of documents (for example, XML and HTML documents). The DOM represents a document as a hierarchical tree of nodes that can be accessed and manipulated. All browsers that support JavaScript use the DOM to represent and render HTML documents. This allows developers to use JavaScript to inspect and modify the document and therefore the UI. If you look back at Listing 1-1, you can see how we use the DOM to access the input field and retrieve its value. We used the JavaScript method getElementById(String) on the DOM representation of the HTML page.

Figure 1-4. SGML and a selection of its child languages

As mentioned earlier, XML allows data to be transferred in an interchangeable way. This is exactly what it's used for in Ajax applications. It allows you to transfer data from the client to the server and vice versa. This makes it easy for the client-side platform to be quite different from the server-side platform. So for instance, while the client side is written in JavaScript, the server side can be written in any possible programming language. Therefore, XML seemed like an ideal data transfer format when Ajax was created. However, as we'll see in the next section, that turned out to be incorrect.

So far we've discussed the major components that, in the past, made up the acronym AJAX. However, in 2006 Garrett redefined the AJAX as Ajax (a simple name, standing for nothing in particular).

Why did he make this change, and why is it important to discuss here? Let's first look at why he made the change. After several years of developing applications based on this new paradigm, two of the three components expanded beyond their original context. The first, asynchronous, remained in place, although it was more and more implemented without using the XmlHttpRequest object that had originally been one of the biggest catalysts behind the whole movement. But the other two, JavaScript and XML, were slowly being expanded. As we'll see in the next section, other approaches such as Flex use a language other than JavaScript to do their scripting in the browser environment. Flex for instance uses ActionScript for scripting (http://www.adobe.com/devnet/actionscript), but also has support for other scripting languages.

Therefore, the JavaScript part of the AJAX acronym was no longer valid. But even more obvious was the need for a change to the XML part of the acronym. XML turned out not to be the best choice for exchanging data between the client and the server. Obviously in some cases you could use XHTML to communicate the content and place it directly inside a page, but this is inconvenient when sending plain data. This is mostly because browsers tend to work differently with XML, both because APIs tend to differ, but even more importantly because the performance can be very different.

Therefore, after initially using XML, developers started to look for alternatives. Basically, they found three alternatives to XML:

Each solution has its advantages and disadvantages, but if we look at the majority of Ajax applications today, we must conclude that XML is no longer the most widely used data transport format.

So Garrett redefined Ajax as a name rather than an acronym. He defined Ajax as an application developed for the Web, using DHTML (see sidebar) and doing some kind of remote communication with the server in an asynchronous manner. That's the kind of application that you'll learn to develop in this book.

Next to the obvious, intrinsic benefits of building a rich Internet application, it also comes with the following additional benefits:

With every good thing, there are some drawbacks. The same goes for Ajax and building rich Internet applications. The following are some of the limitations:

Based on the benefits and shortcomings outlined in the previous section, we strongly believe that rich Internet applications aren't suitable for every application. But there are definite guidelines as to when to build a rich Internet application and when to stick to developing classical web applications as you've probably been doing for some time. Consider the following list:

We feel that if your application meets these prerequisites, a rich Internet application should be preferred. Assuming you have such an application (at least in mind), let's look at the different approaches that are available for developing these applications.

The first and probably most widely used way to develop Ajax applications is by taking a normal web application and adding Ajax capabilities to it by writing some JavaScript. You would usually use preexisting libraries that allow you to focus on the important stuff while reusing features such as remoting and convenience classes for manipulating the interface. In general, there are four main concerns with this approach:

This approach is workable when adding limited Ajax functionality to a traditional web application. But taking into account these concerns, we don't suggest using this approach to develop the rich Internet applications that we discussed earlier.

Adobe Flex is a set of tools for developing rich Internet applications on the proprietary Adobe Flash platform. Flash itself offers a lot more than you could get from HTML in terms of real-time interactivity. However, developing rich applications in Flash is daunting and unintuitive for core developers. The Flash development tool is geared for designers, and developing on a timeline is a strange concept for applications that aren't driven by time but by user actions. Flex removes that barrier to entry by providing a programmatic way for developing RIAs. Although the Flex platform was originally developed by Macromedia in 2004 as a commercial product, Adobe made parts of it open source in 2007 after its acquisition of Macromedia.

When developing rich Internet applications using Flex, you use the tools provided by Adobe. The good thing about this is that Flex comes with a lot of built-in functionality, such as widgets, drag and drop, vector graphics, and animations. This will greatly speed up your development, especially if you're already familiar with Flash and ActionScript.

The main advantage of using Flex is that you develop your application to run inside the controlled environment of the Flash plug-in. So you don't have to take browser quirks into account. On the other hand, the client must have the plug-in installed on the client computer, which might be not the case in some locked-down environments such as schools and government agencies. Some purists also feel that Flex isn't a real Ajax application framework, as it doesn't adhere to the standards normally used for building Ajax applications, such as XHTML and JavaScript.

In February 2008, Adobe released its Adobe AIR runtime, which allows applications developed in Flex to be deployed as local desktop applications while still enjoying the benefits of Ajax, such as seamless installation and updating. The main benefit of AIR is that it gives application developers the best of both worlds: you can use the deployment model of a web application while still getting desktop integration if you need it. More in-depth coverage of Flex, and a guide on how to get up to speed, can be found in The Essential Guide to Flex 3 by Charles E. Brown (Friends of ED, 2008).

Adobe Flex, especially since the release of Adobe AIR, is a good choice for developing rich Internet applications. Especially when you can't do without desktop integration features such as user notification, startup integration, background processes, and (most important) access to the local file system, Flex is a great option. However, remember that even though it's mostly open source, it still requires users to install a proprietary plug-in before using your applications developed in Flex.

More information about Flex can be found at http://www.adobe.com/products/flex and more about Adobe AIR can be found at http://www.adobe.com/products/air.

Another approach to building rich Internet application is using Java applets, or more recently, JavaFX. The most interesting part of JavaFX for our purposes is JavaFX Script, a scripting language for easily creating rich media and interactive content. However, it's built on the Java development platform, so if you want to deploy JavaFX applications on the Web, you're in essence deploying a Java applet, only one created with JavaFX. Therefore, we'll discuss Java applets in this section and just note that it also covers applications written in JavaFX.

The main benefit of a Java applet is that it's a Java program that runs on the client side. Although there are some obvious security restrictions when running from the browser, you can do anything you want with a Java applet, for example make connections to the originating server and spawn threads. You can even drop all security restrictions by digitally signing the application and asking the user for additional permissions, such as accessing the local file system. So if you want to build a rich Internet application, this appears to be the ideal solution. More in-depth information can be found in JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications by James L. Weaver (Apress, 2007).

The main problem with Java applets and JavaFX is the need for a Java Runtime Environment (JRE) to be installed on the client. The JRE has a lower installed base than for instance Flash Player. Another issue is that depending on the requirements and development time, you may need a different version of the JRE. Furthermore, in contrast to the Flash player, the JRE has a substantial download size of approximately 14Mb for offline installation on the Windows platform at the time of writing. Table 1-1 provides an overview of the market penetration and download size of some of the packages discussed in this section.

More information on Java applets and JavaFX can be found at http://java.sun.com/javafx.

Silverlight is Microsoft's recent attempt to provide a platform similar to Flash. It's restricted to a subset of the .NET framework and should therefore be more suitable for developing rich Internet applications. Although Silverlight is starting to get some attention, it has a long way to go before it can call itself a serious alternative to Flash. Currently the biggest hurdle for Silverlight is enlarging its installed base. At the time of this writing, Silverlight's market penetration is negligible. As it has taken Adobe many years to reach its current market share, it will probably be a long time before Silverlight can even begin to challenge it.

Another issue with developing rich Internet applications using Silverlight is that runtimes are currently available for the Windows platform only. For the foreseeable future, no Mac and Linux users will be able to use applications developed in Silverlight. Also, the download size of the Silverlight runtime is large compared to Flash.

For these reasons, we don't consider Silverlight to be a serious option for developing rich Internet applications at the time of this writing, at least not until it acquires a considerable installed base and Microsoft releases runtimes for Linux and Mac users.

More information on Silverlight can be found at http://www.silverlight.net.

Another product that we want to highlight is OpenLaszlo, released by Laszlo Systems under the Common Public License. OpenLaszlo takes the approach to define your UI in Laszlo's own LZX programming language. LZX is basically XML with embedded JavaScript snippets describing application logic. OpenLaszlo then takes the UI definitions and generates a rich Internet application. Previous versions only allowed the application to be translated into a fully functional Flash application. This runs into the same problems as the Flex approach. But starting with version 4 of OpenLaszlo, it now supports translating the UI into a DHTML application. The latest version also supports cross-compilation to embedded platforms such as mobile phones and other devices.

The main problem with OpenLaszlo is that it requires all application logic to be written in JavaScript. This leads to the same problems we discussed in the section about handwritten JavaScript. However, OpenLaszlo claims to eliminate a number of cross-browser compatibility issues, because the compiler is aware of them (see Figure 1-5).

Figure 1-5. OpenLaszlo application code compiled to different output formats

More information about OpenLaszlo can be found at http://www.openlaszlo.org.

The Echo Framework is yet another approach to developing rich Internet applications. The stable version at the time of writing is Echo2. Echo2 takes a nice approach to building these applications by allowing you to write them in Java. In Echo2, you write a servlet that handles all user requests and creates an application for each unique user. An application is created by extending the ApplicationInstance class. This application instance determines the UI of the application and handles user events. Because a new instance of the application is created for each user, it also holds all state. Internally, the application instance is stored in the user session.

The Echo framework takes a revolutionary approach to developing rich Internet applications. But in our opinion, there are two main problems with Echo2:

More information about Echo2 can be found at http://echo.nextapp.com/site/echo2.

As GWT is the subject of this book and is introduced in detail in the next chapter, we won't go into much detail here. But looking at GWT in contrast to the previously discussed solutions, there are two main things to note. First of all, GWT looks a lot like OpenLaszlo in the sense that the application you develop in GWT will eventually be compiled into a DHTML application and run entirely in the browser using XHTML and JavaScript.

But the main advantage of GWT over, for instance, OpenLaszlo is that instead of defining your UI in XML and JavaScript, applications are developed in Java. So for Java developers, this is a natural fit. You can reuse your existing expertise and best practices, favorite IDE, and development tools. The benefit of using GWT over other tools such as Echo2 is that GWT code compiles to a fully client-side JavaScript application and not just a proxy to the server-side Java application.

The most serious competitor GWT is Flex. But in our opinion, GWT has two advantages: first it's completely open source, whereas Flex is just partly open source; and second, a compiled GWT application runs inside any modern browser (assuming JavaScript is turned on) while Flex applications run only on systems where the Flash player is installed.