陈小旺教太极拳基本功:Deploying your Applications on WebSphere Application Server 7.0 (Part 1) | Packt Publishing Technica

Deploying your Applications on WebSphere Application Server 7.0 (Part 1)
bySteve Robinson | August 2009 |Java
After installing an application server, we would want to deployapplications. Applications can be installed manually or in an automatedfashion using scripts. In this two-part article by Steven Charles Robinson,we will cover how to manually deploy a J2EE (Enterprise Edition)application. As we walk through this article, we will show you how todeploy two applications. One application does not require databaseconnectivity; the second is a database aware application which requiressome WebSphere configuration to provide database connectivity to theapplication.
In this article, we will cover the following topics:
Application server internals
The web container
Virtual hosts
WebSphere ports
Data sources
Java Naming and Directory Interface (JNDI)
Application deployment
J2EE applications
Enterprise Archive (EAR)
Web Archive (WAR)
Java Archive (JAR)
Inside the Application Server
Before we look at deploying an application, we will quickly run over the internals of WebSphere Application Server (WAS).The anatomy of WebSphere Application Server is quite detailed, so fornow, we will briefly explain the important parts of WebSphereApplication Server.
The figure below shows the basic architecture model for a WebSphere Application Server JVM.

An important thing to remember is that the WebSphere product codebase is the same for all operating-systems (platforms). The Javaapplications that are deployed are written once and can be deployed toall versions of a given WebSphere release without any code changes.
JVM
All WebSphere Application Servers are essentially Java VirtualMachines (JVMs). IBM has implemented the J2EE application server modelin a way which maximizes the J2EE specification and also provides manyenhancements creating specific features for WAS. J2EE applications aredeployed to an Application Server.
Web container
A common type of business application is a web application. The WASweb container is essentially a Java-based web server contained within anapplication server's JVM, which serves the web component of anapplication to the client browser.
Virtual hosts
A virtual host is a configuration element which is required for theweb container to receive HTTP requests. As in most web servertechnologies, a single machine may be required to host multipleapplications and appear to the outside world as multiple machines.Resources that are associated with a particular virtual host aredesigned to not share data with resources belonging to another virtualhost, even if the virtual hosts share the same physical machine. Eachvirtual host is given a logical name and assigned one or more DNSaliases by which it is known. A DNS alias is the TCP/ host name and portnumber that are used to request a web resource, for example: :9080/.
By default, two virtual host aliases are created during installation. One for the administration console called admin_host and another called default_hostwhich is assigned as the default virtual host alias for all applicationdeployments unless overridden during the deployment phase. All webapplications must be mapped to a virtual host, otherwise web browserclients cannot access the application that is being served by the webcontainer.
Environment settings
WebSphere uses Java environment variables to control settings andproperties relating to the server environment. WebSphere variables areused to configure product path names, such as the location of a databasedriver, for example, ORACLE_JDBC_DRIVER_PATH, and environmental values required by internal WebSphere services and/or applications.
Resources
Configuration data is stored in XML files in the underlyingconfiguration repository of the WebSphere Application Server. Resourcedefinitions are a fundamental part of J2EE administration. Applicationlogic can vary depending on the business requirement and there areseveral types of resource types that can be used by an application.Below is a list of some of the most commonly used resource types.
 
Resource Types
Description
JDBC (Java database connectivity)
Used to define providers and data sources
URL Providers
Used to define end-points for external services for example web services...
JMS Providers
Used to defined messaging configurations for Java Message Service, MQ connection factories and queue destinations etc.
Mail Providers
Enable applications to send and receive mail, typically use the SMTP protocol.
 
JNDI
The Java Naming and Directory Interface (JNDI) is employed tomake applications more portable. JNDI is essentially an API for adirectory service which allows Java applications to look up data andobjects via a name. JNDI is a lookup service where each resource can begiven a unique name. Naming operations, such as lookups and binds, areperformed on contexts. All naming operations begin with obtaining aninitial context. You can view the initial context as a starting point inthe namespace. Applications use JNDI lookups to find a resource using aknown naming convention. Administrators can override the resource theapplication is actually connecting to without requiring areconfiguration or code change in the application. This level ofabstraction using JNDI is fundamental and required for the proper use ofWebSphere by applications.
Application file types
There are three file types we work with in Java applications. Two canbe installed via the WebSphere deployment process. One is known as anEAR file, and the other is a WAR file. The third is a JAR file (oftenre-usable common code) which is contained in either the WAR or EARformat. The explanation of these file types is shown in the followingtable:
 
File Type
Description
JAR file
A JAR file (or Java ARchive) is used for organising many files into one. The actual internal physical layout is much like a ZIP file. A JAR is  generally used to distribute Java classes and associated metadata. In J2EE applications the JAR file often contains utility code, shared libraries and  EJBS. An EJB is a server-side model that encapsulates the business logic of an application and is one of several Java APIs in the Java Platform, Enterprise Edition with its own specification. You can visithttp://java.sun.com/products/ejb/ for information on EJBs.
EAR file
An Enterprise Archive file represents a J2EE application that can be deployed in a WebSphere application server. EAR files are standard Java archive files (JAR) and have the file extension .ear. An EAR file can consist of the following:
One or more Web modules packaged in WAR files.
One or more EJB modules packaged in JAR files
One or more application client modules
Additional JAR files required by the application
Any combination of the above
The modules that make up the EAR file are themselves packaged in archive files specific to their types. For example, a Web module contains Web archive files and an EJB module contains Java archive files. EAR files also contain a deployment descriptor (an XML file called application.xml) that describes the contents of the application and contains instructions for the entire application, such as security settings to be used in the run-time environment...
WAR file
A WAR file (Web Application) is essentially a JAR file used to encapsulate a collection of JavaServer Pages (JSP), servlets, Java classes, HTML and other related files which may include XML and other file types depending on the web technology used. For information on JSP and Servlets, you can visithttp://java.sun.com/products/jsp/.
Servlets can support dynamic Web page content; they provide dynamic server-side processing and can connect to databases.
Java ServerPages (JSP) files can be used to separate HTML code from the business logic in Web pages. Essentially they too can generate dynamic pages; however, they employ Java beans (classes) which contain specific detailed server-side logic.
A WAR file also has its own deployment descriptor called "web.xml" which is used to configure the WAR file and can contain instruction for resource mapping and security.
 
When an EJB moduleor web module is installed as a standalone application, it isautomatically wrapped in an Enterprise Archive (EAR) file by theWebSphere deployment process and is managed on disk by WebSphere as anEAR file structure. So, if a WAR file is deployed, WebSphere willconvert it into an EAR file.
Deploying an application
As WebSphere administrators, we are asked to deploy applications.These applications may be written in-house or delivered by a third-partyvendor. Either way, they will most often be provided as an EAR file fordeployment into WebSphere. For the purpose of understanding a manualdeployment, we are now going to install a default application. Thedefault application can be located in the /installableApps folder. The following steps will show how we deploy the EAR file.
Open the administration console and navigate to the Applications section and click on New Application as shown below:

You now see the option to create one of the following three types of applications:
 
Application Type
Description
Enterprise Application

EAR file on a server configured to hold installable Web Applications, (WAR), Java archives, library files, and other resource files.
Business Level Application

A business-level application is an administration model similar to a server or cluster. However, it lends itself to the configuration of applications as a single grouping of modules.
Asset

An asset represents one or more application binary files that are stored in an asset repository such as Java archives, library files, and other resource files. Assets can be shared between applications.
 
Click on New Enterprise Application.
As seen in the following screenshot, you will be presented with theoption to either browse locally on your machine for the file or remotelyon the Application Server's file system. Since the EAR file we wish toinstall is on the server, we will choose the Remote file system option.
It can sometimes be quicker to deploy large applications by first using Secure File Transfer Protocol (SFTP)to move the file to the application server's file system and then usingremote, as opposed to transferring via local browse, which will do anHTTP file transfer which takes more resources and can be slower.
The following screenshot depicts the path to the new application:

Click Browse.... You will see the name of the applicationserver node. If there is more than one profile, select the appropriateinstance. You will then be able to navigate through a web-based versionof the Linux file system as seen in the following screenshot:

Locate the DefaultApplication.ear file. It will be in a folder called installableApps located in the root WebSphere install folder, for example, /installableApps as shown in the previous screenshot.
Click Next to begin installing the EAR file.
On the Preparing for the application installation page, choose the Fast Path option. There are two options to choose.
 
Install option
Description
Fast Path
The deployment wizard will skip advanced settings and only prompt for the absolute minimum settings required for the deployment.
Detailed
The wizard will allow, at each stage of the installation, for the user to override any of the J2EE properties and configurations available to an EAR file.
 
The Choose to generate default bindings and mappings settingallows the user to accept the default settings for resource mappings oroverride with specific values. Resource mappings will exist depending onthe complexity of the EAR. Bindings are JNDI to resource mappings. EachEAR file has pre-configured XML descriptors which specify the JNDI namethat the application resource uses to map to a matching (applicationserver) provided resource. An example would be a JDBC data source namewhich is referred to as jdbc/mydatasource, whereas the actual data source created in the application server might be called jdbc/datasource1. By choosing the Detailed option, you get prompted by the wizard to decide on how you want to map the resource bindings. By choosing the Fast Path option, you are allowing the application to use its pre-configured default JNDI names.
We will select Fast Path as demonstrated in the following screenshot:

Click on Next.
In the next screen, we are given the ability to fill out somespecific deployment options. Below is a list of the options presented inthis page.
WebSphere Application Server 7.0 Administration Guide

Manage and administer your WebSphere application server to create a reliable, secure, and scalable environment for running your applications with this book and eBook
 
Option value
Description/Values
Precompile JavaServer Pages files
Specify whether to precompile JavaServer Pages (JSP) files as a part of installation. The default is not to precompile JSP files.
Directory to install application
Specifies the directory to which the enterprise application (EAR) file will be installed.
You can change this if you want the application to be physically located outside of the WebSphere file structure.
Distribute application
The default is to enable application distribution. You can override this and choose to not distribute the application across multiple nodes.
Default = true
Use Binary Configuration
Specifies whether the application server uses the binding, extensions, and deployment descriptors located within the application deployment document, the deployment.xml file (default), or those located in the enterprise application resource (EAR) file.
Default = false
Deploy enterprise beans
The tool generates the code needed to run enterprise bean (EJB) files. You must enable this setting when the EAR file is assembled and the EJBDeploy is not run during packaging.
Default = false
Application name
Logical name for the application. The default name is the same as the Ear file. An application name must be unique within a cell.
Create MBeans for resources
Specifies whether to create MBeans  for resources such as servlets or JSP files within an application when the application starts.
The default is to create MBeans
Override class reloading settings for Web and EJB modules
Specifies whether the WebSphere Application Server run time detects changes to application classes when the application is running.
If this setting is enabled and if application classes are changed, then the application is stopped and restarted to reload updated classes.
The default is not to enable class reloading.
 
 
Reload interval in seconds
Specifies the number of seconds to scan the application's file system for updated files.
Process embedded configuration
Specifies whether the embedded configuration should be processed. An embedded configuration consists of files such as resource.xml and variables.xml. When selected or true, the embedded configuration is loaded to the application scope from the .ear file.
File Permission
Allows all files to be read but not written to.
Allows executables to execute.
Allows HTML and image files to be read by everyone..
Application Build ID
A string that identifies the build version of the application. Once set, it cannot be edited.
Allow dispatching includes to remote resources
Web modules included in this application are enabled as remote request dispatcher clients that can dispatch remote includes.
Default = true
Allow servicing includes from remote resources
Web modules included in this application are enabled as remote request dispatcher servers that are resolved to service remote includes from another application. Default = true
Business level application name
Specifies whether the product creates a new business-level application with the enterprise application that you are installing or makes the enterprise application a composition unit of an existing business-level application.
Asynchronous Request Dispatch Type
Specifies whether Web modules can dispatch requests concurrently on separate threads.
Allow EJB reference targets to resolve automatically
Specifies whether the product assigns default JNDI values for or automatically resolves incomplete EJB reference targets.
 
For this deployment, we will leave the majority of these values asdefault. Except we will override the EAR application name to be:
DefaultApplication
as opposed to
DefaultApplication.ear
Click on Next to move on to the Map modules to server page.
Map the application to the appropriate server. At this stage, we onlyhave one application server profile; however, we can administer severalapplication servers and manage multiple server nodes. For thisapplication, we will see two resources contained in the application. AnEJB and a WAR file. We want to ensure that both of these are mapped tothe same server server1. Select both checkboxes and click Apply to ensure the application modules are bound to server1, as shown in the following screenshot:

Accept defaults and click Next.
You will now be presented with a summary of the options chosen during the configuration of the deployment. Click Finish and the wizard will expand the uploaded EAR file into a temporary folder and override any files as required.
Up until now, all the work that has been done by the wizard has been in a temporary folder called wstemp, found at the root of the application server's profile. Here is an example of what that might look like:
wstemp/anonymous1231468782776/workspace/cells/
websphereNode01Cell/applications/DefaultApplication.ear
Once the EAR file has been deployed, a report will be given where youwill be asked to save. This will store the EAR file to the installedApps folder, which is in the following location:
//appsrv01/installedApps/websphereNode01Cell
The EAR file in the installedApps folder is expanded and isthe runtime version of the application, meaning this is what WebSphereconsiders to be the actual application.
There is another important area known as the application registry andan EAR file will also exist there too, containing the actual EAR filewhich was uploaded. The applications registry is located at:
/config/cells/websphereNode01Cell/applications
Click Save to continue. The application has now been deployed.
Navigate to the Applications section of the administration console and click WebSphere enterprise applications and you will get a list of installed applications.
Starting and stopping your applications
In the WebSphere enterprise applications screen, we will see alist of applications which have been installed and their current state.Below is a table explaining the actions which can be performed againstone or more selected applications.
 
Option
Description
Start
When an application is stopped you will see aicon
To start, select one or more application and click the Start button
Stop
When an application is started you will see aicon
To stop, select one or more applications and click the Stop button
Install
As part of deploying an application, you install application files on a server. Depending on EAR /WAR complexity, the deployment wizard will dynamically produce a guide of steps which require user input.
Uninstall
Select applications you wish to uninstall. It is recommended you stop applications first.
Update
To apply delta updates. Only the application code elements that have been changed in the application since last deployment are updated while the application remains running.
Rollout Update
If the application is deployed on one or more clusters spread across multiple nodes using this method reduces the amount of time that any single cluster member is unavailable for service.
Remove File
Deletes a file of the deployed application or module. Remove File deletes a file from the configuration repository and from the file system of all nodes where the file is installed.
Export
Allows the application to be exported as an Ear file. Can be used to backup an application version.
Export DDL
Exporting DDL (Table.ddl) files in the EJB modules of an application downloads the DDL files to a location of your choice, if there are not DDL files a message will be displayed.
Export File
Allows the exporting of  a specific file from an enterprise application or module.
 
We are going to start the default application. Select DefaultApplication and click on the Start action, as shown in the following screenshot:

When an application has successfully started, you will a message similar to the one shown below:

Now, DefaultApplication is started, we can use a web browser to navigate to the URL http://:9080/snoop.
The following screen will load.

The default application contains a very useful administration servlet.
The snoop servlet is an excellent tool to use in testing. Snoop reports on the following attributes:
Servlet context initialization parameters
URL invocation request parameters
Preferred client locale
Context path
User principal
Request headers and their values
Request parameter names and their values
HTTPS protocol information
Servlet request attributes and their values
HTTP session information
Session attributes and their values
>>Continue Reading Deploying your Applications on WebSphere Application Server 7.0 (Part 2)
WebSphere Application Server 7.0 Administration Guide

Manage and administer your WebSphere application server to create a reliable, secure, and scalable environment for running your applications with this book and eBook
About the Author :
Steve Robinson
Steve Robinson is an independent WebSphere specialist andconsultant. He has been consulting in IT since 1997 and has beeninvolved in client projects around the globe; many of which are forfortune 500 companies.
Steve started out originally as a consultant in the IBM LotusNotes/Domino product suite, where he excelled in middleware integrationtechnologies to ensure homogenous environments could exist in the newheterogeneous world. Having worked for many different industries, Stevehas had a plethora of experience in the integration of most technologiesacross many different systems and cultures. He is also an accomplishedprogrammer in including C, Java, and the Microsoft .NET developmenttools.
Steve has gleaned many insights due to the amount of large enterpriseprojects he has been involved with and his passion for documentationand process improvement is recognized by all those he works with.
Steve is married and lives with his family in England. He spends histime either writing, or researching new products and technologies forclient projects along with investigating new ways to automate processwhere possible.
Steve is also known for his contribution to the WebSphere Internetcommunity through one of his many top-ranking WebSphere knowledgeportals:http://www.webspheretools.com.