Deploying WebLogic Platform Applications
|
 |
 |
|
 |
 |
Once the target environment is set up and the application is prepared for deployment, the final step is to deploy the application to the target environment.
This section describes the following topics:
A deployment unit refers to a J2EE application (an Enterprise Application or Web Application) or a standalone J2EE module (an EJB or Resource Adapter) that has been organized according to the J2EE specification and can be deployed to WebLogic Server.
For each type of deployment unit, the J2EE specification defines both the required files and their location in the directory structure of the application or module. Deployment units may include Java classes for EJBs and servlets, resource adapters, Web pages and supporting files, XML-formatted deployment descriptors, and even other modules.
J2EE does not specify how a deployment unit is deployed on the target server—only how standard applications and modules are organized. WebLogic Server supports deployments that are packaged either as archive files using the jar utility, or as exploded archive directories.
In certain circumstances, you may need to deploy individual modules within an application to different targets, for example, when deploying a WebLogic Platform application that combines multiple components of WebLogic Platform. Important considerations for targeting these modules and applications are provided in this section.
The following table lists the deployment tools that are available with WebLogic Platform. You can use these tools to deploy, redeploy, undeploy, and distribute applications.
|
Perform basic deployment functions interactively using a browser.This method of deployment is convenient if you do not know the exact names of deployment units, target servers, or deployed applications. For more information about deploying applications using the WebLogic Server Administration Console, see Configuring and Managing WebLogic Server. |
|
|
Provides a command-line based interface for performing both basic and advanced deployment tasks. Use |
|
|
Provides an Ant task version of the |
The following sections provide considerations for deploying to a production environment, including:
Note: The Customer Support Web site provides general considerations and troubleshooting tips for deploying applications. For more information, see Troubleshooting Deployment Issues at: http://support.bea.com/support_news/product_troubleshooting/Deployment_Pattern.html
You can store an application as a single archive EAR file or as an exploded archive directory. To review considerations, see Deployment Files in Deploying WebLogic Server Applications.
How you target the application depends on the application type:
Target the WebLogic Portal application or Portal modules of a WebLogic Platform application, to the Administration Server and the cluster. This enables data in the Administration Portal, the Datasync Web application, and the LDAP server to be synchronized and promoted correctly.
Deployment of a WebLogic Portal application or Portal modules of a WebLogic Platform application, is a two-step deployment process. For more information, see Step 3: Deploy the Application.
Note: WebLogic Portal does not support a split configuration architecture where EJBs and JSPs are split onto different servers in a cluster.
Target the WebLogic Integration application to a single cluster in the domain. If no target cluster is specified, the target defaults to the first WebLogic Integration cluster or, in the absence of a cluster, the first Managed Server. You can modify this value by editing the wli-config.properties file to set the weblogic.wli.WliClusterName property value to the name of the cluster to which you want to target. For more information about the wli-config.properties file, see wli-config.properties Configuration File in Deploying WebLogic Integration Solutions.
When using a process control, the target process must be targeted to the same Managed Server as the client process. Otherwise, the dispatching table will not be updated and the client process will not have access to the information necessary to call the target process. Similarly, subscriber processes must be targeted to the same Managed Server as the publisher process.
Trading Partner Integration components must be deployed homogeneously to a cluster so that there is no single point of failure.
For considerations when deploying adapters and event generators, see the following sections in Understanding WebLogic Integration Clusters in Deploying WebLogic Integration Solutions:
For more information, see the following sections in Deploying WebLogic Server Applications:
The default Authentication provider delivers two built-in security roles, Admin and Deployer, to enable users to perform deployment tasks using the WebLogic Server Administration Console.
In addition, you may need to create a custom Authentication provider and define additional security roles to further secure the environment. BEA recommends that you create all roles required by an application before deploying it. For more information, see Configuring Security.
The following table lists the staging modes that define how deployment units are made available to targeted servers. For more details about the staging modes and suggestions on when to use them, see Staging Modes in Deploying WebLogic Server Applications.
The deployment order is determined by the Load Order attribute. By default, each deployment unit is configured with a Load Order value of 100. Deployment units with the same Load Order value are deployed in alphabetical order using the deployment name.
You can change the load order in the WebLogic Server Administration Console or using the ApplicationMBean. For more information, and for a description of configuring the application module and startup class order, see Deployment Order in Deploying WebLogic Server Applications.
To adjust the run-time deployment configuration without modifying the contents of the application archive, you can use alternate deployment descriptors that are staged externally to the application. You can specify an alternate deployment descriptor file to be used in place of the standard J2EE (application.xml) or WebLogic Server (weblogic-application.xml) deployment descriptor.
For more information, see Deploying Enterprise Applications With Alternate Deployment Descriptors in Deploying WebLogic Server Applications.
The following sections describe the steps that are required to deploy applications to the target environment, including:
Note: Before deploying to the target environment, be sure that you have prepared the target environment and the application, as described in the following sections:
Start the Administration Server and Managed Servers, if they are not already running, as described in Starting the Servers.
In order to deploy an application to servers in a domain, the files must be accessible to the Administration Server for the domain. Specifically, they must reside on the Administration Server machine or be accessible via a network mounted directory. For more information, see "Uploading Deployment Files to the Administration Server" in Performing Common Deployment Tasks in Deploying WebLogic Server Applications.
The procedure that you use to deploy the application depends on the application type. WebLogic Platform and WebLogic Portal applications require a special deployment sequence.
The following sections describe the procedures for deploying an application, based on the application type:
Deploy the WebLogic Integration, WebLogic Server, or WebLogic Workshop application to the cluster using one of the deployment tools described in Overview of the Deployment Tools. For targeting and other deployment considerations, see Deployment Considerations.
Deployment of a WebLogic Portal application or Portal modules of a WebLogic Platform application, is a two-step deployment process. Initially, the WebLogic Portal application or Portal modules must be deployed to a single server and then subsequently deployed to the cluster.
To deploy a WebLogic Platform or WebLogic Portal Application:
For targeting and other deployment considerations, see Deployment Considerations.
Note: If your cluster is not already running, you can make use of deferred deployment. To initiate deferred deployment, deploy the WebLogic Portal application or Portal modules of a WebLogic Platform application to the Administration Server and the cluster; deploy all other applications and modules to the cluster only. Then, start the Managed Servers, as described in Starting the Managed Servers. At this point, the applications that were deployed to the cluster, are deployed automatically. One advantage of deferred deployment is that the WebLogic Portal application or modules only need to be deployed once.
If your application uses event generators, you must deploy them using the WebLogic Integration Administration Console. For information about deploying event generators, see Creating and Deploying Event Generators in "Event Generators" in Managing WebLogic Integration Solutions.
You can start the Administration Server and Managed Servers, as described in the following sections:
Before you start the servers, perform the following tasks:
Sample start scripts for Node Manager are installed in the WL_HOME\server\bin directory, where WL_HOME is the top-level installation directory for WebLogic Server. Use startNodeManager.cmd on Windows systems and startNodeManager.sh on UNIX systems.
For more information about starting and stopping Node Manager, see Configuring, Stopping, and Starting Node Manager in Configuring and Managing WebLogic Server.
MEM_ARGS variable in the setDomainEnv script in the domain directory, as follows:If you are using Node Manager to administer Managed Servers, set this variable using the Arguments ServerStart attribute, as described in Configuring the Managed Server Start Attributes.
To start the Administration Server:
For more information about starting the Administration Server, see Starting Administration Servers in WebLogic Server Administration Console Online Help.
Start the Managed Server in one of the following ways:
startManagedWebLogic script provided in the domain directory.
The following example provides a code excerpt from an Ant build file and demonstrates how to use weblogic.Deployer to deploy a WebLogic Integration application in an automated way to a single-cluster domain, as shown in Single-Cluster Platform Domain Example.
The following sections step you through the process of deploying an application to a target domain.
To facilitate automation and reuse of the scripts in different target environments, the code excerpt references properties, such as ${cluster.name}, that are resolved in a properties file imported to the Ant script. For example, the following properties are defined in a separate properties file, myprops.properties:
deploy.dir=deploy
cluster.name=platformcluster
admin.addr=myhost
admin.port=9301
admin.username=username
admin.password=password
The file is referenced in the Ant build file as follows:
<property file="myprops.properties"/>
The following defines the main Ant target for the WebLogic Integration application. The target value is shown in bold. The deploy-app target is described below.
<target name="deploy-IntApp">
<antcall target="deploy-app">
<param name="app.name" value="IntApp" />
<param name="app.src" location="${deploy.dir}/IntApp.ear" />
<param name="app.target" value="${cluster.name}" />
<param name="admin.url" value="http://${admin.addr}:${admin.port}" />
</antcall>
</target>
The deploy-app target, referenced in the Ant target above, uses the weblogic.Deployer command to deploy the applications, as follows:
<target name="deploy-app">
<java classname="weblogic.Deployer"
fork="true" failonerror="true">
<arg value="-adminurl"/><arg value="${admin.url}"/>
<arg value="-username"/><arg value="${admin.username}"/>
<arg value="-password"/><arg value="${admin.password}"/>
<arg value="-name"/><arg value="${app.name}"/>
<arg value="-source"/><arg value="${app.src}"/>
<arg value="-targets"/><arg value="${app.target}"/>
<arg value="-deploy"/>
</java>
To deploy the WebLogic Integration application to a single domain, as depicted in Single-Cluster Platform Domain Example:
ant deploy-IntApp
The following examples provide code excerpts from an Ant build file and demonstrates how to use weblogic.Deployer to deploy applications in an automated way to a single-cluster domain, as shown in Single-Cluster Platform Domain Example.
Specifically, this example deploys the following three applications to a production environment:
PlatApp—WebLogic Platform application. For a definition, see About WebLogic Platform Applications.PortApp—WebLogic Portal application.IntApp—WebLogic Integration application.The following sections step you through the process of deploying an application to a target domain.
To facilitate automation and reuse of the scripts in different target environments, the code excerpt references properties, such as ${cluster.name}, that are resolved in a properties file imported to the Ant script. For example, the following properties are defined in a separate properties file, myprops.properties:
cluster.name=platformcluster
admin.name=cgServer
The file is referenced in the Ant build file as follows:
<property file="myprops.properties"/>
As described in Step 3: Deploy the Application, deploying a WebLogic Platform or WebLogic Portal application is a two-step deployment process (unless you use are using deferred deployment):
For example, the following code excerpt defines the "first" Ant targets, to accomplish step 1 above. Target values are shown in bold. Note that deploy-PlatApp-first uses module-level targeting to target the WebLogic Portal modules of the WebLogic Platform application to the Administration Server only and WebLogic Integration modules to the cluster.
Note: The deploy-app target referenced in the following Ant targets is defined in Define the Deploy Ant Target.
You do not need to define a "first" Ant target for the WebLogic Integration application because it does not require a two-step deployment procedure.
<target name="deploy-PlatApp-first">
<antcall target="deploy-PlatApp">
<param name="app.target" value="p13n_ejb.jar@${admin.name},PortIntAppDatasync@${admin.name},\
.workshop/PortIntAppWeb/EJB/GenericStateless@${cluster.name},\
.workshop/PortIntAppWeb/EJB/Allocate_1trtqtoxcz4uv@${cluster.name},\
.workshop/PortIntAppWeb/EJB/ProjectBeans@${cluster.name},PortIntAppWeb@${cluster.name}"
/>
</antcall>
</target>
<target name="deploy-PortApp-first">
<antcall target="deploy-PortApp">
<param name="app.target" value="${admin.name}"
</antcall>
</target>
The following defines the main Ant targets to accomplish step 2 above. Target values are shown in bold. Note that the WebLogic Portal and WebLogic Platform applications are targeted to the cluster, since they will already have been targeted to the Administration Server via the "first" Ant targets described above.
Note: The main Ant target for the WebLogic Integration application is defined in Define the Main Ant Target.
<target name="deploy-PlatApp">
<antcall target="deploy-app">
<param name="app.name" value="PlatApp" />
<param name="app.src" location="${deploy.dir}/PortIntApp.ear" />
<param name="app.target" value="${cluster.name}" />
<param name="admin.url" value="http://${admin.addr}:${admin.port}" />
</antcall>
</target>
<target name="deploy-PortApp">
<antcall target="deploy-app">
<param name="app.name" value="PortApp" />
<param name="app.src" location="${deploy.dir}/PortApp.ear" />
<param name="app.target" value="${cluster.name}" />
<param name="admin.url" value="http://${admin.addr}:${admin.port}" />
</antcall>
</target>
Two deployment Ant targets are defined below: 1) One to execute the "first" Ant targets and deploy the WebLogic Portal application and Portal modules of the WebLogic Platform application to the Administration Server only, and 2) The second to deploy the WebLogic Portal, WebLogic Platform, and WebLogic Integration applications to the cluster.
<target name="deploy-apps-first"
depends="
deploy-PlatApp-first,
deploy-PortApp-first
/>
<target name="deploy-apps"
depends="
deploy-PlatApp
deploy-PortApp
deploy-IntApp
/>
To deploy the applications to a single domain, as depicted in Single-Cluster Platform Domain Example:
ant deploy-apps-first
ant deploy-apps
|
|
|