Activation par serveur

Les objets activés par le serveur sont des objets dont les durées de vie sont directement contrôlées par le serveur. Le domaine d'application serveur crée ces objets uniquement lorsque le client effectue un appel de méthode sur l'objet, plutôt que lorsque le client appelle new (New() dans Visual Basic) ou Activator.GetObject ; cela évite un aller-retour sur le réseau dans le seul but de créer une instance. Seul un proxy est créé dans le domaine d'application client lorsqu'un client demande une instance d'un type activé par le serveur. Cependant, cela signifie également que seuls les constructeurs par défaut sont autorisés pour des types activés par le serveur lorsque vous utilisez les implémentations par défaut. Pour publier un type dont les instances seront créées avec des constructeurs spécifiques qui prennent des arguments, vous pouvez utiliser l'activation par client ou vous pouvez dynamiquement publier votre instance particulière.

Il existe deux modes d'activation (ou valeurs WellKnownObjectMode) pour des objets activés par le serveur : Singleton ** et SingleCall.

Les types Singleton n'ont jamais plus d'une instance à la fois. Si une instance existe, toutes les demandes clientes sont traitées par cette instance. Dans le cas contraire, le serveur crée une instance et toutes les demandes clientes suivantes sont traitées par cette instance. Comme les types Singleton possèdent une durée de vie par défaut qui leur est associée, les clients ne reçoivent pas toujours une référence à la même instance de la classe accessible à distance, même s'il n'existe jamais plusieurs instances disponibles à un même moment.

Les types SingleCall possèdent toujours une instance par demande cliente. L'invocation de méthode suivante sera traitée par une instance de serveur différente, même si l'instance précédente n'a pas déjà été recyclée par le système. Les types SingleCall ne participent pas au système de bail de durée de vie.

Pour créer une instance d'un type activé par le serveur, soit les clients configurent leur application par programme (ou en utilisant un fichier de configuration) et appelle new, soit ils passent la configuration de l'objet distant dans un appel à Activator.GetObject.

**Remarque   **Il se peut que vous ne soyez pas obligé d'inscrire le canal côté client. Si le client n'inscrit pas un canal, le système d'accès distant choisit automatiquement ou crée un canal à l'aide d'un des canaux par défaut spécifiés dans le fichier Machine.config pour effectuer des demandes sortantes. Cette sélection automatique de canal sur le client n'inscrit pas le canal pour écouter d'éventuelles fonctions de rappel provenant du serveur et, à moins que ce canal personnalisé ne soit ajouté au fichier machine.config, il n'inscrit aucune implémentation de canal personnalisé. Dans ces cas, vous devez inscrire le type de canal que vous souhaitez utiliser dans le domaine d'application client.

L'exemple de code suivant illustre un appel à Activator.GetObject, en supposant qu'un TcpChannel a été inscrit pour communiquer sur le port 8080. Si votre client sait seulement que l'objet serveur implémente une interface particulière, vous devez utiliser un appel à Activator.GetObject, car vous ne pouvez utiliser que new (New dans Visual Basic) pour créer une instance d'une classe.

Dim MyRemoteClass As RemoteObjectClass = _
   CType( _
      Activator.GetObject(_
         GetType(RemoteObjectClass), _
         "tcp://computername:8080/RemoteObjectUri" _
      ), _
      RemoteObjectClass
   ) [C#]
RemoteObjectClass MyRemoteClass = (RemoteObjectClass)Activator.GetObject(
   typeof(RemoteObjectClass),
   "tcp://computername:8080/RemoteObjectUri "
);

Gardez à l'esprit que le code précédent ne crée par l'objet distant sur le serveur. Il ne retourne au client qu'une référence au proxy local pour l'objet distant. Le client peut désormais continuer à considérer MyRemoteClass comme une référence directe à l'objet distant. L'instance que le client utilise pour communiquer d'un appel de méthode à l'autre dépend de la déclaration de l'objet serveur en tant que type Singleton ou SingleCall. Que l'éditeur de l'objet serveur expose ces informations ou non, le client traite la référence d'objet de la même manière.

Singletons

Dans COM, « singleton » signifiait qu'aussi longtemps que des clients possédaient des références à votre objet, celui-ci n'était pas supprimé de la mémoire. Cependant, dans .NET Remoting, un objet Singleton est soumis au bail de durée de vie qui lui est spécifié, de sorte qu'il puisse être recyclé même si les clients possèdent des références s'y rapportant. Vous pouvez créer le type d'objet Singleton précédent en substituant la méthode InitializeLifetimeService de MarshalByRefObject pour retourner une référence null (Nothing dans Visual Basic). Cette opération conserve l'objet en mémoire aussi longtemps que le domaine d'application hôte est en cours d'exécution. Pour plus d'informations, consultez Baux de durée de vie. Vous pouvez créer le dernier type d'objet Singleton en configurant la durée de bail initiale dans le fichier de configuration d'accès distant.

Voir aussi

Activation | Activation par client | WellKnownObjectMode, énumération | Activation | Baux de durée de vie