Web Application any application which is using HTTP as carrier -- mostly using a web browser (with or without client-side programs) Proxy gateway between 'inside' and 'outside' -- HTTP on both ends can be used for annotation, filtering -- special form: caches Proxy Caches security enforcement point: filtering and control on the HTTP level bandwidth need reduction: cache stores documents according to the document metadata (expiry, ...) -- delivers it locally as long as it is not stale Squid Web Gateway gateway between HTTP on one side and some other protocol on the other -- has to mediate between conceptual differences usually formats content into HTML on the HTTP side LDAP gateway CVS browser Stateless Web Gateway maintains no state itself (e.g. logging into a server, making a query, logging out again) expensive and wasteful for some databases Stateful Web Gateway maintains the state on behalf of the client (e.g. logging into LDAP server) back button on browsers -> what does that mean? -- client caches -> users sees wrong information, next request may confuse the gateway -- interuption of requests -> how does the gateway recover? -- user abandons service -> when does session time out? Web Application Programming implementing a particular application in a client/server scenario common denominator is the HTTP protocol and mostly HTML FORMs started with CGI programming -- many application infrastructures have been developed over the years Application protocol defined by the application developer -- uses some low-level protocol for communication -- THIS IS NOT HTTP!!! message format -- openess, adhoc vs standards -- serialisation (marshalling, encoding), error handling has to operate above of HTTP -- HTTP is stateless -> applications need to maintain state shared between client and server -> cookies shopping basket -- login/logout Application Protocol Engine part of application software to deal with network messages -- usually provided as an API to the application connect, disconnect, wait_for_message, send_message, ... Client-Server, C/S Architecture client side deals with one part of an application, server with the other -- connected via a network separation depends on the consistency requirements of the particular application examples: X, Citrix (visualisation), HTTP, RPC, ... WWW browser/client interacts with (human) user, requests documents from a HTTP server, presentation aspects document presentation HTML, CSS, WML, Applets, ... document presentation logic DHTML (DOM + JavaScript) Thick client web browser on a PC with much technology on board (JVM, Flash, JavaScript, ...) -- good bandwidth Thin client web browser behind limited bandwidth and with limited hardware resources Handhelds, mobiles WWW server serves documents via HTTP communication tier 1-tier model tightly integrated solution -- everything in one N-tier model separation of concerns data stored in 'pure' form at backend -- application servers provides business logic -- presentation tier either at server or client Client-side Web Programming application (or part thereof) is executed on the client side -- mostly for presentation, sometimes also business logic very fast execution -- no server request necessary only for trivial cases -- mostly server has to full knowledge (according to the business model) -- client software is not under the control of developers -- new browser may behave differently -- security problem with a language may force users to turn technology off -- have to use often different technology on the server (heterogenous development) form validation -- problem: full data consistency can only determined on the server games -- problem: no decent graphical output, slow, source code can be read pull-down menues -- problem: everyone does it differently -- new GUI paradigms everywhere -- how does user know what to do? animations -- problem: very few applications involve animations natively -- mostly 'gadgets' from web developers who should know better DOM manipulation -- hide/show parts of the document, move things around, create new options in FORMs, ... -- useful if used very carefully -- problem: not all browsers support all DOM levels, developer's nightmare XML transformation -- problem: who - seriously - ships original XML data to the client? Visual Basic, VBScript Microsoft supported programming language -- only runs on Windows platform JavaScript procedural programming language -- similar to Java (yeah) JavaScript as Client Language most browsers support it now -- smaller, but annoying differences to JScript does not come with a security model -- early implementations had a lot of vulnerabilities can be used together with DOM (Document Object Model) to access the page content JScript Microsoft's version of JavaScript Dynamic HTML actually JavaScript + DOM embedding code into HTML pages which can access the structure and the content of the page -- reading and modifying -- mainly for rendering effects (fading, moving, resizing) Java Programming Language invented by Sun Microsystem -- meant for 'consumer devices' -- James Gosling: 'Oak' -- very slow in the early years -- write once, test everywhere -- now very efficient compilation Java as Client Language most browsers support it now -- language now stable -- most machines powerful enough still not too many applications for it -- only in particular niches comes with a security model -- only particular commands can be executed -- protects file system and restricts network access Active-X highly proprietary, single platform technology, highly insecure Active X as Client Language only works on Windows platform -- major security concerns -- signed (certified) Active-X controls maybe make more sense in controlled environments Server-side Web Programming using an application server infrastructure and a programming language -- server executes scripts/programs can be in a variety of solutions and languages: Perl/CGI, Java/J2EE, VB/ASP, Python/Zope, Java/WebObjects, .... PHP infrastructure and web programming language to deliver server-generated documents embed PHP commands into an HTML page: <? echo "Rumsti was here" ?> -- syntax similar to C/Java/Perl very broad user base -- runs on many platforms (UNIX, Windows, ...) -- very fast processing -- very rich libraries (various databases, HTTP, IMAP, SNMP, ...) despite recent efforts PHP is no 'real' programming language -- mainly for web pages -> makes it difficult to do background processing -- XML support still lagging behind Java Servlets writing code to handle GET or POST requests -- application only deals with request, response and context object -- rest is done by the servlet engine servlet is put into a 'container' has support for cookies, session handling only works for Java (and Perl/Wombat) -- javax.servlet portable code (Java) -- specification open -- rather performant (modulo Java) -- runs directly in the server (no separate process) -- stays in memory between requests -- sandboxing is possible (security) Tomcat Apache, iPlanet Web Server, Microsoft IIS, BEA WebLogic Application Server, IBM WebSphere, et.al. Java Server Pages embedding Java Code into HTML pages -- or just invoking Java Beans (components) from the page technically based on servlets which parse the page, compile it and run it at every request CGI, Common Gateway Interface dinosaur of all server-side methods -- still in heavy use -- language independent -- many servers have it implemented mostly used with Perl rather slow compared to other methods -- server has to exec process for every request interface describes how FORM content is passed into the script/program and how content is passed back to the server all functionality handled in the script, no server-side functionality easy to deploy for simple applications -- isolated processes -- architecture independent -- open standard -- language independent code difficult to maintainability NSAPI, Netscape Server API mechanism for extending the functionality of the Netscape servers low-level: good for high-security and high-performance currently in version 3.x -- C++ library -- supported by Netscape servers (Communication, Commerce, Proxy) -- on several platforms SSI, server side include started as simple mechanism to include files (HTML snippets) -- executed before content is shipped to the client features added: simple database access -- simple program execution -- simple program logic (if-then) performance at earlier implementations -- hiding commands in HTML comments? -- security: how to protect files on the server -- not a full programming language -- difficult to maintain not standardized, security concerns, dead-end technology J2EE rich infrastructure for Java applications -- more for high-profile web-apps -- platform neutral, but only for Java has support for session handling -- authentication -- security developed by Sun Microsystems has many implementations: Tomcat/Apache, Masslight, JBoss, WebLogic, Sun, .... ASP, Active Server Pages Microsoft technology -- now obsoleted by ASP.NET ASP.NET Mason Perl-based templating system -- applying templates automatically -- supports session handling -- persistent database connections -- server-side caching -- component based XML Application Server XML pipelines -- very flexible way to publish content in various ways AxKit application development environment for Perl, using XML, XSLT and XPathScript to convert content in pipelines use of taglibs for application specific functionality Cocoon application development environment for Java, using XML, XSLT and XPathScript to convert content in pipelines Zope Python-based infrastructure and web programming language to deliver server-generated documents object-oriented by design -- oo programming -- oo database can import 'packages' which implement specific object classes or whole applications