NetBeans: WebApps
Web Apps Component-Based Development User View
Last changed: October 23, 2002
Changes: available in
CVS
Author: Petr Jiricka, Sun Microsystems/NetBeans
- Abstract:
- This document analyzes the development and deployment cycle of Java Web Applications from the point of view of development tools, and suggests reasonable decomponentisation of such applications at development time, and steps to accomplish assembly and deployment.
- Contents:
The main purpose of this document is to describe the deployment environment of Java Web Applications, and to design a physical development structure that would be best suited for developing web apps from the points of view of ease of use, flexibility, integration with external development, build and deployment tools, integration with versioning systems, and which would well support the development of reusable web components in an intuitive manner.
This document does not intend to suggest or prescribe the presentation of the development objects in the IDE, and intends to be independent of particular techologies and concepts of the IDE, such as projects, filesystems, explorer trees etc. It even attempts to be independent of a particular IDE used.
The development structures commonly used for developing Java Web Applications include the structure which exactly matches the contents of the .war (used in the Sun ONE Studio 4.0 release), the structure which allows Java classes to exist outside the WEB-INF/classes directory (used in the Forte for Java 2.0 and 3.0 releases), and the structure which builds the web module to a separate directory, described and recommended by the Jakarta web site: [LINK]. One of the goals of this document is to explain the motivations behind the individual development-time structure, and to generalize the concepts used by them.
Section 2 of this document describes the deployment environment of web applications. Section 3 analyzes how this environment (and its individual parts) can be represented in an IDE at development time. Section 4 describes how the development-time environment is assembled into the deployment environment.
This section describes what is the deployment environment for Web Applications. The complete deployment environment of a single web module may consist of the following:
- The Web Module itself, packaged in a .war file, which further (logically) consists of:
- Documents - these are the files put directly under the web module's document base and it subdirectories, including JSP pages, HTML files, images and other resources, and including any documents put under the
WEB-INF directory, but excluding classes in WEB-INF/classes, libraries in WEB-INF/lib, and other files listed below.
- Classes and resources used by the classes - any
.class, .properties and other files placed under the WEB-INF/classes directory that the web module uses.
- Java libraries packaged as
.jar files under the WEB-INF/lib directory.
- Packaged Tag Libraries, represented as
.jar files under WEB-INF/lib. Furthermore, the .tld files which define these tag libraries may be extracted in the WEB-INF directory of the web module.
- Tag Libraries which are not packaged - these may consist of classes under
WEB-INF/classes, of tag library descriptors under WEB-INF and of .tag (and .tagf) files under WEB-INF/tags.
- Standard deployment information represented by the deployment descriptor
WEB-INF/web.xml.
- Applet jar files included under the document base (not under
WEB-INF/lib).
- The URI Mapping (a.k.a. the Context Path) for this web module.
- Libraries deployed directly to the server that the web module may need, and libraries present on the server by default.
- Server-specific deployment information (a.k.a. deployment plan), which specifies the behavior dependent on a particular server.
- The alternative deployment descriptor (
alt-dd element in the application.xml file, if the web module is delivered as a part of a J2EE application.
This section discusses the desirable treatment of the individual subparts of the WebApps deployment environment at development time, especially the web module.
In the simplest setup, web modules developed in a filesystem structure that corresponds to an unpacked image of the
.war file. That way, the only thing needed to prepare the web module for deployment is to package this structure to a
.war file. This has the advantage that the only piece of information the user has to specify in order to assemble the application is the location of the
.war file. In the case that the server supports in-place deployment, the
.war file does not even need to be created. So one advantage of this approach is a very simple and easily maintainable assembly process.
Another advantage is that some parts of this organization (e.g. the Document Base) have a clear development structure, which matches well how the user thinks about this particular part of the application (content of a website), so it is more comprehensible. For example, if a JSP page links to another page by a relative HTML link, then the user can rely that the location of the second page relatively to the first one in the filesystem will correspond to this link.
A third big advantage of this approach is the ease of integration with standard third-party tools. So for example JSP compilers provided by servers can make sense of the physical setup, and the use of Ant as a build tool is possible and easy.
However, the main disadvantage of the above approach is the fact that this setup imposes a particular physical structure on the user, even if in the IDE this structure may be presented in a different way. The implication is that it is more difficult to use shared libraries, to separate Java sources from the web module, versioning operations become more cumbersome, it is not possible to specify varying (standard) deployment information for different physical deployment targets, and similar. To alleviate this problem, the physical development structure should be more decoupled from the deployment structure, which would give to give the user a reasonable degree of flexibility, while retaining (some of) the advantages of the strict physical setup.
In the following sections we attempt to find the right tradeoff between the advantages of the strict physical structure, and the advantages of a user-defined free-form structure. We identify the necessary constraints of the physical location of individual components of a web module, and areas where decoupling the development-time location from the deployment-time location is possible and practical.
The document base holds all files which are served by the server as "content", which includes JSP files, HTML files, images and other resources. This also specifically includes any resources which are developed in the
WEB-INF directory, in order to better enforce access control policies of the application. For the deployment purposes, it also makes sense to consider the non-packaged tag libraries, the standard deployment descriptor and applet
.jar files as belonging to the document base. Later in this section we will discuss whether this also makes sense to do for development purposes.
The question arises whether it makes sense to further decompose the "content" of the application so it is allowed to develop individual JSP files, HTML files, images and other resources in separate physical locations. Such a request would make sense from the point of view which argues that JSP files are "reusable components" in the sense of J2EE, which do not need to have the knowledge of each other when being developed - only when being dropped to a web application such knowledge is needed. However, in practice, JSPs (not mentioning HTML files and images) are
not reusable components in this sense, for the following reasons:
- JSPs use tag libraries. In order to interpret a JSP correctly at development time, it is necessary to know where the tag libraries it uses are located. To accomplish this, the JSP must be located in the correct location w.r.t. the document base.
- JSPs have links. In order to interpret links in JSP and HTML pages correctly at development time, it is necessary to know the relative mutual location of these documents. This can only be accomplished if the documents are located relatively to the document base.
- JSPs interact with controller servlets. This implies that the JSP must know its target web module, which has the knowledge of the controller servlets logically belonging to it.
The above analysis implies the following constraint that must be met by the development structure for the content of web applications:
Content of web applications must at development time be placed relatively to the document base directory, and associated with a "logical web module" object, which has the knowledge of other components, such as libraries, tag libraries and servlets belonging to this web module.
If this condition was not met, it would become impossible to implement many core features of the Web Apps support in the IDE, such as:
- JSP coloring and completion. These features rely on the knowledge of tag libraries used by the JSPs.
- JSP syntax checking. In order to intepret a JSP and assess its correctness, the context of the web module is important.
- Link checker. A hypothetical feature that checks whether the application contains broken links.
Also, integration with external build tools, such as Ant, would become extremely difficult.
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
[PENDING]
