arcOrama: Le blog consacré à ArcGIS et aux technologies Esri

Le blog francophone consacré
aux technologies Esri

"Tiles on the Cloud" (3/3)

Dans ce troisième et dernier article je souhaitais illustrer l'externalisation de caches au travers d'un exemple simple et concret. L'objectif est de déployer une application (ici en Flex) superposant un fond de carte (service caché) et des équipements liés à l'activité touristique (service dynamique).

Dans cet exemple, on a décidé d'externaliser le stockage du cache en dehors de l'infrastructure du serveur d'arcOrama. Pour cela on a choisi de stocker les fichiers de ce cache sur la plateforme Amazon S3 mais la démarche serait exactement la même pour n'importe quel autre serveur.

Je décris donc ci-dessous la démarche permettant de réaliser cette application:

1. Publication du service de carte dynamique contenant les équipements touristiques

Créer un premier document ArcMap
Ajouter les couches contenant les équipements touristiques
Toujours dans ArcMap, utiliser la barre d'outils de publication de service afin de créer un service de carte optimisé (depuis la version 9.3.1 d'ArcGIS)

2. Création du cache du fond de carte

Créer un deuxième document ArcMap
Ajouter les couches constituant le fond de carte
Toujours dans ArcMap, utiliser la barre d'outils de publication de service afin de créer un service de carte optimisé (depuis la version 9.3.1 d'ArcGIS)
A partir d'ArcCatalog, spécifier les paramètres du cache (échelles, taille et format des tuiles, …) dans les propriétés du service de carte
Lancer la création du cache

3. Copier le cache sur la plateforme Amazon S3

Créer votre compte sur Amazon S3
Installer un outil de gestion de fichiers pour Amazon S3, par exemple Bucket Explorer ou S3Fox Organizer
A l'aide de cet outil, copier l'ensemble de l'arborescence de votre cache
Vous penserez ensuite à bien spécifier les autorisations (ACL) sur l'ensemble des fichiers pour s'assurer que les tuiles seront accessibles à tous les utilisateurs
Vous penserez également à copier les fichiers crossdomain.xml ou clientaccesspolicy.xml à la racine de votre Bucket si vous utilisez des applications clientes Flex ou Silverlight
Vous pouvez vérifier que vos tuiles sont accessibles en saisissant l'URL d'une tuile comme celle-ci.

4. Développer l'application cliente

Créer le projet Flex puis ajouter le contrôle Map
Développer le connecteur permettant d'accéder au cache.
Dans cet exemple, nous avons choisi de créer une application Flex. Pour pouvoir accéder directement aux tuiles du cache sans utiliser le mécanisme standard de l'API Flex ArcGIS, un développement spécifique est nécessaire. En particulier, vous devez développer une classe étendant la classe ArcGISTiledMapServiceLayer qui prendra en charge l'accès aux tuiles copiées sur Amazon S3. Pour plus d'informations, reportez-vous au fichier S3ArcGISTiledMapServiceLayer.as du code source de l'application.
Dans la fonction clé de cette classe est la fonction getTileURL puisqu'elle prend en charge la récupération de l'URL des tuiles. Vous penserez à bien spécifier la structure de base des URL en fonction de votre arborescence de fichier dans Amazon S3.
- Ajouter ensuite les références au service dynamique (ArcGISDynamicMapServiceLayer) et au nouveau type de service (S3ArcGISTiledMapServiceLayer) dans le fichier MXML de votre application.
L'application peut maintenant est exécutée.

Conclusion

Au travers de ces trois articles j'ai montré qu'une application web ArcGIS Server peut facilement tirer profit d'une architecture de type "Cloud". Dans mon modeste exemple, l'objectif était simplement d'optimiser la gestion et la performance d'affichage des caches en l'externalisant sur une plateforme de Cloud Computing. Bien entendu, on peut aller plus loin dans l'intégration de ce type de plateforme avec les technologies ArcGIS. C'est une tendance lourde qui s'affirme et qui sera un des axes de développement de la plateforme ArcGIS dans les prochaines années. Nous aurons l'occasion d'en reparler…

"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.

Ouverture du code source du Template Flex Cadastre

"Tiles on the Cloud" (1/3)

Plus rapides, plus légères et plus ergonomiques, depuis quelques années maintenant, les applications SIG sont entrées, elles aussi, dans l'ère du Web 2.0. Plusieurs améliorations technologiques ont permis cette évolution : l'augmentation des bandes passantes, la maturité des mécanismes Ajax, l'émergence d'interfaces plus accessibles sur les services web favorisant la construction de mashups (approche Restful par exemple) ou encore la démocratisation des technologies RIA (framework JavaScripts, Flex/Flash, Silverlight, …).

Un autre point technique qui a contribué à l'amélioration de l'expérience utilisateur dans les applications web SIG, c'est l'utilisation de plus en plus systématique de caches de cartes. J'en ai souvent parlé sur ce blog, depuis plusieurs années, on peut facilement gérer ce type de caches avec ArcGIS Server. Le principe est simple, les différents niveaux d'échelles de la carte sont précalculées et découpées en tuiles pour être ensuite stockées sur le serveur et délivrées à différentes applications clientes via le Web. Ceci permet de s'affranchir du calcul dynamique de la carte et des requêtes vers la base de données à chaque demande de carte de l'application cliente. Ceci réduit alors de manière significative le temps d'affichage de la carte mais également la consommation de ressources de votre serveur (CPU, mémoire, bande passante, …).

Aujourd'hui les techniques liées à la création et à la gestion des caches sont largement mises en œuvre et maîtrisées par la plupart des concepteurs d'applications ArcGIS Server. Les interrogations se portent désormais sur l'architecture et l'infrastructure à mettre en place pour optimiser ses coûts de déploiement et de montée en charge. En particulier lorsque l'on parle d'applications web s'adressant à un large public, la question de la disponibilité des serveurs, de la bande passante ou encore des espaces de stockage se transforme en véritables enjeux financiers. La question de l'externalisation complète ou partielle de ses caches est plus que jamais d'actualité.

Au travers de deux articles complémentaires, je reviendrai dans les prochains jours sur cette question en essayant (comme souvent dans arcOrama) d'être pragmatique et d'illustrer mes propos à l'aide d'un exemple concret d'application.