How Do You Control WebSphere Application Server?

All application servers have an Admin Service. The Admin Service does just what the name implies. In most application servers, the admin service does a really good job of system administration for one application server. When you try to run five or ten application servers in parallel, things get flakey. WebSphere Application Server is really a network of servers connected by a network of management. This is what IBM means by "network deployment" or the initials ND. At any moment, some servers will be running, some servers will be stopped, and some servers will be in some in between state. Large, distributed networks are like that. If the network is large enough -- we are talking tens of thousands of computers spread across several continents -- just knowing what is running on any given part of your network becomes a chore. The admin service for WebSphere Application Server is meant to control everything in an extended network of thousands of servers. It is possible to control a network that large from one laptop computer located anywhere in the world. Everything means

• configuration -- the way the internal parts of WebSphere Application Server come to life when we start them
• control -- the way those internal parts behave after we start them
• monitoring -- reports and alerts we get

In order to understand how IBM administers the large network of servers that compose WebSphere Application Server, you have to understand some terms

• profile
• cell
• node
• server

IBM goes to great lengths to separate the actual code that executes from the settings that configure and control how that code behaves. Anything information that influences the way WebSphere Application Server behaves is isolated in something that IBM calls a profile. There is one profile for every node in the network of servers that we call WebSphere Application Server. Every time you create a profile, you have created a node. That node and the servers it contains might stand alone or it might be part of a collection of nodes that IBM calls a cell.
A node contains a collection of application servers and web servers that all happen to live on the same physical computer. One physical computer can contain many nodes as long as it has enough memory and enough CPU to power all the servers in all the nodes it contains. Every server in a node is guaranteed to live on the same physical computer.
An application server in the network of servers and services that we call WebSphere Application Server is Java Enterprise Edition platform code running on a Java Virtual Machine. That code produces dynamic content. This article describes how WebSphere Application Server produces dynamic content. Each application server has its own separate Java Virtual Machine. Sometimes, application servers are just called servers. Notice that any one application server is just a very small part of the product we call WebSphere Application Server. In the competing products, that application server is the entire product. Notice the difference in scale
A web server is a computer program that serves up static content. Sometimes, web servers are just called servers.
A cell is a collection on nodes. All the nodes could be on the same physical computer, but more likely, they will be on a network of physical computers
Configuration determines how all the application servers, web servers, message queues, and various internal services of WebSphere Application Server come to life. The configuration information that system administrators are allowed to modify is stored in a collection of XML files and properties files in the config directory of a profile.
XML files and properties files in the config directory of a profile define how the various servers and services in a node come to life. But those configuration files only get read once. They get read when a server or service is initializing. The moment initialization is complete, the XML files and the properties files are ignored. The only way to get a server to pay attention to changes you make in an XML file or a properties file is to stop the server and then start it again.
A network of JMX beans called MBeans control the way the network servers and services behave once they are running. Those same JMX beans also monitor the behavior of the servers and services while they execute.
Two kinds of specialized application servers enable us to configure, control, and monitor the behavior of the distributed network of servers and services that IBM calls WebSphere Application Server

• deployment manager
• node agent

A deployment manager is an application server that runs exactly one application -- an application that manages the configuration and behavior of an entire cell. There is only one deployment manager in any cell. The deployment manager holds the official configuration records for every server and service in the entire distributed network that is part of a cell. When a deployment manager orders a node agent to change the configuration of its servers and services to match this master record, we say the deployment manager has performed a synchronization. Deployment managers only talk to node agents
A node agent controls, configures and monitors all the servers and services in a node. Node agents talk to a deployment manager and node agents talk to the servers in their node. They relay administrative traffic from the deployment manager to the individual servers in their node. They relay status from the servers in their node to the deployment manager.
MBeans do several things

• They simple pieces of Java code that can represent an application, a service, a server, or almost anything else in your enterprise.
• They can report the status of anything in the enterprise
• They can generate alerts concerning anything in the enterprise
• They can be created automatically by WebSphere Application Server on behalf of anything installed in a cell

This thing we call WebSphere's admin service is really a network consisting of the various MBeans, the node agents, and the deployment manager. There are three fairly thin facades to the admin service

• a web browser based graphic user interface called the admin console
• a command line shell called wsadmin. This shell has a very powerful scripting language
• any JMX clients that you might choose to write

If you have never used WebSphere Application Server before, the web browser based admin console is a very good way to learn basic setup and administration. There are limits to what you can do from the admin console. Depending on what you want to do, navigation can either be very easy or very hard. The admin console page that allows you to change JVM heap size is burried deep in the navigation tree of each server. If you want to change heap size for ten servers, you must navigate that tree for each of your ten servers. That can be a lot of tedious mouse clicks.
Once you know what you are doing, wsadmin becomes more attractive than the admin console for many administrative tasks. For one thing, the script language of wsadmin allows you to automate tasks. Once your network reaches a certain size, the admin console becomes a source of errors because of the large number of mouse clicks you must make and the amount of text entry you must provide. Again, the script language provides ways to automate tasks
The most powerful way to control the network of servers and services we call WebSphere Application Server is to write a JMX client. JMX clients have complete unfettered access to the entire admin service and everything that happens across the entire network.

http://www.edu4eng.com/articles/WAS/overview/control.html