Architecture .Net Remoting

L'infrastructure .NET Remoting est une approche abstraite de la communication entre processus. L'essentiel du système fonctionne discrètement. Par exemple, les objets qui peuvent être passés par valeur, ou copiés sont automatiquement passés entre des applications dans différents domaines d'application ou sur des ordinateurs différents. Pour un bon fonctionnement, il vous faut seulement marquer vos classes personnalisées comme sérialisables.

Cependant, ce qui fait la vraie force du système d'accès distant c'est sa possibilité d'activer une communication entre des objets de domaines d'application différents ou des processus en utilisant des protocoles de transport différents, des formats de sérialisation, des modèles de durée de vie des objets et des modes de création d'objets. En outre, l'accès distant vous permet d'intervenir à n'importe quelle étape du processus de communication, pour une raison ou une autre.

Que vous ayez implémenté un nombre d'applications distribuées ou que vous souhaitiez simplement déplacer des composants vers d'autres ordinateurs pour accroître l'évolutivité de votre programme, il est plus facile de concevoir le système d'accès distant comme un système générique de communication entre processus équipé d'implémentations qui gèrent la plupart des scénarios. La rubrique suivante commence par les notions de base relatives à la communication entre processus à l'aide de l'accès distant.

Copies ou références

La communication entre processus nécessite un objet serveur dont les fonctionnalités sont fournies aux appelants à l'extérieur de son processus, un client qui effectue des appels sur l'objet serveur, et un mécanisme de transport pour transporter les appels d'un bout à l'autre. Les adresses des méthodes de serveur sont logiques et fonctionnent correctement dans un processus, ce qui n'est pas le cas dans un processus client différent. Pour résoudre ce problème, un client peut appeler un objet serveur en effectuant une copie de l'objet dans sa totalité et en le transférant vers le processus client, où les méthodes de la copie peuvent être appelées directement.

Cependant, un grand nombre d'objets ne peuvent pas ou ne doivent pas être copiés et déplacés dans d'autres processus d'exécution. Les objets extrêmement gros possédant beaucoup de méthodes représentent des mauvais choix pour une copie ou un passage par valeur dans d'autres processus. Généralement, un client n'a besoin que des informations retournées par une seule ou plusieurs des méthodes de l'objet serveur. La copie de l'objet serveur dans sa totalité, y compris tout un ensemble d'informations internes ou de structures exécutables sans rapport avec les besoins du client, représentent une perte de bande passante ainsi qu'une perte de mémoire et de temps de traitement. En outre, un grand nombre d'objets exposent les fonctionnalités publiques, mais nécessitent des données privées pour l'exécution interne. La copie de ces objets pourrait permettre aux clients non autorisés d'examiner les données internes, ce qui pourrait créer des problèmes de sécurité potentiels. Enfin, certains objets utilisent des données qui ne peuvent pas être copiées de manière compréhensible. Un objet FileInfo, par exemple, contient une référence à un fichier de système d'exploitation dont l'adresse unique réside dans la mémoire du processus serveur. Vous pouvez copier cette adresse, mais celle-ci sera incompréhensible dans un autre processus.

Dans ces situations, le processus serveur doit passer, au processus client, une référence à l'objet serveur, plutôt qu'une copie de l'objet. Les clients peuvent utiliser cette référence pour appeler l'objet serveur. Ces appels ne s'exécutent pas dans le processus client. Au contraire, le système d'accès distant collecte toutes les informations relatives à l'appel et les envoie au processus serveur où elles sont interprétées, l'objet serveur correct est localisé et l'appel est effectué vers l'objet serveur au nom de l'objet client. Le résultat de l'appel est ensuite renvoyé au processus client pour être retourné au client. La bande passante est utilisée uniquement pour les informations critiques : l'appel, les arguments d'appel et toutes les valeurs de retour ou exceptions.

Simplification des architectures d'accès distant

L'utilisation des références d'objet pour communiquer entre des objets serveur et des clients représente le cœur même de l'accès distant. Cependant, l'architecture de l'accès distant fournit au programmeur une procédure encore plus simple. Si vous configurez le client correctement, vous ne devez créer qu'une nouvelle instance de l'objet distant à l'aide de new (ou la fonction de création d'instance de votre langage de programmation managée). Votre client reçoit une référence vers l'objet serveur, et vous pouvez ensuite appeler ses méthodes comme si l'objet était dans votre processus au lieu de s'exécuter sur un ordinateur séparé. Le système d'accès distant utilise des objets proxy qui donnent l'impression que l'objet serveur réside dans le processus du client. Les proxies sont des objets auxiliaires qui se présentent sous la forme d'un autre objet. Lorsque votre client crée une instance du type distant, l'infrastructure de l'accès distant crée un objet proxy qui apparaît au client exactement sous la forme du type distant. Votre client appelle une méthode sur ce proxy, et le système d'accès distant reçoit l'appel, le dirige vers le processus serveur, appelle l'objet serveur et retourne la valeur de retour au client proxy, qui retourne le résultat au client.

Les appels distants doivent être transmis d'une certaine manière entre le processus client et le processus serveur. Si vous créez un système d'accès distant vous-même, vous pouvez commencer par apprendre la programmation réseau et un vaste éventail de protocoles et de spécifications de format de sérialisation. Dans le système .NET Remoting, la combinaison de technologies sous-jacentes nécessaires pour ouvrir une connexion réseau et utiliser un protocole particulier pour envoyer les octets à l'application destinataire est représentée sous la forme d'un canal de transport.

Un canal est un type qui prend un flux de données, crée un lot en fonction d'un protocole de réseau particulier et envoie le lot à un autre ordinateur. Certains canaux ne peuvent que recevoir des informations, les autres ne peuvent qu'envoyer des informations, et d'autres tels que le canal par défaut TcpChannel et les classes HttpChannel peuvent s'utiliser dans l'une ou l'autre direction.

Bien que le processus serveur possède toutes les informations sur chaque type unique, le client sait qu'il a besoin d'une référence à un objet dans un autre domaine d'application, vraisemblablement sur un autre ordinateur. À l'extérieur de l'environnement du domaine d'application serveur, une URL localise l'objet. Les URL qui représentent des types uniques au monde extérieur sont des URL d'activation qui garantissent que votre appel distant est dirigé vers le bon type. Pour plus d'informations, consultez URL d'activation.

Design de système d'accès distant complet

Supposons que vous ayez une application en cours d'exécution sur un ordinateur, et que vous souhaitez utiliser les fonctionnalités exposées par un type stocké sur un autre ordinateur. L'illustration suivante montre le processus général d'accès distant.

Processus d'accès distant

Si les deux versants de la relation sont correctement configurés, un client crée simplement une nouvelle instance de la classe serveur. Le système d'accès distant crée un objet proxy qui représente la classe et retourne à l'objet client une référence au proxy. Lorsqu'un client appelle une méthode, l'infrastructure d'accès distant traite l'appel, vérifie les informations de type et transmet l'appel sur le canal en direction du processus serveur. Un canal à l'écoute sélectionne l'appel et le transmet au système d'exploitation du serveur, qui localise (ou crée si nécessaire) et appelle l'objet demandé. Le processus est ensuite inversé, tandis que le système d'accès distant du serveur empaquette la réponse dans un message que le canal du serveur envoie au canal du client. Finalement, le système d'accès distant du client retourne le résultat de l'appel à l'objet du client par l'intermédiaire du proxy.

Cette opération nécessite très peu de code pour fonctionner. La conception et la configuration de la relation doivent toutefois faire l'objet d'une réflexion. Le code peut être parfaitement correct sans pour autant fonctionner si une URL ou un numéro de port est incorrect. Pour plus d'informations, consultez Configuration.

Même si cette vue d'ensemble détaillée du processus d'accès distant est assez simple, les détails de niveau inférieur sont assez complexes. Les points clés de l'accès distant sont abordés de manière plus approfondie dans d'autres rubriques, voir ci-dessous.

Voir aussi

Vue d'ensemble de .NET Remoting | Limites : Processus et domaines d'application | Objets accessibles à distance et objets non accessibles à distance | Activation d'objets et durées de vie | Canaux | Sécurité | Configuration