1. Advanced Java Programming
Umar Kalim
Dept. of Communication Systems Engineering
26/10/2007
Fall 2007
cs420

2. Agenda Web application, components and Web container
Technologies used in Web application
Web application development and deployment steps
Web Application Archive (*.WAR file)
*.WAR directory structure
WEB-INF subdirectory
Configuring Web application
Web application deployment descriptor (web.xml file)
Reference
Presentation by Sang Shin
So this is the list of topics we are going to talk about in this session.
First, we will define a few terms: “web application”, “web components” and “web container”. Next, we will talk about the steps you will follow to develop and deploy a web application. Then we will talk about “Web Application Archive”, which is called WAR file in short. We will look into the directory structure of a WAR file especially a meta sub-directory called WEB-INF.
A Web application has a accompanying configuration file called web.xml. This file is referred to as the deployment descriptor of the web application and contains all the configuration information of the application that web container needs to know in order to deploy and run the application properly. Understanding the web.xml file is important since you are going to have to construct web.xml file as part of development of your web application.
Then we will go through some life-cycle operations that you can perform over your web applications, for example, installing and deploying, listing all web applications that are currently running on the target web container and updating, removing, undeploying them.

3. Web Application, Components and Container
So let's understand a few terms.

4. Web Components & Container
Applet Container
Web Container
EJB Container
Applet
HTTP/ HTTPS
JSP
Servlet
RMI
EJB
J2SE
JavaMail
JavaMail
JNDI
JMS
JTA
RMI/IIOP
JDBC
JNDI
JMS
JTA
RMI/IIOP
JDBC
App Client Container
JAF
JAF
App Client
HTTP/ HTTPS
J2SE
RMI
JNDI
I talked about the container and component model of J2EE architecture during the J2EE overview session. Under component and container architecture of J2EE, the business logic (typically as EJB's), contents or presentations (typically as web-tier components such as Servlet and JSP components) are captured in the form of components and those components are then run within corresponding host execution environment called containers. (I am using the term “components” a bit loosely here for Servlet and JSP since they are not really components in a strict sense.)‏
In the web-tier container, the components are constructed in the form of web components and web components can be either in the form of servlet or JSP pages while in the EJB-tier container, the components are constructed in the form of EJB beans.
JMS
RMI/IIOP
JDBC
J2SE
J2SE
Database

5. Web Components & Container
Web components are in the form of either Servlet or JSP (along with JavaBean's and custom tags)
Web components run in a Web container
Tomcat and Resin are popular web containers
All J2EE compliant app servers (Sun Java System App Server) provide web containers
Web container provides system services to Web components
Request dispatching, security, and life cycle management
So just to repeat what I just said, web components are in the form of either servlet or JSP pages. And web components run in a web container. And there are a few popular web containers out there, for example, Tomcat and Resin are two most popular web containers.
I said that containers provide host execution environment for the components providing some system services. For web components, the web container provides several system services, for example, receiving service requests from clients and then dispatching them to appropriate web components, and life cycle management of your components. For example, the web container can figure out when it is the time to create an instance of servlet class to handle the incoming service request and when to remove the instance.

6. Web Application & Components
Web Application is a deployable package
Web components (Servlets and JSP's)
Static resource files such as images
Helper classes
Libraries
Deployment descriptor (web.xml file)
Web Application can be represented as
A hierarchy of directories and files (unpacked form) or
*.WAR file reflecting the same hierarchy (packed form)
OK. We have talked a bit on what a web component is, and how web components run in a web container. Now let's talk about a web application. A web application is basically a collection of everything that constitutes a deployable package. The deployable package contains multiple web components, that is, multiple servlets and JSP pages, and static resource files such as images that are part of displayable HTML pages, helper classes that are used by the web components, and library classes and finally deployment descriptor (web.xml file).
A Web application is defined as a hierarchy of directories and files in a standard layout as specified in Servlet specification. Such a hierarchy can be accessed in its unpacked form, where each directory and file exists in the file system separately, or in a packed form known as a Web Application Archive, or WAR file. The former format is more useful during development, while the latter is used when you distribute your application to the target platform.

7. Technologies used in Web Applications.

8. Web Request Handling
In the Java 2 platform, web components provide the dynamic extension capabilities for a web server. Web components are either Java servlets, JSP pages, or web service endpoints. The interaction between a web client and a web application is illustrated in the figure of the slide.
The client sends an HTTP request to the web server. A web server that implements Java Servlet and JavaServer Pages technology converts the request into an HTTPServletRequest object. This object is delivered to a web component, which can interact with JavaBeans components or a database to generate dynamic content. The web component can then generate an HTTPServletResponse or it can pass the request to another web component. Eventually a web component generates a HTTPServletResponse object. The web server converts this object to an HTTP response and returns it to the client.

9. Java Web Application Technologies
Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. Although servlets and JSP pages can be used interchangeably, each has its own strengths. Servlets are best suited for service-oriented applications (web service endpoints are implemented as servlets) and the control functions of a presentation-oriented application, such as dispatching requests and handling nontextual data. JSP pages are more appropriate for generating text-based markup such as HTML, Scalable Vector Graphics (SVG), Wireless Markup Language (WML), and XML.
Since the introduction of Java Servlet and JSP technology, additional Java technologies and frameworks for building interactive web applications have been developed. These technologies and their relationships are illustrated in the figure.

10. Web Application Development and Deployment Steps (using hello2 example under J2EE 1.4 tutorial)‏
Now let's go over the steps needed for the development and deployment of a web application.

11. Web Application Development and Deployment Steps
Write (and compile) the Web component code (Servlet or JSP) and helper classes referenced by the web component code
Create any static resources (for example, images or HTML pages)
Create deployment descriptor (web.xml)
Build the Web application (*.war file or deployment-ready directory)
Deploy the web application into a Web container
Web clients are now ready to access them via URN
So this is the list of steps you will follow in order to develop and deploy a web application. First, you will write and compile the web component code. Web component code is either servlet Java code or JSP pages and helper classes that are used by the web components. You also need to create any static resources such as images or HTML pages. Next, you will create deployment descriptor, that is, the web.xml file.
Then you will build web application. As was mentioned, a web application can be either in the form of *.war file (packed form) or laid-out form of *.war file (unpacked form) as was discussed in previous slide. A *.war file will be a compressed file with the same layout as the build directory.
Then you will deploy the web application to the web container. We will discuss the difference between “installation” and “deployment” later on. (There is a fine distinction between the two.)
Once a web application is deployed, then client can access the web components through the HTML browser. So let's go over each of these steps one by one.

12. 1. Write and compile the Web component code
Create development tree structure
Write either servlet code or JSP pages along with related helper code
Create build.xml for Ant-based build (and other application development life-cycle management) process
IDE (i.e. NetBeans) handles all these chores
So the first step is to write and compile web component code. Now just like any other application development, you might want to create development directory structure that fits your need. As we will see in the following slide, people have recommended directory structure they found suitable for web application development. (This is only a recommendation, of course.)‏
Once you create an appropriate development directory structure, you can then write servlet or JSP along with related helper classes and other pieces. Now another thing people find quite useful is to use ANT build tool for the development and deployment tasks of web applications. As we will see later on, ANT is basically platform independent make utility. And the file that contains the build instructions that ANT uses is called build.xml file.

13. Development Tree Structure
Keep Web application source separate from compiled files
facilitate iterative development
Root directory (example from hello2 sample code from J2EE 1.4 tutorial)‏
build.xml: Ant build file
src: Java source of servlets and JavaBeans components
web: JSP pages and HTML pages, images
To order to facilitate iterative development/deployment and also in order to keep source code separate from compiled files, the source code for the tutorial examples is stored in the following structure under each application directory, for example, for hello1 web application:
build.xml - Ant build file
context.xml - Optional application configuration file
src - Java source of servlets and JavaBeans components
web - JSP pages and HTML pages, images
The Ant build files (build.xml) distributed with the examples contain
*targets for creating an unpacked WAR structure in the build subdirectory of the hello1 application
*targets for copying and compiling files from the src directory to the build directory
*targets for invoking the web container's manager commands to install, reload, remove, deploy, and undeploy applications.

14. Example: hello2 Tree Structure (before “ant build” command)
src/servlets
GreetingServlet.java
ResponseServlet.java
web
WEB-INF
web.xml
duke.waving.gif
build.xml
So this is an example directory structure of hello1 web application you find in the Java WSDP. There are two servlet Java source files. And there is a web directory called web which contains WEB-INF directory and other static resource files.
You will code each web component in the src directory.

15. 2. Create any static resources
HTML pages
Custom pages
Login pages
Error pages
Image files that are used by HTML pages or JSP pages
Example: duke.waving.gif
The next step is to create any static resources that will be used by the web components. And they include some static HTML pages or image files that are used by the HTML pages or JSP pages. And an example of image is duke that you see quite often in various Java-related web pages.
Static resources such as image file are stored in the application's web directory.

16. 3. Create deployment descriptor (web.xml)
Deployment descriptor contains deployment time runtime instructions to the Web container
URL that the client uses to access the web component
Every web application has to have it
The next step is to create deployment descriptor, web.xml file. By the way, the name of this file has to be web.xml file. Now web.xml file contains deployment time and runtime instructions to the web container. For example, you can specify the URN that clients of your web applications will use to access your web components. (We will talk about this URN later on in detail.) Every web application has to have a web.xml file.
The web.xml file is coded and stored in the application's web\WEB-INF directory.

17. 4. Build the Web application
Either *.WAR file or unpacked form of *.WAR file
Build process is made of
create build directory (if it is not present) and its subdirectories
compile Java code into build/WEB-INF/classes directory
Java classes reside under ./WEB-INF/classes directory
copy web.xml file into build/WEB-INF directory
copy image files into build directory
Once you have all the pieces, you can create a web application. As mentioned before, a web application is basically a deployable package that contains everything that is needed for the deployment.
As mentioned before, a web application is either in the form or *.war file (packed) or laid out form of the war file (unpacked). Typically a build process for the web application involves creating “build” directory which functions as the root directory for the compile time generated pieces such as java classes and pieces that are needed to create *.war file such as web.xml file.
For example, the compiled Java classes will end up residing in “build/WEB-INF/classes” directory and web.xml will be copied into “build/WEB-INF” directory and the image files will be copied into the “build” directory itself. Basically the “build” directory is the reflection of directory structure that a particular web container expects (in unpacked form).

18. Example: hello2 Tree Structure (after “asant build” command)‏
src
web
build.xml
build
WEB-INF
classes
GreetingServlet.class
ResponseServlet.class
web.xml
duke.waving.gif
So this is an example of hello1 web application. Once the build process is completed via “ant build” command, “build” directory gets created if it is not present before, and GreetingServlet.class and ResponseServlet.class class files are put into “classes” subdirectory of WEB-INF directory and web.xml file is copied from “web” directory to “build/WEB-INF” directory and image file is copied from “web” directory into “build” directory. Now the build directory is now ready to be taken either as a source directory for creating *.war file (packed form) or can be copied over to web container (unpacked form) for deployment.

19. 5. Deploy Web application
Deploy the application over deployment platform such as Sun Java System App Server or Tomcat
3 ways to deploy to Sun Java System App server
asadmin deploy --port host localhost –passwordfile "c:\j2eetutorial14\examples\common\admin-password.txt" --user admin hello2.war (asant deploy-war)‏
App server admin console
NetBeans
Once you built a ready-to-deployable web application, you can now deploy the application over the web container.

20. 6. Perform Client Access to Web Application
From a browser, go to URN of the Web application
Once your web application has been deployed, then a client (typically a browser) can try to access the web resources by specifying the appropriate URN address.

21.
So for the hello1 example web application, a client will specify to access the hello1 web resource.

22. Running Web Application
This is response html page that gets displayed as a result of the web resource handling of the first HTTP request that comes from the client.

23. Web Application Archive
OK, now let's talk about WAR file.

24. Web Application Web application can be deployed in two different forms
a *.war file or
an unpacked directory laid out in the same format as a *.war file (build directory)‏
Use *.war file when you have to deploy on a remote machine
asant deploy-war command
As was mentioned a couple of times already, a web application can be installed or deployed in two different forms, either as a *.war file (packed form) or unpacked directory that reflects the same directory structure of the *.war file.
Now when you “install”, you can use either form while when you do “deploy” you can use only *.war file. And I will explain why this is the case later on.

25. What is *.WAR file? Ready to deploy'able package over web container
Similar to *.jar file
Contains things to be deployed
Web components (servlets or JSP's)‏
Server-side utility classes
Static Web presentation content (HTML, image, etc)‏
Client-side classes (applets and utility classes)‏
Reflects contents in build directory
So what is war file? It is a ready-to-deployable package over web container. It is like *.jar file and obviously contains things that need to be deployed over the container such as web service components (servlets, JSP pages), server side helper or utility classes, static resources, and sometimes applet classes that would be needed by the client.
As was mentioned before, it reflects the contents of the “build” directory we talked about.

26. Document Root & Context
Document Root of the Web application
Top-level directory of WAR
Contains JSP pages, client-side classes and archives, and static Web resources are stored
Also contains WEB-INF directory
A context is a name that gets mapped to the document root of a Web application
/hello1 is context for hello1 example
Distinguishes a Web application in a single Web container
Has to be specified as part of client URN
Now let's talk about *.war file's directory structure a bit. The top level directory of the war file is called “document root” of the web application. And the “document root” directory contains JSP pages, client side classes and archive file such as applet code and static web resources.
The document root also contains WEB-INF directory.
Now one terminology you have heard many times (but maybe were not sure what it exactly is) is what is called “web application context” or “context” in short. Basically the context is the name of the document root of your web application. For example, /hello1 is the context name of hello1 example. Context is a way to distinguish various web applications in a single web container.
The context has to be specified as part of “request path” that is specified by the client. (We will talk about “request path” later on in this presentation.)‏

27. Directory Structure of *.WAR file
This picture shows the directory structure of *.war file. Please note that the “WebApplicationName” directory reflects the Document root, thus the context.

28. Directory Structure of *.WAR file

29. How to Create *.WAR file? 3 different ways Use IDE (NetBeans)
Use ant tool after putting proper build instruction in build.xml file
“asant create-war” (under J2EE 1.4 tutorial)‏
Use “jar cvf <filename>.war .” command under build directory
So how do you create a *.war file? There are 3 different ways to create *.war file. If you are using an IDE, creating and deploying *.war file gets handled via one or two clicks.
For J2EE 1.4 tutorial sample applications, you can use “asant create-war” command with proper build scripts. Or you can use “jar” command to create the war file. Jar command in this case is like zip utility.

30. Example: Creating hello2.war via “asant create-war” command
C:\j2eetutorial14\examples\web\hello2>asant create-war
Buildfile: build.xml
...
create-war:
[echo] Creating the WAR....
[delete] Deleting: C:\j2eetutorial14\examples\web\hello2\assemble\war\hello2.war
[delete] Deleting directory C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF
[copy] Copying 1 file to C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF
[copy] Copying 2 files to C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF\classes
[war] Building war: C:\j2eetutorial14\examples\web\hello2\assemble\war\hello2.war
[copy] Copying 1 file to C:\j2eetutorial14\examples\web\hello2

31. Example: Creating hello2.war via jar command
C:\j2eetutorial14\examples\web\hello2\build>jar cvf hello2.war .
added manifest
adding: duke.waving.gif(in = 1305) (out= 1295)(deflated 0%)‏
adding: servlets/(in = 0) (out= 0)(stored 0%)‏
adding: servlets/GreetingServlet.class(in = 1680) (out= 887)(deflated 47%)‏
adding: servlets/ResponseServlet.class(in = 1090) (out= 572)(deflated 47%)‏
C:\j2eetutorial14\examples\web\hello2\build>jar xvf hello2.war
created: META-INF/
extracted: META-INF/MANIFEST.MF
extracted: duke.waving.gif
created: servlets/
extracted: servlets/GreetingServlet.class
extracted: servlets/ResponseServlet.class
So in this example, I am creating hello2.war file using “jar” command. Basically you “cd” to “build” directory and then use “jar” command to pick up all the pieces underneath it into the “hello2.war” file. Please don't forget the dot(.) at the end in this example.
In the lower part of the slide, I use “jar tvf” command just to show the contents of the newly created *.war file.

32. WEB-INF Directory Subdirectory of Document root Contains
web.xml : Web application deployment descriptor
JSP tag library descriptor files
Classes : A directory that contains server-side classes: servlets, utility classes, and JavaBeans components
lib : A directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes)
Now what is this WEB-INF directory? WEB-INF directory contains web.xml file, JSP tag library descriptor files (we have not learned this yet so don't worry about it if you don't understand), and “classes” directory that contains servlet classes and “lib” directory that contains various jar files that could contain Java classes that are used by the web components and their helper classes.

33. HTTP request URL & Web component URN (alias) & Context
Request URL: User specified access point of a web resource
path]?[query string]
[request path] is made of context and web component's URN
Context: Name of the root document of a web application – Identifies a particular application on that server
/hello1 is context
Now I would like to talk about how a client can access the web service and explain some related terms.
First “request URL” is user specified access point of a web resource. This is something that is being passed to the web components as part of HTTP request. The typical request URL is made of
path]?[query string]
The [request path] is made of “context” of the web application and the “URN of the web component”. For example, in the case hello1 example, “/hello1” is context and “/greeting” is the URN of the web component. So the [request path] will look like “/hello1/greeting”. Now as mentioned before, context is the name of the root document of the web application. And as a web application developer/deployer, you can choose any name as context name for your application. The context name is specified in the web.xml deployment descriptor.

34. Configuring Web Application via web.xml
Now let's talk about how to configure your web application using web.xml deployment descriptor.

35. Configuring Web Application
Configuration information is specified in web.xml (Web Applications Deployment Descriptor)
Web applications are configured via elements contained in Web application deployment descriptor (web.xml file). You can either manually create web.xml using a text editor of your choice or use a tool.
So let's go over some configuration elements that can be specified in web.xml file.

36. Web Applications Deployment Descriptor (web.xml)
Prolog
Alias Paths
Context and Initialization Parameters
Event Listeners
Filter Mappings
Error Mappings
Reference to Environment Entries, Resource environment entries, or Resources
So this is the list of things that can constitute web.xml file. The most important configuration information that you need to understand is what is called alias paths, which define which URL is mapped to which web components.

37. Web Applications Deployment Descriptor (web.xml)
Case sensitive
Order sensitive (in the following order)
icon, display-name, description, distributable
context-param, filter, filter-mapping
listener, servet, servlet-mapping, session-config
mime-mapping, welcome-file-list
error-page, taglib, resource-env-ref, resource-ref
security-constraint, login-config, security-role
env-entry, ejb-ref, ejb-local-ref
Not only elements in web.xml are case sensitive, they are also order-sensitive. In other words, the elements in web.xml file has to be defined in a specific order that is specified in the Servlet specification. This slide shows the ordered list of configuration elements if they are present in the web.xml (many of them are optional).

38. Prolog (of web.xml) Every XML document needs a prolog
<?xml version="1.0" encoding="ISO "?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "
Since the deployment descriptor is an XML document, it requires a prolog. The prolog of the web.xml file is as follows:
<?xml version="1.0" encoding="ISO "?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN" "

39. Alias Paths (of web.xml)
When a request is received by Servlet container, it must determine which Web component in a which web application should handle the request. It does so by mapping the URL path contained in the request to a Web component
A URL path contains the context root and alias path
Alias Path can be in the form of either
/alias-string (for servlet) or
/*.jsp (for JSP)‏
When a request is received by Tomcat it must determine which Web component should handle the request. It does so by mapping the URL path contained in the request to a Web component. A URL path contains the context root and an alias path
Before a servlet can be accessed, the Web container must have least one alias path for the component. The alias path must start with a / and end with a string or a wild card expression with an extension (*.jsp, for example). Since Web containers automatically map an alias path that ends with *.jsp, you do not have to specify an alias path for a JSP page unless you wish to refer to the page by a name other than its file name.

40. Alias Paths (of web.xml)
<servlet>
<servlet-name>greeting</servlet-name>
<display-name>greeting</display-name>
<description>no description</description>
<servlet-class>GreetingServlet</servlet-class>
</servlet>
<servlet-name>response</servlet-name>
<display-name>response</display-name>
<servlet-class>ResponseServlet</servlet-class>
<servlet-mapping>
<url-pattern>/greeting</url-pattern>
</servlet-mapping>
<url-pattern>/response</url-pattern>
So in order to set up mappings of Hello application in the Web deployment descriptor, you must add “servlet” and “servlet-mapping” elements to the web.xml file. (By the way, to define an alias for a JSP page instead of a servlet, you must replace the servlet-class subelement with a jsp-file subelement in the servlet element.)‏

41. Error Mappings (of web.xml)‏
Maps status code returned in an HTTP response to a Java programming language exception returned by any Web component and a Web resource
<error-page>
<exception-type>exception.OrderException</exception-type>
<location>/errorpage.html</location>
</error-page>
Error mapping information is also specified in the deployment descriptor. That is, an application exception can be mapped into a custom error page. Or an HTTP response can be mapped to a Java exception, like in the example above. Otherwise, a default error page will be displayed.

42. References (of web.xml)
Need when web components make references to environment entries, resource environment entries, or resources such as databases
Example: declare a reference to the data source
<resource-ref>
<res-ref-name>jdbc/BookDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Now references. When web components make references to environment entries or resource environment entries, or resources such as databases, you can also specify information on those in the deployment descriptor. And in this example, a declaration to the data source is specified.

43. Example web.xml of hello2
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns=" version="2.4" xmlns:xsi=" xsi:schemaLocation="
<display-name>hello2</display-name>
<servlet>
<display-name>GreetingServlet</display-name>
<servlet-name>GreetingServlet</servlet-name>
<servlet-class>servlets.GreetingServlet</servlet-class>
</servlet>
<display-name>ResponseServlet</display-name>
<servlet-name>ResponseServlet</servlet-name>
<servlet-class>servlets.ResponseServlet</servlet-class>
<servlet-mapping>
<url-pattern>/greeting</url-pattern>
</servlet-mapping>
<url-pattern>/response</url-pattern>
</web-app>
So this is the complete web,xml file of the hello1 web application. Given that hello1 is rather simple web application, the only thing its deployment descriptor specifies is servlet and its mapping to URNs. For example, the part in the blue color specifies information about the servlet such as name and servlet classes and the part in the red color specify the mapping between servlet and their URNs. These URNs are the ones that clients use when they access the web components. And when the web container receives the URN from a client, it knows which servlet classes to invoke by looking at the deployment descriptor's servlet mapping elements.
Other elements of the deployment descriptor and how they are used are referenced in future classes.

44. Summary & Questions?
That’s all for today!
Fall 2007
cs420