AJAX In Action [84]
In the lifecycle of an Ajax application, the server has two roles to fulfill, and these are fairly distinct. First, it has to deliver the application to the browser. So far, we’ve assumed that the initial delivery of content is fairly static, that is, we write the application itself as a series of .html, .css, and .js files that even a very basic web server would be able to deliver. Nothing is wrong with this approach—in fact, a lot can be said for it—but it isn’t the only option available to us. We’ll look at the alternatives later, when we discuss server-side frameworks in section 5.3. The second role of the server is to talk to the client, fielding queries and supplying data on request. Because HTTP is the only transport mechanism available to us, we’re limited to the client starting off any conversation. The server can only respond. In chapter 4, we discussed the need for an Ajax application to maintain a domain model on both the client (for fast responses) and the server (for access to resources such as the database). Keeping the models in sync with one another Licensed to jonathan zheng Coding the server side 161 represents a major challenge, and one that the client can’t solve on its own. We’ll look at ways of writing data to the server in section 5.5 and present a solution to this problem based on one of the patterns that we encountered in chapter 3. We can deliver the client application—and talk to the client—in several ways, as you will see in this chapter. Is one way better than the others? Do any particular combinations support each other? Can they be mixed and matched? How do the different solutions work with legacy server frameworks and architectures? To answer these questions, a vocabulary for describing our various options will be useful. And that’s exactly what we’re going to develop in this chapter. First, let’s look at the way the server is set up in a web application, and how Ajax affects that. 5.2 Coding the server side In a conventional web application, the server side tends to be a rather complex place, controlling and monitoring the user’s workflow through the application and maintaining conversational state. The application is designed for a particular language, and set of conventions, that will determine what it can and can’t do. Languages may in themselves be tied to specific architectures, operating systems, or hardware. Picking a programming environment is a big choice to make, so let’s discuss the options available to us. 5.2.1 Popular implementation languages Server-side programming is dominated by a handful of languages. Over the very brief course of Internet history, fashions in server-side languages have changed remarkably. The current kings of the hill are PHP, Java, and classic ASP, with ASP.NET and Ruby growing in popularity too. These names are undoubtedly familiar to most readers, so I won’t try to explain what they are here. Ajax is primarily a client-side technology and can interoperate with any of these languages. Indeed, some ways of working with Ajax downplay the importance of the serverside language considerably, making it easy to port Ajax applications from one server platform to another. Web frameworks are in many ways more important to Ajax than the implementation language. Web frameworks carry assumptions with them, about how the application is structured and where key responsibilities lie. Most frameworks have been designed for building classic web applications, and assumptions about the lifecycles of these—which are very different from those of an Ajax app—may be problematic in places. We’ll look at server-side designs and frameworks in the Licensed to jonathan zheng 162 CHAPTER 5 The role of the server following section, but first, let’s review the basic principles of web-based architectures, in order to lay the groundwork for that discussion. 5.2.2 N-tier