Application servers concepts
WebSphere Application Server is organized based on the concept of cells, nodes, and servers. Although all of these elements are present in each configuration, cells and nodes do not play an important role until you take advantage of the features that are provided with Network Deployment. These cells, nodes, and servers can be managed by a combination of deployment managers, administrative agents, and job managers.
The application server is the primary runtime component in all configurations and is where an application actually executes. All WebSphere Application Server configurations can have one or more application servers. In the Express and Base configurations, each application server functions as a separate entity. There is no central administration among application servers.
The base edition of WebSphere Application Server supports simple failover of up to five application server instances. With Network Deployment, you can build a distributed server environment consisting of multiple application servers maintained from a central administration point. In a distributed server environment, you can cluster application servers for workload distribution and failover.
Nodes, node groups, and node agents
A node is an administrative grouping of application servers for configuration and operational management within one operating system instance (virtualization allows multiple operating systems on one machine). It is possible to create multiple nodes inside one operating system instance, but a node cannot leave the operating system boundaries. In a stand-alone application server configuration, there is only one node. With Network Deployment, you can configure a distributed server environment that consists of multiple nodes that are managed from one central administration server.
In distributed server configurations, each node has a node agent that works with the deployment manager to manage administration processes, as shown in figure above. A node agent is created automatically when you add (federate) a stand-alone node to a cell. It is not included in Base and Express configurations.
A node group is a grouping of nodes within a cell that have similar capabilities. A node group validates that the node can perform certain functions before allowing them. For example, a cluster cannot contain both z/OS nodes and nodes that are not z/OS-based. In this case, you can define multiple node groups: one group for the z/OS nodes and one group for nodes other than z/OS
A DefaultNodeGroup is created automatically. This node group contains the deployment manager and any new nodes with the same platform type. A node can be a member of more than one node group.
A cell is a grouping of nodes into a single administrative domain. In the Base and Express configurations, a cell contains one node. That node contains one server.
In a Network Deployment environment, a cell can consist of multiple nodes (and node groups), which are all administered from a single point, the deployment manager. If your cell configuration contains nodes running on the same platform, it is called a homogeneous cell. It is also possible to have a cell made up of nodes on mixed platforms. This is referred to as a heterogeneous cell.
The deployment manager is the central administration point of a cell, which consists of multiple nodes and node groups in a distributed server configuration. The deployment manager uses the node agent to manage the application servers within one node.
A deployment manager provides management capability for multiple federated nodes and can manage nodes that span multiple systems and platforms. A node can only be managed by a single deployment manager, and must be federated to the cell of that deployment manager.
The configuration and application files for all nodes in the cell are centralized into a master configuration repository. This centralized repository is managed by the deployment manager and synchronized with local copies that are held on each of the nodes. The entire centralized repository is not synchronized to each node. Only the node's subset of the repository is replicated.
The deployment manager can also send asynchronous jobs to unfederated nodes using the Job Manager in the administrative console.
An administrative agent is a component that provides enhanced management capabilities for stand-alone (Express and Base) application servers. This concept was first introduced with WebSphere Application Server V7.0 to separate the administrative components from the application server run time.
All configurations that are related to the application server are directly connected to the administrative agent that provides services to administrative tools. An administrative agent can manage multiple stand-alone server instances on a single system or z/OS image. Therefore, when using an administrative agent, as the number of application server instances increases, the redundancy of the administration footprint (for each application server) is eliminated.
A job manager is a component that provides management capabilities for multiple stand-alone application servers, administrative agents, and deployment managers, as illustrated in figure below. It brings enhanced multiple node installation options for your environment.
There are many benefits of the job manager to execute daily tasks in one step for multiple installations. This includes starting and stopping servers, distributing and deploying applications, and various other actions. These jobs can be submitted and executed asynchronously.
A new capability in the job manager in WebSphere Application Server V8 is the ability to submit Centralized Installation Manager (CIM) jobs using the job managers to multiple cells and server topologies.
The job manager was first introduced with WebSphere Application Server V7.0 and is available only with WebSphere Application Server Network Deployment and WebSphere Application Server for z/OS.
WebSphere Application Server provides the infrastructure and capabilities that are required to host applications and proxy servers that distribute work to the application servers. It also provides the ability to define external servers to the administration process and to associate web servers for routing purposes.
Application servers provide the runtime environment for application code. They provide containers and services that specialize in enabling the execution of specific Java application components. Each application server runs in its own Java Virtual Machine (JVM).
WebSphere Application Server V8 has an enhanced JVM designed to improve stability and performance. It provides a Java language compiler and execution environment to support the Java Platform, Standard Edition (Java SE) 6 specification. This JVM is supported on all platforms that ship with an IBM JDK.
Application server clusters
An application server cluster is a logical collection of application server processes that provides workload balancing and high availability. It is a grouping of application servers that run an identical set of applications that are managed so that they behave as a single application server (parallel processing). WebSphere Application Server Network Deployment or WebSphere Application Server for z/OS is required for clustering.
Application servers that are a part of a cluster are called cluster members. When you install, update, or delete an application, the updates are automatically distributed to all members in the cluster. A rollout update option enables you to update and restart the application servers on each node, one node at a time, providing continuous availability of the application to the user.
A proxy server is a specific type of application server that routes requests to content servers that perform the work. The proxy server is the initial point of entry, after the protocol firewall, for requests entering the environment.
Although web servers are independent products, they can be defined to and managed by the WebSphere Application Server administration process. The primary purpose for this is to enable the administrator to associate applications with one or more defined web servers to generate the proper routing information for web server plug-ins if multiple servers are used.
Web servers are associated with two types of nodes:
Managed nodes have a node agent on the web server system that allows the deployment manager to administer the web server. You can start or stop the web server from the deployment manager, generate the web server plug-in for the node, and automatically push it to the web server. In most installations, you have managed web server nodes behind the firewall with the WebSphere Application Server installations. See the figure below:
Unmanaged nodes, see the figure below, are not managed by WebSphere. You usually find these outside the firewall or in the demilitarized zone. You must manually transfer the web server plug-in configuration file to the web server on an unmanaged node. In a z/OS environment, you must use unmanaged nodes if the web server is a not running on the z/OS platform.
Web server plug-ins
A web server can be used to serve static contents and requests, such as HTML pages. When a request requires dynamic content, such as JSP or servlet processing, it must be forwarded to the WebSphere Application Server for handling.
To forward a request, a web server plug-in is generated by the WebSphere Application Server packages and then propagated to a web server. You propagate (manually or automatically with the deployment manager) an Extensible Markup Language (XML) configuration file (configured on the WebSphere Application Server) to the web server plug-in directory. The plug-in uses the configuration file to determine whether a request is handled by the web server or an application server. When WebSphere Application Server receives a request for an application server, it forwards the request to the appropriate web container in the application server. The plug-in can use HTTP or HTTPS to transmit the request. The plug-in is also used for routing requests to one of multiple application servers, see the figure below:
A generic server is a server that is managed in the WebSphere Application Server administrative domain even though the server is not supplied by WebSphere Application Server. The WebSphere Application Server generic servers function enables you to define a generic server as an application server instance within the WebSphere Application Server administration and associate it with a WebSphere Application Server or process.