Java4320: Web Programming Model *

Transcription

1 OpenStax-CNX module: m Java4320: Web Programming Model * R.L. Martinez, PhD This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License 4.0 Abstract The purpose of this module is to provide an introduction to the web programming model. Revised: Wed May 11 08:05:21 CDT 2016 This page is included in the following Books: ITSE Java Programming (Intermediate) 1 Object-Oriented Programming (OOP) with Java 2 1 Table of Contents Preface (p. 1) Viewing tip (p. 2) * Figure Index (p. 2) Preview (p. 2) General background information (p. 2) Discussion (p. 2) Homework assignment (p. 5) Summary (p. 6) What's next? (p. 6) Figures (p. 6) Miscellaneous (p. 12) 2 Preface This module is one in a collection of modules designed for teaching ITSE Java Programming (Intermediate) at Austin Community College in Austin, TX. The purpose of this module is to provide an introduction to the web programming model. The homework assignments for this module expose students to supplemental information regarding the topics presented herein. * Version 1.8: May 11, :08 am

2 OpenStax-CNX module: m Viewing tip I recommend that students open another copy of this module in a separate browser window and use the following links to easily nd and view the Figures while you are reading about them Figures Figure 1 (p. 6). Web Programming Model Figure 2 (p. 6). Default Page Specied Figure 3 (p. 7). Browser and Server Communication Figure 4 (p. 7). Web Development Cycle Figure 5 (p. 7). Output - headerdisplay.jsp Figure 6 (p. 8). Code - css-header.css Figure 7 (p. 9). Code - headerdisplay.jsp Figure 8 (p. 10). Code - headerrequest.jsp Figure 9 (p. 11). Code - headerautorefresh.jsp Figure 10 (p. 11). Code - headerresponse.jsp 3 Preview To program eectively on the web, it is essential that developers understand the basic elements that comprise web software architecture. The fundamental web components from a developer's perspective are discussed in this module. The web programming model consists of the following components: Client (browser) Server (web server) Databases (database servers) Supplemental Content (additional servers) The JSP material in this course covers aspects of the rst two. Database interfaces and supplemental content are addressed in INEW 2338, a following course at ACC. 4 General background information Like many modern technical implementations, the complete internet architecture is quite complex. Applications running on a variety of hardware congurations communicate via more than one hundred possible protocols. The sending software packages data into packets consisting of protocol data units (PDU) and service data units (SDU). The packets are sent down the TCP/IP protocol stack and across the wire to the proper destination. The packets are deconstructed as they ascend the protocol stack and are nally processed by the receiving application. The data transmission cycle between applications happens with remarkable reliability. Communication between client and server is achieved with outstanding quality. When errors or dropped packets do occur, checksums and other mechanisms are implemented to correct the transmission mistakes. Naturally, a system designed to accomplish such technical feats is by necessity exceptionally complicated. Fortunately, developers do not need to comprehend all aspects of web technology to be productive. Furthermore, by taking a building block approach in this course, students will learn essential aspects of JSP without encountering unnecessary (at this point) complexity. 5 Discussion As listed above, the four components of web development are client, web server, database, and other servers. Figure 1 (p. 6) provides a diagrammatic view of the connections linking the essential elements. Even though

3 OpenStax-CNX module: m hardware is depicted in the diagram, this course addresses web-related software running on the devices shown. This course focuses on the inter-relationships between the browser and the web server particularly as they apply to JSP. 5.1 Browser The client computer runs the client software known as the browser in web development. The browser accesses the web server software which runs on the physical web server (hardware). Notice that the term web server can apply to a software program that hosts websites running on a server. The term web server can also refer to the hardware server itself. In this course, web server will generally mean the software hosting websites. In a networking course, web server would likely reference the hardware server. Users have a number of browser alternatives to access websites and popular options are available for download at no charge. Some of the more common choices are: Chrome, Firefox, Internet Explorer, and Safari. Each one of these is simply an executable (e.g. chrome.exe, refox.exe, iexplorer.exe, and safari.exe) that provides a means to connect to websites and display site content. Browsers are specialized programs designed to process and present results of HTML, CSS, and clientside scripting languages such as JavaScript. The majority of processing by browsers is accomplished by the engine (a.k.a. layout engine, rendering engine). Some additional processing work is performed by plug-ins or extensions. Engines running in popular browsers are Blink-Chrome, Gecko-Firefox, Trident-IE, and WebKit- Safari. As an aside, all of the engines listed were written in C++ which is a common language of choice for high performance client-based applications. One considerable challenge for the web developer exists because each browser engine processes HTML, CSS, and JavaScript slightly dierently. For instance, in HTML5 (the latest version of HTML) some browsers support new features while others do not. Sites like html5test.com can be used to check for browser compatibility with selected features. A key design characteristic of browsers is that some behavior within the browser is limited and controlled. For security purposes, access to programs outside of the browser by code running within the browser is prohibited. 5.2 Web Server The software web server is an application dedicated to processing requests that originate from browser clients. Some popular web servers are: Apache HTTP, Apache Tomcat, Glasssh, Internet Information Server, JBoss, Jetty, and WebSphere. Of these seven listed, Apache HTTP and Internet Information Server do not support Java servlets which is required to run JSP applications. To run JSP solutions, a web server must supply a container in which JSP applications execute. In this course, we will use Tomcat to support JSP development and testing. It has a three subsections which are particularly relevant. Jasper is the component within Tomcat that parses and compiles JSP into Java servlet byte code. After compilation, servlets are run in the Tomcat container called Catalina. Tomcat also uses Coyote which is a connector to Apache HTTP server and that enables Tomcat to act as its own HTTP server (without running an HTTP server explicitly). Catalina executes the byte code provided by Jasper and produces HTML output which is then sent to the browser. It is important to note that Jasper is only required to parse and compile byte code once for each le which will occur the rst time the.jsp le is accessed. Subsequent requests for the le will use the byte code previously produced. When the le is re-published with updates, Jasper will again be invoked when the le is requested. 5.3 Browser and Web Server Communication When a user types a URL (Uniform Resource Locator) into the address box (a.k.a location.search property) of a browser and selects Enter, the browser sends a request to the website identied by the URL. The web server packages the request string sent from the browser into a Request object. The web server directs the

4 OpenStax-CNX module: m request to the appropriate resource on the server. The appropriate resource is determined by the default listing in the welcome-le tag of the web.xml le or by URL specication. In Figure 2 (p. 6), the index le will be served by default. Note: Use of web.xml is optional in the Servlet 3+ specication. So, if a user enters java.com in the address box, the request is routed over the internet and will reach the appropriate web server where it will be directed to the index page. See Figure 3 (p. 7). Any server-side code on the index page is processed and HTML is produced from that code. A Response object containing HTML is generated and a Response header is sent back to the browser. CSS and JavaScript are also sent back to the client in the Response header if they were included on the index page. If a user enters a specic page, java.com/latest-version.jsp for instance, then that specic page will be processed and returned instead of the default (index) page. 5.4 Development and Testing After designing web solutions, developers spend most of their time writing and testing code. The topology depicted in Figure 3 (p. 7) shows the browser and web server communicating across the internet. This is the architecture that will be in place for production environments, that is, web users visiting the organization's website. However, when developers are working on solutions prior to publication to production servers, they often install and use local web servers. These local web servers run on the same machine as the development software and the browser(s) used for testing. Figure 4 (p. 7) shows the general steps which comprise web development. After all of the required features have been implemented and tested, developers upload the new pages to the production environment (a.k.a production) and the new pages can then be accessed by users. The JSP portion of the course uses NetBeans for the examples. NetBeans is available for download at: netbeans.org. There are a number of IDEs (Integrated Development Environment) for Java development including: Eclipse, IntelliJ, JBuilder, JDeveloper, and WebSphere. Any of the listed IDEs can be used for development in the JSP portion of this course. But, since the examples are provided in NetBeans, students will likely benet from direct comparisons. Students may even elect to use a simple text editor like Notepad++. However, given local server integration requirements and other IDE advantages, students will probably nd NetBeans to be the most productive. Any of the common browsers can be used for testing pages. At least two browsers should be employed for page verication due to browser dierences. In fact, commercial sites are often veried using multiple browsers and versions. It is also recommended that students access html5test.com to verify new HTML functionality. After code has been designed, developed, and tested on the local machine, the directories and le are uploaded to the production server. In this class, the production server is the student website. Students should exercise due diligence to conrm that their assignments are functioning correctly on their student website. If the pages do not function correctly for the student, the pages will not pass verication testing by the professor and the assignment will not receive credit. 5.5 Request and Response Headers and Objects To eectively produce web software, web developers must understand the essential components and operations of the Request and Response headers and objects. This module presents an overview of the Request/Response processing. The code specics are not thoroughly considered here and should be reviewed after working through the remaining modules in the course. All of the JSP related functionality of Figures 7-10 will be covered in subsequent modules. When a URL is entered in the browser, a Request header containing information that may be used by server programs is sent from the client to the server. Figure 5 (p. 7) shows an example of Request and Response header content. The CSS le is included in Figure 6 (p. 8) as a reference. CSS will be introduced in the next module.

5 OpenStax-CNX module: m In Figure 7 (p. 9), the code that produces the table of Request and Response header content is displayed. When the Request header arrives at the server, the server converts the content into a Request object that contains the header data and methods supplied by the class. Lines 15, 18, and 24 reference the processing les that are included in the page. Note: the error icons shown in Figures 8, 9, and 10 are displayed since each of the les lack import directives. However, the errors are irrelevant since those les are all included in Figure 7 (p. 9) which does import the appropriate packages. The error messages could be disabled from display but were left on here to provide explanation. On line 3 of Figure 8 (p. 10), the getheadernames method of the request object is called to populate an Enumeration named eldnames. Lines 4-9 loops through the Enumeration and produce a table row for each eld contained in the Request object. Line 3 of Figure 9 (p. 11) sets an auto-refresh interval to 10 seconds. Based on that setting, the client sends a new Request header and the server responds with a Response header every 10 seconds. On Figure 5 (p. 7), the time in blue is shown under the Auto Refresh Header and is produced by lines 4-21 of Figure 9 (p. 11). The header table is produced by lines 3-9 of Figure 10 (p. 11). In particular, on line 5 of Figure 10 (p. 11), the response.getheaderfields method is called and returns a Map collection with a String and List of Strings as arguments. These are the elds sent from the JSP server (Tomcat) to the client. The last line of the Response header shows the server is Apache-Coyote 1.1. Coyote is a connector in Apache which enables Catalina (the JSP container in Tomcat) to act as its own HTTP server (in addition to a JSP container). 6 Homework assignment See the JSP section in Blackboard for all JSP homework assignments. 6.1 Supplemental Reading Sources referenced outside of the course are for additional educational purposes. While thorough knowledge and understanding of this supplemental information is not required to complete assignments or prepare for the JSP exam, it should be considered standard information for the professional developer. 7 Run the program I strongly, highly, and emphatically encourage students to write the code from all examples and get them working. By reconstructing the code, students gain valuable software development practice and are able to modify settings, variables, congurations, etc. to further enhance their understanding of the material. It should be considered virtually impossible to learn software development without developing software

6 OpenStax-CNX module: m Summary This module presented an overview of the web programming model. The important components of the model for this course are the client (browser) and web server. To eectively code web solutions it is necessary to understand the communication process used to facilitate browser and server interactions. In the development and testing cycle section, the steps and a few implications for developing and testing web solutions were presented. 9 What's next? Now that the environmental foundation is in place, we are ready to begin considering the individual construction components. HTML and CSS will be reviewed in the next module followed by applications of the JSP technology in subsequent modules. 10 Figures Figure 1 - Web Programming Model. Figure 2 - Default Page Specied.

7 OpenStax-CNX module: m Figure 3 - Browser and Server Communication. Figure 4 - Web Development Cycle. Figure 5 - Output - headerdisplay.jsp.

8 OpenStax-CNX module: m Figure 6 - Code - css-header.css.

9 OpenStax-CNX module: m Figure 7 - Code - headerdisplay.jsp.

10 OpenStax-CNX module: m Figure 8 - Code - headerrequest.jsp.

11 OpenStax-CNX module: m Figure 9 - Code - headerautorefresh.jsp. Figure 10 - Code - headerresponse.jsp.

12 OpenStax-CNX module: m Miscellaneous This section contains a variety of miscellaneous information. Housekeeping material Module name: Java4320: Web Programming Model Author: Dr. R.L.Martinez Maintainer: R.G.Baldwin File: Java4320.htm Published: 11/26/13 Disclaimers: Financial : Although the Connexions site makes it possible for you to download a PDF le for this module at no charge, and also makes it possible for you to purchase a pre-printed version of the PDF le, you should be aware that some of the HTML elements in this module may not translate well into PDF. I also want you to know that, I receive no nancial compensation from the Connexions website even if you purchase the PDF version of the module. In the past, unknown individuals have copied my modules from cnx.org, converted them to Kindle books, and placed them for sale on Amazon.com showing me as the author. I neither receive compensation for those sales nor do I know who does receive compensation. If you purchase such a book, please be aware that it is a copy of a module that is freely available on cnx.org and that it was made and published without my prior knowledge. Aliation : I am a professor of Computer Information Technology at Austin Community College in Austin, TX.