Software Engineering for Internet Applications - Student Community

The Small HammerThe simplest way to separate the programmers from the designers isto create two files for each URL. File 1 contains SQL statements andsome procedural code that fills local variables or a data structure withinformation from the RDBMS. The last statement in File 1 is a call toa procedure that will fetch File 2, a template file that looks likestandard HTML with simple references to data prepared in File 1.Suppose that File 1 is named index.pl and is a Perl script. Byconvention, File 2 will be named index.template. In preparing atemplate a designer needs to know (a) the names of the variablesbeing set in index.pl, (b) that one references a variable from thetemplate with a dollar sign, e.g., $standard_navbar, and (c) that tosend an actual dollar sign or at-sign character to the user it should beescaped with a backslash. The merging of the template and localvariables established in index.pl can be accomplished with asingle call to Perl's built-in eval procedure, which performs standardPerl string interpolation, i.e., replacing $foo with the value of thevariable foo.The Medium HammerIf the SQL/procedural script and the HTML template are in separatefiles in the same directory there is always a risk that a carelessdesigner will delete, rename, or modify a computer program. It maymake more sense to establish a separate directory and give thedesigners permission only on that parallel tree. For example onphoto.net you might have the page scripts in /web/photonet/www/and templates underneath /web/photonet/templates/. A scriptat /ecommerce/checkout.tcl finishes by calling the sharedprocedure return_template. This procedure first invokes the Webserver API to find out what URI is being served. A configurationparameter specifies the start of the templates tree. return_templateuses the URL plus the template tree root to probe in the file systemfor a template to evaluate. If found, the template, in AOLserver ADPformat (same syntax as Microsoft ASP), is evaluated in the context ofreturn_template's caller, which means that local variables set in thescript will be available to the ADP file.The "medium hammer" approach keeps programmers and designerscompletely separated from a file system permissioning point of view.It also has the advantage that the shared procedure called at the endof every script can do some poking around. Is this a user who preferstext-only pages? If so, is there a text-only template available? Is thisrouter for IPv6. SSL encryption for HTTP connections can be donewith plug-in boards, an example of which is the Compaq AXL300,PCI card, available in 2003 for $750 with a claimed performance ofhandling 330 SSL connections per second. Finally it is possible tointerpose a hardware encryption machine between the Web server,which communicates via ordinary HTTP, and the client, which makesrequests via HTTPS. This feature is, for example, option on loadbalancing routers from F5 Networks (www.f5.com).11.2 Do you have enough CPUs?After reading the preceding sections, you've gone out and gottensome computer hardware. How do you know whether or not it will beadequate to support the expected volume of requests? A good rule ofthumb is that you can't handle more than 10 requests for dynamicpages per second per CPU. A "dynamic" page is one that involvesthe execution of any computer program on the server side other thansimple HTTP service, i.e., anything other than sending a JPEG orHTML file. That's non-encrypted or assuming the presence ofhardware encryption in front of the HTTP server. For example, if youhave a 4-CPU RDBMS server handling persistence and abstractionand 4 1-CPU front-end machines handling presentation and HTTPservice you shouldn't expect to deliver more than 80 dynamic pagesper second.You might ask what CPU speed is this 10 hits per second per CPUnumber based upon? The number is independent of CPU speed! Inthe mid-1990s we had 200 MHz CPUs. Web scripts queried thedatabase and merged the results with strings embedded in the script.Everything ran on one physical computer so there was no overheadfrom copying data around. Only the final credit card processingpages were encrypted. We struggled to handle 10 hits per second. Inthe late 1990s we had 400 MHz CPUs. Web scripts queried thedatabase and merged the results with templates that had to beparsed. Data were networked from the RDBMS server to the Webserver before heading to the user. We secured more pages inresponse to privacy concerns. We struggled to handle 10 hits persecond. In 2000 we had 1 GHz CPUs. Web scripts queried thereferer header to find out if the request came from a customer of oneof our co-brand partners. The script then selected the appropriatetemplate. We'd freighted down the server with Java Server Pagesand Enterprise Java Beans. We struggled to handle 10 hits persecond. In 2002 we had 2 GHz CPUs. The programmers haddecided to follow the XML/XSLT fashion. We struggled to handle 10hits per second....140209