Wednesday, September 8, 2010

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.

No comments:

Post a Comment