A propos de l'extension de services

Vous pouvez étendre les services d'imagerie et de carte ArcGIS Server (notamment des extensions de services d'imagerie et de carte, telles que les services d'entités) à l'aide d'une logique personnalisée qui peut s'exécuter sur des clients ArcGIS. Vous pouvez étendre ces types de services de deux façons :

• Extensions d'objet serveur (SOE) : vous permettent de créer de nouvelles opérations de service afin d'étendre les fonctionnalités de base des services d'imagerie ou de carte. Les SOE sont appropriés si vous devez exécuter une logique métier bien définie ne pouvant pas facilement être accomplie à l'aide des API clientes d'ArcGIS. La plupart des SOE utilisent du code ArcObjects pour travailler avec les données et cartes SIG. Les objets ArcObjects sont les composants principaux sur lesquels ArcGIS est conçu. Ils vous permettent d'écrire des fonctions SIG avec la plus grande souplesse.
• Intercepteurs d'objet serveur (SOI) : vous permettent d’intercepter les requêtes pour les opérations intégrées existantes des services d'imagerie ou de carte. Vous pouvez ainsi exécuter une logique personnalisée et modifier le comportement de ces services en remplaçant les opérations existantes d'une manière transparente pour les clients existants. Ces clients peuvent être des applications intégrées à ArcGIS API for Javascript, ArcGIS Runtime SDK, etc.

Les sections suivantes décrivent chaque type plus en détail.

Extensions d'objets serveur (SOE)

Les extensions d'objet serveur (SOE) sont appropriées si vous souhaitez créer de nouvelles opérations de service afin d'étendre les fonctionnalités de base des services d'imagerie et de carte (notamment les extensions de services d'imagerie et de carte, telles que les services d'entités). Les SOE offrent les avantages suivants :

• Vous pouvez proposer une extension d'objet serveur (SOE) en tant que service Web REST (Representational State Transfer) et/ou SOAP (Simple Object Access Protocol), ce qui permet aux clients personnalisés créés sur les API clientes d'ArcGIS et tout autre client REST ou SOAP de les invoquer facilement. En fait, vos SOE REST s'affichent dans le répertoire des services ArcGIS et peuvent proposer les types d'objet courants que les API clientes d'ArcGIS comprennent, principalement au format JSON.
• Lorsque vous créez une extension d'objet serveur, vous fournissez des méthodes grossières qui exécutent des tâches sur ArcGIS Server, plutôt que de passer un grand nombre d'appels depuis le client vers le serveur. Les SOE encapsulent très efficacement la logique ArcObjects, ce qui fournit un environnement idéal à l'exécution rapide de vos appels.

Vous pouvez développer une extension d'objet serveur pour présenter des fonctionnalités ArcObjects non disponibles autrement ou devant être exécutées très rapidement. Les SOE sont destinées aux développeurs expérimentés et requièrent une connaissance de plusieurs plates-formes de développement. ArcObjects SDKs pour Java et Microsoft .NET Framework contiennent plusieurs exemples de SOE que vous pouvez examiner.

Avez-vous besoin d'une extension d'objet serveur ?

Les SOE requièrent la connaissance du développement Web, d'ArcObjects et des langages de programmation, tels que Java ou d'un langage de type .NET, tel que C#. Ils doivent également passer par un processus de déploiement pour être mis à disposition sur votre serveur. Avant de développer une extension d'objet serveur, envisagez de choisir d'autres options plus simples.

L'alternative la plus simple au développement d'une extension d'objet serveur peut consister à créer un modèle de géotraitement exécutant votre logique métier et à le publier en tant que service. Vous pouvez utiliser ModelBuilder pour glisser-déplacer et connecter les outils nécessaires de manière interactive plutôt que d'écrire du code ArcObjects. Les services de géotraitement vous permettent également de procéder à une exécution asynchrone. Vous pouvez alors lancer une tâche, passer à autre chose et y revenir plus tard pour vérifier les résultats.

L'un des inconvénients des services de géotraitement réside dans leur impact relativement important sur la mémoire. De plus ils peuvent s'exécuter plus lentement que les extensions d'objet serveur. Si vous n'exécutez un processus que quelques fois par jour, cela ne pose pas de problème. En revanche, si vous exécutez un processus de nombreuses fois par jour, ou si beaucoup d'utilisateurs l'exécutent simultanément, il peut valoir la peine de prendre le temps de créer une extension d'objet serveur.

De nombreux développeurs ont écrit du code ArcObjects pour différentes tâches qui sont désormais accessibles sans ArcObjects. Pour en savoir plus sur la résolution de problèmes de cartographie Web sans recours à l'utilisation d'ArcObjects, reportez-vous à la rubrique Alternatives aux extensions d'objet serveur.

Intercepteurs d'objet serveur (SOI)

Les SOI sont appropriés si vous cherchez à modifier le comportement des opérations de services de carte ou d'imagerie existants (notamment des extensions de services d'imagerie et de carte, telles que des opérations de service d'entités). Vous pouvez par exemple modifier le comportement d'une requête ou d'une demande d'exportation d'images cartographiques. Voici ce qui est notamment possible de réaliser avec un SOI :

• Ajouter un filigrane sur toutes les images cartographiques
• Assurer une sécurité au niveau des couches
• Autoriser ou interdire l'accès à des opérations spécifiques en fonction du rôle utilisateur

Avez-vous besoin d'un SOI ?

Les SOI requièrent la connaissance du développement Web, d'ArcObjects et des langages de programmation, tels que Java ou d'un langage de type .NET, tel que C#. Ils doivent également passer par un processus de déploiement pour être mis à disposition sur votre serveur. Avant de développer un intercepteur d'objet serveur, demandez-vous si vous avez besoin de cette fonctionnalité.

Si vous souhaitez renforcer votre serveur par de nouvelles fonctions, vous pouvez utiliser un SOE ou des modèles de géotraitement et des scripts. Les SOI conviennent pour ajouter de nouvelles fonctionnalités ou un nouveau comportement aux opérations ArcGIS Server existantes d'une manière transparente pour les applications clientes existantes.

Si vous souhaitez accomplir une ou plusieurs tâches à l'aide d'une série d'extensions, vous pouvez utiliser les intercepteurs d'objet serveur (SOI). Plusieurs SOI peuvent être enchaînés sur un ou plusieurs services. Vous pouvez à tout moment modifier la liste des SOI et leur ordre d'exécution dans la chaîne.

Vous pouvez choisir de créer un ou plusieurs SOI si vous devez implémenter une logique métier personnalisée, par exemple pour répondre à des critères de sécurité ou d'audit que le service d'imagerie ou de carte par défaut ne remplit pas. Par exemple :

• Incluez un filigrane sur toutes les images cartographiques créées par le serveur. Une série de SOI peut être créée pour surimposer un filigrane personnalisé sur des images cartographiques créées par le serveur. Cela permet aux organisations ou aux sociétés d'hébergement d'assurer une personnalisation correcte sur toutes les images.
• Audit et consignation de toutes les requêtes : à des fins de débogage, vous pouvez créer une série de SOI qui consigne des informations détaillées sur les requêtes entrantes, telles que des informations complètes sur les paramètres en entrée et les informations d'identification utilisateur transmises avec la requête.
• Réponses de post-traitement : des informations complémentaires issues de systèmes métier distincts non pris en charge par ArcGIS Server peuvent être ajoutées aux réponses sortantes afin de joindre des données spatiales à d'autres types de données Business Intelligence.
• Contrôle d'accès au niveau des opérations pour les services de carte : ArcGIS Server prend uniquement en charge l'activation des opérations de service pour tous les utilisateurs du service ou la désactivation complète de l'accès. Une série de SOI peut filtrer les requêtes entrantes en fonction du rôle de l'utilisateur afin d'implémenter l'accès au niveau des opérations dans le service.
• Contrôle d'accès au niveau des couches pour les services de carte : ArcGIS Server prend uniquement en charge l'accès aux données au niveau des services ; soit l'utilisateur bénéficie d'un accès complet à toutes les données des services, soit l'utilisateur n'a aucun accès. Une série de SOI peut être implémentée pour filtrer l'accès à des couches spécifiques ou même filtrer des données au sein d'une couche en fonction du rôle de l'utilisateur.

Précisions à connaître pour le développement d'une extension

Le développement d'une extension nécessite la connaissance de l'utilisation d'ArcObjects via des langages de programmation Java ou .NET. Cela nécessite également de comprendre les principes REST ou SOAP. Les extensions développées avec Java peuvent être déployées sur ArcGIS for Server (Windows) et ArcGIS for Server (Linux). Les extensions développées avec .NET peuvent uniquement être déployées sur ArcGIS for Server (Windows).

Une extension peut uniquement être développée pour un type de service en particulier : un service d'imagerie ou de carte. Par exemple, vous ne pouvez pas développer une extension générique qui fonctionne à la fois avec un service d'imagerie et de carte. Dans ce cas, vous devez développer des extensions individuelles pour chaque type de service : une pour un service de carte et l'autre pour un service d'imagerie.

En outre, si vous souhaitez écrire des pages de propriétés personnalisées pour vos extensions en plus des pages générées automatiquement, vous devez connaître le développement Windows Forms, Java Swing (pour les pages ArcCatalog) ou le développement de formulaires Web en HTML (Hypertext Markup Language) et JavaScript (pour les pages du gestionnaire).