In this article, we will look at the structure and deployment of web application. This will build on the previous article, Tutorial: Review of HTTP Methods and Servlet API for the Web Component Developer Exam, where we provided an overview of the Servlet Technology Model that is the basis for most of the components of the web tier. Here we will look at the file and directory structure of a Web Application and all the other elements that are required for creating a proper web application. This is part of a series of articles to help you prepare for the web component developer exam.

Web Applications and their Structure

In the previous article, we didn’t go into detail about the all of the file and directory structure of a web application, as well as what configuration that needs to be performed in order to produce a robust and secure web application.

Your web application consist of sets of servlets, JavaServer Pages (JSP) pages, tag libraries, Hypertext Markup Language (HTML) documents, images, video, audio, style sheets, and other Web content that can be used on any server compatible with the servlet specification. A well designed web application is portable across the majority of web servers without requiring changes to any of the servlets, JSP pages or HTML files within the application. Additionally, each web application has it’s own session, servlet context and class loader as well as directory structure. This design ensures a sufficient level of coordination between the various components of the application while allowing separation from other applications that could be running on the same web server. This overall design allows web applications to help you and your business in a number of ways. We will discuss these below.

Standard Organization of Web Application

One of the benefits of web applications is that they have a standard location for were all the various resources that comprise a web application must go in order to work properly across web servers. Below is outlined the location of most of the standard parts of a web application:

This standard way of organizing an application reduces start up time for new applications as well as reducing ramp up time for a new developer who joins an existing project. The figure below shows the standard locations for web applications deployed to Tomcat:

￼Figure: Standard Locations for Tomcat Web Applications

Portability of a Web Application

The standardization of the Servlet Technology Model including the standardization of the location of the web application’s resources means that any web server that complies with the the Java Servlet specification should be able to deploy and run any standard web application. The benefit of this is avoiding vendor lock-in as well as forcing vendors to compete on features that matter most to you and your organization and the price. This is because the vendor knows that if you are not satisfied with the performance, power, ease of use, support and cost of their web server, that it wouldn’t be difficult for you to redeploy your application on another web server.

Separation of Applications via the Servlet Context

When different web applications are deployed on the same web server, the Java Servlet Technology Model has been designed in such a way that the web applications don’t interfere with each other. The two ways in which this is done is that each application will have its own uniform resource locator (URL) with which it is used to access it’s functionality and its will have it’s own ServletContext object in order to communicate with the web server. Finally a key point to note is that when your web application is running in a web server, when your web server receives a request from a client, it is not the web application that handles the request but the web container in which your application is deployed. The container then gives your web application, the HTTP request and response and it calls the appropriate method from your web application. This is one of the key ways that web applications are kept separate while running in the same web server. So although one can have numerous web applications deployed on the same web server, for each web application they run as if they are deployed on separate servers since in the majority of cases, they will never need to know about the other. Again this standardization facilitates both the development and deployment of web applications. Neither developer nor the administrator, they don’t need to concern themselves with how the web application will integrate with existing applications on the web server. Only if there is a reason for the web applications to communicate with each other, there is a standard means of accomplishing this (normally through the ServletContext).

Structure of a Web Application

As we can see from the figure showing the organization of a Tomcat deployment web applications have a standardized format that is portable across all compliant Web or application servers. The top-level directory of the Web application (called MyTestApp in the figure) is simply a directory with a name of your choosing. Underneath this directory, is a clearly defined organization where designated types of content go in designated locations. Below we will go into the details of these different content types and their locations.

Individual Servlets, Beans, and Helper Classes

As you know from our previous article, “Tutorial: Review of HTTP Methods and Servlet API for the Component Developer Exam”, Servlets are Java classes that are designed to respond with dynamic content to client requests over a network. Similar to all Java classes these files are placed either in WEB-INF/classes or a subdirectory of WEB-INF/classes that matches their package name. Access to a particular servlet is done by specifying a URL using the servlet-mapping element in the web.xml deployment descriptor file. This files is located in the WEB-INF directory of the Web application. An example of this is shown below:

An alternative way for you to access the servlet is by specifying a URL with the prefix servlet after the web application prefix, then the package name and finally the name of the servlet. An example of this is shown below:

XML Code: Syntax for URL

http://hostServer/appPrefix/servlet/packageName.ServletName

This is fine when you may be testing your servlet, but it is not recommended that you use this approach for production web applications. You want to avoid situations where there are multiple paths for accessing your servlets. This can create problems in maintaining your applications as well as a potential security hole for people to gain access to your application. Another issue is that writing a URL with all this information is not only ungainly but difficult for any user to remember. Finally if you do any refactoring to your application and modify the packages, you will need to update any files where you have entered this URL. Best Practice is to explicitly block users from accessing the servlets of your web application without mapping a custom URL. See the listing for the servlet-mapping element above for more information.

Servlets, Beans, and Helper Classes

Often you will leverage existing packages that could contain servlets or other .class files providing functionality to your application. This could be JDBC connectivity, security or a number of other key areas of your application. These classes generally are bundled inside JAR files, and the JAR files are placed in WEB-INF/lib directories. Most of these JARs will be prepackaged but if you are leveraging existing functionality from your organization, make sure that the classes are within packages and that they are in the proper directory structure that matches their package name within the JAR. On most web servers, JAR files can also be shared across multiple Web applications. You need to check the documentation of your web application provider to find out where shared JARs are to be located. On Tomcat, shared JAR files are placed in the in tomcat_dir/shared/lib directory.

JSP Pages

A JSP is a page that the servlet container will translate into a compiled full-fledged Java servlet class. The original JSP pages are placed in either the top-level web application directory or in a subdirectory with a name related to it’s subject. The reason why is that web servers are prohibited from serving files in the directory WEB-INF or in a subdirectory of WEB-INF to the user. When an web application is registered with the server container, a URL prefix is provided that is associated with the web application and indicates where the web application directory is located. Common practice is to use the name of the main Web application directory as the URL prefix (i.e. myTestApp). Afterwards all JSPs can be accessed with URLs that have the the unique name of the server, an optional port, the directory path to the location of the JSPs on the server and finally the JSP. An example is shown below:

XML Code: Syntax for JSP URL

http://hostServer/appPrefix/filename.jsp

In this case, the JSP pages are located in the top-level directory of the Web application. If they were in a subdirectory it would look something like the following:

XML Code: Syntax for JSP located in subdirectory

http://hostServer/appPrefix/subDirectory/filename.jsp

If you choose, a particular JSP can be the default file name. In this case, you will need to make this explicit by updating the welcome-file-list entry in the web.xml file with the name of your JSP. An example of this is shown below:

As far as the servlet and JSP engine is concerned, HTML files, GIF and JPEG images, style sheets, and other Web documents follow exactly the same rules as do JSP pages. They are placed in exactly the same locations and accessed with URLs of exactly the same form.

The Deployment Descriptor - web.xml

A deployment descriptor, web.xml file is a key aspect of your web application. It provides the configuration requirements of your web application in an XML format. In the web.xml file, your web container will find all the information to:

register and create the URL mappings for your servlets

register or specify any of the application's listeners and filters

specify the context init parameter name/value pairs

configure any error pages

specify the application's welcome pages

configure session timeouts

specify security settings that control who can request which web components

The web.xml file, is placed in the WEB-INF subdirectory of the web application directory. Generally the web.xml is web application specific. There are some application servers that allow you to have a global file for all Web applications. In Tomcat this is located in the following directory:
tomcat_dir/conf/web.xml

This file is used only for global configuration settings that you want to apply to all web applications. An example of an web.xml file is shown below:

Key things to note are that there is one servlet, MyTestServlet which is accessed at path <context path>/mytestservlet. The session timeout is set at 15 minutes for the application and Sessions time out in 15 minutes with this application and for any case that a URL cannot be found, the web container will forward the request to the error404.jsp page. This is shown in the <error-page> configuration. There is a filter called MyRequestFilter that is applied to both dynamic and static content requests in this context. Finally the web container will create an instance of the listener class, MyReqListener at startup.

Tag Files

Tag files are used to create custom actions to be used in JSPs. You might already be using some in your web application in the JSP Standard Tag Library (JSTL). This library is most likely already included in your application in a JAR in the WEB-INF/lib directory. But for functionality for your application that is not standard you will most likely build your own custom tag handler for doing this. To create and use custom tags, there are three components that you will need to do:

Create a tag handler class that defines the tag’s behaviour

Create the tag library description (TLD) file that maps the XML element to the tag implementation

Apply the tags to one or more JSP files

Creating a new tag requires that you define a Java class that implements the functionality that you want the tag to accomplish. Your tag will next to extend the SimpleTagSupport which implements the SimpleTag interface and supplies standard implementation for key methods. An example of a tag handler class is shown below:

Your tag handler class should be placed in the WEB-INF/classes directory under the proper subdirectory that aligns with the package structure. The tag files are placed under WEB-INF/tags. Even though the tag files are located inside the protected WEB-INF directory, they are still accessible to your JSP pages. You can also declare tag files from inside a JSP page by using the taglib directive. You only need to use the tagdir attribute. An example of how to do this for a JSP page is shown below:

XML Code: Example of tagdir Attribute

<%@ taglib tagdir="/WEB-INF/tags" ...%>

Here, the server automatically generates the tag library descriptor (TLD) for the tag files. You don’t need to do any custom mapping. You can also bundle tag files into a JAR file. In this case, the JAR file is placed inside of the WEB-INF/lib directory. In this situation the server doesn’t automatically generate the TLD so you need to place the tag files inside of the directory as well as declare the tag file and its path within a .tld file.

Tag Library Descriptor Files

Along with the tag handler you have created to provide the functionality needed for your web application, you will need to provide a tag library descriptor in order to associate the class with the chosen XML tag name. An example of a tag library descriptor is shown below:

Below is a description of the elements that are found within the TLD:
description (optional) - to document the purpose of the custom tag.
name - defines the name of the tag as it will be referred to by the JSP page (is actually a tag suffix).
tag-class - identifies the fully qualified name of the implementing tag handler class.
body-content - tells the container how to treat the content between the beginning and ending occurrence of the tag. This can be either empty, scriptless, tagdependent, or JSP.

The Tag Library Descriptor (TLD) files should be placed inside of the WEB-INF directory or any subdirectory of WEB-INF. Best practice is to put them in a directory within WEB-INF. If you group them in a common directory for TLDs this simplifies their management. You can then have the JSP pages access the TLD files that are in WEB-INF in the following manner using the taglib directive:

XML Code: Taglib Directive with WEB-INF directory

<%@ taglib uri="/WEB-INF/tlds/myTaglibFile.tld" ...%>

You can do this because the TLD is accessed by the server. So there is no prohibition that content inside the client cannot access the TLD file. If you decide to deploy within a JAR file, the .tld file should be placed inside the directory or any subdirectory of META-INF because JAR files are not Web application archives and don’t contain a WEB-INF directory.

WAR Manifest File

The last element for a deployment (at least on Tomcat) is to create a WAR file with a MANIFEST.MF file placed in the META-INF subdirectory. You can use the standard Java archive (jar) tools in order to package and sign your web applications into a WAR file. The jar utility will automatically create the MANIFEST.MF file for you and put it into the META-INF directory. For example, you might have an application for issue tracking that was distributed in an archive file called tracker.war. When packaged into a WAR file, a META-INF directory will be present containing information useful to Java archive tools. But you don’t want this directory to be directly served by the container as content in response to a Web client’s request, despite its contents being visible to servlet code via the getResource() and getResourceAsStream() methods on the ServletContext. Also, any requests to access the resources under the META-INF directory should be returned with a SC_NOT_FOUND(404) response.

The key thing to remember about the directory structure of any web application is that there is a public directory structure consisting of HTML/XML documents, JSP pages, images, applets, etc that the container serves theses directory's contents against incoming requests and a private part under the WEB-INF directory consisting of the following files and directories:

tags/ - containing Tag files (to be accessed by JSPs without the need to write a TLD file).

This private web structure has the following format:

￼

Figure: Format of WEB-INF Directory Structure

The final step to prepare the web application for deployment is to package it in a WAR file using the jar utility command from the top-level directory of the application. An example of using the jar utility is shown below:

Java Code: Example of jar Utility Use

jar cvf MyTestProj.war

The additional options provided cvf represent the following:

c - create a jar file

v - generate verbose output

f - specifies the file jarfile to be created.

The last parameter MyTestProj is just the web application name.

Installing and Executing Your Web Applications

In this section we will look at installing and executing your application. In order to do this I think it is important that we do this from the standpoint of going from the development environment for your web application to its installation and execution on a web server. So I’m going to create a web application called MyTestApp. We will start from the standard development directory structure. I’m going to do this within Eclipse but you can choose to do this within any development environment of your choosing. It will be more or less the same. Below is the directory structure for the development environment.
￼

Figure: Development Directory Structure

This directory structure is the same irrespective of what application or web server that you use. As well you access the files located in this directory structure with URLs of exactly the same form. In the figure above, we are creating a web application called, MyTestProj. Note that the directory structure and URLs would be similar to what we mentioned before. For example, the main URL for the web application would be the following:

XML Code: URL for MyTestProj Web Application

http://www.acme.com/mytestproj

This assumes that we are access the page defined in the welcome list. Even though we can see that the standard directory structure, configuration and URLs help to facilitate the portability of the web applications across numerous web server, registering a web application is a process that is server specific. For example, moving MyTestProj application from Tomcat to JBoss doesn’t require that you modify anything within the directories shown in the figure above. However, the location of the top-level directory for MyTestProj is placed in a different location with JBoss (dependent on which server configuration you use). Also the process to tell the server the mapping of URLs to a particular URL is server-specific. In the following section we will outline how to deploy an application to JBoss 6.1.

Looking to Deploy in JBoss

Deploying a web application into JBoss is relatively straight forward. All that needs to be done is to distribute the WAR or EAR file into the appropriate server under the JBoss server directory. Let’s start at the JBoss home directory. Here there are five sub-directories. These are listed below:

bin – this directory contains numerous scripts and associated files. This includes the “run” scripts for starting JBoss in Windows, Unix or Linux environments.

client – stores both configuration and jar files that are needed by Java client applications or external web containers. You have the choice of using the archives when needed or using the jbossall-client.jar.

docs – holds the XML DTDs used in JBoss for reference as well as example JCA1 configuration files for setting up datasources for various databases (i.e. MySQL, Oracle, Postgres, etc).

lib – contains the jar files which are needed to run the JBoss microkernel.

server – each of the subdirectories corresponds with a different server configuration. You select the configuration desired by passing the option “-c <config name>” to the run script.

JBoss Server Configurations

The JBoss architecture is at it’s core a JMX MBean server instance (the “microkernel”) and a set of pluggable component services – the JMX MBeans. Through this design you have the flexibility and ease of use to setup different configurations to meet your needs. There is no need to start up all the components. It is quite easy to configure it only for the services that you need.

Out of the box, JBoss provides three example configurations: all, default and minimal, each of which installs a different set of services. If you don’t pass any parameters to the run script, JBoss will use the default configuration. Below we will discuss each configuration.

default - this configuration provides a base setup in order to run a stand-alone J2EE server.

minimal – this configuration provides the bare minimum required to start JBoss. The services started are the logging service, a JNDI server and a URL deployment scanner to find new deployments. If you wanted to use JMX/JBoss to start your own services while avoiding any J2EE services, this is the configuration that you would use.

all – this configuration will start up all available services. This will start up all the J2EE services including RMI/IIOP, clustering services as well as the web-services deployer.

Depending on your needs, it is quite straightforward to add your own configuration. Unless you have a script that already will do this for you, the quickest way to accomplish this is to copy an existing one that has the majority of services required for your application and then to modify the contents. For example, if you wanted to use a commerce server like ATG Commerce, on installation, the system will create a new configuration called ATG. If you want to run this configuration you would do the following:

Java Code: Startup of JBoss with New Server Configuration

run -c atg

Irrespective of which server configuration you use, the directory for that server configuration becomes the effective directory while JBoss is running. It contains all the code and configuration information that is needed for the MBeans. It is where you will deploy your application. For every server configuration, there is a standard directory structure. The list of the subdirectories are provided below:

conf – contains the jboss-service.xml file where core services are specified as well as any additional configuration files for the identified services.

data – where the embedded Hypersonic database instance stores its data and where JBossMQ stores messages on disk.

deploy – location of where your application code is deployed (jar, war and ear files). All you need to do is to place the archive file here. You also use this directory for deploying services which can be added or removed from a running server (also known as hot-deployable services.) and JCA resource adaptors. This directory is constantly scanned for updates and any modified components are re-deployed automatically.

lib – contains jar files required for this server configuration. Including in this is library files for JDBC, or Commerce Servers, etc.

log – contains any logs generated by your applications. JBoss uses the Jakarta log4j package for logging. You can use it directly in your own applications from within the server if so desired.

tmp – used as temporary storage of unpacked applications by the deployer.

work – used by Tomcat (the web container for JBoss) for compiling JSPs.

These directories are automatically created by JBoss when the server is run for the first time. When you define a new server configuration, it works in exactly the same manner. You will need to run the server once before the sub directories are created.

JBoss’ Web Container – Tomcat

As mentioned above, Tomcat is now the default web container for JBoss. The embedded Tomcat service is expanded in the deploy directory from the jbossweb.sar Server Archive Resource (SAR) file. There are all of the JAR files needed by Tomcat as well as a web.xml file providing the default configuration for web applications. In any case, there is a Tomcat service that is running looking for any annotations that you may have used for configuring the service. Otherwise you can use the existing xml configuration files either in the jbossweb.sar directory or the jbossweb.sar/META-INF directories. In the META-INF directory holds the main service file, jboss-service.xml. You use this to configure the org.jboss.web.tomcat.tc5.Tomcat5 MBean which is used to control Tomcat. Below is the list of configurable attributes:

DefaultSecurityDomain: used to specify the JAAS security domain to use in the absence of an explicit security-domain specification in the jboss-web.xml of a WAR file.

Java2ClassLoadingCompliance: enables the use of the standard Java2 parent delegation class loading model instead of the servlet model which would load classes first from the WAR. The default for this is true. Setting this to false will enable the servlet class loading model. In this case, you will need to organize your deployment package to avoid duplicate classes in the deployment.

UseJBossWebLoader: indicates that Tomcat should use a JBoss unified class loader as the web application class loader for classes inside of WEB-INF/classes and WEB-INF/lib directories of the WAR file. The default for this is true.

LenientEjbLink: indicates that ejb-link errors should be ignored in favor of trying the jndi-name in the jboss-web.xml. The default for this is true.

ManagerClass: is a class used as the session manager for replicating the state of web applications marked as distributable. org.jboss.web.tomcat.tc5.session.JBossCacheManager is the only provided implementation of a session manager used by JBossCache to track the distributed state.

SubjectAttributeName: represents the request attribute name under which the JAAS subject will be stored. The default is for this to be not undefined.

SessionIdAlphabet: is the set of characters used to create a session IDs. All 65 characters in this set must be unique.

SnapshotMode: sets the snapshot mode in a clustered environment. Possible values are instant mode in which changes to a clustered session are propagated instantly when there are modifications or interval mode which periodically propagates all modifications based on the following attribute, SnapshotInterval.

SnapshotInterval: sets the snapshot interval in milliseconds for the interval snapshot mode. The default value is 1000ms or 1 second.

UseLocalCache: indicates whether the local HTTP session value should be used if it exists. If set to true, the existing local HTTP session values are used and updates are replicated, but not on other clustered nodes (useful for failover). If it is set to false, the session value is obtained from the distributed cache (useful for load balancing). The default for this is true.

UseJK: specifies the use of MOD_JK(2) for load balancing with sticky session combined with JvmRoute. If set to true, JvmRouteFilter will be inserted to intercept every request and replace the JvmRoute if it detects a failover. In this case, JvmRoute must be set inside the engine definition in the Tomcat server.xml file. The default for this is false.

Domain: the JMX domain under which Tomcat will register additional MBeans. The default domain is jboss.web.

SecurityMangerService: is a reference to the JAAS security manager for Tomcat to use. The default is jboss.security:service=JaasSecurityManager.

Configuring the Server.xml File

The server.xml file is used by Tomcat to guide the operation of the Tomcat integration service. This file can be found in the jbossweb.sar directory. The is no DTD or schema definition for it. The Server element is the top level configurable element. It should alway have a Service element that represents the entire web subsystem. The configurable attributes supported are:
name: The unique name for the service.

className: The fully qualified class name that provides the service implementation.

Connector Element

A connector configures the transport mechanism that allows clients to send requests and receive responses from the Service element associated with it. You use connectors to forward requests to the engine and return the results to the requesting client. Each of the connectors is configured via the Connector element. There are a number of attributes that you can configure for connectors. Please see Tomcat documentation in order to know more.

The Engine Element

There is a one to one relation between a Service an Engine configuration. The engine handles requests submitted to a service via the configured connectors. The child elements are supported by the embedded service. This includes Host, Logger, Valve and Listener elements. Below is the list of supported attributes:

className: The fully qualified class name of the org.apache.catalina.Engine interface implementation to use. The default is org.apache.catalina.core.StandardEngine.

defaultHost: is the name of the Host configured under the Engine for handling requests with host names that don’t match a Host configuration.

name: is the logical name assigned to the Engine.

The Host element represents a virtual host configuration for web applications with a specified DNS hostname. The child elements supported include Alias, Valve and Listener. The following attributes are supported:

className: The fully qualified class name of the org.apache.catalina.Host interface implementation to use. The defaults is org.apache.catalina.core.StandardHost.

name: The DNS name of the virtual host. At least one Host element should be configured with a name corresponding to the defaultHost value of the containing Engine.

The Alias Element

You can use an Alias element as an optional child element to the Host element. It would specify an alternate DNS name for the enclosing Host.

The Valve Element

A Valve element configures a hook into the request processing pipeline for the web container. Valves must implement the org.apache.catalina.Valve interface. There is only one required configuration attribute:
className: The fully qualified class name of the org.apache.catalina.Valve interface implementation.
Normally, the commonly used valve is the AccessLogValve (i.e. org.jboss.web.catalina.valves.AccessLogValue) which was used to keep a standard HTTP access log of incoming requests. Other attributes of the valve element are:

directory: the directory path into which the access log files will be created.

pattern: specifies the format for the log message using this pattern. The default is common.

prefix: the prefix added to each log file name. The default value is access_log.

suffix: the suffix added to each log file name. The default value is an empty string.

The Context.xml File

The context.xml file provides the default Context element used for all web applications in the system. It has the following attributes:
cookies: the flag indicating if sessions will be tracked using cookies. The default value is true.
crossContext: the flag indicating whether the ServletContext.getContext(String path) method should return contexts for other web applications also deployed in the calling web application's virtual host.

Setting the Context Root of A Web Application

The next thing you need to do is to set the context root of your web application. The context root determines the URLs Tomcat delegates to your web application. So for our application, the context root is /mytestproj or /mytestproj/*. The context root for an application is determined by how it is deployed. If a web application is deployed within an EAR file, the context root is specified in the application.xml file of the EAR using the context-root element that is already inside of the web module. Below is the application.xml file for the mytestproj project.

If your web applications are deployed outside an EAR file, the context root can be specified either in the WEB-INF/jboss-web.xml file or if no context root is specified, the context root will default to the base name of the WAR file. An example of what a jboss-web.xml file for mytestproj would look like the following:

XML Code: Example of JBoss-Web.xml File

<jboss-web.
<context-root>mytestproj</context-root>
</jboss-web>

The only case where the name of the WAR file will not be the base name is if you have an WAR file called ROOT. This is because JBoss already has a ROOT.war web application in the jbossweb.sar directory. In this case you will need to delete or rename your application.

Deploying a Web Application in JBoss

As Tomcat is running as an embedded service. This means that JBoss is in charge. You should never need to access the Tomcat directory. Your web application is deployed via the JBoss deploy directory and logging output for your application from Tomcat will be found in the JBoss log directory. In general you can accept the default configuration for Tomcat.

Now to deploy our web application, MyTestProj in JBoss. After creating and building all the resources and files for the application, we generate the WAR and EAR files for the application. If there are any configuration that needs to be done in relation to the elements we discussed previously, now is the time to do them. You can do this either by including these configuration files in the EAR to be deployed or you can complete the configuration after the web application is deployed. If you have included the configurations into the EAR file, now we put the EAR file into the deploy directory for the default directory. Once the EAR file is deployed, you make what changes you wish to the configuration, and restart the server and check the output from the server to ensure that there are no errors.

If there is any errors, make the necessary corrections, rebuild the WAR and EAR files and then redeploy the application. You can redeploy the application safely even if it is already deployed. To remove the application, you just need to remove the archive from the deploy directory. Once it is deployed correctly without any errors, you are now ready to point your browser at the application. The application URL is the following:

XML Code: MyTestProj URL

http://localhost:8080/MyTestProj

The process of deploying a web application to other servers is quite similar. In most cases, you will only need to deploy a WAR file whereas in JBoss it is recommended that you deploy an EAR.

OK. That’s it. We have covered all the key aspects as well as the steps that you need in order to deploy a web application. We didn’t cover things related to web security but we will cover that in a later article. Next we move on to the Web Container Model.