Softwareentwicklung mit .NET Teil 6 .NET Remoting Dr. Ralph Zeller

1. Softwareentwicklung mit .NET Teil 6 .NET Remoting Dr. Ralph Zeller

2. Verteilte Applikationen • Früher waren Applikationen eigenständige Einheiten mit wenig Integration. • Heute sind Applikationen in Komponenten aufgeteilt, die miteinander kommunizieren. Applikation Code und Daten

3. Verteilte ApplikationenKommunikation 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)

4. 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

5. 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.

6. 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

7. Appdomains • Eine Appdomain existiert in genau einem Prozess • Ein Prozess kann mehrere AppDomains beinhalten • Aufrufe über AppDomain-Grenzen hinweg erfordert Marshaling Prozess 1 Prozess 2 AppDomain 1 AppDomain 2 AppDomain 3 Objekt Objekt Objekt Objekt Objekt Marshaling Marshaling

8. 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); } }

9. AppDomainBeispiel 1:Fibonacci Zahlen

10. 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(); } }

11. 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

12. MarshalingBeispiel 2:Fibonacci Zahlen

13. Channel Client Server Dis-patcher "Proxy" 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

14. 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.

15. 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

16. 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

17. Zugriff auf Objekte • Remote Objekttypen • Server Konfiguration • Aktivierung und Zugriff • Client Konfiguration

18. 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

19. 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

20. 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");

21. 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>

22. Service & ServerBeispiel 3:FinanzServices

23. 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

24. 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);

25. ClientBeispiel 4:WinHCalc

26. ClientBeispiel 5:ObjRef via File

27. Uff... Fragen?