.NET Remoting - Begriffserklärung im Entwickler-Lexikon/Glossar auf www.IT-Visions.de

Was ist .NET Remoting ?

.NET Remoting ein proprietäres Fernaufrufkonzept der Firma Microsoft im Rahmen des Microsoft .NET Framework, ver-gleichbar mit Remote Method Invocation (RMI) in Java. Anders als der Vorgänger Distributed Component Object Model (DCOM) ist .NET Remoting aber nicht auf ein bestimmtes Über-tragungsformat und -protokoll festgelegt und bietet eine Vielzahl von Aktivierungs- und Konfigurationsoptionen.

.NET Remoting wird von vielen Verfechtern der losen serviceorientierten Kopplung wegen seiner engen Kopplung kritisiert. In der in .NET 3.0 enthaltenen Kommunikationsinfrastruktur Indigo wird das .NET Re-moting-Modell nur noch in wenigen Teilen vertreten sein.
Anders als der Vorgänger DCOM ist .NET Remoting nicht auf ein bestimmtes Übertragungsformat und -protokoll festgelegt und bietet eine Vielzahl von Aktivierungs- und Konfigurationsoptionen.

Der Kern des .NET Remoting ist in der mscorlib.dll und der System.Runtime.Remoting.dll implementiert.

Enge Bindung

.NET Remoting unterscheidet zwischen der Objektübergabe By-Reference- oder By-Value. Außerdem wird unterschieden zwischen Objekt mit Server-Aktivierung (Server-Activated Objects – SAO, auch: Well Known Types) und Objekten mit Client-Aktivierung (Client-Activated Objects – CAO, auch: Activated Types).

Im CAO-Fall ist immer (sowohl im By-Value als auch By-Reference-Fall) eine Klasse zu verwenden – die Aktivierung ist über die Schnittstelle alleine nicht möglich. Der Objekttyp kann im SAO-Fall dem Client durch eine Klasse oder eine Schnittstelle bekannt gegeben werden. Die Nutzung einer Schnittstelle hat den Vorteil, dass der Client nur die Schnittstelle kennen muss, nicht die eigentliche Implementierung. SAO ist allerdings mit einem Call-by-Reference möglich.

Bei den server-aktivierten Objekten unterscheidet man ferner zwischen zwei Fällen:

Single Call: Bei jedem Methodenaufruf wird eine neue Objektinstanz erzeugt. Folglich müssen die Objekte zustandslos sein, da zwei nachfolgende Methodenaufrufe nicht das gleiche Objekt erreichen.
Singleton: In diesem Fall existiert nur eine Objektinstanz, bei der alle Client-Objekte ein und dasselbe Server-Objekt verwenden. Ein solches Objekt eignet sich z. B. zum Austausch von Daten zwischen Clients.

Bei der Client-Aktivierung erhält der Client die Kontrolle über Art und Anzahl der Server-Objekte. Hier wird bei jeder Instanziierung im Client ein zugehöriges Objekt auf dem Server erzeugt, d. h. die Anzahl der Objekte, die der Client sieht, entspricht der Anzahl der Objekte auf dem Server.

Protokolle und Formate

Anders als der Vorgänger DCOM ist .NET Remoting nicht auf ein bestimmtes Übertragungsformat und -protokoll festgelegt und bietet eine Vielzahl von Aktivierungs- und Konfigurationsoptionen.

Zur Übertragung des Fernaufrufs verwendet .NET Remoting Formatter und Channels:

Ein Formatter ist ein Mechanismus, der ein Objekt in einen Byte-Strom umzuwandelt bzw. zurückwandelt. Man spricht in diesem Zusammenhang von Serialisierung bzw. Deserialisierung. .NET 2.0 enthält einen binären und einen SOAP-Formatter.
Ein Channel bietet ein Transportmedium für serialisierte Objekte an. .NET 2.0 enthält TCP, HTTP, IPC (Inter-Prozess-Kommunikation) sowie einen Application-Domain-internen Channel.

Unterschiede zu den Webservices

Hinsichtlich der Performanz ist .NET Remoting über TCP mit dem binären Formatter wesentlich performanter als über HTTP/SOAP. Auch HTTP/binär ist schneller als HTTP/SOAP. Remoting über HTTP/SOAP ist ähnlich performant wie XML-Webservices. Keines der vorgenannten Verfahren ist jedoch so schnell wie DCOM.

Unterschiede zu den Webservices

.NET Remoting mit dem SOAP-Formatter über HTTP ist nicht gleichzusetzen mit XML-Webservices, auch wenn dort ebenfalls SOAP und HTTP zum Einsatz kommen. .NET Remoting mit SOAP/HTTP ist nur unter bestimmten Voraussetzungen kompatibel mit XML-Webservices (siehe [MSDN12]). .NET Remoting nutzt das so genannte »RPC-codierte« SOAP, das nicht Teil des Basic Profile der Web Services Interoperability Organization (WS-I) ist. Die Bereitstellung von XML-Webservices via .NET Remoting beschränkt daher die Interoperabilität zu anderen Plattformen und die daher nicht zu empfehlen.

Hosting

Damit ein Objekt für Remoting-Clients überhaupt erreichbar ist (also die Funktionalitäten zur Verfügung stellt, die das Objekt zum Server macht), muss der Server in einem Host-Prozess angeboten werden. Unter COM hat die Laufzeitumgebung selbst einen universellen Host angeboten – das .NET Framework stellt einen solchen Host-Prozess nicht zur Verfügung. Unter .NET existieren für das Hosting folgende Optionen:

Entwicklung eines eigenen Host (z. B. in Form einer Konsolenanwendung oder eines Windows-Dienstes)
Nutzung des Internet Information Server (IIS)
Nutzung des COM+ Application Servers (alias .NET Enterprise Services)

Weitere Möglichkeiten

Deklarative Remoting-Konfiguration: Neben der Konfiguration von Client und Server durch Programmcode ist alternativ auch eine Konfiguration innerhalb einer XML-Anwendungskonfigurationsdatei möglich. Die deklarative und die programmatische Konfiguration können parallel angewendet werden, d. h. eine Anwendung kann auch noch weitere Ports im Programmcode deklarieren, obwohl bereits eine Konfigurationsdatei eingelesen wurde.
Lebensdauer: In DCOM verwendet ein Server die Referenzzählung seiner Clients und ein Client einen periodischen Ping, um die fortwährende Existenz des Servers zu prüfen. .NET Remoting vermeidet den Netzwerk-Overhead durch einen Lebensdauer-Mechanismus mit Leihdauer (Lease). Jedes Objekt ist mit einer Time-to-Live (TTL) versehen, die heruntergezählt wird. Die Standard¬lebensdauer beträgt fünf Minuten. Ein Server-Objekt kann die Dauer aber auf andere Werte setzen (auch auf »unendlich«). Die Lebensdauer eines Objekts kann durch einen erneuten Methodenaufruf oder durch so genannte Sponsoren verlängert werden.
Austausch generischer Datentypen: Ab .NET 2.0 unterstützt .NET Remoting auch generische Datentyoen
Authentifizierung und Verschlüsselung: Ab .NET 2.0 wird in TCP- und IPC-Channel Authentifizierung und Verschlüsselung untersützt. In .NET 1.x gab es keinerlei Sicherheitsfunktionen.
Zugriffsrechtelisten: Der in .NET 2.0 neu eingeführte IPC-Channel unterstützt auch Zugriffsrechtelisten (ACLs).