Alternatives aux extensions d'objet serveur

Parfois, la richesse d'ArcObjects et le défi que représente le codage d'un service Web peut rendre les extensions d'objet serveur (SOE) difficiles à utiliser pour les débutants. Cette rubrique aborde certaines tâches SIG Web courantes pour lesquelles les développeurs rédigent habituellement du code ArcObjects et fournit des approches alternatives ne requérant pas la rédaction d'un SOE ni de connaître le fonctionnement d'ArcObjects.

Création de mises en page pour l'impression

De nombreux développeurs utilisent ArcObjects pour accéder à l'objet de mise en page du service de carte, plus spécifiquement pour intégrer une fonctionnalité d'impression haute qualité dans leurs applications Web. Ils utilisent ArcObjects pour travailler avec des cartes de qualité, par exemple dans ArcMap, ainsi qu'avec leurs éléments environnants, pour générer des documents imprimables en grand format, et ainsi de suite.

ArcGIS 10.0 contient le module Python arcpy.mapping que vous pouvez utiliser pour générer les scripts de mise en page et d'impression de carte. Vous pouvez ensuite publier le script via un service de géotraitement. Avec arcpy.mapping, vous pouvez manipuler des documents ArcMap à un degré très élevé : vous pouvez ajouter des couches de manière dynamique à la carte, mettre à jour leur symbologie, etc. Vous pouvez également accéder à la mise en page de la carte, en manipulant des éléments tels que le texte et les images.

Dans ArcGIS 10.1, les fonctionnalités arcpy.mapping ont été améliorées. Plus précisément, il est devenu plus facile de charger dynamiquement le contenu d'une application de cartographie Web (y compris les services de carte et graphiques) dans un document ArcMap à l'aide d'arcpy.mapping.

Modification des symboles et moteurs de rendu

Les développeurs utilisent également ArcObjects pour modifier la symbologie d'une couche particulière dans un service de carte. Ce workflow requiert souvent l'utilisation de services non groupés, ce qui limite l'évolutivité des applications. Certains développeurs réussissent à créer des applications avec des services groupés, même si le basculement incessant de l'état d'un service pour répondre aux requêtes de différents utilisateurs entraîne souvent de faibles performances et oblige le développeur à maintenir l'intégrité de l'instance de carte elle-même.

Les API Web ArcGIS vous permettent de symboliser facilement les entités à l'aide d'une couche d'entités ou de graphiques côté client, dont les propriétés de rendu peuvent être modifiées à tout moment. Voici en quoi cela consiste : la géométrie et les attributs des entités visibles sont tous téléchargés sur le client. Il est donc facile pour ce dernier d'afficher les entités dans n'importe quelle couleur, largeur ou avec n'importe quelle borne de classes définie par le développeur de l'application.

La technique des couches d'entités est particulièrement efficace pour la cartographie thématique, l'interaction avec les entités et leur mise en surbrillance, etc., mais elle est parfois insuffisante lorsque vous utilisez des milliers d'entités ou des entités surfaciques très complexes. Dans ce cas, la meilleure approche consiste à demander des modifications de symbologie au niveau du service et à rendre le service de carte responsable du rendu de l'image de carte. Avant, cette opération requérait l'utilisation d'ArcObjects.

ArcGIS 10.1 a amélioré le service de carte pour vous permettre de modifier le contenu et la symbologie de la carte au moment de l'exécution (comme vous le feriez avec ArcIMS). L'utilisation de services non groupés et d'objets ArcObjects détaillés n'est plus requise pour modifier la symbologie des couches de votre service de carte. A la place, vous pouvez décider, à la demande, du contenu ou de la symbologie à utiliser dans la carte que vous souhaitez créer.

Cette amélioration peut rendre vos applications considérablement plus évolutives, tout en simplifiant leur développement et leur maintenance. La définition de la symbologie des couches de votre service de carte au moment de l'exécution s'effectue via l'inclusion d'informations du moteur de rendu dans la requête d'affichage de carte de votre service Web, ainsi que les informations types de visibilité des couches, d'étendue, etc. Les versions 3.0 des API Web ArcGIS incluent des classes utilitaires vous permettant de définir facilement du contenu, des moteurs de rendu, des bornes de classes, une symbologie, etc.

Pour en savoir plus sur la modification rapide du contenu et de la symbologie d'un service de carte, reportez-vous à la rubrique A propos des couches dynamiques.

Mise à jour Web

Dans les premières versions d'ArcGIS Server, la modification des données sur le Web pouvait uniquement être effectuée via du code personnalisé ArcObjects utilisant des connexions locales (DCOM). Dans la version 9.2, une tâche Editeur incluse dans Web ADF permet d'effectuer des modifications de base, par exemple la création, le déplacement et la suppression d'entités. Toute personnalisation de cette tâche ou la création intégrale d'outils de mise à jour requiert encore l'exécution de tâches de programmation ArcObjects importantes.

Les API REST ne permettent pas, à l'origine, de publier des mises à jour Web. Cependant, avec l'introduction du service d'entités dans ArcGIS 10, les mises à jour sont désormais possibles via ces API. Non seulement, les mises à jour sont possibles via les API REST, mais elles sont pratiques à personnaliser car de nombreuses méthodes de mise à jour (couper, tronquer, remplir automatiquement les polygones et redessiner) sont proposées via l'implémentation REST du service de géométrie. Enfin, lorsque vous effectuez des mises à jour à l'aide d'API REST, vous pouvez utiliser des services groupés. Cela représente un véritable avantage en termes de performances.

La prise en charge d'un workflow a toutefois été interrompue dans ArcGIS 10.1 : les transactions longues. Avec Web ADF, vous pouviez utiliser des services non groupés pour effectuer des modifications suivant un modèle de transaction longue. En substance, vous pouviez commencer à mettre à jour les entités et annuler les modifications à tout moment. Avec le service d'entités, toutes les opérations sont sans état, ce qui signifie que vous ne pouvez pas annuler d'opérations au niveau de la base de données (mais vous pourriez le faire si votre application contenait une logique métier). Le modèle de transaction longue pour les mises à jour Web représente l'un des quelques workflows pour lesquels la nouvelle architecture de serveur d'ArcGIS 10.1 ne propose aucune autre alternative.

Il est important de souligner que la non prise en charge des transactions longues ne vous empêche pas d'implémenter des opérations d'annulation/répétition. D'ailleurs, dans les API de cartographie Web ArcGIS, les opérations d'annulation/répétition peuvent être exécutées directement à partir de l'API au niveau de l'application.

Les services non groupés vous permettent d'utiliser une autre fonctionnalité unique : la possibilité de changer de version pendant la mise à jour. Par exemple, cela permet aux utilisateurs Web de stocker leurs modifications dans différentes versions pouvant être réconciliées ultérieurement à partir d'ArcGIS for Desktop. ArcGIS 10.1 a amélioré les services d'entités afin que vous puissiez choisir efficacement une version de vos mises à jour au moment de l'exécution, à partir de n'importe quelle application Web.

Exécution de la logique métier avec le géotraitement

Certaines applications SIG utilisent une série spécifique d'outils pour exécuter une logique métier SIG avancée. Ces outils peuvent prévoir le rendement en bois d'une forêt, identifier des sites appropriés pour un restaurant ou évaluer la dispersion d'un nuage toxique. De nombreux développeurs utilisent ArcObjects pour cela.

Dans nombre de cas, ces processus peuvent être exprimés dans ArcGIS ModelBuilder, où vous pouvez "chaîner" graphiquement les outils ensemble. Ces modèles de géotraitement peuvent être publiés en tant que services Web et utilisés à partir de vos applications Web. Les avantages qui en découlent sont évidents : l'utilisation d'un service de géotraitement peut vous éviter d'avoir à effectuer un codage trop important. De même, vous pouvez tirer parti de l'exécution asynchrone de services de géotraitement, qui est difficile à atteindre en rédigeant votre propre code ArcObjects.

Exceptée la souplesse que représentent les centaines d'outils prêts à l'emploi que vous pouvez combiner dans ModelBuilder, le géotraitement vous donne la possibilité de développer des outils personnalisés. Le moyen le plus simple d'y parvenir consiste à créer des scripts Python pouvant s'exécuter seuls ou en association avec d'autres outils dans un modèle. Cette rubrique en contient déjà un exemple cité plus haut : l'utilisation d'arcpy.mapping pour la création de cartes haute qualité sur le Web.

Pour davantage de contrôle encore, vous pouvez créer un outil de géotraitement personnalisé non pas avec Python mais avec C#, Visual Basic .NET, C++ ou Java. Cela vous permet d'intégrer votre propre logique d'objets ArcObjects détaillés dans vos modèles.

Que vous utilisiez Python ou un autre langage, l'avantage de la création d'outils personnalisés réside dans la possibilité de les réutiliser dans des workflows différents, puisqu'ils se comportent comme tout autre outil prêt à l'emploi. En outre, votre code ArcObjects ou Python peut s'exécuter dans le modèle d'exécution asynchrone des services de géotraitement, ce qui est assez pratique pour les processus de longue durée.

Exécution de calculs géométriques

Les services de géotraitement sont utiles. Mais de la même façon qu'il ne faut pas se précipiter dans le développement d'objets ArcObjects lorsque cela peut facilement être effectué grâce au géotraitement, il est recommandé d'éviter de se lancer dans le géotraitement si des services prêts à l'emploi peuvent faire l'affaire. Vérifiez si le service de géométrie SOAP ou REST propose les méthodes qui vous intéressent. Un service de géométrie peut effectuer des opérations SIG basiques telles que la mise en mémoire tampon, la détermination de relations spatiales et la mesure des longueurs et des surfaces. Faire appel à une série de méthodes dans un service de géométrie et combiner cette opération avec les fonctionnalités de requête des services de carte et la logique côté client peut s'avérer plus simple et plus rapide que l'utilisation d'un service de géotraitement.