Virtual and Physical HTTP Resources

One of the many responsibilities of the Web server is to map URL requests to physical resources on the Web server: static files, scripted dynamic files, or compiled components and APIs. The simplest systems have a one-to-one mapping between a URL and a physical file, with the URL context mapping directly to a file system directory and all the directory paths in the locationtext between the slashes, /mirrored in the subdirectories of the file system.

Figure 12-8 shows a URL hierarchy; the root identifies the protocol (http:), the name of the host (localhost), and the application context (appcontext). Each of the requestable resourcesHTML, JSP, GIF encoded filesis shown with the fully qualified URL. Note that regardless of the type of resource that is identified in the «virtual root» hierarchy, the «HTTPResource» symbol is the same because from the client's point of view, the nature of the file is irrelevant to making the actual request for the resource. For example, it is possible to specify a JSP resource as an image file. Of course, it is expected that the output of the correct MIME type will be set and that the JSP output is encoded as a binary image, not as HTML, which is the norm.[2]

[2] This is a common mechanism for managing and delivering image files from a database instead of from the file system.

Figure 12-8. Virtual file system hierarchy

In a simple mapping, each resource maps to a file, and the «physical root» maps to a directory in the Web server's file system. Figure 12-9 shows a Web server's file system in which the directory web maps to the «physical root» http://localhost/appcontext/.

Figure 12-9. File system containing static and dynamic pages, as well as static resource files

Simple mappings are not always the case. For example, whenever servlets are used, their class filesor the JAR file they are contained inare not located in this physical file system hierarchy with the rest of the system's JavaServer Pages. In J2EE applications, the mapping is located in the web.xml file, and each servlet can be mapped to an arbitrary URL.

These two hierarchiesthe virtual URL hierarchy and the physical component file hierarchyare not required to overlap, and can each be completely arbitrary. The mapping between the virtual resources (URL) and the physical file is architecturally significant and as such should be modeled. The only way to do this is to define two types of hierarchies: the «physical root» hierarchy, defined in the previous chapter, and a new component hierarchy, the «virtual root», a hierarchy of component proxies. Each of these proxies is modeled in with an «HTTP Resource» stereotyped component. The two new WAE stereotypes are summarized as follows.

When modeling systems that override the default URL resolution mechanisms, J2EE systems use servlets, or systems that use compiled binary components to filter or respond to specific URLs.

Figure 12-10 is Figure 11-12, redrawn to define the element Search as a servlet.[3] The component view for the Web elementsclient pages, server pages, and servletsis shown in Figure 12-11, in which the HTTP resource component Search is drawn with a dependency to a normal component, the Search servlet component. Both the virtual and the physical root packages have tag values that set their host and Web context values to be the same. This is often the case when there is a mix of servlets and JavaServer Pages.

[3] This icon and the stereotype «Http_Servlet» is the Rational Rose default for reverse-engineering servlets.

Figure 12-10. Class diagram with Web elements for standard searching functionality

Figure 12-11. Component diagram showing components and URLs that realize the classes in Figure 12-10

Figure 12-12 shows the realizations of the logical classes in Figure 12-10 by the components in Figure 12-11. In Figure 12-12, the HTTP resource component does not realize a logical-view class directly but rather is a proxy to another component, the Search servlet component.

Figure 12-12. Web components and the logical-view elements they realize

An HTTP resource component should identify what it is a proxy for, via a dependency relationship to another component or by realizing a logical-view element that eventually does get realized by a "hard" component of the system. In systems that rely heavily on reusable screen components, often no single JSP realizes any given screen and so any given URL. In these situations, it is convenient to model HTTP resource components as realizing UX model screensor an equivalent logical-model constructthat in turn identifies the logical-view Web elements that make up the screens compartments. Each of these constructs is realized by a normal Web component in the system.

Figure 12-13 shows how an HTTP resource can realize a UX model screen, which in turn is mapped to several design model logical elements: server pages and client pages. These page elements are eventually realized by Web page components, or servlets. In this diagram, the package owning the Web components is not stereotyped «physical root». The reason is that these individual Web components are not intended to be individually requested by the client but rather exist solely to contribute to the realization of the screen.

Figure 12-13. UX model screens can be realized by HTTP resource components

In some situations, it might be useful to model resources other than Web pages. The following components can be included in Web component packages.