Using and Deploying Web Applications
Topics in This Chapter
The purpose of Web applications
The structure of Web applications
Web application registration
Development and deployment strategies
Web application data sharing
Web applications (or "Web apps") let you bundle a set of servlets, JavaServer Pages (JSP) pages, tag libraries, Hypertext Markup Language (HTML) documents, images, style sheets, and other Web content into a single collection that can be used on any server compatible with the servlet specification. When designed carefully, Web apps can be moved from server to server or placed at different locations on the same server, all without making any changes to any of the servlets, JSP pages, or HTML files in the application.
This capability lets you move complex applications around with a minimum of effort, streamlining application reuse. In addition, because each Web app has its own directory structure, sessions, ServletContext, and class loader, using a Web app simplifies even the initial development because it reduces the amount of coordination needed among various parts of your overall system.
1.1. Purpose of Web Applications
Web applications help you in three main ways: organizing your resources, portably deploying your applications, and keeping different applications from interfering with each other. Let's look at each benefit in a bit more detail.
The first advantage of Web applications is that you know where everything goes: Web apps have a standard location for each type of resource. Individual Java class files always go in the directory called WEB-INF/classes, JAR files (bundles of Java class files) always go in WEB-INF/lib, the web.xml configuration file always goes in the WEB-INF directory, and so on. Files directly accessible to clients (e.g., Web browsers) go into the top-level directory of your Web app or any subdirectory under the top-level directory except WEB-INF.
In addition, it's very common for developers to move from one project to another. Having a standard way of organizing your application's resources saves you from having to come up with an application structure every time you start a new project and it also saves a new developer joining your project from having to learn your particular file organization.
Because the servlet specification provides a specific file organization, any compliant server should be able to deploy and run your application immediately. This affords you much freedom in choosing the vendor of your Web server. As long as a server is compliant, you can pick up your application and, with almost no changes, deploy and run it on a server from a different vendor, thus avoiding the dreaded "vendor lock-in." For example, you could start developing your applications using a free Web server and move to a more established, vendor-supported server closer to deployment time.
Different Web applications deployed on the same server do not interfere with each other. Each application has its own uniform resource locator (URL) with which it can be accessed, its own ServletContext object, and so on. Two Web applications deployed on the same server act as if they were deployed on separate servers. Neither needs to know about the other.
This further simplifies development and deployment of Web applications. The developer doesn't have to be concerned with how the application will integrate with the existing applications already deployed on the server. Now, as we will see later in this chapter, there are a few ways in which Web applications can deliberately interact with each other. However, for the most part, they can be developed independently.