Software Engineering for Internet Applications - Student Community

such as ticket bookings would collapse if they had to support thesesearches as well.If separate physical CPUs are to be employed in the abstractionlayer, should they all come in the same box or will it work just as wellto rack and stack cheap 1-CPU machines? That rather depends onwhere state is kept. Remember that HTTP is a stateless protocol.Somewhere the server needs to remember things such as"Registered User 137 wants to see pages in the French language","Unregistered user who started Session 6781205 has placed thehardcover edition of The Cichlid Fishes in his or her shopping cart."In a multi-process multi-computer server farm it is impossible toguarantee that a particular user will always be returned to the samerunning computer program, if for no other reason than you want theuser experience to be robust to failure of an individual physicalcomputer. If session state is being kept anywhere other than in acookie or the persistence layer (RDBMS), your application serverprograms will need to communicate with each other constantly tomake sure that their ad hoc database is coherent. In that case itmight make sense to get an expensive multi-CPU machine to supportthe application server. However, if all the layers are stateless exceptfor the persistence layer, the application server layer can be handledby multiple cheap 1-CPU machines. At orbitz.com, for example, racksof cheap computers are loaded with identical local copies of the fareand schedule database. Each time a user clicks to see the options fortraveling from New York to London, one of those application servermachines is randomly selected for action.11.1.3 Presentation LayerComputer programs in the presentation layer pull information fromthe persistence layer (RDBMS) and merge those results with atemplate appropriate to the user's preferences and client software. Ina Web application these computer programs are doing an SQL queryand merging the results with an HTML template for delivery to theuser's Web browser. Such a program is so simple that it is oftenreferred to as a "script". You can think of the presentation layer as"where the scripts execute".The most common place for script execution is within the operatingsystem process occupied by the Web server. In other words thescript language interpreter is built into the Web server. Examples ofthis architecture are Microsoft Internet Information Server (IIS) andActive Server Pages, AOLserver and its built-in Tcl interpreter,Apache and the mod_perl add-in. If you've chosen to use one ofthese popular styles of Web development you've chosen to merge206contributions" page that will show all contributions from a particularuser. Wherever a person's name appears within the application it willbe a hyperlink to this user contributions page.Given that all site content is stored in relational database tables, themost obvious way to start writing the user contributions page script isby looking at the SQL data models for each individual module. Thenwe can write a program that queries a few dozen tables to find allcontributions by a particular user.A drawback to this approach is that we now have code that maybreak if we change a module's data model yet this code is not withinthat module's subdirectory and this code is probably being authoredby a programmer other than the one maintaining the individualmodule.Let's consider a different application: email alerts. Suppose that yourcommunity offers a discussion forum and a classified ad system,coded as separate modules. A user wishes to get a daily summary ofactivity in both areas. Each module could offer a completely separatealerts mechanism. However, this would mean that the user would gettwo email messages every night when a single combined email wasdesired. If we build a combined email alert system, however, we havethe same problem as with the user history page: shared code thatdepends on the data models of individual modules.Finally let's look at the site administrator's job. The site administratoris probably a busy volunteer. He or she does not want to waste 20mouse clicks to see today's new content. The site administrator oughtto be able to view recently contributed content from all modules on asingle page. Does that mean we will yet again have a script thatdepends on every table definition from every module?Here's a hint at a solution. On the photo.net site each module definesa "new stuff" procedure, which takes the following arguments:• since_when -- the date of the earliest content we'reinterested in• only_from_new_users_p -- a boolean indicating whetheror not we want to limit the report to contributions from newusers (useful for site administration because new users arethe ones who don't understand community standards andnorms)143