WebSphere Middleware Management Architecture

The WebSphere Middleware Management is essentially composed of these major elements:

• JMX Server – hosts the JMX Model MBeans that represent managed resources in the WebSphere network

• Admin Service – provides for external and remote representation of the JMX Server

• Admin Client – the client library for communicating to an admin service

• MBeans and Information Model – defines the type space for the MBeans introduced by WebSphere

• Configuration Repository – holds the configuration of the managed resources in the WebSphere network

• Administration Application and Workspace – implements the user interface to the middleware management system

• Node Agent – provides localized management control of the application server on a given node; also provides the end-point listener for remote management control from the deployment manager

• Deployment Manager – also referred to as the cell manager; provides centralized control over the resources defined in the topology of the deployment cell

• PME Administration Extensions – extensions to the middleware management system in support of the administrable properties of the programming model extensions (of Enterprise edition)

The picture overleaf depicts these components and their relationships within the WebSphere network. We'll discuss each of these in more detail. In addition, we will discuss the architecture for securing and extending the middleware management system:

The aggregation of the deployment manager and all of the nodes and application servers collected in a single topology and recorded in the central configuration repository is referred to as a cell. Application servers only ever belong to a single node, and nodes only ever belong to a single cell. However, different nodes and, by extension, different application servers, even in different cells, can be hosted on the same computer.

JMX Server

The WebSphere middleware management system is fundamentally based on the JMX (Java Management Extension) standard. Thus, the managed resources of the WebSphere execution environment are represented as JMX Model MBeans. MBeans essentially are proxies to the actual managed resource they represent. For example, there is an MBean instance for each application server instance in the system. The JMX specification is described in its entirety at: http://java.sun.com/products/JavaManagement/.

WebSphere makes a strong distinction between operations management and configuration management. Operations management is performed through JMX MBeans. Configuration management is performed through a set of XML documents maintained persistently in the configuration repository (although the configuration repository is itself represented with a Configuration Service MBean). Operations performed on a resource through its MBean proxy may change the operational state of the resource, but will not permanently change its configuration. The next time that resource is initialized with its configuration, it will revert back to the state implied by that configuration. Likewise, a change to a resource's configuration will not be reflected in its MBean state until that resource is actually re-initialized with its configuration (which may be sooner or later depending on the nature of the resource, its ability to accept re-initialization on the fly, and any policies that govern dynamic configuration changes).

Everything in the application server and in the WebSphere network managed by the WebSphere middleware management facility is modeled as an MBean. The full information model is described in detail later. This includes the application server itself, the web and EJB containers' thread pools, and so on. We refer to anything that is represented by an MBean as a managed resource – implying that it is a resource that can be managed through the middleware management facility.

Every application server instance comes with an embedded JMX server. The JMX server is where MBeans reside and are managed. You can abstractly think of the JMX server as a container and MBeans as a special component type. The MBeans hosted in the JMX server of a given application server are there to represent the managed resources in that application server – including the application server itself.

In addition, a JMX server resides in the node agent and deployment manager as well. We'll discuss these components in the overall architecture later, but suffice it to say for now that they provide broader levels of management support across a distributed system and facilitate communication of operational commands from the central deployment manager to the application servers deployed in the network.

Admin Service

The standard JMX specification presumes that all MBeans operations will be invoked locally – from within the same JVM as that in which the MBeans are hosted. However, WebSphere is a distributed environment, and even if it weren't you would most likely want to control the application server from some other process – either on the same computer, or more likely from some central location within your network. WebSphere enables remote communication to the JMX server with a pair of JMX connectors – one based on IIOP, and another based on SOAP/HTTP. In the former case, the JMX server is treated as an RMI/IIOP object. In the latter case, the JMX server is treated as a Web Service.

No portion of the middleware management is gained or lost with one connector or the other – they are equally capable of providing communication to the JMX server and the MBeans they host. The difference between the connectors is entirely based on quality of service – exactly the same tradeoffs that exist between IIOP-based versus SOAP/HTTP-based Web Service communication.

The admin service is essentially a wrapper to enable remote communication to the JMX server. The admin service provides the end-point listener for both the SOAP and IIOP-based JMX connectors. In addition, the admin service provides support for a JMX router. This router knows how to take a JMX operations request and forward it to whatever JMX server is hosting the actual JMX MBean referenced in the operation request. Admin clients can issue operation requests on the admin service in the deployment manager, and if the specified MBean does not reside in the deployment manager, the router function will forward the request to the admin service in the node agent, which in turn will forward it the application server, and so forth until the MBean referred to in the operation request is located. The operation request is then dispatched on the MBean in the JMX server where it is hosted.

Admin Client

The admin client provides remote communication to the admin service. It is used in the admin console, commands, and scripting client. If you write any JMX-based admin applications you will use the admin client.

A major difference between WebSphere and other application servers is that IBM has attempted to overcome the limitation of JMX that requires that you be in the same process as the JMX server that you want to operate on by introducing a proxy to the JMX server. WebSphere introduces the notion of an AdminClient that hides the fact that you may or may not be in the same process as the JMX server that you want to operate on. The AdminClient supports the normal JMX interface, but then takes responsibility for routing JMX requests to the right JMX server where your MBean resides.

When programming management applications in WebSphere, you will mostly be programming to this AdminClient interface. The AdminClient has the following interface definition:

public interface AdminClient {   public static final String CONNECTOR_TYPE = "type";   public static final String CONNECTOR_HOST = "host";   public static final String CONNECTOR_PORT = "port";   public static final String CONNECTOR_TYPE_SOAP = "SOAP";   public static final String CONNECTOR_TYPE_RMI = "RMI";   public static final String CONNECTOR_TYPE_JMS = "JMS";   public static final String PROTOCOL_ADAPTOR_TYPE_SNMP = "SNMP";   public static final String[] CONNECTOR_TYPES =      { CONNECTOR_TYPE_SOAP, CONNECTOR_TYPE_RMI, PROTOCOL_ADAPTOR_TYPE_SNMP };   public static final String CONNECTOR_SOAP_CONFIG = "com.ibm.SOAP.ConfigURL";   public static final String CONNECTOR_SOAP_REQUEST_TIMEOUT =      "com.ibm.SOAP.requestTimeout";   public static final String CONNECTOR_SECURITY_ENABLED = "securityEnabled";   public static final String USERNAME = "username";   public static final String PASSWORD = "password";   public void addNotificationListener(ObjectName name,      NotificationListener listener, NotificationFilter filter,      Object handback) throws InstanceNotFoundException, ConnectorException;   public void addNotificationListenerExtended(ObjectName name,      NotificationListener listener, NotificationFilter filter,      Object handback) throws ConnectorException;   public Object getAttribute(ObjectName name, String attribute)     throws MBeanException, AttributeNotFoundException,            InstanceNotFoundException, ReflectionException, ConnectorException ;   public AttributeList getAttributes(ObjectName name, String[] attributes)     throws InstanceNotFoundException, ReflectionException,             ConnectorException;   public java.util.Properties getConnectorProperties();   public String getDefaultDomain() throws ConnectorException ;   public String getDomainName() throws ConnectorException ;   public Integer getMBeanCount() throws ConnectorException ;   public MBeanInfo getMBeanInfo(ObjectName name)     throws InstanceNotFoundException, IntrospectionException,             ReflectionException, ConnectorException ;   public ObjectName getServerMBean() throws ConnectorException;   public String getType();   public Object invoke(ObjectName name, String operationName, Object params[],     String signature[]) throws InstanceNotFoundException, MBeanException,      ReflectionException, ConnectorException ;     public Session isAlive() throws ConnectorException ;   public boolean isInstanceOf(ObjectName name, String className)     throws InstanceNotFoundException, ConnectorException ;   public boolean isRegistered(ObjectName name) throws ConnectorException ;   public Set queryNames(ObjectName name, QueryExp query)      throws ConnectorException ;   public void reconnect() throws ConnectorNotAvailableException ;   public void removeNotificationListener(ObjectName name,      NotificationListener listener) throws InstanceNotFoundException,      ListenerNotFoundException, ConnectorException;   public void removeNotificationListenerExtended(NotificationListener listener)      throws ListenerNotFoundException, ConnectorException;   public void setAttribute(ObjectName name, Attribute attribute)     throws InstanceNotFoundException, AttributeNotFoundException,            InvalidAttributeValueException, MBeanException,             ReflectionException, ConnectorException ;   public AttributeList setAttributes(ObjectName name, AttributeList attributes)     throws InstanceNotFoundException, ReflectionException,             ConnectorException ; }

The AdminClient interface is largely the same as the javax.management.MbeanServer interface – the primary difference is the removal of operations that require execution in the JMX server process (in the same JVM address space), and the inclusion of methods to support the connection of the client to the target JMX Server (through its corresponding AdminService).

MBeans and the Information Model

The MBean information model is used to define what types of MBeans can be found in the system. Not every one of these MBean types can be found in every JMX server – a few of them are only relevant in the node agent or deployment manager. Through the JMX connectors and routing function built in to the admin service, you can reference to any JMX MBean wherever MBeans are hosted – in the deployment manager, the node agents, or any of the application servers.

The MBeans in the information model include:

AdminOperations	EJBContainer	MessageDriven Bean	SessionBean
Application	EJBModule	Module	SessionManager
ApplicationManager	EntityBean	NameServer	Stateful SessionBean
AppManagement	J2CConnectionFactory	NodeAgent	Stateless SessionBean
CellSync	J2Cresource Adapter	NodeSync	SystemMetrics
Cluster	J2EEResource Factory	Notification Service	ThreadPool
ClusterMgr	J2EEResource Provider	ORB	TraceService
ConfigService	JDBCProvider	Perf	Transaction
ConnectionFactory	JMSDestination	PluginCfg Generator	Transaction Service
DataSource	JMSProvider	PmiRmJmxService	URLProvider
DataSourceCfgHelper	JMSServer	RasLogging Service	WAS40Data Source
DeployedObject	JMXConnector	ResourceAdapter	WebContainer
DeploymentManager	JSP	ResourceAdapter Module	WebModule
Discovery	JVM	SecurityAdmin	WLMAppServer
DynaCache	ListenerPort	Server	WMQQueue Definer
EJB	MailProvider	Servlet	WSGW

As you can see, most of these MBeans represent obvious resources in the system, such as Cluster, ClusterMgr, DeploymentManager, EJBContainer, NodeAgent, and so on. Other MBeans represent resources within your applications, such as EJB, Servlet, WebModule, etc. Others are a little more esoteric, such as AdminOperations, AppManagement, and SystemMetrics. The full Javadocs for all of these MBeans are included in the WebSphere product under web/mbeanDocs/index.html in the install root directory for the WebSphere Application Server, and can also be accessed from the WebSphere InfoCenter at http://www.ibm.com/software/webservers/appserv/infocenter.html. That's really the best place to get detailed information on each of these MBean types and what you can do with them. We'll detail a couple of them below to give you a sense of what's going on. Before we do, there are a couple of things to be said about MBeans.

MBeans are defined to support a set of attributes, operations, and notifications:

• Attributes typically tell you something about the MBean – providing identity information, options that effect operational behavior, relations to other MBeans, or statistical information.

• The operations allow you to drive actions on the MBean (and by extension, the resource that the MBean represents).

• Notifications are events that you can register for – informing you of significant state changes in the MBean (or the resource that it represents).

The attributes, operations, and notifications that a given MBean supports are defined in an MBean descriptor that is registered with the JMX Server. The descriptor is an XML file that describes the characteristics of the MBean. The Javadoc for MBeans supported by WebSphere is generated from these MBean descriptors.

The AppManagement MBean

The AppManagement MBean allows you to perform a number of application management operations – including installing and uninstalling applications and resource adapters, getting and setting information about the application, and changing which application servers the application is to be hosted on.

The AppManagement MBean has no attributes.

The operations of the AppManagement MBean include:

install Application	setModuleInfo	listModules	removeAllAppsFromNode
uninstall Application	moveModule	compareSecurity Policy	removeAllAppsFromCluster
getApplication Info	export Application	installStandaloneRAR	removeAllAppsFromServer
getModuleInfo	extractDDL	checkIfAppExists	ChangeServerTo Cluster
setApplication Info	list Applications	redeploy Application	ClusterMember Added

The module-related operations – getModuleInfo, setModuleInfo, moveModule, and listModules operate on the J2EE modules defined in the specified application.

The AppManagement MBean resides on the application server and (when configured with one) the deployment manager. The instance on the application server only has visibility to the application server on which it resides, and so you can only install an application on that application server, and cannot move the modules of the application to other application server instances when you're operating on the MBean instance hosted on a given application server. On the other hand, if you operate on the instance in the deployment manager then you can install the application into the cell, and configure it to be hosted on any of the application servers configured in that cell.

The notifications generated by the AppManagement MBean include:

websphere.admin.appmgmt

The appmgmt notification is fired whenever an application install, uninstall, or update occurs.

The NodeAgent MBean

The NodeAgent represents the node agent on each computer (more literally, on each node, as a single computer could have more than one node and therefore more than one node agent – we discuss this further in the Node Agent section later in this chapter). The node agent is generally responsible for monitoring all of the application servers that are hosted on that node, and providing remote communication to these servers from the central deployment manager (also discussed later in this chapter). The NodeAgent MBean has no attributes.

It supports the following operations:

launchProcess

stopNode

restart

The launchProcess operation is used to start an application server. This can be issued with or without specifying a timeout value – indicating the maximum time you are willing to wait for the server to start and initialize.

The stopNode operation is used to stop all application servers on the node, including the node agent itself.

The restart operation is used to restart the node agent, and optionally to restart any running application servers at the same time. If the option to restart the running applications is not selected, then just the node agent is restarted – the application servers continue to operate normally. If, on the other hand, the option to restart the application servers is selected, then the application servers on that node are stopped gracefully, and then automatically restarted after the node agent is restarted. The node agent will not be shut down until that last application server on that node has fully quiesced and outstanding workload on that server has completed. In addition, this operation can be used to optionally resynch the node configuration with the cell manager as part of the node agent restart.

The notifications emitted by the NodeAgent MBean include:

websphere.process.starting	websphere.process.running	websphere. process.stopping
websphere.process.stopped	websphere.process.failed

Each of these indicates that one of the application servers on the target node is either starting, running, stopping, stopped, or has failed.

The TransactionService MBean

The TransactionService MBean represents the transaction service and can be used to collect information about the service – including its current operating attributes and the outstanding in-flight transactions. The TransactionService MBean has the following attributes:

transactionLogDirectory

totalTranLifetimeTimeout

clientInactivity
Timeout

The transactionLogDirectory defines the directory in which the transaction log will be recorded. The totalTranLifetimeTimeout indicates, in milliseconds, the maximum amount of time a transaction can take to complete. If any given transaction has not been completed within the time specified in this attribute it will automatically be rolled back by the transaction service. If this attribute is set to zero (0), transactions are not timed – they are left to execute indefinitely.

The clientInactivityTimeout indicates, in milliseconds, the maximum time allowed between client requests under a given transaction. If the client takes more than the specified time to initiate another method request in the same transaction, the transaction will automatically be rolled back. If this attribute is set to zero (0), the interval between client requests is not timed.

The TransactionService MBean supports the following operations:

printableListOfTransactions

listOfTransactions

The listOfTransaction operation returns an array of the outstanding transaction identities, and the printableListOfTransactions returns the list as a single string pre-formatted for printing.

The TransactionService MBean does not emit any notifications.

This obviously is not a complete specification of the information model for the MBeans in WebSphere. You should consult the Javadoc for the MBean information model in the WebSphere InfoCenter for more detail on the remaining MBeans. However, this short summary should have given you the sense of what MBeans are and what they do. We'll come back to the subject of MBeans during the programming track for this chapter.

Configuration Repository

The configuration repository is where the configuration information is kept persistently. The configuration, of course, describes what application servers are located on which node, on which computer, and in which cell. It also defines what applications are hosted on which servers, which servers are aggregated to form a cluster, what resources are located where, the mapping between application references to those resources and the actual resources, and any behavioral options in effect for each resource.

A configuration repository is created on every node where WebSphere is installed – the repository simply consists of a set of configuration documents stored in a particular directory structure on the file system. In addition, if you've installed the Network Deployment edition, a copy of the configuration documents is maintained on the central deployment manager. The central repository is also maintained in a directory structure on the file system of the deployment management node – collecting a copy of every configuration document for each application server on each node federated in the cell.

Each application server only ever operates on the configuration document held for it in its local file system. In this way, no application server is ever dependent on the central configuration repository to know what applications it is serving, or where the resources are for those applications. In this sense, the repository is a highly distributed and fragmented database. This retains a high degree of independence for each application server – allowing it to operate without the central deployment manager and configuration repository, and by extension avoiding the central repository manager as a single point of failure. On the other hand, this fragmentation would make it difficult for the administrators to understand their system configuration.

To overcome this, WebSphere maintains a copy of all of the repository documents in a central repository on the deployment manager. Any configuration management performed with the deployment manager is done against the repository held with the deployment manager. It is then the responsibility of the deployment manager and the node agents on each node to synchronize their respective copies of the configuration documents.

When you make a change to the configuration of the system with the deployment manager and save those changes they are only saved immediately to the central repository. Those changes won't be propagated out to the individual application servers on their respective nodes until the central repository and the node repository are synchronized. The lag-time between when you save a configuration change and when it actually takes effect on the server depends on a number of things, including the synchronization settings in your configuration, and the state of the server(s) that you are changing – that is, whether it is up or down.

The repositories are synchronized first when you add a node into your cell (see the Managing a Network of Application Servers section later in this chapter for more details), and then resynchronized automatically or manually thereafter. A number of options can be set for when and how often the repositories are synchronized. These are controlled through settings on each individual node agent. You can access these options on the admin UI by first selecting System Administration | Cell in the navigation pane of the admin console. This will present the cell configuration notebook:

Next, press the Local Topology page tab, and expand the cell topology below that until you can see the node agent server that you want to configure. Notice that the node agent is itself a server (not an application server, but nonetheless a server), and so you have to expand the servers under the node to locate it. The node agent will always have the name of the node that it represents:

You can then select the node agent server to see the configuration page:

Finally, select the File Synchronization Service to see the options for how and when synchronization between the deployment manager and the node is performed:

The synchronization options are:

• Startup
  This option is ignored by the synchronization service – the service is always enabled and operates on the more specific configuration policies listed below.

• Synchronization interval
  The synchronization interval indicates how frequently (in minutes) resynchronization should be performed if automatic synchronization is selected.

• Automatic synchronization
  The configuration will automatically be resynchronized between the deployment manager and this node if this option is enabled. If auto-synchronization is enabled, the re-synchronization will occur as often as indicated in the synchronization-interval option above.

  Important

  You should think seriously about whether you want auto-synchronization enabled. On the one hand, if you disable it, any configuration changes you make on the deployment manager won't take effect on the application servers affected by that change until you manually force resynchronization. You could find your administrators wondering why their configuration changes are not taking effect. On the other hand, disabling auto-synchronization will help prevent configuration changes from inadvertently changing your production environment. With auto-synch disabled, you have to make the configuration change, save it and manually force the re-synchronization. This gives you slightly better control over your production changes.

• Startup synchronization
  This option instructs the deployment manager to synchronize the configuration for any application server whenever that application server starts.

• Publish synchronization
  This option instructs the deployment manager to synchronize with the node immediately whenever a configuration change is saved by the administrator at the deployment manager.

• Exclusions
  This allows you to specify those files that you explicitly don't want synchronized between the deployment manager and the node. You can list file names with or without wildcards (? and *), on separate lines.

The configuration for each application server is held in the file system on each node. The structure of the configuration repository is:

cells /-- <cell-name> /-- nodes /-- <node-name>* /-- servers /-- <server-name>*

Just as you see it in the admin UI.

There is only ever one cell-name – either the name of the local host for standalone servers, or the name of the cell if the node has been federated into a cell.

You will only ever find one node-name listed under nodes on a given node – the name of the local-node. You will find all of the nodes that have been federated into the cell in the same configuration repository on the deployment manager.

All of the application server instances that have been created on this node will be listed under servers.

Each of these directories – cells/<cell-name>, cells/<cell-name>/nodes/<node-name>, and cells/<cell-name>/nodes/<node-name>/servers/<server-name> – contains a set of configuration XML documents. These documents describe the overall configuration for the system.

Administration Application and Workspace

The Administration application is a fully conforming J2EE web application that implements the user interface of the middleware management system. This application, as you would expect of a web application, supports a browser-based interface.

This same application is used as the middleware management user interface for all editions of WebSphere. It is hosted in the application server for single, standalone server configurations, or it is hosted in the deployment manager in Network Deployment configurations.

The Admin application is installed in the application server by default. Since it is a standard J2EE application, you can see it in the installed applications of the application server in a single, standalone server configuration:

Like other applications, you can uninstall it. However, if you uninstall it from a single, standalone server configuration you will not be able to install it back using a user interface – you will have to use the command line or script interface to re-install it!

If you convert a single, standalone server configuration into a networked configuration of multiple application servers, the Admin application is typically uninstalled from the application server(s) and only run from the deployment manager.

You will find the Admin application will look slightly different when hosted in the deployment manager. When the Admin application is hosted in a single, standalone server it knows that it essentially only has visibility to the application server on which it is run (see additional comments below for why this isn't entirely true). However, when the Admin application is hosted in the deployment manager, it knows that it has visibility to every application server configured in the deployment cell – even on other nodes. In the latter case, the Admin application adjusts its presentation to show all of the application servers in the deployment cell, and allows you to create clusters of multiple application servers (as you might expect, clusters are not supported in single, standalone server configurations).

Workspaces are a concept that is used within the Admin application to hold configuration changes as you make them. A workspace is created for each administrator user when they login to the admin console the first time. As you navigate around in the admin configuration copies of the configuration documents that you touch (via the admin UI) are cached in your workspace. If you change the configuration, the change is initially only made on the cached copy of the configuration document in your workspace. The changes are not applied to the master repository until you "save" those changes. The Save function is always listed on the system menu bar for the admin UI.

If you change the configuration and press OK, you will be reminded that you have pending changes in the workspace that have not been saved, and will be prompted to initiate the save.

Of course, you may want to hold off on saving your changes if you have other changes you need to make. These additional changes will be collected in the workspace until you do save.

The workspace is retained persistently. If you logout without having saved your changes you will be prompted to do so:

You can proceed to logout without saving, and your workspace will be retained persistently. When you log back in again, you will be given the option of continuing with your unsaved changes:

You, of course, can discard your changes at any time without saving them.

Concurrency Model in WebSphere

The base WebSphere Application Server and Network Deployment edition products assume an optimistic concurrency model. That means that WebSphere assumes that two administrators will rarely attempt to change the same part of the configuration at the same time. For example, it assumes that normally only one administrator will change the configuration of a given server at a time. WebSphere does monitor for conflicting configuration changes. However, if such a conflict is discovered, the first administrator to save their changes will be fine, and the second administrator will get a choice of either discarding their own changes and starting over again, or overwriting the changes made by the first administrator – setting the configuration to the way the second administrator sees it (even reverting configuration values that the second administrator has not changed).

If the second administrator overwrites the changes of the first administrator, the first administrator is not notified of that – they won't discover the overwrite until they re-examine the configuration.

Node Agent

The Node Agent is a daemon process that runs on every node federated into the cell. The node agent serves three purposes:

• The node agent serves as an end point for communication from the deployment manager – principally to enable the synchronization of configuration between the deployment manager and the node. In this capacity, the node agent represents the node and the application server instances configured to the node.

• The node agent also contains a JMX server and admin service, both to host MBeans that control the state and operation of the node, and as a conduit to communicate operational and monitoring messages between the deployment manager and the individual application servers.

• The node agent is a monitor and nanny for the application server instances configured on the node. The node agent is responsible for starting application servers on the server, and re-starting them in the rare case they should fail.

The node in a WebSphere network is a logical concept – it represents a set of application servers. Its only concrete constraint is that the servers that it represents must co-reside on the same computer – the node agent must be able to monitor the state of the application server processes, to be able to spawn those processes, and if necessary force them to terminate.

Otherwise, you can establish multiple nodes on the same computer – each representing a different set of application server instances. Obviously the node must have a unique name – by default, nodes are assigned the name of the host (as taken from the IP configuration for the computer) on which they're created – and be assigned a unique port address (in the case where more than one node is configured on the same host). A node agent is created for each defined node.

If you don't federate the application server(s) of a given node into the cell, then the node agent is not needed – it will not be instantiated. However, if you federate the node into the cell (using the addNode command), then the node agent for that node will automatically be instantiated. On Windows platforms, you should register the node agent as a service. In this way, the operating system will ensure that the node is automatically started every time you re-boot the system and, more importantly, monitor the node agent process – restarting if the node agent should fail.

Deployment Manager

The deployment manager is only relevant when you have multiple application server instances that you want to control from a single point – it provides a central point of configuration and control for all of the application servers in the cell. The deployment manager represents the cell – a set of application servers and related resources composed in a topology.

In this role the deployment manager has several responsibilities:

• It manages the central repository for the cell.

• It synchronizes the configuration captured in the central repository with the node repositories for each node registered in the cell.

• It hosts the central JMX server and admin service through which the entire cell can be managed.

• It also hosts the central admin application supporting the browser-based admin UI.

The deployment manager is the point of control that you will attach your clients to – browsers, command-line clients, scripting clients, client admin programs – to manage the cell.

Just to reinforce a point that we made earlier – while the deployment manager is a central point of control for the cell, it is not a single point of failure for the operational aspects of the running system. In other words, application servers will continue to come up and service client requests even if the deployment manager is down. The only thing you lose if the deployment manager is down is the ability to centrally administer the network – change configurations, install applications, and so on. Like any of the WebSphere servers, if it should fail you can restart it within a very short period of time.

PME Administration Extensions

Some of the programming model extensions (PMEs) provided in the Enterprise edition of WebSphere have their own administration requirements. For example, you have to administer the task to profile mappings for Application Profiling, you have to administer the rule repository for Business Rules Beans, and so on. The administration support for the PMEs is shipped in Enterprise edition, and plugs in as an extension to the base middleware management facility in WAS and the deployment manager. You continue to use the standard middleware management facilities as described throughout the rest of this chapter, but after installing the Enterprise edition other things just show up on your admin UI and in the information model.