[ Team LiB ] Previous Section Next Section

Creating a Web Application

So far, we've gone through the essentials of a Web application and how client requests are processed. Now let's go over some of the development strategies and common concepts that encompass Web application development. As with most application development, Web application development can also be categorized into multiple stages as described in Figure 6.4. The life cycle described in Figure 6.4 looks similar to the classic spiral model of software development. There are distinct outputs from each of the steps described. Let's look at some of the important artifacts that are produced as part of the Web application development process. We already mentioned some of the elements that make up the Web application in the previous section.

Figure 6.4. Web application development life cycle.

graphics/06fig04.gif

Development Life Cycle

The conceptual and design phase are similar to any application development, and Web application development is no different. The artifacts of these phases include UML diagrams (as covered in Chapter 5, “Enterprise Application Design with WebLogic Server”) and user specifications document. The artifacts of the development include static resources (such as images, HTML, and so forth) that make up the Web application as well as servlets and JSPs. We'll look at developing these components in detail later in the book when we cover servlets and JSP in detail.

But before we go into the deployment phase of the development life cycle, we need to take a look at the special packaging needs of Web applications.

WEB APPLICATION PACKAGING

The Servlet specifications define the directory structure for organizing the elements of a Web application. The directory structure is hierarchical in nature. Most Web servers, including WebLogic Server, implement the specification in this regard even though it isn't a required format but is merely a recommended format. The following directory listing explains the directory structure for a Web application:



/defaultWebApp (document/context root)
  jsps(subdirectories as needed)
  htmls     "
  etc.     "
   /WEB-INF
    web.xml
    weblogic.xml
    /classes
     servlets and
     supporting java classes
    /lib
     supporting java classes in a jar file

The root of the directory structure hierarchy is called the document root for the Web application. For example, in the Web application defined as part of the default WebLogic domain, mydomain, the document root is defaultWebApp. The document root (also known as the context path) of an application defines the URL namespace for the Web application components; that is, the servlets, static pages, and so on. WebLogic Server does not allow duplicate Web application names in the same WebLogic Server instance. All static files, such as images and welcome files (for example, index.html), must be placed somewhere under the document root.

Alternatively, static files can be placed in directories under the document root. As a convention, images are placed under a subdirectory (for example, \images) in the same level as of that of the \WEB-INF directory. The files can be referred to using the relative path with respect to the document root in the referenced files. All files under the document root (except for the special directory WEB-INF) are public and will be served to the clients. Although the files under WEB_INF/ aren't accessible for the client, the servlets in the Web application can get access to these using the servlet context-related API. We'll cover that when we discuss servlets in detail in Chapter 14. The Web application can take advantage of this restricted access and use the WEB-INF directory to store application-specific files that aren't served to the client but must be accessed from the servlets. The WEB-INF/classes directory contains the classes used by the Web application; for example, servlet, helper, and utility classes. The WEB-INF/lib directory contains the archived class files (JAR files) that contain other helper classes and utility classes. For example, this directory can contain the custom tag libraries.

The following listing is a partial listing of the examples Web application that is packaged along with WebLogic Server:



examplesWebApp\index.jsp
examplesWebApp\SurveyExample.html
examplesWebApp\images\built_on_bea.gif
examplesWebApp\WEB-INF\web.xml
examplesWebApp\WEB-INF\weblogic.xml
examplesWebApp\WEB-INF\classes\examples\servlets\HelloWorldServlet.class
examplesWebApp\WEB-INF\classes\lib\utils_common.jar

If a Web application is packaged and deployed in the recommended format as described here, it can be ported to any other J2EE-compliant server with little or no modifications. In the case of examplesWebApp described earlier, weblogic.xml must be converted to another J2EE-compliant application server format.

Web application can be deployed on the target J2EE server (for example, WebLogic Server) using different techniques depending on the application development phase (that is, development and testing) and requirement of the Web application. Because the source code undergoes frequent changes during the development phase, the Web application can be deployed in an exploded directory format that follows the directory structure listed earlier. Alternatively, all components of Web application can be bundled into a single unit, known as a Web application archive file (WAR), and deployed to the server. Alternatively, Web applications can be packaged into a Web Archive format (war) file. A WAR file is a JAR file that contains a Web application with the same content as the exploded directory. Enterprise archive file deployment provides another option for deploying Web applications in conjunction with other J2EE applications that include EJBs and other Web applications. In the next chapter, we'll take a detailed look at creating WAR and EAR files using the different tools available and deploying them to the WebLogic Server environment.

The last phases in the development life cycle are to make sure that the application conforms to the business requirements. Additionally, these phases can be used to tune the Web application as well as it works in unison with other components of the business application.

Development Strategy

As described in Figure 6.4, building a deployable Web application involves multiple steps, and it's possible for different resource groups to work in tandem to complete a Web application. Figure 6.4 indicates the steps involved in development of the Web application, but does not tell you about the optimal way of going about implementing the different life-cycle processes. In this section, we look at an efficient way of accomplishing each of those tasks. The elements that form the Web application defined earlier, along with the development life cycle, help to define the roles of the Web application developer. The development roles and the corresponding functions can be defined as follows:

  • Web design— Web designers create the static HTML pages and the images required for the Web application.

  • Java development— Java developers create the servlet classes and the tag library associated with the JSPs. Along with the Web designers, developers are involved in the development of JSPs.

The development tasks defined earlier can be carried out in parallel. After the development is done, the application must be assembled to conform to the specifications.

  • Configuration— The configuration files web.xml (contains the servlet mapping) and weblogic.xml (if needed) have to be written or generated using the tools such as WebLogic Builder, which is described in the next chapter.

  • Application assembly— Application assemblers place the compiled sources, along with configuration files (web.xml and weblogic.xml), in the directory structure described

  • Packaging— The packager bundles the Web application into a Web archive (WAR format). If the Web application forms a part of an enterprise application, it can added to an enterprise archive (EAR format).

  • Deployment— The packaged Web application is deployed to WebLogic Server.

Figure 6.5 summarizes the steps involved in the creation of a Web application.

Figure 6.5. Web application role-based development.

graphics/06fig05.gif

Configuring Web Applications

Earlier in the chapter, we took a brief look at the configuration elements (that is, web.xml and weblogic.xml) associated with the Web application. Let's look at configuring a simple Web application (zoo) that maintains animal groups based on the type of food each group eats. The Web application contains the carnivores and herbivores servlets to handle the different types of animals. The zoo Web application is organized in the same structure as described earlier for examplesWebApp.

Listing 6.1 describes the whole simple Web deployment descriptor describing the zoo web application. This provides a working example of how the tags defined in Table 6.1 are used in web.xml.

Listing 6.1 Zoo Web Application—web.xml
1 <?xml version="1.0" ?>
2 <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
3 "http://java.sun.com/dtd/web-app_2_3.dtd">
4<web-app>
5 <welcome-file-list>
6  <welcome-file>index.jsp</welcome-file>
7 </welcome-file-list>
8 <error-page>
9  <exception-type>
10  wlsunleashed.zoo.exception.AnimalNotFoundException
11  </exception-type>
13  <location>animalNotFound.jsp</location>
14 </error-page>
15 <servlet>
16  <servlet-name> carnivores </servlet-name>
17  <servlet-class> wlsunleashed.zoo.CarnivoresServlet </servlet-class>
18  <init-param>
19   <param-name>KingOftheZoo</param-name>
20   <param-value>lion</param-value>
21  </init-param>
22 </servlet>
23 <servlet>
24  <servlet-name> herbivores </servlet-name>
25  <servlet-class> wlsunleashed.zoo.HerbivoresServlet</servlet-class>
26  <init-param>
27   <param-name>StapleDiet</param-name>
28   <param-value>grass</param-value>
29  </init-param>
30 </servlet>
31  <servlet-mapping>
32  <servlet-name>carnivores</servlet-name>
33  <url-pattern>/carnivores/*</url-pattern>
34 </servlet-mapping>
35<servlet-mapping>
36  <servlet-name>herbivores</servlet-name>
37  <url-pattern>/herbivores/*</url-pattern>
38 </servlet-mapping>
39<servlet-mapping>
40  <servlet-name>carnivores</servlet-name>
41  <url-pattern>/king</url-pattern>
42 </servlet-mapping>
43 <servlet-mapping>
44  <servlet-name>herbivores</servlet-name>
45  <url-pattern>/mammals</url-pattern>
46 </servlet-mapping>
47 <servlet-mapping>
48  <servlet-name>carnivores</servlet-name>
49  <url-pattern>/cats</url-pattern>
50 </servlet-mapping>
51 <servlet-mapping>
52  <servlet-name>carnivores</servlet-name>
53  <url-pattern>/mammals/*<url-pattern>
54 </servlet-mapping>
55 </web-app>

The main elements in Listing 6.1 are the <servlet> and <servlet-mapping> tags. Lines 15 to 22 define a <servlet> tag for specifying the logical name mapping for wlsunleashed.zoo.CarnivoresServlet. They also define the initialization parameters for this servlet. Similarly, lines 23 to 30 define the logical name mapping for wlsunleashed.zoo.HerbivoresServlet. The logical names defined by the <servlet-name> along with the <servlet-mapping> elements (lines 31–54) are the key to accessing servlets in a Web application. The servlet-mapping element helps to identify URL requests based on a pattern to a mapped servlet. Now we need to understand how these tag values (servlet and servlet-mapping) are used in responding to a client request. Table 6.1 helps to understand the servlet mapping better for the configuration shown in Listing 6.1.

ACCESSING WEB APPLICATIONS COMPONENTS

The Servlet specifications define the URL pattern to use for accessing servlets defined in a Web application. Let's consider CarnivoresServlet of the zoo Web application. To access this servlet from a Web browser, we use the following URL:

http://zoo:7001/zooWebApp/carnivores

The URL corresponds to the following pattern:

http://machineName:portno/webapp/mapping/resourcename

where

  • machineName is the name of the machine where the WebLogic Server is running; for example, localhost.

  • portno is port at which the WebLogic Server is listening, usually 7001

  • webapp is the Web application name or the context root

  • resourcename is the name of the servlet or JSP as defined in the Web deployment descriptor. Alternatively, the resource name can be divided into the following components: servletpath/pathinfo (where servletpath is the servlet that's mapped to a servlet path) and pathinfo (which is the remaining portion of the URL). Resources can also be static files such as HTML and graphics.


Table 6.1. Servlet Mapping Rules

URL Pattern

Servlet

http://zooserver:7001/zoo/mammals

Herbivores

http://zooserver:7001/zoo/mammals/lion

Carnivores

http://zooserver:7001/zoo/king

Carnivores

http://zooserver:7001/zoo/cats

Carnivores

In addition to the servlet configuration, we must configure the JSP-specific configuration parameters related to WebLogic Server in the WebLogic-specific deployment descriptor briefly described earlier in the chapter. Listing 6.2 describes the simple weblogic.xml file that defines the basic JSP specific elements such as the compile command, working directory, and so on.

Listing 6.2 Zoo Web Application—weblogic.xml
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA
Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

<weblogic-web-app>
   <jsp-descriptor>
    <jsp-param>
     <param-name>
      pageCheckSeconds
     </param-name>
     <param-value>
      30
     </param-value>
    </jsp-param>
    <jsp-param>
     <param-name>
      compileCommand
     </param-name>
     <param-value>
      javac
     </param-value>
    </jsp-param>
   </jsp-descriptor>
</weblogic-web-app>

The pagecheckseconds defined as a JSP param tag instructs the Web container to check for the changes in the JSP file every 30 seconds. Listing 6.2 lists only some of the settings that can be defined as <jsp-param> element. For a full list of elements, refer to the following URL: http://edocs.bea.com/wls/docs81/webapp/weblogic_xml.html.

    [ Team LiB ] Previous Section Next Section