Kap. 3 Verteilte Objektverwaltung

Transkript

1 Kap. 3 Verteilte Objektverwaltung 3.1 Einführung in die verteilte Objektverwaltung (Distributed Object Management, DOM) Anforderungen Kurzübersicht Java RMI Microsoft COM+ CORBA 3.2 Der CORBA-Standard zur verteilten Objektverwaltung 3.3 Objekt-Transaktionsmonitore: transaktionelle verteilte Objektverwaltung 3.4 Iona s Orbix als Beispiel einer kommerziellen CORBA-Implementierung Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 3: Vorlesung Verteilte Objekte 1

2 3.1 Verteilte Objekte Moderne verteilte Informationssysteme sind gekennzeichnet durch die modulare Kapselung von Anwendungslogik (zusammen mit den zugehörigen Daten) in Form von Objekten Die Entwicklung von Informationssystemen entspricht dann dem konsistenten Zusammensetzen dieser verteilten Objekte (bzw. Komponenten) Wiederverwendbare Software-Einheiten Just as databases were at the center of the design of the applications of the 70s and 80s, components are at the center of the applications of the 90s and the next century (David Vaskevitch, Microsoft) Voraussetzung: Geeignete Infrastruktur-Unterstützung zur Entwicklung und zum Zusammenführen verteilter Objekte: Verteilte Objektverwaltung Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 3: Vorlesung Verteilte Objekte 2

3 Kapitel 3: Vorlesung Verteilte Objekte 3 Begriffswelt Objekt Anwendungsobjekt als abstrakter Datentyp, verfügt über Schnittstelle (Methoden und Attribute) Objektreferenz (eindeutig, intern) Designvarianten: Zustand Explizit: Zustand der persistenten Daten aus der Datenbank explizit in Form von Attributen im Objekt materialisiert Implizit: Zustand ist nicht im Objekt materialisiert, sondern wird über Methoden, die auf die DB zugreifen, sichtbar gemacht Software-Einheit, die Methoden eines Objekts aufruft Software-Einheit, die Objektimplementationen anbietet Objekte können also sowohl die Rolle von s als auch die Rolle von n übernehmen Finance Objekt-Bus Account ESQL/C SQL DBMS Account

4 Kapitel 3: Vorlesung Verteilte Objekte 4 Unterschied zwischen RPC und Objekt-Bus RPC Call foo Code akjdkfjdksjfkdjkfjdksfkjasd kdjfkdjfkjdkjfkdkfjd kfjdkfjkd kfjdkjfkdjkfjkdjfkd kfjkdjkfjdkfkdkfkd ddddddddddddddddddddd dddddddddddddddddddd ddddddddd ddddddddddddddd d d dddddddd ddddddddddd dddddddd dd Data Execute foo RPC Mechanismus Objekt-Bus (ORB) Invoke foo on Object X Invoke foo on Object Y Object X Object Y foo foo Objekt-Bus

5 Kapitel 3: Vorlesung Verteilte Objekte 5 Anforderungen an die verteilte Objektverwaltung Orts- bzw. Verteilungstransparenz Aufruf von -Methoden unabhängig von der physischen Platzierung des -Objektes Möglichkeit des Methodenaufrufs über Prozess- und Rechnergrenzen hinweg Plattformunabhängigkeit Hardware- und Betriebssystemunabhängigkeit für - und -Objekte, d.h. Koexistenz mehrerer Plattformen Interoperabilität ist gefordert Sprachunabhängigkeit Einbettung in bestehende Programmiersprachen, aber: Unabhängigkeit der - bzw. -Implementierungen von einer speziellen Programmiersprachenumgebung Trennung von Interface und Implementierung Statische und dynamische Methodenaufrufe Transaktionen Selbstbeschreibung Polymorphismus Sicherheit Unterstützung sogenannter Legacy -Systeme

6 Kapitel 3: Vorlesung Verteilte Objekte 6 Java RMI Übersicht RMI: Remote Method Invocation Aufruf von Objektmethoden in entfernten Java VMs -Objekt besitzt Proxy ( Stub) als Stellvertreter in der VM Stub wird zur Laufzeit in die -VM geladen und Übernimmt das Marshaling von Aufträgen Aufträge gehen an -Skeleton in der Remote VM Unmarshaling Methoden-Aufruf des -Objektes Registry als Verzeichnis-Dienst für Remote-Aufrufe Object Virtual Machine use Stub marshaling download RMI Registry (Naming Service) Stub Skeleton unmarshaling call register Object ( remote object ) Virtual Machine

7 Kapitel 3: Vorlesung Verteilte Objekte 7 Java RMI Verwendung -Entwicklung -Entwicklung Remote-Interface von My definieren (java.rmi.remote Interface erweitern) Code My implementieren (Verwendung von java.rmi.naming zur Lokalisation von Remote-Objekten; Aufruf von Remote-Objekt-Methoden über Stub) javac download Remote-Interface von My implementieren (Java--Klasse von java.rmi.unicastremoteobject ableiten) Stub (.class) javac my.class rmic (Stub-Compiler) Skeleton (.class) Class Verwendung Stub RMI Registry RMI Registry starten -Objekte instanziieren Remote Object my.class -Objekt-Instanz registrieren (java.rmi.naming)

8 Kapitel 3: Vorlesung Verteilte Objekte 8 Java RMI Zusammenfassung Verteilungstransparenz Methodenaufrufe in entfernten VMs möglich RMI Registry als Naming Service Plattformunabhängigkeit Ist gegeben, da jeweils lediglich eine Java VM für bzw. vorausgesetzt wird Sprachunabhängigkeit Beschränkung auf Java, keine andere Sprachanbindung möglich Keine dynamischen Methodenaufrufe Keine Transaktionen

9 Kapitel 3: Vorlesung Verteilte Objekte 9 Microsoft COM+ Übersicht Kein separater Standard, sondern Teil von MS Windows 2000 Basierend auf COM (Component Object Model) COM-: Binärcode (.dll oder.exe), stellt via Interface veröffentlichte Funktionalität (Methoden) bereit DCOM (Distributed COM), bereits in MS Windows 98 / NT integriert Aufruf der im Interface veröffentlichten Methoden eines COM-s (mit Hilfe lokaler Proxy-Objekte über Rechnergrenzen hinweg) Zusätzlich: weitere Services zur Unterstützung von Transaktionssemantik Mehr dazu in Kapitel 3.3 Objekt-Transaktions-Monitore COM+ MS Message Queue (MSMQ) DCOM COM MS Transaction (MTS)

10 Kapitel 3: Vorlesung Verteilte Objekte 10 Microsoft COM+ Zusammenfassung Verteilungstransparenz Plattformunabhängigkeit Ist nicht gegeben durch Beschränkung auf die Microsoft-Welt Sprachunabhängigkeit Beschreibung der Schnittstellen der Objektklassen durch IDL (Interface Definition Language) IDL-Beschreibung (Interface) unabhängig von der jeweiligen Implementierung Anbindung an mehrere Programmiersprachen existiert (z.b. in den diversen Entwicklungsumgebungen von Microsoft) Unterstützt sowohl statische als auch dynamische Aufrufe Transaktionssemantik wird durch MTS bereitgestellt

11 CORBA Übersicht Standard der OMG (= Object Management Group) Eines der weltgrössten Software-Konsortien, bestehend aus ca. 800 Software- Herstellern (u.a. Sun, IBM, HP, Oracle, Microsoft) CORBA = Common Object Request Broker Architecture Offener Interoperabilitäts-Standard für heterogene, verteilte, objektorientierte Systeme Erste Version bereits 1991 veröffentlicht (Standard wurde also definiert, bevor Produkte, d.h. CORBA-Implementierungen, auf dem Markt waren) Kernkomponente ist der ORB (Object Request Broker), der Objekt-Bus von CORBA Gemeinsame Kommunikationsplattform für verteilte Objekte Interaktion zwischen verteilten Objekten wieder über lokale Stellvertreter entfernter Objekte ( IDL Stubs), die über server-seitige Skeletons die eigentliche Methodenimplementierung aufrufen Jeder entfernte Aufruf erscheint dem wie ein lokaler Methodenaufruf IDL Stubs verbergen die Sprache der -Implementierung Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 3: Vorlesung Verteilte Objekte 11

12 Kapitel 3: Vorlesung Verteilte Objekte 12 CORBA Zusammenfassung Verteilungstransparenz Plattformunabhängigkeit Basis-Funktionalität des ORBs; zusätzlich: Durch IIOP (Internet Inter-Orb Protokoll) ist Kommunikation zwischen verschiedenen ORBs möglich Sprachunabhängigkeit Strikte Trennung von Interface und Implementierung Sprachunabhängige Beschreibung der Schnittstellen von Objekten durch IDL (ist allerdings NICHT identisch mit der IDL von COM+) Anbindungen zu diversen Programmiersprachen existieren (C, C++, Smalltalk, Ada, Java, PL/1, ) Unterstützt sowohl statische als auch dynamische Methodenaufrufe OTS: Methodenaufrufe in Transaktionskontext möglich

13 Schöne neue DOM-Welt? Verteilungstransparenz klingt gut, aber man sollte hinterfragen, inwieweit sie wirklich erreichbar ist Oft übersehene Probleme: Latency Zugriff auf entfernte Objekte um Grössenordnungen langsamer Memory Access Zeiger auf lokale Daten sind ungültig; grosse Fehlerquelle! Partial Failure Statt dem ganzen Programm können nur einzelne Teile ausfallen Concurrency Verteilte Objekte müssen nebenläufige Aufrufe verkraften können Die wahre Herausforderung ist das gute Design eines verteilten Informationssystems! Objektverwaltung höherer Ordnung (OHO) SS 2003 Kapitel 3: Vorlesung Verteilte Objekte 13