2 Understanding WebLogic Server Deployment
This chapter includes the following sections:
Overview of the Deployment Process
The term application deployment refers to the process of making an application or module available for processing client requests in a WebLogic Server domain. Application deployment involves multiple tasks.
Java EE Deployment Implementation
WebLogic Server implements the Java EE specification which 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 Java EE deployment specification. You can use a basic Java EE deployment API deployment tool with the WebLogic Server plug-ins (without using WebLogic Server extensions to the API) to configure, deploy, and redeploy Java EE applications and modules to WebLogic Server. The WebLogic Server configuration generated by a Java EE 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.
Figure 2-1 Configuring Applications with the Java EE Deployment API
Description of "Figure 2-1 Configuring Applications with the Java EE Deployment API "
The WebLogic Server deployment plan generated by a Java EE deployment API deployment tool identifies the WebLogic Server deployment descriptors that were generated for the application during the configuration session.
Although the Java EE deployment API provides a simple, standardized way to configure applications and modules for use with a Java EE-compliant application server, the specification does not address many deployment features that were available in previous WebLogic Server releases. For this reason, WebLogic Server provides important extensions to the Java EE deployment API specification to support capabilities described in WebLogic Server Deployment Features.
WebLogic Server Deployment Features
WebLogic Server supports several advanced deployment features to help you reliably deploy and manage applications in a production environment.
Exporting Applications for Deployment to Multiple Environments
Module-Level Deployment and Redeployment for Enterprise Applications
Additional Deployment Configuration Properties
Whereas the Java EE deployment API deployment specification enables you to generate vendor-specific descriptor values necessary for deploying an application, WebLogic Server extensions to Java EE deployment API allow you to configure many additional deployment properties, including:
The names of external resources required for the application to operate
The declared names of services provided in a deployed application (JNDI names), which other applications may reference for their own use
Tuning properties that control the performance and behavior of the application on WebLogic Server
You can store these deployment properties in WebLogic Server deployment plans.
Exporting Applications for Deployment to Multiple Environments
The basic Java EE deployment API configuration process provides a simple way for standardized deployment tools to deploy Java EE applications on multiple application server products. However, it does not help in the process of migrating an application's configuration from one environment to another within an organization. The WebLogic Server deployment API extends the Java EE deployment API to provide support for exporting an application's configuration for deployment to multiple WebLogic Server environments, such as testing, staging, and production domains. See Exporting an Application for Deployment to New Environments.
Administration Mode for Isolating Production Applications
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.
After performing final testing, you can either undeploy the application to make further changes, or start the application in Production mode to make it generally available to clients.
Deployable JDBC, JMS, and WLDF Application Modules
JDBC, JMS, and WLDF resources can be stored as application modules, which can be deployed standalone to multiple servers or clusters or included within an enterprise application as application-scoped resources. Standalone 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 for Oracle WebLogic Server for more information about using application-scoped resources. See Deploying JDBC, JMS, and WLDF Application Modules to deploy standalone or application-scoped resources to WebLogic Server.
Module-Level Deployment and Redeployment for Enterprise Applications
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.
Safe Redeployment for Production Applications
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 Redeploying Applications in a Production Environment.
Security Roles Required for Deployment
The built-in security roles for "Admin" and "Deployer" users allow you to perform deployment tasks using the WebLogic Server Administration Console. The "AppTester" security role allows you to test versions of applications that are deployed to administration mode. When deploying across WebLogic domains, the "CrossDomainConnector" role allows you to make inter-domain calls from foreign domains. For a complete listing of all security roles, see Default Global Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Supported Deployment Units
A deployment unit refers to a Java EE application (an enterprise application or Web application) or a standalone Java EE module (such as an EJB or resource adapter) that has been organized according to the Java EE specification and can be deployed to WebLogic Server.
For each type of deployment unit, the Java EE 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.
Java EE 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 consists of one or more of the following Java EE applications or modules:
Enterprise Java Beans (EJB) modules
Resource adapter modules
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 Applications for Oracle WebLogic Server.
A Web application always includes the following files:
A servlet or JSP page, along with any helper classes.
web.xmldeployment descriptor, a Java EE 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, Servlets, and JSPs for Oracle WebLogic Server.
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 Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server 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 Java EE 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 Developing Resource Adapters for Oracle WebLogic Server.
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; typically the WAR or EJB JAR file is then packaged in an enterprise application. See Developing JAX-WS Web Services for Oracle WebLogic Server.
Java EE Library
A Java EE library is a standalone Java EE module, or multiple Java EE modules packaged in an enterprise application (EAR), that is registered with the Java EE application container as a shared library at deployment time. After a Java EE 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 Java EE library module(s) on deployment, and can use those modules as if they were packaged as part of the application itself. Java EE library support provides an easy way to share one or more Java EE 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 Java EE 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 Java EE Libraries and Optional Packages in Developing Applications for Oracle WebLogic Server describes how to assemble and configure Java EE libraries, and how to configure enterprise applications that utilize Java EE libraries.
Deploying Shared Java EE Libraries and Dependent Applications describes how to deploy Java EE libraries and enterprise applications that reference Java EE libraries.
Optional packages provide similar functionality to Java EE libraries, allowing you to easily share a single JAR file among multiple applications. However, optional packages function as individual Java EE modules (standalone or within an enterprise application), rather than as an enterprise application. 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 Java EE modules and applications that reference the optional package in their
MANIFEST.MF files. Creating Shared Java EE Libraries and Optional Packages in Developing Applications for Oracle WebLogic Server describes how to assemble and configure optional packages, and how to configure Java EE modules that utilize optional packages.
Deploying Shared Java EE Libraries and Dependent Applications describes how to deploy optional packages and Java EE modules that reference optional packages.
JDBC, JMS, and WLDF Modules
A JMS, JDBC, or WebLogic Diagnostic Framework (WLDF) application module can be deployed as a standalone 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 Server Administration Console, and can be changed or deleted as necessary by the administrator. Similarly, standalone 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.
For more information on how to deploy and use JDBC, JMS, and WLDF modules, see:
Client Application Archive
The Java EE specification enables you to include a client application archive file (
.jar file) as a module within an enterprise application (
.ear file). A Java EE 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 Java EE standard
application-client.xml deployment descriptor and WebLogic Server
WebLogic Server provides several tools to help you configure and deploy applications.
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 WebLogic Server Administration Console.
WebLogic Server Administration Console and Fusion Middleware Control
The WebLogic Server Administration Console and Fusion Middleware Control provide a series of Web-based deployment assistants that guide you through the deployment process. They also provide controls for changing and monitoring the deployment status, and changing selected deployment descriptor values while the deployment unit is up and running.
Use the WebLogic Server Administration Console or Fusion Middleware Control when you need to perform basic deployment functions interactively and you have access to a supported browser.
The WebLogic Scripting Tool (WLST) is a command-line interface that you can use to automate domain configuration tasks, including application deployment configuration and deployment operations. See Understanding the WebLogic Scripting Tool for more information.
Deployment Tools for Developers
WebLogic Server provides several tools for deploying applications and standalone modules:
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.
weblogic-maven-pluginis a Maven plug-in for WebLogic Server that you can use to perform deployment operations similar to those supported by
weblogic.Deployer. The plug-in lets you deploy, redeploy, update, and such, applications built using Maven to WebLogic Server from within the Maven environment.
weblogic.PlanGeneratoris a command-line tools that enables developers to export an application's configuration for deployment to multiple WebLogic Server environments.
The deployment API allows you to perform deployment tasks programmatically using Java classes.
autodeploydomain directory allows you to deploy an application quickly for evaluation or testing in a development environment.