Deploying Applications to WebLogic Server
|
 |
 |
|
 |
 |
Deployment Plan Reference and Schema
This appendix provides additional information about WebLogic Server deployment plans. It includes the following sections:
- How Deployment Plans Work
- Deployment Plan Schema
- Understanding the Deployment Configuration Process
- Typical Deployment Configuration Workflows
How Deployment Plans Work
A WebLogic Server deployment plan is an optional XML file that configures an application for deployment to WebLogic Server. A deployment plan works by setting property values that would normally be defined in the WebLogic Server deployment descriptors, or by overriding property values already defined in a WebLogic Server deployment descriptor. When exporting an application, the deployment plan typically acts to override selected properties in the WebLogic Server deployment descriptors you created during development.
Deployment plans help an Administrator easily modify an application's WebLogic Server configuration for deployment into to multiple, differing WebLogic Server environments without modifying the packaged WebLogic Server deployment descriptor files. Configuration changes are applied by adding or changing variables in the deployment plan, which define both the location of the WebLogic Server descriptor properties to change and the value to assign to those properties. Administrators deploying an application need only change the deployment plan—the original deployment files and deployment descriptors remain unchanged.
Figure 7-3 WebLogic Server Deployment Plan
Deployment Plan Schema
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="http://www.bea.com/ns/weblogic/90"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wls="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="1.0">
<xsd:import namespace="http://java.sun.com/xml/ns/j2ee"
schemaLocation="http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd" />
<xsd:element name="deployment-plan" type="wls:deployment-planType"/>
<xsd:complexType name="deployment-planType">
<xsd:sequence>
<xsd:element name="description"
type="xsd:string"
minOccurs="0"
nillable="true"/>
<xsd:element name="application-name"
type="xsd:string"/>
<xsd:element name="version"
type="xsd:string"
minOccurs="0"/>
<xsd:element name="variable-definition"
type="wls:variable-definitionType"
minOccurs="0" />
<xsd:element name="module-override"
type="wls:module-overrideType"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="config-root"
type="xsd:string"
nillable="true"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="global-variables"
type="xsd:boolean"
use="optional"
default="false"/>
</xsd:complexType>
<xsd:complexType name="variable-definitionType">
<xsd:sequence>
<xsd:element name="variable"
type="wls:variableType"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!--
A single variable definition
-->
<xsd:complexType name="variableType">
<xsd:sequence>
<xsd:element name="name"
type="xsd:string"/>
<xsd:element name="value"
type="xsd:string"
minOccurs="0"
nillable="true"/>
<xsd:element name="description"
type="xsd:string"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<!--
Each variable assignment has the following elements:
name: identifies the variable.
xpath: valid xpaths into the descriptor identified by the uri. The xpaths may resolve to multiple elements.
description: an optional description.
-->
<xsd:complexType name="variable-assignmentType">
<xsd:sequence>
<xsd:element name="description"
type="xsd:string"
minOccurs="0"/>
<xsd:element name="name"
type="xsd:string"/>
<xsd:element name="xpath"
type="j2ee:pathType"/>
<xsd:element name="operation" default="add" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="add"/>
<xsd:enumeration value="remove"/>
<xsd:enumeration value="replace"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="module-overrideType">
<xsd:sequence>
<xsd:element name="module-name"
type="xsd:string"/>
<xsd:element name="module-type"
type="xsd:string"/>
<xsd:element name="module-descriptor"
type="wls:module-descriptorType"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="module-descriptorType">
<xsd:sequence>
<xsd:element name="root-element"
type="xsd:string"/>
<xsd:element name="uri"
type="j2ee:pathType"/>
<xsd:element name="variable-assignment"
type="wls:variable-assignmentType"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="hash-code"
type="xsd:string"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="external"
type="xsd:boolean"
use="optional"
default="false"/>
</xsd:complexType>
</xsd:schema>
Understanding the Deployment Configuration Process
Deployment configuration for an application can occur at several points in the lifecycle of an application. Each phase of deployment configuration typically involves creating and working with different deployment files:
- Development configuration—During development, a programmer creates J2EE deployment descriptors for an application or module. The programmer also creates WebLogic Server deployment descriptors to configure the application for deployment to a Weblogic Server development environment.
- Export configuration—Before releasing an application from development, a programmer or designer may optionally export the application's deployment configuration to a WebLogic Server deployment plan. Exporting a configuration creates deployment plan variables for all or a subset of the deployment properties already defined in the application's WebLogic Server descriptor files.
Exporting an application helps deployers in other areas of the organization (such as engineers on the QA team or production Administrators) easily deploy the application to environments that differ from the programmer's development environment. The ideal deployment plan provides a complete list of properties that a deployer will likely need to change before deploying the application in a new environment.
- Deployment-time configuration—An Administrator or deployer configures the application before deploying the application into the target environment. Deployment-time configuration may use the same Weblogic Server deployment configuration files created during development, modified versions of the development configuration files, or custom configuration files that the deployer previously created for the environment, depending on the deployment configuration workflow for your organization.
Note: Applications developed outside of the WebLogic Server development environment (for example, a sample or third-party J2EE application such as PetStore) may include only J2EE descriptors.
Because deployment configuration is performed by different people at different points in the lifecycle of an application, both administrators and developers should work together to create a repeatable configuration workflow for their organization. See Typical Deployment Configuration Workflows for more information.
Administrators and deployers typically perform deployment configuration only at deployment time or after an application has been deployed. At these stages, the additional configuration required for an application depends on the available configuration files. See Updating the Deployment Configuration for an Application.
Typical Deployment Configuration Workflows
Deployment plans enable you to define a convenient, repeatable workflow for configuring an application for deployment to multiple WebLogic Server environments. A configuration workflow for production applications requires cooperation between your development and design teams, which create and package the deployable application, and the administrator or deployer for each target WebLogic Server environment.
The ideal deployment configuration workflow for your organization is determined by:
- Number of different environments in which you deploy the same application
- Difference in resources provided by each target environment
- Frequency with which each target environment changes
- Frequency with which the application's J2EE configuration changes
- Ownership requirements for configuration information in different areas of your organization
The sections that follow describe common deployment configuration workflows for managing deployment plans and deploying applications to multiple WebLogic Server domains.
Application with Single Deployment Plan
Organizations that know the exact configuration of different deployment environments can use a single, well-defined deployment plan to deploy an application to multiple WebLogic Server domains. The single deployment plan configuration workflow works in the following way:
- The development team, cooperating with administrators and deployers, creates a master deployment plan for use with all target environments. The number of target environments will vary depending on your organizational structure. Common deployment environments include one or more Quality Assurance (QA) or testing domains, staging domains, and production domains.
The deployment plan that the team creates at this phase defines variables for all configuration properties that are known to differ between each target environment. For example, the plan might define empty variables for resource names that differ between environments and must be configured before the application can be deployed. The plan may also define default values for common tuning parameters that deployers may want to change in their environments.
For more information about creating a deployment plan during development, see Exporting an Application for Deployment to New Environments.
- When a version of the application is ready to be released, the development team packages the application deployment files and delivers both the deployment files and a master deployment plan to deployers for each target environment.
- Each deployer uses the Administration Console to install the application and identify the deployment plan to use for configuration. The Administration Console validates the overall deployment configuration based on the resources available in the target domain. The Console then presents a list of configurable properties defined in the plan (as well as any invalid properties) to the deployer for editing.
- The deployer uses the Administration Console to interactively configure properties that were defined in the deployment plan. Deployment plan variables that have null values, or invalid values for the target WebLogic Server instances or clusters, must be configured before the application can be deployed. Deployment plan variables that already have valid values need not be changed before deployment.
Figure 7-4 Single Deployment Plan Workflow
Using the single deployment plan workflow provides the following benefits:
- It enables the development or design team to control the deployment configuration of the application.
- It reduces the number of configuration decisions that a deployer must make when deploying the application to a target environment.
- It minimizes the number of configuration files associated with the application, making it easy to store deployment configuration information in a source control system.
In general, you would use a single deployment plan workflow if your organization has a few, well-understood target environments, and you want to easily replicate a standardized deployment configuration in each environment.
Single Deployment Plan Ownership and Limitations
The single deployment plan workflow assumes that the development or design team maintains ownership of the deployment plan, and that deployers limit their plan changes to those variables defined in the plan. If the deployer modifies only those properties defined in the deployment plan, their changes are written back to the same deployment plan as updates to the variables.
However, WebLogic Server imposes no restrictions on the configuration properties that a deployer can modify using the Administration Console. If a deployer configures deployment properties that were not originally defined in a plan, the Console generates a new deployment plan having the additional variable entries, and uses the new plan for deployment or redeployment operations. This can lead to a situation where the deployer uses a deployment plan that is drastically different from the master deployment plan owned by the development team.
To incorporate new changes into the master deployment plan, the deployer retrieves the new, customized deployment plan created by the Console. Ideally, those changes should be applied to the master deployment plan.
Application with Multiple Deployment Plans
Organizations that have numerous deployment environments that frequently change should use a configuration workflow with multiple deployment plans. In a multiple deployment plan workflow, each deployment plan is owned by the deployer of the application rather than the development team. The multiple deployment plan configuration workflow works in the following way:
- The development team releases a version of the packaged application deployment files (containing J2EE and Weblogic Server descriptors). The development team may or may not include a basic deployment plan with exported variables for resource definitions or common tunable parameters.
- Before first deploying the application, each deployer generates a custom deployment plan to configure the application for their target environment.
A custom deployment plan can be created by starting with a template deployment plan (or no deployment plan) and making interactive changes to the application's deployment configuration using the Administration Console. Changes made using the Console are either written back to the original deployment plan, or are stored in a newly-generated deployment plan for the application.
- After defining the deployment configuration for their environment, each deployer retrieves their custom deployment plan and maintains it for future deployments of the application. BEA recommends storing custom configuration plans in a source control system so that new versions can be tracked and reverted to if necessary.
Figure 7-5 Multiple Deployment Plan Workflow
Using the multiple deployment plan workflow provides the following benefits:
- It enables the administrator or deployer to manage both the application configuration and environment configuration in tandem.
- It enables deployers to automate the deployment process by using a custom plan that fully configures the application for their application.
In general, you would use a multiple deployment plan workflow if your organization has many deployment environments that change frequently, making it difficult or impossible to maintain a single master deployment plan.
Multiple Deployment Plan Ownership and Limitations
The multiple deployment plan workflow assumes that the deployer or administrator (rather than the programming or design team) owns and maintains the deployment configuration for an application. It also assumes that the basic J2EE configuration of the application rarely changes, because certain J2EE configuration changes would render a deployer's custom configuration plans invalid. For example, if a module in an Enterprise Application is added, removed, or changed, custom deployment plans referencing the module would become invalid. In this case, each deployer would need to re-create their custom plan by interactively configuring the application using the Administration Console.
