Kap. 7 IS-Infrastruktur: Zusammenfassung

Transkript

1 Kap. 7 IS-Infrastruktur: Zusammenfassung G In Teil I haben wir verschiedene Middleware-Lösungen zur Entwicklung (komplexer), verteilter Informationssysteme kennengelernt Wir haben Middleware eingeführt als Basisdienste zur Unterstützung der Entwicklung und Ausführung von Anwendungen mit dem Ziel der Trennung von Infrastruktur-Funktionalität und Anwendungsfunktionalität Wie gut wird dieses Ziel von den unterschiedlichen Middleware-Lösungen unterstützt (am Beispiel von Transaktionsgarantien)? Fat Clients: SQL-Middleware (ESQL, CLI) Sehr rudimentäre Transaktionsunterstützung Koordination verteilter Transaktionen (2PC) muss explizit durch den Entwickler ausprogrammiert werden Fat Servers: TP-Lite Gut geeignet, falls keine Verteilung berücksichtigt werden muss. Ansonsten: Aufrufhierachie von Prozeduren muss bekannt sein, damit äussere Transaktionsklammer gesetzt werden kann (siehe Übung 1) TP-Monitore Auf prozedurale Anwendungsentwicklung beschränkt. Gute Unterstützung verteilter Transaktionen, aber Verwendung spezieller APIs (siehe X/Open) Kapitel 7: Zusammenfassung Teil I. 1

2 ... Zusammenfassung DOM/CORBA: Ebenfalls gute Unterstützung verteilter Transaktionen (OTS), jedoch explizites Erzeugen und Weitergeben des Transaktionskontextes. Objekt-Transaktionsmonitore Explizites Setzen des Transaktionskontexts und deklarative Spezifikation durch Deployment möglich. EJB: Mächtige Unterstützung deklarativer Spezifikation durch Deployment. Setzt den Middleware-Anspruch der Trennung von Infrastruktur-Funktionalität und Anwendungsfunktionalität mit Abstand am besten um. MOM / Persistent Queues / Queued Transactions Grösserer Aufwand, verteilte Transaktionen zu implementieren, da Kombination von drei unabhängigen Transaktionen erfordert (Zusatzaufwand vor allem bei der Recovery). Gewinn ist jedoch die stärkere Entkopplung einzelner Komponenten. Kapitel 7: Zusammenfassung Teil I. 2

3 Transaktionsunterstützung (nach OHE99) Feature Participants Commit synchronization Only-once semantics Server management on the recipient node Load balancing Supervised exchanges Ordinary Queues, RPCs, ORBs, Publish-and-Subscribe, and Conversational Communications Loosely-coupled client/server programs No No No. It s just a delivery mechanism. (ORBs provide minimal server management.) Using the directory services. The first server to register becomes a hotspot. No dynamic load balancing is provided. No. Exchanges are simply between the client and the server. The exchanges are transient. No crash recovery or error management is provided. You re on your own. Transactional Queues, RPCs, ORBs, Publish-and-Subscribe, and Conversational Communications Transactionally bound client/server and server/server programs. The message invocation causes the recipient program to join the transaction Yes Yes Yes. The process that receives the message is started, load balanced, monitored, and tracked as part of the transaction. Uses the TP Monitor s sophisticated loadbalancing algorithms. Can spread work across multiple machines and dynamically add more processes to cover hotspot of activity. Several servers can read from same queue The TP Monitor supervises the entire exchange, restarts communication links, redirects messages to an alternate server process if the first one gets hung, performs retries, and provides persistent queues and crash recovery. Kapitel 7: Zusammenfassung Teil I. 3

4 Die Ideale Middleware? G Und welches ist jetzt die ideale Middleware-Lösung? G Die gibt es nicht! Alle Ansätze sind sehr gut geeignet für bestimmte, (teilweise eng eingegrenzte) Probleme Middleware-Funktionalität der vorgestellten Lösungen bzw. Produkte verschmilzt immer mehr, d.h. Systeme verbinden immer mehr die Vorteile der unterschiedlichen Ansätze ( Best-of-breed ) Kapitel 7: Zusammenfassung Teil I. 4

5 Beispiel: TP-Lite oder TP-Heavy? Dies war eine aktive Diskussion vor wenigen Jahren! Es ist aber zu erwarten, dass die Unterschiede verschwinden. DBMS-Hersteller werden eine TP-Monitor-ähnliche (Middleware)-Schicht anbieten (siehe auch die Entwicklung hin zu multiplen, asymmetrischen DBMS-Servern) TP-Lite 20 TPS TP-Heavy 80 TPS 200 Clients Informix DB Engine 200 Dedicated Pipes 1000 Clients TP Monitor 24 Shared Pipes Informix DB Engine Vergleich nach Orfali/Harkey/Edwards: Client/Server Survival Guide Kapitel 7: Zusammenfassung Teil I. 5

6 Beispiel OTS: Integration der einzelnen Middleware-Komponenten G Objekt-Transaktionsmonitore = Objekte + Transaktionen + Messages Integrieren die wesentlichen Infrastruktur-Komponenten, die wir in Teil I der Vorlesung kennengelernt haben Zusätzlich: Vereinfachung der Entwicklung komplexer Systeme Von der expliziten Programmierung Hin zu Assembly und Deployment EJB Transaktionen Objekte Messages Kapitel 7: Zusammenfassung Teil I. 6

7 TPC-C Benchmarkresultate nach Performance Rank Company System TpmC $/tpmc Database TP-Monitor OS 1 IBM IBM/eServer xseries US $ SQL Server 2 Compaq ProLiant P US $ SQL Server 3 IBM Netfinity 8500R c/s US $ IBM DB2 UDB IBM IBM/eServer xseries US $ SQL Server 5 Compaq ProLiant 8500-X700-96P US $ SQL Server 6 Compaq ProLiant 8599-X550-96P US $ SQL Server 7 Fujitsu PRIMEPOWER US $ SymfoWARE Server Enterp. Ed. BEA Tuxedo 6.5 Sun Solaris 8 8 IBM IBM eserver pseries US $ Oracle 8i Enterprise Edition v Webshpere App. Server IBM AIX HP HP 9000 Superdome US $ Oracle 8i Enterprise Edition v BEA Tuxedo 6.4 HP UX 11.i 10 Fujitsu PRIMEPOWER US $ SymfoWARE Server Enterp. Ed. BEA Tuxedo 6.4 Sun Solaris 7 Stand: 04/2001, Quelle: Transaction Processing Performance Council, Kapitel 7: Zusammenfassung Teil I. 7

8 Gegenüberstellung der vorgestellten Systeme Kriterium ORACLE TUXEDO CORBA EJB Plattformunabhängigkeit Herstellerunabhängigkeit - o Flexibilität / Deployment / WORA - - o + ++ Komplexität Programmierung Deklarative Transaktionen + - o + ++ Deklarative Persistenz + o o + ++ Verteilungstransparenz o Synchrone / asynchrone Komm. +/- +/+ +/+ +/+ +/+ Skalierbarkeit - + o + o Stabilität o o Investitionssicherheit ++ o o o o Kapitel 7: Zusammenfassung Teil I. 8