Objets accessibles à distance et objets non accessibles à distance

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).

Il est important de se souvenir qu'un objet créé dans un domaine d'application lui est spécifique et peut être appelé directement à partir de ce domaine. Cependant, il doit se produire un événement pour que cet objet soit disponible à l'extérieur de son domaine. Tous les types d'objets ne peuvent pas être publiés et consommés de manière efficace au-delà des limites de domaine. Vous devez donc décider quel type d'objet publier en fonction des besoins de votre application. Il existe deux catégories d'objets répondant aux besoins des applications distribuées : les objets non accessibles à distance et les objets accessibles à distance.

Objets non accessibles à distance

Certains objets ne peuvent pas quitter leur domaine d'application ; ils ne sont jamais marshalés, car ils ne déclarent aucune méthode de sérialisation. Ces objets non accessibles à distance sont conçus pour être utilisés uniquement dans le domaine d'application dans lequel ils ont été créés. Ils sont toujours accessibles directement à partir de ce domaine. La plupart des classes de base de la bibliothèque de classes .NET Framework sont des objets non accessibles à distance. Les objets non accessibles à distance ne peuvent pas être copiés ou représentés dans un autre domaine d'application. Ces objets sont uniquement accessibles à partir de leur domaine d'application d'origine.

Objets accessibles à distance.

Il est possible d'accéder aux objets accessibles à distance de l'extérieur de leur domaine d'application ou de leur contexte à l'aide d'un proxy. Ils peuvent également être copiés, ces copies étant ensuite passées à l'extérieur de leur domaine d'application ou de leur contexte ; autrement dit, certains objets accessibles à distance sont passés par référence et quelques-uns sont passés par valeur.

Les objets accessibles à distance sont des objets qui fonctionnent correctement dans un environnement largement distribué. Il existe deux types principaux d'objets accessibles à distance:

• Les objets marshalés par valeur, qui sont copiés et passés à partir du domaine d'application.

• Les objets marshalé par référence, pour lesquels un proxy est créé et est utilisé par le client pour accéder à distance à l'objet.

Objets marshalés par valeur

Les objets marshalés par valeur (MBV) déclarent leurs règles de sérialisation (soit en implémentant ISerializable pour implémenter leur propre sérialisation, soit en étant marqués avec SerializableAttribute, qui demande au système de sérialiser automatiquement l'objet), mais n'étendent pas MarshalByRefObject. Le système de communication à distance effectue une copie complète de ces objets et passe la copie au domaine d'application appelant. Lorsque la copie figure dans le domaine d'application de l'appelant, les appels destinés à la copie sont directement dirigés vers cette copie. De plus, les objets MBV passés en tant qu'arguments sont également passés par valeur. Hormis la déclaration de l'attribut SerializableAttribute ou l'implémentation de ISerializable, aucune action n'est requise pour passer des instances de votre classe par valeur à travers les limites d'application ou de contexte.

Remarque :

À partir de la version 1.1 du .NET Framework, l'infrastructure de communication à distance ne désérialise pas automatiquement certains types sur le serveur. Si votre application essaie de passer un type qui n'est pas sérialisé automatiquement, vous devez définir le niveau de désérialisation serveur à Full pour que le serveur puisse désérialiser et utiliser votre objet MBV. Pour plus d'informations, consultez Désérialisation automatique dans .NET Remoting.

Utilisez les objets MBV lorsqu'il est intéressant, en termes de performance ou pour des questions de traitement, de déplacer l'état complet de l'objet et toute fonctionnalité exécutable dans le domaine d'application cible. Dans de nombreux scénarios, cela réduit le nombre de boucles longues et gourmandes en ressources sur des réseaux, des processus et des limites de domaine d'application. Les objets MBV sont également utilisés directement à partir du domaine d'application d'origine de l'objet. Dans ce cas, comme aucun marshaling n'a lieu, aucune copie n'est effectuée et l'accès est efficace.

Créez un type marshalé par valeur à l'aide de SerializableAttribute, à moins que vous n'étendiez une classe qui implémente déjà ISerializable. Dans ce cas, vous devez implémenter ISerializable pour votre type.

Le système de communication à distance utilise très souvent des objets sérialisables. Une référence à un objet dans un autre domaine d'application, représentée dans le système de communication à distance par la classe ObjRef, est elle-même sérialisable ; il doit être possible de la copier et d'envoyer la copie à un client. De plus, les objets qui transfèrent des données sont souvent des objets sérialisables. Par exemple, DataSet étend MarshalByValueComponent, qui implémente ISerializable.

Exceptions de communication à distance définies par l'utilisateur

Les exceptions définies par le système sont toutes des types marshalés par valeur (ils implémentent l'interface ISerializable) qui, lorsqu'elles sont levées par un objet distant, sont automatiquement copiées vers l'appelant si les configurations de communication à distance le permettent. À partir de la version 1.1 du .NET Framework, l'élément <customErrors> doit avoir la valeur off pour permettre aux exceptions d'être transmises à l'appelant.

Pour plus d'informations sur la création d'un type d'exception qui peut être levé par un objet distant et intercepté par un appelant distant, consultez Comment : créer un type d'exception qui peut être levé par des objets distants

Objets marshalés par référence

Les objets marshalés par référence (MBR) sont des objets accessibles à distance qui étendent au moins System.MarshalByRefObject. Selon le type d'activation déclaré, lorsqu'un client crée une instance d'un objet MBR dans son propre domaine d'application, l'infrastructure .NET Remoting crée un proxy qui représente l'objet MBR et retourne à l'appelant une référence à ce proxy. Le client effectue ensuite des appels sur le proxy. .NET Remoting marshale ces appels au domaine d'application de l'objet distant et invoque l'appel.

Remarque :
Si le client figure dans le même domaine d'application que l'objet MBR, l'infrastructure retourne au client une référence directe à l'objet MBR, évitant ainsi le traitement du marshaling.

Si un System.MarshalByRefObject est passé en tant que paramètre, il devient un proxy dans l'autre domaine d'application lorsque l'appel arrive. Les valeurs de retour du MBR et les paramètres out fonctionnent de la même façon.

Remarque :

À partir de la version 1.1 du .NET Framework, l'infrastructure .NET Remoting ne désérialise pas automatiquement certains types sur le serveur. Par exemple, pour obtenir la prise en charge des objets MBR passés en tant que paramètres, vous devez définir le niveau de désérialisation du serveur à Full pour que le serveur puisse désérialiser et utiliser le paramètre MBR. Pour plus d'informations, consultez Désérialisation automatique dans .NET Remoting.

Vous devez utiliser les objets MBR lorsque l'état de l'objet et toutes les fonctionnalités exécutables doivent rester dans le domaine d'application dans lequel ils ont été créés. Par exemple, un objet qui a un champ interne correspondant à un handle de système d'exploitation doit étendre System.MarshalByRefObject, car le handle de système d'exploitation ne serait pas explicite dans un autre domaine d'application, dans un autre processus, ou sur un autre ordinateur. Parfois, un objet peut également être beaucoup trop volumineux et, même si cela ne pose pas de problème pour un serveur fiable, il en va différemment d'une connexion à un modem 33,6 Kbits/s

Objets liés au contexte

Les objets liés au contexte sont des objets MBR qui héritent de System.ContextBoundObject, qui hérite lui-même de System.MarshalByRefObject. Vous pouvez vous représenter le contexte comme étant une sous-division d'un domaine d'application qui offre un environnement riche pour les objets qui y résident lors de leur exécution. Par exemple, un contexte pourrait garantir que plusieurs threads n'accèdent pas simultanément aux objets. Chaque domaine d'application possède un contexte par défaut. La plupart des codes managés créent des objets et appellent directement des membres à partir du même domaine d'application à l'aide du contexte par défaut de ce domaine, sans problèmes liés au contexte. Tous les types qui héritent de System.ContextBoundObject sont exposés à d'autres contextes (dans le même domaine ou dans d'autres domaines) en tant que proxies.

Par exemple, supposons que vous disposez d'une méthode sur un type qui fait partie d'une transaction et obéit donc aux règles spécifiques au contexte dans lequel elle a été créée. Ce type doit hériter de System.ContextBoundObject afin que l'accès à l'objet provienne de son propre contexte, et le système peut mettre en vigueur des règles concernant les transactions associées à cet objet et à ses méthodes. Si un System.ContextBoundObject est appelé d'un autre contexte du même domaine d'application, un proxy est créé pour l'appelant, mais la communication entre contextes ne traverse pas le système de canaux, ce qui augmente l'efficacité de l'appel dans cette situation.

Comme un certain temps de traitement est nécessaire pour traverser chaque limite, vous devez déterminer les limites que doit traverser votre objet avant de décider quel type d'objet accessible à distance doit être votre serveur. Il n'est possible d'accéder directement à des objets spécifiques à un contexte particulier qu'à partir de ce contexte. Cela est également vrai pour les objets spécifiques à un domaine d'application particulier. Pour accéder à distance à l'un ou l'autre objet, le système de communication à distance doit parvenir à traverser une limite de contexte, une limite d'application ou les deux avant d'appeler l'objet serveur à partir de l'intérieur d'une limite à laquelle il se rapporte. Si vous n'avez pas besoin d'effectuer un contrôle de contexte pour appeler votre objet, ne faites pas étendre System.ContextBoundObject par votre type distant ; System.MarshalByRefObject fonctionne mieux. Si vous avez besoin d'effectuer un contrôle de contexte, vous devez étendre System.ContextBoundObject, mais vous devez comprendre que la limite supplémentaire doit être traversée avant que l'appel ne soit effectué sur votre objet.

Portée de la publication

Les systèmes de communication à distance décident de façon différente quels membres et quel type de membres peuvent être utilisés à distance. .NET Remoting expose les objets à d'autres domaines d'application comme s'ils étaient locaux, à quelques exceptions près :

• Membres statiques

  Les champs et les méthodes statiques ne sont jamais mis à distance, l'accès à un champ se fait toujours directement à travers la mémoire. Autrement dit, .NET Remoting traite toujours des membres d'instance quelle que soit leur forme.

• Champs d'instance et accesseurs.

  Pour les champs d'instance et les méthodes d'accesseur, le système insère un contrôle pendant l'exécution pour déterminer si l'objet est un proxy. S'il ne s'agit pas d'un proxy, l'accès au champ est direct. Sinon, le proxy fournit des accesseurs à l'appelant.

• Méthodes privées.

  Les méthodes privées ne sont pas accessibles à distance. Vous ne pouvez pas encapsuler et passer à distance un délégué à une méthode privée.

• Délégués.

  Les délégués sont des objets marshalés par valeur. L'objet situé dans le délégué peut être tout type d'objet accessible à distance : un objet sérialisable, un objet MarshalByRefObject ou un objet ContextBoundObject. La seule exception est qu'un délégué à une méthode d'interface n'est pas accessible à distance. Le délégué encapsule l'implémentation de la méthode d'interface, ce qui nécessite que les informations de type du client soient accessibles par le serveur.

• Méthodes de substitution sur un objet.

  Pour des raisons de performances, les méthodes virtuelles sur unobjet s'exécutent toujours localement dans le domaine d'application où elles sont appelées. Les appels à chacune des méthodes suivantes n'atteignent l'objet distant que lorsqu'elles ont été substituées sur l'objet distant :

  • Equals

    Cette méthode virtuelle s'exécute à distance si elle a été substituée.

  • GetHashCode

    Cette méthode s'exécute localement.

  • ToString

    Cette méthode virtuelle s'exécute à distance si elle a été substituée.

  • Equals (version statique)

    Cette méthode s'exécute localement.

  • MemberwiseClone

    Cette méthode s'exécute localement.

Voir aussi

Tâches

Comment : créer un type d'exception qui peut être levé par des objets distants

Autres ressources

Vue d'ensemble de .NET Framework Remoting
Rendre des objets accessibles à distance