Remotefähige und nicht remotefähige Objekte

Dieses Thema bezieht sich auf eine veraltete Technologie, die zum Zwecke der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten wird und nicht für die neue Entwicklung empfohlen wird. Verteilte Anwendungen sollten jetzt mit  Windows Communication Foundation (WCF) entwickelt werden.

Beachten Sie unbedingt, dass ein Objekt, das in einer Anwendungsdomäne erstellt wird und das dieser daher eigen ist, direkt von dieser Domäne aufgerufen werden kann, aber nicht ohne weiteres außerhalb seiner Domäne verfügbar ist. Nicht jeder Objekttyp kann über Domänengrenzen hinweg effizient veröffentlicht oder verwendet werden. Daher müssen Sie unter Berücksichtigung der Anforderungen der gegebenen Anwendung entscheiden; welchen Typ von Objekt Sie veröffentlichen möchten. Im Hinblick auf verteilte Anwendungen gibt es zwei Kategorien von Objekten: nicht remotefähige Objekte und remotefähige Objekte.

Nicht remotefähige Objekte

Einige Objekte können ihre Anwendungsdomäne nicht verlassen; sie können nicht gemarshallt werden, weil Sie keine Serialisierungsmethode deklarieren. Diese nicht remotefähigen Objekte sind für die Verwendung in derselben Anwendungsdomäne konzipiert, in der sie erstellt wurden, und es wird immer direkt von dieser Anwendungsdomäne aus auf sie zugegriffen. Die meisten Basisklassen in der .NET Framework-Klassenbibliothek stellen nicht remotefähige Objekte dar. Nicht remotefähige Objekte können nicht kopiert oder in einer anderen Anwendungsdomäne dargestellt werden. Auf diese Objekte kann nur von ihrer ursprünglichen Anwendungsdomäne aus zugegriffen werden.

Remotefähige Objekte

Auf remotefähige Objekte kann über einen Proxy von außerhalb ihrer Anwendungsdomäne oder ihrem Anwendungskontext aus zugegriffen werden, oder Sie können kopiert werden, und diese Kopien können an Objekte übergeben werden, die nicht zu ihrer Anwendungsdomäne oder ihrem Kontext gehören. Das heißt, einige remotefähige Objekte werden als Verweis übergeben, und andere remotefähige Objekte werden als Wert übergeben.

Remotefähige Objekte sind Objekte, die in einer weit verteilten Umgebung gut einsetzbar sind. Es gibt zwei Hauptarten von remotefähigen Objekten:

• Als Wert gemarshallte Objekte, die kopiert und von der Anwendungsdomäne übergeben werden

• Als Verweis gemarshallte Objekte, für die ein Proxy erstellt und vom Client für den Remotezugriff auf das Objekt verwendet wird.

Als Wert gemarshallte Objekte

Als Wert gemarshallte Objekte deklarieren ihre Serialisierungsregeln (entweder durch die Implementierung von ISerializable für eine eigene Serialisierungsmethode oder durch die Markierung mit SerializableAttribute, die das System anweist, dieses Objekt automatisch zu serialisieren), aber sie erweitern MarshalByRefObject nicht. Das Remotingsystem erstellt eine vollständige Kopie dieser Objekte und übergibt die Kopie der aufrufenden Anwendungsdomäne. Sobald sich die Kopie in der Anwendungsdomäne der aufrufenden Routine befindet, werde Aufrufe der Kopie direkt an diese Kopie weitergeleitet. Zudem werden als Wert gemarshallte Objekte auch als Argument als Wert übergeben. Sie müssen nichts weiter tun, als das SerializableAttribute-Attribut zu deklarieren oder ISerializable zu implementieren, um Instanzen dieser Klasse als Wert über Anwendungs- oder Kontextgrenzen hinweg zu übergeben.

Hinweis:

Ab .NET Framework Version 1.1 deserialisiert die Remotinginfrastruktur bestimmte Typen nicht mehr automatisch auf dem Server. Wenn eine Anwendung einen Typ zu übergeben versucht, der nicht automatisch serialisiert wird, müssen Sie die Serverdeserialisierungsebene auf Full festlegen, bevor der Server das als Wert gemarshallte Objekt deserialisieren und verwenden kann. Weitere Informationen finden Sie unter Automatische Deserialisierung in .NET-Remoting.

Sie verwenden Objekte, die als Wert gemarshallt werden, wenn es im Hinblick auf die Leistung oder Verarbeitung sinnvoll ist, den gesamten Zustand des Objekts und alle ausführbaren Funktionen in die Zielanwendungsdomäne zu verlagern. In vielen Szenarien müssen dann weniger lange, ressourcenaufwendige Schleifen über Netzwerk-, Prozess- und Anwendungsdomänengrenzen hinweg ausgeführt werden. Objekte, die als Wert gemarshallt werden, werden auch innerhalb der ursprünglichen Anwendungsdomäne des Objekts direkt verwendet. Weil in diesem Fall kein Marshalling durchgeführt wird, wird keine Kopie erstellt, und der Zugriff ist effizient.

Sofern Sie keine Klasse erweitern, die ISerializable bereits implementiert, erstellen Sie ein Objekt, das als Wert übergeben wird, mithilfe der SerializableAttribute-Klasse. In diesem Fall müssen Sie ISerializable für den Typ implementieren.

Das Remotingsystem macht umfassenden Gebrauch von serialisierbaren Objekten. Ein Verweis auf ein Objekt in einer anderen Anwendungsdomäne, der im Remotingsystem durch die ObjRef-Klasse dargestellt wird, ist selbst serialisierbar. Es muss möglich sein, eine genaue Kopie zu erstellen und die Kopie an den Client zu senden. Außerdem sind Objekte, die Daten übertragen, oftmals serialisierbare Objekte. Beispielsweise erweitert DataSet die MarshalByValueComponent-Klasse, die ISerializable implementiert.

Remoting und benutzerdefinierte Ausnahmen

Systemdefinierte Ausnahmen sind ausnahmslos Typen, die als Wert gemarshallt werden (sie implementieren die ISerializable-Schnittstelle). Wenn eine solche Ausnahme durch ein Remoteobjekt ausgelöst wird, wird es automatisch kopiert und an den Aufrufer gesendet, wenn die Remotingkonfiguration dies zulässt. Ab .NET Framework Version 1.1 können Ausnahmen nur dann dem Aufrufer übermittelt werden, wenn das <customErrors>-Element auf off festgelegt wird.

Weitere Informationen dazu, wie ein Ausnahmetyp erstellt wird, der von einem Remoteobjekt ausgelöst und von einem Remoteaufrufer empfangen werden kann, finden Sie unterVorgehensweise: Erstellen eines Ausnahmetyps, der von Remoteobjekten ausgelöst werden kann

Objekte, die als Verweis gemarshallt werden

Objekte, die als Verweis gemarshallt werden, sind remotefähige Objekte, die mindestens System.MarshalByRefObject erweitern. Wenn ein Client eine Instanz eines Objekts, das als Verweis gemarshallt wird, in seiner eigenen Anwendungsdomäne erstellt, erzeugt die .NET- Remotinginfrastruktur, abhängig davon, welcher Aktivierungstyp deklariert wurde, einen Proxy, der dieses Objekt repräsentiert, und übergibt dem Aufrufer einen Verweis auf diesen Proxy. Der Client richtet Aufrufe dann an den Proxy. .NET-Remoting marshallt diese Aufrufe an die Anwendungsdomäne des Remoteobjekts und führt den Aufruf aus.

Hinweis:
Wenn sich der Client in der gleichen Anwendungsdomäne wie das Objekt befindet, das als Verweis gemarshallt wird, übergibt die Remotinginfrastruktur dem Client einen direkten Verweis auf dieses Objekt, wodurch der mit dem Marshalling verbundene Mehraufwand vermieden wird.

Wenn ein System.MarshalByRefObject-Objekt als Parameter übergeben wird, fungiert es in der Anwendungsdomäne des Aufrufers als Proxy. Rückgabewerte von Objekten, die als Verweis gemarshallt werden, und out-Parameter zeigen das gleiche Verhalten.

Hinweis:

Ab .NET Framework Version 1.1 deserialisiert die .NET-Remotinginfrastruktur bestimmte Typen nicht mehr automatisch auf dem Server. Damit beispielsweise als Parameter übergebene Objekte, die als Verweis gemarshallt werden, von einer Anwendung unterstützt werden, müssen Sie die Deserialisierungsebene des Servers auf Full festlegen, weil der Server diesen Parameter sonst nicht deserialisieren und verwenden kann. Weitere Informationen finden Sie unter Automatische Deserialisierung in .NET-Remoting.

Sie sollten Objekte, die als Verweis gemarshallt werden, verwenden, wenn der Zustand des Objekts und alle ausführbaren Funktionen die Anwendungsdomäne, in der das Objekt erstellt wurde, nicht verlassen sollten. Beispielsweise sollte ein Objekt, das ein internes Feld mit einem Betriebssystemhandle enthält, System.MarshalByRefObject erweitern, weil der Betriebssystemhandle in einer anderen Anwendungsdomäne, in einem anderen Prozess oder auf einem anderen Computer keine Bedeutung hätte. Ein Objekt kann unter Umständen auch so groß sein, dass es auf einem robusten Server verarbeitet werden kann, aber nicht von einer Remoteanwendung, wenn es über ein Modem mit einer Baudrate von 33,6 KB/s übertragen wird.

Kontextgebundene Objekte

Kontextgebundene Objekte sind Objekte, die als Verweis gemarshallt werden und die von der System.ContextBoundObject-Klasse erben, welche wiederum von System.MarshalByRefObject abgeleitet ist. Ein Kontext ist eine Untereinheit einer Anwendungsdomäne und eine Umgebung für die Objekte, die sich während der Ausführung darin befinden. Zum Beispiel kann ein Kontext garantieren, dass nicht gleichzeitig von mehreren Threads auf die Objekte zugegriffen wird. Jede Anwendungsdomäne hat einen Standardkontext. In verwaltetem Code werden in der Regel Objekte erstellt und Member direkt aus derselben Anwendungsdomäne unter Verwendung des Standardkontexts dieser Domäne aufgerufen, ohne dass kontextbezogene Probleme auftreten. Alle Typen, die von System.ContextBoundObject abgeleitet sind, werden anderen Kontexten (in der gleichen oder einer anderen Domäne) als Proxy verfügbar gemacht.

Nehmen wir beispielsweise eine Methode eines Typs, der Teil einer Transaktion und daher an die Regeln des Kontexts gebunden ist, in welchem er erstellt wurde. Dieser Typ sollte von System.ContextBoundObject erben, damit nur aus seinem eigenen Kontext auf das Objekt zugegriffen werden kann und das System die Regeln bezüglich der mit dem Objekt und seinen Methoden verknüpften Transaktion durchsetzen kann. Wenn ein Objekt des Typs System.ContextBoundObject aus einem anderen Kontext innerhalb der gleichen Anwendungsdomäne aufgerufen wird, wird für den Aufrufer ein Proxy erstellt, die kontextübergreifende Kommunikation erfolgt jedoch nicht über das Channelsystem, wodurch in diesem Fall die Aufrufe effizienter ausgeführt werden.

Weil jede Grenzüberschreitung mit Verarbeitungsaufwand verbunden ist, sollten Sie festlegen, welche Grenzen ein Objekt passieren muss, bevor Sie entscheiden, welcher Typ von remotefähigem Objekt der Server sein sollte. Auf Objekte, die einem bestimmten Kontext eigen sind, kann nur von diesem Kontext heraus direkt zugegriffen werden. Das Gleiche gilt für Objekte, die einer bestimmten Anwendungsdomäne eigen sind. Wenn ein solches Objekt remotefähig sein soll, muss das Remotingsystem eine Kontextgrenze, eine Anwendungsgrenze oder beides erfolgreich überqueren können, bevor das Serverobjekt aus dem jeweiligen Kontext bzw. der Anwendungsdomäne heraus aufgerufen wird. Wenn für Aufrufe eines Objekts keine Kontextprüfung erforderlich ist, sollte der Remoteobjekttyp nicht System.ContextBoundObject erweitern, System.MarshalByRefObject stellt in diesem Fall eine bessere Wahl dar. Wenn der Kontext überprüft werden muss, sollten Sie System.ContextBoundObject erweitern. Sie müssen sich jedoch darüber im Klaren sein, dass dann zuerst eine zusätzliche Grenze passiert werden muss, bevor Aufrufe das Objekt erreichen.

Veröffentlichungsbereich

In verschiedenen Remotingsystemen wird auf unterschiedliche Weise bestimmt, welche Member und welcher Membertyp remote verwendet werden können. Abgesehen von den folgenden Ausnahmen, macht .NET-Remoting Objekte für andere Anwendungsdomänen so verfügbar, als würde es sich um lokale Objekte handeln:

• Statische Member

  Statische Felder und Methoden sind nie remote, und auf Felder wird direkt im Arbeitsspeicher zugegriffen. Das heißt, .NET-Remoting verarbeitet immer Instanzmember irgendeiner Art.

• Instanzfelder und Accessoren

  Bei Instanzfeldern und Accessormethoden prüft das System zusätzlich zur Laufzeit, ob das Objekt ein Proxy ist. Wenn es kein Proxy ist, erfolgt der Feldzugriff direkt. Andernfalls stellt der Proxy dem Aufrufer Accessoren bereit.

• Private Methoden

  Private Methoden können nicht remote sein. Es können keine Delegaten für private Methode erstellt und remote übergeben werden.

• Delegaten

  Delegaten sind Objekte, die als Wert gemarshallt werden. Delegaten können jeden Typ von remotefähigem Objekt enthalten – ein serialisierbares Objekt, ein MarshalByRefObject-Objekt oder ein ContextBoundObject-Objekt. Lediglich ein Delegat für eine Schnittstellenmethode kann nicht erfolgreich an ein Remoteobjekt übertragen werden. Da der Delegat die Implementierung der Schnittstellenmethode enthält, müssen die Typinformationen des Clients für den Server verfügbar sein

• Überschreiben von Methoden eines Objekts

  Um die Leistung nicht zu beeinträchtigen, werden virtuelle Methoden von Object stets lokal in der Anwendungsdomäne ausgeführt, in der sie aufgerufen wurden. Aufrufe der folgenden Methoden werden nur dann an das Remoteobjekt weitergeleitet, wenn diese Methoden beim Remoteobjekt überschrieben wurden:

  • Equals

    Diese virtuelle Methode wird remote ausgeführt, wenn sie überschrieben wurde.

  • GetHashCode

    Diese Methode wird lokal ausgeführt.

  • ToString

    Diese virtuelle Methode wird remote ausgeführt, wenn sie überschrieben wurde.

  • Equals (die statische Version)

    Diese Methode wird lokal ausgeführt.

  • MemberwiseClone

    Diese Methode wird lokal ausgeführt.

Siehe auch

Aufgaben

Vorgehensweise: Erstellen eines Ausnahmetyps, der von Remoteobjekten ausgelöst werden kann

Weitere Ressourcen

Übersicht über .NET Framework-Remoting
Remotefähigmachen von Objekten