Architecture .NET Framework Remoting

Cette rubrique est spécifique à la technologie héritée assurant la compatibilité descendante avec des applications existantes et n'est pas recommandée en cas de nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF)

L'infrastructure .NET Remoting est une approche abstraite de la communication entre processus. Les objets qui peuvent être passés par valeur ou copiés sont passés automatiquement entre des applications de domaines d'application différents ou entre des applications situées sur d'autres ordinateurs. Pour que cela fonctionne, marquez vos classes personnalisées comme classes sérialisables.

Cependant, la véritable force du système de communication à distance réside dans sa capacité à permettre à des objets de domaines d'application ou de processus différents de communiquer à l'aide de protocoles de transport, de formats de sérialisation, de schémas de durée de vie et de modes de création d'objets différents. De plus, la communication à distance permet d'intervenir pratiquement à chaque étape du processus de communication.

Que vous ayez implémenté plusieurs applications distribuées ou que vous souhaitiez déplacer des composants vers d'autres ordinateurs afin d'augmenter l'évolutivité de votre programme, le plus simple est d'aborder le système de communication à distance comme un système générique de communication entre processus doté de quelques implémentations par défaut qui prennent facilement en charge la plupart des scénarios. La présentation suivante commence par les bases de la communication entre processus à l'aide de la communication à distance.

Copies et références

La communication entre processus requiert 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'une extrémité à l'autre. Les adresses de méthodes serveur sont logiques et fonctionnent correctement dans un processus, mais pas dans un processus client différent. Pour pallier ce problème, un client peut appeler un objet serveur en faisant une copie complète de l'objet et en le déplaçant vers le processus client, où les méthodes de la copie peuvent être appelées directement.

Toutefois, de nombreux objets ne peuvent ou ne doivent pas être copiés et déplacés vers un autre processus pour être exécutés. Les objets extrêmement grands comptant de nombreuses méthodes ne doivent pas être copiés ou passés par valeur à d'autres processus. Habituellement, un client n'a besoin que des informations retournées par une ou quelques méthodes de l'objet serveur. Une copie de l'objet serveur dans son intégralité, y compris ce qui pourrait être de grandes quantités d'informations internes ou de structures exécutables sans rapport avec les besoins du client, représenterait un gaspillage de bande passante, de mémoire du client et de temps de traitement. De plus, de nombreux objets exposent des fonctionnalités publiques, mais requièrent des données privées pour toute exécution interne. La copie de ces objets pourrait permettre à des clients non autorisés d'examiner des données internes, ce qui pourrait créer d'éventuels problèmes de sécurité. Enfin, certains objets utilisent des données qui ne peuvent en aucun cas être copiées. Par exemple, un objet FileInfo contient une référence à un fichier du système d'exploitation, qui dispose d'une adresse unique dans la mémoire du processus serveur. Vous pouvez copier cette adresse, mais elle ne sera pas valide dans un autre processus.

Dans ce cas, 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. Le système de communication à distance rassemble toutes les informations concernant l'appel et les envoie au processus serveur, où il est interprété. L'objet serveur correct est ensuite localisé et l'objet serveur est appelé 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 n'est utilisée que pour les informations critiques : l'appel, les arguments d'appel et toutes les valeurs ou exceptions retournées.

Architecture de communication à distance simplifiée

L'utilisation de références d'objet pour communiquer entre des objets serveur et des clients constitue le cœur de la communication à distance. Toutefois, l'architecture de communication à distance fournit au programmeur une procédure plus basique. Si vous configurez correctement le client, il vous suffit de créer une instance de l'objet distant à l'aide de new (ou de la fonction de création d'instance de votre langage de programmation managé). Votre client reçoit une référence à l'objet serveur et vous pouvez appeler ensuite ses méthodes comme si l'objet était dans votre processus et non pas sur un autre ordinateur. Le système de communication à distance utilise des objets proxy pour donner l'impression que l'objet serveur est dans le processus du client. Les proxies sont des objets qui se présentent comme étant d'autres objets. Lorsque votre client crée une instance du type distant, l'infrastructure de communication à distance crée un objet proxy qui semble identique au type distant pour votre client. Votre client appelle une méthode sur ce proxy et le système de communication à distance reçoit l'appel, le route vers le processus serveur, appelle l'objet serveur et retourne la valeur de retour au proxy client, qui à son tour retourne le résultat au client.

Les appels distants doivent être acheminés d'une certaine façon entre le client et le processus serveur. Si vous génériez un système de communication à distance vous-même, vous pourriez commencer par apprendre la programmation réseau et toute une série de spécifications de format de sérialisation et de protocoles. Dans le système .NET Remoting, la combinaison des technologies sous-jacentes requises pour ouvrir une connexion réseau et utiliser un protocole particulier pour envoyer les octets à l'application de réception est représentée sous la forme d'un canal de transport.

Un canal est un type qui, à partir d'un flux de données de données, crée un package d'après un protocole réseau spécifique et l'envoie à un autre ordinateur. Certains canaux ne peuvent que recevoir des informations, d'autres ne peuvent qu'envoyer des informations et d'autres, tels que les classes par défaut TcpChannel et HttpChannel, peuvent être utilisés dans l'une et l'autre direction.

Bien que le processus serveur sache tout à propos de chaque type unique, le client sait uniquement qu'il souhaite une référence à un objet situé dans un autre domaine d'application, peut-être même sur un autre ordinateur. L'URL permet de localiser l'objet à partir du monde extérieur au domaine d'application. Les URL qui représentent des types uniques au monde extérieur sont des URL d'activation qui garantissent que le bon type distant est appelé. Pour plus d'informations, consultez URL d'activation.

Conception d'un système de communication à distance complet

Supposons que vous disposez d'une application qui s'exécute sur un ordinateur et que vous souhaitez utiliser les fonctionnalités exposées par un type stocké sur un autre ordinateur. L'illustration ci-dessous présente le processus de communication à distance général.

Si les deux côtés de la relation sont configurés correctement, un client crée simplement une instance de la classe du serveur. Le système de communication à distance crée un objet proxy qui représente la classe et retourne une référence au proxy à l'objet client. Lorsqu'un client appelle une méthode, l'infrastructure de communication à distance gère l'appel, vérifie les informations de type et envoie l'appel au processus serveur via le canal. Un canal d'écoute sélectionne la demande et la transfère au système de communication à distance serveur qui localise (ou crée, le cas échéant) et appelle l'objet demandé. Le processus est ensuite inversé, le système de communication à distance serveur incorporant la réponse dans un message que le canal serveur envoie au canal client. Enfin, le système de communication à distance client retourne le résultat de l'appel à l'objet client via le proxy.

Cette opération ne nécessite que très peu de code, mais il est nécessaire de réfléchir à la conception et à la configuration de la relation. Le code peut être tout à fait correct mais échouer, car une URL ou un numéro de port est incorrect. Pour plus d'informations, consultez Configuration.

Bien que cette vue d'ensemble détaillée du processus de communication à distance soit assez simple, les détails de niveau inférieur peuvent se révéler assez complexes. Une présentation plus détaillée des éléments majeurs de communication à distance est fournie dans d'autres rubriques, comme indiqué dans la section suivante Voir aussi.

Voir aussi

Concepts

Limites : processus et domaines d'application
Objets accessibles à distance et objets non accessibles à distance
Canaux
Sécurité dans la communication à distance
Configuration d'applications distantes

Autres ressources

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