Deploying Applications

At the end of this chapter you will be able to:

• Describe the Web server capabilities of WebLogic Server
• Describe the Enterprise Java Bean (EJB)
• Describing the Enterprise Application Folder Structure
• Deployments Plans and Side By Side Deployments

 Web Servers:

Web servers are computers on the Internet that host websites, serving pages to viewers upon request. This service is referred to as web hosting. Every web server has a unique address so that other computers connected to the internet know where to find it on the vast network. The Internet Protocol (IP) address looks something like this: 127.0.0.1. This address maps to a more human friendly address, such as http://www.google.com

The Client Server Architecture:

The Internet revolves around the client-server architecture. Your computer runs software called the client and it interacts with software known as the server located at a remote computer. The client is usually a browser such as Internet Explorer, Netscape Navigator or Mozilla. Browsers interact with the server using a set of instructions called protocols. These protocols help in the accurate transfer of data through requests from a browser and responses from the server. There are many protocols available on the Internet. The World Wide Web, which is a part of the Internet, brings all these protocols under one roof. You can, thus, use HTTP, FTP, Telnet, email etc. from one platform - your web browser.

Some common Internet protocols

• HTTP (Hyper Text Transfer Protocol): used on the World Wide Web (WWW) for transferring web pages and files contained in web pages such as images.
• FTP (File Transfer Protocol): employed for transferring files from one machine to the other.
• SMTP (Simple Mail Transport Protocol): used for email.
• Telnet Protocol: Used to open telnet sessions.

The web employs a connection-less protocol, which means that after every client-server interaction the connection between the two is lost Let us now examine the client-server inter-communication with two  models.

Model #1 of the client-server architecture - Static HTML pages

The client (browser) requests for an HTML file stored on the remote machine through the server software. The server locates this file and passes it to the client. The client then displays this file on your machine. In this case, the HTML page is static. Static pages do not change until the developer modifies them.

Model #2 of the client-server architecture - Server side scripting technologies

The second case also involves dynamic response generated by the use of server side technologies. There are many server side technologies today.

Java Server Pages: .jsp pages contain Java code.

Server Side Includes (SSI): Involves the embedding of small code snippets inside the HTML page. An SSI page typically has .shtml as its file extension. With these server technologies it has become easier to maintain Web pages especially helpful for a large web site.

The Role of Web Servers

• Web servers are responsible for handling HTTP requests from clients.
• Web servers typically return:
• Static content (HTML pages, graphics, …)
• Dynamic content (Servlet, JSPs, CGIs, …)

  A Typical Web Interaction

MIME Types:

• Multipurpose Internet Mail Extensions (MIME) is a protocol for identifying and encoding binary data.
• All HTTP response data is encoded with a MIME content type.
• Browsers interpret HTTP response data differently depending upon the MIME type of the data:
  • HTML pages are parsed and displayed
  • PDF documents can be sent to Adobe Acrobat
  • application code can be directly executed

 HTTP Status Code Definitions

• HTTP status codes:
  • indicate to the client whether or not the request was successful
  • provide the client a reason for a failed request
  • used by clients to provide alternate behavior

Each Status-Code is described below, including a description of which method(s) it can follow and any Meta information required in the response.

1xx - Informational  

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

Ex: 100 – Continue, 101 - Switching Protocols  

2xx - Successful  

This class of status code indicates that the client's request was successfully received, understood, and accepted.

Ex: 200 – Ok, 201 – Created  

3xx – Redirection:  

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD.

Ex: 301 - Moved Permanently, 302 – Found  

4xx - Client Error:  

The 4xx class of status code is intended for cases in which the client seems to have erred.

Ex: 400 Bad Request, 401 Unauthorized, 404 Not Found  

5xx - Server Error:

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request.

Ex: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable  

Static Content:

• Static content documents are predefined on the server and do not change.
• WebLogic Server can be used to serve static content
• such as:
  • HTML documents
  • images
  • PDF documents
• WebLogic Server can serve static documents:
  • over standard HTTP
  • through SSL using HTTPS

 Dynamic Content:

• Dynamic content documents may change based on the client’s request.
• HTML documents can be created on the fly by using:
  • Servlets
  • JavaServer Pages (JSPs)
  • Common Gateway Interface (CGI) programs

 Web Applications

 What Is a Web Application?

A web application is any application that uses a web browser as a client. The application can be as simple as a message board or a guest sign-in book on a website, or as complex as a word processor or a spreadsheet. A Web Application is a group of server-side resources that create an interactive online application.   Server-side resources include:

• Servlets (small server-side applications)
• JavaServer Pages (dynamic content)
• static documents (HTML, images)
• Server-side classes
• Client-side applets and beans

 Packaging Web Applications

You add web components to a J2EE application in a package called a web application archive (WAR), which is a JAR similar to the package used for Java class libraries. A WAR usually contains other resources besides web components, including:  

• Server-side utility classes (database beans, shopping carts, and so on).
• Static web resources (HTML, image, and sound files, and so on)
• Client-side classes (applets and utility classes)

  A WAR has a specific hierarchical directory structure. The top-level directory of a WAR is the document root of the application. The document root is where JSP pages, client-side classes and archives, and static web resources are stored. The document root contains a subdirectory called WEB-INF, which contains the following files and directories:  

• web.xml - the web application deployment descriptor
• Tag library descriptor files (see Tag Library Descriptors).
• classes - a directory that contains server-side classes: servlet, utility classes, and JavaBeans components.
• lib - a directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes).

  You can also create application-specific subdirectories (that is , package directories) in either the document root or the WEB-INF/classes directory. Before deploying an application package and registering it with a WLS server. Follow these steps to package a Web App:  

1. Arrange resources in a prescribed directory structure
2. Develop web.xml Deployment Descriptor (or copy as required)
3. Develop weblogic.xml Deployment Descriptor (WLS-Specific)
4. Archive Web App into .war file using jar by using jar –cvf command
5. Deploy Web App onto WLS
6. Configure Web App with WLS Administration Console

Web Application Structure

The structure of Web Applications is defined by the Servlet specification. A Web Application can be either:  

• an archived file (.war file)
• An expanded directory structure

Configuring Web Applications 

Web applications are configured through deployment descriptors web.xml and weblogic.xml which:

• Define run-time environment
• Map URLs to Servlets and JSPs
• Define application defaults such as welcome and error pages
• Specify J2EE security constraints
• Define work managers for applications
• Set the context-root for the application

The web.xml File

The web.xml file is a deployment descriptor for configuring:

• Servlets and JSP registration
• Servlet initialization parameters
• JSP tag libraries
• MIME type mappings
• Welcome file list
• Error pages
• Security constraints and roles
• Resources
• EJB references

The weblogic.xml File

The weblogic.xml is a WebLogic Server specific deployment descriptor for configuring:

• JSP properties
• JNDI mappings
• Security role mappings
• HTTP session parameters
• Work managers
• Context root
• Virtual directory mappings
• Logging parameters
• Library modules

Example of weblogic.xml deployment descriptor. <?xml version=’1.0’ encoding=’utf-8’?> <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> </weblogic-web-app>  

Web Application Archive:

• Web Application archives (.war files)
  • are compressed files that contain directory structures that represent Web Applications
  • simplify the distribution and sharing of Web Applications across a network
  • can share common resources
  • can be combined into larger applications
• For ease of development and debugging Web Applications are not archived until the end of production.

Web archives are created using the jar utility:

URLs and Web Apps

The URL used to reference a resource in a Web Application must include the name of the Web Application. Accessing a resource in a Web Application: http://hostname:port/MyWebApplication/resource Where: resource: Static page, Servlet mapping, or JSP MyWebApplication: Name of the Web Application; not necessary if this is the default Web Application Hostname: Host name mapped to virtual host or hostname: port  

Virtual Directory Mappings:

Virtual directories:

• can be used to refer to physical directories
• let you avoid the need to hard-code paths to physical directories
• allow multiple Web applications to share common physical directories for specific requests such as images
• decrease duplication of files across applications
• are configured in weblogic.xml

Virtual Directory Mapping Example <virtual-directory-mapping> <local-path>c:/usr/gifs</local-path> <url-pattern>/images/*</url-pattern> <url-pattern>*.jpg</url-pattern> </virtual-directory> <virtual-directory-mapping> <local-path>c:/usr/common_jsps.jar</local-path> <url-pattern>*.jsp</url-pattern> </virtual-directory>  

Archive vs. Expanded Directory:

• Archive Web Applications if:
  • in production phase
  • deploying to several machines
• Do not archive Web Applications if:
  • in development/debugging phase
  • application will be updated frequently
  • deploying to a single machine (Administration server)

Enterprise JavaBeans

Enterprise JavaBeans (EJB) is a comprehensive technology that provides the infrastructure for building enterprise-level server-side distributed Java components. The EJB technology provides a distributed component architecture that integrates several enterprise-level requirements such as distribution, transactions, security, messaging, persistence, and connectivity to mainframes and Enterprise Resource Planning (ERP) systems.  

EJB Architecture

Any distributed component technology should have the following requirements:

1. There should be a mechanism to create the client-side and server-side proxy objects. A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object. On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object.

2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy.

3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client.

Enterprise JavaBeans™ (EJB) standardizes development and deployment of Java server components.

• The EJB specification defines relationships between:
  • the EJB and its container
  • the container and the application server
  • the container and the client

Session Beans: Stateful and Stateless Session beans can be either stateful or stateless. Stateful session beans maintain conversational state when used by a client. Conversational state is not written to a database but can store some state in private variables during one method call and a subsequent method call can rely on this state. Maintaining a conversational state allows a client to carry on a conversation with a bean. As each method on the bean is invoked, the state of the session bean may change and that change can affect subsequent method calls. Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. One can specify whether a bean is stateful or not in the bean's deployment descriptor.

Entity Beans: Container and Bean Managed Persistence There are two types of entity beans and they are distinguished by how they manage persistence. Container-managed beans have their persistence automatically managed by the EJB container. This is a more sophisticated approach and here the bean developer does not implement the persistence logic. The developer relies on the deployment descriptor to specify attributes whose persistence should be managed by the container. The container knows how a bean instance's fields map to the database and automatically takes care of inserting, updating, and deleting the data associated with entities in the database.  

Deployment Descriptors: 

Much of the information about how beans are managed at runtime is not supplied in the interfaces and classes mentioned above. There are some common primary services related with distributed systems apart from some specific services such as security, transactions, naming that are being handled automatically by EJB server. But still EJB server needs to know beforehand how to apply the primary services to each bean class at runtime. Deployment descriptors exactly do this all important task.  

JAR Files: 

Jar files are ZIP files that are used specifically for packaging Java classes that are ready to be used in some type of application. A Jar file containing one or more enterprise beans includes the bean classes, remote interfaces, home interfaces, and primary keys for each bean. It also contains one deployment descriptor.  

EJB Application Directory Structure:

• EJB components come packaged in JAR files.
• EJBs are configured by modifying deployment descriptors.

EJB administrator tasks include:

• configure and deploy
• resolve JNDI and other infrastructure issues
• monitor EJB caches and pools

Types of EJBs

Enterprise JavaBeans server-side components come in two fundamentally different types: entity beans and session beans.

What Is an Enterprise Application?

An enterprise application is a business application, obviously. As most people use the term, it is a big business application. In today’s corporate environment, enterprise applications are complex, scalable, distributed, component-based, and mission-critical. They may be deployed on a variety of platforms across corporate networks, intranets, or the Internet. They are data-centric, user-friendly, and must meet stringent requirements for security, administration, and maintenance. In short, they are highly complex systems. Designing and developing such enterprise applications means satisfying hundreds or thousands of separate requirements. What’s more, every development decision you make to satisfy each requirement affects many other requirements, often in ways that are difficult to understand or predict — and the failure to meet any of these requirements can mean the failure of the entire project! An enterprise application is a grouping of several resources into one deployable unit packaged in an .ear file. These resources include: – Web applications (.war) – EJB applications (.jar) – Java applications (.jar) – Resource adapters (.rar)  

J2EE Enterprise Application

Why Enterprise Applications?

Use enterprise applications to: – Avoid name space clashes – Declare application-wide security roles – Deploy an application as one unit – Share application-wide EJB resources – Configure local JDBC datasources – Configure local JMS resources – Configure local XML resources  

EAR File Structure

An example directory structure of an enterprise application is shown below:

Configuring WLS Specific Features  

Configure Enterprise-wide WLS specific features with weblogic-application.xml deployment descriptor:  

• XML parsers
• XML entity mappings
• JDBC datasources
• JMS connection factories and destinations
• Security realms

  WLS Application Class Loader

Each application receives its own class loader hierarchy with the system class loader as its parent.

EAR Class Libraries:  

• Extending the J2EE spec, BEA has added APP-INF/lib and APP-INF/classes to the standard J2EE ear file structure.
• When the application is initialized, paths extracted are appended to the beginning of the application’s CLASSPATH
• Classes are added to the root classloader of the application.

 J2EE Library Support:

• To make things easier, you can create a library of J2EE modules, package them into an Enterprise application (EAR) then deploy and register it with the application container.
• Afterwards, other applications can use the modules as if they were packaged in their own EAR files.
• This allows for more reusability between applications.

Deployment  

Deploying an application involves the following tasks:

• Preparing - Choosing whether to package the application as an archived file or keeping it in an exploded directory
• Configuring – Creating a deployment plan to maintain configuration changes without changing the deployment descriptors
• Deploying – Targeting and distributing the application to WebLogic servers in a domain

Deployment Methods

WLS supports three deployment methods: – Auto-deployment – console deployment – Command-line deployment  

You can deploy: – Enterprise applications – Web applications – Web Services – J2EE libraries – JDBC, JMS and Diagnostic Framework modules – EJB components – Resource adapters – Optional packages – Client application archives  

Applications and EJBs can be deployed: – in an archived file (.ear, .war, .jar) – Or in exploded (open) directory format  

Auto-Deployment – Copying Files

If Production Mode is OFF:

• You can install an application simply by copying it (manually or using the console) to the ‘autodeploy’ folder of the domain
• The Administration Server monitors this folder for new, changed or removed applications
• This configures, targets and deploys the application to the Administration server only

Location of Applications Directory: %BEA_HOME%\user_projects\domains\domain_name\autodeploy  

Development vs. Production Modes

• An Administration server starts either using:
  • development mode, which turns auto-deployment on
  • production mode, which turns auto-deployment off
• The Administration server starts in the mode selected at domain creation time.
• The mode is set for all WebLogic servers in a given domain.

  Production Mode Flag

• When Production mode is disabled, applications can be dynamically deployed.
• Application poller will be enabled in Development Mode.

Console Deployment Method…

• Deploying with the console allows full administrator control:
  • Installation from a location of your choice
  • Manual configuration of application name
  • Targeting of application to individual servers and/or clusters
  • Configuring the application without targeting it
  • Activating deployment when desired

DD Editing

Some deployment descriptor elements are editable via the console

Application Monitoring

Application Testing

You can test a deployed application using the administration console.

Application Update and Delete…

• Using the console, applications can be updated (redeployed) after configuration or component changes, or deleted (undeployed).

• All concurrent deployment activity is tracked by the Administration server in a series of tasks:
  • Task progress and outcome can be queried for each application
  • Reasons for failure are logged

Command-Line Deployment:

Any function that can be done through the Weblogic admin console can be done through command-line equivalents. A simple example of this is redeploying an existing webapp.

Using weblogic.Deployer Utility

To use the weblogic.Deployer utility:

   1. Set up your local environment so that WebLogic Server classes are in your system CLASSPATH and the JDK is available. You can use the setenv script located in your server's /bin directory to set the CLASSPATH.
   2. Use the following command syntax:

    % java weblogic.Deployer [options] [actions] [file(s)]

Here are the examples that can be seen by issuing the command 

java Weblogic.deployer -examples:

Deploy application on admin server:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -deploy c:/myapps/myapp.ear

Deploy individual modules in application to different targets:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -targets mywar@webserver,myjar@ejbserver -deploy

c:/myapps/myapp.ear

Undeploy application from specified targets:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -undeploy -targets server1,server2..

Redeploy application on current targets:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -redeploy

Redeploy individual module in an application:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -redeploy -targets moduleA@serverA,moduleA@serverB

Partially redeploy, for example, to update a JSP in a exploded webapp:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -redeploy mywar/index.jsp

The path of JSP to be updated is relative to the root of the application. If a directory is specified the entire subtree is updated.

Multiple servers sharing the same physical deployment:

java weblogic.Deployer -adminurl url -username username -password password

-name myapp -targets server1,server2 -nostage -deploy c:/myapps/myapp.ear

 The -nostage option indicates that the application is available on all target servers at the same path and hence server should not copy files to the managed servers.

 Deploying Applications with WLST

• WLST provides a number of deployment commands
• You can use these commands to:
  • Deploy, undeploy, and redeploy applications and standalone modules to a WebLogic Server instance
  • Update an existing deployment plan
  • Start and stop a deployed application

Deploying an Application with WLST:

Deploy an application (deployapp.py): #                                                               

# # WLST script for Deploying J2EE Application  # #                                                               

# # Connect to the server print ’Connecting to server  .... ’ connect(’system’,’weblogic’,’t3://localhost:7001’)

appname = "mbeanlister" applocation = "c:/domains/dizzyworld/apps/mbeanlister"

# Start deploy print ’Deploying application ’ + appname

deploy(appname, applocation, targets=’myserver’, planPath=’c:/myapps/plan/plan.xml’)

print ’Done Deploying the application ’+ appname exit()  

What Is a Deployment Plan?

• It is an optional XML document that resides outside an application archive.
• It configures an application for deployment to a specific WLS environment.
• It is created and owned by Administrators or developers for a particular environment.

Advantages of Deployment Plan:

• Works by setting/overriding deployment property values defined in application’s WLS deployment descriptor.
• Helps easily modify an application’s WLS configuration for deployment into different multiple WLS environments without modifying the deployment descriptor files included in the application archive.
• Enables an application to be deployed to multiple domains or to multiple target servers and clusters that have different configuration within the same domain.

Configuring an Application for Multiple Deployment Environments

Sample Deployment Plan

<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90"> <application-name>sample_root</application-name> <variable-definition> <variable> <name>SessionDescriptor_InvalidationIntervalSecs_11029744771850</name> <value>80</value> </variable> <variable> <name>SessionDescriptor_TimeoutSecs_11029744772011</name> <value>8000</value> </variable> </variable-definition> <module-override> <module-name>jspExpressionEar.ear</module-name> <module-type>ear</module-type> <module-descriptor external="false"> <root-element>weblogic-application</root-element> <uri>META-INF/weblogic-application.xml</uri> </module-descriptor> <module-descriptor external="false"> <root-element>application</root-element> <uri>META-INF/application.xml</uri> </module-descriptor> </module-override> <module-override> <module-name>jspExpressionWar</module-name> <module-type>war</module-type> <module-descriptor external="false"> …  

Creating a Deployment Plan

• Tools for creating a deployment plan
  • PlanGenerator
  • Administration Console
• Goals for creating a deployment plan
  • To expose the external resource requirements of the application as variables in the deployment plan
  • To expose additional configurable properties, such as tuning parameters as variables in the deployment plan

WebLogic.PlanGenerator

• Java-based deployment configuration tool.
• It is primarily intended for developers who want to export portions of a WebLogic Server deployment configuration into an XML deployment plan.
• Enables you to generate a basic WebLogic Server configuration for applications that have only J2EE deployment descriptors.

Ex: java weblogic.PlanGenerator -all -plan D:\lab\work\plan\Plan.xml D:\lab\labs\Lab12\exercise\companyStoreAdmin.ear  

Using the Admin Console to Generate a Deployment Plan

• Administration Console automatically generates or updates the deployment plan.
• Generating a deployment plan using the Administration Console involves the following steps:
  • Preparing the deployment files
  • Installing the application archive
  • Saving configuration changes to a deployment plan

 Using an Existing Deployment Plan to Configure an Application

1. Prepare application.
2. Place the existing deployment plan in the plan subdirectory of the application root.
3. Install the application.
4. Administration console validates deployment plan configuration against the target servers and clusters selected during installation.
5. Use Administration console or the weblogic.Deployer utility to identify the application and plan to use for deployment.

  Directory Structure for Easier Production Deployment

This allows deployment configuration files to be located in a well-known location.

• The application directory structure separates generated configuration files from core application files.
• This allows configuration files to be easily changed or replaced without disturbing the application itself.
• Applications can be deployed simply by specifying the installation root.

Sanity Checking in Production without Disruption to Clients

• Using Administration mode, administrators can deploy an application into a production environment without exposing the application to external clients.
• Access to the application is restricted to a configured Administration channel.
• A final (“sanity”) check can be performed on the application directly in the production environment without disruption to clients.

Staged Deployment

Deployment can be configured per server or for each application as:

• staged (default)—files copied to preconfigured staging directory for preparation and activation
• no-stage—files deployed from static location
• external_stage—files copied by user or third-party tool prior to deployment

Side-by-Side Deployment

• A revised version of a production application can be redeployed alongside the older version:
  • Without affecting the existing clients to the application
  • Without interrupting the availability of the application to the new client request
• WebLogic Server automatically manages client connections so that:
  • Existing clients continue to use the older application
  • New client requests are directed to the newer application
• The older version is undeployed after all current clients complete their work.

• To support the production redeployment strategy, WebLogic Server now recognizes a unique version string entry in the Enterprise MANIFEST file.

• When a redeployment operation is requested, WebLogic Server checks the version string to determine whether to deploy a new version of the application.

• Side-by-Side deployment is performed automatically if:
  • An application supports production redeployment
  • Its deployment configuration is updated with changes to resource bindings

• This occurs even if no version string is specified in the application’s manifest file.

Advantages of Side-by-Side Deployment

1. Scheduling application downtime
2. Setting up redundant servers to host new application versions
3. Managing client access to multiple application versions manually
4. Retiring older versions of an application manually

 Requirements and Restrictions for Side-by-Side Deployment

1. A deployed application must specify a version number.
2. WLS can host a maximum of two different versions of an application at one time.
3. On redeploying a new version of an application the followings features cannot change:

• Deployment targets
• Security model
• Persistent store settings

  Production redeployment is supported for:

• Stand-alone Web Application (WAR) modules.
• Enterprise Applications (EARs) whose client access the application via a Web Application (HTTP)

  Production redeployment is not supported for:

• EJB or RAR modules
• Stand-alone or embedded Web Service modules
• Applications that use JTS drivers
• Applications that obtain JDBC data sources via the DriverManager API instead of using the JNDI lookup
• Applications that include EJB 1.1 container-managed persistence (CMP) EJBs

  Redeploying a New Application Version

1. Verify only one version of the application is currently deployed.
2. Verify the MANIFEST.MF files to ensure both applications have different versions.
3. Copy new version into a suitable directory.
4. Redeploy the new application version and specify updated deployment files.
5. Verify both versions are deployed and new requests are being sent to the new version.

  Redeploy vs. Distribute

• Distributing is an alternative to deploying an application.
  • Distributing an application prepares it for deployment by copying its files to all target servers and validating it.
  • You can start a distributed application in Administration mode. Access to the application is then restricted to a configured Administration channel.
• Distributing a new version of the application makes it available for testing prior to being released for general consumption.
• Redeploying a new version of an application will place the application immediately into use and will make it available to new client requests.

Distributing a New Application Version

1. Use the weblogic.Deployer –distribute command
2. Once the application is distributed, start the application in Administration mode
3. Test the application
4. When ready, start the application (without using – adminmode)
5. Optionally set a retirement timeout for the older version of the application.

  Summary: In this chapter we discussed:

• Web & EJB Applications and Deployment Structures
• Deployment Plans
• Deployment staging
• Side-by-Side Deployment