.NET-Remotingarchitektur

Die .NET-Remotinginfrastruktur ist ein abstrakter Ansatz der prozessübergreifenden Kommunikation. Viele Funktionen laufen im System im Hintergrund ab. So werden z. B. Objekte, die als Wert übergeben oder kopiert werden können, automatisch zwischen Anwendungen in verschiedenen Anwendungsdomänen oder auf verschiedenen Computern übergeben. Sie müssen dazu lediglich die benutzerdefinierten Klassen als serialisierbar markieren.

Die eigentliche Stärke des Remotingsystems liegt jedoch darin, dass es die Kommunikation zwischen Objekten in verschiedenen Anwendungsdomänen oder Prozessen mit verschiedenen Übertragungsprotokollen, Serialisierungsformaten, Schemas der Lebensdauer von Objekten und Modi der Objekterstellung ermöglicht. Darüber hinaus ermöglicht Ihnen das Remoting, in nahezu jede Stufe des Kommunikationsprozesses aus beliebigem Grund einzugreifen.

Ob Sie nun zahlreiche verteilte Anwendungen implementiert haben oder einfach nur daran interessiert sind, Komponenten zur Steigerung der Skalierbarkeit des Programms auf andere Computer zu verschieben: Das Remotingsystem erschließt sich am besten, wenn Sie es sich als generisches System für die prozessübergreifende Kommunikation mit einigen Standardimplementierungen, die die meisten Situationen meistern, vorstellen. In der folgenden Erläuterung werden zunächst die Grundlagen der prozessübergreifenden Kommunikation mit Remoting beschrieben.

Kopien oder Verweise

Für die prozessübergreifenden Kommunikation werden ein Serverobjekt, dessen Funktionen Aufrufern außerhalb des Prozesses zur Verfügung gestellt werden, ein Client, der Aufrufe für das Serverobjekt ausführt, und ein Übertragungsmechanismus benötigt, mit dem die Aufrufe von einem Ende zum anderen transportiert werden. Die Adressen von Servermethoden sind logisch und funktionieren ordnungsgemäß in einem Prozess, jedoch nicht in einem anderen Clientprozess. Um dieses Problem zu beheben, kann der Client zum Aufrufen eines Serverobjekts eine Kopie des Objekts als Ganzes erstellen und diese in den Clientprozess verschieben, in dem die Methoden der Kopie direkt aufgerufen werden können.

Viele Objekte können bzw. sollen jedoch nicht kopiert und in einen anderen Prozess zur Ausführung verschoben werden. Extrem große Objekte mit vielen Methoden lassen sich nicht gut in andere Prozesse kopieren bzw. als Wert in andere Prozesse übergeben. Normalerweise benötigt ein Client lediglich die Informationen, die eine bzw. einige wenige Methoden des Serverobjekts zurückgeben. Durch das Kopieren vollständiger Serverobjekte, wozu auch riesige Mengen an internen Informationen oder ausführbare Strukturen zählen, die nichts mit den Anforderungen des Clients zu tun haben, würde unnötig Bandbreite sowie Arbeitsspeicher des Clients belegt und Verarbeitungszeit aufgewendet. Außerdem legen viele Objekte öffentliche Funktionalität offen, benötigen aber private Daten für die interne Ausführung. Durch das Kopieren dieser Objekte können nicht autorisierte Clients in die Lage versetzt werden, interne Daten zu untersuchen, womit sie zu einem möglichen Sicherheitsrisiko werden. Schließlich verwenden einige Objekte Daten, die nicht auf verständliche Art und Weise kopiert werden können. Ein FileInfo-Objekt enthält z. B. einen Verweis auf eine Datei des Betriebssystems, die über eine eindeutige Adresse im Arbeitsspeicher des Serverprozesses verfügt. Sie können diese Adresse zwar kopieren, aber sie hat keinerlei Funktion in einem anderen Prozess.

In solchen Situationen sollte der Serverprozess anstelle einer Kopie des Serverobjekts einen Verweis auf das Serverobjekt an den Clientprozess übergeben. Clients können diesen Verweis dann verwenden, um das Serverobjekt aufzurufen. Diese Aufrufe werden nicht im Clientprozess ausgeführt. Stattdessen erfasst das Remotingsystem alle Informationen über den Aufruf und sendet diese an den Serverprozess, wo die Informationen interpretiert werden, das korrekte Serverobjekt lokalisiert und der Aufruf für das Serverobjekt im Namen des Clientobjekts ausgeführt wird. Das Ergebnis des Aufrufs wird dann zurück an den Clientprozess übergeben, der wiederum für die Weiterleitung an den Client verantwortlich ist. Bandbreite wird hier lediglich für die wichtigen Informationen benötigt, d. h. den Aufruf, Aufrufargumente und alle Rückgabewerte bzw. Ausnahmen.

Vereinfachte Remotingarchitektur

Kernstück des Remoting ist die Verwendung von Objektverweisen für die Kommunikation zwischen Serverobjekten und Clients. Die Remotingarchitektur bietet jedoch ein noch unkomplizierteres Verfahren für den Programmierer. Wenn Sie den Client ordnungsgemäß konfigurieren, müssen Sie lediglich mit new bzw. der Funktion der verwalteten Programmiersprache zum Erstellen von Instanzen eine neue Instanz des Remoteobjekts erstellen. Der Client empfängt dann einen Verweis auf das Serverobjekt, und Sie können die Methoden so aufrufen, als wäre das Objekt in Ihren Prozess eingebunden, d. h., als würde es nicht auf einem separaten Computer ausgeführt. Das Remotingsystem verwendet Proxyobjekte, die den Eindruck vermitteln, dass sich das Serverobjekt im Clientprozess befindet. Bei Proxys handelt es sich um Ersatzobjekte, die sich selbst als anderes Objekt darstellen. Wenn der Client eine Instanz des Remotetyps erstellt, erstellt die Remotinginfrastruktur ein Proxyobjekt, das für den Client genauso aussieht wie der Remotetyp. Der Client ruft eine Methode für diesen Proxy auf, und das Remotingsystem empfängt den Aufruf, leitet ihn an den Serverprozess weiter, ruft das Serverobjekt auf und gibt den Rückgabewert an den Clientproxy zurück, der wiederum das Ergebnis an den Client übermittelt.

Remoteaufrufe müssen auf die eine oder andere Weise zwischen dem Client und dem Serverprozess übertragen werden. Wenn Sie selbst ein Remotingsystem erstellen möchten, setzen Sie sich am besten zunächst mit der Netzwerkprogrammierung sowie den zahlreichen Protokollen und Spezifikationen der Serialisierungsformate auseinander. Im .NET Remoting-System wird die Kombination aus zugrunde liegenden Technologien zum Öffnen einer Netzwerkverbindung und zum Verwenden eines bestimmten Protokolls zum Übertragen der Bytes an die Empfangsanwendung als Transportchannel dargestellt.

Ein Channel nimmt einen Datenstream auf, erstellt in Übereinstimmung mit einem bestimmten Netzwerkprotokoll ein Paket und sendet dieses an den anderen Computer. Manche Channels können nur Informationen empfangen, andere wiederum nur senden, und wieder andere, wie z. B. die standardmäßige TcpChannel-Klasse und HttpChannel-Klasse, können sowohl Informationen empfangen als auch senden.

Auch wenn dem Serverprozess alle Einzelheiten zu jedem eindeutigen Typ bekannt sind, weiß der Client lediglich, dass er einen Verweis auf ein Objekt in einer anderen Anwendungsdomäne, vielleicht auf einem anderen Computer, benötigt. Außerhalb der Serveranwendungsdomäne wird das Objekt anhand eines URL gefunden. Die URLs, die eindeutige Typen nach außen vertreten, sind Aktivierungs-URLs, mit denen sichergestellt werden kann, dass der Remoteaufruf an den richtigen Typ erfolgt. Weitere Informationen finden Sie unter Aktivierungs-URLs.

Entwurf eines vollständigen Remotingsystems

Angenommen, Sie arbeiten mit einer Anwendung, die auf einem Computer ausgeführt wird, und Sie möchten Funktionen verwenden, die von einem Typ offen gelegt werden, der auf einem anderen Computer gespeichert ist. Die folgende Abbildung veranschaulicht den allgemeinen Remotingprozess.

Remotingprozess

Wenn beide Seiten der Beziehung ordnungsgemäß konfiguriert wurden, erstellt ein Client lediglich eine neue Instanz der Serverklasse. Das Remotingsystem erstellt ein Proxyobjekt, das für die Klasse steht, und gibt an das Clientobjekt einen Verweis auf den Proxy zurück. Wenn ein Client eine Methode aufruft, behandelt die Remotinginfrastruktur den Aufruf, überprüft die Typinformationen und sendet den Aufruf über den Channel an den Serverprozess. Ein Empfangschannel nimmt die Anforderung auf und leitet sie an das Remotingsystem des Servers weiter, das das angeforderte Objekt ausfindig macht bzw. erstellt (falls erforderlich) und aufruft. Der Prozess wird dann umgekehrt ausgeführt, da das Remotingsystem des Servers die Antwort in einer Nachricht bündelt, die über den Serverchannel an den Clientchannel übertragen wird. Zu guter Letzt gibt das Remotingsystem des Clients das Ergebnis des Aufrufs über den Proxy an das Clientobjekt zurück.

Dafür ist nur wenig tatsächlicher Code erforderlich. Dennoch sollten in den Entwurf und die Konfiguration der Beziehung einige Überlegungen gesteckt werden. Der Code kann zwar völlig korrekt sein, aber trotzdem fehlschlagen, da ein URL oder eine Anschlussnummer nicht stimmt. Weitere Informationen finden Sie unter Konfiguration.

Obwohl dieser ausführliche Überblick den Remotingprozess relativ unkompliziert darstellt, gestalten sich die Einzelheiten doch sehr komplex. Eine weiterführende Erläuterung der wichtigen Elemente des Remoting finden Sie in den nachfolgend aufgeführten Themen.

Siehe auch

Übersicht über .NET Remoting | Begrenzungen: Prozesse und Anwendungsdomänen | Remotefähige und nicht remotefähige Objekte | Aktivierung und Lebensdauer von Objekten | Channel | Sicherheit | Konfiguration