1 / 38

.NET Remoting und XML Web Services

.NET Remoting und XML Web Services. .NET Remoting und XML Web Services. Ralf Westphal ralfw@ralfw.de. Architekturtriebfedern. Wartbarkeit Leistung Integration Robustheit Stabilität Sicherheit. Triebfeder Wartbarkeit. Wunschliste Flexibilität Transparenz Einfaches Deployment

gavin
Download Presentation

.NET Remoting und XML Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related