14.3 Deploying the applicationIn this section, we show the steps required to deploy the application to WAS. We show you how to deploy a regular EAR file as well as an Enhanced EAR file, and then also how to not honor the configuration information packaged into the Enhanced EAR file. Follow these steps to deploy the application:
From the install windows, install files that are located either on the same machine as the browser you are using to access the WebSphere console, the local file system option, or on the WAS itself, the remote file system option. If you select the Local file system option, the console automatically uploads the file you select to the appserver, or to the deployment manager if this is a distributed server environment. If you select the Remote file system check box, you can browse all the nodes in the cell to find the file. The file is then, if necessary, uploaded to the appserver or deployment manager.
For this example, however, we will explain the options, so select Show me all installation options and parameters. Then click Next.
In this example, the bindings were set in the application EAR file using the Application Server Toolkit and there is no need to override them. The defaults are also correct. Table 14-1
Application default bindings
The rest of the wizard is divided into steps. The number of steps depends on your application, for example, if it contains EJB modules or Web modules, you will see windows prompting for the information necessary to deploy them.
Step 1 gives you a chance to review the installation options. You can specify various deployment options, such as JSP precompiling, and whether you want to generate EJB deployment code. If you are deploying an Enhanced EAR file, this is where you make the decision whether to use the resource configuration information packaged in the Enhanced EAR file or not. If the EAR file you are installing is an Enhanced EAR, the install window preselects the Process embedded configuration check box. If you do not want to use the resource configuration information packaged in the Enhanced EAR file, deselect this check box. Selecting the Pre-compile JSP option makes WebSphere compile all JSPs in the EAR file during install time. This causes the time-consuming task of JSP compilation to be performed during install time instead of during run time, preventing the first user that accesses the application to pay that penalty. A second alternative to pre-compile JSPs is to use the JspBatchCompiler script found in the bin directory of the profile you are using to compile the JSPs after the application has been installed. This page also allows you to specify file permissions for files in your application. To use one of the predefined file permissions, select it, and then click Set file permissions. You can also specify your own file permissions using regular expressions.
The following is an example of a version number: Implementation-Version: V1.2.3
To enable this feature, select the corresponding check boxes to allow dispatching or servicing includes to/from remote resources. For more information about this feature, search the InfoCenter for Remote request dispatcher. Click Next.
Select the server on which you want each module deployed. For better performance, we recommend that you deploy all modules from one application in a single server. Especially, do not separate the EJB clients, usually servlets in Web modules, from the EJBs themselves. Click the
Figure 14-9 Mapping modules to appservers
A single EAR file can contain multiple database mappings. At deployment time, you can choose which one you want to use. In this case, set it to DB2UDBNT_V82_1, because this is the version we are using. Click Next.
Allows you to configure if and how often WebSphere should check for updates to JSP files, and if they should be reloaded or not. In a production environment, you may want to disable this to improve performance. Click Next.
If your application depends on shared libraries, you can specify them here. For more information about using shared libraries, see Shared libraries. Click Next.
Use this window to bind the enterprise beans in your application or module to a JNDI name. In 13.3.1, Defining EJB JNDI names, we defined these values in Table 13-1, so the defaults shown should be correct. Click Next.
Each EJB reference defined in your application must be mapped to an enterprise bean. We used the Application Server Toolkit to do this in 13.3.2, Binding EJB and resource references. Click Next.
Specify the default data source for the EJB 2.x module containing 2.x CMP beans. In 13.3.3, Defining data sources for entity beans, we defined the JNDI name for the EJBs in the PlantsByWebSphere EJB module as eis/jdbc/PlantsByWebSphereDataSource_CMP. You see this in the window. Click Next.
Specify an optional data source for each 2.x CMP bean. Mapping a specific data source to a CMP bean overrides the default data source for the module containing the enterprise bean (defined in step 8, (12). We do not need to do anything here. Click Next.
Each resource reference defined in the application must be mapped to the corresponding resource. The PlantsByWebSphere EJB module has several resource references for data sources, which are shown in this window. Click Next. At this step, we now get an Application Resource Warning. What this tells us is that a resource referenced by the application, mail/PlantsByWebSphere, is not defined for the scope to which we are installing our application. In fact, it is not defined at all in our environment because we will not send any e-mails from the Plants by WebSphere. If you would like to do that, you should define a Mail session with the properties for your mail server and assign it a JNDI name of mail/PlantsByWebSphere. Click Continue.
For each Web module, select the virtual host we created for the application (plantsbywebsphere_host). Click Next.
For each Web module, select the context root to bind the module against. Click Next.
Because the Plants by WebSphere EAR file contains security roles, we need to map them to users and groups in our target environment. However, because we have not enabled application security, WebSphere will not authenticate users trying to access the application. As a result, we do not need to map the roles to users and groups. Click Next.
By default, EJB methods are unprotected. On this window, you can elect to refuse all calls to unprotected methods, or specify which methods you want to exclude. Again, because we have not enabled J2EE security, WebSphere will not authenticate users trying to access the EJBs. Click Next.
The Summary window gives an overview of application deployment settings. If those settings are fine, click Finish to deploy the application.
If you are working in a distributed server environment, make sure you synchronize the changes with the nodes so they application is propagated to the target appserver (s).
Deployment is now complete. You can now launch the Plants by WebSphere application by pointing your browser to: http://www.plantsbywebsphere.com:9081/PlantsByWebSphere Verify the host name is one of the names you added to the plantsbywebsphere_host definition. See 14.1.5, Creating the virtual host for IBM HTTP Server and Apache. Because the DB2 PLANTS database is now empty, it must be populated with data before the application will work. An administrative servlet is supplied for that purpose.
After the database has been populated, you can test the application. |
icon to select all modules in the 
