1 / 138

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

e-Science e-Business e-Government and their Technologies Introduction to Web Applications. Bryan Carpenter, Geoffrey Fox, Marlon Pierce Pervasive Technology Laboratories Indiana University Bloomington IN 47404 January 12 2004 dbcarpen@indiana.edu gcf@indiana.edu mpierce@cs.indiana.edu

leighanna
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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@indiana.edu gcf@indiana.edu mpierce@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, today’s 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.edu:8080 Accept: image/gif, ..., */* ... <html> <head>…</head> <body> … </html> HTTP/1.1 200 OK Content-type: text/html <html> <head>...</head> <body> ... </html> Static HTML files Client HTTP Response

  6. Dynamic Generation of HTML Server HTTP Request GET /hello.pl?who=bryan HTTP/1.0 User-Agent: Mozilla/4.51 [en]... Host: sirah.csit.fsu.edu:8080 Accept: image/gif, ..., */* ... #!/usr/bin/perl $name = param(“who”) ; print “Content-type: text/html\n\n” ; print “<html><body>Hello $name!</body></html>\n” ; Script, or method HTTP/1.1 200 OK Content-type: text/html <html> <body> Hello bryan! </body></html> 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 FORMelement 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 Server’s 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 CGImoduleto hide many of these details—especially 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. CGIexample • The form element in the initial HTML document is as follows: <form action=“http://server-name/cgi-bin/hello.pl”> Name: <input type=text name=who size=32> <p> <input type=submit> </form> • The CGI script hello.pl is: #!/usr/bin/perl use CGI qw( :standard) ; $name = param(“who”) ; print “Content-type: text/html\n\n” ; print “<html><body><h1>Hello $name!</h1></body></html>\n” ;

  11. 2. Java Servlets • In conventional CGI, a Web site developer writes an executable program that processes a form’s 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(“<html><body>”) ; out.println(“Hello ” + request.getParameter(“who”) + “!”) ; out.println(“</html></body>”) ; } }

  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 • ThedoGet() method is called in response to an HTTP GET request directed at the servlet. • As the names suggest, the request object describes the browser’s request, and the response object describes and the servlet’s 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.DLL—Active 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 <%@ LANGUAGE=“VBSCRIPT” %> <HTML> <HEAD><TITLE>Sample ASP</TITLE></HEAD> <BODY> Welcome. It is now approximately <%= Time() %>.<BR> Some simple text formatting using server-side code: <% For intCounter = 1 to 5 %> <FONT SIZE = <%= intCounter %>> Hello </FONT><BR> <% Next %> </BODY> </HTML>

  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 <%@…%> brackets. • Server-side VB inserts appear in <%…%> brackets. • <%=expression%> is shorthand for: Response.Writeexpression 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 <% and %> markers:a small script in Java to perform arbitrary functions. • Expression: anything between <%= and %> markers is evaluated by the JSP engine as a Java expression. • JSP directive enclosed in <%@ and %> markers—passes 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 jsp:useBean 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 Browser Web server

  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(“<html><body>”) ; out.println(“Hello ” + request.getParameter(“who”) + “!”) ; out.println(“</html></body>”) ; } }

  21. An Equivalent JSP Page <html> <body> Hello <%= request.getParameter(“who”)%> ! </body> </html>

  22. Remarks • A suitable form element to front-end this page might be: <form action=“hello.jsp”> Name: <input type=text name=who size=32> <p> <input type=submit> </form> • 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, O’Reilly, 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 JSP—a 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 servers—look 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 don’t 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 don’t happen exactly like this, don’t 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://localhost:8080 • If you are running your web server on a remote host called hostname, point your browser at: http://hostname:8080 • 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 didn’t 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 isn’t 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://localhost:8080

  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 visitor’s 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: <html> <body> <form method=“get” action=“hello.jsp”> Name: <input type=“text” name=“who” size=“32”/> <p/> <input type=“submit”/> </form> </body> </html> andhello.jsp: <html> <body> Hello <%= request.getParameter(“who”)%> ! </body> </html>

  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 don’t 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://localhost:8080/grid04hello/hello.html, 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 server—presumably those matching some selection criterion—will 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, O’Reilly, 2001. • Haven’t 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.html, 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 line—not 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: “who=Bryan”.

  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 who=Bryan

More Related