Overview of the Enterprise application installation process in a
Network Deployment (ND) environment
Following is the sequence of steps for installing an enterprise
application archive (EAR) file using the wsadmin tool or Web
console.
- Start the installation process using either the wsadmin tool or
Web console.
- After the installation process, you will receive the following
response:
ADMA5013I: Application
MyApplication installed successfully
- Saving your changes using $AdminConfig save or console
save.
This operation saves the configuration and Binaries only in the ND config
directory.
$WAS_ND_HOME\config\cells\cell_name\applications\
- In a Network Deployment environment, the save operation alone
does not update the following directories:
federated_Base_Node\config\cells\cell_name\application
federated_Base_Node\installedApps
- Only the synchronize process transfers these files to all selected
federated_Base_Nodes.
It is important to select the Synchronize changes with Nodes
operation during the console save operation.
The node listens to events generated by the sync operation for
notification that an EAR has arrived on that node from the
DeploymentManager (dmgr). The installation destination (installedApps by
default) is checked for the corresponding application and the EAR is
expanded there.
The install, uninstall, and update operations update only the master
repository on dmgr. It is the synchronization mechanism, initiated by one
of these three ways, that transfers the EAR to the node and expands it.
For non-federated Base nodes or for applications that run on the dmgr
(like the Administrative Console) the same listener runs. However, instead
of listening for sync events, it listens for repository events to receive
notification that an EAR has arrived in the master repository. The ear is
then expanded into the installedApps directory on the dmgr or
base.
When you install an EAR, it is added to the dmgr master repository.
When you initiate a sync operation between a dmgr and a specific node,
using the console Synchronize buttons, wsadmin MBean, or by invoking
syncNode.bat/sh on the node, the EAR from the master repository is pushed
down to the node repository using file transfer only if Distribute
Application is enabled during the installation process.
If Distribute Application is disabled, you must use the EARExpander
tool to distribute the binaries.
Refreshing the binaries in
ND_Install_Root\config\cells\my_cell
name\applications\MyApplication.ear\BINARY_FORMAT_of_MyApplication.ear
followed by a Full Resynchronize updates the installedApps only
with Distribution Enabled.
Rules for understanding enterprise application and system
management
- The enterprise application update is a combination of both the
uninstall and install processes (new version of the same EAR file). That
is, Uninstall and Install are achieved by using a single
Update option. During this update process, binaries are distributed
to the appropriate Federated Node just like a Regular Install
process.
Example:
$AdminApp install EAR_location/MyApp.ear
{-update -appname
MyApp}

- The Distribute Application option controls the automatic
distribution of application binaries to the node directories.
federated_node_install_root\installedApps\CellName
This option does not require a value. The default setting is
distributeApp. This can be changed to nodistributeApp.
Example:
$AdminApp install EAR_location/MyApp.ear
{-node MyNode -cell
MyCell -server
MyServer -appname
MyApplication -nodistributeApp}

- Deleting the contents from the Federated
Node_Install_RootinstalledApps\CellName directory does not
affect WebSphere SystemManagement operations, but the corresponding
enterprise application will not work.
- EARs are not compared during every sync due to performance
considerations. Only when an EAR changes in the master repository
(WebSphere_ND_Install_Root\config\cells\cellname\applications.ear\)
does the sync logic push it down to the node. If you refresh the
EAR in the repository, sync brings it down, and it is expanded to the
installedApps directory on the node.
The data is read from the repository
(WebSphere_ND_Install_Root\config\cells\cellname\applications.ear\)
and written to installedApps. (Federated
Node_Install_RootinstalledApps\CellName).
- WebSphere SystemManagement (console/wsadmin/MBean) cannot access or
read data from the installedApps directory.
Example:
Any changes made directly to the installedApps (Hot Deployment) is
not recognized by the WebSphere SystemManagement functions (like
Enterprise Application EXPORT).
WebSphere console, wsadmin, and other administrative tools never read
information from installedApps. The installedApps information is used ONLY
with WebSphere runtime operations.
- WebSphere System Management (console/wsadmin/MBean..) always uses the
master repository information to read or edit the corresponding
application.
$WAS_ND_HOME\config\cells\my_cell_name\applications.ear\
Use Metadata From Binaries
In the master repository
(WebSphere_ND_Install_Root\config\cells\cellname\applications.ear\)
the META-INF/WEB-INF can be loaded from two different locations.
This is controlled by useMetadataFromBinaries flag.
During installation
After Install
The useMetadataFromBinaries flag specifies whether the application
server uses the binding, extensions, and deployment descriptors located
with the application deployment document, the deployment.xml file
(default), or those located in the application ear file. The metadata
files include the deployment descriptors (web.xml, application.xml,
ejb-jar.xml, and the like), the bindings files (ibm-web-bnd.xmi,
ibm-app-bnd.xmi, and the like), and the extensions files (ibm-web-ext.xmi,
ibm-app-ext.xmi, and the like).
Changing useMetadataFromBinaries using wsadmin
wsadmin>set deployed [$AdminConfig getid
/Deployment:petstore/]
wsadmin>set config [$AdminConfig showAttribute $deployed
deployedObject]
wsadmin>$AdminConfig modify $config {{useMetadataFromBinaries true}}
wsadmin>$AdminConfig save
WebSphere System Management (console/wsadmin/MBean..) and
useMetadataFromBinaries
- If "useMetadataFromBinaries" is not enabled (DEFAULT) then
all the META-INF/WEB-INF information are served from
corresponding expanded application directories:
$WAS_ND_HOME\config\cells\my_cell_name\applications\myApplication.ear\deployments\myApplication\myJAR.jar\META-INF
$WAS_ND_HOME\config\cells\my_cell_name\applications\myApplication.ear\deployments\myApplication\myWar.war\WEB-INF
- If it is enabled then all the META-INF/WEB-INF
information are served from application's ear file (binary format
of that application.ear):
$WAS_ND_HOME\config\cells\my_cell_name\applications\myApplication.ear\BINARY_FORMAT_of_myApplication.ear
WebSphere RunTime and useMetadataFromBinaries
- If useMetadataFromBinaries is not enabled (default)
all the META-INF/WEB-INF information is served from corresponding
expanded application directories:
$WAS_ND_HOME\config\cells\my_cell_name\applications\myApplication.ear\deployments\myApplication\myJAR.jar\META-INF
$WAS_ND_HOME\config\cells\my_cell_name\applications\myApplication.ear\deployments\myApplication\myWar.war\WEB-INF
- If it is enabled, all the META-INF/WEB-INF
information are served from 'installedApps'
<Federated_BaseNode>\installedApps
Hot deployment
Hot deployment is a quick and easy way to make changes to an application
without having to restart the server.
Changes made using hot deployment have the potential risk of being
overwritten if someone updates the ear in the repository
(ND_Install_Root\config\cells\my cell
name\applications\MyApplication.ear) and invokes the
mechanism that pushes the newly changed ear file from the repository to
installedApps directory.
Changes applied using hot deployment are never managed and therefore
never appear in administrative clients; for example, Web console, wsadmin,
MBean, and so forth.
Hot deployment is not an alternative for the enterprise
application install and update process.
Hot redeployment is a supported way to change your enterprise
applications. However, for Network Deployment, it gets a lot tougher
because you must make these changes on each node. If the enterprise
application is running at that time, the application behavior might change
based on which node has had the change applied. |