Deployments

Installing an application is said to be deployment. This is what server is developed for.

Deployment Targets:

        Deployment targets are the servers to which you deploy an application or standalone module. During the deployment process, you select the list of targets from the available servers, clusters, and virtual hosts configured in your domain. You can also change the target list at any time after you have deployed a module.

        Admin Server

Managed Server

Cluster

Virtual host

Deployment tools:

Admin 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.

Command line utilities

    WLST

           Scripting tool used to deploy and perform all other admin tasks.

    WL deploy

          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.deployer

           Provides a command-line based interface for performing both basic and advanced deployment tasks.

Open deploy (upload)

Deployment phases:

       WebLogic Server uses a two-phase deployment protocol when deploying applications and standalone modules in a domain. The protocol ensures the consistency of deployments to multiple WebLogic Servers in a domain, and also supports advanced deployment features such as application ordering and improved monitoring.

Each deployment in a WebLogic Server domain takes place in two phases: prepare and activate.

Prepare

The prepare phase ensures that the application and its modules are in a state in which they can be reliably deployed. During the prepare phase, WebLogic Server instances in the domain complete the following tasks:

       1. If necessary, the Administration Server copies deployment files to the target servers' staging directories specified by the Staging Directory Name attribute.

       2. Each target server validates the deployment files and checks for possible errors to ensure that the files can actually be deployed.

Active phase

In the activate phase, target servers make the application available for clients to use. The activate phase constitutes the actual deployment of the application or module.

The activation phase only takes place after the prepare phase successfully completes.

Deployment Operations:

Deploy-install

        Making deployment source files available to target servers and loading classes into classloaders so that applications are available to clients.

Undeploy-uninstall

        stopping a deployment unit and then removing its deployment files and deployment name from target servers.

Update-redeploy

         Updating an deployment unit or part of a deployment unit (for example, an EAR, a module within an EAR, or a static file in a Web Application) that is currently deployed and available to clients. When redeploying an entire application, all of the application's modules must redeploy successfully or the entire application is stopped.

Note: An application becomes unavailable to clients during redeployment. WebLogic Server doesn't guarantee the operation of the application and deployment task if there is an access from the client at this time. For this reason, redeployment is not recommended for use in a production environment.

Start

       reloading an application's classes into classloaders and making the application available to clients. Starting requires that the deployment files be available on target servers as a result of an earlier deployment.

Stop

      Unloading an application's classes and making an application unavailable to clients. Stopping still leaves the deployment files and deployment name available to target servers for subsequent redeployment or starting.

Distribute:

         For stage mode deployments, only copy the deployment files to the target servers (but do not start the deployment).

Deployment units:

         A deployment unit refers to a J2EE application (an Enterprise Application or Web Application) or a standalone J2EE module (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 deployments that are packaged either as archive files using the jar utility, or as exploded archive directories.

Deployable applications:

          J2EE also defines several different types of deployable applications: Web Applications, Enterprise Applications, and client applications. Applications generally include one or more standalone J2EE modules to provide a logical service, and may also provide a direct user interface to the applications' contents.

Web Application:

      A Web Application always includes the following files:

•   A servlet or JSP page, along with any helper classes. 
•   A 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

Enterprise Application:

    An Enterprise Application consists of one or more of the following J2EE applications or modules:

•   Web Applications
•   Enterprise Java Beans (EJB) modules
•   Resource Adapter modules

An Enterprise Application is packaged as a JAR 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.

Client Application archives:

         The J2EE specification provides the ability 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. Client modules in an EAR are defined using the J2EE standard application-client.xml deployment descriptor and an optional WebLogic Server descriptor, client-application.runtime.xml.

Startup and shutdown Classes:

Startup and shutdown classes are Java classes that you can configure to load and execute when you start up or gracefully shut down a server. The deployment process for startup and shutdown classes differs from other deployable units, because you do not specify any actual deployment files. Instead, you identify the servers that will execute the class, and specify the classpath and optional arguments to use for execution.

Staging modes:

      The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or standalone module. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. The following table describes the behavior and best practices for using the different deployment staging modes.

Deployment Staging Mode	Behavior	When to Use
stage	The Administration Server first copies the deployment unit source files to the staging directories of target servers specified by the Staging Directory Name attribute. The target servers then deploy using their local copy of the deployment files.	Deploying small or moderate-sized applications to multiple WebLogic Server instances. Deploying small or moderate-sized applications to a cluster.
nostage	The Administration Server does not copy deployment unit files. Instead, all servers deploy using the same physical copy of the deployment files, which must be directly accessible by the Administration Server and target servers. With nostage deployments of exploded archive directories, WebLogic Server automatically detects changes to a deployment's JSPs or Servlets and refreshes the deployment. (This behavior can be disabled if necessary.)	Deploying to a single-server domain. Deploying to a cluster on a multi-homed machine. Deploying very large applications to multiple targets or to a cluster where deployment files are available on a shared directory. Deploying exploded archive directories that you want to periodically redeploy after changing content. Deployments that require dynamic update of selected Deployment Descriptors via the Administration Console.
external_stage	The Administration Server does not copy deployment files. Instead, the Administrator must ensure that deployment files are distributed to the correct staging directory location before deployment (for example, by manually copying files prior to deployment). With external_stage deployments, the Administration Server requires a copy of the deployment files for validation purposes. Copies of the deployment files that reside in target servers' staging directories are not validated before deployment.	Deployments where you want to manually control the distribution of deployment files to target servers. Deploying to domains where third-party applications or scripts manage the copying of deployment files to the correct staging directories. Deployments that do not require dynamic update of selected Deployment Descriptors via the Administration Console (not supported in external_stage mode). Deployments that do not require partial redeployment of application components.

Most deployments use either stage or nostage modes, and the Administration Console automatically suggests the appropriate mode when you deploy an application or module.

Security role required to deploy an application:

The built-in security roles for "Admin" and "Deployer" users allow you to perform deployment tasks using the WebLogic Server Administration Console.

Deployment names:

When you first deploy an application or standalone module to one or more WebLogic Server instances, you specify a deployment name to describe collectively the deployment files, target servers, and other configuration options you selected. You can later redeploy or stop the deployment unit on all target servers by simply using the deployment name. The deployment name saves you the trouble of re-identifying the deployment files and target servers when you want to work with the deployment unit across servers in a domain.

If you do not specify a deployment name at deployment time, the deployment tool selects a default name. For exploded archive directories, the default deployment name is the name of the top-level directory you deploy. For archive files, the deployment name is the name of the archive file without the file extension (myear for the file myear.ear).