Survey of Technologies for Web Application Development

Surv ey of T ec hnologies for W eb Application Dev elopmen t BARRY DOY LE University of California, Irvine and CRISTINA VIDEIRA LOPES University of California, Irvine W eb-based application dev elop er s face a dizzying array of platforms, l anguages, frameworks and tec hnical artifacts to c ho ose from. W e survey , classif y , and compare tec hnologies supp orting W eb application dev elopment . The classiﬁcation i s based on (1) foundational tec hnologies; (2) int egration with ot her information sources; and (3) dynamic conten t generation. W e further survey and classify softw are engineering technique s and to ols that ha v e been adopted from traditional programming into W eb programming. W e conclude tha t, although the infr astructure problems of the W eb hav e largely b een solved, the cacophon y of technolog ies for W eb-based applications reﬂects the lack of a solid mo del tailored for this domain. Categories and Sub ject Descriptors: A.1 [ General Litera ture ]: Introductory and Survey; D.1.0 [ Program ming T ec hniques ]: Ge neral; D.1. 1 [ Pro grammi ng T echniques ]: Ob j ect-orien ted Programming; D.2.11 [ Sof tw are Engineeri ng ]: Softw are Architectures— langua ges ; p att erns ; H.3.5 [ Informati on Stora ge and Retriev al ]: Online Inform ation Systems— data sharing ; Web- b ase d servic es ; H. 5.4 [ Hyper text/Hyp ermedia ]: Architec tures General T erms: Design, Pr ogramming, Languages Additional Key W ords and Phrases: W eb applications, W eb programmi ng, scripting languages 1. THE DE MAND F OR DYNAMIC CONTEN T Within a decade o f its inception, the W eb evolv ed from a static hypertext pre- sentation medium in to a sta ndard use r interface technology for a growing class o f int era ctive informatio n systems. The initial W eb implementation, deﬁned by its static natur e and a pur po sefully low barrier to entry , was suﬃcient for sharing do c- umen ts but ina dequate fo r more adv anced applications. The early W eb, despite its static limita tio ns, demonstra ted clearly enough the overwhelming p otential a nd global reach of the new medium, setting in motio n a rush of explor ation into how to bring so cia l, educationa l, and commercial a pplications online. Popular interest and media hype related to cyb ersp ac e , a science ﬁc tio n turned plausible by the a r riv al of the Internet, raised exp ectations for the W eb far b eyond its hum ble orig ins to thos e of a universal hub of online informatio n services [Bell 19 97]. Up-to- date informatio n Author’s addresses: B. J. Doyle, Donald Bren School of Information and Computer Sciences, Unive rs i t y of Calif ornia, Irvine, Irvine, CA 92697; email: bdoyle@ics.uci.edu; C. V. Lop es, Donald Bren School of Inform ation and Computer Sciences, University of Calif ornia, Irvine, Irvine, CA 92697; email: lop es@ics.uci.edu. 2 · Bar ry J. Doy le an d Cristina Videira Lop es and eﬀective user interfaces, ess e nt ial r equirements for online ser vice applications , could not b e pr actically implemented with only s tatic conten t. Metho ds for provid- ing dynamic conten t o n- the-ﬂy in resp onse to user requests were develop ed to meet the dema nds of W eb service a pplications. Conceptually , dynamic co nten t extended the early W eb by providing an indirection level that allows users to reques t server r esour c es , prog rams that generate documents, as well as do cuments [Berners- L ee et al. 1 998]. Po wered by dynamic conten t g eneration sy stems, online commer c e , ed- ucation, and communication servic e s b ecame widespread, and the c hara cter o f the W eb bec ame increasing ly applicatio n-centric rather than do cument-cen tric. At the same time client-side interactivity was extended far beyond its origina l constraints, which limited in tera ction to o nly simple page-base d navigation through hyper text links. 1.1 The Sta tic W eb The W orld Wide W eb, co mmonly referred to as simply the W eb, was develop ed in 1990 at the E urop ean Orga niza tion for Nuclear Research (CERN) as a hypertext system for sharing do cumentation b etw een disparate computers and applica tions ov er the Internet [Berners- L ee 1 989; Berners- L ee e t al. 1994; Berners- L e e a nd Fischetti 2000 ]. The simple and op en desig n of the W eb attracted attention outside of CE RN, initially ma inly within the netw ork r esearch commun ity . Accepta nc e of the W eb acce le rated after CERN releas ed its implementation into the public domain in April 199 3, which a llow ed or ganizations to exp eriment with the W eb without concern for future licensing en tangle men ts. NCSA Mos a ic 1.0 , the ﬁrst W eb bro wser with a g raphical use r interface (GUI), was r eleased by the Nationa l Center for Sup ercomputer Applications (NCSA) at the Univ er s ity of Illino is at Urbana-Cha mpaign in September 199 3. The NCSA Mosa ic browser was simple to insta ll and use on the X Windows, Micro soft Windows, and Macintosh platfor ms. The GUI br owser was an immediate p opular success that was a catalyst for a r us h o f business in terests and the public to embrace the In ternet. The s uc c ess of NCSA Mosaic and the W eb led to demands for dynamic conten t, improv ed interfaces, a nd connectivity to external systems. The age of purely static W eb w as eﬀectiv ely o ver when NCSA intro duced the Common Gatewa y Interface (CGI) in la te 1993 as a featur e of the NCSA h ttp d 1 .0 W eb server. CGI allows a browser clien t to reques t data from a progra m r unning on a W eb ser ver rather than from a static do cument. Other inno v ations suc h as browser ﬁll-in forms and Server Side Includes (SSI) were additional early metho ds for making the W eb mo r e int era ctive a nd dynamic. Building o n the early foundations provided by CERN and NCSA, the histor y of W eb prog ramming can b e view ed as a contin uing quest for improv ements in eﬃciency , eas e of use and reliability for interactive dynamic conten t ge ner ation. 1.2 W eb T echnol ogy Design Pressures The W eb architecture has evolv ed into an eﬀectiv e infrastructur e for a wide class of co mplex, interactiv e ser vices. Several factors shap ed the mostly ad-ho c evolu- tion of the W eb. T able I summarizes the thr ee ma jor factors and so me of their pressures on the evolution of the W eb. This table provides a set of criteria that is used througho ut the pap er for a ssessing and comparing dynamic W eb conten t Survey of T echn ologies fo r Web Application Development · 3 F actor Ob j ectiv es Global distribution Reliability Extensibility Scalability Pe rf ormance Po rtabili t y ov er heterogene ity Loose coupling Securit y In teractivit y Dynamic page generation Data v alidation Handling of browser navigation anomalies State managemen t Ev ent-act ion Human and socio- economic f actors Agile dev elopment Designer/programmer integ ration Learning eﬀort Po pularity Conformance to standards and practices T able I. W eb tec hnology design factors. developmen t technologies. Glob al Distribution. The W eb is a distributed system that lo osely co uples clients with g eogra phically-disp ers e d servers through message -passing ov er the Internet. The HTTP proto col is a sp eciﬁc implementation o f the genera l distributed sy s tems client-serv er communications mo del. W eb applications are implemented within a distributed a pplication layer ab ov e HTTP , and are therefore b ound to the require- men ts of distr ibuted systems. Pr op erties and design p oints for distr ibuted op era t- ing systems that ar e impo rtant for the W eb a re r eliability , extensibility , scalability , per formance, heterog e neit y , a nd se c urity [Sinha 199 7]. Inter activity. W orking around the us er in terface int era ctivity limitations of the W eb architecture is a central theme of W eb pro gramming. Constraints of the HTTP proto co l, which imp ose a s ta teless, s trictly pull- only architecture o n W eb applications, mandate pag e-centered in tera ctivity , limiting client pro cessing to page rendering, for m data collection, and na vig ation to subsequent pages. Any interac- tion betw een a client a nd a ser ver re s ults in a complete page to be downloaded in resp o nse, even if the new page diﬀer s only s lig htly from the previous version. The level of in teractivity is similar to the ar chaic blo ck-mode in terfaces that con- nect dumb ter minals to mainframe computers. The need to address the limitations of HTTP , which are justiﬁable for scalability and simplicit y r e asons, has provided m uch of the imp etus for the developmen t o f technologies that hav e made the W eb progre s sively more reliable, interactiv e, and dynamic. Human F actors. Additional re q uirements for W eb dev elopment tec hnolog ies ar e related to human fa ctors that reﬂec t the cultural and so cial environment in which the applications are created. 1.3 Objective The transition to the mo der n dynamic W eb a nd b eyond has ge nerally be e n neither organize d nor o r derly , ra ther it was acco mplished thro ugh indep endent innov a tion 4 · Bar ry J. Doy le an d Cristina Videira Lop es by many individuals and groups; sometimes collab o r atively , s o metimes comp eti- tively , and often in isolation. W eb developers are pragmatic when ev aluating new techn olo gies: those that work well within the co nstraints of the applica tions are accepted; others ar e ignored or b ecome obsolete, no t explic itly retired, but instea d gradually falling out of us e. As a re s ult, the W eb developmen t landscap e is clut- tered with a v ariety o f tec hnologie s and to ols, and littered with obsolete or fa iled options that can trap newcomers. The ob jectiv e of this pap er is to derive o rder from the ch ao s b y descr ibing the foundations o f the W eb and clas s ifying the related technologies and progr amming techn iques that a re used to create dyna mic W eb applica tions. Although server-side dynamic conten t g e neration is an essential part of almo st a ll W eb a pplications, it is to o enmeshed with other concerns to b e a dequately explor ed in isolation. Therefore, the remaining sections of this pap er descr ib e the relev ant technologies and tech niques sepa rately and as they evolv ed in relation to each another. In Section 2, the W eb’s ar chitecture is rev ie wed, since it is the foundation for the techn olo gies that supp or t dyna mic conten t. The pr ogress ion of developmen ts that made the W eb increasingly dynamic and r e liable is reviewed to survey imp or tant technologies and the context in which they were created. Section 3 surveys technologies speciﬁca lly created for la rge enterprise so ft ware s ystems. A summary and cla ssiﬁcation of the techn olo gies is presented in section 4 , providing a roa dmap for technology sele c tio n. Section 5 explo r es s o ft ware engine e ring metho ds and too ls that have been carried forward fro m traditional pro gramming into the realm o f the W eb, and a ssesses their ﬁtness and level of maturity for developing W eb applica tions. Finally , section 6 draws the co nclusions of o ur study . 2. SUPPORT F OR DYNAMIC CONTE NT T ec hnolo gies are best understo o d in light of the context that motiv ated their cre- ation. The evolution of the W eb has b een primarily motiv ated by a sear ch for abstractions that impr ov e its usability for end users, through richer user int erfa c e s, and for developers with mor e p ow erful pr ogramming metho ds. This section r e- counts the r oad to dynamic conten t as a sequential narr ative, star ting with a brief review of the architectural foundations o f the W eb and design points for W eb ap- plications. The remaining sub-sections describ e the pr ogres s ion o f developmen ts that shap ed the dynamic W eb, from the simple initial gatewa y methods that en- abled dynamism, to the recent frameworks that aim to simplify developmen t while improving reliability and functionality . 2.1 An Architecture fo r Distributed Hyp ermedia Applicatio ns The architectural foundatio n of the W eb is the request- r esp onse cycle realized b y the Hyp ertext T rans fer Pr o to col (HTTP) [Fie lding et al. 19 9 9] a nd Hype r text Markup Langua g e (HTML and XHTML) [Raggett 1999 ; Altheim and McCar- ron 2 001] standards . The Representational State T ransfer (REST) architectural style provides a mo del architecture for the W eb that was used to ra tionalize the deﬁnition of the HTTP 1.1 r ecommendation [Fielding and T aylor 2002]. Mo du- larity , extensibility , a nd inv ersion of control are characteristics inhere n t in the W eb that have a llowed incorp or ation of featur es suppor ting dynamic conten t. Inv ersion of co nt ro l is implemented on b oth clients and se r vers b y v arious plug-in, conten t Survey of T echn ologies fo r Web Application Development · 5 WEB SERVER O p e r a t i n g S ys t e m A b st r a ct i o n L a ye r R e ce p t i o n R e q u e st A n a l yz e r A cce ss C o n t r o l R e so u r ce H a n d l e r T r a n sa ct i o n L o g Operating System BROWSER Client Machine Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response Fig. 1. A reference arc hitecture for W eb servers adapted f rom the architectu re of Hassan and Holt [2000]. handling, and ﬁltering int er fa ces that allow custom comp onents to b e inv oked in resp onse to even ts. The following sections review the op er ations of W eb ser vers and browsers highlig ht ing the extension po int s that are leveraged to provide interactiv e and dy namic conten t for W eb applications . 2.1.1 W eb Servers. W eb servers implement the server-side duties o f HTTP , the application-layer proto co l that governs mes sage-pa ssing betw een W eb client s and servers. Figure 1 is ada pted from a refer e nc e architecture for W eb s ervers provided by H ass an and Holt [2000]. The mo st common W eb server implemen tations are the Apac he HTTP server [Apache Softw are F oundation 2004], a v ailable for mo st op erating systems, a nd the Internet Information Service (I IS) [Micr osoft Corp o- ration 2005 b], av aila ble o nly for Micro soft Windows op erating systems. Request and resp onse mes s ages share a common format that includes a start line, messa ge headers, and optiona lly , a messa g e bo dy and message traile r s. Request mes sages sp ecify a r equest metho d, most co mmonly GE T or PO ST , and a Universal Resource Ident iﬁer (URI) for a requested resource. Res o urces are a key abstraction for the W eb, unifor mly identifying do cuments, serv ices, colle c tio ns of other r esources , a nd other types of information sources using a single naming scheme. Resp onse mes- sages include a status line and a repres e nt ation of a resour ce. The proto col supp orts transmission of any conten t t yp e that can b e r epresented as a sequence of bytes with asso ciated metadata. Resp onse s ar e interpreted by client br owsers. 2.1.2 W eb Br owsers. W eb browsers pro cess us er interface co mmands, forma t and send request messages to W eb servers, w ait for and interpret s e rver re s po nse messages, and re nder conten t within the browser’s display window area. Fig ur e 2 is a simpliﬁed architecture diagram that illustrates the opera tions of W eb browsers. HTML and XHTML [Altheim and McCarro n 2 001] are the mos t common conten t t yp es on the W eb. Br owser extensibility fea tures allow many other conten t types to be display ed by deferring their rendering to re g istered plug-in comp onents (helper applications) that handle the conten t. The p erv asiveness of HTML makes it a friendly target for dy namic conten t g eneration systems. 6 · Bar ry J. Doy le an d Cristina Videira Lop es WEB BROWSER Operating System Operating System Abstraction Layer Network Interface Request Formatter User Interface Response Analyzer Response Renderer Client Machine WEB SERVER Server Machine R e q u e s t A n a l y z e r A c c e s s Co n tr o l Request Response Fig. 2. An architecure that il lustrates the op erations of W eb browsers. 2.1.3 H TML. HTML do cuments c ontain text interspe r sed with formatting ele- men ts. Casc ading Style She ets (CSS) allow forma tting elements to b e separa ted into reusable st yle sheets [Bos et al. 20 04]. Uneven CSS implementations in browsers and ing rained pr actices resulted in a n extended accepta nce p erio d for style sheets. Promotio n o f W eb standards and improv ed browser implementations of the stan- dards hav e rec e nt ly res ulted in steadily increasing use of CSS to separ a te pres ent a- tion attributes from con tent [Zeldman 2 003]. Client -s ide s c r ipts can b e em b edded in HTML do cuments to add int era ctivity to W eb pages and further pr o cess a do cument b e fo re it is rendered by a browser. The Do cument Obje ct Mo del (DO M) [W3C 2004 a] interface allows embedded scr ipts to mo dify the str ucture, conten t, and presentation of do cuments. The co mb inatio n of HTML, client-side scripting, and DOM is infor mally known a s Dynamic HTML (DHTML) . The most p o pular client -s ide scripting la nguage is Jav aScr ipt. It is also po ssible to refer e nce Jav a applets, ActiveX cont ro ls, Macr o media Flash presenta- tions, and other kinds of precompiled progra ms within HTML do cuments, but the approach has compatibility , latency , and securit y iss ues that limit its eﬀectiveness [Bellovin e t al. 2000]. In spite o f these concerns, ActiveX and Macromedia Flash are still widely used by web designers to provide a more gr aphically-intensive user exp erience than w ould otherwise b e practically achiev able on the W eb. While the promising W3C Scala ble V ector Graphics (SVG) [W3 C 2 005a ] and Sync hronized Media Integration Language (SMIL) [W3C 2005b] standar ds provide XML-bas ed alternatives to Macro media Fla sh for mult imedia pr esentations, they are not yet per v asively used. 2.1.4 X ML. The Extensible Markup L anguage (XML) is a widely accepted markup language that simpliﬁes the transmission of structured data between applications [Y ergeau et al. 2 004]. XML is a meta-la ng uage for creating collectio ns o f custom elements, in contrast to HTML, which provides a ﬁxed set of elements. The Ext en- sible Styleshe et L anguage (XSL) family includes an XML-ba sed element matching language fo r XSL T ransfor mations (XSL T) that is used to pro grammatica lly tra ns- form XML do cument s into other for ma ts [Clark 1 999]. XML has b e en ex tremely succes sful standar d since the orig inal recommendation Survey of T echn ologies fo r Web Application Development · 7 was releas ed in December, 1997. XML provides the base syntax for the XHTML and CSS standar ds tha t normalize and will eventu ally replace HTML as the dominan t presentation technology for the W eb. Conﬁgurations for W eb a pplications a nd services ar e now commonly maintained within XML ﬁles. The extensive av ailability of XML pa rsers makes it more conv enient for progr ammers to work with XML ﬁles rather than develop pa r sers for pr o prietary ﬁle formats. W eb ser v ices standards including SOAP [W3C 2 004b] and XML-RPC [Winer 199 9] leverage XML for conﬁguratio n a nd as a r e quest and respo nse messag e fo r mat for remote pro cedure calls ov er HTTP . 2.2 Initial Dynamism The ear liest technical elements that allowed for interactiv e and dyna mic conten t were HTML for ms, the HTTP POST request metho d, and the Co mmon Gateway Int erfa c e (CGI). HTML forms are used to collect user input data that is submitted to a forms pr o cessor on a W eb ser ver in a GET or POST messa g e. By 1 993, the av ailability of CGI completed the for ms pro cess ing path by pr oviding a means by which W eb servers co uld pro ce ss and resp ond to submitted data . CGI is functional but not sca la ble; as its limitatio ns b ecame clear other so lutions were developed that were mo re eﬃcien t but more complicated. This se c tio n r eviews the ﬁrs t wa ve of technologies for the dynamic W eb including CGI, its server-side successo rs, a nd client-side extension interfaces. 2.2.1 F orms. The HTML for ms ca pability naturally e x tends the W eb’s do cu- men t metaphor by allowing user input to b e entered o n W eb pa ges. A form is a section of a do cument tha t contains named user interface controls suc h as text boxes, chec k b oxes, radio buttons, lis t b oxes, and buttons [Ragg e tt et al. 199 7]. The deﬁnition of a for m sp e c iﬁes a request metho d ( GET or POST ) and a URI for a server-side forms proce s sor. When a form is submitted, the browser for mats a re- quest messa ge containing the form data as a sequence of name-v alue pairs . F or G ET messages, the for m data set is app ended to the a ction URI a s query parameter s . When POST is used, the form data is sent in the message b o dy . The for ms capability o f HTML is r e lied on by many W eb applicatio ns . The for ms int erfa c e is simple, cro ss-platform, supp orts ligh t da ta v a lidation, and a llows pages to b e even t-driven. The e vent mo del of a form is implicit in the URI references asso ciated with submit buttons. The lo osely coupled interaction b etw een forms and their pro cessors can b e a source of reliability problems since there is no static gua r - antee that the data types o f submitted data elements confor m to the exp ectatio ns of form pro cessor . 2.2.2 CGI. CGI was the ﬁrst widely av aila ble means for integrating W eb ser vers with externa l systems, initially provided as a metho d to pro cess data s ubmitted from HTML forms [NCSA 1993]. CGI allows server-side progr ams to be inv oked in r esp onse to HTTP requests. A W eb ser ver cr eates a new pro cess for each CGI request. Figure 3 shows the ar chictecture of CGI. CGI pro grams can b e written in any pro gramming language that supp or ts environmen t v ar iables and the standard input and output streams. The ea rliest CGI progr ams w er e written in C, but the deploymen t eas e and p or tability of int er pr eted scripting languag es such as tcl, Perl, and Python has made them the lang uages of choice for CGI [Ous terhout 19 9 8]. Perl 8 · Bar ry J. Doy le an d Cristina Videira Lop es BROWSER Client Machine WEB SERVER Operating System Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response CGI Process CGI Interface Fig. 3. The CGI archite cture. #! /usr/lo cal/bin/perl # Display the form data set sen t i n a GET or POST request. print ”Conte nt-t ype: text/ht ml \ n \ n”; print ” < html >< head >< title > F orm Data < /title >< /head > \ n”; print ” < b o dy bgcolor= \ ”#FFFFFF \ ” \ n > ” if ($ENV { ’REQUEST METHOD’ } eq ’POST’) { read (STDIN, $buﬀer, $ENV { ’CONTENT LENGTH’ } ); @pairs = split(/&/, $buﬀer); } elsif ($ENV { ’REQUEST METHOD’ } eq ’ GET’) { @pairs = split(/&/, $ENV { ’QUER Y STRING’ } ); } else { print ” < p > $ENV { ’REQUEST METHOD’ } message r eceiv ed < /p > ”; } foreach $pair (@pairs) { ($name, $v alue) = spl it(/=/, $pair); $v al ue = ∼ tr/+/ /; $v al ue = ∼ s/%([a-f A-F0-9][a-f A-F0-9])/pac k(”C”, hex($1))/ eg; $name = ∼ tr/+/ /; $name = ∼ s/%([a-f A-F0-9][a-f A-F0-9])/pac k(”C”, hex($1))/eg; print ” < p > Field $name has the v alue $v alue < /p > \ n”; $F ORM { $name } = $v alue; } print ” < /b ody >< /html > \ n”; Fig. 4. An example of a Perl CGI script. is the most p opular language for CGI scr ipting. User input a nd metadata ab out requests is passed into CGI prog rams through environment v ariables a nd within the standard input stre am, r esp ectively . The output written by a CGI prog ram to its standard output stream is sent to the client within an HTTP resp onse message. The example Perl script in Figur e 4 reads an environmen t v ar iable to determine the reques t method ( GET or P OST ) and displa ys the data that was submitted fr om a form. CGI was the ﬁrs t widely supp orted technology for dynamic conten t and is still Survey of T echn ologies fo r Web Application Development · 9 suppo rted out-of-the-b ox by most W eb ser vers. In tandem with s cripting languages , CGI is a platform-indep endent s o lution with a simple, well-known int erfa c e. The disadv an tag e s ar e related to scalability and usability co ncerns. CGI is not highly scalable b ecause a new pro cess must b e created for each request. F or busy W eb sites serving thousa nds of concur rent users, the CP U a nd memory usa ge r equired to cons tantly create a nd destroy pro cess es se verely limits the num b er o f concurr ent requests that can be ha ndled. The use o f scripting languag es further stra ins a W eb server’s capac ity due to the need to start an in terpreter for each request. The usability problems o f CGI stem from the limitations o f its thin abstraction ov er the HTTP proto co l. Progr ammers m ust understand the workings of HTTP , down to the level of for ma tting details of reso urce identiﬁers and message s , to be able to cr eate CGI scripts. No page computatio n mo del is pr ovided; the pro- grammer is resp o nsible for gener a tion of the r e s p o nse by printing HTML to the standard output stre am. Ro le separa tio n b etw een designer s and progr ammers is diminished due to the fact that the pre sentation a ttributes of pages are embedded with print statements in progr ams. W eb page a uthoring to ols such as F rontP age or Dreamw eav er can no t b e used since the pres ent atio n HTML is embedded within a program’s logic. Other resp onsibilities including state manag ement, s ecurity , v a lidation, data ac- cess, and even t handling a re co mpletely deleg ated to progra mmers. A spate of fragile, idiosyncr atic W e b application implemen tations were the result of the lac k of structure allow ed by CGI. The in tro duction of softw are engineering disc ipline in the fo r m of co ding g uidelines, scripting libraries, and frameworks has improv ed the situation to some exten t [Stein 1998 ]. Despite its limitations, CGI is not obs olete. It natively exists within most W eb servers, in contrast to other dynamic co nten t so lutions tha t requir e additio na l com- po nent installation. The out-of-the-b ox, universal av a ilability of CGI makes it a po ssible ta rget for sma ll to medium-sized applica tions with low-volume exp ecta - tions. W u et al. [2000] found CGI to be ineﬃcient in handling concurrent clien t requests a nd therefore suita ble only for low-traﬃc applications ba s ed on benchmark compariso ns to other options for generating dynamic c onten t. The tec hnolo gy is still in use ma inly due to the increasing p opularity of scripting languag es, w hich can provide a straightforward, po rtable alter na tive to Jav a. 2.2.3 S c alable CGI Implementations. F astCGI (Open Market), mo d per l com- bined with the Apache::Registry module (Apache), and PerlEx (ActiveSt ate) a re examples of W eb server extensions tha t impr ov e the scala bilit y of CGI. F astCGI is a CGI implementation that maintains a p o ol of p ersistent pro c e sses that are reused for multiple requests to reduce pr o cess crea tion ov er hea d [Brown 1996]. Figure 3 shows the a r chitecture o f s calable CGI implementations. mo d per l is an Apache extension that embeds a Perl interpreter within the W eb server that allows Perl scripts to access the Apache C languag e API. Apache::Registry is a Perl libr ary that supp or ts CGI under mo d per l. The combination of mo d p er l and Apache::Registry improves p erformance by a voiding the ov erhea d o f star ting and stopping a Perl interpreter for eac h request. An Apac he W eb server can also be extended to supp ort co r resp onding capa bilities for other scripting la nguages including Python (mo d snake, mo d p ython), tcl (mo d tcl), and Ruby (mo d ruby 10 · Barry J. D oy le an d Cristina Videira Lop es BROWSER Client Machine WEB SERVER Operating System Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response CGI Process 1 CGI Interface … CGI Process 2 CGI Process 3 CGI Process N… CGI Process Pool Fig. 5. The scalable CGI architect ure. with eRuby). PerlEx provides s imilar ca pabilities for Micr osoft I IS b y ma int aining a p o o l of interpreters that is manag e d by a W eb server extensio n mo dule [ActiveS- tate 2003 ]. Gousios and Spinellis [2002] compared the perfor mance of F a stCGI, mo d p erl, PHP , a nd Jav a s ervlets under Apache on Linux using a minimal commo dity hard- ware conﬁg uration (a single Pen tium I I I 733 MHz pro cesso r with 384 MB of mem- ory). Their re s ults show ed that F astCGI was the b est p erfor ming and mos t r e - liable option on the b enchmark ha rdware. Jav a s ervlets also p erformed s tea dily , even though the author s co nceded that the b enchmark conditions were no t realistic for the technology , which is more appropria tely matc hed to enterprise-level hard- ware supporting multiple pro cess ors and larg e r amoun ts of memor y . Apte et al. [2003] compar e d the p erfor mance of a s imila r technology group (CGI, F astCGI, Jav a serv lets, and JSP ) on a dual-pro cesso r Solaris system (2 360 MHz Sun Ultra pro cesso r s with 512 MB of memory) with similar results that show ed F a stCGI to be the b est p er fo rmer. How ever, the authors also concluded that facto rs other than per formance, including developmen t time, suppo rt a v ailability , ease of in tegra tion, and deploymen t co nv enience, a re als o impo rtant concerns for W eb de velopment groups. 2.2.4 W eb Server Ex t ension In terfac es. The initial reac tio n from W eb ser ver providers to CGI p er formance issues was to cre ate proprietar y APIs with similar capabilities [Reilly 200 0]. All o f the ma jor W eb s e rvers hav e APIs that can b e used to introduce new functionalit y into a W eb server throug h extension mo dules. The most well-kno wn e x amples a re NSAPI, o r iginally created for Netsca p e W eb servers [Sun Micros ystems, Inc. 200 3 ]; Micro soft ISAPI [Microsoft Corp or a tion 200 5a]; and the Apa che mo dule API [Apa che Softw are F oundation 200 3]. Extensio n mo d- ules a re usually req uired to b e written in C or C++ and compiled into dyna mic link librar ie s that are link ed into the W e b server at r untim e. Extensions can run extremely fast s ince they are compiled co de that r uns in the W eb ser ver address space. ISAPI and the Apache interface are representative of W eb se rver APIs in g eneral. ISAPI suppo rts the developmen t of extensions a nd ﬁ lters that mo dify the b e havior Survey of T echn ologies for Web Application Development · 11 WEB SERVER Operating System BROWSER Client Machine Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response Extension Filter Fig. 6. The reference architec ture for W eb servers mo diﬁed to s ho w ﬁlters and extensions. of I IS. Figure 6 s hows the plac e men t of ﬁlters and ex tensions within the referenc e architecture. The corres po nding Apache API constr ucts a re mo dules , hand lers , and ﬁlters [Thau 1 996]. ISAPI extensio ns behave like CGI scripts; extens io ns are inv oked directly b y clients or through URI mapping, and are r esp onsible for handling requests and creating res po nses. On IIS servers, a well-known example is the mapping of .asp ﬁles to asp. dll , the Active Ser ver Pages interpreter. A corres p o nding example fo r Apache is the asso cia tion of .php ﬁles to the mo d php extension mo dule. ISAPI ﬁlters p erfor m additional b ehaviors in a ddition to the default b ehaviors, and ca n b e used to implemen t custom log g ing, authentication, mapping, and retriev al features. The Apa che API also supp orts ﬁlters as a mo dular wa y to manipulate reques t or resp ons e da ta streams. W eb server APIs were o riginally designed as scalable repla c e men ts for CGI, but they ar e r arely directly used to build W eb applications . The APIs ar e complex , non-p ortable, a nd require adv anced progr amming knowledge, so extens io n mo dules are diﬃcult to build, test, and maintain. Reliability can b e co mpromised due to the tight integration of extensions in to W eb servers; a single ﬂaw in an extension mo dule can crash a W eb ser ver. The cost of developing extens io ns is ea sier to justify for widely reusa ble fea tures than for those supp or ting only a s ingle applica tion. In spite o f their weaknesses, W eb ser ver APIs are an impo rtant building blo ck for dynamic conten t genera tion sy s tems. In fact, for pe rformance reaso ns mos t server- side technologies that suppo r t dynamic cont ent are ba sed on W eb server extensio n mo dules. 2.2.5 Br owser Extension Int erfac es. One of the ﬁr st browser extension inter- faces was the C o mmon Client In terfac e (CCI) for NCSA Mo saic [NCSA 199 5]. CCI w as a n API that a llow ed exter nal applica tions to comm unicate with r unning browser instances by requesting a URL to b e display ed. CCI is obso lete but inﬂu- enced the browser extension tec hnolo g ies that followed. During the browser wars of the mid-19 90s all of the ma jor browser providers created proprieta ry APIs to diﬀerentiate their pro ducts. T he Netscap e P lug-In API and Micros oft ActiveX ar e examples of browser-sp eciﬁc APIs. F or systems r equiring dynamic in terfaces , the key fea tures of browser-s pe c iﬁc AP I s ar e s uppo rt for plug - 12 · Barry J. D oy le an d Cristina Videira Lop es WEB BROWSER Operating System Operating System Abstraction Layer Network Interface Request Formatter User Interface Response Analyzer Response Renderer Client Machine WEB SERVER Server Machine R e q u e s t A n a l y z e r A c c e s s Co n tr o l Request Response Helper Function Fig. 7. Browsers ar e extended through plug-in and scripting inte rf aces that inﬂuence the rendering and handling of the user interface. in comp onents and access to internal browser metho ds a nd prop erties rela ted to the presentation of conten t. Security tha t preven ts downloaded compo nents from per forming undesira ble a c tio ns is a key req uirement for browser extensions. ActiveX makes use of “Authen tico de” , a c o de-signing schem e that veriﬁes that downloaded binary comp onents a re pristine as oﬀered b y a certiﬁed provider prior to their execution by a browser. Figur e 7 illustrates the place of extensions within the architecture of browsers. Applets. Jav a applets repre sent an extension appr oach that is not browser-sp eciﬁc since it leverages the p ortable Jav a b yte code format. Applets a re Jav a clas s ﬁles that ar e downloaded and interpreted by a Jav a Virtual Ma chine (JVM) r unning within the browser address space. The JVM executes applets o nly after v erifying that their co de is sa fe, meaning that it has not be e n tampe r ed with and contains no instructions that violate the client’s securit y po licy . Applets can also be digita lly signed and veriﬁed to provide a n a dditional level of secur ity . Jav a applets initially suﬀered from p o o r p er ceived p erformance due to extended download times and slow int erpr etation; therefore the technology has b een relegated to a secondar y role, e ven though p erfo r mance has since b een v astly impro ved b y the in tro duction of just in time (J IT) compilation to native co de. T he per v a sive Macromedia Flash animation play er plug-in provides an a lternative to Jav a a pplets that is no w commonly used to e mbed ma rketing presentations in W eb pages. Client-side Scripting. Interpreters for light weigh t scripting languag es such as Jav aScript a nd VBScr ipt were av a ilable for most browsers by the end of 19 96. Client -s ide scripting langua ges interfaces ar e more accessible than browser extension APIs, since they remov e the need to know an e ntire AP I to add pieces of useful functionality to an HTML do cument. Client-side scripts ar e slightly less eﬃcient than plug-ins, but the adv ant ag es of eas y acc e ss to browser pro p er ties a nd metho ds outw eigh the pe r formance pena lt y . Initially , each br owser cr eator implemented a proprietar y scripting languag e and API that was incompa tible by des ign with other browsers. Scripting languag e sta ndards, including ECMAScript and DOM, hav e improved the situation to the point that cro ss-browser scripting is p o ssible. Ric h In ternet Applications. The applet conce pt ha s recen tly b een reviv ed un- Survey of T echn ologies for Web Application Development · 13 der the guise of rich Int ernet applic ations (RIA) . The ob jective of the RIA concept is to break aw ay from the pag e-centered constr a ints impo s ed by the W eb to supp ort a more interactive user exp erience. RIA solutions that a ttempt to intro duce a new plug-in architecture o n to the W eb (Ko nfabulator, Curl, and Sash W eblications, to name a few) have attracted attention, but even tually lo se momentum due to the requirement to download and insta ll a plug-in. Laszlo and Mac romedia Flex ar e RIA environments that are attempting to exploit the large installed base of Flash users to pr ovide improved interactivity without requiring plug-in installa tion. Las- zlo a pplications are describ ed using an XML application descr iption lang uage. The Laszlo Presentation Server is a J av a se r vlet that dynamically comp o ses a nd se r ves Flash interfaces in respo nse to requests for Laszlo applica tions. RIA solutions can improv e the resp onsiveness and presentation quality of W eb user interfaces, but hav e no t rea ched the mainstrea m of developmen t. More ex p er ience with the tec h- nologies is needed to assess their compa tibilit y with the existing W eb infrastructure befo re widespread adoption of RIA will o c c ur . Expanded Use of Dynamic HTML. Gar rett [2005] coined the term Ajax for using the combination of XHTML, CSS, DOM, XML, XSL T, Jav aScript, and XML- HttpRequest, a Jav aScr ipt API for accessing W eb serv ices, to deliver RIA co m- pletely within the existing W eb infra structure. The pro duction application of Ajax within several po pular, hig h- volume web sites including Gmail, Go o gle Sugg est, Go ogle Ma ps, and the Amazon.com A9 sear ch e ngine provides evidence that the combination can b e eﬀective and sc alable. The disa dv antages of Ajax lie in browser compatibility iss ues and the no n-straightforward Jav aScript co ding that can b e re- quired to implemen t simple functionality . 2.3 Interp reted T empla te-Based Scriptin g The use of templates is a common characteristic o f pattern-based pro g ram con- struction systems. A template is a mo del for a set of do cument s, co mpo sed of ﬁxed and v ar iable parts, that is con textually expanded to yield conforming docu- men t instances. The v a r iable parts o f a template enca psulate progr a mming logic such that ea ch v ariable pa r t exp os es a prog ram function tha t s pe c iﬁes how it is expanded in co ntext. P redominately-ﬁxe d templates ar e ea sier to construct and comprehend tha n more v ariable templates since less pro gramming is r equired and the deﬁned structure is la r gely static. Many W eb s ites consist of genera lly ﬁxed HTML pages with s mall amounts of v ariable co nt ent. In contrast to template pro cessing, CGI pr o cessing is mor e suitable for applications with mos tly v ariable conten t, which a re not a s common on the W eb. The template mo del b etter supp o rts the co mmon W eb a pplication pa ttern by embedding lo gic w ithin ﬁxed presentation markup. T emplates re duce the pr ogra mming skill needed to create dynamic con- ten t. Ro le separatio n is well-supp orted since the addition of lo gic can b e deleg ated to progra mmers. Figure 8 illustrates that template- ba sed sc r ipting interpreters ar e implemen ted as W eb server extensions. 2.3.1 S erver-side Includes. The Server Side Includes (SSI) capability was in- tro duced b y NCSA in 19 9 3 a s metho d for embedding trivial co mputations within HTML pages to be pro cessed directly by the W eb s erver, instead of by a separ ate pro cess as with CGI. SSI templa tes contain ﬁxed HTML text and v aria ble ar eas 14 · Barry J. D oy le an d Cristina Videira Lop es WEB SERVER Operating System BROWSER Client Machine Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response Template Interpreter Fig. 8. The W eb ser ver arc hitecture is extended with a template-based scripting interpreter to implement server-side templates. with co mma nds that execute b efor e a resp onse is s ent to a user. The technology is tag-c enter e d , in tha t dynamic b ehavior is s p eciﬁe d by sp ecial HTML tags, for matted comments that denote command keyw ords and pa r ameters. The initial SSI implementation supp orted the in clude command for text ﬁle in- clusion, the echo co mmand for v ariable o utput, and the exec c o mmand for running external programs. Conditiona l pro cess ing and other features were independently added to SSI by W eb server providers. On Apache W eb s e r vers, SSI plus several extensions is known as Extende d SSI (XSSI) . Fig ure 9 is a n ex ample Apache XSSI template with co nditional pro cessing comma nds ( if , elif , and en dif commands) and core SSI commands including conf ig , i nclud e , a nd echo . The example shows t wo typical uses of SSI which ar e to include common elements o n a g roup of pages, and c onten t adaptation bas ed o n client attributes. While infrequently used, SSI is not completely o bsolete and the core se t of co m- mands is supp or ted by most W eb ser vers. Ro le separation is better supp or ted by SSI than by CGI s ince the ﬁxed and v a riable ar eas of page s c a n b e built indep en- dent ly . W eb desig ners can work s trictly with HTML to desig n the app e arance of a page, adding exec commands to retrieve infor ma tion where dynamic con tent is required. Developmen t of log ic inv oked by e xec commands c a n b e delega ted to progra mmers. The disa dv a nt ag es of SSI a re related to scalability and usability concerns. SSI is no more scalable than CGI, and can b e worse for do cuments with multiple exe c commands. Each exec command leads to a pr o cess cr eation, adding appreciably to the W eb server pro cessing load even relative to CGI. The usability co ncerns are due to the primitive s yntax and CGI- ba sed pro ces s mo del. The syntax is erro r- prone, diﬃcult to in terna lize, but do es not not supp or t complex pro cessing other than through CGI v ia e xec co mmands. The dep endence on exec for non-trivial pro cessing defeats role separ ation. F or larger applications, the inevitable r eliance on exe c leads to barely main tainable, m ulti-lang uage tangles o f templates, scripts, and prog rams. While SSI is ra rely appropriate for new applica tions, it provides a n accessible, low cost alternative for non-critica l, low-traﬃc W eb applica tions Survey of T echn ologies for Web Application Development · 15 < ht ml > < head > < meta ht tp-equiv=”Cont ent-Langu age” conte nt=”en-us” > < title > SSI Example < /title > < !– #set var= ”V AR css” value=”msie” – > < !– #if expr= ”( $ HTTP USER AGENT=/Mozil la/) && ( $ HTTP USER AGENT !=/c omp atible/)” – > < !– #set var= ”V AR css” value=”nav” – > < !– #elif expr= ”( $ HTTP USER AGENT=/Op er a/)” – > < !– #set var= ”V AR css” value=”op er a” – > < !– #endif – > < LINK REL=”stylesheet ” type=”text/ css” href=”/css { / < !– #echo var= ’V AR css’ – > .css” > < / head > < bo dy > < !– #include virtual= ”p agehe ader.shtml” – > < p > This is an example SSI page. < /p > < p > Document name: < !– #echo var= ”DOCUMENT NAME” – > < /p > < p > Serv er lo cal time: < !– #config timefmt= ”%I:%M %p %Z” – > < !– #echo var =”DA TE LOCAL” – > < / p > < p > Browser type: < !– #echo var= ”HTTP USER AGENT”– > < /p > < !– #include virtual= ”p agefo oter.shtml” – > < p > Last up dated: < !– #con fig timefmt= ”%c” – > < /p > < / b ody > < / ht ml > Fig. 9. An example of an XSSI document. 2.3.2 ColdF usion. ColdF usion was intro duced in 1995 by Allair e Co rp oratio n as an “eas y to prog r am” tec hnolo gy for cr e ating dynamic conten t. The deﬁning featur e of the technology is the templa te- based ColdF usion Markup Languag e (CFML), originally interpreted but now JIT-co mpiled into servle ts . CFML adv a nced the templating model of SSI by providing a large set of comma nds , o riginally fo cus ed on databa se pr o cessing but ultimately also supp orting other functions including ﬁle management, ﬂow control, a nd forms pro ces sing, that is designe d to be compre- hensive for W eb applications. The co mmand syntax is simple, in that ColdF usion commands are recogniz a ble as tags with names starting with cf with v a riable refer- ences enclosed in # characters. Fig ure 1 0 shows a n e xample o f a simple ColdF usion template that displays dynamic conten t r etrieved from a database. ColdF usion is co mpa rable to SSI, sharing many of its adv antages and disad- v a nt ag es. T emplates are po r table since in terpr eters are av ailable for several W eb servers including Apache and I IS. Role separa tion b etw een W eb designers and pro- grammers is pos s ible to a simila r exten t as with SSI. Database access is optimized compared to CGI a nd SSI. The syntax is more ex pressive than that o f SSI, but still not well-suited for expr essing complex lo gic. The size o f the lang uage, in terms of the sheer n umber of options, reduces its usability . 2.3.3 S erver-Side J avaScript. The next widely-used technology for server-side scripting was script-c enter e d t emplating as exempliﬁed by the introductio n o f Server- Side J avaScript (SSJS) a nd the Microsoft A ctive S erver Pages (AS P) environment 16 · Barry J. D oy le an d Cristina Videira Lop es < cfquery name= ”A uthorR esult” datasour c e=”bo okdb” > SELECT authorName FROM authors < / cfquery > < ht ml > < head > < title > ColdF usion Example Author Listing < /TITLE > < / head > < bo dy > < h1 > Author List < /h1 > < cfoutput query= ”A uthorR esult” > #authorName# < BR >< / cfou tput > < / b o dy > < / ht ml > Fig. 10. An example of a ColdF usion document. WEB SERVER Operating System BROWSER Client Machine Operating System Abstraction Layer Reception Request Analyzer Access Control Resource Handler Transaction Log Server Machine Request Response ASP Interpreter (asp.dll) COM Objects ASP Templates Fig. 11. The architect ure of ASP . asp.dll is the scripting language interpreter that provide s access to COM ob jects f or inte rop erabili t y . in 199 6. Figure 11 shows the place of script-centered templating within the re f- erence W eb ser ver architecture. In sc ript-centered templating, blo cks of logic ar e embedded in HTML pages. Scr ipt-centered templating quic kly ga ined p opularity among prog rammers a s a more natura l wa y to pro duce dynamic conten t. SSJS preceded and inﬂuenced ASP but did no t catch on with developer s and is o bso- lete. SSJS pag es were c o nstructed from HTML and Jav aScript co de contained within < SERVER > tags. SSJS pages were compiled in to byte-co de representations that were interpreted by a n interpreter o n the W eb server. The SSJS develop- men t a nd runtime environment provided se rver , appli catio n , data base , cli ent , and re quest ob jects tha t supp orted state management. Output functions includ- ing wri te and w ritel n were provided to generate dyna mic conten t into HTTP resp onses from J av aScript co de blo cks. Figur e 12 shows an example of a SSJ S script. 2.3.4 Active Server Pages (ASP). ASP is a server-side s cripting environment for W eb applications that provides a scripting language engine that supports sev- eral languages , an o b ject mo del, and an in terface for accessing server comp onents. Survey of T echn ologies for Web Application Development · 17 < ht ml > < head > < title > Serv er-Side Jav aScript E xample Author Listing < /title > < /head > < bo dy > < h1 > Author List < /h1 > < server > if (!datab ase.c onne cted ()) { datab ase.co nne ct(”O DBC”,”b o okdb”,”admin”,””,” ”); } if (datab ase.co nne cte d()) { qs = ”SELECT au id, au fname, au lname FROM authors”; r esults = datab ase.cursor(qs); write(” < table b or der=2 c el lp adding=2 c el lsp acing=2 > ” + ” < tr >< th > ID < /th >< th > First Name < /th >< th > L ast Name < /th >< /tr > \ n”); while (r esults.next()) { write(” < tr >< td > ” + r esults.au id + ” < /td > + ” < td > ” + r esults.au fname + ” < /td > ” + ” < td > ” + r esults.au lname + ” < /td >< /tr > \ n”); } r esults.close(); write(” < /table > \ n”); } else { write(” < p > Datab ase c onne ction faile d”); } < / server > < / b o dy > < / ht ml > Fig. 12. An example of a Server-Side Jav aScript template. The most commonly us e d s cripting la nguage for ASP pa ges is VBScript. JScript, a Jav aScript v ariant, is als o supp orted out- o f-the-b ox, and other la nguages can be installed. ASP pag es are text ﬁles with .asp extension names that contain ﬁxed HTML a nd blo cks of scr ipting code within specia l bra ck ets ( < % .. % > ) o r < scri pt > .. < /s cript > tag pairs. The int eg r ative p ow er of ASP comes from the ability to a ccess COM comp onents on the server from within W eb pag es. The Comp onent Ob ject Mo del (COM) is a Microsoft s ta ndard that provides a language - indep e ndent means for deﬁning a nd referencing comp onents a s ob jects. An ASP executio n ha s built-in access to several automatically insta nt iated COM comp onents, collectively known a s the ASP built- in o b jects that hav e pro p e rties a nd metho ds that enca psulate the HTTP request- resp onse cycle. ASP scr ipts can also re fer ence the prop er ties and methods of other COM comp onents that are av aila ble on the W eb server. A standard ASP installa- tion includes a set of COM c omp onents that s uppo rt co mmon requirements of W eb applications. Figure 13 shows a simple ASP pa ge that displays data from a ta ble in a database. In the hands o f exp erienced prog rammers, ASP’s combination of HTML, scr ipting language co de, a nd access to COM comp onents c an b e a p ow erful to o l for building dynamic W eb a pplications. ASP b ecame the most p opular scr ipting - based tem- plating technology on the W eb, at le ast pa r tially due to the large installe d base of Microsoft server op era ting systems. The emergence o f ASP w as a s tep forward for W eb application developmen t; many sys tems s upp or ting dynamic conten t that 18 · Barry J. D oy le an d Cristina Videira Lop es < % Dim c onn, rs Set c onn = Serve r. Cr e ateObje ct(”ADOD B.Conne ction”) Set rs = Server.Cr e ateObj e ct(”ADODB.Re c or dset”) c onn.Op e n ” bo okdb”, ”sa”, ”p asswor d” Set rs = c onn.Exe cute(”sele ct au id, au fname, au lname fr om authors”) % > < ht ml > < head > < title > ASP Example A uthor Listing < /title >< /head > < bo dy > < h1 > Author List < /h1 > < table > < tr >< th > ID < /th >< th > First Name < /th >< th > Last Name < /th >< /tr > < % Do Until rs.EOF % > < tr >< td >< % = rs(”au id”) % >< /td > < td >< % = rs(”au fname”) % >< /td > < td >< % = rs(”au lname”) % >< /td >< /tr > < % rs.movenext Loop % > < / table > < / b o dy > < / ht ml > Fig. 13. An example ASP page that retrieves data from a database table. follow ed were inﬂuenced by the tec hnolo g y . The disadv antages of ASP are related to po r tability , scalability , integration, r e- liability , and usability concerns. Since ASP is still primar ily applicable only to Microsoft systems despite v ar ious p orting eﬀorts, applications are ge nerally not po rtable and integration with other platforms can b e pr oblematic. Scala bilit y is limited due to runtime interpretation, which consumes extra CPU cycles compared to compiled code ex ecution. While COM in tegra tion pr ovides access to an ad-ho c set of adv anced features including s upp o r t for tra nsactions, the techn olo gy was not designed from g round up as a c o mprehensive, ser vice-orie nt ed framework, so crit- ical concer ns such as security and reliability are not in tegr al to the environment . While the programming mo del is conceptually simple, the fundamental misma tch betw een the even t-driven natur e of applications and the page-centered int era ction constraints of the W eb is not addressed. The script-centered approach is less ac- cessible to non-prog rammers than tag - centered approaches, so ro le separation are diminished. 2.3.5 PHP. PHP is a n op en-source , cros s-platform, ob ject- ba sed scr ipting la n- guage for dyna mic W eb applications that is analog ous to ASP . V ersio ns o f PHP run on many o p er ating systems and W eb ser vers, and interfaces are av ailable to many database sy s tems. PHP is av aila ble for Windo ws o p e rating sys tems , but since ASP is genera lly the preferred option on Windows sys tems, P HP is most prev alent o n Linux sys tems running Apache. The PHP syntax contains e le ment s b orr ow ed fr o m C, Perl, and Jav a. Figure 1 4 shows a n example PHP script. While the adv an- tages a nd disadv an tag es of PHP a re compara ble to those of ASP , the po rtability of PHP can b e b eneﬁcial if an applicatio n needs to run on several platforms or Survey of T echn ologies for Web Application Development · 19 < ht ml > < head > < title > PHP Example < /title > < / head > < bo dy > < ? php $ r es string = ”; $ c onnval = o db c c onne c t (”b o okdb”, ”sa”,”” ); if ( $ c onnval) { $ rs r et = o db c e xe c( $ c onnval,”sele ct au lname + ’ , ’ + au fname as au name f r om authors”); if ( $ rs r et) { echo ” The SQL statement e x e cute d suc c essful ly. < br > ”; echo ” The r esults ar e b elow: < br > ”; echo ” < table >< tr >< td >< b > Au thor Name < /b >< /td >< /tr > ” while ( $ r es = o db c fetch r ow( $ rs r et)) { $ r es string = ” < tr >< td > ”.o db c r esult( $ rs r et,”au name”).” < /td >< /tr > ” ; echo $ r es string; } } else { echo ” The SQL statement did not exe cute suc c essful ly ”; } } else { print (” < br > Conne ct ion F aile d”); } ? > < / table > < / b o dy > < / ht ml > Fig. 14. An example PHP script that retrieves data f rom a database table. W eb servers. The op e n source co mbination of Lin ux, Apache, MySQL, and PHP , commonly referred to as LAMP , is gaining in terest as a low c ost platform fo r W eb applications. 3. SCALING UP TO T HE ENTERPR ISE In theo ry , server-side scripting environments such a s ASP provide building blo cks that supp ort the needs of large enterprise systems, but in reality to o m uch infras- tructure resp ons ibilit y is ass ig ned to individua l develop e rs. Instead o f b eing able to fo cus solely o n business logic, W eb application developer s hav e to implement ho me- grown solutio ns fo r transaction management, reso ur ce po o ling, and other complex features. F or larg e-scale W eb application development to be prac tical, infrastruc- ture concerns need to b e s e parated fr om business logic and presentation c oncerns. 3.1 Application Servers, Comp onents, and Middlewa re Large- s cale W eb applications ar e typically built with an architecture that makes use of applica tion servers a nd middleware to sep erate the W eb server, presenta- tion logic, business logic , and data access concerns into dis tinct tiers. Fig ure 15 20 · Barry J. D oy le an d Cristina Videira Lop es Browser Server machine Web server Database server Server machine Web server App server Server machine Web server Server machine App server Server machine Web server Server machine App server (Presentation) Server machine App server (Business) Database server Database server Database server Browser Browser Browser Fig. 15. Example multi-tiered conﬁgurations for W eb appli cations. In all of the conﬁgurations an HTTP pro cess and database server are r equired. shows several co mmon tier conﬁgurations (t wo-tier, three-tier, and four-tier) that are commonly used for enterprise W eb applica tio ns. The relia bility a nd infras- tructural req uirements for la rge W eb a pplications and the essential s e rvices that suppo rt the re quirements, co llectively k nown as midd lewar e servic es , are summa- rized in T able I I. The most widely applicable and eﬀectiv e middlew are services are standardized, po rtable, and supp ort rapid a pplication development. A pplic ation s ervers a im to meet the middleware requir ements of enterprise s ystems and are an int egr al part of la rge, dynamic W eb a pplications. This section presents an ov erview of the standards, prog ramming languag es, a nd environments that supp o rt enterprise-cla ss W eb a pplications. 3.2 Java-based Architectures Jav a is a p opular , g arbage - collected, ob ject-o riented la nguage developed by Sun Microsystems. Although Jav a initia lly gained attent ion on the W eb as a client-side techn olo gy for running secure a pplets within browsers, its impa ct has ultimately bee n g r eater on the server-side. The p o rtability o f Jav a a pplications b etw een plat- forms that suppo r t J av a Virtual Ma chine (JVM) implemen tations is a pa rticularly v a luable feature fo r the W eb, the most diverse computing environmen t imag inable. Reliability is improved relative to scripting la ng uages b e c ause Jav a is s tatically t yp e-s a fe. The en viro nment supp or ts run time reﬂection, interface-implementation separatio n, and dy na mic class loading, which are building blo cks for comp onents and application ser vers. None of the features are nov el, but the pack ag ing of the features w ithin a single environment was timely and g ained momentum with devel- op ers. There hav e b een tw o ma jor versions, Jav a and Jav a 2. Jav a 2 de-empha s ized ap- plets and deﬁned platform editions. A platform edition co nsists of a J VM, an SDK, and APIs. The J av a Run time Environmen t (JRE) cons is ts of the JVM and comp o- nent s needed to run applications. J av a 2, Standard Edition (J2 SE) consists of the Survey of T echn ologies for Web Application Development · 21 Requiremen t Approac h/Solution Description Reliability T ransparent fail -ov er Route r equests f or fail ed servi ces to another serve r. T ransaction supp ort Units of w ork completely succeed or are rolled bac k. System managemen t Provide system monitoring and control capa- bilities. High av ailability Minimize time that a system is not av ailable due to f ailures. Replication Duplicate r esources for l oad balancing or r ecov- ery . F ailure recov ery Detect servi ce failur es, divert requests to an- other instance. Throughput Load balancing Alternate r equests b et ween s erve rs to equalize utilization. Clustering In terconnect multiple serv ers to s har e a pro- cessing workload. Threading Execute requests concurrently within a pro cess. Eﬃciency Pro cess requests with mi nimal resources and la- tency . Scalability Mainta in stable p erf or mance as the rate of re- quests increases. Resource p ooli ng Share r esources betw een multiple users in an optimized wa y . Cac hing Sa ve computations f or later compatible re- quests. In tegration Remote method inv ocation In terfaces for synchronou s metho d i nv ocation. Bac k-end integration Int erfaces to external information systems. Database access Store and r etriev e database information. Location transparency Allow services to b e requested by directory name. Multi-proto col support In tegrate m ultiple protocols i nt o a uniform in- terface. Message-passing Async hronous comm unications though message-passing. Legacy connection In terfaces to obsolete or surpassed tec hnologies. Securit y Logging and auditing Record signiﬁcant activities that o ccur within the system. Pe rmi ssion chec king V erify identit y and protect resources. Dev elopment Rapid dev elopment Reliable applications can b e developed quick ly . Dynamic redeploymen t Running applications can b e up dated without int erruption. Separation of concerns Role-sp eciﬁc con tributions are separate i n co de modules. Mo dularity Isolated changes minimally im pact other parts of a system. Reusability Mo dules can b e used for multiple applications. Soft ware scalability Soft ware r emains manageable as system si ze in- creases. Po rtable languages Mo dules can r un without change s on multiple platforms. Standardization The tec hnology has m ultiple compliant prov iders. T able I I. Requiremen ts for en terprise business systems. 22 · Barry J. D oy le an d Cristina Videira Lop es JRE and the SDK. The J av a 2 platfor m, Enterprise Edition (J2EE ) is the pla tform used for enterprise W eb applica tion developmen t. J2E E includes J2SE a nd a set of sp eciﬁcations, designed to b e implemented by a pplica tion server providers, that deﬁnes a sta ndards for enterprise middleware services that provide infrastructure for large s cale W eb a pplications. 3.2.1 J ava Servlets. Jav a s ervlets e x tend W eb servers to supp ort dyna mic co n- ten t gener a tion. The Jav a Ser vlet API was introduced in 199 7 as a r eplacement for CGI. Servlets are functionally s imilar to CGI scripts in tha t b oth are intermediary comp onents that genera te dynamic resp onses to HTTP requests. Problems a reas for CGI that a re a ddressed by s ervlets ar e p erfor mance, sta te management, and standardized a ccess to middleware. The pro c e ss mo del is sim- ilar to scalable CGI in that instance s servic e multiple requests , but with servlets each instance is dedicated to a pa rticular ser vlet. Ser v lets ar e executed b y servlet c ontainers , also known as servlet engines , w hich ar e Jav a applications that man- age threads through their lifecycle . The use of threads instea d of pr o cesses im- prov es eﬃciency and sc alability , while providing eﬃcient access to glo bal ob jects initialized by the container. Since successive requests to a servlet are handled by a contin uous thread, lo cal ob jects instan tiated within the thread are av aila ble throughout a servlet’s lifetime. Server-side s ta te manag ement is suppor ted by the Servle tCont ext and Htt pSessi on s e rvlet API classes that hide details of co okie writing, URL rew r iting, and hidden ﬁeld creation. Servlets hav e access to the larg e set of Jav a platform AP Is. The eﬃciency and sca lability of ser vlets were the ma jo r factors that led to the emergence of J av a as a n imp or tant langua g e for server-side W eb progr amming, which is ong oing despite the ins urgence o f the .NET e nvironmen t. The usability disadv an tag e s o f servlet progr amming a re analo gous to thos e of CGI. As with CGI, the ser vlet mo del provides only a thin abstractio n over HTTP . Prog rammers must manually genera te resp ons e s by writing to the standar d output stream, so role separatio n is not well supp orted. Therefore, rela tively few W eb applications are comp osed entirely of s ervlets. Instead, servlets ar e used as a n under lying mechanism behind template-based, mo del- driven, and framework-bas ed technologies that were subsequently developed. Servlet Conta ine rs. Servlet containers extend W eb servers to implement the Jav a servlet API. A servlet container can function indep endently as a standalone W eb server, or ca n be connected to an ex ternal W eb server so that the container is dedicated to servlet pro cessing. A req uest r eaches a servlet container as the result of tw o ma pping s. The ﬁrst mapping forwards reques ts fr o m the W eb ser ver to the servlet co nt ainer . The second mapping determines the servlet c lass to execute based on the s e rvlet name extracted from the request URI. After a r e quest is mapp ed, the actions taken dep end on the current lifecycle stage o f the ser vlet. If the s ervlet is not a c tive, the container loads the servlet class and creates a class instance, and inv okes the s ervlet’s i nit metho d. Once the servlet instance is identiﬁed, the servle t container inv okes the servlet’s servi ce metho d to pro cess the request, passing a reque st ob ject a nd a respon se o b ject. A re quest ob ject encapsulates information abo ut HTTP requests, including para meters, attributes, headers , the request pa th, and the message b o dy . A respo nse ob ject encapsulates metho ds for Survey of T echn ologies for Web Application Development · 23 building HTTP res po nses. Servlet dev elop er s ov er r ide doGet a nd d oPost metho ds that a re inv oked b y the service metho d to resp o nd to HTTP r equest types ( GET or POST ). The cont ainer ca lls a servle t’s des troy metho d when it needs to r emov e a servlet from s e rvice. Servlet Programming. Servlet progra mming is supp or ted b y clas ses a nd inter- faces of the javax. servl et a nd javax. servl et.http pa ck ages. A s e r vlet must implemen t or extend a class that implements the Servlet interface. The Se rvlet int erfa c e deﬁnes the lifecycle metho ds of a servlet. A t ypical se r vlet cla ss extends HttpSe rvlet and ov errides the request pro cessing metho ds as requir ed by the a p- plication. Figur e 1 6 shows an ex a mple o f a v ery simple Jav a s ervlet progra m. 3.2.2 J avaServer Pages. Jav aServer Pages (JSP) is a templating technology that was int ro duced in 1999 to simplify servlet development. An exa mple JSP page is shown in Figure 17 . JSP pag es are text ﬁles with .js p extension names that contain HTML, and Jav a co de within sp ecia l delimiters ( < % .. % > ). Jav a declara - tions ca n be included within ( < % ! .. % > ) delimiters as ca n expres sions within ( < %= .. % > ) delimiters. JSP translation directives can be included in J SP pag es within ( < %@ .. % > ) delimiters . Commonly used directives a re @impor t , used to impo rt J av a pack ages; @ inclu de , used to include JSP fragment ﬁles into pag es; and @tagli b , used to declare tha t a page us es a tag library . The sy n tax diverges fr o m the simplicity of ASP with the addition o f elements that are closer in essence to SSI and ColdF usion. JSP pages can contain XML elements that initiate standard or custo m execution phas e actions . The standa rd a ctions de- ﬁned in the JSP sp eciﬁcation ar e recog nizable as elements with js p: preﬁxes. Examples of s tandard actions a r e < jsp: usebe an > , < js p:set prope rty > , a nd < jsp: getpro perty > , for making use of Ja v aBean comp onents; < jsp:i nclud e > , used to include s tatic or dyna mic resources within a page; and < jsp :forw ard > which transfer s control to a nother W eb pa ge. Custom actions inv oke functionality in tag libr aries , whic h a re Jav a comp onents that are reused by JSP pa ges. Custom actions are implemen ted b y tag ﬁles with J SP syntax or b y Jav a classes that con- form to with the JSP T ag Extension API. The J SP Standar d T ag Libr ary (JSTL) provides many ta g s supp or ting c o mmon functionality for W eb applications includ- ing conditional pro c essing, iter ation, in terna tio nalization, XML manipulation, and database ac c ess. JSP 2 .0 introduced the Expr ession La nguage (EL) , a simple lan- guage used to embed ex pr essions within JSP pa ges without Jav a s c ripting. JSP Containers. On the surface, JSP is r eminiscent o f ASP , but the implementa- tion is very diﬀerent. While ASP pag e s are int erpr eted, JSP pa ges ar e transfo r med by a JSP cont ainer in to servlets. A JSP c ontainer is a mo diﬁed ser vlet con tainer that also serves JSP pages . JSP pa ges hav e a lifecycle that includes translation (per page) a nd execution (p er request) phas es. T ranslatio n can o cc ur prior to de- ploymen t, on deploymen t, o r at runtim e a t the discretion of the implementer. In the executio n phase, the co nt ainer r outes requests to the s ervlet thread that was created on be ha lf o f a JSP page. The underlying servlet mechanism is unchanged by the additio n of the JSP technology , so JSP can b e considered to b e an eas ier, alternative path to developing servlets. JSP is p opular among develop ers b ecause it is simpler than serv le ts for W eb application developmen t. At ﬁrst g la nce, JSP app ear s to compe tently s uppo rt ro le 24 · Barry J. D oy le an d Cristina Videira Lop es import com.test.searc h.*; import jav a.io.*; import jav ax.servlet.*; import jav ax.servlet.http .*; public class ServletExample extends HttpServlet { String searchName = n ull; Searc hEngine searc hEngine = null; public void init() throws Servl etExcept ion { searc hEngine = new SearchEng ine(); } public void doGet(HttpSe rvletRequest request, HttpServletResponse resp onse) throws IOException, ServletException { resp onse.setConten tT yp e(”text /html”); PrintW r iter out = resp onse.getW riter(); out.print ln(” < html >< head >< title > Se rvlet Example < /title >< /head >< bo dy > ”); out.print ln(” < h1 > Ente r a name to search f or < /h1 > ”); if ((searc hName != null) { out.print ln(”The details are: ”); String result = searchEngine.searc h(searc hName); out.print ln(result); searc hName = null; } out.print ln(” < p >< form action= \ ””); out.print (resp onse.encodeURL(”ServletExample”)); out.print (” \ ” method=POST > ”); out.print ln(” < p > Search name: < input type=text size=30 name= \ ”Searc hName \ ” > ”); out.print ln(” < p >< input t yp e=submit v alue= \ ”Searc h \ ” > ”); out.print ln(” < /form >< /b o dy >< /ht ml > ”); out.close(); } public void doPost( HttpServletRequest request, HttpServletResponse resp onse) throws IOException, ServletException { searc hName = request.getPa rameter(”Searc hName”); doGet(requ est, r esponse); } } Fig. 16. An example Jav a servlet pr ogram. separatio n b etw een de s igners a nd pro grammers . Simple examples like the JSP page shown in Figur e 17 appe a r to provide e vidence. In prac tice , J SP pages tend to b e dominated by J av a co de and XML ta gs which defeats r ole separ ation. Pres entation is not adeq ua tely separa ted from b ehavior, leading to maintenance problems for large a pplications. The use of custom actions r esults in less co de b eing directly placed in JSP pag es and facilitates re use, but do es not a ddress the essential pr ob- lem; rather the problem is obscured since Jav a code is hidden behind action tags. Exp erience has shown that mixing Jav a and HTML pr o duces systems that ar e har d Survey of T echn ologies for Web Application Development · 25 < % @ page language =”java” import =” java.sql.*,Sche duleBe an” % > < jsp:useBe an id=” sche dule” sc op e=”session” class=”Sche duleBe an” / > < ht ml > < head > < title > T eam Sc hedule < /title > < / head > < bo dy > < p > T eam Schedu le: < /p > < table > < tr > < td >< b > Date: < /b >< /td > < td >< b > Time: < /b >< /td > < td >< b > Location: < /b >< /td > < td >< b > Opponent: < /b >< /t d > < / tr > < ! − − Get the app ointment information – > < %! Resul tSet rs; % > < % sche dule.setT e amName(r e quest.get Par amete r(”te am”)); rs = sche dule.exe c uteQuery(); % > < % while (rs.nex t ()) { % > < tr > < td >< b >< % = rs.getString(”D ate”) % >< /b >< /td > < td >< b >< % = rs.getString(”Ti me”) % >< /b >< /td > < td >< b >< % = rs.getString(”Lo c ation”) % >< /b >< /td > < td >< b >< % = rs.getString(”O pp onent” ) % >< /b >< /td > < / tr > % > } rs.close(); % > < / table > < / b o dy > < / ht ml > Fig. 17. An example of a si mple JSP page. to ma int ain [Hun ter 2 0 00]. Since J SP was introduced, m uch of the subse q uent in- nov ation for W eb developmen t has b een mo tiv ated by a sea r ch for techniques that prop erly exploit the capabilities of JSP and servlets. 3.2.3 Alternative T emplating Engines. Dedicated templating engines such as V elocity a nd W ebMacro aim to r eplace JSP as a presentation tec hnolo g y for W eb applications. T emplating engines a r e genera lly des igned to not allow Jav a co de to be a dded to templates, so tha t develop ers a re no t tempted to mix business a nd presentation logic in templates. XML tr ansformatio n, a notably diﬀerent appro ach within the same problem space, is taken by Enhydra XMLC, curr ent ly an op en source Ob jectW eb pr o ject. With XMLC, plain XML templates are compiled in to DOM template ob jects, which are Jav a classes that pro grammatica lly render the v a rious k inds of output requir ed by classes of c lie nt s, including HTML, WML, and other formats . Ra ther than embed Jav a co de into the templates, pro grammer s call XMLC-generated metho ds to manipulate prop erties of the DOM repres entation 26 · Barry J. D oy le an d Cristina Videira Lop es WEB SERVER Server Machine R e q u e s t A n a l y z e r A c c e s s C o n t r o l Request Response BROWSER Client Machine J2EE SERVER Application Server Machine WEB CONTAINER Business Logic Tier EJB CONTAINER Java Servlets JavaServer Pages (JSP) EJB Components Java Classes Java Naming and Directory Interface (JNDI) Java Database Connectivity (JDBC) Java Transaction Server (JTS) Java Messaging Service (JMS) Java Connector Architecture (JCA) Java Auth. Service (JAAS) Java 2, Standard Edition (J2SE) Java Virtual Machine (JVM) Presentation Tier Middleware J2EE Services and Interfaces Fig. 18. The J2EE archite cture for W eb applications. befo re the r esp onse is gener ated for the client. Apache Co co on, another well-kno wn XML transformatio n fra mework, supp orts dynamic conten t gener ation to multiple client types (channels) throug h its XSL T-based XSP templating langua g e. 3.2.4 J 2EE. The Java 2 platform, Enterprise Edition (J2EE) [Ro ma n et al. 2001] is a comprehensive set of standards desig ned to pr ovide a portable en viro n- men t that supp orts the requirements of large, enterprise W eb applications. J 2EE was ﬁr st anno unced in April, 19 97 and the ﬁr st r elated sp eciﬁcatio n, Enterprise J av- aBeans 1.0, was distributed in Mar ch, 1998 . J2EE-compliant application servers were widely av ailable by the end of 1999 . P r evious compara ble technologies include transaction pr o cessing mo nitors, message-o riented middleware, and distributed ob- ject brokers (CORBA and COM). The older tec hnolo gies generally only provided middlew ar e services throug h explicit API ca lls . A comp onent requiring transac - tional supp ort had to make AP I ca lls in an appropr iate sequence to b egin and commit transactions . In contrast, J 2EE suppo rts de clar ative midd lewar e b y which containers provide middleware services (such as concurr ency , transa c tional suppo rt, per sistence, distr ibution, naming, and security) to comp onents as sp eciﬁed in a set of declar ative conﬁgura tions. The use of declara tive middleware allows dev elop er s to concentrate on business log ic ra ther than on complex infrastructural details. The architecture of J2EE that supp orts W eb applications is s hown in Figure 18. The mo st well-known J2E E sp eciﬁca tion is Enterprise Jav a B eans (E JB), a co m- plex standar d for server-side comp onents. An EJB c ontainer is an a pplication server that pr ovides an execution environment for EJB comp onents. A J2EE s erver is an application server that implements all of the J 2EE s pe c iﬁcations. T able I I I summa- rizes the ma jor J 2EE sp eciﬁc a tions that are rele v a nt for W eb applicatio ns . When implemen ting a Jav a server-side W eb applicatio n, it is imp ortant to decide which services a re requir e d fo r the a pplication to help determine the class of application server that is needed. High-end application ser vers that implement all of the J2 EE sp eciﬁcations tend to b e muc h mor e exp ensive than s impler servers that provide few er servic es. In many cas e s , supp or t for servlets and JSP is suﬃcient to mee t the Survey of T echn ologies for Web Application Development · 27 Speciﬁcation Description En terprise Jav aBeans (EJB) Serv er-si de managed Ja v a components. Ja v a N ami ng and Directory Interface (JNDI) A directory interface for lo cating comp onen ts. Ja v a Database Connectivit y (JDBC) An interface f or accessing relational databases. Ja v a T ransaction Server (JTS) Declarativ e transactional supp ort for EJB components. Ja v a Messaging Servi ce (JMS) Allows comp onent s to comm unicate through m essag- ing. Remote Metho d Inv ocation (RMI) An interface for communication betw een distributed ob jects. Ja v a Servlets and Jav aServe r Pages (JSP) W eb server extension components. Ja v aMail Allows email to be sen t from Jav a programs. J2EE Connector Architecture (JCA) Connect ivity to legacy systems. Ja v a API for XML Parsing (JAXP) XML parsing Ja v a Authentica tion and Authorization Service (JAAS) Securit y for EJB comp onen ts. T able I I I. J2EE sp eciﬁcations. needs of an a pplication. J2EE has bee n successful and compliant applica tio n ser vers are av ailable fr om many providers. The platform can be very sca lable if pr op erly exploited, but the size and complexity of the a rchitecture can make it a diﬃcult en viro nment to work with. The lear ning curve for J 2EE developer s can b e relatively leng th y , esp ecially if EJB is use d, due to the co mplexity of the comp onent architecture. 3.3 .NET .NET is an enterprise computing platform which is provided a s a set of pro ducts for Micros o ft op er ating systems. The featur e s of .NET are compar able to thos e of J2EE. While designed to b e a cross-platform environment, .NET is mos t rele v ant for Micros o ft op e rating systems , although the open source Mo no pr o ject promises to bring .NE T to Linux. Due to the la rge installe d ba se o f Micr osoft op erating systems, .NET has bee n stea dily g aining traction with develope rs since its initial pro duction release in 2001. The main comp onents of the .NET platfor m a re the Common L anguage Runtime (CLR) a nd the .NET F r amework c lass libr a ry . The CLR is a virtual machine that dynamica lly compiles Micr osoft Interme diate L anguage (MSIL) byte c o de into native executable co de at runtime. .NET is a multi-language environment in that m ultiple so urce lang uages can b e compiled into MSIL byte co de and executed by the CLR. The Common T yp e System (CTS) deﬁnes how types are declar ed and us e d in the CL R, pr oviding a basis for type interop erability b etw een mo dules implement ed in diﬀerent languag es. Self-de s cribing comp onents, known as assem blies within .NET, a re ma na ged and executed by the CLR. The .NET F ramework class library is a large class librar y tha t provides similar functionality as the Jav a Platform APIs. Assemblies and the types they deﬁne are hierarchically group ed into names paces that can b e referenced by pr ogra ms . While many progr a mming langua ges are suppo rted, the primar y development language is C # , which is very similar to Jav a . .NET provides an environment for enterprise W eb applications that is co mparable 28 · Barry J. D oy le an d Cristina Videira Lop es WEB SERVER Server Machine R e q u e s t A n a l y z e r A c c e s s C o n t r o l Request Response BROWSER Client Machine .NET SERVER Application Server Machine Business Logic Tier ASP.NET Web Forms .NET Managed Components Assemblies Active Directory (AD) ADO.NET .NET Framework Enterprise Services Microsoft Message Queue (MSMQ) Messaging API (MAPI) .NET Framework System.XML .NET Framework Common Language Runtime (CLR) Presentation Tier Middleware .NET Framework Services and Interfaces Fig. 19. The . NET architec ture for W eb applications. J2EE F eature .NET Equiv alen t Ja v a Primaril y C # , other languages are suppor ted Ja v a Virtual Machine (JVM) Common Language Run time (CLR) En terprise Jav aBeans (EJB) Assemblies, .NET CLR managed comp onent s Ja v a N ami ng and Directory Interface (JNDI) Activ e Directory (AD) Ja v a Database Connectivit y (JDBC) ADO.NET Ja v a T ransaction Server (JTS) COM+, . N ET F ramew ork System.EnterpriseServices Ja v a Messaging Servi ce (JMS) Microsoft Message Queue (MSMQ) Remote Metho d Inv ocation (RMI) Remote Metho d Inv o cation (RMI) Swing API Win F orms Ja v a Servlets and Jav aServe r Pages (JSP) ASP .NET, W eb F orms Ja v a Serv er F aces (JSF) ASP .NET, W eb F orms Ja v aMail Messaging API (MA PI) Ja v a API for XML Parsing (JAXP) .NET F ramework System.XML T able IV. J2EE - .NE T platform feature cross-r ef erence. to J2 E E. T able IV co mpares the features of the t wo environments. ASP .NET is a reworked version of ASP that enables rapid dev elopment of W eb applications that make use of the capabilities of the .NET framework. The architecture of .NET for W eb a pplications is shown in Figure 19. 3.4 Architectures Based o n Other Languages While J2EE and .NET are the most well-known platforms for enterprise W eb ap- plications, a lternatives exist. Python is a simple, p or ta ble, freely av ailable o b ject- oriented pro gramming langua ge that has b een used a s a basis for enterprise systems developmen t [T ra uring 2 003]. Twisted is a large, sta ble framework that provides suppo rt for distr ibuted and netw or ked a pplica tions as well a s W eb applications [Twisted Matrix Lab orator ies 20 0 5]. The brea dth of Twisted illustrates the dif- Survey of T echn ologies for Web Application Development · 29 T ec hnology Tier Implemen tations Markup Standards Cl ient HT M L, XHTML, CSS Protocol sp eciﬁcations Serv er HTTP , SSL, M IME, W ebDA V W eb browser Client In ternet Explorer, Op er a, M ozilla, Netscape W eb server Serv er Apac he, Internet Information Server, Sun Jav a W eb Serve r, Zeus W eb Serv er, Jigsa w T able V. F oundational techno logies for the W eb. ﬁculties inv olved in supp orting enterprise W eb development outside of J2 EE and .NET: the framework includes a W eb server and a DNS server; enterprise capa- bilities including authen ticatio n and database co nnectivity; a distributed-ob ject broker; proto col abstractions and implemen tations including HTTP , SMTP , IR C, DNS, T elnet, TCP , and UDP; and interop erability with Python to olkits [Vinos k i 2004]. Another well-known Py tho n framework tha t is similar to Twisted is the Python E nterprise Application K it (P EAK) [PE AK 20 05]. Other langua g es that hav e be e n pr o p osed for enterprise web development ar e Cur l [W ard and Hostetter 2003], Cro quet [Smith et al. 20 03], Haskell [Meijer 2000], L ISP [Graham 20 01], Perl [Rolsky and Williams 200 3], Scheme [F elle isen 2 002], and Smalltalk [Bryant 2004]. E ach alter native lang uage and environmen t faces an uphill road on the wa y tow ar ds widespr ead a doption in enterprises due to the p opularity of J2E E and .NET, while a lso facing the diﬃculties of either r eimplementing basic W eb function- ality o r relying on prexisiting, low-perfor ming features of the infrastr ucture such as CGI. 4. CLASSIFICA TION OF SYSTEM S SUPPOR TING DYNAMIC WEB CONTENT This section s ummarizes the s urvey so far by pr esenting a cla ssiﬁcation of tech- nologies tha t ar e r e lev a nt to dynamic conten t gener ation fo r the W eb. Reﬂective of the ma jor sys tem requirements for dyna mic W eb applications, the top level of the classiﬁcation is divided into foundatio nal, in tegr ation, and dyna mic user in terface generation technology c la sses. Ea ch top level class is sub-classiﬁe d by technology t yp e, form, and function to yield co mparable g roups. A t the most ba s ic level of the class iﬁc a tion, key prop erties of well-kno wn examplars are named a nd c o mpared with the ob jectiv e of providing technology selection guidelines for W eb developmen t pro jects. F oundational T ec hnologi es. The basic functionalit y of W eb br owser clients is deﬁned by the HTTP proto co l a nd conten t description lang uage standards including HTML, XHTML, and CSS. W e b server functionality is also deﬁned by the HTTP proto col. T able V class iﬁes the foundatio nal technologies of the W eb. T able VI shows the most co mmonly used W eb browsers and W eb servers based on market share as o f January , 2005. In tegration T ec hnologi es. In tegr ation technologies do no t directly generate dynamic conten t. Rather they provide interfaces that allow web sites to acce s s information in o ther systems. T able VI I provides a classiﬁca tio n of client-based int egr ation technologies. T able VI I I shows the most commonly- used server-side 30 · Barry J. D oy le an d Cristina Videira Lop es Tier Pro duct (Provider) Platform (Tier s hare % ) W eb browsers In ternet Explor er (Microsoft) Windo ws (69.7) Oper a (Op era Softw are) Sev eral (1.9) Mozilla (The Mozilla Or ganization) Sev eral (23.3) Netscape (AOL / Netscape) Seve ral (1.4) W eb servers Apac he (Apac he Soft ware F oundation) Several (68.4) In ternet Information Server (Microsoft) Windo ws (20.9) Sun Jav a System W eb Server (Sun) Sev eral (23.3) Zeus W eb Server (Zeus T echnology) Sev eral (1.2) T able VI. W eb browsers and serv ers. T ec hnology Exemplars Key Prop erties and Common Us age Browser interfaces State managemen t Netscape Cookie API Us ed f or client state p ersi stence. W eb service cli en t in- terfaces SOAP , XML- RPC Highly p ortable. Increased i n teractivity . Scripting interfaces XMLHttpClient Highly p ortable. Increased i nt eractivity . T able VI I. Client -based i n tegration tec hnologies. T ec hnology Exemplars Key Prop erties and Common Us age Programmi ng la n- guages Nativ ely compiled C, C++ Highly p or table, hi gh p erformance, low us- ability . CGI scri pting and web ser v er ex- tension. In terpreted Perl, Python, Ruby Highly por table. Pe rf or mance v aries. CGI scripting. Byte-code compiled Ja v a, .N ET languages Highly portable. Goo d perf ormance. Ex- tensiv e l anguage run-time li braries. Comp onents Complex comp onent s CORBA, COM, EJB, .NET managed compo- nen ts En terprise systems dev elopment. Simple components Ja v aBeans, Spr i ng, pico- Con tainer, Ja v a classes En terprise systems developmen t. Impro ved usability . Middleware XML transformation XSL T, Co coon XML W eb publishing. Messaging MSMQ, MQ Series, J2EE JMS En terprise systems dev elopment. Securit y J2EE JAAS En terprise systems dev elopment. Data access ODBC, JDBC, ADO. NET Highly p or table. Highly scalable. Ob j ect-relational mapping Hib ernate, JDO, T opView, iBatis Highly por table. Highly scalable. Im- prov ed usability . W eb services SOAP , XML- RPC Highly p ortable. T able VII I. Serv er-si de i nt egration tec hnologies. int egr ation technologies. Survey of T echn ologies for Web Application Development · 31 T ec hnology Exemplars Key Prop erties and Common Us age Browser extension Browser speciﬁc APIs CCI, Activ eX, Netscape Plug-API High p er formance, low usabili t y . Extend browser capabilities. Client dynamism Directly inte rpreted Jav aScript, VBScript, DOM, SVG Highly p ortable due to W eb standards ac- ceptanc e. Increased interactivit y . Byte-code Macromedia Fl ash, Jav a applets Highly portable de p ending on plug-in spread. M arke ting presentation develop- men t. Rich interfaces Browser alternative s CURL, Sash W eblications, Konfabulator, XAML Used f or applications with high interactiv- ity r equiremen ts that need to access the In- ternet. Client fr amew orks Jak arta Commons http- Client Used for browser alternativ e developmen t. F orms interfaces InfoP ath, XF orms Used b y forms-based business systems. Dynamic assembly Edge Side Includes (ESI), Client Side Includes (CSI) Impro ved cached conte nt deli very . T able IX. Clien t-based dynamic con tent generation technolog ies. T ec hnology Exemplars Key Prop erties and Common Us age Serve r extension Serv er-s p eciﬁc ISAPI, NSAPI, Apac he API Proprietary . Scalable. Complex. Imple- men t extended server capabilities. Gatewa ys Simple CGI Po rtable. Not scalable. Low usability . Small-scale applications with si mple na vi- gational requirement s. Scalable F ast CGI Po rtable. Scalable. Lo w usabil ity . Medium to l arge-scale applications wi th s imple nav- igation requirements. In terpreters General purp ose Serv er-s ide Jav aScript, mod- perl Medium to large-scale applications wi th simple navigat ion requirements. T emplate-based SSI, XSSI, ColdF usion, ASP , PHP , JWIG Po rtable. Medium to large-scale applica- tions with simple navigation requirement s. Extended servers Servlet engines T omcat, Resin Highly p ortable. Scalable. Medium to en terprise-scale applications. F ramew orks. T emplate engines JSP , V elo cit y , W ebMacro, XMLC, F r eeMarker Po rtable. Scalable. Generally used as the view component of MVC impl emen tations. Con tent m anagemen t Zope, Co coon Scalable. W eb publishing. J2EE application serve rs W ebSphere, jR un, JBOSS, W ebLogic Highly p ortable. Highly scalable. Com- plex. En terprise systems. T able X. Server-side dynamic cont ent generation technologies. Dynamic Con tent Generation T ec hnologies. T able IX provides a cla s siﬁ- cation of dynamic technologies for W eb clients. T able X provides a classiﬁcation of dynamic tec hnolog ies for W eb ser vers. 32 · Barry J. D oy le an d Cristina Videira Lop es 5. WEB PROGRAMMING VS. R EGULAR P ROGRAMMING In softw are developmen t terms, the maturity level o f the s ta te of common pr ac- tices for W eb development has traditionally la gged rela tive to the technologies and techn iques used for other client-server applications [Gellersen and Gaedke 1999]. As la te a s 199 5, the CGI w as still the most practical option for dy na mic W eb con- ten t creation. In con tra s t, distributed ob ject en viro nmen ts based on CO RBA and COM have bee n av ailable fo r client-server developmen t since 1992. By the time that templating and scripting la nguages were co mmonly supp or ting la rgely ad- ho c W eb development practices, client-serv er development more a dv a nced, supp or ted by graphical developmen t to o ls, frameworks, and softw are engine e r ing practices. As the W eb b egan to b e used in a n increasingly la rge cla ss of cr itical business applications, it b eca me apparent that the fundamen tal require ments were not well suppo rted b y existing solutio ns. Ear ly attempts, ro ug hly b etw een 1995 and 1999, centered on try ing to ﬁnd a unifying API for W eb pr ogra mming , essentially v iewing the W eb as a distributed o b ject system in the tradition of CORBA [W3C 19 97; Cardelli and Davies 199 9; Manola 1999; T ho mpson e t a l. 1999 ]. Diﬃculties in co or- dinating the eﬀor ts o f the wide-ranging W eb communit y hindered eﬀor ts to deﬁne a global API, but the ma rk of distributed o b ject research c a n be seen in servic e- oriente d ar chite ct ur e (SOA) standards , which implemen t glo ba lly distributed W eb service technologies by exchanging XML ov er HTTP [W3C 2 004b]. The contin ual dispa rity fueled a marketing pip eline for dynamic W eb technol- ogy crea tors. Almost an y adv a nce that addressed limitations of W eb development could ﬁnd a waiting base o f p otential a dopters. Even pr oblematic technologies such as Activ eX found av enues of acceptance solely based on increment al beneﬁts. The intro duction of J2EE in 1 999 was a ﬂashpo int for the dynamic W eb; instantly the maturit y gap was nar row ed and priorities shifted s o that man y soft ware engi- neering adv a nces w ere for the ﬁr st time being driven by the req uir ements of W e b applications. The imp o r tance o f J2E E can not b e ov ersta ted since it set standar ds that hav e since inﬂuenced subseq ue nt signiﬁcant adv ances for W eb developmen t, including .NET, whic h surfa c e d a s a comp etitive r esp onse. This section examines to ols, tec hniques, and technologies that hav e b een ca r ried forward from traditional progr amming domains into the rea lm of the W eb. 5.1 F ramewo rks and Patterns While J2 EE and .NET provide infr astructure ne e de d to build reliable enterprise- scale W eb applications , the res po nsibility for eﬀectiv ely using the technology falls on individual implementers. Man y W eb applications ar e built in an ad-ho c fash- ion, without regard fo r softw are engineering pr inciples, deeply entangling cont ent, presentation, and b ehavior so that the str ucture of the implementation is obscur e d [Pressma n 2 000]. Recently muc h eﬀor t has b een dev oted to devising metho ds that exploit the technology base in a disciplined wa y while simplifying developmen t. The tangible result has b een the emerg ence of a large num ber o f W eb applica- tion development frameworks. The Jav a communit y has b een very inﬂuential in that the mos t p opular frameworks are op en so urce Jav a pro jects. W ell-known W eb application frameworks ar e also av a ilable for s erver-side scripting langua ges such as Perl, P HP , and Python. While ASP .NET a nd the .NET framework provide a Survey of T echn ologies for Web Application Development · 33 wealth of supp or t for W eb developmen t out-o f-the-b ox, .NET is also b eco ming a target for fra mework developmen t. This section discusses frameworks in relation to W eb application dev elopment along the req uir ements and patterns that prompt their developmen t. 5.1.1 Char acteristics of F r ameworks. F rameworks a re extensible mo dule sets suppo rting r apid development o f rep etetive require ments in a reliable w ay thoug h reusable skeletal des ign pattern rea lizations. The ob jective is to allow develop ers to c oncentrate on the problem doma in rather than on low-level implementation details, while providing concr ete b eneﬁts b eyond the asso cia ted ac q uistion a nd learning curve co sts. F rameworks are co mparable in terms of do cument atio n qual- it y , extensibility , mo dularity , evolv ability , ma turity , a nd white/black b ox prop erties [F a yad a nd Sc hmidt 1997 ]. Po orly documented and imma tur e frameworks should be avoided for critical applications. 5.1.2 Cate gories of Web F r ameworks. T he most useful fra meworks supp orting W eb application de velopment c a n b e ca tegorized as W eb applica tion and user inter- face fra meworks, p ersistence frameworks, and ligh tw eight co ntainers [Nash 20 03]. W eb applica tion and user interface fra meworks ar e the most directly r elev an t to dy- namic conten t gener ation sy stems. Persistence fra meworks such as Hib erna te aim to allow pro grammers to eﬃciently retrieve and up date data ba se infor mation thro ugh encapsulated ob jects rather than through direct SQ L calls, or through E J B en tity bea ns. F rameworks that leverage inv ersio n of control to simplify comp onent-based developmen t, collectively known as lightweigh t c ontainers , are gaining traction a s an more us ua ble alterna tive for J 2EE applications that would o therwise needlessly incur the implementation complexity o f EJB, even tho ugh high-end capa bilities are not require d. The op en so urce PicoCo n tainer and Spring fra meworks a r e highly- regar ded light weigh t container frameworks [Johnson and Ho eller 2004]. 5.1.3 Mo del-View-Contr ol ler. The Mo del-View-Contr ol ler (MVC ) design pat- tern [Krasner and Pope 19 88], commonly used in user interface progra mming to separate pre s entation, business, and sta te management concerns, is a logica l a rchi- tectural choice that matches the even t-driven nature of dynamic W eb applications. Early W eb technologies did not allow convenien t separ ation of co ncerns, but the more recent co nv ergence of J av a, scr ipting a nd template languag es, a nd s ervlets suppo rts the mo dula r ization o f W eb applications to alig n with the MV C roles. Figure 20 shows the most common mapping o f the MV C roles to J 2EE entities. F or .NET, a simila r mapping to ASP .NET, the IHttpH andler interface, and man- aged comp onents is p os sible. Much attent ion ha s b een fo cuse d on creating W eb MV C fr ameworks since 2000 , when the p otential for reuse and strea mlining the developmen t pro ce ss b ecame evident. As a r esult, many co mp e ting frameworks are av ailable, many of whic h a re pro ducts of o p en sourc e development pro jects. While the most well-kno wn fra meworks currently tar get the J2EE pla tform, several hav e bee n po rted to .NET, and ther e are also many scripting la nguage fr a meworks av ail- able. Scripting languag es framew or ks a re handicapp ed from the start by either a reliance on CGI or the need to implement a s uppo rting infr a structure analogo us to servlets, in addition to supp o rting MV C. 34 · Barry J. D oy le an d Cristina Videira Lop es Model (EJB or JavaBeans) Controller (Java Servlet) View (JSP or other type of template) Request Update Response Access Forward Fig. 20. Adapting the M VC architec ture for the J2EE W eb applications. 5.1.4 A pplic ation-driven Web MVC F r ameworks. Applica tion-driven W eb MV C frameworks implemen t MVC using the F r ont Contr ol ler pattern [F owler 2 002]. In the F ront Controller pa tter n, events are dir ected to an application- level Co ntroller that invok es the corr ect actio n in resp onse . The even t-action table is is maint ained at the a pplication le vel, usually in an XML ﬁle. Navigation deta ils ar e abstracted out of individual pag es, altho ugh the encapsulation and r eusability is compr omised by dep endencies on the c o nﬁguation ﬁle that deﬁnes the even t-action table. An application consists o f a Cont ro ller class, Mo del classes, View page templates, a nd a conﬁgura tion ﬁle. The main ob jectiv e is even t-handling rather than hiding imple- men tation details, so progr ammer familiarity with resource implement atio n tech- nologies is assumed. The light weigh t nature of the abstra c tio n reduces the lear ning curve fo r exp er ie nc e d W eb develop ers rela tive to more opa q ue frameworks. Novice W eb progr ammers may fac e an extended orientation p erio d due to the need to com- prehend the workings of a framework in a ddition to mo re fundamen tal co nce pts. Apac he Struts. The mos t well-kno wn a pplication-driven W eb MVC fra mework is the o p e n s ource Ap ache Strut s framework [Husted et a l. 20 0 3]. First introduced in 2000, Struts co nt inues to b e the most p opular W eb MV C framework for J av a. The framework is mature , well-do cument ed, a nd eﬀectively supp or ts the r equirements o f a la rge c la ss of interactive W eb applications. The implementation is str aightforw ar d and ba sed on the servle t, JSP , HTML for ms, Jav aBeans, and XML standar ds . While several well-known frameworks with active develop e r co mmu nities, including W ebW ork, Spring MV C, and Mav erick, o ccupy the same a rchitectural niche, the details of Struts, the de-facto leader, a re broadly r epresentativ e of the category . The e vent-action table for a Struts applicatio n is sp eciﬁe d in s truts -conf ig.xm l , an application-level conﬁguratio n ﬁle. The web.xm l conﬁgura tio n ﬁle for an appli- cation maps URI names to the Action Servl et serv let, a central C o ntroller s e r vlet supplied by the framework that routes requests to Action class instances that en- capsulate respons e log ic . Action instances access s ession data, HTML form data, and integration comp onents to formulate dynamic r esp onses. F orm be ans, Jav- aBean c o mp o nents that implemen t the Struts Actio nForm or DynaAc tionF orm in- terfaces, encapsula te the server-side state of the input ﬁelds o f an HTML form. The DynaA ctionF orm interface simpliﬁes state management by dy na mically creat- Survey of T echn ologies for Web Application Development · 35 ing form b eans when they ar e needed without requiring additional pro g ramming. After pro cessing res p o nse log ic , an Act ion class transfers control to the Controller passing a glob al forwar d , the logical name o f the View template tha t will gen- erate the next page of the dynamic user interface based o n the outcome of the resp onse logic. Although View templates are normally JSP pages , the framew or k allows o ther template engines to be used, including V elo city and W e bMacro. The Mo del is the lea st constrained tier of a Struts application, cons isting of comp o- nent s that are accessed by Ac tion class instances a nd View templates to dy na m- ically access and upda te per sistent informa tion. Field-level input v alidations, im- plement ed either by hand- c o ding fo r m b ean vali date( ) metho ds or by declara tion in the validator -rule s.xml and validatio n.xml conﬁguration ﬁles, are a lwa ys per formed on the server-side and optionally throug h generated Jav aScr ipt on the client-side. 5.1.5 Page-driven MVC F r ameworks. Page-driven frameworks implemen t the Page Contr ol ler pattern [F owler 20 02] to provide a n ev ent-driv en model for W eb progra mming that rec alls traditiona l desktop GUI progr a mming. In the Page Con- troller pattern, even ts generated from pages are directed to pag e-level Controllers. The even t-action table is sprea d thr oughout individual pag es of an application. An application co nsists of related pages , clas s es, a nd co nﬁg uration ﬁles. Rela- tive to application-driven frameworks, the higher degree of pag e indep endence al- lows heavier a bstraction over r esource implementation de ta ils that suppo rts r apid comp onent-based developmen t throug h drag-a nd-drop GUI page comp ositio n. The high abstr a ction level may extend the learning even for exp e rienced W eb progr am- mers due to the need to b eco me familiar with with a completely diﬀerent ob ject mo del. Desktop API Deriv ativ es. Several Jav a page-dr iven frameworks, including the op en source Echo [NextApp 2005] and wingS [wingS Pro ject T eam 2005 ] fr ame- works, implemen t the ob ject mo del o f the Jav a Swing API to litera lly apply desktop GUI pr o gramming techniques to W eb dev elopment. W ebCream [CreamT ec, LLC 2005] ta kes the approa ch to its lo g ical c onclusion b y converting compiled Swing applications into HTML pa ges at the W eb server dynamically at r unt ime. The eﬀectiveness of desktop API-der iv ative W eb application frameworks is limited by their code int ensive na ture, whic h preven ts role separa tion b e tween designers and progra mmers. GUI developmen t too ls such as EchoStudio simplify development , but are not ac cessible to W eb designer s since pa ge des ig ns a r e not bas ed on HTML so familiar W eb a uthoring to o ls can not b e use d. W ebOb jects. Other pa ge-driven frameworks take a mo re practical, template- based a pproach to incorp ora ting desk to p GUI pr ogra mming pra ctices into W eb de- velopmen t. The pr oprietary W eb development fra mework of the NeXT (now Apple) W ebOb jects application server en viro nment pioneered a page- driven, c o mpo nent- based a pproach to W eb progr a mming in 19 96. The W ebOb jects framework was initially built for Ob jective-C, but was re- implement ed for Jav a in 20 00 to supp ort J2EE developmen t. W ebOb jects applications are collections of pag es co nt aining HTML and r eferences to Web Comp onents . T ap estry . T ap estry [Ship 2004], av aila ble since 200 0, is a n o p e n source Jav a framework fro m Apache that was heavily inﬂuenced by W ebOb jects. T ap e s try 36 · Barry J. D oy le an d Cristina Videira Lop es provides an ob ject mo del for comp onent-based developmen t of W eb a pplica tions. A T ap estry application is a collection of pages that a re co mpo sed from HTML and c omp onents that encapsulate dynamic b ehavior. In T ap estr y , comp o ne nts a re known as Java Web Comp onen t s (J WC) . T apestr y supports tw o kinds of compo - nent s, user interface comp one nts a nd control comp onents. Co nt ro l comp onents are not render ed on pa g es but instead pr ovide control ﬂow cons tr ucts. Simple a p- plications can be co nstructed entirely fro m library co mpo nents provided as pa r t of the fra mework distribution. A T ap estry pa ge is deﬁned by an XML sp eciﬁca - tion, one o r more Jav a cla sses, and an HTML template. The XML sp eciﬁcatio n ident iﬁes a Jav a pag e c o ntroller class, and deﬁnes identiﬁers that indirectly bind comp onents to HTML templates. The page co n tro ller class implements l isten er metho ds that handle use r in terface even ts. T emplates contain HTML and co mpo - nent reference s . A T ap es try component deﬁnition includes an XML sp eciﬁca tion, one or more Jav a class es, and an HTML template. Both page and co mp o nent templates consist of plain HTML and placeholder tag s that reference components through a s p ecia l attribute, jwci d . Role sepa ration is well-suppo r ted since W eb designers can use their preferr ed authoring to o ls to design page templates, which templates contain only v alid HTML. Although the fra mework int erna lly routes all requests thro ugh a single entry servlet, the Ap plica tionSe rvlet , the T ap estr y ob- ject mo del co mpletely abs tracts ser vlet pro ces sing. Pr ogrammer s do not need to understand ser vlet pro ces s ing to eﬀectively use the fra mework. T ap estry app eals to desktop GUI progr a mmers since they are familiar with even t-driven progra m- ming. While the dynamic conten t generation pro cess is computationally intensive, the framework av oids sca lability problems by eﬃciently caching internal ob jects. ASP . NET and Ja v aServ er F aces. While T ap estry is technically hig hly-rega rded, the momen tum behind the framew or k has b een larg ely eclipse d by the emergence of ASP .NET [Esp o sito 2 0 03] and, to a lesser extent so far , the nascent Jav aServer F aces (JSF) spec iﬁc a tion [Mann 2004]. ASP .NET is a n upgraded version of ASP that suppo rts W eb F or ms, a namespace within the .NET framework tha t pr ovides a page-driven ob ject mo del for W eb prog ramming that is simila r to the T apes tr y ob ject mo del. JSF is a sp eciﬁca tion for a co mp o nent-based W eb a pplication frame- work built ov er JSP and tag librar ie s, muc h closer in concept to Struts than ASP .NET. J SF has s up er ﬁcial similarities to ASP .NET, but is very diﬀere nt in detail. Both fr ameworks supp ort rapid user interface developmen t with GUI form builder to ols, primarily Visua l Studio.NET for ASP .NET a nd Jav a Studio Cre- ator for JSF. A ma jor conc e ptual diﬀerence is that ASP .NET is page- driven, while JSF is application-dr iven. All requests for J SF application resourc es ar e r outed to views by a c e ntral servlet, the F acesS ervle t , p er s p eciﬁc a tions in the a pplication- level face s-con fig.xm l ﬁle. While the uptake o f JSF is in an ear ly stage and widespread adoption is not inevitable, the merging of characteristics of the F ront Controller and Page Controller patterns pr ovides a higher degree of deploymen t ﬂexibility due to clea rer separa tio n of the navigational as pec t from page deﬁnitions relative to ASP .NET. P ortals and P ortlets. The c o mp o nent mo del of p ortlets is close ly related to JSF, which features int egr ation with the Jav a Portlet API [Abdelnur and Hepp er 2003 ]. Portlets ar e managed Jav a comp o ne nts that resp o nd to requests and generate dy- Survey of T echn ologies for Web Application Development · 37 namic co nten t. Jav a Portlet API sp eciﬁes how to comp ose comp onent po rtlets into combined p ortals that aggreg ate conten t fro m p ortlet sub ject to p er sonalizatio n. A similar comp onent mo del is provided by the ASP .NET W ebParts framework. 5.2 Other Programming T echnolog ies Several technologies have b een developed that attempt to addre ss the mismatch betw een ﬂo w control in W eb developmen t relative to other kinds o f prog r amming. The disconnect is ma inly due to the fact that user interface pro cess ing is distributed in W eb pr ogra ms, with clients displaying int er fa ces that are a t least partially formu- lated o n s ervers. F unctional progr amming with contin uations has b een us ed to g en- erate dynamic con tent with some success, but remains outside of the mainstream. Contin uations are used to a bstract the retention of state information b etw een in- teractions. The MA WL, < bigwig > , JWIG, and Co co on Flow pro jects implement session-c enter e d pr o gra mming , a metho d for combining page template fra g ments with control ﬂow log ic that maintains the state o f lo ca l v ar iable by a mech anis m that has similarities to c o ntin uations. 5.3 Mo del-Driven Development of W eb Applicatio ns The deﬁning feature o f mo del-driven de velopment is auto matic co de genera tion of deploy able applications from hig h-level featur e sp eciﬁca tio ns. Mo del-driven devel- opment technologies for W eb applications aim to simplify the dev elopment pro cess by gener ating deployable sites from pre s entational, b ehavioral, and navigational requirements speciﬁed in mo dels. In the tradition of prior work in automatic pro- gramming and CASE, which were not completely successful, mo del-driven devel- opment tec hnolog ies aim to reduce the dep endency on low-level progra mming b y raising the abstractio n mo del to a higher level. Adaptatio n to W eb developmen t required the c r eation o f new kinds of mo dels, metho ds, and techniques that b etter match the unique prop erties of W eb applications. Initial Progress. Araneus [Atzeni et al. 1 9 97] and Strudel [F ernandez et al. 19 99], are repr esentativ e of initial research pro gress in a dapting mo del-dr iven techniques for W eb development. These sy s tems utilize data mo dels to manage collections o f generated cont ent derived using da tabase metadata and queries. F raternali [19 99] survey ed current work in the a rea as of 19 99, including AutoW eb, RMM, OOHDM, and the Oracle W eb Developmen t Suite, each of which applied pr oprietar y databa se, navigation, b ehavior, and presen tation mo deling approaches to W eb development. W ebML a nd its c o mmercial s uccessor , W ebRatio, use pr oprietar y hyp ertext, data, and presentation models to comprehensively extend the prior work by generating co de for an abstract framework that maps to platform-s p eciﬁc MV C implemen ta- tions a t runtime. Other pro ducts, including Co deChar g e, Co deSmith, DeKlar it, and F abrique, emphasiz e GUI-based maintenance of detailed mo dels that fa c ilitate generative pr ogra mming of the presentation tier for W eb applicatio ns, at v arying degrees o f rigo r. While these initial a ppr oaches were work able, widespr ead usa ge of the tec hnolo gies was limited by the r eliance on pr oprietar y mo deling languages . Mo del -driv en Arc hitecture. The Mo del Driv en Arc hitecture (MD A) standard from OMG chose UML as the primar y mo deling lang uage for mo de l- driven de- velopmen t. UML was formally extended to b e computationally complete in order to b e a ble to supp ort the level of detail ne e ded to genera te applications of abi- 38 · Barry J. D oy le an d Cristina Videira Lop es trary c omplexity from sp eciﬁcatio ns. The MD A standards are the pro duct of a n industry-wide eﬀort to raise the abstraction level of business sys tems developmen t. The Meta-O b ject F acility (MOF) is a set of standa rdized interfaces, including the XML Metadata Interc hange forma t (XMI), that provide the basis for the sp eciﬁ- cation mo dels required for MDA . A Platform Indep endent Mo del (PIM) sp eciﬁes application featur es g enerically that are c onv erted by rule-driven translators into Platform Sp eciﬁc Mo dels (PSM) that reﬂect the unique prop er ties of dispar ate plat- forms. A PSM can b e either direc tly interpreted or further pro cessed to g enerate a deploy able system. W eb applica tions are suppor ted by MD A too ls as a nother im- plement ation pla tform to target for co de genera tion. La rge vendors are backing the MD A standards with compliant to olsets, including Oracle ADF a nd IBM/Ra tional Rapid Dev elop er , and co mprehensively supp or t W eb application and W eb ser vice developmen t. While MD A has the p otential to shield developer s from the imple- men tation complexities inherent in W eb applications and impr oving the pro cess, the MD A pr o cesses represent a ma jor para digm shift for organiza tions and widesprea d diﬀusion of the technologies, if is oc curs, will be incr emental. 5.4 Author ing T o ol s and Development Environments A diverse r a nge of developmen t to ols supp or ts the cr e a tion o f W eb applica tions. The simplest W eb authoring to o ls supp or t static page creation thro ugh dir ect edit- ing, WYSIWIG HTML editing, and the ability to sav e do cuments into other formats to an HTML repres ent atio n. The to ols in this catego ry include Ado b e PageMill, Amay a, and Micr osoft Oﬃce applications such as W ord, Exce l, and Pow erPoin t. The nex t level of sophistication is found in site management to ols that include HTML editors. Microsoft F rontP age, NetOb jects F usion, and initial versions of MacroMedia Drea mwea ver a re in this catego ry , featuring too ls for managing a site’s link structure, simplifying deploymen t, and as sisting in the in tro ductio n of client-based dynamism in to pages. Rece nt versions of Drea m weav er feature tighter int egr ation with server-side dynamic cont ent g eneration technologies, blurr ing the distinction between W eb authoring to ols a nd full-ﬂedged W eb application devel- opment environmen ts. This la tter category includes Microsoft VisualStudio.NET, Sun Jav a Studio Crea tor, and the Eclips e-based W ebSphere Application Devel- op er. F ull-ﬂedged dev elopment environments hav e all of the functiona lit y of W eb authoring to ols, while als o s upp o r ting progr amming-intensiv e activities. As the de- velopmen t pro cesses mov e towards co mpo nent-based metho ds, the exp osed APIs of the co mp o nents may lead to le s s co de- int ensive developmen t pro cesses for dynamic web a pplia tions and increased convergence of the development enviromen ts towards the simplicit y of W eb authoring to ols. 5.5 Summa ry T able XI prese nts a summary o f the curr ent server-side application developmen t approaches. In s pite of the amount o f eﬀor t that has bee n fo cused o n bringing discipline to web programming, as evidenced by n umber o f approa ches that hav e bee n tried, W eb application developmen t is still hard. Even when using the most adv anced frameworks or developmen t environmen ts to prog ram simple applicatio ns , progra mmers must internalize several prog ramming mo des and languages within a single implementation str eam. Examples are a bunda n t, as in the case of the .NET Survey of T echn ologies for Web Application Development · 39 T ec hnology Exemplars Key Prop erties and Common Us age F rameworks Scripting language- based Twisted (Python) , W eb- W are (Python), Snake lets (Python), Rails (Ruby) Po rtable. Smal l to large-scale appli cations with complex navigation requirement s. Application-driven St ruts, Spring MVC, W eb- W ork, Mav eric k, Barracuda Po rtable. Scalable. En terprise we b sites with complex navigation requirement s. Pa ge-driven, component-base d, desktop mo del Ec ho, wi ngS, W ebCream, Wi.Ser Po rtable. Complex. Ease transition to W eb programming. Pa ge-driven component-base d, W eb mo del W ebOb jects, T apestry , ASP .NET W ebF orms Po rtable. Scalable. High usabil ity . Rapid developmen t. Simple to medium- complexit y navigation requirements. Application/P age Hybrid-driven component-base d Ja v aServe r F aces Po rtable. Scalable. High usability . En- terprise web sites with complex navigation requirement s. Rapid dev elopment . Po rtal comp osition Jav a Portlet sp eciﬁcation, W ebP arts, Tiles, SiteMesh Po rtable. Scalable. En terprise por tal de- v elopment. Mo del Driven D e- ve lo pmen t Data-cen tered AutoW eb, RMM, OOHDM, Oracle W eb De- v elopment Suite, W ebML, W ebRatio Data-in tensive applications. GUI-cen tered Co deCharge, CodeSmith, DeKlarit, F abrique In teration-inte nsive applications. MDA-complian t Oracle ADF, IBM/Rational Rapid Dev elop er OMG standard. Dev elopment En- vironments Authoring tool s Adobe P ageMill, Amay a, Microsoft Oﬃce (W ord, Ex- cel, Po werP oint ) Static cont ent creation and editing. W eb si te manage- men t F rontP age, NetOb jects F usion, MacroMedia Dreamw ea ver Mostly static web si tes with simpl e naviga- tion requirements. F ull-ﬂedged en vir on- men ts Microsoft VisualStu- dio.NET, Sun Jav a Studio Creator, W ebSphere Appli- cation Developer Programming-intensiv e. Others Programming lan- guages MA WL, < bigwig > , JWIG, functional cont inuations, Coco on Flow Researc h pr o jects. T able XI. Serve r- side dev elopment approac hes. 40 · Barry J. D oy le an d Cristina Videira Lop es W eb pr ogra mmer who must b e minimally b e familiar with HTTP , C # , ASP .NET, Jav aScript, HTML, XML, W ebF orms, Visua lStudio .NE T, and v arious middleware int erfa c e s of the .NET F ramework, including ADO.NET for access to da tabases, befo re even starting to build an a pplication. The ment al mo dels a re complex , not int uitive, and hav e built-in co nceptual barriers that extend be yond the details of particular technologies. Newcomers face a long learning curve b efore they can bec ome pro ductive. 6. CONCLUSIONS W e hav e presented an ex tensive survey and s everal categ orizatio ns of technologies related to web pro gramming. The s e veral tables presented throug hout the pap er can serve as a roadma p for choo sing technical a rtifacts accor ding to a sp eciﬁc a pplication needs. The conclusions of our study can be summar ized as fo llows. Infrastructure. The technical problems related to the web infrastr uc tur e hav e largely b een solved. Scalabilit y is simply a matter o f cost, a s evidenced by the existence of Go ogle which serves over 1 000 user s per s econd with sub-second av er- age resp onse time. High levels of scala bilit y ar e achiev ed through loa d balancing betw een p eer systems, and clustering systems are us e d to balance the pro cessing load betw een clusters of low-cost servers. While the Goo gle solution is b eyond the techn ica l capabilities o f most orga nizations, the load balancing fea tures o f J2E E and .NET pr ovide pra ctical scalability . These enterprise solutions a lso hav e fea- tures that can assure reasona ble levels of reliability , extens ibility , po rtability , and security of W eb a pplications. Application Dev elo pmen t. Simple a pplications that provide o nly small amounts of dynamic conten t are appr opriately suppo rted by ad-ho c prog r amming such as CGI. How ever, as a pplications b ecome interaction- a nd data-intensive, tho s e ad- ho c pr ogra mming metho ds don’t s cale well. Industrial-str ength applicatio n de- velopmen t platfor ms s uch a s J2E E and .NET, built on several years of ad-ho c exp erimentation, a im at simplifying applica tion developmen t. Unfortunately , the learning curve for master ing one o f these platfor ms is lo ng and steep, and even the most pr oﬁcient s oftw are engineer who can master non-web application development will b e ov er w he lmed by the complexity . Also, supp ort for the co ordina ted sepa - ration b etw een desig ners, business exp erts and progra mmers is lacking. The most int eres ting challenges ahea d lie in eﬀectively simplifying the pro cesses and metho ds of web application developmen t. In the last few years, a s igniﬁcant eﬀort has b een devoted to devising meth- o ds that e x ploit the technology base in a disciplined wa y . These methods include frameworks based on pr ov en desig n patterns, exp erimental pro gramming language approaches, mo del-dr iven architectures a nd dev elopment environmen ts. Although promising, they carry along pre conceptions br ought fr o m no n-W eb applica tion de- velopmen t. It is to o ear ly to as s ess their s uitability and impa c t. Overall, our study led us to b e lieve that the most c r itical element at this p oint is to for mulate a co ncise and simple mo del of what these a pplications are ab out, and to build a pro gramming system around such a mo del. Survey of T echn ologies for Web Application Development · 41 REFERENCES Abdelnur, A. and Hepper, S. 2003. JSR 168: P ortlet speciﬁcation. JCP speciﬁcation. http: //www.jc p.org/en/jsr/d etail?id=168 . Activ eState 2003. PerlEx - O nline Do cs . ActiveStat e. http://aspn.act ivestate.com/ASPN/ docs/ASP NTOC- PERLEX____/ . Al theim, M . and McCarron, S. 2001. XHTML 1.1 - m odule-based XHTML: W3C recommen- dation 31 M ay 2001. W3C Recommendation. http://www.w3. org/TR/xhtml11/ . Apac he Softw are F oundat ion 1996–200 3. Ap ache HTTP Server V ersion 1.3: Ap ache API Notes . Apac he Soft ware F oundation. http://h ttpd.apache.org/d o cs/misc/API.html . Apac he Soft ware F oundation 1999-2004. Ap ache HTTP Server Pr oject . Apache Softw are F oun- dation. http://h ttpd.apache.o rg/ . Apte, V. , Hansen, T. , and Reeser, P. 2003. Performance comparison of dynamic web platforms. Computer Communic ations 26, 8, 888–898. A tzeni, P. , Mecca, G . , an d Merialdo, P. 1997. T o w eav e the web . In 23r d International Confer enc e on V ery L ar ge Datab ases (VLDB’97) . Bell, G. 1997. The b o dy electric. Communic ations of the ACM 40, 2, 30–32. Bellovin, S. M . , Cohen, C. , Ha vrilla, J. , Hernan, S. , King, B. , Lanza, J. , Pesante, L. , Pethia, R. , McAllister, S. , Hen aul t, G. , Goodden, R. T. , Peterson, A. P. , Finnegan, S. , Ka t ano, K. , Smith, R. M. , and Lowenthal, R. A. 2000. Results of the security i n A ctiveX wo rkshop, CER T Co ordination Center, Pittsburgh, P A, August 22-23, 2000. www.cert. org/ reports/ activeX_report .pdf . Berners-Lee, T. 1989. Information managemen t: A prop osal. http://www.w3 .org/History/ 1989/pro posal.html . Berners-Lee, T. , Cailliau, R. , Luotonen, A. , Nielsen, H. F. , and Secret, A. 1994. The World-Wide Web. Communic ations of the ACM 37, 8, 76–82. Berners-Lee, T. , Fielding, R. , and M asinter, L. 1998. RFC 2396: Unifor m resource identiﬁe rs (URI): Generic s yn tax. http://www.ie tf.org/rfc/rfc2396.txt . Berners-Lee, T. an d Fischetti, M. 2000. Wea ving the Web . Harp erColli ns, San F rancisco, CA . Bos, B. , C ¸ elik, T. , Hickson, I . , and Lie, H. W. 2004. Cascading style sheets, level 2 revision 1, CSS 2.1 sp eciﬁcation: W3C candidate recommendation 25 F ebruary 2004. W3C Recommen- dation. http://www .w3c.org/TR/CSS21/ . Bro wn, M. R. 1996. F astCGI: A high-p erformance gatewa y interface. Position paper f or the work- shop “Programming the W eb - a search for APIs”, Fi fth International W orld Wide W eb Confer- ence, 6 May 1996, P ari s , F r ance. http://www.fas tcgi.com/devkit/doc/fastcgi- whitepaper/ fastcgi. htm . Br y ant, A. 2004. T utorial: A walk on the Seaside. http://bet a4.com/seaside2/tutorial.html . Cardelli, L. and Da vies, R. 1999. Service comb inators for we b computing. IEEE T r ansactions on Softwar e Engine ering 25, 3, 309–316. Clark, J. 1999. XSL transfor m ations (XSL T) version 1.0: W3C recommendation 16 Nov em b er 1999. W3C Recommendation. http://www.w3.o rg/TR/xslt . CreamT ec, LLC 2005 . WebCr e am White Pap er . Cr eamT ec, LLC. http://www.cre amtec.com/ webcream / . Esposito, D. 2003. Th e ASP .NET page ob ject mo del: One day in the l ife of an ASP .NE T we b page. MSDN Libr ary . http://msdn.m icrosoft.com/library/default.asp?url=/library/ en- us/dnaspp/ht ml/aspnet- p ageobjectmodel.asp . F ay ad, M. E. a nd Schmidt, D. C. 1997. Ob ject-orient ed application f rameworks: Introduction. Communic ations of the ACM 40, 10, 32–38. Felleisen, M. 2002. Developing interac tive web programs. In A dvanc e d F unctional Pr o gr amming , J. Jeuring and S. L. P . Jone s, Eds. Lecture Notes i n Computer Science, v ol. 2638. Spri nger, 100–128. Fernandez, M. F. , Suciu, D. , and T a t arinov, I. 1999. Declarativ e sp eciﬁcation of data-in tensive we b sites. In Domain-Sp eciﬁc L anguages (DSL) . 135–148. 42 · Barry J. D oy le an d Cristina Videira Lop es Fielding, R. , Gettys, J. , Mogul, J. , Fr ystyk, H. , Masinter, L. , Leach, P. , and Berners- Lee, T. 1999. RF C 2616: Hyp ertext transfer proto col – HTTP/1.1. W3C Recommendation. ftp://ft p.isi.edu/in-no tes/rfc2616.txt . Fielding, R. T. and T a ylor, R. N. 2002. Principled design of the mo dern w eb ar chitecture. ACM T r ansactions on Internet T echn olo gy 2, 2, 115–150. F owler, M. 2002. Patterns of Enterprise Applic ation Ar chitectur e . Addison-W esley , Boston, MA. Fra ternali, P. 199 9. T ools and approaches for develop ing data -i n tensive web applications: A survey . ACM Computing Surveys . Garrett, J. J. 2005. Ajax: A new approac h to W eb applications. http://ww w.adaptivepat h . com/publ ications/essay s/archives/0003 85print.php . Gellersen, H.-W. and Ga edke, M. 1999. Ob ject-oriented web application dev elopment. IEEE Internet Computing 3, 1, 60–68. Gousios, G . a nd S pinellis, D. 2002. A comparison of p ortable dynamic we b conten t techno logies for the apac he web server. In Pr o ce e dings of the 3r d International Sy stem A dministr ation and Networking Confer enc e SANE 2002 . 103–119. Graham, P. 2001. Lisp in web-based applications. http://lib1. store.vip.sc5.yahoo.com/lib/ paulgrah am/bbnexcerpts .txt . Hassan, A. E. and Hol t, R. C. 2000. A reference arc hitecture for web serv ers. In WCRE . 150–159. Hunter, J. 2000. The problems with JSP. http://www.s ervlets.com/soapbox/problems- jsp. html . Husted, T. , Dumoulin, C. , Franciscus, G. , and Winterfeldt, D. 2003. Struts in Action . Manning Publications, Greenwic h, CT. Johnson, R. and Hoeller, J. 2004. Exp ert One- on-One J2EE Development without EJB . Wiley , Indianapolis, IN. Krasner, G. E. and Pope, S. T. 1988. A co okb o ok for using the mo del-view controller user int erface paradigm in smalltalk-80. Journal of O bje ct Oriented Pr o gr am. 1, 3, 26–49. Mann, K. 2004. JavaServer F ac es in A ction . Manning Publications, Gr een wich, CT. Manola, F. 1999. T echnologies for a web ob j ect mo del. IEEE Internet Computing 3, 1, 38–47. Meijer, E. 2000. Server si de we b scripting in haskell. Journal of F unct ional Pr o gr amming 10, 1, 1–18. Microsoft Corp oration 2005a. IIS Web Development SDK . M icrosoft Corp ora- tion. http://msdn .microsoft.com/library/default.asp?url=/library/en- us/iissdk/html/ e8eff418 - 8e4f- 4db8- ad70- 01473bf10741.asp . Microsoft Corp oration 2005b. Internet Information Servic es . Microsoft Corp oration. http: //www.mi crosoft.com/wi ndowsserver2003 /iis/ . Nash, M. 2003. Java F r ameworks and Comp onents: A c c eler ate Y our Web Applic ation D evelop- ment . Cambridge University Press, Cambridge, UK . NCSA 1993. The Common Gateway Interfac e . NCSA. http://h oohoo.ncsa.ui uc.edu/cgi/ . NCSA 1995. NCSA Mosaic Common Client Interfac e . N C SA. http ://archive.ncs a.uiuc.edu/ SDG/Soft ware/XMosaic/C CI/cci- spec.html . NextApp 2005. Echo White Pap e r . NextApp. http://www.next app.com/products/echo/doc/ white_pa per.html . Ousterhout, J. K. 1998. Scripting: Higher-level programming for the 21st cen tury . IEEE Computer 31, 3, 23–30. PEAK 2005. Python Enterprise Applic ation K it pr oje ct homep age. PEAK. http://pea k. telecomm unity.com/ . Pressman, R. S. 2000. Manager - what a tangled web we wea ve. IEEE Softwar e 17, 1. Raggett, D. 1999. HTML 4.01 speciﬁcation: W3C recommendation 24 Decem ber 199 9. W3C Recommendation. http://www. w3.org/TR/html4/ . Raggett, D. , Lam, J. , Alexander, I. F. , Kmiec, M. , and Alexander, I. 1997 . R aggett on HTML 4 , 2nd Edition ed. Addison-W esley , Reading, MA. Survey of T echn ologies for Web Application Development · 43 Reill y, D. J . 2000. Inside Server- Base d Applic ations . Mi crosoft Press, Redmond, W A. R olsky, D. and Williams, K. 2003. Emb e dding Perl in HTML wit h Mason . O’Reill y , Cam bri dge, MA. R oman , E. , Ambler, S . , Jewell, T. , Roman, E. , Jewell, T. , an d M a rinescu, F. 2001. Mas- tering Enterprise JavaBe ans , 2nd Edition ed. Wiley , New Y ork, NY. Ship, H. M. L. 2004. T ap estry in A ction . Manning Publications, Greenwic h, CT . Sinha, P. K. 1997. Di stribute d Op er ating Syste ms: Conc epts and Design . IEEE Press, New Y ork, NY. Smith, D. A. , Ka y, A. C. , Ra ab, A. , and Reed, D. P. 2003. Cro quet - a collab oration system arc hitecture. In C5 . IEEE Computer Society , 2–. Stein, L. , Ed. 1998. Oﬃcial Guide to Pr o gr amming with CGI.pm . Wiley , New Y or k, NY. Sun Microsystems, Inc. 2003. Sun O NE Web Server, NSAPI Pr o gr ammers Guide, V ersion 6.1 . Sun Microsystems, Inc. http://doc s- pdf.sun.com/817- 1835- 10/817- 1 835- 10.pdf . Thau, R. 1996. Design considerations for the Apache Server A PI. Computer Networks 28, 7-11, 1113–112 2. Thompson, C. W. , P azan dak, P. , V asudev an, V. , Manola, F. , P almer, M. , Ha nsen, G. , and Bannon, T. J. 1999. Int ermediary architect ure: Inte rp osing mi ddlew are ob ject services b etw een we b clien t and serve r. ACM Computing Surveys 31, 2es, 14. Trauring, A. 2003. Python: Language of c hoice for EAI. EAI Journal , 43–45. Twisted Matrix Lab oratories 2005. The Twiste d A dvantage. Twisted Matri x Lab oratories. http: //twiste dmatrix.com/se rvices/twisted- advantage . Vinoski, S. 2004. Dark matter revisited. IEEE Internet Computing 8, 4, 81–84. W3C . 1997. Inte grating ob ject tec hnology and the W eb. W3C. http://www.w3. org/OOP/ . W3C . 2004a. Document ob ject mo del (DOM) tec hnical reports. W 3C. http://ww w.w3c.org/ DOM/DOMT R . W3C . 2004b. SOAP sp eciﬁcations: Latest SOAP versions. W3C. http://w ww.w3.org/TR/soap/ . W3C . 2005a. Scalable V ector Graphics (svg). W3C. http://www.w3. org/Graphics/SVG/ . W3C . 2005b. Synch ronized multimedia. W3C. http://www.w3.o rg/AudioVideo/ . W ard, S. an d Hostetter, M. 2003. Cur l: A l anguage for web con tent . International Journal of Web Engine ering and T e chnolo gy 1, 1, 41–62. Winer, D. 1999. XM L-RPC speciﬁcation. UserLand Softw are, Inc. http://www.xm lrpc.com/spec . wingS Pro j ect T eam 2005. Welc ome t o wingS . wingS Pro ject T eam. http://wing s.mercatis. de/tiki-index.php . Wu, A. W. , W ang, H. , and Wilkins, D. 2000. Pe rf ormance comparison of alternative sol utions for we b-to-database applications. In Pr o c e e dings of Pr o c e e dings of the Southern Confer enc e on Computing, Hattiesbur g, MS, Oct ob er 26-28, 2000 (SCC 2000) . http://rain. vislab.olemiss. edu/ ~ ww1/Slid e_Show_Images/SCC_Amanda/SCC_Amanda.pdf . Yergeau, F. , Bra y, T. , P aoli, J. , Sperberg-McQueen, C. M. , and Maler, E. 2004. Extensible Markup Language (XML) 1.0 (third edition): W3C recommendation 04 February 2004. W3C Recommendation. http://www. w3c.org/TR/2004/REC- xml- 20040204/ . Zeldman, J. 2003. Designing with Web St andar ds . New Riders, Indianap ol is, IN. Mo d e l Controller View User input actions State change notifications State cha n g e s User requests User interface updates State queries View selection

Survey of Technologies for Web Application Development

Original Paper

Comments & Academic Discussion

Leave a Comment

Original Paper

Related Papers

Comments & Academic Discussion

Leave a Comment