Understanding WebLogic Server Deployment

 

  1. Overview of the Deployment Process
  2. J2EE 1.4 Deployment Implementation
  3. WebLogic Server Deployment Features
  4. Supported Deployment Units
  5. Deployment Tools

 


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 generally involves the following tasks:

 


J2EE 1.4 Deployment Implementation

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. WebLogic Server deployment descriptors are generated as needed to store WebLogic Server configuration data.

Configuring Applications with the J2EE 1.4 Deployment API

The WebLogic Server deployment plan generated by a J2EE 1.4 deployment API deployment tool identifies the WebLogic Server deployment descriptors that were generated for the application during the configuration session.

The J2EE 1.4 deployment API does not address many deployment features that were available in previous WebLogic Server releases. For this reason, WebLogic Server provides important extensions to the J2EE 1.4 deployment API specification to support capabilities

 


WebLogic Server Deployment Features

Weblogic Server supports the following advanced deployment features to help you reliably deploy and manage applications in a production environment.

 

Additional Deployment Configuration Properties

WebLogic Server extensions to J2EE 1.4 deployment API allow you to configure many additional deployment properties, including:

You can store these deployment properties in WebLogic Server deployment plans.

 

Exporting Applications for Deployment to Multiple Environments

The basic J2EE 1.4 deployment API configuration process 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 J2EE 1.4 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.

 

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.

See:

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 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:

 

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.

 

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.

 


Supported Deployment Units

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:

 

Enterprise Application

An Enterprise Application consists of one or more of the following J2EE applications or 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.

 

Web Application

A Web application always includes the following files:

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.

 

Enterprise JavaBean

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.

 

Resource Adapter

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.

 

Web Service

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.

 

J2EE Library

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.

 

Optional Package

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 (stand-alone 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.

 

JDBC, JMS, and WLDF Modules

A JMS, JDBC, or WebLogic Diagnostic Framework (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.

 

Client Application Archive

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-appclient.xml descriptor.

 


Deployment Tools

Weblogic Server provides the following tools to help you configure and deploy applications:

 

weblogic.Deployer

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.

 

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.

 

WLST

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.

 

Deployment Tools for Developers

WebLogic Server provides several tools for deploying applications and stand-alone modules: