Web Application Architecture (Based J2EE 1.4 Tutorial)
Web Application Architecture (Based J2EE 1.4 Tutorial)
Web Application Architecture (Based J2EE 1.4 Tutorial)
In this session, I am going to talk about what a typical Web application looks like. I will also show you how to build a Web application by going through step by step guideline. Most of the contents in this presentation is made from Chapter 4: Web Application tutorial section of Java WSDP.
07/30/2006
Even though Sang Shin is a full-time employee of Sun Microsystems, the contents here are created as his own personal endeavor and thus does not reflect any official stance of Sun Microsystems. Sun Microsystems is not responsible for any inaccuracies in the contents. Acknowledgments
The slides of this presentation are made from Web Application section of J2EE 1.4 tutorial written by Sun Microsystems
07/30/2006
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 Web application deployment descriptor (web.xml file)
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.
07/30/2006
07/30/2006
JDBC
JAF
JAF
J2SE
RMI
RMI/IIOP
J2SE
JDBC
JNDI
JMS
J2SE
Database 5
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.
JDBC
JNDI
JMS
JNDI
JTA
JMS
JTA
JavaMail
JavaMail
07/30/2006
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
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.
07/30/2006
Web components (Servlets and JSP's) Static resource files such as images Helper classes Libraries Deployment descriptor (web.xml file) A hierarchy of directories and files (unpacked form) or *.WAR file reflecting the same hierarchy (packed form)
7
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.
07/30/2006
07/30/2006
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.
07/30/2006
10
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
07/30/2006
Web Application Development and Deployment Steps (using hello2 example under J2EE 1.4 tutorial)
11
Now let's go over the steps needed for the development and deployment of a web application.
11
07/30/2006
12
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
07/30/2006
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
13
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
07/30/2006
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
14
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
07/30/2006
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
07/30/2006
HTML pages
Example: duke.waving.gif
16
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
07/30/2006
Deployment descriptor contains deployment time runtime instructions to the Web container
17
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
07/30/2006
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
?
copy web.xml file into build/WEB-INF directory copy image files into build directory
18
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/WEBINF/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
07/30/2006
Hello1 src web build.xml build ? WEB-INF classes ? GreetingServlet.class ? ResponseServlet.class web.xml ? duke.waving.gif
19
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
07/30/2006
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 4848 --host localhost passwordfile "c:\j2eetutorial14\examples\common\adminpassword.txt" --user admin hello2.war (asant deploy-war) App server admin console NetBeans
20
Once you built a ready-to-deployable web application, you can now deploy the application over the web container.
20
07/30/2006
21
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
07/30/2006
http://localhost:8080/hello1/greeting
22
So for the hello1 example web application, a client will specify http://localhost:8080/hello1/greeting to access the hello1 web resource.
22
07/30/2006
23
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
07/30/2006
24
07/30/2006
Web Application
?
a *.war file or an unpacked directory laid out in the same format as a *.war file (build directory)
25
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
07/30/2006
? ?
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)
26
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
07/30/2006
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
27
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
07/30/2006
28
This picture shows the directory structure of *.war file. Please note that the WebApplicationName directory reflects the Document root, thus the context.
28
07/30/2006
29
29
07/30/2006
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
30
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
07/30/2006
31
07/30/2006
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
07/30/2006
WEB-INF Directory
? ?
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)
33
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
07/30/2006
HTTP request URL & Web component URN (alias) & Context
?
http://[host]:[port]/[request path]?[query string] [request path] is made of context and web component's URN http://localhost:8080/hello1/greeting?username=Monica
Context: Name of the root document of a web application Identifies a particular application on that server
/hello1 is context
34
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 http://[host]:[port]/[request 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
07/30/2006
Now let's talk about how to configure your web application using web.xml deployment descriptor.
35
07/30/2006
36
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
07/30/2006
Prolog Alias Paths Context and Initialization Parameters Event Listeners Filter Mappings Error Mappings Reference to Environment Entries, Resource environment entries, or Resources
37
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
07/30/2006
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
38
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
07/30/2006
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/webapp_2_3.dtd">
39
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-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
39
07/30/2006
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
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 http://<host>:8080/context_root/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
07/30/2006
41
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 servletclass subelement with a jsp-file subelement in the servlet element.)
41
07/30/2006
Represents application context Can be shared among Web components in a WAR file
<web-app> ... <context-param> <param-name> javax.servlet.jsp.jstl.fmt.localizationContext </param-name> <param-value>messages.BookstoreMessages</param-value> </context-param> ... </web-app>
42
The Web components in a WAR share an Java object that represents their application context, which is referred to as context object. And you can set name-value pairs to the context object so that all web components in the same web application can have access to the name-value pairs that are saved in the context object. In order to initialize the name-value pairs, you add a context-param or init-param element to the web.xml file. The context-param is a sub-element of the top-level web-app element. The initparam is a subelement of the servlet element. This slide shows an element used to declare a context parameter that sets the resource bundle used in the example discussed in Chapter 16 of Java WSDP Servlet tutorial:
42
07/30/2006
43
You can also specify life cycle events, which we will talk about when we talk about Servlet later on in this course. (If you don't understand life cycle events for now, that is fine.) Life-cycle events are only specified in the deployment descriptor if you have them coded as part of your application.
43
07/30/2006
This is the filter mappings. Filters are software components that intercept incoming HTTP requests and outgoing HTTP responses and perform whatever functions such as caching, logging, compression, or transformations. And these filters can be chained and plugged during deployment time to achieve desired behavior. And which filters ought to be plugged in and how they get chained are specified in the deployment descriptor. Filter and filter-mapping descriptors are only coded in the deployment descriptor if you have servlet filter components. These are optional elements in the deployment descriptor. Again we will talk about filter when we talk about advanced servlets. And you don't really have to understand filters for now.
44
07/30/2006
Maps status code returned in an HTTP response to a Java programming language exception returned by any Web component and a Web resource
45
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.
45
07/30/2006
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>
46
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.
46
07/30/2006
47
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.
47
07/30/2006
Passion!
48
48