Deploying EJB Applications


There are three basic ways to deploy an EJB application, or any other J2EE application, in a WebLogic Server environment:

  • Automatic deployment

  • WebLogic deployer utility or Ant tTask

  • WebLogic Console deployment

These three methods were examined in the context of deploying Web applications in Chapter 5. Most of the same rules, best practices, and limitations discussed in that chapter apply to their use with EJB and enterprise applications. In this section, we ll briefly discuss preparing the environment for deployment and then walk through the deployment process for the bigrez.com enterprise application using two of the methods, automatic deployment and WebLogic Console deployment. See Chapter 5 for a discussion of the WebLogic Deployer Utility and wldeploy Ant task.

Creating Required Services

Before attempting to deploy an EJB application or enterprise application, you should configure the required services (JDBC connections, JMS resources, etc.) in the server environment. Although some applications may deploy properly without the required services, applications with container-managed persistence (CMP) entity beans, message-driven beans (MDBs), or startup components requiring services will not deploy.

When a CMP entity bean component is deployed, for example, WebLogic Server tests that the JDBC DataSource defined in the bean descriptor file is available and that the underlying database contains the table and column information defined in the CMP bean. This test is repeated for each CMP bean in the EJB archive file. All beans must pass the test, or none of them will be deployed successfully.

When an MDB component is deployed, the server will attempt to connect the MDB to the JMS destination defined in its descriptor file. If the JMS destination is not available the server will display an error message in the log and attempt to reconnect to the destination periodically until it is available. This will not stop the MDB from deploying, although it will not operate properly until the JMS resource is created.

As a general rule, you should configure the required services and resources before attempting to deploy the application.

Best Practice  

Create and configure all required services and resources before attempting to deploy the application.

The bigrez.com application uses a JDBC DataSource in the CMP entity beans, a JMS queue in the ReservationSessionBean stateless session bean and Email-_ProcessingBean MDB component, and a JavaMail Session object in the EmailProcessingBean . All of these services and their underlying resources should be configured before deploying the application.

Creating services and resources in a single-server development environment is fairly easy. The WebLogic Console provides straightforward screens for creating resources in the current domain. Rather than walk through each screen in detail we will simply list the required resources for bigrez.com and provide specific configuration information as a reference.

The JDBC resources required by bigrez.com in the development environment are the following:

  • A JDBC connection pool named BigRezPool connected to the development database. The specific driver class name , URL, properties, and password obviously depend on your database. The new JDBC Connection Pool Wizard will help you select the proper values. See the WebLogic Server online documentation at http://edocs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection__pools.html or your database documentation for more information. This pool must be targeted to the current server and should have Maximum Capacity set to at least four connections.

  • A JDBC DataSource that Honors Global Transactions named BigRezDataSource using the BigRezPool as its underlying connection pool. This DataSource should use the JNDI name BigRezDataSource and must be targeted to the current server as well.

The JMS resources required are the following:

  • A JMS FileStore called JMSFileStore configured to use the ./jmsstore directory to persist JMS messages. Create an empty jmsstore directory below the domain root directory (the directory containing the config.xml file) to hold the JMS message files.

  • A JMS ConnectionFactory called BigRezEmailConnectionFactory using the default values for all message, transaction, and flow-control param-eters. The default values are sufficient for development and unit test purposes. Chapters 9 and 11 will discuss best practices and provide configuration param-eters suitable for a production environment. Don t forget to target this resource to the server.

  • A JMS Server called JMSServer configured to use the JMSFileStore and targeted to the server. All other configurations parameters can be left with default values.

  • A JMS Queue called BigRezEmailQueue in the JMSServer configured to use the JNDI name BigRezEmailQueue . Target the queue to the current server. It is also a good idea to set the Redelivery Limit to a reasonable number (3 “5) rather than leaving it at the default value of -1. The default value allows unlimited redeliveries of the message in the case of errors in the component processing the message. All other parameters can use default values.

The final resource required by bigrez.com is a JavaMail Session resource used to send outgoing email. The name and JNDI name should be BigRezEmailSession , and the properties should be similar to the following with the placeholder information replaced with valid smtp information:

 mail.smtp.user=nyberg mail.transport.protocol=smtp mail.smtp.host=mail.mymail.com mail.smtp.password=something 

Target this resource to the current server, and you are done configuring resources for bigrez.com .

The domain is now ready for the deployment of the bigrez.com enterprise application using either the exploded directory structure or the single archive file. We ll discuss the two recommended approaches for deployment in the next two sections.

Automatic Deployment

Because we discussed automatic deployement at some length in Chapter 5 we will simply review the technique here and present the steps required to deploy the bigrez.com application.

First, ensure that automatic deployment is enabled by setting the PRODUCTION__MODE variable in the server boot script to the value false . The administration server will now scan the applications directory in the domain for new (or modified) application archives and exploded directory structures during each boot process and periodically during server operation.

Next, copy the bigrez.ear archive file or the entire rezapp exploded application structure to the applications directory in the domain. The server can be running, if desired, although with exploded applications it is usually best to copy the structure with the server stopped to avoid the race condition discussed in Chapter 5.

Note that the makeapp and dist targets in the build.xml script served to deploy the exploded application to the local domain by creating the exploded directory structure and copying all of the required files to the proper locations in that structure. In other words, we designed the Ant scripts to employ automatic deployment on the developer s workstation whenever we issue the dist target.

Automatic redeployment of the application occurs whenever the bigrez.ear file is overwritten or the META-INF/REDEPLOY file is touched and its timestamp changes. These rules were discussed at length in Chapter 5. The build.xml file includes a useful target, redeploy , which touches the REDEPLOY file and causes a redeployment in a running server:

 <target name=redeploy>   <touch file=${deploy.dir}/META-INF/REDEPLOY/> </target> 

Automatic deployment is a very useful technique for deploying exploded and archived enterprise applications in a single-server development or test environment. The ability to redeploy the application without rebooting the server or accessing the WebLogic Console is very useful during development. As Chapter 11 will discuss, however, automatic deployment can be problematic in production environments with multiple servers and should be avoided in these environments.

Best Practice  

Use automatic deployment on developer workstations and other single-server environments to eliminate manual deployment steps and provide quick redeployment of modified applications. Avoid its use in production and multiple server environments.

WebLogic Console Deployment

Chapter 5 also walked through the process of deploying a simple Web application using the WebLogic Console. Deploying an enterprise application to a single server environment is very similar to deploying a Web application. The process involves the following steps:

  1. Start the WebLogic Server instance in production mode by including PRODUCTION_MODE=true in the startWebLogic script.

  2. Copy the exploded archive file or .ear file to the applications directory or any other desired directory.

  3. Deploy the application using the administration console.

As in Chapter 5, the first two steps are self-explanatory. Using production mode disables the automatic deployment of archives and directory structures placed in the applications directory, allowing you to control this deployment manually through the console. The application may be placed in the applications directory, as in the automatic deployment case, or it may be placed in any desired directory on the server. We suggest a directory such as myapps in the domain directory structure to avoid confusion.

The remaining steps to deploy an enterprise application follow the same general process outlined in Chapter 5 for a Web application:

  1. Start the server and open the WebLogic Console.

  2. Open the list of current applications deployed in the server using the Applications link on the left side of the screen.

  3. Click the Deploy a new Application link on the right side. Use the supplied screens to navigate to the location of your new application, and select the application archive file or root directory to be deployed.

  4. Continue the process by targeting the new application to your server, giving it a name, and clicking the Deploy button to deploy the application.

  5. Use the standard application tabs and screens to modify the deployment information if required.

The application is now deployed and ready for users.

As long as automatic deployment remains disabled via PRODUCTION_MODE=true , changes to the enterprise archive file or REDEPLOY file will not be sensed by the server and no redeployment will occur automatically. Use the WebLogic Console to redeploy a modified application by selecting the application using the link on the left side of the screen and employing the deployment features provided on the right (see Figure 8.14). The application may also be undeployed using this screen, a function that eliminates the application components from the server but does not remove the file or directory structure from the disk.

click to expand
Figure 8.14:  Use WebLogic Console to redeploy applications.

Deploying applications using the WebLogic Console is appropriate for complex test and production environments requiring better control of the process than provided by automatic deployment. It is not required for single-server environments in which the automatic approach properly deploys the application.

Best Practice  

Manual deployment of applications using the WebLogic Console is more appropriate for complex test and production environments involving multiple servers and clustering.

We didn t cover the WebLogic Deployer Utility or wldeploy Ant task in this section, but that does not mean they are inappropriate as deployment techniques. As stated in Chapter 5, these tools provide a viable alternative for deploying and redeploying applications in WebLogic Server. Choose the option that best meets your needs.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net