For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.


Network flows between the MobileFirst Server components

The MobileFirst Server 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:

Network flows between different MobileFirst Server components and the mobile devices

The flows between the various MobileFirst Server components, IBM MobileFirstâ„¢ Analytics, the mobile devices, and the application server are explained in the following sections:

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


MobileFirst runtime to MobileFirst Server 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 MobileFirst 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 MobileFirst Server administration service, MobileFirst Server live update service and MobileFirst 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:

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 MobileFirst Server administration service, MobileFirst Server live update service and MobileFirst runtime.

To distinguish different installation of MobileFirst Server on the same application server or on the same WebSphere Application Server cell, we 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 MobileFirst Operations Console shows no runtime available.

An administration service must be able to communicate with all the MobileFirst 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 MobileFirst Server administration service, MobileFirst Server live update service and MobileFirst 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 MobileFirst Server administration service to MobileFirst Server 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:

MobileFirst Server administration service

  • Table 1 - JNDI properties for administration services: JMX
  • Table 4 - JNDI properties for administration services: proxies
  • Table 5 - JNDI properties for administration services: topologies
MobileFirst runtime
List of JNDI properties for MobileFirst runtime


MobileFirst Server administration service to MobileFirst runtime in other servers

As described in MobileFirst runtime to MobileFirst Server 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.


MobileFirst Server administration service and MobileFirst 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 MobileFirst runtime to MobileFirst Server administration service and MobileFirst Server administration service to MobileFirst 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.


MobileFirst Server push service and MobileFirst runtime to MobileFirst Analytics

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

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


MobileFirst Server administration service to MobileFirst Server live update service

The administration service communicates with the live update service to store and retrieve configuration information about the MobileFirst 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:


MobileFirst Operations Console to MobileFirst Server administration service

MobileFirst 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 MobileFirst Operations Console.

Note: The mfp.admin.endpoint property enables the console to locate the administration service. We 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.


MobileFirst Server administration service to MobileFirst Server 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 MobileFirst runtime.

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

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:


MobileFirst Server 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:

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


Mobile devices to MobileFirst 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 MobileFirst security framework.

Parent topic: Topologies and network flows