The following sections provide an overview of WebLogic Server deployment:
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 generally involves the following tasks:
WebLogic Server implements the Java EE 5 specification. Java EE 5 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 5 deployment specification. You can use a basic Java EE 5 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 Java EE 5 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 Java EE 5 deployment API deployment tool identifies the WebLogic Server deployment descriptors that were generated for the application during the configuration session.
Although the Java EE 5 deployment API provides a simple, standardized way to configure applications and modules for use with a Java EE 5-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 5 deployment API specification to support capabilities described in WebLogic Server Deployment Features.
WebLogic Server supports the following advanced deployment features to help you reliably deploy and manage applications in a production environment.
Whereas the Java EE 5 deployment API deployment specification enables you to generate vendor-specific descriptor values necessary for deploying an application, WebLogic Server extensions to Java EE 5 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.
The basic Java EE 5 deployment API configuration process provides a simple way for standardized deployment tools to deploy J2EE 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 5 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 Chapter 5, "Exporting an Application for Deployment to New Environments".
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.
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.
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 Chapter 8, "Redeploying Applications in a Production Environment".
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.
A deployment unit refers to a J2EE application (an Enterprise application or Web application) or a standalone 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 consists of one or more of the following J2EE 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.xml deployment 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, 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 Programming WebLogic Enterprise JavaBeans 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 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 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 Getting Started With JAX-WS Web Services for Oracle WebLogic Server.
A J2EE library is a standalone 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 for Oracle WebLogic Server describes how to assemble and configure J2EE libraries, and how to configure Enterprise applications that utilize J2EE libraries.
Deploying Shared Java EE Libraries and Dependent Applications 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 as individual J2EE 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 J2EE modules and applications that reference the optional package in their
MANIFEST.MF files. Creating Shared J2EE Libraries and Optional Packages in Developing Applications for Oracle WebLogic Server describes how to assemble and configure optional packages, and how to configure J2EE modules that utilize optional packages.
Deploying Shared Java EE Libraries and Dependent Applications describes how to deploy optional packages and J2EE modules that reference optional packages.
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 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:
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 Server provides the following 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 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.
Use the Administration Console 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 Oracle WebLogic Scripting Tool for more information.
WebLogic Server provides several tools for deploying applications and standalone modules:
wldeploy is an Ant task version of the
weblogic.Deployer utility. You can automate deployment tasks by placing
wldeploy commands in an Ant
build.xml file and running Ant to execute the commands.
weblogic.PlanGenerator is 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.
autodeploy domain directory allows you to deploy an application quickly for evaluation or testing in a development environment.