Runtime binaries

The core product files are the actual product binary files, and can be shared by many profiles. The directory structure for the product has two major divisions of files in the installation root directory for the product. One division is the runtime binaries and the other is for profiles. We will discuss this in detail in

Profiles

A profile is an 'instance' of a WebSphere Application Server configuration. A profile contains its own set of administration scripts, its own environment, its own repository, and its own node agent. Many profiles can be created from a single install. Profiles can be installed to share runtime binaries allowing multiple profiles to benefit from a single maintenance update. It is also possible to allow each profile to have its own copy of the runtime binaries allowing profiles to update independently.

An example of using multiple profiles might be that a developer needs to create separate profiles of the product in order to segregate development and testing, each profile being based on a different fix-pack level, and/or containing specific configuration settings. In the following chapters, we will explain profiles in more detail.

Cells

A unit of management is a Cell. The entire administrative configuration data is stored in XML files containing the master configuration of the Cell. It is also a grouping of nodes into a single administrative domain. For WebSphere Application Server, it means you group (federate) several servers within a Cell, then you can administer them with a single administrative console. Federating multiple application servers into a single administrative console is covered in

The following diagram outlines the components of a Cell:

Nodes

A node is the term which can be given to the physical OS instance on which the WebSphere process will run. Another important term related to nodes is the Node Agent. Node Agents are responsible for spawning or killing server processes and also configuration synchronization between the Deployment Manager and the Node in the WebSphere Network Deployment product.

When using WebSphere Application Server, there is no node agent process available for a standalone application server node, unless you decide to federate the application server node with a Deployment Manager for a given Cell of an existing WebSphere Network Deployment installation. In short, a standalone installation of a WebSphere is in fact a single Cell, Node, Node Agent, and Server all in one.

It can be quite confusing at times, because WAS is designed for scalability and extension, so depending on the version of WAS purchased, you can extend its architecture and infrastructure footprint. Some of these terms come into their own once you upgrade to WebSphere Network Deployment and other extended variants of WAS.

Since version 7, the administrative agent has become available. This provides a single interface to administer multiple standalone application servers. Multiple servers may exist for development, test, staging, pre-production, and so forth, thus having a single administration console to manage many servers provides administrators with new capability.

Servers

Each standalone Application Server node needs to run a JVM in which a deployed JEE application will run. With WAS base, each profile will have a single JVM. In WAS ND, we can have multiple JVMs per node, which is part of the highly-available design architecture of WAS ND. You could say an installation of a standalone WebSphere application server is a cell, a node, and a server with a single JVM all in one along with an administration console.