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, jedoch nicht, wenn der Client new (New() in Visual Basic) oder Activator.GetObject() aufruft. So kann eine Roundtrip im Netzwerk verhindert werden, die 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 mit Argumenten erstellt werden, können Sie entweder die Clientaktivierung verwenden oder die betreffende Instanz dynamisch veröffentlichen.

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 recycelt 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 für die Kommunikation auf Anschluss 8080 registriert wurde. Wenn der Client nur Informationen darüber hat, dass 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
   ) [C#]
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 handelte. 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 Publisher des Serverobjekts diese Informationen offen legt, behandelt der Client seinen Objektverweis identisch.

Singletons

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

Siehe auch

Aktivierung | Clientaktivierung | WellKnownObjectMode-Enumeration | Aktivierung | Lebensdauer-Leases