WebSphere Application Server Network Deployment topologies

The administration components and the runtimes are deployed in servers or clusters of the WebSphere® Application Server Network Deployment cell.

Examples of these topologies support either asymmetric or symmetric deployment, or both. You can, for example, deploy the administration components (MobileFirst Operations Console, the administration service, and the live update service) in one cluster and the runtimes managed by these components in another cluster.

Symmetric deployment in the same server or cluster

Figure 1 shows symmetric deployment where the runtimes and the administration components are deployed in the same server or cluster.

Figure 1. Symmetric deployment, same server or cluster

Administration components and runtimes deployed in the same cluster.

The deployment of this topology has the following characteristics:

One or several administration components can be deployed in one or several servers or clusters of the cell. Each instance of MobileFirst Operations Console communicates with one administration service and one live update service.
One or several runtimes can be deployed in the same server or cluster as the administration components that manage them.
One runtime is managed by only one MobileFirst Operations Console.
Each administration service uses its own administration database schema.
Each live update service uses its own live update database schema.
Each runtime uses its own runtime database schema.

Asymmetric deployment with runtimes and administration services in different server or cluster

Figure 2 shows a topology where the runtimes are deployed in a different server or cluster from the administration services.

Figure 2. Asymmetric deployment, different server or cluster

Administration components and runtimes deployed in a different server or cluster.

The deployment of this topology has the following characteristics:

One or several administration components can be deployed in one or several servers or clusters of the cell. Each instance of MobileFirst Operations Console communicates with one administration service and one live update service.
One or several runtimes can be deployed in other servers or clusters of the cell.
One MobileFirst Operations Console manages several runtimes deployed in the other servers or clusters of the cell.
One runtime is managed by only one MobileFirst Operations Console.
Each administration service uses its own administration database schema.
Each live update service uses its own live update database schema.
Each runtime uses its own runtime database schema.

This topology is advantageous, because it enables the runtimes to be isolated from the administration components and from other runtimes. It can be used to provide performance isolation, to isolate critical applications, and to enforce Service Level Agreement (SLA).

Symmetric and asymmetric deployment

Figure 3 shows an example of symmetric deployment in Cluster1 and of asymmetric deployment in Cluster2, where Runtime2 and Runtime3 are deployed in a different cluster from the administration components. MobileFirst Operations Console manages the runtimes deployed in Cluster1 and Cluster2.

Figure 3. Symmetric and asymmetric deployment in different clusters of a cell

Each cluster supports a different type of deployment, Cluster1 symmetric and Cluster2 asymmetric.

The deployment of this topology has the following characteristics:

One or several administration components can be deployed in one or several servers or clusters of the cell. Each instance of MobileFirst Operations Console communicates with one administration service and one live update service.
One or several runtimes can be deployed in one or several servers or clusters of the cell.
One MobileFirst Operations Console can manage several runtimes deployed in the same or other servers or clusters of the cell.
One runtime is managed by only one MobileFirst Operations Console.
Each administration service uses its own administration database schema.
Each live update service uses its own live update database schema.
Each runtime uses its own runtime database schema.

Configuration of JNDI properties

Some JNDI properties are required to enable JMX communication between the administration service and the runtime, and to define the administration service that manages a runtime. For details about these properties, see List of JNDI properties for MobileFirst Server administration service and List of JNDI properties for MobileFirst runtime

The following local JNDI properties are required for the administration services and for the runtimes:

Table 1. Local JNDI properties for administration services and runtimes in WebSphere Application Server Network Deployment topologies
JNDI properties	Values
mfp.topology.platform	WAS
mfp.topology.clustermode	Cluster
mfp.admin.jmx.connector	The JMX connector type to connect with the deployment manager. The value can be SOAP or RMI. SOAP is the default and preferred value. You must use RMI if the SOAP port is disabled.
mfp.admin.jmx.dmgr.host	The host name of the deployment manager.
mfp.admin.jmx.dmgr.port	The RMI or the SOAP port used by the deployment manager, depending on the value of mfp.admin.jmx.connector.

Several administration components can be deployed to enable you to run the same server or cluster with separate administration components managing each of the different runtimes.

When several administration components are deployed, you must specify:

On each administration service, a unique value for the local mfp.admin.environmentid JNDI property.
On each runtime, the same value for the local mfp.admin.environmentid as the value defined for the administration service that manages that runtime.

If the virtual host that is mapped to an administration service application is not the default host, you must set the following properties on the administration service application:

mfp.admin.jmx.user: the user name of the WebSphere Application Server administrator
mfp.admin.jmx.pwd: the password of the WebSphere Application Server administrator