Chapter 11. Deployment
Chapter 11. Deployment Table of Contents
J2EEDeploymentPhases...... 1 What Happens During Deployment? ...... 3 ApplicationPackageRequirement...... 3 DeploymentDescriptorFiles...... 4 DeploymentScenarios...... 4 TypesofDeployment...... 6 DeploymentTools...... 7 Deploying a Sample Application ...... 8
This module describes deployment phases and scenarios, and Sun ONE Application Server deployment requirement. It also compares the different deployment types and tools available with Sun ONE Application Server and shows how to deploy a sample application using Administration GUI.
Objectives
• Identify J2EE deployment phrases and scenarios.
• List the package requirement of an application to deploy to Sun ONE Application Server
• Differentiate J2EE standard and Sun ONE Application Server deployment descriptors
• Describe the deployment types and tools supported by Sun ONE Application Server
• Deploy a sample application using Administration GUI
J2EE Deployment Phases
In J2EE specifications, deploying an application involves three phases:
• Component creation, done by application developers.
• Application assembly, done by possibly a different set of application developers.
• Application deployment, done by developers and administrators.
1 Chapter 11. Deployment
Component Creation
Application developers create individual files and group them into modules. Each module includes an XML file called a deployment descriptor. This file describes the parameters needed to deploy the module's components.
One type of module is called a .war file, which stands for web archive file. A .war file might contain components such as servlets, JSP files, and static files such as HTML and images.
Another type of module is called a .jar file, which stands for Java archive file. This module is sometimes called an EJB .jar file because it contains the Java files that together make up an enterprise bean.
Application Assembly
Application developers assemble modules into an .ear file, which stands for enterprise archive file. An .ear file rep- resents an application.
The various archive files—.war, EJB .jar, and .ear—all have the same format. They are all JAR files. The file suf- fixes differ so that you can distinguish the components they contain. These suffixes are mandated by the J2EE speci- fication. JAR is a file format based on the popular ZIP file format. In short, JAR files are .zip files.
Application Deployment
2 Chapter 11. Deployment
During development and testing, application programmers will most likely deploy their own applications. When an application is ready for production, administrators usually deploy it. Deployment tasks include the following:
1. Optionally configuring the .ear file.
2. Specifying the destination hosts and directories for the .ear file.
3. Running the deployment command (from a command line or from a GUI tool).
What Happens During Deployment?
When you deploy an application, its components are deployed to a container, which provides various services. A Sun ONE application is deployed as a set of nested units or modules. A module consists of one or more components for the same container type and one deployment descriptor of that type. In other words a module is the smallest, in- dependent deployable unit for a particular container and is often referred to as a deployment unit.
Components
A component is an application-level software unit. Component may be defined as the smallest, independent, soft- ware functional unit in a Sun ONE application server environment. A component may be a single class or a collec- tion of classes. Sun ONE application server platform supports the following types of components: EJB components, Web Components, applets, application clients or resource adapter components. For example, a component can be an EJB, a servlet, a JSP page, applet, an application client or a connector.
Containers
Containers provide services to the components. In other words, components depend on some runtime support, pro- vided by container. A component doesn’t exist on its own and it’s lifecycle is controlled by the container. Compo- nents communicate with each other and to the outside world, using the services of containers, such as lifecycle man- agement, theading, security etc.
Services
A component uses services provided by the container such as naming, deployment, transaction,and security. These services simplify application programming and allow components and applications to be customized at deployment time to use resources available in the deployment environment.
Application Package Requirement
Applications deployed to the Sun ONE AS must comply with standard J2EE packaging requirements. Refer to the J2EE specification and the Sun ONE Application Server documentation for details on packaging requirements.
A packaged application is an EAR (Enterprise Archive) file that contains compiled Java classes, HTML pages, JSPs, and a number of XML-based deployment descriptors. These components are deployed to the appropriate container (WEB/EJB) for a server instance; the container provides additional runtime support for applications. Once deployed, the application is available to users.
Other types of entities that can be deployed are WAR (Web Archive) and EAR (Enterprise Archive) files. All are in ZIP format and can be opened with any ZIP-compliant utility, like WinZip or the Unix zip/unzip utility. They are created with the App Server’s jar (Java Archive) utility, which can be executed by hand. 3 Chapter 11. Deployment
A Sun ONE application is deployed as a set of nested units or modules. A module consists of one or more compo- nents for the same container type and one deployment descriptor of that type. In other words a module is the small- est, independent deployable unit for a particular container and is often referred to as a deployment unit. It is usually the developer’s job to package the application into an EAR file that can be deployed to a server instance.
Deployment Descriptor Files
A deployment descriptor is a plain text file, with a .xml extension which conforms to the XML standards.
An application deployment descriptor, contains a list of the application’s modules and information on how to cus- tomize the application. Similarly, a component deployment descriptor contains declarative data to customize the component in the module.
J2EE Standard Descriptors
The J2EE platform provides assembly and deployment facilities. These facilities use JAR files as the standard pack- age for components and applications, and XML-based deployment descriptors for customizing parameters. The J2EE standard deployment descriptors are described in the J2EE specification, v1.3.
Table below lists J2EE modules and their associated deployment descriptors:
Table 11.1. J2EE Modules and Deployment Descriptors
Module Deployment Descriptors EJB modules Contain enterprise java beans and an ejb ejb-jar.xml sun-ejb-jar.xml (optional) deployment descriptor. These are packaged as .jar files. Web modules Contain JSPs, servlets, image files, other web.xml sun-web.xml (optional) web related files and a web deployment descriptor. These are packaged as .war files. Resource Adapter modules Contain all java interfaces, ra.xml sun-ra.xml (optional) classes, native libraries and other documentation along with the resource adapter deployment descriptor. These are packaged as a .rar file. Application Client Modules Contain class files and an applicationclient.xml sunapplicationclient. xml application client deployment descriptor. These and are packaged as a .jar file.
Sun ONE Application Server Descriptors
The sun Deployment Descriptors extend the J2EE deployment descriptors by including Sun ONE Application Server-specific information necessary for deployment of the application on Sun ONE Application Server. If you de- ploy the application on a different platform, the Sun ONE Application Server-specific deployment descriptor files are essentially ignored (are not parsed). However, if these files are missing from the archive files, deployment on Sun ONE Application Server will fail.
Deployment Scenarios
Sun ONE Application Server supports application-based and module-based registration and deployment. For mod- ule-based registration and deployment, individual modules can be deployed independently of applications, allowing
4 Chapter 11. Deployment
the developer to make an appropriate choice.
Deployment by Module
Individual module-based deployment is preferable when components need to be accessed by:
• Other modules
• J2EE Applications
• RMI/IIOP clients (Module-based registration allows shared access to a bean from an RMI/IIOP client, a servlet, or an EJB.)
Modules can be combined into an EAR file and then deployed as a single module. This is similar to deploying the modules of the EAR independently.
Sun ONE Application Server 7 supports deployment of individual WAR and EJB JAR modules.
Deployment by Application
A J2EE application is a logical collection of one or more J2EE modules, tied together by a single, application-level DD. A J2EE application may contain zero or more client archive JAR files, EJB JAR files, or WAR files. It must contain at least one module though.
Deployment of RMI/IIOP Clients
Deployment is only necessary for clients that communicate with EJBs. Deploying an RMI/IIOP client is a three-step process:
1. Deploy the EAR or EJB JAR to be accessed by the RMI/IIOP client.
2. Assemble the necessary client files and deploy the client.
3. After deployment, a client JAR file is created in the following location for an application:
or in the following location for an individually deployed module:
The client JAR contains the ties and necessary classes for the RMI/IIOP client. Copy this file to the client ma- chine, and set the APPCPATH environment variable on the client to point to this JAR.
Deployment of Static Content
Static content (HTML, images, etc) can be hosted both on the web server and on the Sun ONE Application Server. However, when a WAR is registered, the static content gets deployed on the application server. All of the samples shipped with Sun ONE Application Server host the static content on the application server.
5 Chapter 11. Deployment
Types of Deployment
The following types of deployment are supported in Sun ONE Application Server:
• Normal deployment
• Dynamic deployment
• Dynamic redeployment
• Dynamic reloading
Definitions
Dynamic Deployment and Redeployment
Dynamic deployment and redeployment of J2EE applications enables you to perform initial deployments of applica- tions and subsequent redeployment without needing to restart the targeted application server instance. The applica- tion server completely reloads your application during redeployment. These features apply to both EAR level de- ployment as well as to deployments and individual web and EJB JAR module deployments. No server configuration changes are required to enable dynamic deployment and redeployment.
Dynamic Reloading
If dynamic reloading is enabled, you do not have to redeploy an application or module when you change its code. All you have to do is copy the changed class files into the deployment directory for the application or module. The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes.
This is useful in a development environment, because it allows code changes to be tested quickly. Dynamic reload- ing is not recommended for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that transit time become invalid. The client must restart the session. Note
You may encounter the term "hot deploy" while reading about application servers. In many cases, hot de- ploy refers to dynamic deployment, dynamic redeployment and dynamic reloading. However, make sure you look closely at the details of the application server documentation to determine if all of these capabili- ties are supported by a specific product.
Conditions for Deployment
Conditions for normal deployment:
• A J2EE technology application or module is being deployed for the first time.
• The target server instance is not running.
• The Sun ONE Application Server Administration Server is running. 6 Chapter 11. Deployment
• The application or module is enabled by default and can run immediately after the target server instance comes up.
Conditions for dynamic deployment:
• A J2EE technology application or module is being deployed for the first time.
• The target server instance is running.
• The Sun ONE Application Server Administration Server is running.
The Sun ONE Application Server Administration Server invokes the deployment backend when it finds a new appli- cation or module in a defined area on the file system. The application or module is enabled by default and can run without stopping the target server instance.
Conditions for dynamic redeployment:
• A J2EE technology application or module is being deployed for the first time. The target server instance is run- ning.
• The Sun ONE Application Server Administration Server is running.
The Sun ONE Application Server Administration Server invokes the deployment backend which detects a redeploy- ment. It then conveys to the server instance an undeployment is required, and overwrites the previously deployed bits and configuration.
The application or module is enabled by default and can run without stopping the server instance.
Conditions for Dynamic Reloading:
• A single class file is touched by a user while the server instance (or the application or module using that class) is running.
• The target server instance is running.
• The Sun ONE Application Server Administration Server need not be running.
• The application or module is enabled by default and can run without stopping the target server instance.
Deployment Tools
Deploying a J2EE application makes it available to users. Applications are deployed to one or more Sun ONE Ap- plication Server instances. Once deployed, users access applications simply by entering the appropriate URL in their browser.
There are multiple ways of deploying applications in Sun ONE Application Server 7, each with its own advantages:
• Administration GUI -- The Sun ONE Application Server provides a simple-to-use graphical user interface for deploying, undeploying (removing) applicaitons, and doing basic application management like starting and stop- ping applications.
7 Chapter 11. Deployment
• Administration CLI -- The asadmin command is a command-line utility that provides a number of tools for de- ploying and managing applications.
• Sun ONE Studio 4 for Java -- Sun ONE Studio is an Integrated Development Environment (IDE) for creating J2EE applications and modules. It includes tools for assembly and deployment.
• Assembly Tool -- A standalone assembly tool, based on the Reference Implementation, is available for assem- bling applications. This gives developers and administrators an additional tool for assembling applications.
• Ant -- The Jakarta ANT build utility is another command line utility that provides various tools for deploying and managing J2EE applications.
This course focuses on using the Administraiton GUI and CLI for deployment. It is assumed that the developer packages applications or modules.
Deploying a Sample Application
This page will walk you through the deployment process of a sample application. You have a choice of deploying and registering the application through either command line utilities or the Sun ONE Application Server administra- tive console. The sample application you will deploy is a simple web application.
GUI Based Deployment
Start the Administrative Console
1. Open a browser window and specify the location of your the administrative server's console application. http://localhost:4848
2. Sign in to the administrative console using the administrative user name and password supplied during product in- stallation.
Deploy the sample application
1. In the administrative console, select and expand the Applications node under the application server instance server1 in the left pane.
2. Select the Web Apps folder.
3. Click the Deploy button in the right pane.
8 Chapter 11. Deployment
4. Click Browse and specify the path of the application that you want to deploy. Here, we deploy the application simple, which is under directory
5. Click OK.
6. Specify the Web Application Name, Context Root and the Virtual Server for the application that you want to de- ploy.
9 Chapter 11. Deployment
Note: The Web Application Name is used to refer to the application on the Web and the Context Root is used to re- fer to the application while specifying the address of the application. The Run Verifier option enable you to run a J2EE[tm] application verifier as part of the deployment process. The Precompile JPS option enables you to have the JSPs files compiled during the deployment process.
7. Click OK to deploy to the application. Once the deployment process completes, the following page is displayed:
10 Chapter 11. Deployment
8. Make the application server instance aware of the newly deployed application by applying the changes.
8a. Select the "server1" node.
8b. Click the Apply Changes button. Note that a server instance restart is not required in this case.
Run the Application
Now that the application is completely deployed. To run the deployed sample application, perform the following steps:
1. Open a new browser window
2. Type the following URL in the browser window: http://localhost:
Where
3. A page with some servlet and JSP examples should display. To this point, you have successfully deployed a sam- ple application.
CLI Based Deployment
In addition to deploying applications via the administrative console, you can also use the asadmin utility to deploy applications from the command line. Execute the following command for more information: asadmin deploy --help 11 Chapter 11. Deployment
What happens during deployment?
To support formal application deployments, the administrative server must be running. The administrative server re- ceives the deployed application, registers the application in the target server instance's server.xml file and installs the application in the target server instance's application deployment area.
12