Ajax Patterns And Best Practices (2006)

C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

9

Figure 1-7. The various Starbucks in Montreal

The search results are presented by combining the addresses of the search results with a map. My search was “Starbucks Montreal,” and some Starbucks were found, which is good. However, also found was a Souvlaki Restaurant, and oddly, National Car and Truck Rental. What we are witnessing is an imperfect search due to imperfect data. In a perfect world, search strings are perfectly and concisely formulated on a perfectly organized database. However, with ever-growing databases that have ever-growing data, searches are not perfect because of time constraints, data organization, and scope.

A creative multidimensional Ajax application is the site http://www.housingmaps.com. Housingmaps is an appropriate example because it is an early example of a Web 2.0 application. The purpose of Housingmaps is to allow a user to search for housing rentals. The rentals are based on data from Craigslist, and the maps are provided by Google. If I search for an apartment rental in Montreal, the resulting output is illustrated in Figure 1-8.

10	C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

Figure 1-8. Apartment rentals in Montreal

The generated results are perfect. As most Montreal people know, when they ask for Montreal, they mean Montreal the island, and Figure 1-8 includes only the island. Additionally, by clicking on one of the found rentals, a balloon appears that gives more details on the rental and if possible some images. The user can easily click on each found location and quickly decide whether it is of interest to them.

Ajax Architecture Basics

You have a quick definition and some examples that illustrate the basic ideas behind an Ajax application. The next step is to illustrate an Ajax architecture. See Figure 1-9.

In Figure 1-9 there is a browser. The browser has two pieces of content: Content 1 and Content 2. Each piece of content is fetched from a different server. Content 2 is fetched from a server that also has two pieces of content, which are also retrieved from separate servers. From an architectural point of view, Ajax implements the Pipes and Filters pattern.3

3.John Vlissides et al., Pattern Languages of Program Design 2 (Boston, MA: Addison-Wesley Professional, 1996), p. 430.

C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

11

Figure 1-9. Ajax architecture

The data is fetched from the server by using a Representational State Transfer (REST)4 architecture style. The essence of REST is to create a simpler web services architecture by using HyperText Transfer Protocol (HTTP). REST is used solely for the transfer of data, and in particular is used extensively with Ajax applications. The overall idea is to generate content and to have that content filtered and processed. The filtered and processed content serves as an information basis, where another process acts as a client that filters and processes the information. The filtered and processed information acts as an information basis for another client. Content is fluid and constantly modified.

In Figure 1-9, the browser seems to be an end point where the data is not filtered or processed any further. However, that is very far from the truth. In an Ajax infrastructure, the data is always in a state of flux. A script can be used to retrieve HTML content that is saved to a file. Another script processes the saved HTML content that could serve as content for a web service. Putting it simply, when writing an Ajax application the data is never final and always in a state of flux.

It’s About the Data

At the time of this writing, many people were working furiously on getting toolkits ready to make it possible to write Ajax applications. In fact, it has been mentioned that Ajax was already invented long before it became popular.5 Although I agree that Ajax has been around a long time, the question is why is Ajax popular now? Mainly because Ajax involves the manipulation of data streams. We have an Internet economy and Ajax makes that economy work better.

Let’s focus on Google and Map.search.ch. What do both of these sites sell? They don’t sell software; they sell data! Map.search.ch sells information about Swiss addresses. Google sells information about basically everything on this planet. The strength of Google is not in the software that it sells or offers, but in the ability to manage and present the data.

4.http://en.wikipedia.org/wiki/REST

5.http://radio.weblogs.com/0001011/2005/06/28.html#a10498

12	C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

When you create your own Ajax application, think of the data that you are managing. Think of how that data can be sliced, diced, and made presentable to the end consumer. Getting the data in the right form is half of the battle. The other half is the presentation. Ajax applications operate from the client side and download data streams that can be manipulated or executed. Many will believe that this means people are ready to use the thin client and to always use applications from the network. However, Ajax does not mean the network is the computer. In fact, going back to the original Ajax fundamental concept, it means that a user uses Ajax and REST to get at the data they are interested in and will use that data locally. For example, say

I am going to buy a book. I search Amazon.com and Barnes & Noble.com. Because neither Amazon.com nor Barnes & Noble compare the prices, I need to download the search results and manipulate them locally. In other words, I need to manipulate the search results to get the information I want. What Ajax and REST promote is the people’s ability to slice and dice data in a format that is best suited to their requirements.

One last point about the data. Throughout this book, XML or HTML content that is XML compliant will be used. Many people might think that XML has its problems and have proposed protocols that are better. Frankly, I think that is plain wrong. The strength of XML is not its ability to encode data in a verbose format. The strength of XML is its ability to be understood by any platform, its ability to be parsed, sliced, and diced by a wide array of tools. To rebuild as sophisticated an infrastructure as XML is virtually impossible because it would be a gargantuan task. Therefore, when writing your own Ajax and REST applications, stick to XML. Having written on the strengths of XML, there are specific situations where other formats such as JavaScript Object Notation (JSON) would work well.

It’s About the Navigation

Ajax applications have the ability to quickly sift through large amounts of data in a very short period of time in a very reasonable fashion. Contrast this to previous times when people would hire experts, or buy expert magazines that already sifted through the data for the client. Now we have applications to do this automatically because applications have this expert knowledge built in.6 An example is the Amazon.com Diamond Search,7 shown in Figure 1-10.

Using the diamond search, a client can select from a series of parameters such as price, quality, and cut to find an appropriate diamond. Typically, comparing these details would have required surfing different sites and performing different queries. Amazon.com, on the other hand, created an easy-to-use program that uses graphical sliders to query and find the diamonds that are of interest.

It could be argued that the Amazon.com Diamond Search site could have been reproduced without the fancy graphics or any Ajax technology. Fair enough, that is true, but remember that Ajax is not only about technology. Ajax is also about the Internet economy, and the diamond search utility is an example of creating a dynamic, fun-to-use site. The more time people spend at the site, the more likely they are to buy. You could argue that the Amazon.com Diamond Search makes it unnecessary to seek the advice of a professional.

6.Amazon has introduced Mechanical Turk, which does specific tasks for users, at http://www.mturk. com/mturk/welcome

7.http://www.amazon.com/gp/search/finder/103-8737513-3625466?productGroupID=loose%5fdiamonds

C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

13

Figure 1-10. Amazon.com Diamond Search

To further illustrate the fundamental change of web applications, I will talk about my recent car buying experience. To choose a car, I used the power of the Internet and some specific information sources that rated and compared cars. I used Google to search the car makers for personal experiences and detailed information. Having whittled down my choices to three car makers, I decided to hit the road and visit some dealers. What happened shocked me. All the car dealers rebuffed me because they could not do their half-hour shtick on why I should buy from them. I peppered them with questions that surprised them. It was disappointing, and I was saddened. My wife said, “You know, for the car you like, is there another dealer?” In fact, there was, and it turned out to be the region’s biggest and central dealership. At this dealership, an older gentleman approached us and I again peppered him with questions. His answer was, “Ah, you did research. Which car do you want to take for a drive?” He did not go into a long spiel but let us control the process, and of course we bought the car.

The moral of the story is that the experts on the Internet might be familiar with only certain parameters, but because websites allow these parameters to be compared in an easy-to-use interface, users are more informed. Informed people expect those human experts that they are seeking to have knowledge that goes deeper than their basic parametric comparisons. In other words, car salespeople need to assume that they will have informed clients and therefore must provide some added value to interest a client in purchasing a vehicle.

It is more important when building an Ajax application to understand the data being presented and then to design the user interface fitted to the data. In traditional development, it is the other way around. The data is fit to the software because software designers are good at

14	C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

designing software but bad at designing user interfaces.8 I could be controversial and state that Ajax applications have stormed in because the applications are built by mature web designers who know more about user-interface design than software design. I do not mean to belittle the web designers; in fact I mean to illustrate that because of them we have these cool applications. If there is one downside to Ajax, it’s that you need to be a user-interface designer who is an expert in the domain being presented. Software development is moving from a horizontal approach (general-purpose software) to a vertical approach (domain-specific software).

Comparing Ajax to Other Application Types

There you have it, the description of the Ajax application. The remaining question is how an Ajax application compares to applications using other technologies and methodologies.

To fully understand the ramifications of Ajax, let’s put on our software architect’s hat and reengineer Map.search.ch in the context of other architectural models.

Rich-Client Local Installation

In the traditional software model, you download an application, install it, and then execute it. Converting Map.search.ch into a traditional piece of software would require writing a client. The client would have to be written in a platform-neutral language such as Sun Microsystems’ Java, or a Microsoft .NET language, or the open source Python (if I missed your programming language, for example Ruby, please do not consider it an insult. I just mentioned the languages that I regularly code in). If the client were written in a language such as C++, then it would need to be recompiled for each platform.

Choosing a programming language often is not the difficult part because languages exist on all platforms. The difficult part is how to code the graphical user interface (GUI). Often the problem is deciding whether to code using a GUI toolkit that takes advantage of the platform and therefore is specific to the platform—or to use a GUI toolkit that might not be as specific to the platform and might not be able to use all the tricks of the platform, but therefore is crossplatform. The decision the developer makes has significant ramifications.

A large percentage of applications are coded by using C++ and the Microsoft Windows GUI toolkit. This means that these GUI applications will most likely execute only on Microsoft Windows. Another choice for Map.search.ch could have been Java. Then the application could execute on multiple platforms, but the Java runtime would need to be installed on each of the platforms. Choose C++ and Windows, and you have one set of problems. Choose Java and multiple operating systems, and you have another set of problems. Sadly, there is no single best solution because each solution has its problems.

The last consideration is the data that is used to power the Map.search.ch application. The problem is that there would be a large amount of data. The only possible solution is to distribute the application with a single or multiple DVDs. The client would either install all the DVDs to the local hard disk or reference the DVDs from the computer’s DVD drive while doing the DVD shuffle. The DVD shuffle is when the program constantly asks you to switch DVDs for one piece of information, causing much frustration as you are constantly opening and closing the DVD drive.

8.Alan Cooper, About Face: The Essentials of User Interface Design (New York, NY: John Wiley & Sons, 1995), p. 21.

C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

15

This architecture has the following problems:

•Writing a multiplatform client has its challenges and requires extra resources in terms of time and money to be invested.

•The data has to be available locally, which can be a challenge for larger applications. Switzerland has more than 7 million inhabitants. Imagine the size of the data for a country such as the United States, which has nearly 300 million inhabitants.

•There are associated production costs that are not negligible; DVDs have to be mastered, boxes printed, and materials assembled.

•Updating the DVD data is a tedious process that requires an online connection or the purchase of another DVD data set. There is always a time lag between assembling the data and letting the consumer use the data.

•Updates of the client software require a new distribution of the software. Clients without an Internet connection cannot have their software updated dynamically.

•To use the software on multiple machines on a local area network, the software has to be installed on the multiple machines. It is not straightforward to share the data or to have the software automatically installed on multiple machines.

•Integration between Map.search.ch and the public transportation system is not possible unless Map.search.ch integrates the logic.

Overall, the rich-client local installation is not suited for the type of application that Ajax solves. The rich-client local installation application has too many issues regarding logistics and overhead. Granted, some of the issues are solved with money, which is earned by selling the software, but the application is still time lagged.

In general, the rich-client local installation application is threatened by the Ajax solution because you could create a local edition of an Ajax application by installing the HTTP server locally. The local edition would still have the problems associated with distributing the DVD data. But the big advantage is that the locally installed Ajax application can be installed on a local area network and accessed by multiple clients without having the client installed on multiple computers.

Rich-Client Web Services

The rich-client web services application is similar to the rich-client local installation application, except the data is not distributed via DVDs. A rich-client web services application uses web services, which are Internet-based method calls using XML as the protocol. In the formal specification sense, web services are based on Simple Object Access Protocol (SOAP). Like the rich-client local installation, the rich client has to be installed locally on each machine. The data that the rich client accesses is somewhere else on the Internet.

16	C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

This architecture has the following problems:

•As outlined in the Rich Client Local Installation scenario, writing a multiplatform client has its challenges and requires extra resources in terms of time and money to be invested.

•The client can be downloaded from a central site, but the client still needs to be installed locally for each machine. This makes updating the software more complicated.

•Web services that are implemented by using SOAP can either be simple or very complicated, depending on the requirements.

•Rogue third parties may end up using your data without your explicit permission.

•Integration between Map.search.ch and the public transportation system is not possible unless Map.search.ch integrates the logic.

A web service has become a commonly used rubber stamp for making Internet-based method calls using XML. In many cases, web services are associated with SOAP. There is no specific problem with SOAP, or with Web Services Description Language (WSDL), except that the “simple” is being taken out of the technology. Web services using SOAP have a large number of other specifications associated with them, and those specifications are useful for enterprise- to-enterprise communications.

Plain-Vanilla Web Application

The plain-vanilla web application is what I would call a lowest common denominator solution. The difference between Ajax and the plain-vanilla web application is the amount of dynamics and interaction. Both use a web browser, but there is less interaction and fewer dynamics with a plain-vanilla web application. Generally speaking, a plain-vanilla web application is controlled using server-side interactions. The client is there only to display the data that is generated by the server, and provides links or simple GUI elements to determine what the next step should be.

This architecture has the following problems:

•Interaction between the browser and consumer is simple and limited.

•The consumer is presented with an inferior user interface when compared with a rich client.

•The application requires recoding by the programmer to make the data fit the limited browser implementation. Some interactions result in hacks, which cause the consumer to be confused when they press the Back button, or reload, and so on.

The plain-vanilla web application model has suited us for a long time. It works and is successful. It is the application development model that created the Internet that we have and use today. The problem with the plain-vanilla web application model is that it is showing its age. Ajax is an evolution of this model.

C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

17

Some Final Thoughts

Now that you know what Ajax is all about, at least at the higher architectural level, and how it compares to other architectures, here is a summation of principles:

•An Ajax application can be a traditional application such as a word processor. What is unique about an Ajax application is that it combines multiple data streams into a unique view that is natural from the perspective of the user. In the case of Map.search.ch, this unique view is the display of mapped data in combination with aerial photos to explain to the user where things are.

•Ajax applications solve a problem in a specific context. When going beyond that context, the Internet is exploited in that other websites are referenced transparently, without the client having to figure out what the other website could be. The example from Map.search.ch was the shifting of the http://map.search.ch website to the Swiss train http://www.sbb.ch website. Clients will notice the change of website, but they will not notice where one “application” starts and another “application” ends.

•Ajax applications are written to solve an immediate problem and do not attempt to generalize. You would generalize when writing horizontal software applications. Ajax applications, in contrast, are vertical in nature. For example, Google develops their own software for their own consumption. In contrast, companies such as Microsoft for the most part sell software that could be used by a Google-like company to provide Googlelike services. Even if the software being written is horizontal in nature, the solution is vertical. For example, if I were to write an Ajax word processor, the idea behind the word processor would not be to sell licenses of the word processor, but to sell services associated with the word processor. These services could include document conversion, typesetting, editing, and other value-added services.

•There is no single state to an Ajax application. Whenever a state is captured in the form of an HTML page or file, then it is a snapshot. There is no guarantee that performing the same actions will result in the same snapshot. This makes testing more complicated because it means you need to test logic and not results.

•Ajax applications are not about the application, but the data. For example, when you install an application on a local computer, you care about the application, because most applications store the data in a proprietary format. If the application is lost, then so is your data. Over time, converters have been written so that losing an application is not as critical. With the advent of Ajax applications, what is critical is the data. In most cases, the data will be stored in formats that can be manipulated by other applications. Therefore, when writing Ajax applications, you are concerned with managing and providing an interface to the data.

•Ajax applications are generally “idiot proof” and do not require lengthy user manuals or explanations. This relates back to the scope of the Ajax application in that what you see is what you get. There are no hidden or extra features to confuse the user.

•Ajax applications are dynamic and exhibit behavior that is similar to a traditional client application that is executed from the local computer.

18	C H A P T E R 1 ■ I N T R O D U C T I O N T O A J A X

Everything is not rosy when writing Ajax applications, and the following problems can arise:

•The consumer is entirely dependent on the Internet. You can create an Ajax application that runs from a local server, but most likely that server will reference another server.

•A question of ownership with respect to the presented content arises because many Ajax applications combine streams from other websites. This referencing could be hostile or desired.

•The user must get used to the Internet way of doing things, which is not always identical to the traditional rich client’s way.

The next chapter describes the essentials of an Ajax application. Before you learn about Ajax patterns, you need to learn more about the basics of Ajax.