Deploying Applications to WebLogic Server

WebLogic Server 7.0 introduces new features, which guarantee homogeneous deployment across clusters, different application staging strategies, application ordering, tracking a deployment task, and an improved deployment API as well as new tools that facilitate deployment. The following subsections discuss all these new features.

Two-Phase Deployment

WebLogic Server 7.0 introduces a new deployment model called two-phase deployment , which helps to maintain consistency in the deployment of applications across servers in a WebLogic cluster. This deployment model guarantees that an application is either deployed on all the servers in a cluster or none, thus preventing inconsistent deployment of applications.

Using the two-phase deployment model, the deployment of applications occurs in two phases: the prepare phase and the activate phase .

• Prepare phase: In this phase, the applications are validated and distributed to the target servers. Necessary error checking is completed to ensure that the application and its components are in a state from which they can be reliably deployed to the target WebLogic Servers. In other words, applications are prepared for deployment. The client cannot access the application yet.

• Activate phase: In this phase, the actual deployment of the application and its components takes place. The application is activated on the target WebLogic Servers and made available to the clients. Only after the successful completion of this phase are the clients able to access the application. This phase proceeds only if the prepare phase of the deployment has been successful on all the servers in the WebLogic cluster.

If either of the phasesprepare or activatefails on any WebLogic Server in a cluster, the WebLogic cluster deployment fails.

For example, consider what would happen in a typical failure scenario in which you have two WebLogic Servers (m1 and m2) in a WebLogic cluster. The prepare phase succeeds on both the servers, which means the application has been validated and the files have been copied over to the target servers. The commit succeeds on m1, but fails on server m2 for some reason. In this failure case, the application deployment on m1 would be rolled back, which would result in a homogeneous deployment state. That is, the application would not be deployed on any of the servers in the cluster. The user can then check to see why the deployment failed on m2, correct the problem, and start the deployment task again. The two-phase deployment feature hence prevents inconsistent deployment states across clustered WebLogic Servers.

Application Staging

During the prepare phase of a two-phase deployment, application files are copied from the source on the Administration Server to a staging directory on the managed server. This copying of application files to a location on the file system from where they can be deployed is called application staging . Staging consists of three factors:

• Should the application files be copied?

• Where should the application files be copied?

• By whom should the application files be copied?

Each server has a staging mode, which controls these factors. We'll discuss how the staging mode can be set later in this section. The three staging modes in WebLogic Server are as follows :

• nostage: In this mode, the application files aren't copied to any location. The application is deployed from the source directory itself. This is the default staging mode for the Administration Server.

• stage: In this mode, the application files are copied by the Administration Server to a preconfigured staging directory on those managed servers to which the application is targeted . This is the default staging mode for managed servers.

• external_stage: In this mode, the application files are copied to the managed server's staging directory, but not by WebLogic Server. The server assumes that a user or some third-party tool will perform the distribution of application files.

Setting the Staging Mode and Staging Directory

The staging mode controls whether the application files are copied, the location to which they're copied, and by whom. You can set the staging mode through the Administration Console using the following steps:

1. Start the Administration Server and access the Administration Console.

2. Select the domain name in the navigation tree in the left pane.

3. Click the server's node in the left pane for which you have to set the staging mode and staging directory.

4. Click the Configuration, Deployment tab in the right panel. From the displayed screen, as illustrated in Figure 27.3, select the staging mode you require from the drop-down list box.

   Figure 27.3. Set the staging mode, staging directory, and upload directory for an Administration Server.

   

   On the screen shown in Figure 27.3, you can also set the following attributes:

   • Staging Directory: This is the directory on the server to which the application files are copied during the prepare phase of the two-phase deployment. If an absolute path isn't specified, the path is relative to the root directory; that is, the directory from which the server instance is started.

   • Upload Directory: This is the directory where all the uploaded applications are placed. This attribute can be configured only for the Administration Server because applications can be uploaded only to the Administration Server.

5. Click the Apply button so that the preceding settings are saved in the configuration file of the Administration Server. Because these attributes are not dynamic, you must restart the server for the changes to take effect.

The attributes discussed earlier are MBean attributes of weblogic.management.configuration.ServerMBean . These can also be set using the JMX API or the weblogic.Admin utility. Each application also has a StagingMode attribute, which can be set on its corresponding application MBean to override the server's StagingMode attribute. This can be performed via the Administration Console. To set this attribute for a Web application, use the following procedure:

1. Start the Administration Server and access the Administration Console.

2. Expand the Deployments node in the navigation tree on the left pane.

3. Expand the Web Applications node to list all the Web applications configured in the domain.

4. Click on the Web application for which you want to override the StagingMode attribute.

5. Select the StagingMode attribute for the Web application in the right pane.

The Deployment Order for Services and Applications in WebLogic Server

WebLogic Server 7.0 deploys or starts services before it deploys applications. Services such as JDBC and JMS are started before deploying applications such as Web applications and EJBs. The reason for this order is that these services are sometimes necessary for some of the applications to be deployed correctly. For example, JDBC connection pools and data sources are needed for CMP entity EJBs, and message-driven beans might require a JMS destination to be bound to the JNDI tree before initialization. Web applications might acquire JDBC connections or look up EJBs or JMS objects in the server's JNDI tree during initialization if the load-on-startup element is present.

The following is the deployment order for applications, from first to last:

1. Connectors

2. EJBs

3. Web applications

You can set the ordering of applications for the servers in a domain by setting the deployment order attribute in the Administration Console. The server uses this attribute to determine when it should deploy an application relative to other applications of the same type. This attribute is a number and applications with the lowest number are deployed first. There's no guarantee with regard to the order of deployment among applications that have equal deployment order attributes specified. The ordering is relative between the applications on the same server and not among servers.

The ordering of components within an application EAR file is controlled by the order in which the application components (EJBs and Web applications) are declared in the application.xml deployment descriptor. For example, consider the following application.xml snippet from the J2EE Blueprint PetStore application:

 <application> <module> <ejb>petstoreEjb.jar</ejb> </module> <module> <web> <web-uri>petstore.war</web-uri> <context-root>petstore</context-root> </web> </module> </application> 

When the petstore.ear is deployed, the petStoreEjb.jar will be deployed before the petstore.war .