"Tiles on the Cloud" (2/3)
Comme nous l'avons évoqué dans l'article précédent, l'externalisation des caches ArcGIS Server est une solution qui peut conduire à une réduction des coûts d'hébergement (espaces de stockage et de sauvegarde) et de mise à disposition (bande passante). Au-delà de ces considérations économiques, l'externalisation de ses caches peut également présenter un intérêt technique.
Si l'on considère une application web SIG dans laquelle on utilise à la fois des services cachés (pour le fond de carte) et des services dynamiques (pour les couches métiers), il y aura un gain de performance à séparer les serveurs. Même si la diffusion de services cachés est peu consommateur de mémoire et de CPU, c'est la gestion de la file d'attente des requêtes coté client (navigateur) qui peut être source de latence dans l'affichage complet de la carte. En effet, par défaut, un navigateur ne sait pas envoyer plus de 2 requêtes simultanées (en HTTP 1.1) à un même serveur. Ainsi l'utilisation d'un serveur différent pour les caches permet de mieux paralléliser ces requêtes et ainsi gagner du temps sur l'affichage global de la carte. Ceux qui utilisent des services ArcGIS Online ou Cartosphère constatent ce gain de temps.
Spécialiser ses serveurs ArcGIS Server
La première solution consiste, tout simplement, à mettre en ligne plusieurs serveurs ArcGIS Server afin de pouvoir en dédier certains au calcul, à l'hébergement et à la diffusion des services cachés. Pour mieux répartir l'usage des ressources de chaque serveur, une alternative intéressante peut consister à faire un mixte entre services cachés et services dynamiques sur chaque serveur. Dans ce dernier cas, le risque est de se retrouver, pour certaines applications, avec l'ensemble des servies nécessaires situés sur le même serveur.
Déporter ses caches sur un simple serveur web
La deuxième solution consiste à entreposer ses caches sur un serveur dédié à l'intérieur ou à l'extérieur de votre organisation. Le serveur, qui ne dispose pas d'ArcGIS Server, publie alors une arborescence de fichiers (les tuiles du cache) qui auront été préalablement calculés à partir d'un serveur ArcGIS Server de votre organisation. L'application cliente consomme alors directement les fichiers du cache via ce serveur web.
Cette solution offre l'avantage de ne pas utiliser une licence ArcGIS Server pour la diffusion du caches mais en revanche elle nécessite de pouvoir s'affranchir de certaines contraintes. Tout d'abord, les caches qui sont mis en ligne doivent être calculés puis par la suite mis à jour à partir d'un service ArcGIS Server. Même si ces opérations sont ponctuelles, il faut prévoir cette ressource ArcGIS Server dans l'architecture de votre organisation. Ensuite, le fait de travailler avec un cache "mort" (sans service de carte associé) ne vous permettra pas de disposer de fonctions d'interrogation ou de sélection sur les entités de votre fond de carte. Enfin, même pour les services de cache, les API web d'ArcGIS Server (Flex, JavaScript et Silverlight) ont besoin de communiquer avec le service ArcGIS Server correspondant. En câblant votre application sur un cache "mort", vous devrez réaliser un développement spécifique (mais relativement simple) dans l'application cliente, afin de modifier à la volée les requêtes sur les tuiles.
Techniquement cette externalisation des caches est donc possible et opérationnelle aujourd'hui. Un exemple intéressant est probablement celui de la société américaine Roktech partenaire d'ESRI Inc. Cette société propose un système d'hébergement de caches basé sur ces principes en utilisant la plateforme Amazon S3 pour le stockage des fichiers. Si le sujet vous intéresse, je vous recommande la lecture de cet article issu du dernier numéro d'ArcUser qui relate un cas d'application et explique l'architecture proposée.
Pour que tout cela soit plus concret, je détaillerai dans un dernier article, un exemple simple d'application Flex exploitant des caches stockés sur Amazon S3.
0 comments :
Enregistrer un commentaire