.NET Remoting

.NET Remoting ist ein umfassendes, erweiterbares Framework für die Entwicklung verteilter Anwendungen und als solches Teil von Microsofts .NET Framework. Es dient der nahtlosen Kommunikation zwischen Objekten, die sich in verschiedenen Applikationsdomänen oder Prozessen bzw. auf unterschiedlichen Computern befinden. Es ermöglicht sozusagen die Kommunikation zwischen Applikationen, die lokal am selben Computer, auf verschiedenen Computern im selben Netzwerk oder sogar auf Computern über mehrere Netzwerke hinweg liegen. .NET Remoting wurde in die Common Language Runtime (CLR) eingebaut. Dadurch sind einheitliche Schnittstellen zu anderen Technologien in .NET gegeben.

.NET Remoting wird von Microsoft mittlerweile als veraltete Technologie bezeichnet und nicht mehr zur Entwicklung verteilter Anwendungen empfohlen. Die empfohlene Nachfolgetechnologie war zunächst die ebenfalls zu .NET gehörige Windows Communication Foundation. Da diese jedoch für .NET Core nicht zur Verfügung steht, empfiehlt Microsoft stattdessen gRPC, das den Vorteil hat, plattformübergreifend zur Verfügung zu stehen.^[1]

Früher wurde die interaktive Kommunikation zwischen Programmen mit DCOM (Distributed COM) durchgeführt, das bei Computern, die sich im selben Netzwerk befinden, problemlos und schnell funktioniert. Sollte aber eine Kommunikation übers Internet stattfinden, müssen mit DCOM enorme Hürden genommen werden. Außerdem ist es kaum möglich, DCOM über eine Firewall zu betreiben, da DCOM versucht, über mehrere Ports, die üblicherweise standardmäßig bei einer Firewall blockiert sind, seine Verbindung aufzubauen.

.NET Remoting merzt die Probleme von DCOM aus, indem es mehrere Protokolle unterstützt.

Mit Remoting ist es, wie bereits oben erwähnt, möglich, verteilte RPC-basierte Objektsysteme zu erstellen. Die Anwendung von Remoting ist denkbar einfach. Die Klassenbibliothek definiert eine Klasse MarshalByRefObject, die Basisklasse für alle verteilten Objekte ist. Will man per Objektreferenz auf eine Instanz einer Klasse über Prozessgrenzen hinweg zugreifen, genügt es, die Klasse von MarshalByRefObject abzuleiten, wie folgendes Beispiel zeigt:

public class Foo: MarshalByRefObject
{
	…
}

Die grundsätzliche Kommunikation in Remotingsystemen ist Remote Procedure Call (RPC)-basiert. Die Architektur von Remoting benennt als wesentliche Elemente:

• Verteilte Objekte,
• Proxys und
• Transportkanäle

Dabei ist jedes dieser Elemente individuell anpassbar und erweiterbar. Verteilte Elemente werden anders als bei DCOM nicht mehr in der Registry von Windows registriert, sondern durch einen so genannten Service Host publiziert. Ein Service könnte beispielsweise

• ein einfaches Konsolen- bzw. Windowsprogramm,
• ein Windows-Systemdienst oder
• der Internet Information Server (IIS) sein.

Anders als bei DCOM müssen die Interfaces der verteilten Objekte nicht mehr in einer IDL (Interface Definition Language) beschrieben werden. Es ist möglich, Interfaces zu verwenden oder einfach die Klasse der verteilten Objekte zu den Clients zu transportieren. Die Verwendung von Interfaces ist dabei besonders attraktiv, da das Interface-Konzept elementarer Bestandteil der Plattformen ist und somit von allen .NET-konformen Sprachen verstanden werden kann.

z. B.: ein C#-Interface könnte auch durch ein Visual Basic.NET-Interface dargestellt werden. Es hat denselben Effekt:

public interface IFoo
{
	void MachWas(string doit);
}

Public Interface IFoo
	Sub MachWas(ByVal doit As String)
End Interface

Wichtig dabei ist, dass das C#-Interface z. B. in einer Visual Basic.NET-Klasse implementiert werden kann oder umgekehrt. Aufgrund der Spracheninteroperabilität der .NET-Plattform können Interfaces bis zu einem gewissen Grad eine IDL vollständig ersetzen.

Proxyobjekte werden bei der Aktivierung eines Remoteobjekts durch einen Client erstellt. Das Proxyobjekt verhält sich wie ein Stellvertreter des Remoteobjekts. Es stellt sicher, dass alle für den Proxy gesendeten Aufrufe an die richtige Remoteobjektinstanz weitergeleitet werden. Wenn ein Client ein Remoteobjekt aktiviert, erstellt das Framework eine lokale Instanz der TransparentProxy-Klasse, die eine Liste aller Klassen sowie der Schnittstellenmethoden des Remoteobjekts enthält. Da die TransparentProxy-Klasse beim Erstellen der CLR registriert wird, werden alle Methodenaufrufe für den Proxy von der CLR abgefangen. Hier wird der Aufruf untersucht, um zu ermitteln, ob es sich um eine zulässige Methode des Remoteobjekts handelt und ob sich eine Instanz des Remoteobjekts in derselben Anwendungsdomäne wie der Proxy befindet. Ist dies der Fall, wird ein einfacher Methodenaufruf an das eigentliche Objekt weitergeleitet. Befindet sich das Objekt in einer anderen Anwendungsdomäne, werden die Aufrufparameter im Stapel in ein IMessage-Objekt gepackt und an die RealProxy-Klasse über den Aufruf ihrer Invoke-Methode weitergeleitet. Diese Klasse (oder vielmehr eine interne Implementierung der Klasse) ist für die Weiterleitung der Meldungen an das Remoteobjekt zuständig. Sowohl die TransparentProxy-Klasse als auch die RealProxy-Klasse werden bei der Aktivierung eines Remoteobjekts geschützt erstellt, aber nur TransparentProxy wird an den Client zurückgegeben. TransparentProxy ist eine interne Klasse, die nicht ersetzt oder erweitert werden kann. Die RealProxy-Klasse und die ObjRef-Klasse sind wiederum öffentlich und können bei Bedarf erweitert und angepasst werden. Die RealProxy-Klasse ist z. B. ein idealer Kandidat für die Durchführung des Lastenausgleichs, da sie alle Funktionsaufrufe für ein Remoteobjekt bearbeitet. Wenn Invoke aufgerufen wird, kann eine von RealProxy abgeleitete Klasse Informationen zur Belastung von Servern im Netzwerk abrufen und den Aufruf an den entsprechenden Server weiterleiten.

Auf entfernte Objekte („Remote objects“) wird mittels so genannten Channels zugegriffen. Channels transportieren die Nachricht zum Objekt hin oder vom Objekt weg. Es gibt zwei Channel, die wichtig sind: TcpChannel und HttpChannel. Diese können auch abgeleitet werden, sodass ein eigener Channel nach seinen Bedürfnissen erstellt werden kann.

Wie bereits anfangs erwähnt, gibt es das MarshalByRefObject, von dem die Klasse abgeleitet sein muss. Jedoch gibt es zwei unterscheidbare Vorgangsweisen, wie entfernte Objekte erstellt werden können:

• Objekterzeugung durch Server (Server-activated objects)
• Objekterzeugung durch Client (Client-activated objects)

Bei Server-activated objects (SAO) werden die Objektinstanzen im Server erzeugt. Alternative Verfahren wären hierbei:

• Single-call object
  • bei jedem Aufruf wird ein neues Objekt erzeugt und danach zerstört
  • auf Server-Farmen kann dadurch die Last verteilt werden
• Singleton object
  • es gibt eine einzige Objektinstanz für alle Clients
  • Objekt wird mit Serverstart erzeugt
• Published object

Bei Client-activated objects (CAO) erzeugt der Client die Objekte: Alternative Verfahren wären:

• direkte Erzeugung
• Erzeugung über Fabrik (Factory)

Eine neuere Version (.NET Remoting 2.0) ist bereits vorhanden, die Unterstützung für IPv6-Adressen und den Austausch der generischen Typen bietet. Neu ist auch der Remoting-Channel IPC für die lokale Inter-Prozess-Kommunikation ohne Verwendung eines Netzwerkprotokollstacks.

• Ingo Rammer: Advanced .NET Remoting, Apress 2005, ISBN 978-1-59059-417-9

• Übersicht über .NET Framework-Remoting in der MSDN-Library-Dokumentation zum .NET Framework
• PDF-Datei über Remoting (PDF-Datei; 259 kB)
• PDF-Datei über .NET allgemein, behandelt auch Remoting (PDF-Datei; 201 kB)

1. ↑ shirhatti: Einführung: GrpC für WCF-Entwickler. Abgerufen am 28. November 2019 (deutsch).