Topologies et flots réseau

Présentation

Les informations présentées ci-après décrivent les topologies de serveur possibles pour les composants MobileFirst Server, ainsi que les flots réseau disponibles.
Les composants sont déployés en fonction de la topologie de serveur que vous utilisez. Les flots réseau vous expliquent comment les composants communiquent entre eux et avec les appareils des utilisateurs finaux.

Aller à

• Flots réseau entre les composants MobileFirst Server
• Contraintes sur les composants MobileFirst Server et MobileFirst Analytics
• Plusieurs environnements d’exécution de Mobile Foundation
• Plusieurs instances de MobileFirst Server sur le même serveur ou la même cellule WebSphere Application Server

Flots réseau entre les composants MobileFirst Server

Les composants MobileFirst Server peuvent communiquer entre eux via JMX ou HTTP. Vous devez configurer certaines propriétés JNDI pour activer les communications.
L’image suivante représente les flots réseau entre les composants et l’appareil :

Les flots entre les différents composants MobileFirst Server, MobileFirst Analytics, les appareils mobiles et le serveur d’applications sont décrits dans les sections suivantes :

1. Communication entre l’environnement d’exécution de Mobile Foundation et le service d’administration de MobileFirst Server
2. Communication entre le service d’administration de MobileFirst Server et l’environnement d’exécution de Mobile Foundation dans d’autres serveurs
3. Communication entre le service d’administration de MobileFirst Server et l’environnement d’exécution de MobileFirst et le gestionnaire de déploiement sur WebSphere Application Server Network Deployment
4. Communication entre le service push de MobileFirst Server et l’environnement d’exécution de Mobile Foundation et MobileFirst Analytics
5. Communication entre le service d’administration de MobileFirst Server et le service Live Update de MobileFirst Server
6. Communication entre MobileFirst Operations Console et le service d’administration de MobileFirst Server
7. Communication entre le service d’administration de MobileFirst Server et le service push de MobileFirst Server et le serveur d’autorisations
8. Communication entre le service push de MobileFirst Server et un service de notification push externe (sortant)
9. Communication entre les appareils mobiles et l’environnement d’exécution de Mobile Foundation

Communication entre l’environnement d’exécution de Mobile Foundation et le service d’administration de MobileFirst Server

L’environnement d’exécution et le service d’administration peuvent communiquer entre eux via JMX et HTTP. Cette communication est établie lors de la phase d’initialisation de l’environnement d’exécution. L’environnement d’exécution contacte le service d’administration installé en local sur son serveur d’applications pour obtenir la liste des adaptateurs et des applications qu’il doit prendre en charge. La communication est également établie lorsque certaines opérations d’administration sont exécutées à partir de MobileFirst Operations Console ou du service d’administration. Sur WebSphere Application Server Network Deployment, l’environnement d’exécution peut contacter un service d’administration qui est installé sur un autre serveur de la cellule. Cela permet le déploiement non symétrique (voir Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation). Toutefois, sur tous les autres serveurs d’applications (Apache Tomcat, WebSphere Application Server Liberty ou WebSphere Application Server autonome), le service d’administration doit être en cours d’exécution sur le même serveur que l’environnement d’exécution.

Les protocoles pour JMX dépendent du serveur d’applications :

• Apache Tomcat - RMI
• WebSphere Application Server Liberty - HTTPS (avec le connecteur REST)
• WebSphere Application Server - SOAP ou RMI

Pour la communication via JMX, ces protocoles doivent être disponibles sur le serveur d’applications. Pour plus d’informations sur les exigences, voir Prérequis pour le serveur d’applications.

Les beans JMX de l’environnement d’exécution et du service d’administration sont obtenus auprès du serveur d’applications. Toutefois, avec WebSphere Application Server Network Deployment, les beans JMX sont obtenus auprès du gestionnaire de déploiement. Le gestionnaire de déploiement possède la vue de tous les beans d’une cellule sur WebSphere Application Server Network Deployment. Par conséquent, certaines configurations ne sont pas requises sur WebSphere Application Server Network Deployment (par exemple, la configuration en parc de serveurs) et un déploiement non symétrique est possible sur WebSphere Application Server Network Deployment. Pour plus d’informations, voir Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation.

Pour distinguer une autre installation de MobileFirst Server sur le même serveur d’applications ou sur la même cellule WebSphere Application Server, vous pouvez utiliser un ID d’environnement, qui est une variable JNDI. Par défaut, cette variable comporte une valeur vide. Un environnement d’exécution portant un ID d’environnement donné communique uniquement avec un service d’administration doté du même ID d’environnement. Par exemple, si le service d’administration possède un ID d’environnement X et l’environnement d’exécution possède un ID d’environnement différent (par exemple, Y), les deux composants ne se voient pas. Aucun environnement d’exécution disponible n’apparaît dans MobileFirst Operations Console.

Un service d’administration doit pouvoir communiquer avec tous les composants d’environnement d’exécution de Mobile Foundation d’un cluster. Lorsqu’une opération d’administration est exécutée, comme le téléchargement d’une nouvelle version d’un adaptateur ou le changement du statut actif d’une application, tous les composants d’environnement d’exécution du cluster doivent être prévenus de la modification. Si le serveur d’applications n’est pas WebSphere Application Server Network Deployment, cette communication ne peut être établie que si un parc de serveurs est configuré. Pour plus d’informations, voir Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation.

L’environnement d’exécution communique également avec le service d’administration via HTTP ou HTTPS pour télécharger des artefacts volumineux, tels que des adaptateurs. Une URL est générée par le service d’administration et l’environnement d’exécution ouvre une connexion HTTP ou HTTPS sortante pour demander un artefact à partir de cette URL. Il est possible de remplacer la génération d’URL par défaut en définissant les propriétés JNDI (mfp.admin.proxy.port, mfp.admin.proxy.protocol et mfp.admin.proxy.host) dans le service d’administration. Le service d’administration aura peut-être également besoin de communiquer avec l’environnement d’exécution via HTTP ou HTTPS pour obtenir les jetons OAuth utilisés pour exécuter les opérations push. Pour plus d’informations, voir Communication entre le service d’administration de MobileFirst Server et le service push de MobileFirst Server et le serveur d’autorisations.

Les propriétés JNDI utilisées pour la communication entre l’environnement d’exécution et le service d’administration sont les suivantes :

Le service d’administration de MobileFirst Server

• Propriétés JNDI pour les services d’administration : JMX
• Propriétés JNDI pour les services d’administration : proxys
• Propriétés JNDI pour les services d’administration : topologies

L’environnement d’exécution de Mobile Foundation

• Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst

Communication entre le service d’administration de MobileFirst Server et l’environnement d’exécution de Mobile Foundation dans d’autres serveurs

Comme indiqué dans la rubrique intitulée Communication entre l’environnement d’exécution de Mobile Foundation et le service d’administration de MobileFirst Server , une communication est requise entre un service d’administration et tous les composants d’environnement d’exécution d’un cluster. Lorsqu’une opération d’administration est exécutée, tous les composants d’environnement d’exécution d’un cluster peuvent alors être avertis de cette modification. La communication est établie via JMX.

Sur WebSphere Application Server Network Deployment, cette communication peut être établie sans aucune configuration spécifique. Tous les beans gérés JMX correspondant au même ID d’environnement sont obtenus auprès du gestionnaire de déploiement.

Pour un cluster de WebSphere Application Server autonome, de profil Liberty de WebSphere Application Server ou d’Apache Tomcat, la communication ne peut être établie que si un parc de serveurs est configuré. Pour plus d’informations, voir Installation d’un parc de serveurs.

Communication entre le service d’administration de MobileFirst Server et l’environnement d’exécution de MobileFirst et le gestionnaire de déploiement sur WebSphere Application Server Network Deployment

Sur WebSphere Application Server Network Deployment, l’environnement d’exécution et le service d’administration obtiennent les beans gérés JMX qui sont utilisés pour la communication entre l’environnement d’exécution de Mobile Foundation et le service d’administration de MobileFirst Server et pour la communication entre le service d’administration de MobileFirst Server et l’environnement d’exécution de Mobile Foundation dans d’autres serveurs avec le gestionnaire de déploiement. Les propriétés JNDI correspondantes sont mfp.admin.jmx.dmgr.* décrites dans Propriétés JNDI pour les services d’administration : JMX.

Le gestionnaire de déploiement doit être actif pour que les opérations nécessitant une communication JMX entre l’environnement d’exécution et le service d’administration puissent être exécutées. Ces opérations peuvent être l’initialisation de l’environnement d’exécution ou la notification d’une modification effectuée via le service d’administration.

Communication entre le service push de MobileFirst Server et l’environnement d’exécution de Mobile Foundation et MobileFirst Analytics

L’environnement d’exécution envoie des données à MobileFirst Analytics via HTTP ou HTTPS. Les propriétés JNDI de l’environnement d’exécution utilisées pour définir cette communication sont les suivantes :

• mfp.analytics.url - URL qui est exposée par le service MobileFirst Analytics pour recevoir les données d’analyse entrantes de l’environnement d’exécution. Exemple : http://<hostname>:<port>/analytics-service/rest

  Lorsque le service MobileFirst Analytics est installé en tant que cluster, les données peuvent être envoyées à n’importe quel membre du cluster.

• mfp.analytics.username - Nom d’utilisateur permettant d’accéder au service MobileFirst Analytics. Le service Analytics est protégé au moyen d’un rôle de sécurité.
• mfp.analytics.password - Mot de passe permettant d’accéder au service Analytics.

• mfp.analytics.console.url - URL transmise à MobileFirst Operations Console pour afficher un lien vers MobileFirst Analytics Console. Exemple : http://<hostname>:<port>/analytics/console

  Les propriétés JNDI du service push utilisées pour définir cette communication sont les suivantes :

• mfp.push.analytics.endpoint - URL qui est exposée par le service MobileFirst Analytics pour recevoir les données d’analyse entrantes du service push. Exemple : http://<hostname>:<port>/analytics-service/rest

  Lorsque le service MobileFirst Analytics est installé en tant que cluster, les données peuvent être envoyées à n’importe quel membre du cluster.

• mfp.push.analytics.username - Nom d’utilisateur permettant d’accéder au service MobileFirst Analytics. Le service Analytics est protégé au moyen d’un rôle de sécurité.
• mfp.push.analytics.password - Mot de passe permettant d’accéder au service Analytics.

Communication entre le service d’administration de MobileFirst Server et le service Live Update de MobileFirst Server

Le service d’administration communique avec le service Live Update pour stocker et extraire des informations de configuration relatives aux artefacts de Mobile Foundation. La communication est établie via HTTP ou HTTPS.

L’URL permettant de contacter le service Live Update est générée automatiquement par le service d’administration. Les deux services doivent figurer sur le même serveur d’applications. La racine de contexte du service Live Update doit être définie comme suit : <adminContextRoot>config. Par exemple, si la racine de contexte du service d’administration est mfpadmin, la racine de contexte du service Live Update doit être mfpadminconfig. Il est possible de remplacer la génération d’URL par défaut en définissant les propriétés JNDI (mfp.admin.proxy.port, mfp.admin.proxy.protocol et mfp.admin.proxy.host) dans le service d’administration.

Les propriétés JNDI permettant de configurer cette communication entre les deux services sont les suivantes :

• mfp.config.service.user
• mfp.config.service.password
• Propriétés décrites dans Propriétés JNDI pour les services d’administration : proxys.

Communication entre MobileFirst Operations Console et le service d’administration de MobileFirst Server

MobileFirst Operations Console est une interface utilisateur Web qui agit en tant que serveur frontal avec le service d’administration. Cette console communique avec les services REST du service d’administration via HTTP ou HTTPS. Les utilisateurs autorisés à utiliser la console doivent également être autorisés à utiliser le service d’administration. Chaque utilisateur mappé à un rôle de sécurité spécifique de la console doit également être mappé au même rôle de sécurité du service d’administration. Avec cette configuration, les demandes provenant de la console peuvent alors être acceptées par le service.

Les propriétés JNDI permettant de configurer cette communication entre les deux services sont décrites dans Propriétés JNDI pour MobileFirst Operations Console.

Remarque : La propriété mfp.admin.endpoint permet à la console de localiser le service d’administration. Vous pouvez utiliser l’astérisque “*” comme caractère générique pour indiquer que l’URL, générée par la console pour contacter les services d’administration, utilise la même valeur que la demande HTTP entrante sur la console. Par exemple, *://*:*/mfpadmin indique que le protocole, l’hôte et le port de la console doivent être utilisés, mais que mfpadmin doit être utilisé comme racine de contexte. Cette propriété est spécifiée pour l’application de console.

Communication entre le service d’administration de MobileFirst Server et le service push de MobileFirst Server et le serveur d’autorisations

Le service d’administration communique avec le service push pour demander diverses opérations push. Cette communication est sécurisée via le protocole OAuth. Les deux services doivent être enregistrés en tant que clients confidentiels. Un enregistrement initial peut être effectué lors de l’installation. Au cours de ce processus, les deux services doivent contacter un serveur d’autorisations. Ce serveur d’autorisations peut être l’environnement d’exécution de Mobile Foundation.

Les propriétés JNDI du service administration utilisées pour définir cette communication sont les suivantes :

• mfp.admin.push.url - URL du service push.
• mfp.admin.authorization.server.url - URL du serveur d’autorisations de Mobile Foundation.
• mfp.admin.authorization.client.id - ID de client du service d’administration, par exemple, un client confidentiel OAuth.
• mfp.admin.authorization.client.secret - Code secret utilisé pour obtenir les jetons basés sur OAuth.

Remarque : Les propriétés mfp.push.authorization.client.id et mfp.push.authorization.client.secret du service d’administration peuvent être utilisées pour enregistrer le service push automatiquement en tant que client confidentiel lorsque le service d’administration démarre. Le service push doit être configuré avec les mêmes valeurs.

Les propriétés JNDI du service push utilisées pour configurer cette communication sont les suivantes :

• mfp.push.authorization.server.url - URL du serveur d’autorisations de Mobile Foundation. Identique à la propriété mfp.admin.authorization.server.url.
• mfp.push.authorization.client.id - ID de client du service push utilisé pour contacter le serveur d’autorisations.
• mfp.push.authorization.client.secret - Code secret utilisé pour contacter le serveur d’autorisations.

Communication entre le service push de MobileFirst Server et un service de notification push externe (sortant)

Le service push génère un trafic sortant avec le service de notification externe, tel que APNS (Apple Push Notification Service) ou GCM (Google Cloud Messaging). Cette communication peut également être établie via un proxy. Selon le service de notification, les propriétés JNDI suivantes doivent être définies :

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

Pour plus d’informations, voir Liste des propriétés JNDI pour le service push de MobileFirst Server.

Communication entre les appareils mobiles et l’environnement d’exécution de Mobile Foundation

Les appareils mobiles contactent l’environnement d’exécution. La sécurité de cette communication est déterminée par la configuration de l’application et des adaptateurs qui sont demandés. Pour plus d’informations, voir Infrastructure de sécurité de MobileFirst.

Contraintes sur les composants MobileFirst Server et MobileFirst Analytics

Vous devez comprendre les contraintes sur les divers composants MobileFirst Server et sur MobileFirst Analytics avant de choisir votre topologie de serveur.

• Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation
• Contraintes sur le service push de MobileFirst Server

Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation

Découvrez les contraintes et le mode de déploiement du service d’administration, du service Live Update et de l’environnement d’exécution par topologie de serveur.

Le service Live Update doit toujours être installé avec le service d’administration sur le même serveur d’applications, comme indiqué dansCommunication entre le service d’administration de MobileFirst Server et le service Live Update de MobileFirst Server. La racine de contexte du service Live Update doit être définie comme suit : /<adminContextRoot>config. Par exemple, si la racine de contexte du service d’administration est /mfpadmin, la racine de contexte du service Live Update doit être /mfpadminconfig.

Vous pouvez utiliser les topologies de serveurs d’applications suivantes :

• Serveur autonome : profil de WebSphere Application Server Liberty, Apache Tomcat ou profil complet de WebSphere Application Server
• Parc de serveurs : profil Liberty de WebSphere Application Server Liberty, Apache Tomcat ou profil complet de WebSphere Application Server
• Cellule WebSphere Application Server Network Deployment
• Collectivité Liberty

Modes de déploiement

Selon la topologie de serveur d’applications que vous utilisez, vous avez le choix entre deux modes de déploiement pour déployer le service d’administration, le service Live Update et l’environnement d’exécution dans l’infrastructure de serveur d’applications. Dans le cadre d’un déploiement asymétrique, vous pouvez installer les environnements d’exécution sur différents serveurs d’applications à partir des services d’administration et Live Update.

Déploiement symétrique
Dans le cadre d’un déploiement symétrique, vous devez installer les composants d’administration de Mobile Foundation (MobileFirst Operations Console, le service d’administration et le service Live Update), ainsi que l’environnement d’exécution sur le même serveur d’applications.

Déploiement asymétrique
Dans le cadre d’un déploiement asymétrique, vous pouvez installer les environnements d’exécution sur différents serveurs d’applications à partir des composants d’administration de Mobile Foundation.
Le déploiement asymétrique est pris en charge uniquement pour la topologie de cellule WebSphere Application Server Network Deployment et la topologie de collectivité Liberty.

Sélection d’une topologie

• Topologie de serveur autonome
• Topologie de parc de serveurs
• Topologie de collectivité Liberty
• Topologies WebSphere Application Server Network Deployment
• Utilisation d’un proxy inverse avec des topologies de parc de serveurs et WebSphere Application Server Network Deployment

Topologie de serveur autonome

Vous pouvez configurer une topologie autonome pour le profil complet de WebSphere Application Server, le profil Liberty de WebSphere Application Server et Apache Tomcat. Dans cette topologie, tous les composants d’administration et environnements d’exécution sont déployés dans une seule machine virtuelle Java.

Avec une machine virtuelle Java, seul le déploiement symétrique est possible, avec les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés. Chaque application MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Un ou plusieurs environnements d’exécution peuvent être déployés.
• Une application MobileFirst Operations Console peut gérer plusieurs environnements d’exécution.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution.

Configuration des propriétés JNDI

Certaines propriétés JNDI sont requises pour activer la communication JMX (Java Management Extensions) entre le service d’administration et l’environnement d’exécution et pour définir le service d’administration qui gère un environnement d’exécution. Pour plus d’informations sur ces propriétés, voirListe des propriétés JNDI pour le service d’administration de MobileFirst Server et Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst.

Serveur de profil Liberty de WebSphere Application Server autonome
Les propriétés JNDI globales suivantes sont requises pour les services d’administration et les environnements d’exécution :

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

Serveur Apache Tomcat autonome Les propriétés JNDI locales suivantes sont requises pour les services d’administration et les environnements d’exécution :

Les propriétés JVM sont également requises pour définir l’invocation RMI JMX (Java Management Extensions). Pour plus d’informations, voir Configuration de la connexion JMX pour Apache Tomcat.

Si le serveur Apache Tomcat s’exécute derrière un pare-feu, les propriétés JNDI mfp.admin.rmi.registryPort et mfp.admin.rmi.serverPort sont requises pour le service d’administration. Voir Configuration de la connexion JMX pour Apache Tomcat.

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.
Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

WebSphere Application Server autonome
Les propriétés JNDI locales suivantes sont requises pour les services d’administration et les environnements d’exécution :

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.
Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

Topologie de parc de serveurs

Vous pouvez configurer un parc de serveurs d’applications pour le profil complet de WebSphere Application Server, le profil Liberty de WebSphere Application Server et Apache Tomcat.

Un parc de serveurs est un ensemble de serveurs individuels sur lesquels les mêmes composants sont déployés et les mêmes bases de données de service d’administration et d’environnement d’exécution sont partagées entre les serveurs. La topologie de parc de serveurs permet la répartition de la charge des applications Mobile Foundation sur plusieurs serveurs. Chaque serveur du parc doit être une machine virtuelle Java du même type de serveur d’applications, autrement dit, il doit s’agir d’un parc de serveurs homogène. Par exemple, un ensemble de serveurs Liberty peut être configuré en tant que parc de serveurs. En revanche, un ensemble mixte constitué d’un serveur Liberty, d’un serveur Tomcat ou d’un serveur WebSphere Application Server autonome ne peut pas être configuré en tant que parc de serveurs.

Dans cette topologie, tous les composants d’administration (MobileFirst Operations Console, le service d’administration et le service Live Update), ainsi que les environnements d’exécution sont déployés sur chaque serveur du parc.

Cette topologie ne prend en charge que le déploiement symétrique. Les environnements d’exécution et les composants d’administration doivent être déployés sur chaque serveur du parc de serveurs. Le déploiement de cette topologie possède les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés. Chaque instance de MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Les composants d’administration doivent être déployés sur tous les serveurs du parc de serveurs.
• Un ou plusieurs environnements d’exécution peuvent être déployés.
• Les environnements d’exécution doivent être déployés sur tous les serveurs du parc de serveurs.
• Une application MobileFirst Operations Console peut gérer plusieurs environnements d’exécution.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration. Toutes les instances déployées du même service d’administration partagent le même schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update. Toutes les instances déployées du même service Live Update partagent le même schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution. Toutes les instances déployées du même environnement d’exécution partagent le même schéma de base de données d’environnement d’exécution.

Configuration des propriétés JNDI

Certaines propriétés JNDI sont requises pour activer la communication JMX entre le service d’administration et l’environnement d’exécution du même serveur et pour définir le service d’administration qui gère un environnement d’exécution. Ces propriétés sont répertoriées dans les tableaux présentés ci-après. Pour savoir comment installer un parc de serveurs, voir Installation d’un parc de serveurs. Pour plus d’informations sur les propriétés JNDI, voir List of JNDI properties for MobileFirst Server administration service and Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst.

Parc de serveurs de profil Liberty de WebSphere Application Server
Les propriétés JNDI globales suivantes sont requises dans chaque serveur du parc de serveurs pour les services d’administration et les environnements d’exécution :

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

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

La propriété JNDI mfp.admin.serverid est requise pour permettre au service d’administration de gérer la configuration du parc de serveurs. Sa valeur correspond à l’identificateur de serveur et doit être différente pour chaque serveur du parc.

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

Parc de serveurs Apache Tomcat
Les propriétés JNDI globales suivantes sont requises dans chaque serveur du parc de serveurs pour les services d’administration et les environnements d’exécution :

Les propriétés JVM sont également requises pour définir l’invocation RMI JMX (Java Management Extensions). Pour plus d’informations, voir Configuration de la connexion JMX pour Apache Tomcat.

La propriété JNDI mfp.admin.serverid est requise pour permettre au service d’administration de gérer la configuration du parc de serveurs. Sa valeur correspond à l’identificateur de serveur et doit être différente pour chaque serveur du parc.

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

Parc de serveurs de profil complet de WebSphere Application Server
Les propriétés JNDI globales suivantes sont requises sur chaque serveur du parc de serveurs pour les services d’administration et les environnements d’exécution :

Les propriétés JNDI suivantes sont requises pour permettre au service d’administration de gérer la configuration du parc de serveurs.

Plusieurs composants d’administration peuvent être déployés pour permettre à la même machine virtuelle Java de s’exécuter sur des composants d’administration distincts qui gèrent différents environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier les valeurs suivantes :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété JNDI mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère l’environnement d’exécution.

Topologie de collectivité Liberty

Vous pouvez déployer les composants MobileFirst Server dans une topologie de collectivité Liberty.

Dans la topologie de collectivité Liberty, les composants d’administration de MobileFirst Server (MobileFirst Operations Console, le service d’administration et le service Live Update) sont déployés dans un contrôleur de collectivité et les environnements d’exécution de Mobile Foundation dans un membre de collectivité. Cette topologie prend en charge uniquement le déploiement asymétrique, les environnements d’exécution ne peuvent pas être déployés dans un contrôleur de collectivité.

Le déploiement de cette topologie possède les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés dans un ou plusieurs contrôleurs de la collectivité. Chaque instance de * * MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Un ou plusieurs environnements d’exécution peuvent être déployés dans les membres de cluster de la collectivité.
• Une application MobileFirst Operations Console gère plusieurs environnements d’exécution qui sont déployés dans les membres de cluster de la collectivité.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution.

Configuration des propriétés JNDI

Les tableaux ci-après répertorient les propriétés JNDI requises pour activer la communication JMX entre le service d’administration et l’environnement d’exécution et pour définir le service d’administration qui gère un environnement d’exécution. Pour plus d’informations sur ces propriétés, voir List of JNDI properties for MobileFirst Server administration service and Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst. Pour savoir comment installer manuellement une collectivité Liberty, voir Installation manuelle sur une collectivité Liberty de WebSphere Application Server.

Les propriétés JNDI globales suivantes sont requises pour les services d’administration :

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

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

Plusieurs composants d’administration peuvent être déployés pour permettre au contrôleur d’exécuter des composants d’administration distincts qui gèrent différents environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier sur chaque service d’administration une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.

Les propriétés JNDI globales suivantes sont requises pour les environnements d’exécution :

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

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

La propriété JNDI suivante est requise pour l’environnement d’exécution lorsque plusieurs contrôleurs (répliques) utilisant les mêmes composants d’administration sont utilisés :

Lorsque plusieurs composants d’administration sont déployés dans le contrôleur, la valeur de la propriété JNDI mfp.admin.environmentid locale de chaque environnement d’exécution doit être identique à celle définie pour le service d’administration qui gère l’environnement d’exécution.

Topologies WebSphere Application Server Network Deployment

Les composants d’administration et les environnements d’exécution sont déployés dans des serveurs ou des clusters de la cellule WebSphere Application Server Network Deployment.

Les exemples de ces topologies prennent en charge le déploiement symétrique et/ou le déploiement asymétrique. Vous pouvez, par exemple, déployer les composants d’administration (MobileFirst Operations Console, le service d’administration et le service Live Update) dans un cluster et les environnements d’exécution gérés par ces composants dans un autre cluster.

Déploiement symétrique dans le même serveur ou cluster

Le diagramme ci-après illustre un déploiement symétrique dans lequel les environnements d’exécution et les composants d’administration sont déployés dans le même serveur ou cluster.

Le déploiement de cette topologie possède les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés dans un ou plusieurs serveurs ou clusters de la cellule. Chaque instance de * MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Un ou plusieurs environnements d’exécution peuvent être déployés dans le même serveur ou cluster que les composants d’administration qui les gèrent.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution.

Déploiement asymétrique avec des environnements d’exécution et des services d’administration dans un serveur ou un cluster différent

Le diagramme ci-après illustre une topologie dans laquelle les environnements d’exécution sont déployés dans un serveur ou un cluster différent de celui des services d’administration.

Le déploiement de cette topologie possède les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés dans un ou plusieurs serveurs ou clusters de la cellule. Chaque instance de * MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Un ou plusieurs environnements d’exécution peuvent être déployés dans d’autres serveurs ou clusters de la cellule.
• Une application MobileFirst Operations Console gère plusieurs environnements d’exécution déployés dans les autres serveurs ou clusters de la cellule.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution.

Cette topologie présente des avantages, car elle permet d’isoler les environnements d’exécution des composants d’administration et des autres environnements d’exécution. Elle peut être utilisée pour fournir un isolement des performances, isoler les applications vitales et appliquer un accord sur les niveaux de licence.

Déploiement symétrique et asymétrique

Le diagramme ci-après illustre un exemple de déploiement symétrique dans Cluster1 et un exemple de déploiement asymétrique dans Cluster2, où Runtime2 et Runtime3 sont déployés dans un cluster différent de celui des composants d’administration. MobileFirst Operations Console gère les environnements d’exécution déployés dans Cluster1 et Cluster2.

Le déploiement de cette topologie possède les caractéristiques suivantes :

• Un ou plusieurs composants d’administration peuvent être déployés dans un ou plusieurs serveurs ou clusters de la cellule. Chaque instance de MobileFirst Operations Console communique avec un service d’administration et un service Live Update.
• Un ou plusieurs environnements d’exécution peuvent être déployés dans un ou plusieurs serveurs ou clusters de la cellule.
• Une application MobileFirst Operations Console peut gérer plusieurs environnements d’exécution déployés dans les mêmes ou dans d’autres serveurs ou clusters de la cellule.
• Un environnement d’exécution est géré par une seule application MobileFirst Operations Console.
• Chaque service d’administration utilise son propre schéma de base de données d’administration.
• Chaque service Live Update utilise son propre schéma de base de données Live Update.
• Chaque environnement d’exécution utilise son propre schéma de base de données d’environnement d’exécution.

Configuration des propriétés JNDI

Certaines propriétés JNDI sont requises pour activer la communication JMX entre le service d’administration et l’environnement d’exécution et pour définir le service d’administration qui gère un environnement d’exécution. Pour plus d’informations sur ces propriétés, voirListe des propriétés JNDI pour le service d’administration de MobileFirst Server et Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst.

Les propriétés JNDI locales suivantes sont requises pour les services d’administration et les environnements d’exécution :

Plusieurs composants d’administration peuvent être déployés pour vous permettre d’exécuter le même serveur ou cluster avec des composants d’administration distincts qui gèrent chacun des environnements d’exécution.

Lorsque vous déployez plusieurs composants d’administration, vous devez spécifier :

• Sur chaque service d’administration, une valeur unique pour la propriété JNDI mfp.admin.environmentid locale.
• Sur chaque environnement d’exécution, la même valeur pour la propriété mfp.admin.environmentid locale que celle définie pour le service d’administration qui gère cet environnement d’exécution.

Si l’hôte virtuel qui est mappé à une application de service d’administration ne correspond pas à l’hôte par défaut, vous devez définir les propriétés suivantes sur l’application de service d’administration :

• mfp.admin.jmx.user : Nom d’utilisateur de l’administrateur de WebSphere Application Server
• mfp.admin.jmx.pwd : Mot de passe de l’administrateur de WebSphere Application Server

Utilisation d’un proxy inverse avec des topologies de parc de serveurs et WebSphere Application Server Network Deployment

Vous pouvez utiliser un proxy inverse avec des topologies réparties. Si votre topologie utilise un proxy inverse, configurez les propriétés JNDI requises pour le service d’administration.

Vous pouvez utiliser un proxy inverse, par exemple, IBM HTTP Server, avec des topologies de parc de serveurs frontaux ou WebSphere Application Server Network Deployment. Dans ce cas, vous devez configurer les composants d’administration de manière appropriée.

Vous pouvez appeler le proxy inverse à partir :

• du navigateur lorsque vous accédez à MobileFirst Operations Console ;
• de l’environnement d’exécution lorsqu’il appelle le service d’administration ;
• du composant MobileFirst Operations Console lorsqu’il appelle le service d’administration.

Si le proxy inverse est dans une zone démilitarisée (configuration de pare-feu permettant de sécuriser les réseaux locaux) et un pare-feu est utilisé entre la zone démilitarisée et le réseau interne, ce pare-feu doit autoriser toutes les demandes entrantes issues des serveurs d’applications.

Lorsqu’un proxy inverse est utilisé devant l’infrastructure de serveur d’applications, les propriétés JNDI suivantes doivent être définies pour le service d’administration :

La propriété mfp.admin.endpoint qui fait référence à l’URL du proxy inverse est également requise pour MobileFirst Operations Console.

Contraintes sur le service push de MobileFirst Server

Le service push peut figurer sur le même serveur d’applications que le service d’administration ou l’environnement d’exécution, ou sur un autre serveur d’applications. L’URL utilisée par les applications client pour contacter le service push est identique à celle utilisée par les applications client pour contacter l’environnement d’exécution, à ceci près que la racine de contexte de l’environnement d’exécution est remplacée par imfpush. Si vous souhaitez installer le service push sur un autre serveur que celui de l’environnement d’exécution, votre serveur HTTP doit acheminer le trafic vers la racine de contexte /imfpush sur un serveur où le service push s’exécute.

Pour plus d’informations sur les propriétés JNDI requises pour adapter l’installation à une topologie, voir Communication entre le service d’administration de MobileFirst Server et le service push de MobileFirst Server et le serveur d’autorisations. Le service push doit être installé avec la racine de contexte /imfpush.

Plusieurs environnements d’exécution de Mobile Foundation

Vous pouvez installer plusieurs environnements d’exécution. Chaque environnement d’exécution doit avoir sa propre racine de contexte et tous ces environnements d’exécution sont gérés par le même service d’administration de MobileFirst Server et la même application MobileFirst Operations Console.

Les contraintes décrites dans Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de Mobile Foundation s’appliquent. Chaque environnement d’exécution (avec sa racine de contexte) doit avoir ses propres tables de base de données.

Pour obtenir des instructions, voir Configuration de plusieurs environnements d’exécution.

Plusieurs instances de MobileFirst Server sur le même serveur ou la même cellule WebSphere Application Server

La définition d’un ID d’environnement commun permet d’installer plusieurs instances de MobileFirst Server sur le même serveur.

Vous pouvez installer plusieurs instances de service d’administration de MobileFirst Server, de service Live Update deMobileFirst Server et d’environnement d’exécution de Mobile Foundation sur le même serveur d’applications ou la même cellule WebSphere Application Server. Toutefois, vous devez distinguer leurs installations à l’aide de la variable JNDI mfp.admin.environmentid, qui est une variable du service d’administration et de l’environnement d’exécution. Le service d’administration ne gère que les environnements d’exécution possédant le même identificateur d’environnement. Par conséquent, seuls les composants d’environnement d’exécution et le service d’administration ayant la même valeur pour la propriété mfp.admin.environmentid sont considérés comme faisant partie de la même installation.