Enterprise application administration on V5 releases
 White paper
 
Abstract
Enterprise application and WebSphere® Application Server system management for all releases of WebSphere Application Server V5.
 
 
Content

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.
  1. Start the installation process using either the wsadmin tool or Web console.

  2. After the installation process, you will receive the following response:

    ADMA5013I: Application MyApplication installed successfully

  3. 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\

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

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

  1. 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}

  2. 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}

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

  4. 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).

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

  6. 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.
 
Related information
Hot deployment and dynamic reloading
Changing or adding WAR files
Changing or adding EJB JAR files
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > System Management/Repository
Operating system(s): Windows
Software version: 5.1.1
Software edition:
Reference #: 7004969
IBM Group: Software Group
Modified date: Apr 8, 2004