Deploying Applications to WebLogic Server
The term application deployment refers to the process of making an application or module available for processing client requests in a WebLogic Server domain. For an administrator, application deployment generally involves the following tasks:
Some BEA deployment tools, such as the Administration Console, automatically guide you through each step to help you quickly deploy applications to a WebLogic Server domain. Other tools, such as the
weblogic.Deployer tool, provide more control over individual steps in the deployment process, but require additional conceptual knowledge about how WebLogic Server performs each step. This document focuses mainly on using the
weblogic.Deployer tool, which provides access to many advanced deployment features. However, the Administration Console is also documented where it provides unique functionality. For example, only the Administration Console provides interactive deployment configuration for applications and modules. For a detailed list of deployment tools, including those documented elsewhere in WebLogic Server documentation, see Overview of Deployment Tools.
WebLogic Server implements the J2EE 1.4 specification. J2EE 1.4 includes a deployment specification, JSR-88, that describes a standard API used by deployment tools and application server providers to configure and deploy applications to an application server.
WebLogic Server implements both the JSR-88 Service Provider Interface (SPI) plug-in and model plug-in to comply with the J2EE 1.4 deployment specification. You can use a basic J2EE 1.4 deployment API deployment tool with the WebLogic Server plug-ins (without using WebLogic Server extensions to the API) to configure, deploy, and redeploy J2EE applications and modules to WebLogic Server. The WebLogic Server configuration generated by a J2EE 1.4 deployment API configuration process is stored in a deployment plan and one or more generated WebLogic Server deployment descriptor files, as shown in Figure 2-1. WebLogic Server deployment descriptors are generated as needed to store WebLogic Server configuration data.
The WebLogic Server deployment plan generated by a pure J2EE 1.4 deployment API deployment tool identifies the WebLogic Server deployment descriptors that were generated for the application during the configuration session.
Although the J2EE 1.4 deployment API provides a simple, standardized way to configure applications and modules for use with a J2EE 1.4-compliant application server, the specification does not address many deployment features that were available in WebLogic Server 8.1, or introduced in WebLogic Server 9.0. For this reason, WebLogic Server provides important extensions to the J2EE 1.4 deployment API specification to support capabilities described in WebLogic Server Deployment Features.
application module—An XML document that configures JMS or JDBC resources. Application modules can be deployed as stand-alone modules in which case their resources are bound to the global JNDI tree. Application modules can also be bundled as part of an Enterprise Application and scoped within the application itself; in this case, the modules are referred to as application-scoped modules.
application installation directory—A WebLogic Server directory structure designed to help organize deployment files and generated deployment configuration artifacts for an application or module. Also referred to as an application root directory.
application version—A string value that identifies the version of a deployed application. Compatible applications that use version strings can use the WebLogic Server production redeployment strategy.
deployment configuration—The process of defining the deployment descriptor values required to deploy an application to a particular WebLogic Server domain. The deployment configuration for an application or module is stored in three types of XML document: J2EE deployment descriptors, WebLogic Server descriptors, and WebLogic Server deployment plans.
deployment plan—An XML document that defines an application's WebLogic Server deployment configuration for a specific WebLogic Server environment. A deployment plan resides outside of an application's archive file, and can apply changes to deployment properties stored in the application's existing WebLogic Server deployment descriptors. Use deployment plans to easily change an application's WebLogic Server configuration for a specific environment without modifying existing deployment descriptors. Multiple deployment plans can be used to reconfigure a single application for deployment to multiple, differing WebLogic Server environments.
production redeployment—A WebLogic Server redeployment strategy that deploys a new version of a production application alongside an older version, while automatically managing HTTP connections to ensure uninterrupted client access.
staging mode—The method WebLogic Server uses to make deployment files available to target servers in a domain. Staging modes determine whether or not files are distributed (copied) to target servers before deployment.
The built-in security roles for "Admin" and "Deployer" users allow you to perform deployment tasks using the WebLogic Server Administration Console. Additionally, in this version of WebLogic Server, there is a new security role, "AppTester" that allows you to test versions of applications that are deployed to Administration mode.
Whereas the J2EE 1.4 deployment API deployment specification enables you to generate vendor-specific descriptor values necessary for deploying an application, WebLogic Server extensions to J2EE 1.4 deployment API allow you to configure many additional deployment properties, including:
WebLogic Server extensions to the J2EE 1.4 deployment API make it easy to reconfigure an application as needed for deployment to multiple, different WebLogic Server environments, without unpacking or otherwise modifying the deployment source files. Migration of applications is accomplished by exporting an application's deployment configuration to a deployment plan during development.
To export an application's configuration, developers use the new
weblogic.PlanGenerator tool and select WebLogic Server deployment descriptor properties that need to change when the application is deployed into another environment. For example, global resource names and tuning parameters typically differ between environments because different domains provide different types and quantities of resources to deployed applications.
weblogic.PlanGenerator creates variable definitions in a deployment plan which act as placeholders for the selected descriptor properties. Deployment tools such as the Administration Console automatically present deployment plan variables to a deployer for customizing before deployment.
Variable definitions allow an Administrator or other deployer to easily change the values of those descriptor properties as needed for different server domains, without changing the actual deployment descriptors files in the application itself. By setting empty (null) variable definitions for required descriptor properties, a developer can require valid entries to be filled in before an application can be deployed.
See Configuring Applications for Production Deployment for information about configuring applications with the Administration Console before deployment. See weblogic.PlanGenerator Command Line Reference for information about using the
weblogic.PlanGenerator tool. See Deployment Plan Reference and Schema for details about WebLogic Server deployment plans.
Distributing an application copies deployment files to target servers and places the application in a prepared state. You can then start the application in Administration mode, which restricts access to the application to a configured Administration channel so you can perform final testing without opening the application to external client connections or disrupting connected clients. You can start an application in administration mode with the
-adminmode option as described in Starting a Distributed Application in Administration Mode. See Distributing Applications to a Production Environment and Distributing a New Version of a Production Application.
JDBC, JMS, and WLDF resources can now be stored as application modules, which can be deployed stand-alone to multiple servers or clusters or included within an Enterprise Application as application-scoped resources. Stand-alone JDBC, JMS, and WLDF application modules make it easy to replicate resources in multiple WebLogic Server domains. Application-scoped resource modules make it possible to include all of an application's required resources within the application module itself, for maximum portability to multiple environments. See Developing Applications with WebLogic Server for more information about using application-scoped resources. See Deploying JDBC, JMS, and WLDF Application Modules to deploy stand-alone or application-scoped resources to WebLogic Server.
WebLogic Server enables you to target individual modules of an Enterprise Application to different server targets, or to deploy only a subset of available modules in an Enterprise Application. This provides flexible packaging options, allowing you to bundle a group of related modules together in an Enterprise Application, but deploy only selected modules to individual servers in a domain.
WebLogic Server enables you to safely update and redeploy a new version of a production application without affecting current HTTP clients to the application. Production redeployment helps you roll out bug fixes or new functionality without application downtime, and without creating redundant servers in order to roll out the changes. See Updating Applications in a Production Environment.
A deployment unit refers to a J2EE application (an Enterprise Application or Web application) or a stand-alone J2EE module (such as 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 the following types of deployment units:
An Enterprise Application is packaged as an archive file with an
.ear extension, but is generally deployed as an exploded EAR directory. An exploded EAR directory contains all of the JAR, WAR, and RAR modules (also in exploded format) for an application as well as the XML descriptor files for the Enterprise Application and its bundled applications and modules. See Developing WebLogic Server Applications for more information.
web.xmldeployment descriptor, a J2EE standard XML document that configures the contents of a WAR file.
Web applications may also contain JSP tag libraries, static .html and image files, supporting classes and
.jar files, and a
weblogic.xml deployment descriptor, which configures WebLogic Server-specific elements for Web applications. See Developing Web Applications for WebLogic Server for more information.
Enterprise JavaBeans (EJBs) are reusable Java components that implement business logic and enable you to develop component-based distributed business applications. EJB modules are packaged as archive files having a
.jar extension, but are generally deployed as exploded archive directories. The archive file or exploded archive directory for an EJB contains the compiled EJB classes, optional generated classes, and XML deployment descriptors for the EJB. See Programming WebLogic Server Enterprise JavaBeans for more information on the different types of EJBs.
A Resource Adapter (also referred to as a connector) adds Enterprise Information System (EIS) integration to the J2EE platform. Connectors provide a system-level software driver that WebLogic Server can use to connect to an EIS. Connectors contain both the Java classes, and if necessary, the native components required to interact with the EIS. See Programming WebLogic Resource Adapters for more information.
A Web Service is a set of functions packaged into a single entity that is available to other systems on a network, and can be shared by and used as a component of distributed Web-based applications. Web Services commonly interface with existing back-end applications, such as customer relationship management systems, order-processing systems, and so on.
A Web Service module may include either Java classes or EJBs that implement the Web Service. Web Services are packaged either as Web Application archives (WARs) or EJB modules (JARs) depending on the implementation. See Programming WebLogic Web Services for more information.
A J2EE library is a stand-alone J2EE module, or multiple J2EE modules packaged in an Enterprise Application (EAR), that is registered with the J2EE application container as a shared library at deployment time. After a J2EE library has been registered, you can deploy Enterprise Applications that reference the library in their
weblogic-application.xml deployment descriptors. Each referencing application receives a copy of the shared J2EE library module(s) on deployment, and can use those modules as if they were packaged as part of the application itself. J2EE library support provides an easy way to share one or more J2EE modules among multiple Enterprise Applications without physically adding the shared modules to each dependent application.
The deployment files of a shared library resemble either a standard Enterprise Application or J2EE module, as discussed in this section. Shared libraries differ from standard EARs and modules only by the contents of their
MANIFEST.MF files. Creating Shared J2EE Libraries and Optional Packages in Developing Applications with WebLogic Server describes how to assemble and configure J2EE libraries, and how to configure Enterprise Applications that utilize J2EE libraries.
Deploying JDBC, JMS, and WLDF Application Modules describes how to deploy J2EE libraries and Enterprise Applications that reference J2EE libraries.
Optional packages provide similar functionality to J2EE libraries, allowing you to easily share a single JAR file among multiple applications. However, optional packages function at the level of an individual J2EE module (stand-alone or within an Enterprise Application), rather than at the Enterprise Application level. For example, third-party Web Application Framework classes needed by multiple Web applications can be packaged and deployed in a single JAR file, and referenced by multiple Web application modules in the domain.
Optional packages are delivered as basic JAR files that have no deployment descriptors. You simply designate the JAR as an optional package at deployment time, and WebLogic Server registers the file with the target servers you select. After the optional package has been registered, you can then deploy J2EE modules and applications that reference the optional package in their
MANIFEST.MF files. Creating Shared J2EE Libraries and Optional Packages in Developing Applications with WebLogic Server describes how to assemble and configure optional packages, and how to configure J2EE modules that utilize optional packages.
Deploying Shared J2EE Libraries and Dependent Applications describes how to deploy optional packages and J2EE modules that reference optional packages.
JMS and JDBC configurations in this release of WebLogic Server stored in XML documents that conform to the appropriate WebLogic Server schema for the resource:
weblogic-jdbc.xsd. You create and manage JMS and JDBC resources either as system modules, similar to the way they were managed prior to pre-9.0 versions of WebLogic Server, or as application modules, similar to standard J2EE modules.
A JMS, JDBC, or WLDF application module can be deployed as a stand-alone resource, in which case the resource is available in the domain targeted during deployment, or as part of an Enterprise application. An application module deployed as part of an Enterprise Application is available only to the enclosing application (an application-scoped resource). Using application-scoped resources ensures that an application always has access to required resources, and simplifies the process of deploying the application into new environments.
In contrast to system modules, application modules are owned by the developer who created and packaged the module, rather than the Administrator who deploys the module. This means that the Administrator has more limited control over JDBC, JMS, and WLDF application modules. When deploying an application module, an Administrator can change resource properties that were specified in the module, but cannot add or delete resources.
System modules are created by the Administrator via the WebLogic Administration Console, and can be changed or deleted as necessary by the Administrator. Similarly, stand-alone application modules created by the Administrator can be used to recreate global resources in multiple WebLogic Server environments simply by deploying the modules into new domains.
See Deploying Applications and Modules for information about deploying JMS and JDBC stand-alone modules.
The J2EE specification enables you to include a client application archive file within an Enterprise Application. A J2EE client application module contains the Java classes that execute in the client JVM (Java Virtual Machine) and deployment descriptors that describe EJBs (Enterprise JavaBeans) and other WebLogic Server resources used by the client. This enables both the server-side and client-side components to be distributed as a single unit. You define client modules in an EAR using the J2EE standard
application-client.xml deployment descriptor and WebLogic Server
weblogic.Deployer provides a command-line based interface for performing both basic and advanced deployment tasks. Use
weblogic.Deployer when you want command-line access to WebLogic Server deployment functionality, or when you need to perform a deployment task that is not supported using the Administration Console.
The Administration Console provides a series of Web-based Deployment Assistants that guide you through the deployment process. The Administration Console also provides controls for changing and monitoring the deployment status, and changing selected deployment descriptor values while the deployment unit is up and running.
The WebLogic Scripting Tool (WLST) is a new command-line interface that you can use to automate domain configuration tasks, including application deployment configuration and deployment operations. See WebLogic Scripting Tool for more information.
wldeployis an Ant task version of the
weblogic.Deployerutility. You can automate deployment tasks by placing
wldeploycommands in an Ant
build.xmlfile and running Ant to execute the commands.
autodeploydomain directory allows you to deploy an application quickly for evaluation or testing in a development environment.