Activation serveur

Le serveur a un contrôle direct sur la durée de vie des objets qu'il active. Le domaine d'application serveur crée ces objets uniquement lorsque le client effectue un appel de méthode sur l'objet et non pas lorsque le client appelle new (New() en Visual Basic) ou Activator.GetObject ; cela permet d'éviter un aller-retour réseau rien que pour la création d'instance. Lorsqu'un client demande une instance d'un type activé par le serveur, seul un proxy est créé dans le domaine d'application client. Cela signifie que seuls les constructeurs par défaut sont autorisés pour les types activés par le serveur. Pour publier un type dont les instances seront créées avec des constructeurs spécifiques qui acceptent des arguments, vous pouvez utiliser l'Activation client ou vous pouvez publier votre instance spécifique de manière dynamique.

Modes d'activation serveur

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

Les types Singleton n'ont jamais plusieurs instances simultanément. Si une instance existe, cette instance répond à toutes les demandes du client. S'il n'existe pas d'instance, le serveur crée une instance qui répondra à toutes les demandes suivantes du client. Comme les types Singleton ont une durée de vie par défaut associée, les clients ne recevront pas toujours de référence à la même instance de la classe accessible à distance, bien qu'il n'y ait jamais plus d'une instance disponible simultanément.

Les types SingleCall ont toujours une instance par demande du client. Une instance de serveur différente répondra à l'appel de méthode suivant, même si l'instance précédente n'a pas encore été recyclée par le système. Les types SingleCall ne participent pas au système de baux de durée de vie.

Pour créer une instance d'un type activé par le serveur, les clients configurent leur application par programme ou à l'aide d'un fichier de configuration. Lorsque vous configurez une application par programme, vous utilisez la méthode Activator.GetObject pour instancier un objet activé par le serveur sur le client. Lorsque vous configurez une application à l'aide d'un fichier de configuration, vous pouvez appeler Activator.GetObject ou utiliser l'opérateur New pour instancier un objet activé par le serveur sur le client.

Remarque :

Vous ne serez peut-être pas obligé d'inscrire le canal côté client. Si le client n'inscrit pas de canal, le système distant crée automatiquement un canal en utilisant l'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 qu'il écoute les fonctions de rappel du serveur, et, à moins qu'un canal personnalisé ne soit ajouté au fichier machine.config, il n'inscrit aucune implémentation de canal personnalisée. Vous devez alors inscrire le type de canal que vous souhaitez utiliser dans le domaine d'application client.

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

Dim MyRemoteClass As RemoteObjectClass = _
   CType( _
      Activator.GetObject(GetType(RemoteObjectClass), _
         "tcp://computername:8080/RemoteObjectUri" ), _
      RemoteObjectClass
   ) 

RemoteObjectClass MyRemoteClass = (RemoteObjectClass)Activator.GetObject(
   typeof(RemoteObjectClass),
   "tcp://computername:8080/RemoteObjectUri "
);

N'oubliez pas qu'à ce stade, aucune communication réelle n'a encore été établie avec le serveur, l'objet distant lui-même n'a donc pas été instancié. C'est l'objet proxy qui a été instancié, côté client. Le client peut maintenant utiliser MyRemoteClass comme si c'était une référence directe à l'objet distant. L'instance RemoteObjectClass que le client utilise réellement pour communiquer d'appel de méthode en appel de méthode varie selon que l'objet serveur est déclaré en tant que type Singleton ou SingleCall. Le client traite la référence d'objet dont il dispose de la même façon, que l'éditeur de l'objet serveur expose cette information ou non.

Singletons

Dans COM, « singleton » signifiait que tant que les clients avaient des références à votre objet, l'objet ne serait pas supprimé de la mémoire. Dans l'accès distant .NET toutefois, un objet Singleton est soumis au bail de durée de vie qui lui a été assigné afin qu'il puisse être recyclé même si des clients lui font encore référence. Vous pouvez créer l'ancien type d'objet Singleton en substituant la méthode InitializeLifetimeService de MarshalByRefObject pour retourner une référence nulle (Nothing en Visual Basic). Cela permet de conserver l'objet dans la mémoire tant que le domaine d'application hôte s'exécute. Pour plus d'informations, consultez Baux de durée de vie. Vous pouvez créer le nouveau type d'objet Singleton en configurant la durée initiale du bail dans le fichier de configuration d'accès distant.

Voir aussi

Référence

WellKnownObjectMode Enumeration

Concepts

Activation d'objets distants
Activation client
Baux de durée de vie

Copyright ©2007 par Microsoft Corporation. Tous droits réservés.