e-Science e-Business e-Government and their Technologies Introduction to Web Applications

1
e-Science e-Business e-Government and their
TechnologiesIntroduction to Web Applications

• Bryan Carpenter, Geoffrey Fox, Marlon Pierce
• Pervasive Technology Laboratories
• Indiana University Bloomington IN 47404
• January 12 2004
• dbcarpen_at_indiana.edu
• gcf_at_indiana.edu
• mpierce_at_cs.indiana.edu
• http//www.grid2004.org/spring2004

2
Contents of this Lecture Set

• Introduction Web applications and interfaces.
• The Tomcat Web server.
• Java Servlets and HTTP.
• JavaServer Pages
• Deploying a JSP-based Web application.

3
Web Applications

• We consider a Web Application to be a set of
  related programs and resources embedded in, or
  accessed through, a Web server.
• The whole application may be made available as a
  single archive file, ready for immediate
  deployment in a Web server.
• One can identify two broad kinds of Web
  application
• Presentation oriented, built around dynamic HTML
  pages.
• Service oriented, in which a Web Service is made
  available to other applications through XML and
  HTTP protocols.
• In this section we will be most interested in
  presentation oriented Web Applications.
• Web services will be discussed at length in later
  sections. Note they commonly make use of some of
  the same technologies we discuss here (e.g.
  Servlets).

4
Web Interfaces

• As a matter of common experience, todays Web is
  much more than a collection of static HTML
  documents.
• We are all accustomed to Web sites that react in
  complex ways to requests and queries submitted
  through browsers.
• Many technologies have been introduced to
  facilitate this interactivity.
• One basic idea has been around since the earliest
  days of the Web, and has come through relatively
  unscathed, is dynamic generation of HTML.

5
Requesting a Static HTML Document
Server
HTTP Request
GET /index.html HTTP/1.0 User-Agent Mozilla/4.51
en... Host sirah.csit.fsu.edu8080 Accept
image/gif, ..., / ...
lthtmlgt ltheadgtlt/headgt ltbodygt lt/htmlgt
HTTP/1.1 200 OK Content-type
text/html lthtmlgt ltheadgt...lt/headgt ltbodygt ... lt/ht
mlgt
Static HTML files
Client
HTTP Response
6
Dynamic Generation of HTML
Server
HTTP Request
GET /hello.pl?whobryan HTTP/1.0 User-Agent
Mozilla/4.51 en... Host sirah.csit.fsu.edu8080
Accept image/gif, ..., / ...
!/usr/bin/perl name param(who) print
Content-type text/html\n\n print
lthtmlgtltbodygtHello name!lt/bodygtlt/htmlgt\n
Script, or method
HTTP/1.1 200 OK Content-type
text/html lthtmlgt ltbodygt Hello bryan! lt/bodygtlt/html
gt
HTTP Response
Client
7
Server-side Frameworks

• First briefly describe four general frameworks
  for dynamic generation of HTML
• 1. CGI
• 2. Java Servlets
• 3. Microsoft Active Server Pages (ASP)
• 4. JavaServer Pages (JSP)
• All these technologies require some browser-side
  mechanisms to get responses from the client
• Typically HTML forms, and/or Javascript.
• But use of HTTP and HTML means that the
  browser-side mechanisms are quite well-separated
  from the server-side issues.

8
1. CGI

• The earliest technique for responding dynamically
  to browser input was CGI Common Gateway
  Interface.
• The FORM element of some HTML document contains
  input fields.
• Inputted data is read by browser, forwarded to
  server in a GET or POST request.
• The URL in the action attribute of the HTML form
  identifies an executable file somewhere in the
  Web Servers document hierarchy.
• On the server side, the Web server is configured
  to execute this program when it receives the HTTP
  request created by submitting the form.

9
Action of a CGI Script

• The executable file may be written in any
  language. Here we assume it is written in Perl.
• The Web Server program will invoke the CGI
  script, and pass it the form data, either through
  environment variables or by piping data to
  standard input of the script.
• In modern Perl you can use the CGI module to hide
  many of these detailsespecially extracting form
  parameters.
• The CGI script generates a response to the form,
  on its standard output. This is piped to the Web
  server, which returns it to the browser.
• The response will be the text of a dynamically
  generated HTML document, preceded by some HTTP
  headers.

10
CGI example

• The form element in the initial HTML document is
  as follows
• ltform actionhttp//server-name/cgi-bin/hello.pl
  gt
• Name ltinput typetext namewho
  size32gt ltpgt
• ltinput typesubmitgt
• lt/formgt
• The CGI script hello.pl is
• !/usr/bin/perl
• use CGI qw( standard)
• name param(who)
• print Content-type text/html\n\n
• print lthtmlgtltbodygtlth1gtHello name!lt/h1gtlt/bodygtlt/h
  tmlgt\n

11
2. Java Servlets

• In conventional CGI, a Web site developer writes
  an executable program that processes a forms
  input. The program (or script) must be executed
  every time a form is submitted.
• Servlets provide a more modern, Java-centric
  approach.
• The server incorporates a Java Virtual Machine,
  which is running continuously.
• Execution of a CGI script is replaced invocation
  of a method on a servlet object.
• This is typically much cheaper than starting a
  whole new program.

12
A Hello Servlet

• import java.io.
• import javax.servlet.
• import javax.servlet.http.
• public class Hello extends HttpServlet
• public void doGet(HttpServletRequest
  request,
• 
  HttpServletResponse response)
• throws
  IOException, ServletException
• response.setContentType(text/html)
• PrintWriter out response.getWriter()
  
• out.println(lthtmlgtltbodygt)
• out.println(Hello
  request.getParameter(who) !)
• out.println(lt/htmlgtlt/bodygt)

13
Remarks

• HttpServlet is the base class for servlets
  running in HTTP servers.
• The URL in the action attribute of the form might
  be something like
• http//server-name/examples/servlet/Hello
• The doGet() method is called in response to an
  HTTP GET request directed at the servlet.
• As the names suggest, the request object
  describes the browsers request, and the response
  object describes and the servlets response.
• Servlet code is very flexible, but verbose.

14
3. Microsoft ASP

• Microsoft independently addressed the performance
  issues of CGI, through ISAPI (Internet Server
  Application Programming Interface).
• Comparable to Java Servlets an HTTP request for
  a dynamic page triggers a DLL call within the
  running server process, rather than execution of
  a program.
• One application of ISAPI that has become
  important is the library ASP.DLLActive Server
  Pages.
• An ASP page looks basically like an HTML
  document, but includes inserts of CGI-like code.
• Effectively turns CGI inside out.
• Scripting language for the inserts typically
  Visual Basic, though other languages are possible.

15
ASP Example

• lt_at_ LANGUAGEVBSCRIPT gt
• ltHTMLgt
• ltHEADgtltTITLEgtSample ASPlt/TITLEgtlt/HEADgt
• ltBODYgt
• Welcome. It is now approximately lt Time()
  gt.ltBRgt
• Some simple text formatting using server-side
  code
• lt
• For intCounter 1 to 5
• gt
• ltFONT SIZE lt intCounter gtgt Hello lt/FONTgtltBRgt
• lt
• Next
• gt
• lt/BODYgt
• lt/HTMLgt

16
Remarks

• The basic structure of the document looks like a
  static HTML documents, with some special inserts.
• It includes processing directives (e.g. LANGUAGE)
  in lt_at_gt brackets.
• Server-side VB inserts appear in ltgt brackets.
• ltexpressiongt is shorthand for
• Response.Write expression
• comparable with out.println(expression) in
  Servlets.
• Response is one of a number of predefined objects
  available in scripting inserts.
• We will get very familiar with this syntax later,
  because JavaServer Pages steals it, almost
  verbatim!

17
4. JavaServer Pages

• JavaServer Pages (JSP) allow special tags and
  Java code to be embedded in HTML files. These
  tags and code are processed by the Web server to
  dynamically produce standard HTML.
• Produce dynamic Web pages on the server side
  (like Servlets), but separate application logic
  from the appearance of the page.
• The tags allow previously compiled Java
  components, in the form of JavaBeans, to be used.
• One can also define custom tag libraries.
• May produce XML documents, instead of HTML.
• JavaServer Pages were developed as a response to
  ASP.
• Built on top of Java Servlets, and use many of
  the same utility classes.

18
JSP elements

• A JSP page looks like standard HTML or XML, with
  extra elements processed by the JSP container.
• Typically, these elements create text that is
  inserted into the resulting document.
• JSP elements include
• Scriptlet enclosed in lt and gt markers a small
  script in Java to perform arbitrary functions.
• Expression anything between lt and gt markers
  is evaluated by the JSP engine as a Java
  expression.
• JSP directive enclosed in lt_at_ and gt
  markerspasses information to the JSP engine
  (guide compilation).
• JSP actions or tags are a set of customizable,
  XML-style tags for particular actions, e.g.
  predefine jspuseBean instantiates a Java Bean
  class on the server.

19
3 Tier Architecture
URL
JSP page
request
HTTP request
JavaBean Library
JSP container compiles to a servlet
properties, call methods
response
HTTP response
DB
HTTP page
Web server
Browser
20
Hello Servlet Revisited

• import java.io.
• import javax.servlet.
• import javax.servlet.http.
• public class Hello extends HttpServlet
• public void doGet(HttpServletRequest
  request,
• 
  HttpServletResponse response)
• throws
  IOException, ServletException
• response.setContentType(text/html)
• PrintWriter out response.getWriter()
  
• out.println(lthtmlgtltbodygt)
• out.println(Hello
  request.getParameter(who) !)
• out.println(lt/htmlgtlt/bodygt)

21
An Equivalent JSP Page

• lthtmlgt ltbodygt
• Hello lt request.getParameter(who) gt !
• lt/bodygt lt/htmlgt

22
Remarks

• A suitable form element to front-end this page
  might be
• ltform actionhello.jspgt
• Name ltinput typetext namewho size32gt
  ltpgt
• ltinput typesubmitgt
• lt/formgt
• The JSP version is much more compact and easier
  to understand!
• We can expect this to be generally the case when
  the logic behind a dynamic page is relatively
  simple, and the bulk of the content is static
  HTML.

23
References

• Web Development with JavaServer Pages, Duane K.
  Fields and Mark A. Kolb, Manning Publications,
  2000.
• Thorough, insightful.
• Core JSP, Damon Houghland and Aaron Tavistock,
  Prentice Hall, 2001.
• Some imaginative examples. Good section on JSP
  and XML.
• JavaServer Pages, 3rd ed, Hans Bergsten,
  OReilly, 2004.
• Core Servlets and JavaServer Pages, Marty Hall,
  Prentice Hall, 2000.
• Useful reference for Servlets, especially.
• JavaServer Pages, v2, and other documents, at
• http//java.sun.com/products/jsp/

24
Getting Started with Tomcat
25
Server Software

• Standard Web servers typically need some
  additional software to allow them to run Servlets
  and JSPa so-called Servlet Container.
• There are commercial products e.g.
• New Atlanta ServletExec (www.newatlanta.com)
• Macromedia Jrun (www.macromedia.jrun/software/jrun
  )
• For this course you will be expected to use
• Apache Tomcat (http//jakarta.apache.org/tomcat)
• The official reference implementation for the
  Servlet 2.4 and JSP 2 specifications.
• Can be used as a small, standalone Web server, or
  as a servlet container for Apache, IIS, iPlanet,
  etc serverslook under JK in the Tomcat
  documentation.

26
Tomcat

• Tomcat is an open source Web Server, implemented
  entirely in Java.
• It can be used to serve ordinary static Web
  content (HTML, etc), but its main claim to fame
  is as the reference implementation of the Servlet
  and JSP specifications.
• For purposes of coursework you should download
  and install Tomcat on a computer available to
  you.
• Any PC running Windows (for example) should
  suffice.
• For debugging class projects, you can access your
  server through localhost URLs, so you dont need
  a registered domain name (or even an Internet
  connection).

27
Downloading Tomcat 5

• I will give instructions for installing Tomcat 5
  under Windows (details for Windows XP).
• You can also easily install on Linux, or other
  UNIX flavor. If you choose to work on a shared
  UNIX machine, be aware that you may have adjust
  your port number to avoid clashing with servers
  run by other users.
• I assume Java is already installed on your
  computer (preferably Sun J2SE 1.4 or later).
• Go to http//jakarta.apache.org/tomcat/
• Follow the Binaries link for download, and
  scroll down to Tomcat 5 archives and installers.
• Get the installer for Windows at the time of
  this writing the file was called
  jakarta-tomcat-5.0.18.exe.
• Size of the file was about 10MB.

28
Installation

• Run the installer. On the installation wizard,
  click through, accepting the Apache License
  agreement.
• In the instructions that follow I assume you
  accept the default installation options, so the
  install location will probably be
• C\Program Files\Apache Software
  Foundation\Tomcat 5.0
• You will need about 40MB of free disk space.
• I also assume that you accept the default port
  number for Tomcat, which is 8080.
• You may choose 80, if there is no other Web
  server running on the computer, but I will assume
  the 8080 default.
• You may take the opportunity to set a good admin
  password for the Web server.
• You will also be prompted for the name of the
  folder where Java is installed, but the wizard
  usually makes a good guess.

29
Running the Server

• By default on Windows the server will start
  automatically when installation completes. You
  should see a progress window like

• When startup completes this window disappears,
  and you will probably see an icon like this in
  your taskbar

• If things dont happen exactly like this, dont
  panic! There are several different ways to
  start and stop the server, discussed shortly.

30
Check Your Server is Up

• If you are running Tomcat on your local PC, point
  your Web browser at
• 
  http//localhost8080
• If you are running your web server on a remote
  host called hostname, point your browser at
• 
  http//hostname8080
• You should see the default Tomcat home page,
  which contains some useful documentation

31
Restarting the Server

• This is a seemingly trivial skill that needs to
  be properly mastered!
• You will find that restarting the server is a
  vital part of the debugging cycle for Web
  applications if you think you restarted the
  server, but it didnt really restart, you can go
  down frustrating blind alleys of debugging.
• There are at least 3 mechanisms for starting and
  stopping the server under Windows.

32
Stopping and Starting the Server

• Three ways
• To Start use the shortcut you find under
• start?All Programs?Apache Tomcat 5.0
• To Stop right-mouse-click on Tomcat icon that
  appears on the taskbar, and select Shutdown.
• Use the Windows Services tool that you may find
  through the Windows Management console or perhaps
  through start?Control Panel?Administrative
  Tools?Services
• This gives a convenient way to start, stop, or
  restart services, including Tomcat.
• From a Windows Command Prompt, run the batch
  files startup.bat, shutdown.bat which you will
  find in bin\ under the installation folder,
  typically
• C\Program Files\Apache Software
  Foundation\Tomcat 5.0\bin\

33
Tips for Restarting

• Choose one of the approaches on the previous
  slide mixing one approach to starting with
  another for stopping isnt likely to work
  properly!
• Approach 1 is perhaps the most natural under
  Windows, but for me it seemed error-prone.
• Approach 2 seems OK. Approach 3 is robust
  because it displays a console window while the
  server is running, so you know for sure whether
  the server is up or down.
• Until you are confident you have this mastered,
  regularly check whether or not the server is
  running by
• clearing your browser cache (Tools?Internet
  Options?Delete Files under IE 6), then
• (for added assurance) restarting your browser,
  then
• trying to visit the URL http//localhost8080

34
Using Linux

• Tomcat runs very well under Linux. Follow the
  instructions in the Tomcat documentation for
  installation.
• To start or stop the server, use the scripts
  startup.sh, shutdown.sh in the Tomcat
  installation bin/ directory.

35
A First Web Application

• As a toy example, we will deploy the trivial
  Hello World of dynamic HTML.
• We create a Web Application that consists of one
  static HTML document with a form prompting for
  the visitors name, and a dynamic JSP document
  that displays a customized greeting for that
  visitor.

36
Preparing a folder

• Under Tomcat, each web application should be
  created in a dedicated folder, normally created
  under the folder called webapps\ in the server
  installation directory.
• First I make a folder
• C\Program Files\Apache Software
  Foundation\Tomcat 5.0\webapps\grid04hello\
• Within the new folder I must create a nested
  folder called WEB-INF\.
• For now the subfolder can be empty. But without
  a grid04hello\WEB-INF\, Tomcat 5 will not
  automatically recognize grid04hello\ as a web
  application folder!

37
A Hello Web Application

• In the grid04hello/ folder I create the two files
  index.html
• lthtmlgt
• ltbodygt
• ltform methodget actionhello.jspgt
  
• Name ltinput typetext
  namewho size32/gt ltp/gt
• ltinput typesubmit/gt
• lt/formgt
• lt/bodygt
• lt/htmlgt
• and hello.jsp
• lthtmlgt
• ltbodygt
• Hello lt request.getParameter(who)
  gt !
• lt/bodygt
• lt/htmlgt

38
Files and Folders

• Tomcat 5.0\
• webapps\
• grid04hello\
• hello.html
• hello.jsp
• WEB-INF\
• currently empty
• other Web applications
• Tomcat server code, configuration, logs,
  etc

39
Starting the Web Application

• To start the Web application (i.e. to get it
  loaded into your server) you just need to restart
  your Tomcat server.
• If you are developing a simple Web application
  like the one here, using only HTML and JSP files,
  you dont usually need to restart more than once.
  A running server will recognize when deployed
  JSP files are edited, and recompile them
  automatically. But you do have to restart the
  server to get the new application recognized
  initially (later we describe an alternative way
  to deploy the application).

40
Using the Web Application

• Visiting http//localhost8080/grid04hello/hello.h
  tml, I should see something like

• On entering my name, and hitting submit, I see

41
The Rest of this Section

• We discuss Java Servlets in some detail. For
  presentation-oriented Web Applications JSP is
  usually more convenient. But JSP and other Java
  Web technologies are built on top of Servlets,
  and you will need some knowledge of the Servlet
  classes to use JSP effectively.
• We cover writing Web Applications with JSP.
• We will also say something about managing Tomcat.
• General organization of Servlet-based Web
  applications.

42
Java Servlets
43
Servlets

• At its most abstract, a Java Servlet is a Java
  class that can be embedded in a some
  general-purpose server program. A subset of
  requests arriving at the serverpresumably those
  matching some selection criterionwill be
  redirected to the servlet for special handling.
• Although servlets are supposedly deployable in
  various kinds of servers (HTTP, Databases, FTP,
  ?), we will only be interested in HTTP servlets,
  embedded in Web servers.
• Most commonly a servlet is responsible for
  handling HTTP GET or POST requests, directed at a
  particular URL.

44
Contents of this Section

• Introduction
• Review of HTTP features.
• Simple servlet.
• Servlet deployment issues.
• Servlet programming.
• Form processing with Servlets.
• Servlet Life Cycle.
• Generating responses.
• Cookies and session-tracking.

45
References

• Core Servlets and JavaServer Pages, Marty Hall,
  Prentice Hall, 2000.
• Good coverage, with some discussion of the Tomcat
  server.
• There is a 2001 sequel called More Servlets and
  JavaServerPages.
• Java Servlet Programming, 2nd Edition, Jason
  Hunter and William Grawford, OReilly, 2001.
• Havent seen second edition, but 1st ed (1998)
  was good, with some good examples.
• Java Servlet Specification, v2.4, and other
  documents, at
• http//java.sun.com/products/servlet/

46
The HTTP Protocol

• We begin by reviewing some essential features of
  Hyper Text Transfer Protocol.
• HTTP is a textual, client-server protocol,
  consisting of requests and responses.
• It is commonly implemented over TCP, though other
  underlying protocols are possible.
• e.g. some handheld devices implement the most
  important parts of HTTP, but not general IP
  protocols.
• Like many W3C documents, the detailed
  specification is bizarrely complex, but the most
  important ideas are very simple.

47
A GET Request

• When one points Internet Explorer 6 (say) at a
  URL like
• http//www.grid2004.org/index.ht
  ml,
• the HTTP request sent to the server may look
  something like
• GET /index.html HTTP/1.1
• Accept image/gif, image/x-xbitmap, image/jpeg,
  image/pjpeg, application/vnd.ms-excel,
  application/vnd.ms-powerpoint, application/msword,
  /
• Accept-Language en-us
• Accept-Encoding gzip, deflate
• User-Agent Mozilla/4.0 (compatible MSIE 6.0
  Windows NT 5.1)
• Host www.grid2004.org
• Connection Keep-Alive
• Exercise adapt the Simple Server program,
  outlined early in the section on Java sockets, to
  print out the HTTP request it receives. Confirm
  the format above by pointing a browser at your
  server.

48
Anatomy of an HTTP Request

• If you are not very familiar with the HTTP
  protocol, study the format of this request. The
  individual lines here are called headers. Even
  without prior knowledge you may be able to guess
  the meaning of many of the headers.
• After the headers, there is a blank linenot
  obvious on the previous slide, but important to a
  well-formed request.

49
POST Requests

• Another common HTTP request is the POST request.
• In ordinary Web browsing this is commonly used to
  send some data to the server, submitted using an
  HTML form.
• In this context the data might include values of
  fields typed directly into the browser window,
  and uploaded contents of local files, selected
  through a form.
• The format is very similar to GET, except that
  the first word in the method header is POST,
  and the blank line terminating the headers is
  followed by the posted data.
• The following example was generated by submitting
  a form. Note two extra headers Content-length
  and Cache-control. The posted data is simply
  whoBryan.

50
An Example POST Request

• POST /handleform HTTP/1.1
• Accept image/gif, image/x-xbitmap, image/jpeg,
  image/pjpeg, application/vnd.ms-excel,
  application/vnd.ms-powerpoint, application/msword,
  /
• Accept-Language en-us
• Accept-Encoding gzip, deflate
• User-Agent Mozilla/4.0 (compatible MSIE 6.0
  Windows NT 5.1)
• Host www.grid2004.org
• Content-Length 9
• Connection Keep-Alive
• Cache-Control no-cache
• whoBryan

51
The HTTP Response

• A typical HTTP response has a format similar to
  the HTTP post request a series of headers, a
  blank line, then the returned data.
• The returned data may for example be an HTML
  page.
• The first header now gives an error status for
  the request a status code of 200 indicates
  success.
• The following response could be generated by the
  server when the course home page is requested.
• Exercise compile and run the TrivialBrowser
  class, given early in the section on Java
  sockets. You should see something similar to the
  contents of the next slide.

52
Example HTTP Response

• HTTP/1.1 200 OK
• Date Fri, 06 Feb 2004 013456 GMT
• Server Apache/1.3.29 (Unix) PHP/4.3.4
• Last-Modified Thu, 29 Jan 2004 222725 GMT
• ETag "832b65-2cf-401988cd"
• Accept-Ranges bytes
• Content-Length 719
• Content-Type text/html
• lt!DOCTYPE HTML PUBLIC gt
• ltHTMLgt
• ltHEADgt
• ltTITLEgte-Science e-Business e-Government and
  their Technologieslt/TITLEgt
• lt/HTMLgt

53
The HttpServlet class

• Having reviewed some essential features of HTTP,
  we are ready to start describing servlets.
• Every HTTP servlet will extend the base class
  HTTPServlet, which is defined in the package
  javax.servlet.http.
• This class defines a series of request-handling
  methods
• doGet() Handle HTTP GET
  request.
• doPost() Handle HTTP POST
  request.
• doPut() Handle HTTP PUT
  request.
• doDelete() Handle HTTP DELETE
  request.
• doOptions() Handle HTTP OPTIONS
  request.
• doTrace() Handle HTTP TRACE
  request.
• When you define a new servlet class, you normally
  override one or more of these methods.

54
A Hello World Servlet

• import java.io.
• import javax.servlet.
• import javax.servlet.http.
• public class Hello extends HttpServlet
• public void doGet(HttpServletRequest
  request,
• 
  HttpServletResponse response)
• throws
  IOException, ServletException
• response.setContentType(text/html)
• PrintWriter out response.getWriter()
  
• out.println(lthtmlgtltbodygt)
• out.println(lth1gtHello World!lt/h1gt)
  
• out.println(lt/htmlgtlt/bodygt)

55
A Request Handling Method

• All HttpServlet request-handling methods
  (doGet(), doPost(), etc) have a similar
  interface.
• They are passed parameters of type
  HttpServletRequest, HttpServletResponse
• Needless to say, these are Java objects
  representing the HTTP request and response.
• The request and response objects have methods for
  accessing the headers, the data payload, and
  other properties of the HTTP messages.
• In the example, the first line of doGet() sets
  the Content-Type header of the response, and the
  remaining lines write the data payloada short
  HTML documentto the response.
• The servlet container can complete most headers
  in the response, but setting the Content-Type
  header is mandatory.

56
Deploying Servlets

• At the end of the section introducing Tomcat, we
  deployed a trivial Web app using a JSP page.
• We nested a folder in webapps/ for our
  applications, and also created an empty subfolder
  called WEB-INF/.
• In general the WEB-INF/ folder of an application
  holds associated classes and XML descriptors.
• In particular servlet class files and the
  deployment descriptor (web.xml file) go in the
  WEB-INF/ folder.
• In the following example we recycle the
  grid04hello/ folder created earlier.

57
Files and Folders

• Tomcat 5.0\
• webapps\
• grid04hello\
• HTML and JSP files
• WEB-INF\
• web.xml
• classes\
• Hello.class
• other Web applications
• Tomcat server code, configuration, logs,
  etc

58
Compiling the Servlet

• The servlet source should be contained in a file
  Hello.java.
• You can conveniently put the source itself in the
  classes\ subfolder of WEB-INF\, and compile it
  in situ.
• Or compile the source wherever you like, and just
  copy the class file to classes\.

59
Setting the Class Path

• If you are using javac from a command prompt, you
  must add the servlet classes to the class path,
  so the compiler knows where to find them.
• e.g. click to
• start?Control Panel?System?Advanced?Env
  ironment Variables
• and define new system variables
• TOMCAT_HOME c\Program Files\Apache Software
  Foundation\Tomcat 5.0
• CLASSPATH .TOMCAT_HOME\common\lib\ser
  vlet-api.jar
• If you are using an IDE like JBuilder, there will
  probably be built-in support for developing
  servlets. You may not have to worry about these
  details.

60
The Deployment Descriptor

• Tomcat 5 apparently requires a deployment
  descriptor mentioning every servlet class in the
  Web application.
• Create a file web.xml in the WEB-INF\ foldera
  minimal descriptor for our servlet is given on
  the next slide.
• Dont worry if this doesnt make much sense to
  youwe will cover XML shortly. You may copy the
  example web.xml file from
• Tomcat 5/servlets-examples/WEB-INF/web.x
  ml
• and edit it appropriately.
• The important parts are the ltservletgt and
  ltservlet-mappinggt elements, which define the
  servlet class and the URL it is found at.

61
Minimal web.xml File

• lt?xml version"1.0" encoding"ISO-8859-1"?gt
• lt!DOCTYPE web-app
• PUBLIC "-//Sun Microsystems, Inc.//DTD Web
  Application 2.3//EN"
• "http//java.sun.com/dtd/web-app_2_3.dtd"gt
• ltweb-appgt
• ltdisplay-namegtgrid2004 Hello
  exampleslt/display-namegt
• ltdescriptiongtgrid2004 Hello
  examples.lt/descriptiongt
• ltservletgt
• ltservlet-namegtHellolt/servlet-namegt
• ltservlet-classgtHellolt/servlet-classgt
• lt/servletgt
• ltservlet-mappinggt
• ltservlet-namegtHellolt/servlet-namegt
• lturl-patterngt/servlet/Hellolt/url-patterngt
• lt/servlet-mappinggt
• lt/web-appgt

62
Viewing the Servlet

• Restart your Tomcat server.
• Visit the URL
• http//localhost8080/grid04hello/servlet/
  Hello
• You should see something like

63
Servlets vs JSP

• Compared with our earlier Hello Web JSP
  application, you will notice that writing and
  deploying a Java servlet is much more work.
• This isnt surprising, because JSP is a higher
  level application layered on servlets.
• If you are building an application around dynamic
  HTML, it will nearly always be preferable to use
  JSP.
• But it is important to know something about raw
  servlets, because eventually you will want to
  implement HTTP applications (e.g. Web services)
  that do something other than generate dynamic
  HTML. For these JSP wont help.

64
Servlet Programming
65
Form processing with Servlets

• Assume we have a form in an HTML document like
• ltform methodget
• actionhttp//hostname8080/grid04hello
  /servlet/Hellogt
• Name ltinput typetext namewho size32gt
  ltpgt
• ltinput typesubmitgt
• lt/formgt
• This supposes Tomcat is running on port 8080
  on the host hostname.

66
Getting Form Parameters

• A suitable goGet() method in the Hello servlet
  class would be
• public void doGet(HttpServletRequest request,
• HttpServletResponse
  response)
• throws
  IOException, ServletException
• response.setContentType(text/html)
• PrintWriter out response.getWriter()
• out.println(lthtmlgtltbodygt)
• out.println(Hello request.getParameter(
  who) !)
• out.println(lt/htmlgtlt/bodygt)
• The method getParameter() of HttpServletRequest
  will parse the HTTP request and extract the named
  form parameter (who in this example).
• If a single form parameter has multiple values
  (allowed in HTML), can instead use
  request.getParameterValues(), which returns an
  array.

67
GET vs POST Idempotence

• If the method attribute on the form is GET, the
  form data is appended to the path component of
  the action URL, and sent in an HTTP GET request.
• Be aware browsers may silently retry GET requests
  that apparently failed. Use the GET method only
  for actions that are idempotentactions where
  accidental repeats dont have observable effects
• A Google search for a particular topic is
  effectively idempotent.
• Transferring 1000 from your bank account is not
  idempotent.
• If the method is POST, the URL is not extended
  the form data is sent in the data payload of an
  HTTP POST request.
• Browsers are supposed to prompt before retrying a
  POST request.
• To handle a POST request with a servlet, define
  the doPost() method instead of the doGet()
  method other details are unchanged.

68
URL Encoding

• URL encoding is a method of wrapping up form-data
  in a way that will make a legal URL for a GET
  request.
• The encoded data consists of a sequence of
  namevalue pairs, separated by .
• Spaces in values are replaced by .
• Non-alphanumeric characters are converted to the
  form XX, where XX is a two digit hexadecimal
  code.
• In particular, line breaks in multi-line form
  data (e.g. addresses) become 0D0Athe hex ASCII
  codes for a carriage-return, new-line sequence.
• URL encoding is somewhat redundant for the POST
  method, but it is the default anyway.
• If you are using servlets you usually dont need
  to worry about any of this, because
  getParameter() and related methods do the
  decoding for you.

69
Reading Posted Data

• Where posted data is not simply URL Encoded form
  parameters (e.g. if a file is uploaded, producing
  to posted data in multipart MIME format), the
  data may be read directly
• public void doPost(HttpServletRequest req,
• HttpServletResponse
  resp)
• BufferedReader in new BufferedReader(req.
  getReader())
• String line
• while((line in.readLine()) ! null)
• Dont try to combine reading data using
  getReader() with the higher-level approach using
  getParameter()choose one or the other.

70
Information from Request Headers

• There is a series of convenience methods that
  read information from the request headers,
  including
• getMethod(), getRequestURI(), getProtocol()
• 
  Method header
• getContentLength()
  Content-Length header
• getContentType()
  Content-Type header
• getAuthType(), getRemoteUser()
  Authorization header
• getCookies()
  See later
• getHeader(String name) Any
  HTTP request header
• getHeaders(String name)
  Enumeration of headers
• getHeaderNames()
  Enumeration of header names
• Exercise Study the servlet RequestHeaderExample,
  which comes in the servlet examples in the
  Tomcat release, for an example inspecting request
  headers.

71
Servlet Life Cycle

• By default, a Web server only creates one
  instance of a servlet class for each ltservletgt
  element in the web.xml file.
• All requests to the same URL are handled by the
  same servlet class instance.
• This means that a request may see effects of
  processing earlier requests through values of
  instance variables.
• Or class variables.
• By default, though, each request is handled in a
  different Java thread.
• So mutual exclusion is an issue.

72
A Counter Servlet

• public class Counter extends HttpServlet
• int count 0
• public void doGet(HttpServletRequest
  request,
• 
  HttpServletResponse response)
• throws
  IOException, ServletException
• response.setContentType(text/html)
• PrintWriter out response.getWriter()
  
• out.println(lthtmlgtltheadgtlt/headgtltbodygt
  )
• out.println(This servlet instance has
  been accessed
• (count)
  times)
• out.println( lt/bodygtlt/htmlgt)

73
Remarks

• The first time I point my browser at this servlet
  I get a response page containing the message
• This servlet has been accessed
  0 times
• Each time I reload the URL, the count increases.
• Since count is an instance variable of the class,
  this illustrates the case that only a single
  instance of Counter is created.

74
Mutual Exclusion

• The counter servlet is not completely reliable,
  because it is possible to have concurrent
  requests handled in different threads. The
  instance variable count is shared by threads.
  This could lead to problems of interference.
• For example, the increment of count could be done
  in a synchronized statement
• int myCount
• synchronized(this)
• myCount
  count
• Subsequently the local variable
  myCountwhich is private to the threadis printed
  in the response.

75
The init() Method

• The init() method
• public void init() throws ServletException
  . . .
• is called once when the servlet is created.
  You override it to define initialization code for
  your servlet instance.

76
Initialization Parameters

• A new counter servlet, defining an init() method
• public class InitCounter extends HttpServlet
• int count
• public void init() throws ServletException
  
• ServletConfig config
  getServletConfig()
• try
• count Integer.parseInt(config.
  getInitParameter(initial))
• catch (NumberFormatException e)
• count 0
• definition of doGet() method

77
Defining Initialization Parameters

• In web.xml, I add the element
• ltservletgt
• ltservlet-namegtCounter2lt/servlet-
  namegt
• ltservlet-classgtInitCounterlt/serv
  let-classgt
• ltinit-paramgt
• ltparam-namegtinitiallt/para
  m-namegt
• ltparam-valuegt50lt/param-va
  luegt
• lt/init-paramgt
• lt/servletgt
• If I restart the server and point my browser at
  this servlet I see the (misleading) message
• This servlet has been accessed 50 times

78
Generating Responses

• A minimal server response to a client request
  might be
• HTTP/1.1 200 OK
• Content-Type text/plain
• Hello World!
• We already saw how to set the content type
  explicitly using setContentType().
• In general the content type can be any MIME type
  recognized by the browser.
• A servlet can explicitly set other values by
  using the setStatus() method.

79
Explicitly Returning Status Codes

• Status values are available as predefined
  constants in the HttpServletResponse class, e.g
• final int SC_OK 200
• final int SC_FOUND 302
• final int SC_NOT_FOUND 404
• Use like
• response.setStatus(HttpServletResponse.SC_OK)

80
Common Cases

• There are a couple of convenience methods on
  HttpServletResponse for dealing with common
  cases
• void sendError(int sc, String message)
• send specified status, with generated page
  containing message.
• void sendRedirect(String location)
• send SC_TEMPORARY_REDIRECT status, and include
  Location header.
• By sending the SC_FOUND or SC_TEMPORARY_REDIRECT
  status, together with a dynamically generated
  URL, a servlet can cause a the browser to go
  directly to a different page or site (without the
  user manually clicking another link).

81
Cookies and Session Tracking
82
The Problem

• HTTP is said to be a stateless protocol. It
  consists of a series of request/response
  transactions with no intrinsic association
  between different transactions.
• Stateless protocols have reliability advantages
  recovery from failure, robustness and simplicity
  of protocol implementation.
• Modern HTTP isnt completely stateless by
  default it tries to keep TCP connections open
  between transactions.
• Very often a Web application needs a server to
  engage in an extended dialog with a client,
  involving a series of requests and responses.
• So the problem is how to define and keep track of
  a particular session between client and Web
  server.
• This is called session tracking.

83
Example

• Classic example of session information is the
  contents of a customers shopping cart, at an
  online store.
• Typically the shopping carts of all customers
  actively browsing a site will be stored on the
  server side (e.g. in data structures managed by a
  servlet).
• But every HTTP request coming from a customer
  must somehow be tagged with information
  correlating the transaction with a particular
  session.
• When a customer chooses a new item, the server
  needs a nugget of identifying information, to
  decide which shopping cart the new item should go
  in.

84
Basic Approaches

• Practical approaches to attaching session
  information to transactions include
• URL-Rewriting (fat URLs)
• Assumes all pages associated with the session
  are dynamically generated by the server. Session
  identification is directly appended to any URLs
  in the generated pages that refer back to the
  same server.
• Cookies
• An extension to HTTP that lets a Web server
  ask a browser to store small amount of
  identifying information. The browser returns
  this information in subsequent HTTP request
  headers, when it revisits the same server.
• We will focus on use of cookies, because they
  provide the most flexibility, and they are used
  almost universally today.

85
Cookies

• If a browser receives an HTTP response including
  a Set-Cookie header (and is willing to take the
  cookie) it stores the information in the header.
• This information can either be stored in the
  memory of the browser process (session cookie)
  or saved to disk (persistent cookie).
• Whenever a browser constructs an HTTP request for
  a server, it checks whether it is storing any
  cookies it previously received from the server.
• If so, it returns the cookie information in a
  Cookie header attached to the new request.

86
Uses of Cookies

• Recognizing a regular customer
• A persistent cookie can save some identification
  information for a particular customer. The
  stored information could be actual name or
  details, but more likely some opaque key into a
  database on the server.
• Session Tracking
• Within a single dialog with a site, session
  cookies can be used as the underlying mechanism
  for session tracking.
• The first application is limited, because many
  people configure their browsers to reject
  persistent cookies, regarding them as an
  intrusion of privacy.
• But nearly everybody will accept session cookies
  (you have to work quite hard to make Internet
  Explorer reject session cookies).

87
The Servlet Cookie API

• A servlet creates a cookie by using a constructor
  for the class Cookie.
• Various attributes can be set for the cookie
  before sending it to the client. They include
• The name and value of cookie
• The domain to which the cookie should be
  returned.
• By default the cookie will only be returned
  to the server that sent it, but this default can
  be overridden.
• The URI path to which the cookie should be
  returned.
• By default, the cookie is only returned to
  pages in the same directory as the page that sent
  the cookie.
• The time when a persistent cookie expires.

88
Example

• View the Cookies example in the Tomcat release.
  If you are running Tomcat locally, go to
• http//localhost8080/servlets-examples/
• In the example, the lines that add a set-cookie
  header to a server response are
• Cookie c new Cookie(name, value)
• response.addCookie(c)
• The resulting HTTP response will include a header
  like
• Set-Cookie namevalue

89
Browser Behavior

• If the browser accepts a cookie, it returns a
  cookie header like
• Cookie namevalue
• in HTTP requests, when revisiting the same
  server.
• In servlet code you read the set of cookies
  returned by the browser by, e.g.
• Cookie cookies request.getCookies()
• Exercise Set one or two cookies using the
  Cookies example in the Tomcat release. After
  setting the cookies, also visit the Request
  Headers example to see the returned HTTP cookie
  headers themselves.

90
The Session Tracking API

• You should be able to see in a general way how
  the Servlet cookie API can be used for session
  tracking.
• Actually you dont need to explicitly manipulate
  cookies to achieve this servlets provide a
  higher-level API that transparently uses cookies
  to keep track of sessions.
• Using the higher-level API has the added benefit
  that it also supports URL-rewriting as a tracking
  mechanism, in the (fairly unlikely) event that a
  browser doesnt support session cookies.

91
The HttpSession class

• A session is defined as an associationlasting
  for some timebetween a particular browser and a
  particular Web application.
• It is represented by an instance of the
  HttpSession class.
• A servlet method retrieves the current session
  object by applying the method getSession() to the
  HttpRequest.
• If no session object exists on a call to
  getSession(), a new one will be created.
• Objects of any type can be bound to sessions by
  storing them as named attributes in the session,
  using the setAttribute(), getAttribute() methods
  of HttpSession.

92
Shopping Cart Using a Session

• public void doGet(HttpServletRequest req,
• HttpServletResponse
  resp) throws
• HttpSession session request.getSession(tru
  e)
• ArrayList shoppingCart
• (ArrayList) session.getAttribute
  (cart)
• if(shoppingCart null) // New
  session
• shoppingCart new ArrayList()
• session.setAttribute(cart,
  shoppingCart)
• Add or remove items from cart

93
Remarks

• The true argument of getSession() means that a
  new session object will be created if one does
  not already existyou should probably always use
  this argument.
• See the Sessions example in the Tomcat release
  for a complete example using various session
  tracking methods.
• It is instructive to revisit the Cookies
  example after starting a session you should find
  a cookie called JSESSIONID has been established.

94
Session Attributes vs. Instance Variables

• In Java programs, local variables are normally
  declared inside methods to hold values computed
  and used within the invocation.
• Typically, instance variables are used to hold
  values that need to be shared across multiple
  invocations.
• In servlet programmingwhere several browser
  sessions may be concurrently operating on a
  single servlet instancethis role for instance
  variables is naturally taken over by attributes
  of the session object.
• Think hard before declaring an instance variable
  in a servlet! In many cases you should probably
  be using a session attribute instead.

95
The Scope of a Session

• A servlet context is a group of servlets (and
  possibly other resources), collected together as
  a Web application.
• Several servlets may be involved in the same
  session, hence share the same HttpSession object.
• This sharing is automatic if the servlets are in
  the same context, and are interacting with the
  same browser.
• Servlets from different contexts in the same
  server, or interacting with different browsers,
  always have distinct HttpSession objects.

96
Life-Time of a Session

• In general a session expires after some interval.
• The method
• public void setMaxInactiveInterval(int
  seconds)
• on HttpSession can be used to request that
  the session will be invalidated if there has been
  no transaction in the specified interval.
• The method
• public void
  invalidate()
• on HttpSession can be used to forcibly end a
  session.

97
JSP JavaServer Pages
98
What is a JSP Page?

• According to the JavaServer Pages Specification
• A JSP page is a text-based document that
  describes how to process a request to create a
  response. The description intermixes template
  data with some dynamic actions.
• JSP deliberately supports multiple paradigms for
  authoring dynamic content.
• These include Scriptlets, JavaBeans and Tag
  Libraries.

99
JSP Features

• Fixed template datathe parts of a JSP page that
  are used verbatim in the response. In simple
  cases this data will take the form of plain HTML.
  It may also be XML, or plain text.
• Standard directives guiding translation of a JSP
  page to a servlet.
• Scripting elements scriptlets, expressions, and
  declarations that include Java fragments to embed
  dynamic content.
• Standard actions which are predefined XML-like
  tags.
• A tag extension mechanism, called tag libraries.

100
Translating and Executing JSP Pages

• A JSP page is executed in a JSP container,
  generally installed in a Web server.
• The underlying semantic model is that of a
  servlet.
• A JSP container will translate the JSP page to a
  Java servlet.
• By default, translation and compilation of a JSP
  page is likely to occur the first time it is
  accessed.
• With Tomcat 5, you can find the generated Java
  and the class files in a subdirectory under the
  folder Tomcat 5.0\work\ .

101
Directives vs Request-time Operations

• Directives provide global information about the
  behavior of a JSP pageindependent of any
  specific request.
• In practice, they guide the process of
  translation from JSP to a Java Servlet. They are
  compile-time instructions.
• Scripting elements and actions have some effect
  in the context of a particular request.
• e.g. generating some output that depends on form