Topologies and Network flows

Overview

The information presented here details possible server topologies for PMF components, as well as available network flows.
The components are deployed according to the server topology that you use. The network flows explain to you how the components communicate with one another and with the end-user devices.

Jump to

• Network flows between the PMF components
• Constraints on the PMF components and Persistent Mobile Foundation Analytics
• Multiple PMF runtimes
• Multiple instances of PMF on the same server or WebSphere Application Server cell

Network flows between the PMF components

The PMF components can communicate with each other over JMX or HTTP. You need to configure certain JNDI properties to enable the communications.
The network flows between the components and the device can be illustrated by the following image:

The flows between the various PMF components, Persistent Mobile Foundation Analytics, the mobile devices, and the application server are explained in the following sections:

1. PMF runtime to PMF administration service
2. PMF administration service to PMF runtime in other servers
3. PMF administration service and PMF runtime to the deployment manager on WebSphere Application Server Network Deployment
4. PMF push service and PMF runtime to Persistent Mobile Foundation Analytics
5. PMF administration service to PMF live update service
6. PMF Operations Console to PMF administration service
7. PMF administration service to PMF push service, and to the authorization server
8. PMF push service to an external push notification service (outbound)
9. Mobile devices to PMF runtime

PMF runtime to PMF administration service

The runtime and the administration service can communicate with each other through JMX and HTTP. This communication occurs during the initialization phase of the runtime. The runtime contacts the administration service local to its application server to get the list of the adapters and applications that it needs to serve. The communication also happens when some administration operations are run from PMF Operations Console or the administration service. On WebSphere Application Server Network Deployment, the runtime can contact an administration service that is installed on another server of the cell. This enables the non-symmetric deployment (see Constraints on PMF administration service, PMF live update service and PMF runtime). However, on all other application servers (Apache Tomcat, WebSphere Application Server Liberty, or stand-alone WebSphere Application Server), the administration service must be running on the same server as the runtime.

The protocols for JMX depend on the application server:

• Apache Tomcat - RMI
• WebSphere Application Server Liberty - HTTPS (with the REST connector)
• WebSphere Application Server - SOAP or RMI

For the communication via JMX, it is required that these protocols are available on the application server. For more information about the requirements, see Application server prerequisites.

The JMX beans of the runtime and the administration service are obtained from the application server. However, in the case of WebSphere Application Server Network Deployment, the JMX beans are obtained from the deployment manager. The deployment manager has the view of all the beans of a cell on WebSphere Application Server Network Deployment. As such, some configurations are not needed on WebSphere Application Server Network Deployment (such as the farm configuration), and non-symmetric deployment is possible on WebSphere Application Server Network Deployment. For more information, see Constraints on PMF administration service, PMF live update service and PMF runtime.

To distinguish different installation of PMF on the same application server or on the same WebSphere Application Server cell, you can use an environment ID, which is a JNDI variable. By default, this variable has an empty value. A runtime with a given environment ID communicates only with an administration service that has the same environment ID. For example, the administration service has an environment ID set to X, and the runtime has a different environment ID (for example, Y), then the two components do not see each other. The PMF Operations Console shows no runtime available.

An administration service must be able to communicate with all the PMF runtime components of a cluster. When an administration operation is run, such as uploading a new version of an adapter, or changing the active status of an application, all runtime components of the cluster must be notified about the change. If the application server is not WebSphere Application Server Network Deployment, this communication can happen only if a farm is configured. For more information, see Constraints on PMF administration service, PMF live update service and PMF runtime.

The runtime also communicates with the administration service through HTTP or HTTPS to download large artifacts such as the adapters. A URL is generated by the administration service and the runtime opens and outbound HTTP or HTTPS connection to request an artifact from this URL. It is possible to override the default URL generation by defining the JNDI properties (mfp.admin.proxy.port, mfp.admin.proxy.protocol, and mfp.admin.proxy.host) in the administration service. The administration service might also need to communicate with the runtime through HTTP or HTTPS to get the OAuth tokens that are used to run the push operations. For more information, see PMF administration service to PMF push service, and to the authorization server.

The JNDI properties that are used for the communication between the runtime and the administration service are as follows:

PMF administration service

• JNDI properties for administration services: JMX
• JNDI properties for administration services: proxies
• JNDI properties for administration services: topologies

PMF runtime

• List of JNDI properties for PMF runtime

PMF administration service to PMF runtime in other servers

As described in PMF runtime to PMF administration service, it is required to have the communication between an administration service and all the runtime components of a cluster. When an administration operation is run, all the runtime components of a cluster can then be notified about this modification. The communication is through JMX.

On WebSphere Application Server Network Deployment, this communication can occur without any specific configuration. All the JMX MBeans that correspond to the same environment ID are obtained from the deployment manager.

For a cluster of stand-alone WebSphere Application Server, WebSphere Application Server Liberty profile, or Apache Tomcat, the communication can happen only if a farm is configured. For more information, see Installing a server farm.

PMF administration service and Mobile Foundation runtime to the deployment manager on WebSphere Application Server Network Deployment

On WebSphere Application Server Network Deployment, the runtime and the administration service obtain the JMX MBeans that are used in PMF runtime to PMF administration service and PMF administration service to PMF runtime in other servers by communicating with the deployment manager. The corresponding JNDI properties are mfp.admin.jmx.dmgr.* in JNDI properties for administration services: JMX.

The deployment manager must be running to allow the operations that require JMX communication between the runtime and the administration service. Such operations can be a runtime initialization, or the notification of a modification performed through the administration service.

PMF push service and PMF runtime to Persistent Mobile Foundation Analytics

The runtime sends data to Persistent Mobile Foundation Analytics through HTTP or HTTPS. The JNDI properties of the runtime that are used to define this communication are:

• mfp.analytics.url - the URL that is exposed by Persistent Mobile Foundation Analytics service to receive incoming analytics data from the runtime. Example: http://<hostname>:<port>/analytics-service/rest

  When Persistent Mobile Foundation Analytics is installed as a cluster, the data can be sent to any member of the cluster.

• mfp.analytics.username - the user name that is used to access Persistent Mobile Foundation Analytics service. The analytics service is protected by a security role.
• mfp.analytics.password - the password to access the analytics service.

• mfp.analytics.console.url - the URL that is passed to PMF Operations Console to display a link to PMF Analytics Console. Example: http://<hostname>:<port>/analytics/console

  The JNDI properties of the push service that are used to define this communication are:

• mfp.push.analytics.endpoint - the URL that is exposed by Persistent Mobile Foundation Analytics service to receive incoming analytics data from the push service. Example: http://<hostname>:<port>/analytics-service/rest

  When Persistent Mobile Foundation Analytics is installed as a cluster, the data can be sent to any member of the cluster.

• mfp.push.analytics.username - the user name that is used to access Persistent Mobile Foundation Analytics service. The analytics service is protected a security role.
• mfp.push.analytics.password - the password to access the analytics service.

PMF administration service to PMF live update service

The administration service communicates with the live update service to store and retrieve configuration information about the PMF artifacts. The communication is performed through HTTP or HTTPS.

The URL to contact the live update service is automatically generated by the administration service. Both services must be on the same application server. The context root of the live update service must define in this way: <adminContextRoot>config. For example, if the context root of the administration service is mfpadmin, then the context root of the live update service must be mfpadminconfig. It is possible to override the default URL generation by defining the JNDI properties (mfp.admin.proxy.port, mfp.admin.proxy.protocol, and mfp.admin.proxy.host) in the administration service.

The JNDI properties to configure this communication between the two services are:

• mfp.config.service.user
• mfp.config.service.password
• And those properties in JNDI properties for administration services: proxies.

PMF Operations Console to PMF administration service

PMF Operations Console is a web user interface and acts as the front end to the administration service. It communicates with the REST services of the administration service through HTTP or HTTPS. The users who are allowed to use the console, must also be allowed to use the administration service. Each user that is mapped to a certain security role of the console must also be mapped to the same security role of the service. With this setup, the requests from the console can thus be accepted by the service.

The JNDI properties to configure this communication are in JNDI properties for the PMF Operations Console.

Note: The mfp.admin.endpoint property enables the console to locate the administration service. You can use the asterisk character “*” as wildcard for specifying that the URL, generated by the console to contact the administration services, use the same value as the incoming HTTP request to the console. For example: *://*:*/mfpadmin means use the same protocol, host, and port as the console, but use mfpadmin as context root. This property is specified for the console application.

PMF administration service to PMF push service, and to the authorization server

The administration service communicates with the push service to request various push operations. This communication is secured through the OAuth protocol. Both services need to be registered as confidential clients. An initial registration can be performed at installation time. In this process, both services need to contact an authorization server. This authorization server can be PMF runtime.

The JNDI properties of the administration service to configure this communication are:

• mfp.admin.push.url - the URL of the push service.
• mfp.admin.authorization.server.url - the URL of the PMF authorization server.
• mfp.admin.authorization.client.id - the client ID of the administration service, as an OAuth confidential client.
• mfp.admin.authorization.client.secret - the secret code that is used to get the OAuth-based tokens.

Note: The mfp.push.authorization.client.id and mfp.push.authorization.client.secret properties of the administration service can be used to register the push service automatically as a confidential client when the administration service starts. The push service must be configured with the same values.

The JNDI properties of the push service to configure this communication are:

• mfp.push.authorization.server.url - the URL of the PMF authorization server. Same as the property mfp.admin.authorization.server.url.
• mfp.push.authorization.client.id - the client ID of the push service to contact the authorization server.
• mfp.push.authorization.client.secret - the secret code that is used to contact the authorization server.

PMF push service to an external push notification service (outbound)

The push service generates outbound traffic to the external notification service such as Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM). This communication can also be done through a proxy. Depending on the notification service, the following JNDI properties must be set:

• push.apns.proxy
• push.gcm.proxy

For more information, see List of JNDI properties for PMF push service.

Mobile devices to PMF runtime

The mobile devices contact the runtime. The security of this communication is determined by the configuration of the application and the adapters that are requested. For more information, see PMF security framework.

Constraints on the PMF components and Persistent Mobile Foundation Analytics

Understand the constraints on the various PMF components and Persistent Mobile Foundation Analytics before you decide your server topology.

• Constraints on PMF administration service, PMF live update service and PMF runtime
• Constraints on PMF push service

Constraints on PMF administration service, PMF live update service and PMF runtime

Find out the constraints and the deployment mode of the administration service, live update service, and the runtime per server topology.

The live update service must be always installed with the administration service on the same application server as explained in PMF administration service to PMF live update service. The context root of the live update service must define in this way: /<adminContextRoot>config. For example, if the context root of the administration service is /mfpadmin, then the context root of the live update service must be /mfpadminconfig.

You can use the following topologies of application servers:

• Stand-alone server: WebSphere Application Server Liberty profile, Apache Tomcat, or WebSphere Application Server full profile
• Server farm: WebSphere Application Server Liberty profile, Apache Tomcat, or WebSphere Application Server full profile
• WebSphere Application Server Network Deployment cell
• Liberty collective

Modes of deployment

Depending on the application server topology that you use, you have two modes of deployment choice for deploying the administration service, the live update service and the runtime in the application server infrastructure. In asymmetric deployment, you can install the runtimes on different application servers from the administration and the live update services.

Symmetric deployment
In symmetrical deployment, you must install the PMF administration components (PMF Operations Console, the administration service, and the live update service applications) and the runtime on the same application server.

Asymmetric deployment
In asymmetric deployment, you can install the runtimes on different application servers from the PMF administration components.
Asymmetric deployment is only supported for WebSphere Application Server Network Deployment cell topology and for Liberty collective topology.

Select a topology

• Stand-alone server topology
• Server farm topology
• Liberty collective topology
• WebSphere Application Server Network Deployment topologies
• Using a reverse proxy with server farm and WebSphere Application Server Network Deployment topologies

Stand-alone server topology

You can configure a stand-alone topology for WebSphere Application Server full profile, WebSphere Application Server Liberty profile, and Apache Tomcat. In this topology, all the administration components and the runtimes are deployed in a single Java Virtual Machine (JVM).

With one JVM, only symmetric deployment is possible with the following characteristics:

• One or several administration components can be deployed. Each PMF Operations Console communicates with one administration service and one live update service.
• One or several runtimes can be deployed.
• One PMF Operations Console can manage several runtimes.
• One runtime is managed by only one PMF 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 Java Management Extensions (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 PMF administration service and List of JNDI properties for PMF runtime.

Stand-alone WebSphere Application Server Liberty profile server
The following global JNDI properties are required for the administration services and the runtimes.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.

When you deploy several administration components, 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 JNDI property as the value defined for the administration service that manages the runtime.

Stand-alone Apache Tomcat server The following local JNDI properties are required for the administration services and the runtimes.

JVM properties are also required to define Java Management Extensions (JMX) Remote Method Invocation (RMI). For more information, see Configuring JMX connection for Apache Tomcat.

If the Apache Tomcat server is running behind a firewall, the mfp.admin.rmi.registryPort and mfp.admin.rmi.serverPort JNDI properties are required for the administration service. See Configuring JMX connection for Apache Tomcat.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.
When you deploy several administration components, 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 JNDI property as the value defined for the administration service that manages the runtime.

Stand-alone WebSphere Application Server
The following local JNDI properties are required for the administration services and the runtimes.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.
When you deploy several administration components, 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 JNDI property as the value defined for the administration service that manages the runtime.

Server farm topology

You can configure a farm of WebSphere Application Server full profile, WebSphere Application Server Liberty profile, or Apache Tomcat application servers.

A farm is a set of individual servers where the same components are deployed and where the same administration service database and runtime database are shared between the servers. The farm topology enables the load of PMF applications to be distributed across several servers. Each server in the farm must be a Java virtual machine (JVM) of the same type of application server; that is, a homogeneous server farm. For example, a set of several Liberty servers can be configured as a server farm. Conversely, a mix of Liberty server, Tomcat server, or stand-alone WebSphere Application Server cannot be configured as a server farm.

In this topology, all the administration components (PMF Operations Console, the administration service, and the live update service) and the runtimes are deployed on every server in the farm.

This topology supports only symmetric deployment. The runtimes and the administration components must be deployed on every server in the farm. The deployment of this topology has the following characteristics:

• One or several administration components can be deployed. Each instance of PMF Operations Console communicates with one administration service and one live update service.
• The administration components must be deployed on all servers in the farm.
• One or several runtimes can be deployed.
• The runtimes must be deployed on all servers in the farm.
• One PMF Operations Console can manage several runtimes.
• One runtime is managed by only one PMF Operations Console.
• Each administration service uses its own administration database schema. All deployed instances of the same administration service share the same administration database schema.
• Each live update service uses its own live update database schema. All deployed instances of the same live update service share the same live update database schema.
• Each runtime uses its own runtime database schema. All deployed instances of the same runtime share the same runtime database schema.

Configuration of JNDI properties

Some JNDI properties are required to enable JMX communication between the administration service and the runtime of the same server, and to define the administration service that manages a runtime. For convenience, the following tables list these properties. For instructions about how to install a server farm, see Installing a server farm. For more information about the JNDI properties, see List of JNDI properties for PMF administration service and List of JNDI properties for PMF runtime.

WebSphere Application Server Liberty profile server farm
The following global JNDI properties are required in each server of the farm for the administration services and the runtimes.

<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" host="*" />

<administrator-role>
    <user>MfpRESTUser</user>
</administrator-role>

The mfp.admin.serverid JNDI property is required for the administration service to manage the server farm configuration. Its value is the server identifier, which must be different for each server in the farm.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.

When you deploy several administration components, 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 JNDI property as the value defined for the administration service that manages the runtime.

Apache Tomcat server farm
The following global JNDI properties are required in each server of the farm for the administration services and the runtimes.

JVM properties are also required to define Java Management Extensions (JMX) Remote Method Invocation (RMI). For more information, see Configuring JMX connection for Apache Tomcat.

The mfp.admin.serverid JNDI property is required for the administration service to manage the server farm configuration. Its value is the server identifier, which must be different for each server in the farm.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.

When you deploy several administration components, 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 JNDI property as the value defined for the administration service that manages the runtime.

WebSphere Application Server full profile server farm
The following global JNDI properties are required on each server in the farm for the administration services and the runtimes.

The following JNDI properties are required for the administration service to manage the server farm configuration.

Several administration components can be deployed to enable the same JVM to run on separate administration components that manage different runtimes.

When you deploy several administration components, you must specify the following values:

• 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 JNDI property as the value defined for the administration service that manages the runtime.

Liberty collective topology

You can deploy the PMF components in a Liberty collective topology.

In the Liberty collective topology, the PMF administration components (PMF Operations Console, the administration service, and the live update service) are deployed in a collective controller and the PMF runtimes in collective member. This topology supports only asymmetric deployment, the runtimes cannot be deployed in a collective controller.

The deployment of this topology has the following characteristics:

• One or several administration components can be deployed in one or several controllers of the collective. Each instance of * * PMF Operations Console communicates with one administration service and one live update service.
• One or several runtimes can be deployed in the cluster members of the collective.
• One PMF Operations Console manages several runtimes that are deployed in the cluster members of the collective.
• One runtime is managed by only one PMF 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

The following tables list the 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 more information about these properties, see List of JNDI properties for PMF administration service and List of JNDI properties for PMF runtime. For instructions about how to install a Liberty collective manually, see Manual installation on WebSphere Application Server Liberty collective.

The following global JNDI properties are required for the administration services:

<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" host="*"/>

<administrator-role> <user>MfpRESTUser</user> </administrator-role>

Several administration components can be deployed to enable the controller to run separate administration components that manage different runtimes.

When you deploy several administration components, you must specify on each administration service, a unique value for the local mfp.admin.environmentid JNDI property.

The following global JNDI properties are required for the runtimes:

<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" host="*"/>

<administrator-role> <user>MfpRESTUser</user> </administrator-role>

The following JNDI property is required for the runtime when several controllers (replicas) using the same administration components are used:

When several administration components are deployed in the controller, each runtime must have the same value for the local mfp.admin.environmentid JNDI property as the value that is defined for the administration service that manages the runtime.

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 (PMF 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

The diagram below shows symmetric deployment where the runtimes and the administration components are deployed in the same 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 * PMF 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 PMF 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

The diagram below shows a topology where the runtimes are deployed in a different server or cluster from the administration services.

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 * PMF 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 PMF Operations Console manages several runtimes deployed in the other servers or clusters of the cell.
• One runtime is managed by only one PMF 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

The diagram below 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. PMF Operations Console manages the runtimes deployed in Cluster1 and Cluster2.

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 PMF 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 PMF 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 PMF 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 PMF administration service and List of JNDI properties for PMF runtime.

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

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

Using a reverse proxy with server farm and WebSphere Application Server Network Deployment topologies

You can use a reverse proxy with distributed topologies. If your topology uses a reverse proxy, configure the required JNDI properties for the administration service.

You can use a reverse proxy, such as IBM HTTP Server, to front server farm or WebSphere Application Server Network Deployment topologies. In this case, you must configure the administration components appropriately.

You can call the reverse proxy from:

• The browser when you access PMF Operations Console.
• The runtime when it calls the administration service.
• The PMF Operations Console component when it calls the administration service.

If the reverse proxy is in a DMZ (a firewall configuration for securing local area networks) and a firewall is used between the DMZ and the internal network, this firewall must authorize all incoming requests from the application servers.

When a reverse proxy is used in front of the application server infrastructure, the following JNDI properties must be defined for the administration service.

The mfp.admin.endpoint property that references the URL of the reverse proxy is also required for PMF Operations Console.

Constraints on PMF push service

The push service can be on the same application server as the administration service or the runtime, or can be on a different application server. The URL used by the client apps to contact the push service is the same as the URL used by the client apps to contact the runtime, excepted that the context root of the runtime is replaced by imfpush. If you install the push service on a different server than the runtime, your HTTP server must direct the traffic to the /imfpush context root to a server where the push service runs.

For more information about the JNDI properties that are needed to adapt the installation to a topology, see PMF administration service to PMF push service, and to the authorization server. The push service must be installed with the context root /imfpush.

Multiple PMF runtimes

You can install multiple runtimes. Each runtime must have its own context root, and all of these runtimes are managed by the same PMF administration service and PMF Operations Console.

The constraints as described in Constraints on PMF administration service, PMF live update service and PMF runtime applies. Each runtime (with its context root) must have its own database tables.

For instructions, see Configuring multiple runtimes.

Multiple instances of PMF on the same server or WebSphere Application Server cell

By defining a common environment ID, multiple instances of PMF are possible to be installed on the same server.

You can install multiple instances of PMF administration service, PMF live update service, and PMF runtime on the same application server or WebSphere Application Server cell. However, you must distinguish their installations with the JNDI variable: mfp.admin.environmentid, which is a variable of the administration service and of the runtime. The administration service manages only the runtimes that have the same environment identifier. As such, only the runtime components and the administration service that have the same value for mfp.admin.environmentid are considered as part of the same installation.