Serveraktivierung

Serveraktivierte Objekte sind Objekte, deren Lebensdauer direkt vom Server gesteuert wird. Die Serveranwendungsdomäne erstellt diese Objekte nur, wenn der Client einen Methodenaufruf für das Objekt durchführt. Diese Objekte werden jedoch nicht erstellt, wenn der Client new (New() in Visual Basic) oder Activator.GetObject() aufruft. So kann ein Roundtrip im Netzwerk verhindert werden, der nur der Erstellung einer Instanz dient. Wenn ein Client eine Instanz eines serveraktivierten Typs anfordert, wird in der Clientanwendungsdomäne lediglich ein Proxy erstellt. Dies bedeutet jedoch auch, dass nur Standardkonstruktoren für serveraktivierte Typen zulässig sind, wenn Sie Standardimplementierungen verwenden. Um einen Typ zu veröffentlichen, dessen Instanzen mit bestimmten Konstruktoren erstellt werden, die Argumente verwenden, können Sie entweder die Clientaktivierung verwenden oder die betreffende Instanz dynamisch veröffentlichen.

Serveraktivierungsmodi

Es gibt zwei Aktivierungsmodi (oder WellKnownObjectMode-Werte) für serveraktivierte Objekte: Singleton und SingleCall.

Singleton-Typen verfügen nie über mehrere Instanzen gleichzeitig. Wenn eine Instanz vorhanden ist, werden alle Clientanforderungen über diese Instanz abgewickelt. Wenn keine Instanz vorhanden ist, erstellt der Server eine Instanz, und alle nachfolgenden Clientanforderungen werden über diese Instanz abgewickelt. Da Singleton-Typen eine Standardlebensdauer zugeordnet ist, erhalten Clients nicht immer einen Verweis auf dieselbe Instanz der remotefähigen Klasse, selbst wenn zu keinem Zeitpunkt mehr als eine Instanz verfügbar ist.

SingleCall-Typen haben stets eine Instanz pro Clientanforderung. Der nächste Methodenaufruf wird auch dann über eine andere Serverinstanz abgewickelt, wenn die vorherige Instanz vom System noch nicht wieder verwendet wurde. SingleCall-Typen nehmen nicht am Lebensdauer-Leasesystem teil.

Zum Erstellen einer Instanz eines serveraktivierten Typs konfigurieren Clients ihre Anwendung entweder programmgesteuert (oder verwenden eine Konfigurationsdatei) und rufen new auf oder übergeben die Konfiguration des Remoteobjekts in einem Aufruf von Activator.GetObject.

Hinweis

Clientseitig muss der Channel möglicherweise nicht registriert werden. Wenn der Client keinen Channel registriert, wählt das Remotingsystem automatisch einen Channel aus bzw. erstellt diesen. Dazu wird einer der Standardchannels aus der Datei Machine.config für ausgehende Anforderungen verwendet. Durch die automatische Channelauswahl auf dem Client wird der Channel nicht für die Überwachung der Rückruffunktionen vom Server registriert. Wenn der benutzerdefinierte Channel nicht der Datei Machine.config hinzugefügt wird, werden zudem keine benutzerdefinierten Channelimplementierungen registriert. In diesen Fällen müssen Sie den in der Clientanwendungsdomäne zu verwendenden Channeltyp registrieren.

Im folgenden Codebeispiel wird ein Aufruf von Activator.GetObject dargestellt. Dabei wird davon ausgegangen, dass ein TcpChannel-Objekt für die Kommunikation über Port 8080 registriert wurde. Wenn der Client nur Informationen darüber hat, ob das Serverobjekt eine bestimmte Schnittstelle implementiert, müssen Sie einen Aufruf von Activator.GetObject verwenden, da Sie nur mit new (New in Visual Basic) eine Instanz einer Klasse erstellen können.

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 "
);

Beachten Sie, dass der vorangegangene Aufruf kein Remoteobjekt auf dem Server erstellt. Er gibt lediglich einen Verweis auf den lokalen Proxy für das Remoteobjekt an den Client zurück. Der Client kann nun mit der Behandlung von MyRemoteClass fortfahren, als ob es sich um einen direkten Verweis auf das Remoteobjekt handelt. Mit welcher Instanz der Client tatsächlich beim jeweiligen Methodenaufruf kommuniziert, hängt davon ab, ob das Serverobjekt als Singleton-Typ oder als SingleCall-Typ deklariert ist. Ungeachtet dessen, ob der Herausgeber des Serverobjekts diese Informationen verfügbar macht, behandelt der Client seinen Objektverweis identisch.

Singletons

In COM bedeutete "Singleton", dass ein Objekt nicht aus dem Arbeitsspeicher gelöscht wird, solange Clients über Verweise auf das Objekt verfügen. In .NET Remoting hingegen unterliegt ein Singleton-Objekt dem Lebensdauerlease, der für das Objekt angegeben wurde, daher kann es selbst dann wieder verwendet werden, wenn Clients über Verweise darauf verfügen. Sie können den früheren Typ des Singleton-Objekts erstellen, indem Sie die InitializeLifetimeService-Methode von MarshalByRefObject außer Kraft setzen, sodass ein NULL-Verweis (Nothing in Visual Basic) zurückgegeben wird. So verbleibt das Objekt so lange im Arbeitsspeicher, wie die Hostanwendungsdomäne ausgeführt wird. Details finden Sie unter Lebensdauerleases. Sie können den neuen Typ des Singleton-Objekts erstellen, indem Sie die ursprüngliche Leasezeit in der Remotekonfigurationsdatei konfigurieren.

Siehe auch

Referenz

WellKnownObjectMode-Enumeration
Marshal

Konzepte

Aktivierung von Remoteobjekten
Clientaktivierung
Lebensdauerleases