Structure of a Java EE Web Module

In the Java EE platform, web components provide the dynamic extension capabilities for a web server. Web components can be Java servlets, web pages implemented with JavaServer Faces technology, web service endpoints, or JSP pages. Web components are supported by the services of a runtime platform called a web container. A web container provides such services as request dispatching, security, concurrency, and life-cycle management. A web container also gives web components access to such APIs as naming, transactions, and email.

Web components and static web content files, such as images, are called web resources. A web module is the smallest deployable and usable unit of web resources.


The J2EE standard prescribes a directory structure for web applications that controls both where files should reside and what visibility they will have from the perspective of the visiting web browser. The top-level directory of a web module is the document root of the application. The document root is where XHTML pages, client-side classes and archives, and static web resources, such as images, are stored.

The document root contains a sub directory named WEB-INF. The WEB-INF directory is mandatory in a web application. Although WEB-INF is directly under the document root, it should be considered to be out of the accessible path and is invisible to a visiting web browser. It can contain the following files and directories:

• classes: A directory that contains server-side classes: servlets, enterprise bean class files, utility classes, and JavaBeans components

• tags: A directory that contains tag files, which are implementations of tag libraries

• lib: A directory that contains JAR files that contain enterprise beans, and JAR archives of libraries called by server-side classes

• Deployment descriptors, such as web.xml (the web application deployment descriptor) and ejb-jar.xml (an EJB deployment descriptor)

• The META-INF, this directory is only relevant for use within a war file, where it is mandatory and performs a role very similar to the WEB-INF directory of a non jarred web application. If you create a META-INF directory within your application root the contents will not be directly visible from a visiting web browser. However because the META-INF directory only has relevance for war files it should not be present in a production (non war) environment and it is common practice to only create it for the purpose of generating the directory structure for a war file

A web module needs a web.xml file if it uses JavaServer Faces technology, if it must specify certain kinds of security information, or if you want to override information specified by web component annotations.

You can also create application-specific subdirectories (that is, package directories) in either the document root or the WEB-INF/classes/ directory.

A web module can be deployed as an unpacked file structure or can be packaged in a JAR file known as a Web Archive (WAR) file. Because the contents and use of WAR files differ from those of JAR files,WAR file names use a .war extension. The web module just described is portable; you can deploy it into any web container that conforms to the Java Servlet specification.

Web Application Types

A web application is a dynamic extension of a web or application server. Web applications are of the following types:

• Presentation-oriented: A presentation-oriented web application generates interactive web pages containing various types of markup language (HTML, XHTML, XML, and so on) and dynamic content in response to requests.
• Service-oriented: A service-oriented web application implements the endpoint of a web service. Presentation-oriented applications are often clients of service-oriented web applications.

Web Application Life Cycle

The process for creating, deploying, and executing a web application can be summarized as follows:

1. Develop the web component code.
2. Develop the web application deployment descriptor, if necessary.
3. Compile the web application components and helper classes referenced by the components.
4. Optionally, package the application into a deployable unit.
5. Deploy the application into a web container.
6. Access a URL that references the web application.

Structure of a Java EE Application

 

A Java EE module consists of one or more Java EE components for the same container type and, optionally, one component deployment descriptor of that type. 

Java EE modules are of the following types:

• EJB modules, which contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.
• Web modules, which contain servlet class files, web files, supporting class files, GIF and HTML files, and a web application deployment descriptor. Web modules are packaged as JAR files with a .war (web archive) extension.
• Application client modules, which contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension. 
• Resource adapter modules, which contain all Java interfaces, classes, native libraries, and other documentation, along with the resource adapter deployment descriptor. Together, these implement the Connector architecture for a particular EIS. Resource adapter modules are packaged as JAR files with an .rar (resource adapter archive) extension.

An Enterprise Archive (EAR) file contains Java EE modules and, optionally, deployment descriptors. 

Deployment Descriptor

A deployment descriptor, an XML document with an .xml extension, describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. 


At runtime, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly, i.e. with specific container options, security settings and describes specific configuration requirements.

In Java EE, there are two types of deployment descriptor: 

•  Java EE deployment descriptors, and 
•  Runtime deployment descriptors 

 A Java EE deployment descriptor is defined by a Java EE specification and can be used to configure deployment settings on any Java EE compliant implementation. For example, the web.xml file is a standard Java EE deployment descriptor, specified in the java servlet specification. 

A runtime deployment descriptor is defined by the vendor of each container implementation.It is used to configure Java EE implementation-specific parameters. For example, the GlassFish Server runtime deployment descriptor contains such information as the context root of a web application, as well as GlassFish Server implementation-specific parameters, such as caching directives. The GlassFish Server runtime deployment descriptors are named sun-moduleType.xml and are located in the same META-INF directory as the Java EE deployment descriptor.