WebSphere is not just an IBM application
server; it is actually an IBM brand name. Numerous extension and
companion products are coming out using the WebSphere
WebSphere Programming Model
This product extends the application programming model. A number of its features were discussed in Chapter 9, Advanced Persistence, etc.
This product enables the configuration and management of
This WebSphere extension product is effective for increasing web serving performance,
To facilitate our discussion, let's introduce a few new terms to create a working vocabulary.
The WebSphere Application Server product introduces these terms:
A single WebSphere application server, which is sometimes referred to as a "base server".
This is a special J2EE application that is pre-installed in your WebSphere environment. It provides a browser-based interface through which your app servers and applications are managed. Please note we will discuss the presence of the Admin Console in this chapter, but will
The WebSphere Network Deployment product introduces these additional terms:
An administrative process, executing on the same physical computer system as the node it supports. A single Node Agent supports all app servers running on the same node.
A logical group of nodes, configured together in the same network for administrative purposes.
A logical app server comprising multiple instances of the same app server, usually spanning multiple nodes, and acting as a single unit providing reliability and load balancing.
Network Deployment Manager
An app server running an instance of the Admin console that provides administrative control over all other app servers configured together into the same cell.
Let's look at a base server first. This is what you get when you install the WebSphere Application Server product. This configuration consists of a single app server installed on some physical computer system. This app server
Note in the
For ease in understanding, we have used the
With the WebSphere Application Server product package, you can define as many single servers as you need on the same physical machine. If you have more than one app server installed, each one is independent and administered separately. In other words, they are not
You might start to
The purpose of the WebSphere Network Deployment product package is twofold:
To enable administration of multiple WebSphere nodes, and the app servers they contain, through a single browser connection
To enable the configuration of servers into clusters for application scale and availability
When you install WebSphere Network Deployment, at first all you get is a single, specialized app server, called the Network Deployment Manager. At first it appears really no different from any other app server, except for its
We'll soon see, however, that it plays a unique role within a group of WebSphere nodes, which we call a cell .
Please note that the Deployment Manager hosts only administrative applications, such as the Admin Console – you cannot target this server for your own applications.
Another thing to note about the Deployment Manager is that it always exists in its own dedicated node. It is not possible to define other app servers in the Deployment Manager's node. It has its own node largely for isolation purposes because in the WebSphere implementation, server configurations are physically isolated on a per-node basis. We'll talk more about that in just a little bit.
In the following diagram, we see that the Deployment Manager node can be co-located on the same physical computer system as other app server nodes:
The fact that the Deployment Manager may exist on the same physical computer system as other app servers is evidence that nodes are only logical – in fact you can configure multiple app server nodes on the same physical computer system, too. You might wonder why on earth one would do that. One of the best reasons will not occur until we release the
Naturally, the Deployment Manager can exist on its own physical computer system:
This is our recommendation for increased availability – a point that should become clearer as we describe the organization of a cell.
A cell is a collection of nodes, organized into the same administrative domain.
It is important to recognize that a base server is transformed when its node is federated with the Deployment Manager's node. Upon taking this action, the Deployment Manager becomes responsible for providing administrative access to the servers on the newly federated node. The base servers on that node are no longer standalone: no longer separately administered. In fact, the Admin console on each base server is
It is because the Deployment Manager is responsible for providing administrative access to all nodes and servers within the cell, that we recommend running the Deployment Manager on its own physical computer system. In a production environment, app server nodes are typically far busier than the Deployment Manager node. This greater activity on an app server node increases the opportunity for failure. Therefore isolating the Deployment Manager to its own physical computer system naturally
OK, so let's consider what our cell would look like after federating our first base server node. The following diagram depicts this trivial cell:
The benefit of grouping servers into cells is that the entire cell can be administered from a single point. This can substantially decrease administrative complexity and facilitates the coordination of administrative actions across a set of app servers.
You can increase the
The presence of additional app server nodes makes it possible for us to build a
. The motivation for configuring a cluster is scale and availability. A cluster is a collection of homogenous servers, with each server having the same configuration and hosting the same applications. When servers are configured into a cluster, WebSphere automatically
The following diagram depicts a server cluster:
Now that we've built up a basic vocabulary, we're ready for the topography overview coming up later in this chapter, but let's first take that