InfoCenter Home > 6.6.8: Administering Web applications (overview)The servlets and JavaServer Pages (JSP) files in a Web application share a servlet context, meaning they share data and information about the execution environment, including a Web application classpath. Approaches to configuring Web applicationsThere are two basic approaches to configuring Web applications. The administrator can configure a Web application:
To configure a Web application from the bottom up, the administrator can first explicitly configure the individual servlets that will eventually comprise the Web applications. When configuring a servlet, the administrator specifies the name and location of the servlet class file, and other information necessary for enabling the administrator to manage the servlet. The administrator can combine one or more explicitly-defined servlets and Web resources into an Web application, allowing them to be managed as a logical unit (the Web application). Because they are explicitly configured, the servlets can also be managed individually. For example, the administrator can unload a servlet from the Web application without causing the rest of the application to become unavailable to users.
The administrator can also configure a Web application from the top down. This technique might be familiar to an administrator who has used Web server products or IBM WebSphere Application Server Version 2. Instead of explicitly defining each component (servlet, Web page, and so on), the administrator specifies the directories in which he or she plans to place the components of each type. In the simplest case, each Web application has one directory for servlets and another for Web resources. Any servlet placed in the designated servlet directory becomes part of the Web application, and similarly any Web pages and JavaServer Pages (JSP) files are picked up from the designated Web resource directory. Because the servlets are not explicitly defined, they cannot be managed or monitored individually.
Web applications inside enterprise applicationsA Web application can be part of an enterprise application (an "application" for short). In the simplest case, an enterprise application is simply a "wrapper" for a Web application -- the files that comprise the application are exactly the same files that comprise the Web application. In such a case, why bother to add a Web application to an enterprise application? An enterprise application help file discusses the benefits. In a more complex case, an application might contain multiple Web applications and (in the case of IBM WebSphere Application Server Advanced Edition) some enterprise beans as well. Configuring Web applications directly in WebSphere systems administrationThe administrator should understand a few main settings as he or she configures Web applications:
The administrator can also specify properties such as:
Classpath considerationsAn important classpath-related setting to note is the Module Visibility. This application server setting impacts the portability of applications and standalone modules from other WebSphere Application Server versions and editions. If your existing module does not run as-is when you transfer it to Version 4.0, you might need to reassemble an existing module or change the module visibility setting. See the information on setting classpaths for a full discussion of classpath considerations. See the application server property reference for information about the module visibility setting. Identifying a welcome page for the Web applicationThe default welcome page for your Web application is assumed to be named index.html. For example, if you have an application with a Web path of: /webapp/myappthen the default page named index.html can be implicitly accessed using the following URL: http://hostname/webapp/myapp
|
| ||
|