Building Java Enterprise Systems with J2EE
Part VI: Enterprise Web Enabling IN THIS PART
29 Web Browsers and Servers in the Enterprise 30 Traditional Web Programming and Java 31 XML 32 Java Servlets 33 JavaServer Pages
- 794 -
Building Java Enterprise Systems with J2EE
Chapter 29. Web Browsers and Servers in the Enterprise IN THIS CHAPTER • • • • • •
Web Web Java Web Web Web
Browsers Browser Security Plug-in Servers Server Security Server Availability
We described the basic approach to developing Web-based Java applets in Chapter 4, "Java Foundations for Enterprise Development," and the basic communications infrastructure of the Web and HTTP in Chapter 13, "Web Communications." This chapter builds on those concepts with an introduction to the two primary computing platfor ms used to Web-enable an enterprise: Web browsers and Web servers. Understanding the basic architecture of Web browsers and Web servers, as well as understanding the common problems and solutions encountered with their use, is fundamental to understanding how to Web-enable an enterprise using the Java enterprise technologies discussed in subsequent chapters. This chapter thus simply provides a basic conceptual framework for you to understand how Web browsers and servers are constructed, as well as the most significant facts for you to consider with their use in an enterprise. In this chapter, you will learn: • • • • • •
The architecture of Web browsers and the types of Web browsers most commonly used in the enterprise. The problems and solutions of Web browser security. The Java Plug-in software for using an alternative Java Virtual Machine inside of a Web browser. The architecture of Web servers and the types of Web servers most commonly used in the enterprise. The problems and solutions of Web server security. The options for building highly available Web server applications.
Web Browsers A Web browser is an application whose primary role is to transform GUI requests into HTTP requests and to transform HTTP responses into GUI display content. HTTP requests are, of course, sent to Web servers, and HTTP responses are received from Web servers. - 795 -
Building Java Enterprise Systems with J2EE
Requests for Web content are cast in the form of URLs that identify remote resource media accessible via the Internet. Web responses are often in the form of Web page documents with multimedia and HTML-based presentation content such as text, static and animated images, hyperlinks, GUI components, audio clips, and video clips. Additionally, referenced documents of various types managed by external handlers, Java applets, and executable browser script language commands (for example, JavaScript) can also be returned in an HTTP Web response. Because HTTP is the standard protocol for the World Wide Web (WWW), Web browsers become the GUI windows to the WWW. However, current Web browser GUI component types, the bandwidth for most HTTP connections, and the nature of HTTP itself constrain the GUI designs of current Web browser–based document content. Some Web browsers may take advantage of more sophisticated GUI component interactions, but often at the cost of standards compliance or additional bandwidth consumption. It is for these reasons that the state of the art for most Web browser Web pages tends to be limited to supporting a set of core multimedia features for use over the Internet and limited Web page presentation features with the bulk of presentation being HTML related. Web Browser Architecture Figure 29.1 presents a basic conceptual architecture for Web browsers to provide a glimpse into their underlying structure. At the heart of a Web browser is a main controller process, which manages the caching and state management of information, manages stimulation of Web request and response handling, invokes the configuration of browser properties, and drives the basic presentation of Web page content. Request handlers map GUIbased requests into HTTP network requests, and response handlers map HTTP responses into GUI-based events and requested display content. Each request and response drives the I/O of HTTP data to and from a network interface. An HTTP protocol is used for unsecured connections, and HTTPS is used for HTTP with SSL-based connections. Figure 29.1. The Web browser architecture.
- 796 -
Building Java Enterprise Systems with J2EE
A cache manager is often employed within Web browser architectures to store previous request and response data in an effort to avoid making unnecessary network requests. A state manager may also be employed to provide some management of session information using cookies or to facilitate some other form of session tracking. Furthermore, a configuration manager may be used to configure the properties and behavior of a Web browser. A document presentation interface is used to drive the actual display of GUI-based browser content. Web browsers typically support one or more of the following types of document presentation interfaces: •
•
•
•
•
•
HTML Presentation Manager: All Web browsers have some form of HTML-based presentation manager to output HTML display content and receive user inputs via HTML entities such as input forms and hyperlinks. XML Presentation Manager: A few current Web browser implementations and more Web browsers in the future are expected to support parsing of XML documents. We describe XML in more detail in Chapter 31, "XML" . Java Runtime Environment: A Java runtime environment may be embedded into a Web browser to execute Java applets, as well as to invoke the services of downloaded JavaBean components. ActiveX Runtime Engine: A Microsoft ActiveX runtime engine is embedded into Microsoft browsers to execute downloaded ActiveX/COM components. Scripting Language Runtime Engine: One or more runtime scripting language engines may also be used to execute scripting commands that were embedded into HTML pages (for example, JavaScript). External Content Handler: External content handlers may be used to dynamically execute the content of retrieved URL
- 797 -
Building Java Enterprise Systems with J2EE
•
information in an application that runs in a process external to the Web browser (for example, Adobe Acrobat PDF viewer). Plug-In Content Handler: Alternatively, certain content handlers can execute the content of retrieved URL information directly within a Web browser window in a separate thread via a content handler plug-in.
Web Browser Implementations Various Web browser implementations exist, but the Netscape Navigator (NN) and Microsoft Internet Explorer (IE) Web browser products are by far the most popular. NN runs on various platforms, whereas IE is targeted for Microsoft platforms. Both browsers support the latest and greatest in HTML presentation standards, as well as various extensions to HTML. Both browser implementations also support a JavaScript scripting language runtime environment and a Java applet execution environment. Despite the presence of standards, NN and IE do differ in feature support. Thus, it is often a challenge for developers of Web page content to determine the lowest common denominator of support across both NN and IE. However, by designing to such a lowest common denominator, you can help ensure a maximal level of Web client base support. Another interesting Web browser implementation is the HotJava browser from Sun. Implemented entirely in Java, it provides a customizable environment for extending the browser implementation following the configurable JavaBeans component model. The HotJava browser has built-in support for managing HTML, JavaScript, and Java runtime environment (JRE) applet presentation environments. Additionally, HotJava can also support various IE- and NN-specific extensions to the standard HTML specifications.
Web Browser Security Web browsers expose their host machines to a wide range of security risks. Because of the growth in usage and the widely distributed nature of the WWW, the use of Web browsers introduces exposure to a whole new slew of risks for client machines that have never before been seen by industry. Hackers now take advantage of an easier means to funnel malicious code to client machines, as well as a greater opportunity for tapping security-critical resources and information on client machine environments. It is for these reasons of enhanced risk exposure that Web browser and document presentation manager implementations often consider security from the outset of product development. This section briefly examines
- 798 -
Building Java Enterprise Systems with J2EE
the security problems associated with Web browser usage and security solutions to these problems. Web Browser Security Problems Security-critical resources on the machine in which a Web browser sits can be maliciously corrupted, referenced, or replaced by malicious content executing within a Web browser. Access to client machine resources can also be denied or delayed by malicious Web browser content. The following is a partial list of the more significant types of security problems that can plague a Web browser environment: •
•
•
•
•
•
•
•
•
Exposed HTML Presentation Manager Flaw Attacks: Flaws in certain HTML presentation manager implementations can be exploited. This may result in privacy and confidentiality concerns, as well as cause denial of service via exploited memory management faults. Exposed Runtime Engine Flaw Attacks: Flaws in scripting language, Java, and ActiveX runtime engine implementations can be exploited to perform operations on a client's machine to tap security-critical resources. Java Applet and ActiveX Component Attacks: Without proper controls, malicious Java applets and Microsoft ActiveX components that have been downloaded by a user may be used to access security-critical resources on the client machine. External Content Handler Attacks: External content handlers can be used to spawn infected documents (for example, Microsoft Word documents with a Word Macro virus). Plug-in Content Handler Attacks: Malicious plug-in content handlers that are downloaded and installed into a Web browser environment have complete access to the client machine's security-critical resources. Client Information Request Attacks: Malicious Web sites may solicit security-critical information from users (for example, credit-card information and passwords). Sensitive HTTP Requests and Response Data: Certain HTTP requests and responses may contain certain securitycritical data that needs protection over the wire. Client Privacy Violations: Certain machine, configuration, and session information sent from a Web browser to a Web server can be used to disseminate certain private information about a Web user. Falsified Client Identification: Malicious Web users can falsely identify themselves as a particular Web user to a Web site.
- 799 -
Building Java Enterprise Systems with J2EE
Web Browser Security Solutions Web browser and document presentation manager implementers, as well as developers of Web browser content, can address the security issues that plague Web browsers in various ways. The integrity and confidentiality of Web browser requests and responses are both addressed to various degrees by Web browser implementations. The authorization, identity, and authenticity of Web users and visited sites also play a key role in Web browser security solutions. Various means for providing secure Web browser environments based on the previously mentioned Web browser security problems are listed here: • •
• •
•
•
• •
•
•
Browser Implementation Updates: Users should frequently update their browsers with the latest patches. Java Security Restrictions: Java has been built with security in mind as a primary design consideration. The Java 1.0 security sandbox model, Java 1.1 signed applet code restrictions, or Java 1.2/2.0 fine-grained access control restrictions may all be used to limit which and how securitycritical resources can be accessed. Authenticode Restrictions: ActiveX code can be signed using Microsoft's Authenticode technology. Java Plug-in Updates: The security of an embedded Java runtime environment implementation can be enhanced by using a more rigorously tested JVM implementation that can be added to your Web browser environment using the Java Plug-in. Runtime Engine Disabling: As a more draconian measure, scripting-language engines and Java runtime engines can often be disabled within a Web browser's configuration. External Content Handler Security: Users need to manage the security inside of their external content handlers and should be wary of the external documents they download and spawn. Users can run a virus checker on documents before activating them with a content handler. SSL Confidentiality: SSL is built into many Web browsers to enable secure transfer between Web browser and server. SSL Client Authentication: A client-side certificate can be sent to a Web server during SSL handshaking to authenticate a particular client's identity. SSL Server Authentication: A server-side certificate can be sent to a Web browser during SSL handshaking to authenticate a particular server's identity. Anonymizer Sites: In the name of privacy, certain Web sites exist that can redirect your Web requests to other Web
- 800 -
Building Java Enterprise Systems with J2EE
sites after removing certain privacy-related information from the HTTP request.
Java Plug-in The Java Plug-in defines an approach for enabling the use of an alternative Java runtime environment inside of a Web browser instead of using the browser's built-in JRE. This is particularly useful for enabling your Web browsers used throughout an enterprise to take advantage of the latest JRE platform, APIs, and enhancements. The latest JDK v1.2.2, for example, can be downloaded to your enterprise users'Web browsers simply by use of a few special tags inside of an HTML document. Both Java applets and JavaBean components can thus be downloaded for use in a Web browser and can take advantage of the latest JDK library releases. After the libraries are downloaded, they are stored on the user's local hard disk and are simply used whenever the need for such alternative libraries is designated from within a Web page. Installing the Java Plug-in into a Web Browser Use of the Java Plug-in focuses on the definition of special tags in an HTML document that direct a Web browser to use a special JRE to process the downloaded Java code. The specification of such tags differs from browser to browser. After a Java Plug-in is installed inside of a user's Web browser environment, subsequent demands for such a JRE are forwarded to the user's local machine installation. Updates to the JRE are less time-consuming after the initial installation time. However, initial installation may require download times over a local area network that are anywhere from 3 to 10 minutes. Wide area network download times, such as over the Internet, are significantly longer. Use of the Java Plug-in with IE relies on IE's built-in extension mechanism for augmenting IE with additional COM and ActiveX components that can be called from within a Web page. A pair of
and tags is inserted into an HTML document to designate the use of an IE extension mechanism. If no Java Plug-in has been installed yet, and the user visits a site which designates that a Java Plug-in should be used, an IE browser first asks the user whether it is acceptable to download and install a signed ActiveX component. If the user answers Yes, a Java Plug-in ActiveX wrapper is downloaded to the Web browser that in turn manages the download and install of the new JRE. Netscape's built-in plug-in mechanism is used to extend the NN browser to download and install native code to be used as a
- 801 -
Building Java Enterprise Systems with J2EE
browser plug-in. The
and tags are inserted into an HTML document to designate the use of an NN plug-in. If no Java Plug-in is yet loaded, an empty plug-in picture is displayed within the browser window, and the user is asked to download the appropriate plug-in. The user then downloads and installs the Java Plug-in for NN by following the instructions. Designating the Use of a Java Plug-in JRE As we just mentioned, the installation of a Java Plug-in JRE can be initiated via the specification of the appropriate tags in a Web page. The Java Plug-in HTML Specification at http://java.sun.com/products/plugin/1.2/docs/tags.html defines the syntax needed within a Web page for designating the use of the Java Plug-in with an associated Java applet or JavaBean component. The Java Plug-in HTML Converter tool is also available and can be used to automatically mark up HTML documents with the necessary tags for using the Java Plug-in (http://java.sun.com/products/plugin/1.2/features.html). We only briefly describe the syntax of such tags from within an HTML document here to give you a flavor for what referencing the Java Plug-in from within a browser environment looks like. We encourage you to examine the Java Plug-in HTML Specification for more information and to use the Java Plug-in HTML Converter for ease of mapping your Java applet tags to Java Plug-in–style tags. For example, suppose that we wanted to run a Java applet inside of a Web browser and use the Java Plug-in. A normal Java applet tag designation, such as the format described in Chapter 4, may be defined as shown here:
We might then decide that our applet should operate inside of a JRE v1.2.2 environment and therefore require the use of a Java Plug-in HTML Specification as shown here:
- 802 -
Building Java Enterprise Systems with J2EE
classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" codebase="http://java.sun.com/products/plugin/1.2.2 /jinstall-1_2_2-win.cab#Version=1,2,2,0" width="400" height="300">
<![CDATA[ </COMMENT> No Java 2.0 support is possible for this applet. ]]> In this rather convoluted tag sequence, multiple needs were satisfied. We've encapsulated all information within an IE OBJECT tag pair such that IE can use its extension mechanisms to process the applet. Per the Java Plug-in HTML Specification, certain standard applet tags map to OBJECT attributes, and others map to PARAM tags within an OBJECT tag scope. Additionally, the statically defined classid and codebase values within the OBJECT tag attributes are defined to point to the appropriate Java Plug-in ActiveX component wrapper to use. Such a wrapper may be downloaded from the codebase if it is not already loaded onto the client's machine. The necessary tags for use of the Java Plug-in within NN browsers are defined within the COMMENT tags shown above. IE ignores the COMMENT tags, and NN will not recognize the leading OBJECT tag. Thus, the information within the EMBED tags is interpreted only by NN browsers. As you can see, the various APPLET tag elements also map to attributes of the EMBED tag. The special pluginspage leading tag and trailing tag. The various tags also may have attributes embedded within the initial tag, usually in the form of name-value pairs, such as . Colors specified using a hexadecimal identifier or color name and sizes specified in numbers of pixels or percentages of a displayed page are common examples of attributes embedded in various HTML tags. The general structure of an HTML document includes a heading and body. As an alternative to displaying a single HTML page inside of an HTML body, frames may also be used to display and control different windows within the same HTML page. We describe each element of the following sample HTML document structure in the sections that follow: [HTML Document Title] ] ] [ The Body of your HTML Document here… Document display elements: The set of embedded frame windows here… ] and tags designates a title for the HTML document. Titles are often displayed in the title bar of a browser window when the associated HTML document is loaded. Titles are also often the information that is displayed by search engines and hot-lists, so titles often are descriptive enough to convey the content of a particular HTML document. For example BEESHIRTS.COM<br />
<br />
and tags enclose the part of a document that is highlighted as a hyperlink. When you enclose text or some other data within and , the associated URL can be invoked via a click on the highlighted text or data between the tags. For exampleClick here for sale on Hockey Shirts and tags. This location can also be hyperlinked relatively within a document by use of the and tags. For exampleCustom Graphics Hand Oven Designs and tags block off a row in the table. The and tags block off a table cell in each row. The and tags contain table header cells. For example Small Medium Tennis Pro Shirt Yes Yes Millennium Shirt Yes Yes
and tags. Each frame within the FRAMESET tags can then be indicated via a to designate the size in rows of a frame set either in pixels or as a percentage size of a document. to designate the size in columns of a frame set either in pixels or as a percentage size of a document. The CGI Example " +" \n" + "\n" + "\n" + "\n" + "\n" + "I received following Data from client " ); } /** * To generate HTML Body */ private void generateHTMLBody(String[] data) { System.out.println(""); while(keys.hasMoreElements()){ System.out.println(""); String key = (String)keys.nextElement(); String value = (String)receivedValues.get(key); System.out.println(""+key+ " "+value +" "); System.out.println(" "); } System.out.println("
"); } System.out.println("/cgi-bin ejava.webch30.SampleCGIExample Contact write("Hi There!"); // Write to client document var clientName = Client.name; write("Client is :"+clientName); // Write to client document Hello World "; print " "; print " "; print << EOF; } SubElement1_Value SubElement2_Value " Foo & Bar &CorpAddress; " 123 101 10/19/99 Leave stuff at back door if no answer 11/10/99 $3.80 11/01/99 -
1001 10 $78.99 … … … 12345678901234 10/10/2000 0987654321 … … &VISA; … … … … I'll use proper tags here. Here I will not. But here I will again. 123 101 10/19/99 Leave stuff at back door if no answer 11/10/99 $3.80 11/01/99 -
1001 10 $78.99 &VISA; 12345678901234 10/10/2000 0987654321 Listing 31.2 presents our sample order.dtd DTD file used to validate an order XML document, such as the one in our dtdAndXmlDocument.xml file. Note first that we've defined top-level element content models for an order, an item, and a charge_card. Note that the order element contains both the item and the charge_card element. The card_signature element in our charge_card element is optional. We've also defined entities for VISA, MC, and AMEX credit card strings, as well as a parameter entity for PD that is referenced within the charge_card element definition. Most entities have parseable data values identified by the #PCDATA type. A couple of key things should also be noted about the elements within the order document. The ship_weight element within our order element optionally has content. Finally, note that our charge_card element has a required card_type attribute. Listing 31.2 XML Order DTD (order.dtd)… BeeShirts Home BeeShirts.com has sweater styles to suit you … "); System.exit(0); } try { String xmlFileURI = "file:" + new File (argv [0]).getAbsolutePath (); // Get Parser Factory SAXParserFactory saxParserFactory = SAXParserFactory.newInstance (); // set Document Validation true "); System.exit(0);[email protected] email address and sam password value to retrieve dummy order status data since we defer illustrating database connectivity until a subsequent chapter. If the user enters invalid login information five times in a row, the user is then directed to registration.html. If the user clicks the Remind button, the user is told that she will be emailed her password information. Clicking the Remind button also results in the HTTP POST to OrderStatusServlet. TermsAndConditionsServlet: Handles the HTTP request generated from clicking the Terms button and displays some simple order terms-and-conditions information. deliveryinformation.html: Contains a static HTML page referenced from the Delivery button and displays some canned delivery information. " + "\n BeeShirts.com \n \n"); // Print common BODY begin tags printWriter.println( "" ); return printWriter; } Similarly, the ServletsHelper.createClosingDocumentResponse() method can be used to close the PrintWriter stream after closing BODY and HTML tags are written as shown here:"); printWriter.println(" "); // Write the common left-hand portion of the page ServletsHelper.writePageLeftArea(printWriter, serverInfo); // Write this servlet's specific center of the page info writePageCenterArea(printWriter, cookieValue); // Close with TABLE end tags printWriter.println(" "); printWriter.println("
"); // If the cookie session value is valid, then user has visited // the site before, so display a welcome message… if(cookieValue != null){ printWriter.println(" WELCOME BACK : " + cookieValue +" "); } We also encourage you to examine all the HTTP response handling semantics defined for the BeeShirts.com storefront code on the CD. Almost all the responses from the BeeShirts.com servlets manage display of the top and left portions of the BeeShirts.com screens with custom development for the center area of the screen. In between HTTP request handling and HTTP response generation, some session management takes place, as we describe in a subsequent section. However, in general, BeeShirts.com servlet response generation follows the same basic pattern. For your edification in understanding the code on the CD, we describe the basic response generation scenarios here: •[email protected] email address and sam password to induce a successful login. A set of canned order data is then generated via the constructOrderForThisCustomer() method and displayed with the showUserOrders() method. WELCOME BACK : " + cookieValue +" … … … … … … … … … Note At the time of this writing, the BEA WebLogic Server v5.0 and v5.1 required that you specify an older Web API version number in the DOCTYPE reference of a web.xml file. The BEA WebLogic Server also did not support use of the standard element in a web.xml file. The DOCTYPE reference for BEA WebLogic is defined as such: ServletApp Application description servletsch32.war beeshirts A J2EE reference implementation deploytool with no command-line arguments spawns a GUI-based deployment tool for creating J2EE application EAR files, as well as for deploying J2EE applications. The deploytool invoked with the -deploy option deploys an application element inside of a particular element. The ServletConfig.getInitParameterNames() retrieve the values from within an sub-element of . The ServletConfig.getInitParameter() method can be used with a parameter name defined within a to retrieve a value defined within a parallel element named . A sample snippet of a particular XML deployment descriptor document defining these values is shown here: … OrderStatus ejava.servletsch32.OrderStatusServlet email [email protected] lastName Mellone … … Thus, our OrderStatusServlet that is bound to the named OrderStatus servlet in the preceding snippet may be used to retrieve initial parameter values as such (calls are assumed to be made from within OrderStatusServlet here):[email protected] " String emailAddressFromParameter = getInitParameter("email"); Servlet Context Configuration The ServletContext abstraction shown in Figure 32.3 encapsulates an interface to a servlet container environment that can also be configured via an XML deployment descriptor. The ServletContext.getInitParameterNames() retrieves the values from within a sub-element of . The ServletContext.getInitParameter() method can be used with a parameter name defined within a to retrieve a value defined within a parallel element named . A sample snippet of a particular XML document defining these values is shown here: … StoreName BeeShirts Site 105 Designates the deployed web site. … … For example, we could retrieve a ServletContext object and the initialization parameters from within a particular Java Servlet as shown here: and elements as defined in our web.xml file: … 30 … If we were to retrieve such information from an HttpSession object, we could use the following code snippet: element, values in an element, types defined in an element, and descriptions defined in a element can all be defined inside elements within the servlet deployment descriptor file. The environment values are then read from within a servlet via the JNDI API. Such environment values can only be read and not modified at runtime. Acceptable types for these environment values are java.lang.Boolean, java.lang.String, java.lang.Integer, java.lang.Double, and java.lang.Float. As an example, we have defined a configurable welcome message for the front page of our BeeShirts.com Web application from within an env-entry named WelcomeMessage as shown here: … Customizable description for the Application WelcomeMessage A big welcome to our online TShirts shoppe. Wide Variety of Shirts Wide Range of Sizes Secure Shopping Hand Made Designs Many More Features … java.lang.String Servlets access such environment variables by first creating an instance of a javax.naming. InitialContext object using the parameterless form of the InitialContext constructor. The servlet then performs a lookup() on the InitialContext with a name that begins with java:comp/env. The object returned from the lookup() is of the associated . Environment entry names can be also be named as subcontexts below java:comp/env, such as java:comp/env/foo/bar. Lookups via the InitialContext can thus be made with respect to relative and absolute context references as discussed in Chapter 19, "Naming Services." As an example of programmatic access to a configurable object, the WelcomeMessage defined in the previous XML document can be retrieved from within a servlet as is the case from within our BeeShirtsServlet class's writePageCenterArea() method extracted as a snippet here: elements. Information such as the EJB reference name, class type, and interface names can be defined under this element. Servlets can then act as clients to these EJBs in a very straightfor ward fashion using the JNDI API with EJB reference names looked up under a standard java:comp/env/ejb root context name. We defer detailed discussion of EJB references from J2EE clients until Chapter 36, "Modeling Components with Enterprise JavaBeans," and Chapter 37, "Advanced Enterprise JavaBeans Serving." Web applications can also be configured for access to resources in a simple manner as defined under elements in the Web application XML deployment descriptor. Resources include JDBC data sources, JMS connections, JavaMail sessions, and URLs. Web applications can then obtain access to such resources using JNDI and a standard JNDI lookup naming convention. EJB applications can also access database management and messaging services in a fashion similar to Web applications. Although it is possible to access database management and messaging services from within a Web server tier, we defer much of our discussion on how such services are more commonly accessed to our EJB discussion in Chapter 36 and Chapter 37. Servlet Transaction Service Management Servlets can begin, commit, and rollback transactions using the javax.transaction. UserTransaction interface as described in Chapter 23, "Transaction Services." Using such an interface, servlets can access multiple shared resources and EJBs within the context of a single atomic transaction. A handle to a UserTransaction object is obtainable using JNDI with a lookup via the name of java:comp/UserTransaction . A servlet transaction may be begun only within a service() method thread, and the transaction must be committed or rolled back before returning from the service() method. Otherwise, the servlet container will abort element defined within the element of the Web application XML deployment descriptor is used to define the particular authentication configuration used by a Web application. The sub-element of defines the type of authentication used. Authentication of principals that access servlets is accomplished in one of four ways, including basic, digest-based, forms-based, and SSL client certificate–based authentication. These four authentication types, with their associated element value in parentheses, are defined here: • sub-element of defines this domain name string. The Web client responds with a username and password solicited from the Web user. Digest-Based Authentication (DIGEST): Although a username and password are used to authenticate a user as with basic authentication, an added layer of security is provided by encoding the password using a simple cryptographic algorithm. Forms-Based Authentication (FORM): Standard HTML forms for login and failed login can be defined using a forms-based authentication scheme within the subelement of . When a user attempts to log in, standard field names of j_username and j_password are posted to a specified Web server URL using a standard action named j_security_check. As a sample snippet, the form within the referenced login HTML page may be defined as shown here: SSL Client Certificate–Based Authentication (CLIENT-CERT): Client authentication via SSL using client certificates is perhaps the most secure means for authentication. Because this form of authentication requires SSL over HTTP, this form of authentication is sometimes referred to as HTTPS-based client authentication. sub-element of the element. The simply defines a set of valid role names and optional descriptions in this way: Sytem Administration Role admin … Access to a particular servlet can then be restricted to access by users of a defined role using the subelement of a element. A element defines a security role assumed by the application, and a element refers to one of the servlet container-managed element's values as illustrated here: UserAccountManagement … SystemAdmin admin … The role of a user associated with a particular HTTP servlet request can be determined via a call to the HttpServletRequest.isUserInRole(String) method with a role name parameter designating the security role defined within a Web deployment descriptor. More sophisticated Web resource authorization can be specified with the sub-element of . A collection of Web resources can be specified and associated for access only by principals belonging to certain associated roles. Furthermore, the secure nature of the communications link over which access occurs can also be defined. As an example for limiting access to detailed user information stored on a Web server, we might have this: … UserInfo URL for all detailed user information /users/* POST Only allow system administrator access admin Require SSL session to get user info CONFIDENTIAL … Servlet Availability Service Management element placed within the element of a Web application's XML deployment descriptor designates the capability to run the Web application inside of a distributable servlet environment. By specifying that a Web application can operate in a distributable fashion, we are telling the servlet container environment that the Web application adheres to a few behavioral constraints to facilitate distribution. Web containers can then implement features of clustering and failover that would otherwise not be possible for nondistributable servlets. The restrictions that must be adhered to by the servlets mainly revolve around the type of objects that are stored in an HttpSession object. Only java.io.Serializable, javax.ejb. EJBObject, javax.ejb.EJBHome, javax.transaction.UserTransaction, and javax.naming.Context objects may be stored in an HttpSession by a distributable servlet. Otherwise, an IllegalArgumentException may be thrown by the container when an attempted HttpSession storage operation is performed. By restricting such object types to being added to a servlet HttpSession object, the servlet container can guarantee the mobility of servlet session object state during failover or clustering. element along with an xmlns:jsp attribute is used to define the root of the XML-based JSP document that must be formatted according to a standard DTD. Tags Although we sometimes think of tags as discrete snippets of markup that define parts of a JSP or HTML page, the term tags as it relates to custom tag extensions is actually an important part of the JSP specification with a very specific meaning. Custom tags relate to custom actions that can be defined by developers using a special set of JSP tag extension Java classes and interfaces. These custom actions are implemented by custom Java-based tag handler classes that handle any custom tags inserted into a JSP. A collection of these tag handlers is referred to as a tag library, which can be referenced and utilized by JSPs using a special tag library directive. Furthermore, an XML-based tag library descriptor file can also be used to configure a particular tag library. We have much more to say about custom tags and actions in a later section. Comments Comments in JSP pages can be used to document JSP source code or used to embed information to be sent to the client. Comments that are to be ignored during processing and used to document JSP source code are included between <%-- and --%> characters. Comments specific to the type of scripting language being used with the JSP may also be used within scripting elements. Thus, for Javabased JSP scripting, we would place documentation comments between <% /** and **/ %> characters. As an example of such comments, we have this: element of the XML document representing the JSP is augmented with an xmlns: name space definition attribute identifying the tag library like this: … Directive Examples The BeeShirts.jsp page first uses a page directive to describe the page and import any auxiliary libraries needed by its translation unit. Thereafter, the BeeShirts JSP then defines some basic HTML template data followed by another page directive to define an errorPage JSP and two include directives. The include directives simply include the BeeShirtsTopArea.jsp JSP within a top row of an HTML table and the BeeShirtsLeftArea.jsp JSP within a second row of the HTML table. The main welcome message body of the BeeShirts.jsp JSP is then displayed within a separate cell of the second row. The HTML template data and JSP directives for this BeeShirts.jsp JSP are shown here: BeeShirts.com
<%@ include file="BeeShirtsTopArea.jsp" %> <%@ include file="BeeShirtsLeftArea.jsp" %> …
Note that we've excluded other code not shown in the preceding snippet at this point in the book because we have not yet covered certain topics. For the most part, our BeeShirts.com JSPs follow the same pattern as described previously with the use of a page directive at the top of each JSP, referencing of an error page, and the inclusion of the BeeShirtsTopArea and BeeShirtsLeftArea JSPs via include directives as was done with the BeeShirts JSP. JSPs using such directives include the BeeShirts, AboutUs, ContactInformation, Registration, BrowseShirts, Cart, OrderStatus, TermsAndConditions, and VerifyLogin JSPs. All of these JSPs share the fact that they are front pages that directly receive HTTP requests. Additionally, the OrderStatus JSP also includes the LoginForm JSP directly following the inclusion of both the BeeShirtsTopArea and the BeeShirtsLeftArea JSPs. Furthermore, as was illustrated in Figure 33.3, the Registration, BrowseShirts, and Cart JSPs all handle both GET and POST requests in a separate fashion. When a GET request type is received, the JSP includes one type of file, and when a POST request type is received, another course of action is taken. JSP scriptlets encapsulate the conditional logic, and the include directives sit outside of the scriptlet boundaries. We illustrate this here for the element as exemplified here: private static int MAX_FAILED_LOGINS = 5; Expressions Expressions are scripting elements that define statements that are evaluated during request processing time. When expressions are evaluated, their evaluated output value is converted to a String. Expressions are defined within the <%= and %> character sequences. The expressions inserted between such boundaries are defined in a scripting language–specific way. Here's an example of a Javaspecific expression: <%=cart.getCartAsHTMLTable()%> XML-based JSP files using expressions simply insert expressions inside of a element as shown here: new java.util.Date() Scriptlets Scriptlets are more general-purpose scripting elements used to execute statements, declare variables and methods, evaluate expressions, and utilize JSP objects. Scriptlets are executed during the processing of JSP client requests with any output generated to the response output object. Scriptlets are defined within the <% and %> character sequences. Any code contained within such boundaries is expressed in terms of the host scripting language. As an example of a Java-based scriptlet taken from the Registration JSP, we have this: element as shown here: String method = request.getMethod(); // Include RegistrationForm if GET method request. // Include DisplayRegistrationInformation if POST method request. // if the request method type is not POST if(!method.equalsIgnoreCase(JSPHelper.POST_METHOD)){ } else{ } BeeShirts.com <%-- Add Error page to display Error --%> <%@ page errorPage="ErrorDisplay.jsp" %> <%-- Get the server information --%> <% String serverInfo = JSPHelper.getServerInfo(request); %> <%-- Display the Top and Left part of JSP --%> <%@ include file="BeeShirtsTopArea.jsp" %> <%@ include file="BeeShirtsLeftArea.jsp" %> <%-- Create session object and obtain cookie value --%> <% // Create a session each time the user comes to this site. boolean createNew = true; session = request.getSession(createNew); // check if it is the first time visiting and if has cookie Cookie[] cookies = request.getCookies(); <%-- Print welcome message --%> <% // If have cookie, then print welcome back message if(cookieValue != null){ out.println(" WELCOME BACK : " + cookieValue +"
After a page directive and some preliminary HTML, the BeeShirts JSP first makes a call to the static getServerInfo() method on a JSPHelper class used as a utility class with our exam ples. The static JSPHelper.getServerInfo() method simply extracts the server hostname, server port, and context path from the request object and returns a formatted String of this information as shown here: element in our web.xml deployment descriptor as shown here: Customizable description for the Application WelcomeMessage A big welcome to our online T-Shirts shoppe. … java.lang.String Finally, the BeeShirts JSP uses the out object to print any specialized WELCOME BACK message, as well as the message looked up from the JNDI java:comp/env/WelcomeMessage named environment entry. As a final example of implicit object usage with exception handling, our ErrorDisplay.jsp standard error handler JSP, shown in Listing 33.2, uses the exception object to print the contents of the received exception, as well as a stack trace for the exception. While exceptions are a rather ugly thing to display on a Web page, for our development purposes, it can be very informational. We thus print out such exception information in the ErrorDisplay JSP. Listing 33.2 BeeShirts.com Standard Error Page JSP (ErrorDisplay.jsp) BeeShirts.com Error Display Page Error occurred in accessed page : <%=exception%> and exception occurred in : <%exception.printStackTrace(new PrintWriter(out)); %>
element. The value attribute can be either a string value or an expression evaluating to a string value. The sub-element has the following general form: sub-elements used to add parameters to the forwarded request object. The relative URL of the resource to which the request will be dispatched is defined by a page attribute within the element. The page attribute can be defined in terms of a string or an expression that evaluates to a string and is described in terms of a URL relative to the JSP Web application context (if it begins with a /) or relative to the JSP file. This action can be in either of these two forms: We have the following associated examples: jsp:include Action The standard jsp:include action element is used to include the output response from another resource into the output from the current JSP. If the other resource is a static file, the content is simply included with the current output response. If the other resource generates a dynamic response, the request dispatched to sub-elements used to add parameters to the dispatched request object for use by resources that generate dynamic content. The URL of the resource to which the request will be dispatched is defined after a page attribute within the element. You must also include a mandatory flush attribute that must always be set to true, indicating that the output buffer is to be flushed. This action can be in either of these two forms: For example: element has the following general form: … The id and scope attributes are individually specified, but the class, type, and beanName attributes must be defined according to one of the four combinations shown previously. The jsp:useBean attributes are defined here: • element will be processed to initialize the object. Mainly, the action defined next is used in this context. As an example of associating an object from a session scope to an identifier used to manage some system user information, we have the following sample cases: element has a name attribute that refers to the identifier of an object located or instantiated via a jsp:useBean action. Attributes are also defined that describe a mapping from named JSP request parameters to named JavaBean properties whose values are to be set. The action element has the following general form: element are as shown here: • action element. property: Defined with a value that describes how named request parameter values can be used to set associated JavaBean property values. The property="*" form can be used to indicate that any named request parameters received by the current JSP are to be set into matching JavaBean properties that share the same name. The property="propertyName" form can be used to specifically designate the name of the JavaBean property that should be set. JavaBean properties that have types of boolean/Boolean, byte/Byte, char/Character, int/Integer, long/Long, double/Double, float/Float, or indexed arrays of these types can all be set using this action. param: Defined with a value that is the name of a request parameter to be used with a named property attribute value if the name of the JavaBean property differs from the name of the request parameter. value: Defined with a value that will be used to directly set a JavaBean property named by the property attribute. The action element has the following general form: element handles the correct formatting and insertion of either OBJECT tags or EMBED tags as appropriate, depending on the Web client's particular browser requirements. The attributes defined within the element either are derived from or directly map to attributes defined within the standard HTML APPLET, OBJECT, and EMBED tags described in previous chapters. Furthermore, two sub-elements of the element are used to define JavaBean or Java applet parameters and alternative text displays. Note See Chapter 29, "Web Browsers and Servers in the Enterprise," for a discussion of the Java Plug-in technology. Chapter 29 and Chapter 4, "Java Foundations for Enterprise Development," also provide a better understanding for element. action element has the following general form: [ [ ] [ Alternative message if failed to load ] The code, codebase, archive, name, width, height, align, vspace, and hspace attributes of the jsp:plugin element all directly map from attributes of an APPLET tag as described in Chapter 4's discussion of Java applets as well as from the EMBED and OBJECT tags described in Chapter 29. Additionally, the remaining attributes of a jsp:plugin element are defined here: element that contains one or more elements. Each element then defines the name and value of parameters used to initialize the Java applet or JavaBean. This is, of course, akin to the PARAM tags within an APPLET tag. Finally, the element within the element can be used to display an alternative text message if the Java applet or JavaBean cannot be loaded in the Web client's browser. This is similar to the ALT attribute of an APPLET tag or to any text added within the body of an APPLET tag. For example (analogous to the example from Chapter 29's Java Plug-in discussion), we have this: Cannot load Java Applet. Standard Action Examples The CheckOut JSP provides a good example of a JSP making effective use of the type of action. As Listing 33.3 demonstrates, the CheckOut JSP first attempts to retrieve a Customer object from the session. If no Customer object is retrieved, the client is redirected to the Registration JSP. Subsequently, a ShoppingCart object is looked up in the session object. If no ShoppingCart is present, the client is redirected to the BrowseShirts JSP; otherwise, it's redirected to the Cart JSP. Listing 33.3 Check Out JSP (CheckOut.jsp) BeeShirts.com
<%-- Get handle to an Address JavaBean --%> element to define a servlet class within each element, a element can be used. The element is used to identify the filename for JSPs that are directly deployed without precompilation. The path to the JSP file relative to the root Web application context must also be specified as part of this element's value. For example, our JSP file BeeShirts.jsp is placed directly under the root Web application context directory in a WAR file, and thus we have an entry in our sample web.xml deployment descriptor file as shown here: … BeeShirts BeeShirts BeeShirts.jsp … If the JSP is precompiled into an implementation class, the element can be used. If it is still desirable to refer to the JSPs using the JSP name or some other configurable URL pattern, a element can be used. For example, we use a BEA WebLogic precompiler to translate and compile the BeeShirts.jsp file into a _beeshirts Java class file in the ejava.jspch33 package, and then set deployment descriptor entries for this JSP in a weblogic_app.xml file on the CD like this: … BeeShirts BeeShirts ejava.jspch33._beeshirts … BeeShirts BeeShirtsJSP … As just alluded, we in fact include two sample XML-based deployment descriptor files on the CD. The web.xml file is used to directly deploy the BeeShirts.com JSPs in their raw JSP file form to the J2EE reference implementation server. The weblogic_app.xml file is used to deploy JSPs that have been precompiled as Java Servlets to the BEA WebLogic Server. JSP Configuration In addition to defining basic entry information for each JSP as illustrated previously, both sample XML deployment files also contain configuration information for the JSPs that can be read in one of two ways. The BrowseShirts JSP and OrderStatus JSP both have collections of values associated with them that can be read via calls to ServletConfig akin to the way their servlet counterparts read such values in Chapter 32. We also define a collection of corresponding entries in each XML file as another means for reading configuration information into JSPs and any J2EE component for that matter. Note Although we include sample code in our JSPs for accessing configuration information from both and elements in an XML deployment descriptor, we have coded the examples to utilize only the information retrieved from . This is because the products we have used to implement our sample JSP code at the time of this writing did not support use of values. We have nevertheless left the code on the CD for accessing so that you can see how both forms of configuration information may be read. entries, the description for the BrowseShirts JSP follows this form: … BrowseShirts BrowseShirts BrowseShirts.jsp numberOfShirts 8 Number Of Shirts to Read shirt_0 0,XL,White, 11.5, 123,145,shirtOne.jpg First Shirt Information … … Recall that the DisplayBrowsedShirts JSP is included as part of the BrowsedShirts translation unit. The DisplayBrowsedShirts.getQueriedShirts() scriptlet method is where access to such values is performed with calls such as this: values displayed here: … numberOfShirts 8 java.lang.String shirt_0 0,XL,White, 11.5, 123,145,shirtOne.jpg java.lang.String … The DisplayBrowsedShirts.getQueriedShirtsFromEnvironment() scriptlet method implements the form of configuration that is utilized by our actual online JSP processing example. This method is where access to values is performed with calls to the InitialContext object stored within our JSPHelper class as such: entries for OrderStatus. The constructDefaultUserInformationFromEnvironment() method reads this information from the entries and is the method actually invoked by our sample code. Direct JSP Deployment Procedure Considerations JspApp Application Description jspch33.war beeshirtsjsp Assuming that the J2EE reference implementation server was started (that is, by calling %J2EE_HOME%\bin\j2ee -verbose), the compilej2ee.bat script can then successfully deploy the EAR file using the deploytool utility as shown here: element within the element of a web.xml deployment descriptor file. A element contains a element that points to the location of the tag library classes. The element also contains a element that points to the location of the TLD file to be associated with the tag library classes. For example: … /tag/BeeShirtsActions /WEB-INF/tld/BeeShirts.tld … If no location mapping is defined in the web.xml file, the uri attribute of a taglib directive may be used to define the location of the TLD file. However, a taglib directive in a JSP more commonly refers to a library that has been defined in a web.xml file as exemplified here: 
