Chapter 1. Architecture

1.1.  Identify the components and services in a WebSphere Application Server and describe how they are related or interact.

[Note]

System management in a stand-alone server environment

A stand-alone application server provides the necessary capabilities to run J2EE-compliant applications. A stand-alone application server is a good starting point for development and test teams. It can also be used for proof-of-concept or lightweight applications that do not require intensive system resources.

To create a stand-alone application server, you must create a WebSphere Application Serve profile on a single (physical) machine with one application server only. The profile defines the application server, node, and cell.

You can manage the application server using the administrative console, wsadmin, and command-line utilities. All of the configuration data for the application server, including the installed applications, is stored in a configuration repository created when the profile is created.

Figure below shows the system management components of a stand-alone application server environment:

Figure 1.1. Stand-alone application server system management environment

Stand-alone application server system management environment


System management in a distributed server environment

A single stand-alone server does not provide load balancing, scaling, or high-availability capability; however, a distributed server environment can help you meet these challenges by creating clusters of application servers. Clustered servers provide work load balancing, session data replication, and failover.

At a high level, building a distributed server environment involves these steps:

  1. You start by creating a deployment manager profile. The deployment manager is responsible for administering the entire cell. A deployment manager administers one cell only.

  2. After the deployment manager is created, the next step is to create a custom profile, which creates a second cell (defaultCell), a node, and a node agent. At this point, you do not have a functioning application server environment, just the beginnings of one. Figure below shows this temporary stage of the environment.

    Figure 1.2. A deployment manager and unfederated custom profile

    A deployment manager and unfederated custom profile


  3. The next step is to federate the node (NodeA in figure above) to the deployment manager's cell by using the addNode.sh command. After being federated, NodeA is no longer part of the defaultCell, but rather is part of the deployment manager's cell (dmgrCell).

  4. After the federation is complete, all administration of NodeA is delegated to the deployment manager, and new application servers can be created on the node using the administrative tools for the deployment manager. This environment is illustrated in figure below. Additional nodes can be added and servers created to create a distributed server environment.

    Figure 1.3. The distributed server environment

    The distributed server environment


Centralized changes to configuration and application data

The deployment manager maintains a master repository of all the configuration files for nodes and servers in the cell. When configuration changes are made with the deployment manager, the changes are first stored in the master repository. After that, automatic or manual synchronization pushes the changes down to the affected nodes.

The configuration and application data repository is a collection of files that contain all of the information that is necessary to configure and execute servers and their applications. Configuration files are stored in XML format, while application data is stored as EAR files and deployment descriptors.

Configuration repository directory structure

Each node containing a deployment manager, application server, administrative agent, or job manager has its own profile directory under the install_root/profiles directory.

The repository files are arranged in a set of cascading directories within each profile directory structure, with each directory containing a number of files relating to different components of the cell, as shown in figure below:

Figure 1.4. Repository directory structure

Repository directory structure


The overall structure of the master repository is the same for both a stand-alone server environment and a distributed server environment. But there are some critical differences, including:

  • Stand-alone server environment:

    • The master repository is held on a single machine. There is no copy of it on any other node.

    • The repository contains a single cell and node.

    • Because each application server is stand-alone, there is no nodeagent/ directory.

    • Clusters are not supported. Therefore, the repository tree does not contain the clusters/ directory or subdirectories.

  • Distributed server environment:

    • The master repository is held on the node containing the deployment manager.

    • Each node also has a local copy of the relevant configuration and application data files from the master repository.

    • When changes are made to the configuration in the master repository, those changes must be synchronized to the configuration files on the nodes. Permanent changes to the configuration requires changes to the file or files in the master repository.

    • Changes can be made to the configuration files on a node, but the changes are temporary and are overwritten by the next file synchronization from the deployment manager. Configuration changes made to node repositories are not propagated up to the cell.

Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide