Konstruktion von verteilten Objekten: Teil1:Konzepte Abschnitt 1
Werbung
Konstruktion von verteilten Objekten: Teil1:Konzepte Abschnitt 1: Verteilte Systeme Wichtige Charakteristika verteilter Systeme Bestandteile verteilter Systeme Ein verteiltes System besteht aus Komponenten auf untereinander vernetzten Rechnern,die über Middleware so interagieren,dass sie insgesamt als ein gemeinsames Systemziel erfüllend erscheinen. Ein Rechner, der Komponenten eines verteilten System beherbergt, wird als Host bezeichnet. Ein Host ist ein Rechner ,der Komponenten eines verteilten Systems ausführt. Middleware ist eine Schicht zwischen Netzbetriebssytemen und nwendungen,die sich Heterogenitäts- und Verteilungsaspekten annimmt. Zentral und verteilt organisierte Systeme im Vergleich – – – – – – – – – Zentral organisierte Systeme besitzen nichtautonome Komponenten. werden oft mittels homogener Techologie gebaut. Ressourcen werden von mehreren Benutzern zeitgleich gemeinsam genutzt. Besitzen einen einzelnen Ausführungsort und Störungsort. Verteilte Systeme besitzen autonome Komponenten können mittels heterogener Technologien gebaut werden Komponenten können exclusiv benutzt werden werden mit nebenläufigen Prozessen ausgeführt besitzen mehrere Störungsorte Anforderungen verteilter Systeme -Skalierbarkeit bezeichnet die Fähigkeit,sich an zukünftig steigende Last anpassen zu können (Verteilte Systemarchitekturen erreichen Skalierbarkeit durch den Einsatz von mehr als einen Hosts) -Offenheit: offene Systeme sind einfach zu erweitern und zu ändern (Verteilte Systemkomponenten erzielen Offenheit durch die Kommunikation über wohl definierte Schnittstellen) -Heterogenität von Komponenten kann von den Programmiersprachen ,den Betriebssystemen,den Hardwareplattformen und den Netzwerkprotokollen herrühren. (Für verteilte Systeme ist die Komponentenheterogenität der Normalzustand) -Gemeinsamer Ressourcenzugriff:oft müssen Ressourcen wie hardware ,Software und Daten,von mehreren benutzern gemeinsam genutz werden. -Fehlertolleranz: ein auch bei Vorhandensein von Fehlern weiterlaufender Betrieb wird als fehlertollerant bezeichnet (wird erreicht durch Replikation) Transparenz in verteilten Systemen: – Zugriffstransparenz bedeutet,dass die Schnittstellen für lokale und entfernte Kommunikation gleich sind – Ortstransparenz bedeutet,dass die Dienstanfordere nichts über physische Orte von Komponenten wissen müssen – Migrationstransparenz bedeutet,dass eine Komponente verlagert werden kann,ohne dass benutzer oder Clients davon Kenntniss nehmen müssen(hängt von Zugriffs und Ortstransparenz ab) – Replikationstransparenz bedeutet, dass Benutzer und Programmierer nicht wissen, ob ein Replikat oder ein Orginal den Dienst erbringt(hängt von Zugriffs und Ortstransparenz ab) – Nebenläufigkeitstransparenz bedeutet, dass Benutzern und Programmierern nicht bewusst ist,dass Komponenten Dienste nebenläufig anfordern. – Skalierbarkeitstransparenz bedeutet,dass Benutzer und Programmierer nicht wissen, wie die Skalierbarkeit eines verteilten Systems erreicht wird (hängt von Replikations und Migrationstransparenz ab) – Performanztransparenz bedeutet, dass benutzern und Programmierern nicht bewusst ist, wie gute Systemperformanz beibehalten wird(hängt von Replikations und Migrationstransparenz ab) – Fehlertransparenz bedeutet, dass benutzern und Programmierer sich nicht bewusst sind, wie verteilte Systeme Fehler verbergen (hängt von Nebenläufigkeits und Replikationstransparenz ab) Zusammenfassung: - Verteilte Systeme bestehen aus mehreren vernetzten Hosts,auf denne jeweils eine oder mehrere Komponenten ausgeführt werden. Diese Komponenten benutzen Middleware zur Kommunikation untereinander.Die Middleware verbirgt in einem gewissen Ausmaß die Verteilung und die Heterogenität vor den Entwicklern. – Entwickler haben oft nicht die Möglichkeit einer zentral organisierten Systemarchitektur, weil nichtfunktionale Anforderungen sie zum Einsatz einer verteilten Architekur zwingen. Zu diesen Anforderungen zählen die Skalierbarkeit,die Offenheit,die Heterogenität,die gemeinsame Ressourzennutzung und die Fehlertolleranz. – Wir haben verschiedene Dimensionen diskutiert, in denen die Verteilung den Benutzern, Anwendungsentwicklern und Administratoren transparent sein kann.Diese Dimensionen sind siehe Transparenz in verteilten Systemen.Diese sind Entwurfszielefür verteilte Systeme. Fragen 1.1- 1.9 Abschnitt 2: Der Entwurf verteilter Objekte Uml-Repräsentationen für den Entwurf verteilter Objekte: -Use-Case-Diagramme erfassen die Anforderungen aus funktionaler Sicht. Akteure sind Typen menschlicher Benutzer oder externer Systeme Ein UCD ist eine generische Beschreibung einer Folge von Interaktionsereignissen zwischen dem System und seinen externen Akteuren -Sequenzdiagramme modellieren Interaktionsszenarien zwischen Objekten als sequenzielle Abfolge ( Nachrichten werden zwischen Client und Serverobjekt versendet,um die Ausführung von Operationen anzufordern) Können während Analyse und Entwurf eingesetzt werden -Klassendiagramme definieren die Typen der Objekte über Attribute, Operationen und Assoziationen. Attribute können öffentlich oder privat sichtbar sein. Ein typ kann einen anderen Typ verallgemeinern. Assoziationen verbinden Objekte und können Aggregations-oder Kompositionssemantik tragen. Abhängigkeiten zeigen,das ein Objekttyp von einem anderen Objekttyp abhängt. Assoziationen können verschiedene Kardinalitäten besitzen. Klassendiagramme werden für die Erfassung von typenbezogenen Abstraktionen in der Analyse und im Entwurf verteilter Objekte benutzt. Pakete werden zur hierachischen Strukturierung der Analyse und Entwurfsinformation verwendet. -Objektdiagramme zeigen Beispiele von Klasseninstanziierung. -Zustandsdiagramme modellieren das dynamische Verhalten von Objekten auf einer typbezogenen Abstraktionsebene Zustände können aus anderen Zuständen zusammengesetzt werden. Ein Metamodell für verteilte Objekte: Metaobjekt Facility Ebene 3 Metaobjekt modell Ebene 2 Objekttypen Ebene 1 Objekte Ebene 0 Objekte - Objekte besitzen Attribute,die ihre zustände repräsentieren und Operationen,die die Zustände ändern können - Ein Attribut ist eine Abbildung zwischen einem Objekt und einem Wert.Es ist durch seinen Namen und seinen typ charakterisiert. Verteilte Objekte haben keine Klassen oder static Variablen - Objekte haben einen eindeutigen Bezeichner und möglicherweise mehrere auf sie zeigende Refernzen Typen -Objekttypen spezifieren die gemeinsamen Charakteristika ähnlicher Objekte. -Objekttypen definieren einen Vertrag ,der die Interaktion zwischen Client und Serverobjekten bestimmt. -Objekte sind instanzen von Objekttypen -Objekttypen sind durch Schnittstellen definiert. Diese legen die von Clients anfragbaren Operationen fest -Eine Signatur spezifiert den Namen, Parameter, Rückgabewert und Ausnahmen einer Operation. Nicht alle von einem Objekttyp unterstützen Operationen müssen in der Schnittstelle enthalten sein. Metamodelle für verteilte Objekte enthalten auch Typen, die nicht Objekte sind! Typkonstruktoren sollten nicht mit Konstruktoren verwechselt werden,die Objekte erzeugen! Anfragen Eine Objektanfrage wird durch ein Clientobjek gestellt, um von einem Serverobjekt die Ausführung einer Operation. Ausnahmen Ausnahmen benachrichtigen Clients über aufgetretene Fehler bei der Ausführung einer Objektanfrage. Untertypen und Mehfachvererbung – – Ein Untertyp erbt alle Attribut-, Operations- und Ausnahmendefinitionen von seinem Obertyp. Ein Untertyp kann von mehr als einem Obertyp erben. Polymorphie -bedeutet, dass ein Attribut oder ein Paramter Instanzen verschiedener Typen refernzieren kann. -Späte Bindung bedeutet, dass erst zur Laufzeit entschieden wird,welche Operation beziehungsweise Operationsimplementierung für eine Anfragenausführung die richtige ist. Lokale und verteilte Objekte im Vergleich Lebenszyklus: Die Erzeugung, Migration und Löschung verteilter Objekte unterscheidet sich von lokalen Objekten. Objektreferenzen: -für verteilte Objekte sind grösser als für lokale Objekte! Latenzzeit von Anfragen: -eine verteilte Objektanfrage ist Größenordnungen langsamer als ein lokaler Methodenaufruf -beim Entwurf verteilter Objekte muss die Latenzzeit von Anfragen berücksichtigt werden Objektaktivierung: -andauernde Verfügbarkeit verteilter Objekte zur bedienung von Anfragen ist nicht garantierbar -Aktivierung bringt inaktive Objekte in den Hauptspeicher, so dass sie eine Objektanfrage bedienen können -der Overhead der Aktivierung vergrößert die Latenzzeit von Objektanfragen beträchtlich -Aktivierung und Deaktivierung sollten transparent sein -Objekte mit Zustand müssen persistent sein Parallelität: -verteilte Objekte werden oft parallel ausgeführt -Nebenläufigkeit muss gegebenfalls kontrolliert werden Kommunikation: -für Anfragen an verteilte Objekte gibt es verschiedene Kommunikationsprimitive ( Kapitel 7) Fehler : -die Wahrscheinlichkeit des Scheiterns verteilter Objektanfragen ist größer als die lokaler Methodenaufrufe -man kann verschiedene Zuverlässigkeitsgrade für verteilte Objekte unterscheiden -Clients müssen prüfen, ob Server eine Anfrage ausgeführt haben Sicherheit: -die Verteilung von Objekten macht sie anfällig für sicherheitsrelevante Angriffe -während des Entwurfes verteilter Objekte müssen Sicherheitsaspekte berücksichtigt werden Zusammenfassung: – Ein Komponentenmodell legt fest, wie Dienste definiert werden,wie der extern sichtbare Zustand einer Komponente ermittelt wird, wie Komponenten identifiziert und Dienste angefordert werden.Durch die objektorientierte Sichtweise dieses Buchs auf verteilte Systeme werden Komponenten als Objekte betrachtet.Objekte kommunizieren mit Objektanfragen.Ein Clientobjek kann vom Serverobjekt die Ausführung einer Operation oder den Zugriff auf ein Attribut anfordern. – UML: Möglichkeit um Objektmodelle aus verschiedenen perspektiven auszudrücken: Use Case Diagramme: Bedarf an Systemschnittstellen identifizieren Sequenzdiagramme: Szenarien von Objektinteraktionen modellieren Klassendiagramme: kann man die statischen Eigenschaften von Klassen formulieren(insbesondere Attribute und Operationen und die Assoziationen einer Klasse zu anderen) Zustandsdiagramme:geben den internen Zustand verteilter Objekte und die Übergänge zwischen diesen Zuständen wieder All diese Diagramme unterstützen den Entwurf verteilter Objekte und vor allem die Kommunikation darüber – Bestandteile eines Metaobjektmodells für verteilte Objekte: - Operationen - Attribute - Ausnahmen - Untertypbildung -Mehrfachvererbung - Polymorphie – Unterschiede im Entwurf von zentralisierten Objekten: - Lebenszyklus verteilter Objekte ist komplexer, da auch Ortsinformation berücksichtigt werden muss -Referenzen auf verteilte Objekte sind komplexer, da sie auch in der Lage sein müssen, Objekte zu lokalisieren, und weil Sicherheits und Typinformation hinzugefügt werden muss - Latenzzeit für Anfrage ist ca 2000 mal größer als der overhead eines lokalen Methodenaufrufs (Objekte müssen gegebenfalls aktiviert werden und auch deaktviert werden, wenn sie länger nicht länger benutzt werden.Dies erhöht wiederum die Anfragen-Latenzzeit. - Verteilte Objekte können Aufgaben potenziell schneller als zentrale Objekte ausführen( Grund: echte Parallelität) - verteilte Objekte können aussfallen, deshalb müssen sowohl Client als auch Serverobjekte so gebaut werden, dass sie Ausfälle tolerieren können. - verteilte Objekte kommunizieren möglicherweise über unsichere Rechnernetze Fragen 2.1 bis 2.12 Kapitel 2:Middleware für verteilte Objekte Primzipien objektorientierter Middleware: Rechnernetze: -Iso / OSI Refernzmodell Die physikalische Schicht beschäftigt sich mit der Übertragung von Bits über ein physikalisches Medium Die Leistungsschicht verbindet zwei Rechner Die Netzwerkschicht realisiert die Verbindung mehrerr Knoten in einem Netz Die Transportschicht kümmert sich um längere Nachrichten zwischen zwei Rechnern Die Sitzungsschicht etabliert und betreibt Verbindungen zwischen verteilten Systemkomponenten Die Darstellungsschicht löst Unterschiede Unterschiede in der Datenkodierung auf und ermöglicht den Transport komplexer Daten Die Anwendungsschicht stellt die Anwendungsfunktionalität bereit. TCP ist ein verbindungsorientiertes, UDP ein verbindungsloses Transportprotokoll. TCP: -bietet zur Kommunikation bidirektionale Ströme zum Hineinschreiben aus Auslesen von Daten -sorgt für Zuverlässigkeit bei unzuverlässigen Netzwerkprotokollen, ist aber weniger effizient als UDP UDP: -können Nachrichten fetser Länge zwischen Hosts eines verteilten Systems gesendet werden -verbessert die Zuverlässigkeit nicht, ist aber effizienter Middlewaretypen: – – – – Transaktionsorientierte Middleware wird oft zusammen mit verteilen Datenbankanwendungen benutzt Objektorientierte Middleware besitzt Fähigkeiten transaktionsorientierte Middleware Message-orientierte Middleware wird dann benutzt, wenn zuverlässige, asynchrone Kommunikation die dominante Form der Interaktion im verteilten System ist objektorientierte Middleware wird zunehmend mit Message-orientiertes Middleware eingesetzt RPC - ein RPC ist ein Hostgrenzen überschreitender Prozeduraufruf - der Ursprung objektorientierter Middleware - die RPC Darstellungsschichtintegration bildet Anwendungsdatenstrukturen in eine homogene und übertragbare Form ab - die Abbildungen zwischen den Kodierungen in den Anwendungen und beim Transport werden Marshalling( packen) und Unmarshalling (entpacken) genannt - Marshalling kann statisch oder dynamisch implementiert werden - Client und Server Stubs sind statische Implementierungen des Marshalling und Unmarshalling - Aktivierungs Policie bestimmen, wie Server in die Lage versetzt werden, Anfragen auszuführen Objektorientierte Middleware - jede Objektorientierte Middleware besitzt eine Schnittstellenbeschreibungssprache - IDLs unterstützen das Konzept von Objekttypen als Parameter, Fehlerbehandlung und Vererbung - die Darstellungsschicht bei objektorientierter Middleware muss Objektreferenzen auf das Transportformat abbilden# - die Sitzungsschicht implementiert die Objektaktivierung in den Objektadaptern - Objektadaper müssen Server neu starten können.DIese registrieren sich bei einem Implementierungsrepository oder einer Registry. - die Sitzungsschicht muss die Operationsauswahl implementieren - die Sitzungsschicht muss Synchronisation realisieren Entwicklung mit objektorientierter Middleware: -Schnittstellenbeschreibung IDLs besitzen Sprachkonstrukte für alle Konzepte ihres zugrunde liegenden Metamodells. Schnittstellenbeschreibung detailieren Klassendiagramme wesentlich Schnittstellen als Verträge zwischen Client und Server Schnittstellen sind die Grundlage für die Verteilung von Typinformation Client und Sercer Stubs werden automatisch aus Schnittstellen abgeleitet -Stubgenerierung Client und Server Stubs sind Proxie für Server und Clients Stubs werden generiert durch den IDL Compiler der Middleware -Implementierung von Clientobjekten Ein Client stellt eine statitische Objektanfrage über den Aufruf einer lokalen Methode eines Client Stubs Stubs sind typisierbar. Compiler können deshalb die typsicherheit prüfen Mit Stubs kann Zugriffstransparenz erreicht werden Die Middleware kann einen Stub umgehen, wenn Server und Client auf dem selben Host liegen -Implementierung von Serverobjekten Der generierte Server Stub muss die vom Anwendungsentwickler entworfene Serverimplementierung aufrufen -Serverregistrierung Serverobjekte müssen in der Registry oder im Implementierungsrepository der Middleware registriert werden Fragen 3.1 – 3.12 Cobra, COM und JAVA/RMI Cobra: ein wichtiges Entwurfsziel von Corba ist das Überwinden von Heterogenität Metaobjektmodell und Schnittstellenbeschreibung: Objekte - Cobraobjekte besitzen einen eindeutigen Bezeichner, können aber Ziel mehrerer Objektreferenzen sein (Objektreferenzen sind persistent;bedeutet das eine Objektreferenz auch bein einem derzeitig deaktivierten Serverobjekt gültig bleibt) Typen - Cobras Objektmodell ist statisch getypt(dh alle Attribute,Paramater und Operationsrückkehrwerte einen statischen Typ besitzen) --> möglichkeit der Typsicherheit - Objekttypen besitzen einen eindeutigen Namen ( Interface) - Cobra unterstützt komplexe Typen, deren Instanzen nicht entfernt zugreifbare Werte sind -Module begrenzen die Gültigkeit von Bezeichnern Attribute -machen die Zustandsinformation von Serverobjekten den Clientobjekten zugänglich -Readonly Attribute können durch Clientobjekte nicht geändert werden -unsterstützt wird auch das Konzept der Konstanten (Readonly Attribute) Operationen - Cobra Objekte spezifieren diejenigen Dienste,die Clients von Serverobjekten anfordern eine Operation besitz einen Rückgabetyp, einen Operationsnamen,eine Liste von Parmatern und und auslösbaren Ausnahmen - können in-,out- und inout-Parameter besitzen (in spezifiziert,dass der Client einen aktuellen Wert liefert,out bedeutet der Server produziert einen Wert währen der Anfrage;inout übergabe eines aktuellen Paramters,der durch den Server modifiziert wird) -es gibt kein Überladen um Programmiersprachenanbindungen nicht zu komplizieren Anfragen – werden benutzt für den Aufruf einer bestimmten Operation bei einem Serverobjekt – statische Anfragen sind zur Übersetzungszeit des Clients definiert – dynamische Objektanfragen werden zur Laufzeit des Clients definiert – die Ausführungssemantik ist „at-most-once“( bei einem Client angezeigten Fehler das Serverobjekt die angefragte Operation nicht ausgeführt hat; wird kein Fehler angezeigt kann der Client davon ausgehen das die Operation ausgeführt worden ist) Fehlerbehandlung – bei auftreten eines Fehlers löst Cobra eine Ausnahme aus Untertypen und Mehrfachvererbung – Cobra unterstütz Mehrfachvererbung – jedes Cobraobjekte erbt von Object. Polymorphie – arbeitet mit statischer Typisierung Architektur – Marshalling und Unmarshalling wird durch Client Stubs und Implementierungsskeletons durchgeführt – Objektadaper unsterstützen die Objektaktivierung und -deaktivierung – die ORB Schnittstelle enthält das Schnittstellenrepository und wird verwendet für die Initialisierung von Clients und Servern – Cobra bietet Zugriffs und Ortstransparenz COM Com unterstützt binäre Verkapselung( dh Kodierung von Serverobjekten in Maschinencode sich unabhängig von den Clients entwickelt) COM definiert das Speicherlayout von Objekten. Damit produzieren unterschiedliche Compiler interoperablen Binärcode Metaobjektmodell und Schnittstellenbeschreibung Objekte – COM Schnittstellen besitzen eindeutige physikalische Bezeichner ( UUID) – COM Objekte werden durch zeiger auf Hauptspeicherebene identifiziert, an denen das Objekt oder ein Proxy liegt – COM Implementierungen können mehrere Schnittstellen gleichzeitig implementieren – COM Klassen managen den Lebenszyklus und können Objekte lokalisieren – COM benötigt keinen Modulmechanismus Typen – COM Grundtypen sind atomare Typen und Typkonstruktoren – hat weniger Typkonstruktoren als COBRA Attribute – behandelt Attribute als Operationen Operationen – die in einer Schnittstelle deklarierten Operationen sind für alleClients sichtbar – COM Operationem besitzen in-, out-, inout Parameter Anfragen – HRESULT kennzeichnet eine erfolgreiche oder fehlerbehaftete Anfrage – COM unterstützt statische und dynamische Operationsaufrufe – „at most once“ Fehlerbehandlung – gegenüber COM sind HRESULTs ausdruckschwächer, um Fehlergründe zu erläutern Vererbung – COM unterstützt das Erbene von genau einer Schnittstelle – jede COM-Schnittstelle erbt von Iunknown Polymorphie – Type coercion bedeutet, dass Typumwandlungen durch die Operation QueryInterface unterstützt werden – Marshalling und Unmarshalling werden durchgeführt durch Objektproxies, Schnittstellenproxies, Objekt-Stubs und Schnittstellen Stubs – Aktivierung und Deaktivierung werden durch den Service Control Manager implementiert – COM unterstützt Zugriffs und Ortstransparenz JAVA/ RMI – Java besitz keine Schnittstelenbeschreibungssprache,sondern verwendet für diesen Zweck – auch Java Pakete in Java schränken Gültigkeitsbereich von Deklarationen ein (Gültigkeitsbereich muss bei jedem Auftreten mittels des Paketnamens angegeben werden) Objekte Mit Java kann ein Clientobjekt Methoden eines entfernten Serverobjekts aufrufen. Client und Serverobjekt sind dabei in Java geschrieben. Lokale Methoden werden durch eine Klassendefintion bestimmt. Typen Java ist eine streng typisierte Sprache und besitz eine statisches Typsystem. Sie bietet atomare Typen und Objekttypen. Zu den atomaren Typen gehören bspweise int, float, double und char. Die objekttypen in Java sind die Klassen und Schnittstellen. Soll ein Serberobjekt entfernt zugreifbar sein, muss es mindestens eine Java Schnittstelle implementieren,die die vordefinierte Schnittstelle java.rmi.Remote direkt oder indirekt erweitert. Remote deklariert keine Operationen , dient aber als Abstraktion für eine entfernte Zugangsmöglichkeit. Attribute Rmi besitzt keine Mechanismen für Attribute. Operationen: Operationen werden in Java als Methoden bezeichnet. Parameter entfernter Methoden dürfen keine Typen entfernter Klassen beinhalten. Die Parameterübergabe atomarer Typen geschieht im Call by Value für lokale wie auch entfernte Methoden. Dies bedeutet das die aufgerufene Methode mit einer Kopie des Werts arbeitet. Objekte werden per Call by Reference für lokale Methodenaufrufeübergeben. Dies bedeutet, dass nicht das Objekt an die aufgerufene Methode übergeben wird, sondern eine Objektreferenz Parameter Atomarer Typ Nicht entfernter Objekttyp Entfernter Objekttyp Lokaler Aufruf Call by Value Call by Reference Call by Reference Entfernter Aufruf Call by Value Call by Value Call by Reference Anfragen Entfernte Methoden werden mit At-most-once-Semantik ausgeführt – im Gegensatz zu Corba und Com unterstützt Java keine Definition von entfernten Methodenaufrufen zur Laufzeit Fehlerbehandlung – Entfernte Methoden müssen deklarieren, dass sie RemoteException auslösen könnten – entfernte Methoden können zusätzliche Ausnahmen auslösen – Untertypen und Mehrfachvererbung Entfernte Schnittstellen können gleichzeitig von entfernten und nicht entfernten Schnittstellen erben. Polymorphie Java unterstütz durch Vererbungsbeziehungen statisch eingeschränkte Polymorphie. Variablen, Paramter und Ergebnistypen haben einen statischen Typ. Zuweisungen zu denen sind möglich, wenn der statische Typ ein Obertyp des statischen Typs des zugewiesenen Objekts ist. Diese Bedingung gewährleistet die Typsicherheit. Architektur: siehe buch seite 156 Kapitel 5: Auflösung der Heterogenität: Unterschiede in Objektmodellen – Typsysteme von Programmiersprachensprachen unterschieden sich – Unterschiedliche Programmiersprachen besitzen unterschiedliche Typkonstruktion – Einige Sprachen unterscheiden zwischen Schnittstelle und Implementierung – Sprachen behandel Vererbung unterschiedlich Maschinencode: – Die von Compilern derselben Sprache erzeugten Binärkodierung kann sich unterscheiden – Die Kodierung in Maschinencode – Das Speicherlayout von Objekten und die Position von Attributen können sich unterscheiden Programmiersprachenanbindungen: Eine Programmiersprachenanbindung legt fest , wie IDL Konstrukte in einer Implementierung eines Client oder Serverobjekts verwendet werden können – Reduktion der Komplexität durch Schnittstelenbeschreibungssprache IDL Seite 169 Abbildung der Objektmodelle: – – – – – – – – – – Die Anbindungen von Programmiersprachen zu einer IDL muss bidirektional sein ( Hin und Zurück) Verteilte Objektmodelle sind statisch typisiert Objekttypen sind als Schnittstelle definiert, die Anbindungen der Programmiersprachen bilden die Objekttypen der Middleware auf die Typen der Client und Server Stubs Anbindungen definieren, wie Objektreferenzen implemntiert sind in den meisten Programmiersprachenanbindungen sind die Objektrefernezkodierungen des Serverobjekts in Clientstubs gekapselt Attribute werden immer als Operationen deklariert Operationen als Prozeduren oder Methoden (sind über Stubs erreichbar) Ausnahmen werden als Ausnahmen oder explizite Ausgabenparameter dargestellt, die ausgewertet werden müssen Auflösung von Mehrfachvererbung hängt vom Vererbungsmodell der Programmiersprache ab Alle Programmiersprachenanbindungen setzen die Existenz eines gemeinsamen Wurzelobjekts vorraus Implementierung von Sprachanbindungen – Middleware stellt für Client und Serverobjekte APIs zur Verfügung – Middleware beinhaltet auch IDL Compiler zur Erzeugung von Programmcode für Stubs und Implementiereungs Skeletons Zugriffstransparenz: Die auflösung der Sprachheterogenität ist transparent für die betroffenen Programmierer Heterogene Middleware – – – – Unterschiedliche Middleware wird uU aufgrund verfügbarer Programmiersprachenanbindungen benötigt aufgrund der Integration mit bestehenden Systemen benötigt aufgrund der Verfügbarkeit auf unterschiedlicher Hardware benötigt aufgrund unterschiedlicher Performanzprofile benötigt Beisiele für Heterogenität: – Die Objektmodelle und IDLs unterscheiden sich – Objektreferenzen werden unterschiedlich kodiert – Datenhetrogenität wird auf unterschiedliche Art aufgelöst – Es werden verschiedene Transportprotokolle verwendet Interoperabilität: bezeichnet die Fähigkeit, dass verschiedene Middlewareimplementierungen zusammenarbeiten können. Brücken: – übersezten eine Anfrage von einer Middleware zu einer anderen – innerhalb einer Middleware angesiedelte Brücken werden Inlinebrücken genannt – die oberhalb einer Middleware angesiedelt sind, nennt man Brücken auf Anfrageneben (request-level bridges) können von Anwendungsentwicklern hinzugefügt werden Zusammenarbeit: Zusammenarbeit legt fest, wie verschiedene Middleware Standards miteinander integriert werden – ist schwieriger zu erreichen als Interoperabilität – Zusammenarbeitsspezifikationen werden duch Compiler realisiert, die von einer IDL in eine andere Übersetzen Heterogene Datenkodierung: – Integer werden auf unterschiedlicher Hardware unterschiedlich kodiert – es gibt verschiedene Kodierungsschemata für Zeichenintervalle (little und Big Endian) – komplexe Datentypen werden in verschiedenen Programmiersprachen unterschiedlich kodiert – Middleware sollte die Konvertierung der Daten transparent vornehmen Eine Standarddatenkodierung ist ein vereinbartes Zwischenformat Verschiedene Möglichkeiten die Heterogenität aufzulösen: – Darstellungsschicht – Anwendungsschicht – durch die Plattform (virtuelle Maschine) Zusammenfassung drei Dimensionen wo Heterogenität auftreten kann: – unterschiedliche Programmiersprachen – unterschiedliche Middleware – unterschiedliche Datenkodierungsverfahren – – – – – – Corba und Com lösen Programmiersprachenheterogenität dadurch auf, dass sie ein gemeinsames Objektmodell definieren und eine Schnittstelenbeschreibungssprache anbieten Die Implementierung der Sprachanbindungen erreicht man durch APIs und IDLs Compiler Middlewareheterogenität wird mittels Interoperabilitäts und Zusammenarbeitsspezifikationen aufgelöst Zusammenarbeitsspezifikationen bestimmen, wie unterschiedliche Middleware systeme sich an einer Objektanfrage beteiligen. Eine solche Spezifikation hat festzulegen, wie die Objektmodelle der teilnehmende Middleware aufeinander abgebildet werden Eine Auflösung in der Darstellungsschicht bildet Heterogene Datenkodierungen auf eine standardisierte Form ab, wie z.B XDR CDR NDR Eine Auflösung in der Anwendungsschicht durch explizite Datenkodierung mit den Objektanfragen mitgesendet werden z.b XML Dynamische Objektanfragen: – – Eine zur Übersetztungszeit des Clients definierte Objektanfrage ist eine statische Anfrage Eine zur Laufzeit des Clients definierte Objektanfrage ist eine dynamische Anfrage jede Objektanfrage muss folgende Punkte festlegen: 1. das Serverobjekt, von dem die Ausführung einer Operation angefragt wird 2. den Name der Operation, deren Ausführung angefragt wird 3. die aktuellen Parameter der angefragten Ausführung 4. eine Datenstruktur, die für die Ergebnisse der Operation bereitgestellt wird Dynamische Objektanfragen sind anfällig für Typunsicherheit Clients benötigen Reflection Schnittstellen, um zur Laufzeit Typinformationen aufzurufen Reflection Clients müssen ermitteln,ob die Server die Operation unterstützen, die sie dynamisch anfragen Prinzipien: – Reflection Schnittstellen bieten Details über den Typ der Serverobjekts zum Zeitpunkt der Ausführung an – Reflection Schnittstellen strukturieren Typinformation gemäß der Schnittstellenbeschreibungssprachen – Der IDL Compiler sammelt Reflection Information und speichert sie persistent Das Corba Schnittstellen Repository – Reflection wird in Corbas Schnittstelle unterstüzt – Operationen des SchnittstellenRepositorys spiegeln sich im abstrakten Syntaxbaum der IDL wieder – Typen des Schnittstellenrepositories sid in CORBA/ IDL definiert Dynamische Objektanfragen sind teuer in der Entwicklung und laufen langsamer – – Dynamische Aufrufe sind von Natur aus unsicher, weil der Namer der angefragten Operation als Zeichenkette oder Token verschlüsselt sind Reflection Mechanismen sind nötig um den Typ eines Serverobjektes zu ermitteln und um Typsicherheit zu gewähren Fortgeschrittene Kommunikation zwischen verteilten Objekten: Synchronisierung von Anfragen: Prinzipien: – Synchrone Anfragen blockieren den Client, bis der Server die Ausführung beendet hat – Nichtsynchrone Anfragen werden benötigt, um die Blockierung von Clients zu vermeiden – Einweganfragen geben die Kontrolle unmittelbar an den Client zurück und Client und Server werden nicht synchronisiert – verzögert synchrone Anfragen geben dem Client die Kontrolle sofort zurück und der Client ruft die Ergebnisse später mit aktivem Warten ab (Nachteil: bei der Ergebnisermittlung den Clients die Synchronisierung mit dem Server obliegt.Dabei kann insbesondere der Fall eintreten , dass zum Zeitpunkt des Aufrufs der Operation das Ergebnis nocht nicht vorliegt.Dann ist der Client blockiert oder die Anfrage muss erneut aufgerufen werden dh Polling ( aktives Warten)) – Asynchrone Anfragen geben die Kontrolle unmittelbar an den Client zurück und der Server ruft den Client zur Übermittlung des Ergebnisses auf ( Callback) – Nichtsynchrone Anfragen können durch Kombination von synchronen Anfragen und Multithreading erreicht werden Einweganfragen: ( Verwendung von Threads) – Die Blockierung des Hauptthreads kann verhindert werden, indem der synchrone Aufruf in einem neuen Thread getätigt wird – zur Vermeidung der Clientblockierung können Threads mit COM, Corba, Java verwendet werden Unterschied zwischen Einweganfragen und verzögert synchronen Anfragen besteht dadrin, dass der Client einige Zeit nach dem senden der Anfrage vom Request Objekt eine Operation get response aufruft. Damit werden Server und Clienr synchronisiert. Das Ergebnis ist dann in einer Datenstruktur verfügbar, die während der Operation create_request übergeben wurde. Asynchrone Anfragen: – können mit Hilfe von synchronen Anfragen und Threads implementiert werden Gebrauch von Nachrichtenschlangen: – realisieren asynchrone Anfragen. Sie müssen persistent gespeichert werden – arbeitet nach dem First in First out Prinzip und garantiert, dass Nachrichten in der gleichen Reihenfolge entnommen werden, in der sie auch angefügt wurden – eine Antwortschlange dient der Übertragung und Zwischenspeicherung der Antworten Anfragen-Multiplizität: – eine Unicast Anfrage geht von einem Clientobjekt an ein einziges Serverobjekt Die Anfrage eines Clients an mehrere Verschiedene Objekte zur Ausführung ein und derselben Operation wird Gruppenanfrage genannt – – Die Gruppenzusammensetzung wird von einem Kanal verwaltet und ist dem Client unbekannt Gruppenanfragen sind anonym Gruppenanfragen können mit Hilfe von synchronen Anfragen implementiert werden Multianfragen: – rufen Operationen von mehreren dem Client bekannten Serverobjekt auf – bei einer Multianfrage kann der Client Ergebnisse dann einsammeln, wenn sie verfügbar werden – können unter Verwendung von Tupelräumen implementiert werden – die Verwendung von Threads geht einher mit mit Performant und Entwicklungsoverheads Zuverlässigkeit von Anfragen: Unicast Anfragen: – exactly-once (dt genau einmal, werden garantiert genau einmal durchgeführt. Schwer zu erreichen und kostspielig) – atomic (dt atomar, entweder vollständig oder gar nicht) – at last once ( mindestens einmal, garantiert einmal, aber möglicherweise auch öfter) – at most once (höchstens einmal, benachrichtigen den Client wenn ein Fehler auftritt) – maybe (vielleich, weiss der Client nicht ob die Anfrage ausgeführt wird!) Gruppen und Multianfragen: – k-Zuverlässigkeit( mindestens k angefragte Operationem werden ausgeführt) – total geordnet( verhindern Anfragen am Überholen vorangegangener Anfragen) – bestmöglich( geben keine Garantie hinsichtlich der Dienstgüte vgl maybe) Zusammenfassung: – Anfragen in Java COM Corba sind per Voreinstellung unicast und synchron und werden at most once ausgeführt. Clients müssen Server mit einer Objektreferenz identifizieren – Einweganfragen werden niemals synchronisiert – verzögert synchrone Anfragen werden von den Clients mit Hilfe aktiven wartens synchronisiert (polling) – asynchrone Anfragen werden vom Server synchronisert – das senden von Multianfragen kann die Performanz von Anfragen erhöhen, da zum einen der Kommunikationsoverhead zwischen Client und Server reduziert wird und zum anderen die Clients die Wartezeit auf Ergebnisse verringern, weil sie sie in der Reihenfolge bearbeiten, wie sie verfügbar werden – Multianfragen können unter Verwendung von Tupelräumen, synchronen Anfragen und mehreren Threads in allen Formen realisiert werden Lokalisieren verteilter Objekte: Prinzipien des Naming: – ein Name ist eine Folge von Bezeichnern, die an eine Objektreferenz gebunden ist und die in die Referenz aufgelöst werden kann – Namensräume müssen hierarchisch strukturiert sein – die hierarchische Struktur erreicht man durch geschachtelte Namenskontexte Namensoperationen: – – – – – – – – – bind (führt eine neue Namensbindung für ein Objekt ein und wird von Administratoren benuzt, um ein Serverobjekt bei einem Nameserver zu registrieren; besteht aus zwei Parametern: Namen, Objektreferenz) resolve( gibt eine Objektreferenz für einen Namen zurück) list( alle in einem bestimmten Namenskontext definierten Namensbindungen) Es muss nicht jedes Serverobjekt an einen Namen gebunden werden Für das selbe Objekt können verschiedene Namen definiert werden Nameserver müssen ihre Namensräume persistent speichern Nameserver sollten auf effiziente Namensauflösung optimiert werden Eine Förderation von Namensservern besteht aus verknüpften Namenskontexten auf unterschiedlicher Middleware Ein Naming handbuch definiert das Layout des Namensraums Objekt Trading: – Clients können nicht immer ihre Server per Namen identifizieren Prinzipien des Objekt Tradings: – Teilnehmer am trading können Dienste exportieren, importieren oder sie vermitteln Spezifikationen von Diensttypen: – Diensttypen definieren Funktionalität und Güte von Diensten – Eigenschaften unterstützen die Definition der Dienstgüte – Eigenschaften sind als Eigenschaftstypen von Diensten definiert – Diensttypen definieren Name, Objekttyp und eine Menge von Eigenschaftstypen – die wesentlichen Trading Operationen sind register( Export von Diensten, withdraw( zuvor registrierte Dienste zu widerrufen) , query( nach Diensten fragen) and change( Eigenschaften von zuvor registrierten Diensten ändern) – Tradingrichtlinien bestimmen, wie Anfrageergebnisse behandelt werden – föderierte Trader exportieren und fragen gegenseitig nach Diensten Im Trading bestimmt ein Diensttyp einen Schnittstellentyp und eine Menge von Eigenschaftstypen. Ein Angebot ist eine Instanz eines Diensttyps. Ein Trader verwaltet eine Angebotsdatenbank, die Dienstangebote und ein Repository für Diensttypen enthält. Trader haben zwei Arten von Clients: Exporter und Importer – Exporter registrieren Angebote beim Trader. Der Trader fügt dieses Angebot seiner Angebotsdatenbank hinzu. Während des Exports werden Werte für alle obligatorischen Eigenschaftstypen des Dienstes zur Verfügung gestellt. Auf dieseweise können Exporter eine bestimmte Dienstgüte zusichern – Importer benutzen Dienstypen, Constraints, Richtlinien und Vorgaben, um den Trader zu fragen. Trader antworten auf Anfragen, indem sie eine Folge von Angeboten aus ihrer Datenbank zurückgeben, die dem Diensttyp entsprechen und sich an die Constraints und Richtlinien halten. Die Folge ist gemäß der Vorgaben sortiert. Der Lebenszyklus verteilter Objekte: Objektlebenszyklus: Erzeugung verteilter Objekte: Konstruktoren objektorientierter Programmiersprachen kann man den Ort neuer Objekte nicht mitgeben – Sicht des Cliententwicklers Eine Fabrik ist ein Objekt, das andere Objekte erzeugt. Eine abstrakte Fabrik verbirgt die Details der Erzeugung und wird in konkreten Fabriken verfeinert. 1. Ein Fabrikfinder ist ein Objekt, das eine Fabrik lokalisiert 2. Der Gebrauch von Fabriken ist unabhängig von der Middleware – Sicht des Serverentwicklers auf die Erzeugung 1. Serverentwickler müssen Fabriken entwerfen, die Fabriken erzeugen 2. Fabriken registrieren Objekte bei der Middleware und erhalten für diese Objektreferenzen 3. Die Registrierung wird unter Verwendung der Middleware Schnittstelle geleistet 4. Die Fabrik muss due Aktivierungsstrategie für das Objekt festlegen – Sicht der Administratoren auf die Erzeugung 1. Der ausführbare Code des Fabrik und des Fabrikfinders wird bei der Middleware registriert 2. der Fabrikfinder muss in den Namens- oder Tradingdienst eingefügt werden Migration von Objekten an entfernte Orte: Objektmigration bezeichnet das Kopieren oder Verschieben eines Serverobjekts von einem Rechner auf einen anderen. Middleware kann Migration nicht vollkommen transparent implementieren( Zielort bestimmen nicht möglich, kein Wissen über Datenstrukturen, Herkunfts und Zielhost können heterogen sein) – – – Sicht der Cliententwickler auf die Migration 1. Clientprogrammierer brauchen nur eine einzige Schnittstelle, um jeden Typ von Objekt migrieren zu können 2. Die Migration benuzt Fabriken zum Erzeugen von Objekten auf entfernten Hosts und Fabrikfinder als Ortsproxies Sicht der Serverentwickler auf die Migration 1. Jedes migrierbare Objekt muss Lebenszyklusoperationen implementieren 2. Neue Kopien müssen sowohl für das Kopieren als auch fpr das Verschieben von Objekten erzeugt werden 3. Die Auflösung der Datenheterogenität während des Attributtransfers verwendet die in Kapitel 5 besprochenen Mechanismen 4. Verschiebeoperationen müssen die Objektreferenz übertragen, um Migrationstransparenz zu erreichen 5. Heterogenität des Maschinencodes wird durch die Registrierung von Fabriken und Objektimplementierungen auf verschiedene Hosts aufgelöst Sicht des Administrators auf die Migration Die Administrationsaufgaben bei Migration sind dieselben wie bei der Erzeugung Orts und Migrationstransparenz: – Migration ist transparent für Client-, aber nicht für Serverentwickler – Fabrikfinder schaffen Ortstransparenz – Migration schafft keine Replikationstransparenz Löschen von Objekten: Referenzielle Integrität bedeutet, dass die Gültigkeit von durch einen Client gehaltenen Referenzen auf ein Serverobjekt garantiert ist! – Sicht des Cliententwicklers auf die Löschung 1. Speicherbereinigung bedeutet die implizite Löschung von nicht länger benötigten Objekten – – 2. Destruktoren sind Objekte, die definieren, was getan werden muss, wenn ein Objekt gelöscht wird 3. Referenzielle Integrität kann nicht über die Middleware Grenzen hinaus gewährleistet werden Sicht der Serverentwickler auf die Löschung 1. Objekte müssen ihre Verfügbarkeit als Dienstanbieter bei der Middleware widerrufen 2.Objekte müssen Resourcen freigeben Sicht der Administratoren auf die Löschung 1. Administratoren müssen die Löschung von Instanzen und die Löschung von Typen bedenken 2. Instanzlöschung beinhaltet das Entfernen von Objektreferenzen aus dem Ortsdienst 3. Die Löschung des Objekttyps beinhaltet eine Reihe von Aktivitätem - Löschung aller Fabriken, die Instanzen des Typs erzeugen - Löschung des Typs dieser Fabrik - Entfernung des Objekttyps aus dem Schnittstellen- Repository - Entfernung der Objektimplementierung aus dem Implementierungs- Repository Zusammengesetzte Objekte: Oft hat eine Gruppe von Objekten denselben Lebenszyklus. Sie zusammenzusetzen, ermöglicht es uns, Lebenszyklusoperationen auf die Gruppe anzuwenden Modellierung der verteilten Objektkomposition: Uml- Klassendiagramme liefern Administratoren und Programmierern eine Modell für die Komposition von Objekten Implementierung der komposition verteilter Objekte: – – Komposition sollte unter Verwendung eines Beziehungsdienstes implementiert werden Beziehungen sollten eigenständige Objekte sein Basisbeziehungen Ein Rollenobjekt ist ein Proxy für ein Objekt, das an einer Beziehung teilnimmt. Beziehungen werden von Fabriken erzeugt, die Kardinalitäts, Grad und Typisierungseinschränkungen prüfen Objekte die in einer Beziehung zueinander stehen, verwenden Rollen und Beziehungen Der Grad definiert, wie viele Rollen eine Beziehung hat Typisierungsbedingungen schränken die Objekttypen ein, die Rollen referenzieren können Graphen aufeinander bezogener Objekte Beziehungsdienste können Algorithmen zum Durchlaufen von Graphen implementieren Referenz und Enthaltenseinbeziehungen Ein Beziehungsdienst kann eine direkte Implementierung für die Semantik von UML Kompositionen liefern Der Lebenszyklus zusammengesetzter Objekte betrifft die Migration und die Löschung zusammengesetzter Objekte Definition einens zusammengesetztes Objekt: – ein zusammengesetztes Objekt wird durch einen Wurzelknoten bestimmt – Alle Rollenobjekte, die im transitiven Abschluss der Enthaltenseinbeziehungen liegen, gehören zum Objekt – – – – Alle Enthaltenseinbeziehungenobjekte, die mit diesem Knotenobjekten verbunden sind, gehören zum zusammengesetzten Objekt Alle Knotenobjekte, die mit den Rollenobjekten im zusammengesetzten Objekt verbunden sind, gehören zum zusammengesetzten Objekt Alle Serverobjekte, auf die Knoten verweisen, gehören zum zusammengesetzten Objekt Eine tiefe Lebenszyklusoperation ist eine Operation, die auf ein zusammengesetztes Objekt und alle in ihm enthaltenen Beziehungs und Rollenobjekte angewand wird Zusammenfassung: - Die vier Lebenszyklusoperationen sind: Erzeugen, Kopieren, Verschieben, Löschen von Objekten - Objekterzeugung wird von Fabriken unterstützt. Eine Fabrik ist ein verteiltes Objekt, das - - Operationen exportiert, die neie Objekte erzeugen. Die neu erzeugten Objekte operieren anfangs am selben Ort wie die Fabrik - Fabrikfinder werden werden von Migrationsoperationen genutzt, um den Ort des Hosts auf eine Weise zu bestimmen, die sowohl für den Client als auch für den Server transparent ist - Objektlöschung kann explizit oder implizit durchgeführt werden. Objekte werden explizit gelöscht, wenn autorisierte Clients eine Löschoperation anfragen. In diesem Fall müssen Clients referenzielle integrität sicherstellen. Objekte werden von der Middleware implizit gelöscht, wenn kein Clientobjekt eine Referenz auf das Objekt besitzt Objektpersistenz: Ein Persistenzdienst hilft Entwicklern von Serverobjekten, Persistenz zu implementieren Persistenz ist die Fähigkeit eines Objektzustands, das Ende des das Objekt ausführenden Prozesses zu überleben (standbehaftete und zustandslose Objekte) – – – – Zustandsbehaftete Objekte besitzen in ihrer Implementierung Instanzvariablen. Entwickler eines Serverobjekts müssens Persistenz implementieren Persistenzdienste verbergen die Details der Datenspeicherung vor Serverobjekten um Persitenz zu erreichen, müssen Daten aus dem Hauptspeicher in einen Sekundärspeicher (swap) Persistenzdienste – – – – – – – – Definnitionssprachen für Persistenzdienste definieren Objektpersistenz unabhängig von einem Datenspeicher Datenspeicher sind Speichertechnologien, die benutzt werden,um Persistenz von Daten zu erreichen Storagetypen definieren die Repräsentation der Storagetypen Storagetypspezifikationen sind Schnittstellen zu Storage-Objekten Eine Storage Objekt Inkarnation ist eine Repräsentation eines Storage-Objekts in einer Programmiersprache Ein Storage- Home regelt die Lebenszyklen der Typen von Storage Objekten. Seine Schnittstelle wird in einer Storage Home Spezifikation definiert Storage Home Inkarnationen sind Repräsentationen von Storage Homes in einer Programmiersprache Um Storage Objekte effizient identifizieren zu können, können Persitenzdienste das Konzept – – der Schlüssel unterstützen Eine Sitzung ist eine logische Verknüpfung zwischen Datenspeicher und einem Prozess, der ein Serverobjekt ausführt Persistenzdienste müssen mit Objektadaptern integriert werden Eine Persistenzdienststruktur: – Die Sitzungsverwaltung des Persistenzdienstes muss mit der Sitzungsverwaltung des Datenspeichers integriert werden( öffnen,schliessen von den Dateien) – Eine Schema ist eine Typdefinition von Informationen, die in einer für den jeweiligen Datenspeicher spezifischen Sprache definiert werden – Implementierungen von Serverobjekten sind von Schemata unabhängig und daher nicht an eine bestimmte Datenspeichertechnologie gebunden – Storage Objekt und Storage Home Inkarnationen sind abhängig von der Datenspeichertechnologie Erzeugen von Architekturkomponenten Storageobjekt und StorageHome Inkarnationen können automatisch erzeugt werden (PSSDL Compiler) Der PSSDL Compiler macht Serverobjekte von Datenspeichern unabhängig Datenspeichertechnologie für Persistenz: Dateien können Daten sequenziell oder in strukturierter Form speichern Relationale Datenbanken enthalten eine Menge von Tabellen, deren Struktur ein einem relationalen Schema definiert ist Trotz der Strukturunverträglichkeit sind relationale Datenbanken aufgrund ihrer Marktdurchdringung am meisten verbreitet – – – – – Zusammenfassung die gebräuchlichsten Formen der Herstellung von Persistenz sind die Verwendung von Dateisystemen, relationalen Datenbankverwaltungssysteme oder Objektdatenbanken als Datenspeicher, die Daten auf einem Sekundärspeicher abbilden Die Verwendung eines Dateisystems umfasst die Serialisierung von Objektrrepräsentationen in Ströme, die dann in einer Datei gespeichert werden Relationale Datenbanken stellen Persistenz durch die Speicherung von Objektattributen in Tabellen her. Damit ist eine objektrelationale Abbildung verbunden ,die zu einer Strukturunverträglichkeit führen kann Objektdatenbanken vermeiden diese Strukturunverträglichkeit durch dich unmittelbare Abbildung von strukturierten Objekten in einen Sekundärspeicher.
