.NET Remoting und XML Web Services

1. .NET Remoting und XML Web Services

2. .NET Remoting und XML Web Services Ralf Westphal ralfw@ralfw.de

3. Architekturtriebfedern • Wartbarkeit • Leistung • Integration • Robustheit • Stabilität • Sicherheit

4. Triebfeder Wartbarkeit • Wunschliste • Flexibilität • Transparenz • Einfaches Deployment • Lösung • Schichtung • Modularisierung

5. UI Geschäftslogik (GL) Datenbankzugriff UI Geschäftslogik (GL) Datenbankzugriff Schichtung/Modularisierung • Horizontale Aufteilung (Schichtung) • „Separation of Concerns“ • UI • Geschäftslogik • Datenbankzugriff • Vertikale Aufteilung • Komponenten • Objekte • Entkopplung

6. knapp CPU DB Ressourcen Hauptspeicher Festplattenspeicher reichhaltig Durchsatz (tx/sec) Skalierbarkeit Ressourcen Triebfeder Leistung • Wunschliste • Hohe Leistung (Durchsatz) • Leistung = Arbeit / Zeit • Abhängig von Ressourcenverfügbarkeit • Einfache Leistungssteigerung • Lösung • Skalierbare Architektur • Skalierbarkeit: Wie verändert sich der Durchsatz bei Addition von Ressourcen? (Clientzahl konstant)

7. Architekturen I • 1 Schicht • Dateibasierte Datenbank (z.B. Jet Engine) • Pro • Einfach • Con • Nicht skalierbar • Hohe Netzwerklast • Imperformante Zugriffssynchronisation • DB-Konsistenz von Clients abhängig Netzwerk Client

8. Architekturen II • 2 Schichten (Client/Server) • Serverbasierte Datenbank (z.B. SQL Server) • Pro • Geringere Netzwerklast • „Scale up“ möglich (Aufstocken des DB-Servers) • Einfachere Zugriffsynchronisation • Con • Komplexe Geschäftslogik bei vielen Clients • Hoher Server-Ressourcenverbrauch durch viele Clients Netzwerk Client DB Server

9. Architekturen III • 3 Schichten • Zentrale Geschäftslogik • Pro • Noch geringere Netzwerklast • „Scale out“ möglich (Hinzufügen von Applikationsservern) • Geringer DB-Ressourcenverbrauch durch zustandslose zentrale Logik • Einfachere Deployment zentraler Logik • Dient Triebfedern Wartbarkeit, Robustheit, Sicherheit • Con • Erfordert verändertes Programmiermodell Host Client DB Server GL Netzwerk

10. Architekturen IIIa • 3 Schichten mit Load Balancing • Geschäftslogik läuft auf mehreren Applikationsservern GL Client DB Server Netzwerk Load Balacing GL GL

11. Triebfeder Integration • Wunschliste • Anbindung von „Legacy Code“ • Anbindung von Code auf anderen Plattformen • Prozessor • Betriebssystem • Entwicklungsplattform • Anwendungsteile sind per definitionem verteilt • Lösung • Kommunikationstechnologie auf Basis des kleinsten gemeinsamen Nenners

12. Host GL Thema heute • Verteilte Anwendungen sind kein Selbstzweck • Erfordern modulare Architektur • Voraussetzung für Skalierbarkeit • Voraussetzung für Integration Client DB Server Netzwerk

13. Technische Herausforderungen • Verteilung • Methodenaufrufe über Speichergrenzen hinweg • Transport von Methodenaufrufen zw. Client & Server • Integration • Plattformunabhängigkeit • Dienstbeschreibung • Methodenaufrufformat

14. Messagebasierte Kommunikation • Übertragung von Methodenaufrufen als Nachrichten • Serialisierung des Call Stack beim Client (Marshaling) • Transport der Message zum Server • Deserialierung & Rekonstruktion des Call Stack (Unmarshaling) • dito für Rückgabewerte Server Client Netzwerk Objekt TP Call Stack RP Serialisierter Call Stack Call Stack

15. Implikationen I • Typen von Parametern/Rückgabewert müssen serialisierbar sein • kein Problem für skalare Typen • für viele BCL-Typen kein Problem (z.B. ArrayList) • eigene Typen als [Serializable()] kennzeichnen • Methodenaufrufe dauern sehr lang! • Anzahl Methodenaufrufe minimal halten • „Chunky statt chatty“ Interfaces • Widerspricht z.T. OOP • Fördert Skalierbarkeit, weil weniger Wert auf objektinternen Zustand gelegt wird

16. Demo • Serialierbarer Typ • „Chunky statt chatty“ Interface

17. Implikationen II • (Un)Marshaling sollte automatisch und transparent ablaufen • Entfernte Typen von MarshalByRefObject ableiten • Proxys beim Client werden automatisch erzeugt

18. Demo • Entfernter Typ • Transparent Proxy

19. Kommunikation über Speichergrenzen hinweg • Kommunikationsmedium • Über Speichergrenzen hinweg • Physikalisch • Prozess • Maschine • Logisch • AppDomain (intra-Prozess) • Context (intra-AppDomain) • keine Isolierung • Netzwerk, Shared Memory, ... • Host • Welche Anwendungen können entfernte Komponenten hosten? • .NET Remoting: Jede Anwendung • XML Web Service: IIS & jede Anwendung • Serviced Components: Applikationsserver (COM+)

20. Implikationen III • Einigung auf Kommunikationskanal • .NET Framework bietet zwei Kanäle (Channel) • TCP • HTTP • Einigung auf Messageformat • .NET Framework bietet zwei Formate • Binär • SOAP • Kanäle und Formate können erweitert werden

21. Demo • Verteilte Anwendung mit Client und Server

22. Lebensdauer entfernter Objekte • GC funktioniert nicht • Einem Server sind die Wurzeln seiner Objekte in Clients nicht bekannt • Lösung: Verschiedene Lebensdauermodelle • Server bestimmt Lebensdauer (well known Objects) • SingleCall • Singleton • Client bestimmt Lebensdauer (client activated Objects) • Objekte mit Verfallsdatum • Lease Based Lifetime • Singleton • Client activated Objects

23. Demo • SingleCall • Singleton • Client Activated Object

24. Transparente Verteilung • Konfigurationsdateien bei Client & Server • Kanal & Protokoll • Veröffentlichte Typen • Lifetime • 1 Zeile Code in Client & Host

25. Pro/Con Remoting • Pro • Simpel • Erweiterbar • max. Transparenz • Con • Keine Security • Keine Transaktionen • Fixer ThreadPool

26. Kommunikation mit Unbekannt • Keine Kontrolle über... • Client (Delphi?, Java?, C++?, Linux? ...) • Server (Cobol?, Java?, Unix?, Mac? ...) • Unwägbarkeiten • Prozessor • Betriebssystem • Entwicklungsplattform • Kommunikation erfordert kleinsten gemeinsamen Nenner • Kanal: TCP/IP + HTTP (=Text) • Kodierung beim Marshaling: SOAP (=Text (XML)) • Schnittstellenbeschreibung: WSDL (=Text (XML))

27. Veröffentlichung von Diensten • .NET Remoting • HTTP-Kanal • SOAP-Formatierer • XML Web Services • ASP.NET „Seite“ • Definiert Methoden • Typen müssen serialisierbar sein • Immer SingleCall • Host ist IIS

28. XML Web Services definieren • Service-Klasse • Kennzeichnen mit [WebService] • Ableiten von System.Web.Services.WebService • Service-Methode • Kennzeichnen mit [WebMethod] • Transaktionen möglich • WSDL wird automatisch generiert

29. Demo • XML Web Service definieren

30. XML Web Service Client • Referenz auf XML Web Service setzen • Web Service-Aufruf über Proxy-Klasse • Wird autom. aus WSDL generiert

31. Demo • XML Web Service Client • Tx mit XML Web Service

32. Pro/Con XML Web Services • Pro • Einfach • Plattformunabhängigkeit • Transparent für Client-Code • Einschränkungen bei Datentypen • Struktur • Größe (Übertragung als Text!) • Erweiterbar • SOAP-Extensions/Header • Con • Tx & Security nicht plattformübergreifend

33. To the rescue • Web Services Enhancements (WSE) • Erweiterung des XML Web Service Framework • Binärdatenübertragung • Security • Routing

34. Alternativen für Verteilung • .NET Enterprise Services (COM+) • „Echter“ Applikationsserver • Heterogene Transaktionen • Rollenbasierte Security • Object Pooling • Queued Components • ... • System.Net • Low-level APIs • Sockets • TCP-/UDP-Klassen

35. Fazit • Mehrere Optionen für Verteilung • .NET Remoting • XML Web Services • .NET Enterprise Services • Verteilung ist einfach • Serialisierbare Parameterklassen • Definition entfernter Klasse • (Fast) Transparent für Client & Server

36. Fragen?

37. Ressourcen • Tom Barnaby, Distributed .NET Programming in VB.NET, APress 2002 • Ingo Rammer, Advanced .NET Remoting, APress 2002 • Clemens Vasters, .NET Enterprise Services, Carl Hanser 2002

38. Ihr Potenzial. Unser Antrieb.