Transcript .NET Remoting

Softwareentwicklung mit .NET
Teil 6
.NET Remoting
Dr. Ralph Zeller
1
Verteilte Applikationen

Früher waren Applikationen eigenständige Einheiten
mit wenig Integration.
Applikation
Code und Daten

Heute sind Applikationen in Komponenten aufgeteilt,
die miteinander kommunizieren.
2
Verteilte Applikationen
Kommunikation im Netzwerk

Kommunikation unter Server Applikationen
•
•
•
•
•
Manche sind in der Nähe (Intranet)
Manche weiter weg (Internet)
Manche hinter Firewalls
Manche benutzen gleiche Protokolle (HTTP,
SOAP), laufen aber auf unterschiedlichen
Plattformen
Manche benutzen gleiche Protokolle und laufen
auf derselben Plattform (z.B. .NET)
3
Verteilte .NET App.


Zwischen .NET und Non-.NET Applikationen
•
•
Verwende Web Service Protokolle
HTTP, SOAP, WSDL
Zwischen .NET Applikationen
•
•
•
•
Verwende wenn möglich Binärprotokolle
Binär = High Speed
Verwende wenn nötig Web Service Protokolle
HTTP um Firewalls zu überwinden
4
Was ist .NET Remoting?

Remoting ist der Zugriff auf Objekte über
Grenzen hinweg.

Grenzen können unterschiedliche
Maschinen, Prozesse, Application Domains
oder Kontexte sein.

Marshaling heißt Objekte für den Transport
über Grenzen hinweg aufzubereiten.
5
Appdomains

Die CLR abstrahiert OS-Prozesse und
arbeitet mit „virtuellen Prozessen“

Isolierter Ausführungsraum für
Anwendungen

Unabhängig vom OS Konzept für Prozesse
und Threads

Diese virtuellen Prozesse werden
Appdomains genannt

Appdomains dienen als
„Ausführungscontainer“ für Assemblies
6
Appdomains
•
•
•
Eine Appdomain existiert in genau einem Prozess
Ein Prozess kann mehrere AppDomains beinhalten
Aufrufe über AppDomain-Grenzen hinweg erfordert
Marshaling
Prozess 2
Prozess 1
AppDomain 1
AppDomain 2
Objekt
AppDomain 3
Objekt
Objekt
Objekt
Objekt
Marshaling
Marshaling
7
AppDomain erzeugen
•
•
•
Erzeuge neue AppDomain im aktuellen Prozess
Führt Assembly in neuer AppDomain aus
Aufruf blockiert Main Methode, bis yourapp.exe
beendet ist
using System;
public class MyApp
{
public static int Main(string[] args)
{
AppDomain child = AppDomain.CreateDomain("childapp",
null, null);
return child.ExecuteAssembly("yourapp.exe", null, args);
}
}
8
AppDomain
Beispiel 1: Fibonacci Zahlen
9
Objekte und AppDomains
•
•
•
CreateInstance erzeugt ein Objekt „Target“ in der
AppDomain „sandbox“
Rückgabe ist ein Objekthandle
Unwrap() erzeugt ein Proxy Objekt, über das auf
„Target“ zugegriffen wird
using System;
using System.Runtime.Remoting;
public class MyApp {
public static int Main(string[] args) {
AppDomain child = AppDomain.CreateDomain("sandbox",
null,null);
ObjectHandle oh = child.CreateInstance("foolib",
"Target");
Target t = (Target)oh.Unwrap();
t.DoSomethingInteresting();
}
}
10
AppDom. und Marshaling

Aufrufe über Domaingrenzen hinweg erfordert
Marshaling

Marshal by value:
•
•
•
•

Kopie des gesamten Objekts wird ans Ziel gesendet
Keine Beziehung zum Original
Klassen müssen mit dem Attribut [serializable]
versehen werden
oder das ISerializable Interface implementieren
Marshal by reference:
•
•
•
Objektreferenz wird ans Ziel gesendet
Proxy verknüpft Referenz und Original
Wird durch Ableitung einer Klasse von
System.MarshalByRefObject erreicht
11
Marshaling
Beispiel 2: Fibonacci Zahlen
12
Remoting Arichtektur

Messages: Was wird gesendet

Channels: Wohin wird es gesendet

Formatter: Wie wird es gesendet

Proxy

•
Erzeugt aus Meth.aufrufen des Clients Messages
Dispatcher
•
Generiert am Server aus Messages Meth.aufrufe
Client
"Proxy"
Channel
Server
Dispatcher
13
Was: Messages



Messages sind Objekte
•
•
implementieren IMessage Interface
einfache Wertetabellen {Schlüssel, Wert}
.NET Messagetypen:
•
•
•
Konstruktoraufrufe
Methodenaufrufe
Vordefinierte Typen haben vordefinierte Einträge
in der Wertetabelle
Aufrufvarianten
•
•
Synchron: Aufruf mit sofortiger Antwort
Asynchron: Aufruf mit verzögerter oder fehlender
Antwort.
14
Wohin: Channels

Channels transportieren Messages

TCP Channel



•
•
Für schnelle LAN Kommunikation
Permanente Socket Verbindung
HTTP Channel
•
•
Für Kommunikation über Internet
Keine permanente Verbindung notwendig
Custom Channels
•
IPX, Pipes
Channels können Sinks implementieren
•
•
•
Zum Überwachen und Logging
Erweiterte Sicherheitsprüfungen
Messages komprimieren
15
Wie: Formatter
•
•
•
Formatter serialisieren .NET Objekte in ein spezielles
Wire-Format
• .NET Formatter: SOAP und binärer Formatter
• eigene Formatter: IIOP, RMI, ORPC
Werden von Channels dynamisch verwendet
Wahl des Channels und Formatters hängt vom
Unternehmensumfeld ab
SOAP, Binary,
eigene Formate
Dekodieren aus
Wire-Format
Channel
Kodieren ins
Wire-Format
16
Zugriff auf Objekte
 Remote
 Server
Objekttypen
Konfiguration
 Aktivierung
 Client
und Zugriff
Konfiguration
17
Remote Objekttypen

Well known Objects (Server activated)
•
•

Singleton
• Es gibt eine einzige Objektinstanz für alle Clients
• Objekt wird mit Serverstart erzeugt
Single-call
• Bei jedem Aufruf wird ein neues Objekt erzeugt
und danach zerstört
• Auf Server Farmen kann dadurch die Last verteilt
werden
Client-Activated Objects
•
Jeder Client bekommt sein eigenes Objekt
18
Well Known Objects

Server meldet Objekt im System an

Clients verbindet sich mit dem Objekt

Konfiguration über Files oder im Code über
Methodenaufrufe

.NET Aktivierungsmodell ist nicht wie COM
•
•
.NET ist eher wie CORBA (!)
• ohne aktiven Endpunkt (Serverdienst) gibt es
keine Verbindung
• Keine Registry Einträge
• .exe Server kann nicht remote-aktiviert werden
Vereinfacht Remoting wesentlich
19
Server konfigurieren

Konfiguration im Sourcecode
// Channel mit HTTP als Transportprotokoll erzeugen
// und auf Port 61500 anmelden.
// Der Default Formatter des HTTP Channels ist SOAP.
HttpChannel httpChannel = new HttpChannel(65100);
ChannelServices.RegisterChannel(httpChannel);
// Das Well Known Objekt "FinanzServices" wird angemeldet.
// Das Objekt wird über den Endpunt "FService" angesprochen.
RemotingConfiguration.RegisterWellKnownServiceType (
typeof(FinanzServices),
"FService",
WellKnownObjectMode.Singleton );

Konfiguration über .config Datei
RemotingConfiguration.Configure("FService.exe.config");
20
Server .config Datei
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode="Singleton"
type="FinazServices, FService"
objectUri="FService" />
</service>
<channels>
<channel port=65100 ref="http">
<serverProviders>
<formatter ref="binary" />
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
21
Service & Server
Beispiel 3: FinanzServices
22
Service Interface

Client benötigt Informationen über die
Remote Klasse
•
•


Methodennamen, Parameter, Rückgabewert
Werden zur Compile- und Laufzeit benötigt
Interface enthält diese Informationen
•
•
Client referenziert Interface
Remote Klasse implementiert Interface
SoapSuds.exe generiert Interface
Soapsuds.exe –ia:FService –nowp –oa:FSInterface.dll
23
Client konfigurieren

Aufruf über Activator Klasse
•
Konfiguration im Source
// Activator.GetObject() liefert einen Proxy des
// remote Objekts.
FSInterface FS = (FSInterface)Activator.GetObject (
typeof(FSInterface),
// Typ des remote Objekts
"http://localhost:65100/FService" ); // Endpunkt
•
Konfiguration über .config Datei
RemotingConfiguration.Configure("WinHCalc.exe.config");
Type type = RemotingConfiguration.
GetRegisteredWellKnownClientTypes()[0].ObjectType;
String url = RemotingConfiguration.
GetRegisteredWellKnownClientTypes()[0].ObjectUrl;
FSInterface FS = (FSInterface)Activator.GetObject(type, url);24
Client
Beispiel 4: WinHCalc
25
Client
Beispiel 5: ObjRef via File
26
Fragen?
Uff...
27