.NET Framework-Remotearchitektur

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.

Die .NET-Remoteinfrastruktur ist ein abstrakter Ansatz zur prozessübergreifenden Kommunikation. Objekte, die über den Wert übergeben oder kopiert werden können, werden zwischen den Anwendungen in verschiedenen Anwendungsdomänen oder auf verschiedenen Computern automatisch übergeben. Markieren Sie die benutzerdefinierten Klassen als serialisierbar, damit dies funktioniert.

Die wahre Stärke des Remotesystems besteht jedoch in seiner Fähigkeit, eine Kommunikation zwischen Objekten in verschiedenen Anwendungsdomänen oder Prozessen unter Verwendung verschiedener Transportprotokolle, Serialisierungsformate, Schemas für die Objektlebensdauer und Objekterstellungsmodi zu ermöglichen. Remoting macht außerdem einen Eingriff in fast jeder Phase des Kommunikationsprozesses möglich.

Ob Sie nun eine Reihe verteilter Anwendungen implementiert haben oder zur Verbesserung der Skalierbarkeit Ihres Programms Komponenten auf andere Computer verschieben möchten, ist es am einfachsten, wenn Sie das Remotesystem als generisches System zur prozessübergreifenden Kommunikation mit einigen Standardimplementierungen verstehen, die mit den meisten Szenarien problemlos umgehen können. Die folgende Abhandlung beginnt mit den Grundlagen der prozessübergreifenden Kommunikation unter Verwendung des Routings.

Kopien im Vergleich zu Verweisen

Eine prozessübergreifende Kommunikation erfordert ein Serverobjekt, dessen Funktion Aufrufern außerhalb des Prozesses bereitgestellt wird, einen Client, der Aufrufe des Serverobjekts durchführt, und einen Transportmechanismus, der die Aufrufe zwischen den Endpunkten überträgt. Die Adressen der Servermethoden sind logisch und funktionieren in einem Prozess ordnungsgemäß, in einem anderen Clientprozess aber nicht. Um dieses Problem zu umgehen, kann ein Client ein Serverobjekt aufrufen, indem er eine Kopie des gesamten Objekts erstellt und es zum Clientprozess verschiebt, wo die Methoden der Kopie direkt aufgerufen werden können.

Viele Objekte können oder dürfen jedoch nicht kopiert und zur Ausführung zu einem anderen Prozess verschoben werden. Extrem große Objekte mit vielen Methoden dürfen nicht kopiert oder über den Wert an andere Prozesse übergeben werden. In der Regel benötigt ein Client nur die Informationen, die von einer oder ein paar Methoden des Serverobjekts zurückgegeben werden. Das gesamten Serverobjekt mit möglicherweise riesigen Mengen an internen Informationen oder ausführbaren, nicht in Zusammenhang mit den Anforderungen des Clients stehenden Strukturen zu kopieren, wäre nicht nur eine Verschwendung von Bandbreite, sondern auch von Clientspeicher und Verarbeitungszeit. Außerdem machen viele Objekte öffentliche Funktionen verfügbar, erfordern aber private Daten zur internen Ausführung. Durch das Kopieren dieser Objekte könnten nicht autorisierte Clients interne Daten untersuchen und damit das Potenzial für Sicherheitsprobleme schaffen. Schließlich verwenden manche Objekte Daten, die auf keine verständliche Weise kopiert werden können. So enthält z. B. ein FileInfo-Objekt einen Verweis auf eine Betriebssystemdatei, die eine eindeutige Adresse im Speicher des Serverprozesses besitzt. Sie können diese Adresse zwar kopieren, sie ist in einem anderen Prozess jedoch nicht gültig.

In diesen Situationen muss der Serverprozess dem Clientprozess einen Verweis auf das Serverobjekt und keine Kopie des Objekts übergeben. Clients können das Serverobjekt mit diesem Verweis aufrufen. Diese Aufrufe werden im Clientprozess nicht ausgeführt. Stattdessen sammelt das Remotesystem alle Informationen über den Aufruf und sendet sie an den Serverprozess, wo die Informationen interpretiert werden und das richtige Serverobjekt gesucht und im Auftrag des Clientobjekts aufgerufen wird. Das Ergebnis des Aufrufs wird anschließend an den Clientprozess zur Rückgaben an den Client zurückgesendet. Die Bandbreite wird nur für die wichtigen Informationen (Aufruf, Aufrufargumente und Rückgabewerte oder Ausnahmen) verwendet.

Vereinfachte Remotearchitektur

Die Verwendung von Objektverweisen für die Kommunikation zwischen Serverobjekten und Clients ist das Herzstück des Remotings. Die Remotearchitektur bietet dem Programmierer jedoch eine einfachere Prozedur. Wenn Sie den Client richtig konfigurieren, erstellen Sie mit new (oder der Erstellungsfunktion für Instanzen Ihrer verwalteten Programmiersprache) einfach eine neue Instanz des Remoteobjekts. Ihr Client erhält einen Verweis auf das Serverobjekt, und Sie können seine Methoden anschließend so aufrufen, als ob sich das Objekt in Ihrem Prozess befände und nicht auf einem separaten Computer. Das Remotesystem vermittelt mit Proxyobjekten den Eindruck, dass sich das Serverobjekt im Prozess des Clients befindet. Proxys sind Objekte, die sich als ein anderes Objekt ausgeben. Wenn der Client eine Instanz des Remotetyps erstellt, erstellt die Remoteinfrastruktur ein Proxyobjekt, das für den Client genau wie der Remotetyp aussieht. Der Client ruft eine Methode für diesen Proxy auf, das Remotesystem 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 das Ergebnis an den Client zurückgibt.

Remoteaufrufe müssen zwischen dem Client und dem Serverprozess auf irgendeine Weise übermittelt werden. Wenn Sie selbst ein Remotesystem erstellen würden, müssten Sie sich unter Umständen zunächst Kenntnisse über die Netzwerkprogrammierung sowie eine Vielzahl von Protokollen und Spezifikationen für Serialisierungsformate aneignen. Im .NET-Remotesystem wird die Kombination der zugrunde liegenden Technologien, die zum Öffnen einer Netzwerkverbindung und zum Verwenden eines bestimmten Protokolls erforderlich sind, um die Bytes zur Empfangsanwendungen zu senden, als Transportchannel dargestellt.

Ein Channel ist ein Typ, der einen Datenstream nimmt, ein Paket entsprechend einem bestimmten Netzwerkprotokoll erstellt und das Paket an einen anderen Computer sendet. Manche Channels können nur Informationen empfangen, andere können nur Informationen senden und wieder andere, wie die TcpChannel-Standardklasse und die HttpChannel-Standardklasse, können für beide Richtungen verwendet werden.

Der Serverprozess weiß alles über jeden eindeutigen Typen, während der Client nur weiß, dass er einen Verweis auf ein Objekt in einer anderen Anwendungsdomäne möchte, die sich möglicherweise auf einem anderen Computer befindet. Außerhalb der Serveranwendungsdomäne sucht eine URL nach dem Objekt. Die URLs, die nach außen hin eindeutige Typen darstellen, sind Aktivierungs-URLs. Diese stellen sicher, dass der Remoteaufruf für den richtigen Typ erfolgt. Weitere Informationen finden Sie unter Aktivierungs-URLs.

Umfassendes Remotesystemdesign

Angenommen, Sie haben eine auf einem Computer aktive Anwendung und möchten eine Funktion nutzen, die von einem auf einem anderen Computer gespeicherten Typ verfügbar gemacht wird. Die folgende Abbildung veranschaulicht den allgemeinen Remoteprozess.

Wenn beide Seiten der Beziehung ordnungsgemäß konfiguriert sind, erstellt ein Client lediglich eine neue Instanz der Serverklasse. Das Remotesystem erstellt ein Proxyobjekt, das die Klasse darstellt, und gibt einen Verweis auf den Proxy an das Clientobjekt zurück. Wenn ein Client eine Methode aufruft, verarbeitet die Remoteinfrastruktur den Aufruf, überprüft die Typinformationen und sendet den Aufruf über den Channel zum Serverprozess. Ein Überwachungschannel nimmt die Anforderung auf und leitet sie an das Remotesystem des Servers weiter, das das angeforderte Objekt sucht (oder bei Bedarf erstellt) und aufruft. Anschließend wird der Prozess umgekehrt: Das Remotesystem des Servers packt die Antwort in eine Nachricht, die der Serverchannel an den Clientchannel sendet. Zum Schluss gibt das Remotesystem des Clients das Ergebnis des Aufrufs über den Proxy an das Clientobjekt zurück.

Damit dies funktioniert, ist nur sehr wenig eigentlicher Code erforderlich, allerdings sollten Sie sich Gedanken über das Design und die Konfiguration der Beziehung machen. Der Code kann völlig richtig sein und doch fehlschlagen, weil eine URL oder eine Anschlussnummer falsch ist. Weitere Informationen finden Sie unter Konfiguration.

Diese grobe Übersicht über den Remoteprozess ist zwar recht einfach, die Details auf niedrigerer Ebene können aber ziemlich komplex sein. Die Hauptelemente des Remotings werden in anderen, im folgenden Abschnitt aufgeführten Themen ausführlicher behandelt.

Siehe auch

Konzepte

Grenzen: Prozesse und Anwendungsdomänen
Remotefähige und nicht remotefähige Objekte
Channels
Sicherheit beim Remoting
Konfiguration von Remoteanwendungen

Weitere Ressourcen

Übersicht über .NET Framework-Remoting
Objektaktivierung und Lebensdauer