5.2.3 WAS on AIX - disk layout

The WAS runtime installs on AIX under /usr/IBM/WebSphere/AppServer by default. This is where the base code resides.

To run enterprise applications, one or more profiles are created that, by default, are contained in this directory. Applications may include customizations for specific roles that point back to this higher level base code.

The profiles consist of a set of directories that contain scripts that execute the base level WAS runtime components in the higher level directories, and specific XML file customizations to better support the applications that are hosted on that profile. On a WAS Network Deployment environment, for example, a DMgr profile is used to support the deployment manager, and other profiles support WAS nodes and specific standalone WAS configurations.

Before moving on to how WAS works, it is useful to know how it is laid out on the file system. An examination of the home directory of the user who installs and maintains WAS will illustrate why it is best to be consistent regarding who performs this role.

The home directory of the installing user ID contains a hidden .WASRegistry file, which identifies the installation root for all WAS installations and related products.

The default installation directory for WAS on AIX of...

/usr/IBM/WebSphere/AppServer

...uses the directories listed below. For each separately configured profile, an instance of the top level environment exists under the profile name beneath the profiles directory.

The default installation file system layout is listed in Table 5-1. There are a number of components in Table 5-1 that may need further explanation, most notably the references to the Eclipse and OSGI runtime.

Developers and many administrators are familiar with the concept of the Eclipse IDE and its plug-ins that allow for expansion of the base runtime environment. More details are provided later in this chapter, but as of Version 6.1, WAS itself is essentially composed of server-side Eclipse plug-ins.

Table 5-1

Directory Description
bin WAS-specific binaries (that is, shared objects and so on) and management scripts. In the profile version of this directory, the parent scripts are called. (parent and profile)
cip Default CIP config for use with the Eclipse-based installation factory tool.
configuration The config.ini file used to control the Eclipse/OSGI base configuration and startup. This is a very important file because it controls what gets loaded as part of the OSGI initialization, so it can be used to start components on the JVM before WAS itself does. (parent and profile)
deploytool Eclipse-based tool for application deployment, as well as a complete Eclipse environment.
derby Lightweight Java-based Apache Derby database in embedded and network server versions.
etc Virtual Member Manager (VMM/WIM) environment for building a customer user and group management environment for use with federated user repositories; samples for the WS-Security Web services setup; and tmx4j open source JMX™ code that IBM uses for offering JMX management facilities. (parent and profile)
features Configuration for some of the Eclipse "features" used to group dependent Eclipse plug-ins. The subdirectories each contain a feature.xml file that lists plug-ins and versions that have prerequisites and dependencies that should be configured, managed and upgraded together. Features include the base product, the network deployment product, the UDDI server, the Web services gateway, and others. Note that the feature dependencies in most of the feature.xml files refer to version 6.0.0 products except for some of the IBM programming model extensions (PME) and new 6.1.0-specific features (labelled 7.0.0), showing that much of the core code is the same between the two 6.X versions, despite the architectural change.
firststeps Firststeps application HTML and script files used for easy initial configuration. This makes use of the core WAS runtime library for its work. (parent and profile)
installableApps EAR, WAR, etc files that form the applications that are available for deployment to the application servers configured as part of the cell managed by this installation. (parent and profile)
installedApps Deployed code from the installableApps that the profile nodes run. (parent and profile)
installedConnectors Resource adapter archive files used by the connectors installed for the application server that uses the J2EE Connector Architecture (JCA or J2C) to interface to external or earlier systems. (parent and profile)
installedFilters (at profile level) Filters that the profile nodes run.
java JVM used by this installation of WAS (in this case, the IBM J9 JVM).
lafiles License agreement files in multiple languages for the WAS environment.
lib Java library files (JAR files) that support some of the base WAS product set. They include libraries to support some DBMSs, utility libraries, libraries to support the service integration bus and mail server interaction, some of the associated WAS tools (the log analyzer) and base libraries to support WAS startup. Java libraries for WebSphere MQ are in a subdirectory. One file of particular interest is that used to identify the Eclipse platform in use (.eclipseproduct), which reveals that an Eclipse 3.1.2 product is in use:
name=Eclipse Platform
id=org.eclipse.platform
version=3.1.2
This file goes along with the startup.jar file that contains the org.eclipse.core.launcher code for running the base Eclipse environment that can host some of the Eclipse-based tools and the bootstrap.jar file that performs similar functions. This is the same code as can be found on the Eclipse Web site for developing an AIX Eclipse application. The startup.jar and bootstrap.jar files start the Eclipse runtime by obtaining configuration information from properties files, config files and the classpath, and then bootstrapping Eclipse/OSGI with the correct information.
logs Log files for the parent environment (usually, only the creation log files for the profiles created using the manageprofile.sh script). In the profiles themselves, the directory contains the start and stop logs, and the error logs (that is, stdout and so on).
optionalLibraries This contains directories for optional Java jar files that can be deployed to the environment to provide extra functionality, such as Jython, Struts, and the JSF-Portlet bridge. This contains Java code rather than shared objects or achieve library files.
plugins Like all Eclipse applications, this contains the Eclipse runtime environment plug-ins and much of the core WAS runtime environment itself that is now implemented as Eclipse plug-ins and OSGI bundles. Pay particular attention to:

org.eclipse.osgi_3.1.2.jar Core of the OSGI platform
com.ibm.cds_1.0.0.jar Class loader integration with the shared classes environment
com.ibm.ws.runtime_6.1.0.jar Base WAS runtime Java environment
org.eclipse.jdt.core_3.1.2.jar
com.ibm.jdt.core_6.1.0.jar
Java runtime integration between WAS, Eclipse and the JVM.

profiles Configuration and scripts specific to a configured runtime set of nodes and instances created by a particular profileTemplate. Common default profiles are the Dmgr01 profile created by the" dmgr" profileTemplate and the AppSrv01 profile created by the "managed" profileTemplate. Under these profile directories, pay particular attention to the logs directory containing log files for the instances, the config/cells directory containing the Web server plugin-cfg.xml file and the application server server.xml file for each instance, and the bin directory containing management scripts.
profileTemplates XML configuration files and ant scripts used by the manageprofiles.sh script for setting up the appropriate WAS environments for a particular role. Which directories of these files are available to allow which profile roles to be set up depends on the chosen WAS installation type purchased (that is, standalone, network deployment and so on).
properties Property files and XML configuration files for key tools and WAS components for the base environment. (parent and profile)
runtimes Java jar files for the client administration tools and the Web services thin client.
samples Runtime applications and Java source for sample applications provided with WAS. These are good resources for Java developers to learn how J2EE applications should be written. (parent and profile)
sar2war_tool XML and an XSL script to convert a WAS Session Initiation Protocol (SIP) servlet archive (sar) for use by the WAS SIP container into a standard J2EE Web archive (war) file. Note: This sar file standard is not the same as that in use by JBoss for service archives.
Scheduler DDL for the database implementations for various DBMSs that support the WAS Scheduler service that can invoke WAS-hosted Java code to a schedule.
systemApps Java EAR files for system-level applications such as the event service or the scheduler calendar application.
temp Dummy entry for the main installation-but for profile temp directories, it contains relevant property files and checkpoint serialized object files for the instance. (parent and profile)
tmsStorage (at profile level) Persisted copy of the runtime deployment tasks for the deployment manager.
tranlog (at profile level) Tranlog directory and a partnerlog directory that are together used for XA distributed transaction management. These should be stored on a shared storage device like a NAS (with NFSv4) for the highest availability so that other instances in the cluster can access them. This set of files contains details of in-doubt transactions.
UDDIReg IBM UDDI registry for Web services to support lookup of Web services within a private enterprise.
uninstall Java code and XML configuration files to support uninstalling WAS.
universalDriver Architecture-neutral DB2 driver to support JDBC access to DB2 on multiple platforms.
util jacl and shell scripts for installing and configuring WAS and its features.
web HTML documentation for WAS, including some of the Rational® Rose® models used to create WAS itself, the application client configuration tool, the JMX management interfaces, and the programming model for entity beans. If we want to know how WAS works, and make WAS perform better on your platform at the lowest level, examine the documentation contained here. The documentation for the docs directory and all classes directory in particular contains significant information.
wstemp (at profile level) HTML documentation for WAS, including some of the Rational Rose models used to create WAS itself, the application client configuration tool, the JMX management interfaces, and the programming model for entity beans. If we want to know how WAS works, and make WAS perform better on your platform at the lowest level, examine the documentation contained here. The documentation for the docs directory and all classes directory in particular contains significant information.

WAS on AIX default installation file system layout

Next