Architecture .Net Framework Remoting

L'infrastructure .NET Remoting est une approche abstraite de la communication entre processus. L'essentiel du système fonctionne de façon transparente. 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 capacité à 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 certain nombre d'applications distribuées ou que vous souhaitiez simplement déplacer des composants vers d'autres ordinateurs pour augmenter 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 avec des implémentations par défaut qui gèrent facilement la majorité 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 même processus, mais non 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 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 volumineux avec de nombreuses méthodes représentent des mauvais choix pour une copie ou un passage par valeur dans d'autres processus. Généralement, un client a besoin uniquement des informations retournées par une seule ou quelques-unes seulement des méthodes sur l'objet serveur. La copie de l'objet serveur dans sa totalité, y compris d'une large quantité 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 des 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 des 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 elle ne conviendra jamais dans un autre processus.

Dans ce type de situation, 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 de références d'objets pour communiquer entre des objets serveur et des clients est au cœur même du fonctionnement de l'accès distant. L'architecture de l'accès distant fournit cependant 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 de la fonction de création d'instance de votre langage de programmation managée). Votre client reçoit une référence à l'objet serveur et vous pouvez ensuite appeler ses méthodes comme si cet objet se trouvait dans votre processus et non comme s'il s'exécutait sur un ordinateur distinct. 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 comme le 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, lequel retourne le résultat au client.

Les appels distants doivent être transmis d'une certaine manière entre le client et le processus serveur. Si vous envisagez de créer un système d'accès distant vous-même, vous pouvez commencer par apprendre la programmation réseau et prendre connaissance des nombreuses spécifications relatives aux protocoles et aux formats de sérialisation. Dans le système .NET Remoting, la combinaison des 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 ce lot à un autre ordinateur. Certains canaux peuvent uniquement recevoir des informations, d'autres uniquement envoyer des informations, et d'autres encore, tels que les classes TcpChannel et HttpChannel peuvent s'utiliser pour les deux opérations.

Bien que le processus serveur possède toutes les informations sur chaque type unique, le client lui, sait uniquement 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 dans l'environnement extérieur sont des URL d'activation qui garantissent que votre appel distant est dirigé vers le type approprié. Pour plus d'informations, voir 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 souhaitiez 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 extrémités de la relation sont correctement configurées, 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. Enfin, 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, voir 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

Concepts

Limites : Processus et domaines d'application
Objets accessibles à distance et objets non accessibles à distance
Canaux
Sécurité dans l'accès distant
Configuration d'applications distantes

Autres ressources

Vue d'ensemble de .NET Framework Remoting
Activation d'objets et durées de vie