DAS OBJEKTORIENTIERTE

Transkript

1 Gesamtverband der Deutschen Versicherungswirtschaft e.v. Prozesse Objekte Funktionen Daten Komponenten Request Broker Edition 1999 Die Anwendungsarchitektur der Versicherungswirtschaft DAS OBJEKTORIENTIERTE TECHNISCHE REFERENZMODELL VERSION 1.0 OBJEKTORIENTIERT GDV

2 Autoren: Das Projektteam "Objektorientiertes technisches Referenzmodell" Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.v., Berlin GDV 1999

3 Das objektorientierte technische Referenzmodell Willkommen bei VAA Edition 1999! Liebe Leserin, lieber Leser, haben Sie bereits eine der Broschüre der VAA Edition 1999 gelesen? Wenn ja, können Sie gleich weiter blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes VAA-Dokuments dieser Ausgabe. Ansonsten freuen wir uns über Ihr Interesse an der VAA und gratulieren Ihnen zu Ihrer Entscheidung, sich mit diesem Thema zu beschäftigen, an dem wir seit Jahren mit großem Engagement und immer noch mit viel Spaß arbeiten. Mit WIR sind alle gemeint, die sich in den letzten Jahren direkt an der Arbeit in den VAA-Gremien beteiligten. Um wen es sich dabei im einzelnen handelt, können Sie in einem Anhang der Broschüre ANFORDERUNGEN UND PRINZIPIEN nachlesen, darüber hinaus werden die VAA-Gremien auf der neuen VAA-CD und im Internet (Adresse vorgestellt. Nun zur Sache: Die VAA wurde in den vergangenen zwei Jahren in zwei Richtungen weiterentwickelt. Der erste Schritt in Richtung Objektorientierung ist getan. Sie finden in der VAA Edition 1999 das OBJEKTORIENTIERTE FACHLICHE REFERENZMODELL und das OBJEKTORIENTIERTE TECHNISCHE REFERENZMODELL der VAA. Das Geschäftsobjekt PRODUKT wurde bereits detailliert ausgearbeitet. Die prozedurale Variante lebt weiter. Sie wurde ergänzt um eine weitere fachliche Komponente, INKASSO/KONTOKORRENT. Darüber hinaus wurden die aufgrund der Aufnahme der Objektorientierung notwendig gewordenen Überarbeitungen und Ergänzungen der Dokumente der 2. Auflage von VAA vorgenommen. Es entstand eine Vielzahl von zum Teil sehr umfangreichen Dokumenten, die auf drei Wegen veröffentlicht werden: CD-ROM, Internet und als gebundene Broschüren in Papierform. Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren Dokumentationen der VAA Edition 1999 einen grafischen Wegweiser erstellt, den Sie auf der nächsten Seite finden können. Vielleicht hilft er Ihnen, sich zurechtzufinden und Ihre Schwerpunktthemen "herauszufischen". Viel Spaß beim Studium des hier und in den übrigen Dokumenten zusammengestellten VAA-Wissens. GDV

4 Das objektorientierte technische Referenzmodell Dokumentenstruktur der VAA Edition 1999 Anforderungen und Prinzipien Glossar neu überarbeitet VAA prozedural (pvaa) Version 2.1 Prozeduraler Rahmen neu Fachliche Beschreibung Inkasso/Kontokorrent Partner Partner/Anhang Provision Schaden/Leistung Vertrag Technische Beschreibung Datenmanager Datenmanager/Anhang Dialogmanager Parametersystem Workflow-/Vorgangsmanager neu überarbeitet VAA objektorientiert (ovaa) Version 1.0 Objektorientiertes fachliches Referenzmodell Hauptdokument Anhang A Use-Case-Modell Anhang B Klassenmodell Modell in Rational-Rose-Format Objektorientiertes technisches Referenzmodell Produkt neu neu neu neu neu neu GDV 1999

5 Das objektorientierte technische Referenzmodell Inhalt Inhaltsverzeichnis I. Einführung und Überblick... 6 I.1. Kontext...6 I.2. Elemente des technischen Referenzmodells...7 I.2.1. Die technische Architektur...8 I.2.2. Die Systemarchitektur...8 I.2.3. Fachliche Komponenten und technisches Referenzmodell...9 II. Die technische Architektur der VAA II.1. Die Object Management Architecture (OMA)...12 II.1.1. Definitionen und Grundbegriffe...12 II.1.2. Der Object Request Broker (ORB)...14 II.1.3. Charakterisierung der einzelnen Services...14 II Life Cycle Service...15 II Naming Service...16 II Relationship Service...17 II Persistence Service...21 II Transaction Service...23 II Concurrency Service...26 II Trader Service...27 II Collection Service...31 II Property Service...33 II Query Service...34 II Security Service...37 II Externalization Service...38 II Event Service...41 II.1.4. CORBA 3.0 und Java...43 II.2. Distributed Internet Architecture (DNA)...45 II.2.1. Definition und Grundbegriffe...45 II.2.2. Komponenten...45 II Präsentation...46 II Anwendungsservice...47 III. Die Systemarchitektur der VAA III.1. Komponente...48 III.2. Business Object...49 III.2.1. Definition...49 III.2.2. Struktur eines Business Objects...50 III.2.3. Typisierung...51 III Entity Business Object (EBO)...51 III Process Business Object (PBO)...52 III.2.4. Dienste...53 GDV 1999 i

6 Inhalt Das objektorientierte technische Referenzmodell III BO-Manager - Framework und BO-Persistence Service III Transparenter Zugriff auf Methoden eines Business Objects III Transparentes Speichern von Business Objects III Suchen von Business Objects III Erzeugen von Business Objects III Löschen von Business Objects III Transaktionsmanagement III Verwalten von BO-Beziehungen III Parametrisierung von Business Objects III Benachrichtigungsdienst zwischen Business Objects III.2.5. Business Objects und Komponenten III Vom Business Object zur Komponente III Allgemeine Typen von Objekten III.3. Präsentationskomponente III.4. Verteilung von Präsentation und Business Object III.5. Kopplung von Systemen III.5.1. Entkoppelung und Anpassung von Funktionalität III.5.2. Anpassungen der System- bzw. technischen Architektur IV. Architekturmodelle im Überblick...75 IV.1. Einordnung IV.2. OMG Vorschläge zur Business Object Architecture IV.2.1. Architekturziele und Kontext IV.2.2. Grundmuster der Architektur IV Definitionen IV Services IV BO- und Type-Manager Interfaces IV Shared Services IV.2.3. Wertung IV.3. IBM San Francisco IV.3.1. Architekturziele und Kontext IV.3.2. Grundmuster der Architektur IV Foundation Layer IV Common Business Objects Layer (CBOs) IV Core Business Processes Layer IV.3.3. Wertung IV.4. Enterprise JavaBeans IV.4.1. Architekturziele und Kontext IV.4.2. Grundmuster der Architektur IV Komponente IV Container IV Das Komponentenmodell IV Granularität der Komponenten ii GDV 1999

7 Das objektorientierte technische Referenzmodell Inhalt IV Standardisierte Schnittstellen...98 IV Anpassung ohne Änderung im Source Code...98 IV.4.3. Enterprise JavaBeans Komponentenmodell...99 IV Implizite Services...99 IV Portabilitätsschicht...99 IV Ausführung der Services IV.4.4. Detaillierte Beschreibung der EJB Architektur IV Transiente und persistente Objekte IV Naming und Registry IV EJB Objektschnittstelle IV Deklarierte Attribute IV Kontext Objekt und Environment Objekt IV.4.5. Beschreibung der Services IV Distribution Services IV State Management IV Persistence Management IV Transaction Management IV Security IV.4.6. Enterprise JavaBean Deployment IV.4.7. Wertung V. Ausblick VI. Glossar VII. Literatur GDV 1999 iii

8 Inhalt Das objektorientierte technische Referenzmodell Verzeichnis der Abbildungen Abbildung 1: Weg zu SW-Komponenten 7 Abbildung 2: Das technische Referenzmodell der VAA 8 Abbildung 3: Zusammenhang der Modelle und Architekturen 9 Abbildung 4: OMG-Architektur verteilter Systeme 12 Abbildung 5: Kommunikation zwischen Client- und Serverobjekten mit Hilfe des ORBs 14 Abbildung 6: Beispiel für CORBA Naming Context 17 Abbildung 7: Beispiel für die Verwendung des Relationship Services 20 Abbildung 8: Beispiele für die Verwendung von "graphs-of-related-objects" 21 Abbildung 9: Komponenten des Persistence Service 22 Abbildung 10: Komponenten des Transaction Service 24 Abbildung 11: Beispiel CORBA Transaction Service 25 Abbildung 12: Locking Modes des Concurrency Services 26 Abbildung 13: Kommunikation zwischen Trader, Server und Client im Trader Service 28 Abbildung 14: Beispiel Trader Service 30 Abbildung 15: Typen von Collections im Collection Service 32 Abbildung 16: Beispiel für den Property Service 34 Abbildung 17: Der CORBA Query Service 35 Abbildung 18: Beispiel für eine Query mit dem QueryManager 36 Abbildung 19: Prinzipieller Ablauf einer Berechtigungsprüfung in CORBA 38 Abbildung 20: Lesen und Schreiben von Objekten im Externalization Service 40 Abbildung 21: Beispiel für den Event-Service 42 Abbildung 22: Präsentation in der DNA 46 Abbildung 23: Kategorien von Business Objects 51 Abbildung 24: Entity Business Object 52 Abbildung 25: Process Business Object 53 Abbildung 26: Contracts zwischen Business Objects, BO-Manager - Framework und BO-Persistence Service 55 Abbildung 27: Proxy-Objekte für Business Objects 56 Abbildung 28: Business Objects als Komponenten 64 Abbildung 29: Heterogene komponentenorientierte Systeme 64 Abbildung 30: Kompatibilitätsebenen 65 Abbildung 31: Zusammenhänge im MVC-Konzept 66 Abbildung 32: Business Objects und Präsentationskomponenten 67 Abbildung 33: Konstruktionsprinzip von Präsentationen 68 Abbildung 34: Fat Client 69 Abbildung 35: Thin Client 69 Abbildung 36: Ultra Thin Client 70 Abbildung 37: Beispiel einer Systemanbindung durch Fassaden und Adapter 72 Abbildung 38: Konvergenz der Architekturen 72 Abbildung 39: Beispiel für die Anbindung eines Legacy - Systems 74 Abbildung 40: Einordnung der betrachteten Architektur-Frameworks 76 Abbildung 41: Interaktion von Business System Domains 78 Abbildung 42: Interface Hierarchie für Business Objects und Type Managers 80 Abbildung 43: InterOp Services über verschiedene Komponenten 81 Abbildung 44: Phasen des Commits im Transaction-Service (Interoperability Specification) 90 Abbildung 45: Ausblick auf die "Multi Layer Architecture" von San Francisco 92 Abbildung 46: Die San Francisco Architektur 93 Abbildung 47: Kategorien von Common Business Objects (CBO-Layer) 95 iv GDV 1999

9 Das objektorientierte technische Referenzmodell Inhalt Abbildung 48: Kern-Geschäftsprozesse in San Francisco 96 Abbildung 49 : Enterprise JavaBeans Container 100 Abbildung 50: Konvergenz der Komponenten-Architekturen 107 Verzeichnis der Tabellen Tabelle 1: Operationen des CORBA Naming Service 17 Tabelle 2: Eigenschaften von Diensten beim CORBA-Trader Service 28 Tabelle 3: Functional Interfaces des CORBA Trader Service 29 Tabelle 4: Administration Interfaces des CORBA Trader Service 30 Tabelle 5: Merkmale von CORBA Collections 32 Tabelle 6: Interfaces des CORBA Property Service 34 Tabelle 7 : Kompatibilität der Dienste des BO-Frameworks und der CORBA Services 56 Tabelle 8: Identity eines Business Objects (Interoperability Specification) 82 Tabelle 9: Life Cycle Operationen der Interoperability Specification 84 Tabelle 10: State Access Operationen der Interoperability Specification 84 Tabelle 11: Intrinsic events (Interoperability Specification) 85 Tabelle 12: Bedingungen für das Auslösen von Events (Interoperability Specification) 86 Tabelle 13: Bedingungen für die Übermittlung von Events (Interoperability Specification) 86 Tabelle 14: Interfaces des Query Service der Interoperability Specification 87 Tabelle 15: Introspection Interface (Interoperability Specification) 88 Tabelle 16: Exception Categories (Interoperability Specification) 88 Tabelle 17: Eigenschaften des Transaction Service (Interoperability Specification) 89 GDV 1999 v

10 Einführung und Überblick Das objektorientierte technische Referenzmodell I. Einführung und Überblick I.1. Kontext Das technische und fachliche Referenzmodell [i] bilden gemeinsam das Fundament der objektorientierten Versicherungs-Anwendungs-Architektur (VAA). Unter Referenzmodell wird in diesem Kontext folgendes verstanden: Das Referenzmodell ist eine einheitliche und konsistente Struktur, die es erlaubt, minimal und vollständig die Strukturen von Versicherungsunternehmen zu beschreiben. Einheitlichkeit und Konsistenz setzen präzise Definitionen der verwendeten Strukturelemente und ihrer Eigenschaften und Beziehungen voraus. In der objektorientierten Betrachtungsweise sind Objekte die grundlegenden Strukturelemente eines Modells, ihre Eigenschaften manifestieren sich in der Definition von Methoden und Objektvariablen. Einheitlichkeit in der Darstellung von Eigenschaften und Beziehungen sowie die Gewährleistung der Konsistenz wird durch den Einsatz einer Modellierungssprache wie UML (Unified Modelling Language) erleichtert. Das objektorientierte Begriffssystem und die Darstellungsformen der UML bilden somit die definitorischen und methodischen Grundlagen des technischen und fachlichen Referenzmodells. Die Rahmenbedingungen und Grundprinzipien der VAA sind auch Grundlage für die Gestaltung der objektorientierten Referenzmodelle. Sie sind ausführlich in dem Dokument beschrieben. Die Anwendungsarchitektur der Versicherungswirtschaft Grundlagen und Prinzipien Das objektorientierte technische Referenzmodell der VAA ist entsprechend der oben angegebenen Definition eine einheitliche und konsistente Struktur, die es erlaubt, minimal und vollständig den technischen Lebensraum von Versicherungskomponenten zu beschreiben. Das technische Referenzmodell soll die vollständige Umsetzung des fachlichen Modells ermöglichen, wobei die Beschreibung der dazu notwendigen technischen Mechanismen auf einer Stufe erfolgt, die unterschiedliche Realisierungsalternativen offenläßt, ohne daß die Wahl einer Alternative die Änderung des Referenzmodells erfordert. Komponentenmodelle und Softwarekomponenten Das technische Referenzmodell liefert die Vorgaben für die Strukturierung von Komponenten aus technischer Sicht. Das aus dem technischen Referenzmodell hervorgehende Komponentenmodell definiert, wie Komponenten miteinander kommunizieren und gemeinsame Dienste (z.b. für Transaktionssicherung) genutzt werden. Das technische Komponentenmodell bildet dabei den Rahmen für die Umsetzung fachlicher Komponenten im Sinne eines Metamodells. Dieses Metamodell definiert Begriffe wie Business Object oder Transaktion zur Verwendung im fachlichen Komponentenmodell, ohne daß ihre innere Funktion oder Struktur bekannt sein muß. 6 GDV 1999

11 Das objektorientierte technische Referenzmodell Einführung und Überblick Eine Softwarekomponente entsteht somit durch Zerlegung des fachlichen Referenzmodells in fachliche Teile (z.b. Partner und Vertrag) und deren Integration in das technische Komponentenmodell. Die folgende Abbildung zeigt schematisch den Zusammenhang zwischen Referenzmodell, Komponentenmodellen und Softwarekomponenten. Abbildung 1: Weg zu SW-Komponenten I.2. Elemente des technischen Referenzmodells Das technische Referenzmodell beschreibt einmal rein technische Dienste, die für das Funktionieren einer Anwendung notwendig sind (z.b. die Datenspeicherung oder die Präsentationstechnik), ohne daß diese Funktionen im fachlichen Modell in Erscheinung treten. Zudem definiert es Strukturvorgaben, Verhalten und Kategorien von Objekten (z.b. Business Object ), die für die Bildung fachlicher Komponenten relevant sind. Beide Aspekte des technischen Referenzmodells sollten soweit möglich getrennt voneinander betrachtet werden. Die Trennung zwischen technischen Diensten und Strukturvorgaben erleichtert die Beschreibung fachlicher Komponenten, ohne daß die konkrete technische Funktionsweise bekannt sein muß. Damit wird ein höherer Grad an Allgemeingültigkeit und Abstraktion erreicht, gleichzeitig ist ein Abgleich zwischen den fachlichen und technischen Anforderungen an ein Referenzmodell möglich, ohne daß technische Details diskutiert werden müssen. In fast allen modernen Anwendungsarchitekturen ist eine Trennung zwischen Strukturvorgaben und technischen Diensten zu finden. In Anlehnung an übliche Konventionen wird in diesem Dokument der Begriff Technische Architektur für die Beschreibung der technischen Dienste und der Begriff Systemarchitektur für Strukturvorgaben, Verhalten und Kategorien von Objekten verwendet. GDV

12 Einführung und Überblick Das objektorientierte technische Referenzmodell Technisches Referenzmodell Dienste BO-Transaktionen BO-Persistenz BO-Beziehungen Technische Dienste Business Objects und Komponenten Suchen Erzeugen Löschen Parametrisierung Events... CORBA Services Präsentation Datenbanken System- Architektur Technische Architektur Object Request Broker Abbildung 2: Das technische Referenzmodell der VAA I.2.1. Die technische Architektur Basis der technischen Architektur des Referenzmodells ist die Object Management Architecture der OMG (OMA), die Spezifikationen der CORBA-Services [ii] und des Object Request Brokers [iii]. Soweit bekannt wurden die unter CORBA 3.0 erwarteten Erweiterungen dieses Standards ebenfalls berücksichtigt. Die technische Architektur beschreibt die technischen Dienste des Referenzmodells in Form von Schnittstellenspezifikationen auf Basis der von der OMG genormten Interface Definition Language (IDL). IDL ist sprach- und plattformunabhängig und kann mittels sogenannter Language Bindings auf Programmiersprachen abgebildet werden. Der Begriff Dienst oder Service in objektorientierten Umgebungen beinhaltet nicht nur Funktionen, die von der eigentlichen Anwendung völlig getrennt sind und nur über eine Programmierschnittstelle (API) aufgerufen werden. Ebenso zählen auch Eigenschaften dazu, die ein Anwendungsobjekt von einer Serviceklasse erben kann (Beispiel: CORBA Collection und Property Service). In vielen Fällen werden Dienste auch als eine Konvention des gegenseitigen Nachrichtenaustauschs zwischen einem Serviceobjekt und den Anwendungsobjekten definiert, d.h. beide Objekte müssen ganz bestimmte Schnittstellen implementieren (Beispiel: CORBA Transaction und Event Service). Für diese Art der Servicegestaltung haben sich die Begriffe Protokoll oder Contract eingebürgert. Ebenfalls zu den technischen Diensten zählen Klassenbibliotheken für die Präsentation und Datenbanken. I.2.2. Die Systemarchitektur Das grundlegende Strukturelement der Systemarchitektur ist das Business Object (Geschäftsobjekt). Die Systemarchitektur definiert den Begriff Business Object und beschreibt dessen innere Struktur, arbeitet verschiedene Typen von Business Objects heraus und definiert Anforderungen an Komponenten und deren Interaktion. Sie stellt somit ein Metamodell für die Realisierung fachlicher Objekte 8 GDV 1999

13 Das objektorientierte technische Referenzmodell Einführung und Überblick und Komponenten dar. Das Metamodell bedient sich dabei technischer Dienste und Strukturen, die in der technischen Architektur definiert sind. Die Systemarchitektur beschreibt darüber hinaus Dienste für die Verwaltung von Business Objects und Komponenten. Zusätzlich beschreibt sie Verteilungsoptionen für Anwendungssysteme. Wie bei der technischen Architektur sind Dienste der Systemarchitektur nicht nur als Programmierschnittstellen zu verstehen. In vielen Fällen sind sie als Basisklassen für Business Objects angelegt oder definieren ein Protokoll zwischen Business- und Service-Objects. Die OMG benennt Dienste auf der Ebene der Systemarchitektur in den Common Facilities Architecture (CORBAFacilities) [iv]. Die Dienste der Systemarchitektur vereinfachen die Verwendung der technischen Dienste im Kontext von Business Objects und ergänzen stärker fachlich oder system-management - orientierte Funktionalität. Die dadurch erzielte Entkopplung zwischen technischen Diensten und Business Objects bedeutet gleichzeitig eine größere Unabhängigkeit von der Weiterentwicklung technischer Plattformen. Die Systemarchitektur der VAA orientiert sich an bekannten Ansätzen komponentenorientierter, verteilter Anwendungsarchitekturen wie (Enterprise)JavaBeans, SanFrancisco und der Interoperability Specification der OMG, ohne jedoch eine spezifische Implementierung vorauszusetzen. I.2.3. Fachliche Komponenten und technisches Referenzmodell Die folgende Abbildung zeigt den Zusammenhang zwischen fachlichen Komponenten, Systemarchitektur und technischer Architektur: Fachliches Referenzmodell Versionierbar (from LibraryPackage) Actor-Role -Pattern VersionierbarerAkteur Standard 0..1 an Anschrift Person Standard * * an Rufnummer * Standard Ba 0..1 Bankverbindung 0..1 Fachliche Komponentenmodelle Technisches Referenzmodell Dienste BO-Transaktionen BO-Persistenz BO-Beziehungen Technische Dienste Business Objects und Komponenten Suchen Erzeugen Löschen Parametrisierung Events... CORBA Services Präsentation Datenbanken System- Architektur Technische Architektur Object Request Broker Abbildung 3: Zusammenhang der Modelle und Architekturen GDV

14 Einführung und Überblick Das objektorientierte technische Referenzmodell Basisdienste wie Betriebssysteme, Netzwerkprotokolle bzw. -Infrastruktur und Hardware- Eigenschaften sind nicht Bestandteil des technischen Referenzmodells, sondern stellen die technische Infrastruktur eines Anwendungssystems dar. Aspekte der technischen Infrastruktur werden nur berücksichtigt, wenn damit wichtige Anforderungen an die Realisierung des technischen Referenzmodells verknüpft werden. 10 GDV 1999

15 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA II. Die technische Architektur der VAA Basis der technischen Architektur des Referenzmodells ist die Object Management Architecture der OMG (OMA) und die Spezifikationen der CORBA-Services und des Object Request Brokers. Die Object Management Architecture implementiert wichtige Elemente der VAA-Grundprinzipien [v]: Verteilung (Grundprinzip der Zerlegung) Der Object Request Broker (ORB) ermöglicht die plattformübergreifende Verteilung von Systemkomponenten. Entkopplung (Grundprinzip der Zerlegung) CORBA stellt mit seinem Interface-Konzept den Grundmechanismus für die Entkopplung von Systemkomponenten zur Verfügung. CORBA-Interfaces sind sprachneutral und können unter den gebräuchlichsten Sprachumgebungen (u.a. prozedurale Sprachen wie COBOL und C) eingesetzt werden. Viele CORBA-Services sind auf eine möglichst weitreichende Unabhängigkeit von Komponenten ausgelegt (z.b. Relationship und Event Service). Interaktion (Grundprinzip der Zerlegung) CORBA stellt einen Event Service für die Kommunikation zwischen Komponenten zur Verfügung und stellt mit IDL eine typsichere Schnittstellenbeschreibungssprache zur Verfügung. Wiederverwendung, Konvergenz und Migration (Grundprinzip der evolutionären Entwicklung) Durch die Trennung von Interface und Implementierung von verteilten Objekten werden die Voraussetzungen für eine evolutionäre Entwicklung von Systemteilen und ihrer Wiederverwendung in anderem Kontext geschaffen. Grundprinzip der Strukturierung Die Object Management Architecture liefert ein technisches Modell für die Strukturierung von Anwendungssystemen in ORB, Services, Facilities und Domain Interfaces (siehe folgenden Abschnitt). Microsofts Distributed InterNet Architecture (DNA) ist ein konkurrierendes Architekturkonzept. Obwohl in DNA eine Reihe von Merkmalen wie Plattformunabhängigkeit und Interoperabilität weniger stark ausgeprägt sind wie in OMA, handelt es sich um ein Modell, das aufgrund der weiten Verbereitung von MS Windows eine wichtige Rolle bei der Entwicklung verteilter Anwendungssysteme spielt, insbesondere in desktop-orientierten Systemen. Im Anschluß an die Darstellung der Object Management Architecture folgt eine kurze Darstellung der Architektur und der Komponenten von DNA. Vergleiche zwischen DNA (bzw. den zugrundeliegenden Basistechnologien) und CORBA unter verschiedenen Aspekten sind in der Literatur zu finden (vgl. [vi] und [vii]). Weitere Elemente der technischen Architektur Die CORBA Standards enthalten keine Spezifikationen zur Benutzerschnittstelle. Angaben dazu in den CORBA Facilities [iv] haben lediglich Definitionscharakter. Wichtig aus Sicht des VAA- Referenzmodells ist vor allem das Zusammenspiel zwischen Fachlogik, Steuerung und Präsentation GDV

16 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell unter Verteilungsaspekten (siehe hierzu Kapitel III.2.5 und III.3), die Präsentationstechnik selbst ist nicht Gegenstand des Referenzmodells. Das technische Referenzmodell berücksichtigt in stärkerem Maße die unterschiedlichen Formen der Datenspeicherung als der CORBA Persistence Service. Insbesondere die bei Versicherungsunternehmen immer noch wichtige Anbindung von IMS- oder VSAM - Datenbanken wird konzeptionell berücksichtigt (siehe hierzu Kapitel III.2.4.1). II.1. Die Object Management Architecture (OMA) II.1.1. Definitionen und Grundbegriffe Untenstehende Abbildung zeigt die Architektur verteilter, objektorientierter Systeme aus Sicht der Object Management Group, die sogenannte Object Management Architecture (OMA). Abbildung 4: OMG-Architektur verteilter Systeme Object Request Broker und CORBA Services Im Mittelpunkt der OMA-Architektur steht der Object Request Broker (ORB). Seine Funktionsweise und Systemeinbettung bildet einen der Hauptbestandteile der CORBA-Spezifikation. Unter dem Sammelbegriff CORBA 2.0 werden neben der reinen Broker-Funktionalität auch eine Reihe allgemeiner technischer Dienste verstanden, die sogenannten CORBA-Services (s.u.). Die CORBA-Services spezifizieren Verhalten und Schnittstellen verteilter Objektsysteme hinsichtlich Transaktionsmanagement, Objekterzeugung, Persistenz u.ä. 12 GDV 1999

17 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA Interface Definition Language (IDL) Die Beschreibung des Verhaltens von Objekten erfolgt durch Spezifikation ihrer Schnittstellen ( Methoden ) mit Hilfe der Interface Definition Language IDL. IDL ermöglicht die plattform- und sprachenunabhängige Spezifikation dieser Schnittstellen. Das Ziel der Sprachenunabhängigkeit wird von der OMG dabei konsequent verfolgt. So werden zum Beispiel auch Vererbungsbeziehungen auf der Ebene der IDL-Schnittstellen beschrieben und nicht durch Angabe entsprechender Objektbeziehungen. Für die Implementierung existieren sogenannte Language Binding Spezifikationen, die beschreiben, auf welche Weise IDL-Aufrufstrukturen und Datentypen auf die Strukturen der jeweiligen Programmiersprache abgebildet werden. Internet Interorb Protocol (IIOP) Für die Kommunikation verwenden Object Request Broker heutzutage vor allem das ebenfalls von der OMG spezifizierte Internet Interorb Protokoll (IIOP), das auch die Kommunikation zwischen ORBs verschiedener Hersteller erlaubt. Domain Interfaces In den letzten Jahren entwickelte die OMG verstärkt Aktivitäten zur Spezifikation von sogenannten Domain Interfaces. Domain Interfaces beschreiben das Verhalten von verteilten, objektorientierten Systemen, die ein bestimmtes Geschäftsfeld ( business domain ) abdecken. Verantwortlich für Spezifikationen in diesem Bereich sind sogenannte Domain Task Forces. Wichtig für Finanzdienstleistungsunternehmen ist die Business Object Domain Task Force (BODTF) und die Financial Domain Task Force (FDTF) und ihre Arbeitsgruppe Insurance Working Group (IWG). Die Arbeiten von FDTF und IWG sind rein fachlich orientiert und dienen im wesentlichen zur Spezifikation eines fachlichen Referenzmodells. BODTF liefert Spezifikationen für Business Objects allgemeiner Natur und ist deshalb für die technische Referenzarchitektur von Bedeutung. Die folgenden Standardisierungsvorschläge der BODTF wurden bei der Definition des technischen Referenzmodells näher betrachtet (siehe Kapitel IV.2): Interoperability Specification [viii] Business Object Component Architecture (BOCA) [ix] Es ist nicht damit zu rechnen, daß diese Vorschläge in ihrer heutigen Form zur Standardisierung gelangen. Der Erfolg von Java und dem Komponentenmodell JavaBeans bzw. Enterprise-JavaBeans veranlaßte die OMG, sich stärker an dieser Entwicklung zu orientieren. Man kann davon ausgehen, daß innerhalb des Jahres 1999 OMG-Spezifikationen vorliegen werden, die sich stark an JavaBeans und Enterprise-JavaBeans orientieren (siehe Kapitel II.1.4). Aus diesem Grund wurden bei der Definition des technischen Referenzmodells die JavaBeans- und Enterprise-JavaBeans - Spezifikationen besonders berücksichtigt (siehe Kapitel IV.4). Ein weiterer Grund für die Orientierung an modernen Java-basierten Komponententechnologien ist das Fehlen ausreichender OMG-Spezifikation für die Serverseite einer verteilten Anwendung. Die CORBA 2.0 Spezifikation läßt zuviel Raum für ORB-Hersteller bei der Gestaltung der Objekt- und Transaktionsverwaltung auf der Serverseite, wodurch Implementierung mit unterschiedlichen ORBs nicht kompatibel sind. Diese Mängel sollen durch CORBA 3.0 (siehe Kapitel II.1.4) und vor allem durch das Zusammenwachsen von CORBA und Enterprise-JavaBeans behoben werden. GDV

18 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell II.1.2. Der Object Request Broker (ORB) Der Object Request Broker (ORB) definiert einen Objektbus, auf dem Client-Objekte mit verteilten Serverobjekten plattformunabhängig kommunizieren können. Der ORB ist unter anderem zuständig für die Übertragung der Aufrufparameter, der plattformabhängigen Formatierung der Werte und der Erzeugung einer system-übergreifenden Objektreferenz. Im allgemeinen kommuniziert ein Client- Objekt nicht direkt mit dem ORB, wenn es Methoden eines Server-Objektes aufrufen will, sondern über sogenannte Stubs. Stubs sind lokale Repräsentationen von Server-Objekten auf dem Client, die aus der IDL-Spezifikation der Serverobjekte generiert werden. Die Kommunikation mit dem ORB geschieht innerhalb der Stubs. Für den Client erscheint dadurch das Serverobjekt wie ein lokales Objekt. Server-seitig geschieht die Anbindung des Server-Objektes an den ORB über sogenannte Skeletons und Object Adapters. Skeletons übermitteln Methodenaufrufe eines Clients an das Serverobjekt, Object Adapters stellen den Skeletons und den Serverobjekten eine ORB-Schnittstelle zur Verfügung. CORBA spezifiziert die Grundfunktionalität, die jeder Object Adapter zur Verfügung stellen muß, den sogenannten Basic Object Adapter (BOA). Der ORB benötigt sowohl auf dem Client als auch auf dem Server Informationen über die Schnittstellen, Bezeichnungen und Aufrufparameter verteilter Objekte. Client-seitig werden diese Informationen im Interface Repository gespeichert, auf dem Server im Implementation Repository. Stubs sind nur verwendbar, wenn alle Methoden und Aufrufparameter eines Serverobjekts zur Entwicklungszeit bekannt sind. Für dynamisch konfigurierbare Systeme stellt CORBA ein dynamic invocation interface (DII) zur Verfügung, mit deren Hilfe Methodenaufrufe zur Laufzeit erstellt werden können. Analog dazu gibt es server-seitig ein dynamic skeleton interface (DSI). Client static invocation Anwendungsobjekt 1. Objekt erzeugen mit Angabe der Referenz 2. Aufruf method() Stub von "aobj" method() Client - ORB Server Implementierung der Klasse von "aobj" Skeleton dynamic invocation (DII) Anwendungsobjekt 1. aobj, Parameter, method() dem req- Objekt mitteilen; 2. Aufruf req.invoke() Request - Objekt invoke() Client - ORB Server-ORB aobj method() IIOP IIOP Abbildung 5: Kommunikation zwischen Client- und Serverobjekten mit Hilfe des ORBs II.1.3. Charakterisierung der einzelnen Services Generell bestehen alle CORBA-Spezifikationen aus Schnittstellen-Beschreibungen, die sogenannten Interface Definitions. In einem verteilten, plattformunabhängigen System sind die in IDL definierten Interfaces das einzige, was ein Objekt von einem Service wissen muß. Der Ort des Objektes, das einen Service implementiert, ist völlig transparent. CORBA Services bestehen in vielen Fällen aus Interface - Beschreibungen von Objekten, die den betreffenden Service implementieren und Beschreibungen von Interfaces, die ein Objekt, das den Service nutzen will, selbst implementieren muß. Es handelt sich also um eine wechselseitige Vereinbarung, 14 GDV 1999

19 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA wie mit bestimmten Aufgaben umzugehen ist. In der objektorientierten Literatur hat sich dafür der Begriff Protokoll eingebürgert. Objekte, die einen Service implementieren, werden vom Hersteller eines CORBA kompatiblen ORBs zur Verfügung gestellt. Für Interfaces, die ein Objekt implementieren muß, das einen Service nutzen will, stehen im allgemeinen Basisklassen zur Verfügung, von denen die Anwendungsobjekte abgeleitet werden können. CORBA Interface-Beschreibungen werden in sogenannten Modulen zusammengefaßt. So enthält zum Beispiel das Modul cosrelationships alle Interface-Beschreibungen des Relationship Service. II Life Cycle Service Definition Der Life Cycle Service definiert Dienste und Konventionen zur Erzeugung, zum Löschen, Kopieren und Verschieben von Objekten. Diese Operationen können auch Beziehungen zwischen Gruppen verwandter Objekte behandeln. Das sind z.b. Containment- und Referenzbeziehungen, oder das Erzwingen von referentieller Integrität zwischen Objekten. Beziehungen zwischen Objekten werden mit dem Relationship Service definiert, d.h. der Life Cycle Service stellt Schnittstellen bereit, die vom Relationship Service abgeleitet sind. Darüber hinaus benötigt der Life Cycle Service noch den Naming Service, um Objekte zu finden. Objekte werden durch sogenannte Factories erzeugt. Factories sind Objekte, die über Methoden verfügen um ein Objekt eines bestimmten Typs zu erzeugen [x]. Um ein neues Objekt zu erzeugen, muß ein Client zunächst die zugehörige Factory finden. Dazu benutzen Clients entweder Suchmechanismen, wie den Trader Service oder das FactoryFinder - Interface oder sie erhalten Factory-Objekte als Parameter von Operationen. Es gibt kein Standard Interface für eine Factory. Sie sind abhängig von der Objektimplementierung, d.h. verschiedene Objektimplementierungen können verschiedene Factory Interfaces definieren. Da es kein Standard Interface für eine Factory gibt, existiert ein Generic Factory Interface, das eine generische Operation zur Erzeugung von Objekten bereitstellt. Um ein Objekt zu erzeugen, muß der Client eine Objekt Referenz für eine Factory (entweder generische Factory oder objektspezifische Factory) besitzen und einen create - Request an diese absetzen. Als Ergebnis auf den create - Aufruf wird ein neues Objekt von der Factory erzeugt und die Objektreferenz an den Client zurückgeliefert. Die Factory ist für die Bereitstellung der benötigten Ressourcen verantwortlich. Um ein Objekt zu löschen, muß der Client einen remove - Request an das Objekt absetzen. Dieses Objekt muß jedoch das LifeCycleObject Interface unterstützen. Die Objektreferenz wird ungültig, der Client ist jedoch nicht für das Freigeben der Ressourcen verantwortlich. Um Objekte zu kopieren oder zu verschieben, muß der Client einen copy- oder move - Request an das Objekt absetzen. Auch hier muß das Objekt wieder das LifeCycleObject Interface unterstützen. Zunächst wird ein neues Objekt im Bereich des Factory Finders angelegt. Der Factory Finder definiert eine Schnittstelle, um Factories zu finden. Bei einem copy oder move wird demnach mit Hilfe des GDV

20 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell Factory Finders die entsprechende Factory im Zielnamensraum gefunden und ein neues Objekt durch die gefundene Factory erzeugt. Dieses Objekt wird mit den Daten des zu kopierenden oder zu verschiebenden Objektes initialisiert. Bei einem move - Request wird zusätzlich noch die Objektreferenz im Quellnamensraum gelöscht. Bei einem sogenannten deep-copy oder deep-move werden nicht nur die angegebenen Objekte in einen anderen Namensraum transferiert, sondern alle mit diesem Objekt in Beziehung stehenden Objekte. Diese werden über den Relationship Service identifiziert. Wertung In einem über mehrere Adressräume verteiltem Objektsystem ist ein Life Cycle - Service unbedingt erforderlich. Der Life Cycle - Service von CORBA stellt einen Satz von Schnittstellen bereit, die auch bei Verwendung unterschiedlicher Plattformen in einer Systemlandschaft die gleichen Verfahren zum Erzeugen, Verschieben und Löschen von Objekten garantieren. II Naming Service Definition Der Naming Service ist ein Mechanismus für Objekte in einer verteilten Umgebung andere Objekte zu finden. Der Naming Service erlaubt die Assoziation eines Objekts mit einem Namen in einem sogenannten Namensraum, das sogenannte Name Binding. Dieser Namensraum bildet den Namenskontext (Naming Context), in dem der Objektname eindeutig ist, d.h. Namen werden immer relativ zu einem Namenskontext definiert. Der Naming Service wird von folgenden Diensten benötigt: Life Cycle, Query, Ein Name setzt sich aus einer geordneten Folge von Komponenten (ordered sequence of components) zusammen, wobei eine Komponente aus einem Key-Value - Paar (identifier attribute / kind attribute) besteht, das vom Naming Service nicht interpretiert wird. Die Folge von Komponenten bilden einen zusammengesetzten Namen (vergleichbar mit der Pfadangabe einer Datei bestehend aus einer Kette von Unterverzeichnissen). Jede Komponente, mit Ausnahme der letzten, wird dazu verwendet, den Kontext zu benennen. Die letzte Komponente stellt den eigentlichen Namen des Objektes dar. Allein die Implementierung kann anwendungs- oder plattformspezifisch sein. Das CosNaming Modul besteht aus zwei Schnittstellen, die den Naming Service definieren. Naming Context Interface Binding Iterator Interface Im Naming Context - Interface sind folgende Operationen definiert: Binding objects Name resolution Eine Namen-Objekt Zuordnung wird für einen bestimmten Kontext erzeugt. Hiermit wird ein Objekt über den assoziierten Namen gefunden. Es wird jedoch nicht der Typ des Objektes zurückgeliefert. Der Client ist für den richtigen Objekttyp selbst verantwortlich. 16 GDV 1999

21 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA Unbinding Creating naming contexts Deleting contexts Die Zuordnung Objekt Name wird für einen bestimmten Kontext aufgehoben. Anlegen neuer Namenskontexte Löschen bestehender Namenskontexte Listing a naming context Anzeigen bestehender Namenskontexte Tabelle 1: Operationen des CORBA Naming Service Das Binding Iterator - Interface kann benutzt werden, um die gesamte Kette der Komponenten eines Namens Schritt für Schritt durchzugehen. Beispiel Abbildung 6: Beispiel für CORBA Naming Context Wertung In verteilten Systemen ist die Möglichkeit der hierarchischen Namensgestaltung für Objekte unbedingt erforderlich. Insbesondere für systemweit verfügbare Dienste sind sprechende Namen zu empfehlen. Gegenüber anderen Implementierungen hat der CORBA Naming Service den Vorteil der Plattformunabhängigkeit. II Relationship Service Definition GDV

22 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell Der Relationship Service ermöglicht es, Beziehungen von Objekten plattformübergreifend zu verwalten. Folgende Merkmale zeichnen den Service aus: Zur Darstellung von Relationen wurden zwei neue Arten von Objekten eingeführt: Rollen und Relationen. Beide können spezifische Attribute zur Beschreibung einer Relation erhalten. Typbeschränkungen und Kardinalitätskriterien können über den Relationship Service definiert und überprüft werden. Sie sind unabhängig von den beteiligten Objekten. Der Life Cycle Service und Relationship Service sind aufeinander abgestimmt. Einerseits werden Operationen wie Copy, Move und Remove auf Graphen von Objekten angewandt. Andererseits stellt der Relationship Service Methoden zur Verfügung, mit denen der Life Cycle Service Graphen von Objekten durchlaufen kann, ohne die entsprechenden Objekte zu aktivieren. Der Relationship Service unterstützt die Komponente compound life cycle des Life Cycle Service Verteilte Implementierungen des Relationship Service können eine ähnliche Performanz und Verfügbarkeit haben, wie Corba-Zugriffe über die Objektreferenz. Rollenobjekte können zusammen mit Ihren Objekten abgelegt werden und müssen nicht notwendigerweise in einem zentralen Repository hinterlegt werden. Der Relationship Service ist dreistufig aufgebaut: Base Relationship Model Graphs of related Objects Specific Relationships Base Relationship Model Relationen und Rollen bilden die Basis des Relationship Services. Rollenobjekte ermöglichen eine dynamische Subtypisierung von Objekten. Durch die Einführung von Rollenobjekten ist es möglich, kontextabhängige und -unabhängige Aspekte von Objekten zu trennen. Eigenschaften, die über Rollen definiert sind, und Relationen, die auf diesen Rollen aufsetzten, können sich kontextabhängig ändern, ohne daß die Objekte, denen sie zugeordnet sind, ihre Eigenschaften ändern müssen. Demgegenüber werden die kontextunabhängigen Eigenschaften von Objekten in deren eigene Spezifikation und Schnittstelle übernommen. Die Relationen und die Rollen, die innerhalb des Relationship Service eingesetzt werden, haben IDL- Schnittstellen und werden über eigene Factories verwaltet. Die Kardinalität einer Rolle gibt an, wie viele Relationen eine Verbindung zu ihr haben können. Der Grand (Degree) einer Relation gibt an, zu wie vielen Rollen sie in Verbindung stehen kann. Im Base Relationship Model stehen folgende Operationen zur Verfügung: Erzeugen eines Rollen- oder Relationenobjektes (fällt in die Zuständigkeit der Rollen- oder Relationen-Factory). Navigieren durch eine Relation Löschen von Rollen und Relationen Iteration über die Relationen an denen eine Rolle teilnimmt (fällt in die Zuständigkeit des Relationen-Iterators). 18 GDV 1999

23 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA Für jede Rolle werden zwei Typen von Kardinalitäten definiert: Minimum und Maximum. Minimum: Die minimale Anzahl von Instanzen einer Relation, an denen die Rolle teilnimmt. Maximum: Die maximale Anzahl von Instanzen einer Relation, an denen die Rolle teilnimmt. Die Interfaces des Base Relationship Models werden im CosRelationships - Modul beschrieben. Letzteres enthält Relationship- und Role Interface Relationship- und Role Factory Relationship Iterator (zählt die Anzahl der Relationen, an denen eine Rolle teilnimmt). Beispiel Ein Beitragszahler überweist seine Beiträge zu einem bestimmten Vertrag über sein Girokonto auf ein Konto des entsprechenden Versicherungsunternehmens. Durch die Zuordnung Kunde - Kundenkonto - Eingangskonto - Vertrag wird eine Zahlung als Beitragszahlung zu dem entsprechenden Vertrag identifiziert. Es wäre nicht ausreichend nur das Kundenkonto zu ermitteln und dieses einer Person zuzuordnen. Es besteht die Möglichkeit, daß dieselbe Person eine Immobilie aus dem Vermögen der Versicherung gemietet hat und die Miete von dem gleichen Konto überweist. Eine sichere Unterscheidung ist - in diesem Beispiel - nur möglich, wenn für diese Mietzahlungen ein anderes Eingangskonto eingerichtet wird. In der beschriebenen Situation treten unterschiedliche Aspekte eines Girokontos zu Tage. Letzteres hat zunächst eine Reihe von Eigenschaften, die unabhängig von besonderen Anwendungssituationen sind: Kontonummer, Bankleitzahl etc. Diese Eigenschaften wird man in die Definition der Klasse Konto übernehmen. Darüber hinaus gibt es jedoch einige Aspekte, die nur in bestimmten Anwendungssituationen von Bedeutung sind. Ein Konto dient z.b. als Beitragskonto für Versicherungsbeiträge und in diesem Zusammenhang spielt die Zuordnung Girokonto des Kunden - Vertrag - Eingangskonto eine Rolle. Ähnlich verhält es sich mit dem Mietverhältnis zwischen dem Versicherungsunternehmen und dem Kunden. Hier ist die Zuordnung Girokonto des Kunden - Immobilie - Eingangskonto der Vermögensverwaltung von Bedeutung. Wird das Konto eines Partners mit der Rolle Kundenkonto versehen, so wird es dadurch zu einer speziellen Ausprägung der Klasse Konto und stellt somit eine Reihe von neuen Eigenschaften zur Verfügung. Diese Subtypisierung kann vorgenommen werden, ohne daß das Objekt Konto selbst etwas davon "erfährt". Das Konto kann darüber hinaus eine Reihe von zusätzlichen Rollen erhalten - z.b. Mietkonto - ohne daß diese gegenseitig sich in irgendeiner Form beeinflussen. Erfolgt in unserem Beispiel nach einer gewissen Zeit eine Beitragsfreistellung des Vertrages, dann wird die Relation Beitragsverhältnis gelöscht und mit ihr die entsprechenden Rollenobjekte Kundenkonto, beitragspflichtiger Vertrag etc. Die Darstellung des Kontos selbst und auch die übrigen Rollen des Kontos bleiben davon unberührt. Bei den übrigen Objekten Kunde, Versicherungsunternehmen etc. und ihren Rollen liegen ähnliche Verhältnisse vor. GDV

24 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell Rolle: Konto von Rolle: Kontoinh. Rolle: Beitragszahler Konto Relation Girokonto Person Vertrag Relation Beitragsverhältnis Rolle: Beitragspflichtiger Vertrag Rolle: Beitragskonto für Vertrag Konto Relation Girokonto VU Rolle: Konto von Rolle: Kontoinh. In diesem Beispiel hat die Relation "Beitragsverhältnis den Degree 3 und die Relation Girokonto den Degree 2. Die Kardinalität der Rolle "Konto von" wäre 1 und der Rolle Eingangskonto wäre die Kardinalität n zuzuordnen. Abbildung 7: Beispiel für die Verwendung des Relationship Services Graphs of related Objects Ein Graph ist eine Menge, die aus Knoten (Nodes) und Kanten (Edges) besteht. Dabei sind Knoten identifizierbare Objekte, die das Node-Interface unterstützen. Knoten stellen eine Menge (Collection) aus verschiedenen Rollen eines Objektes und dem Objekt selbst dar. Über das Node-Interface der einzelnen Knoten können Graphen nach verschiedenen Kriterien durchlaufen werden (Traversal ). Dazu muß ein Knoten folgende Eigenschaften besitzen: Ein Readonly Attribut, das alle Rollen des Knotens beschreibt Eine Methode, die es erlaubt, Rollen eines bestimmten Typs auszugeben Operationen, um Rollen hinzuzufügen oder zu löschen. Der Relationship Service definiert ein Traversal Object, das bei Angabe eines Startpunktes eine Folge von gerichteten Kanten des entsprechenden Graphen ausgibt. Jede dieser Kanten ist wie folgt aufgebaut: Eine Instanz der Relation Ein Start-Knoten und eine Start-Rolle der Kante Eine Folge der restlichen Knoten ( bei einer n-ären Relation sind dies (n - 1) Knoten ) Beim Durchlaufen eines Graphen müssen Zyklen erkannt bzw. vermieden werden. Ferner wird durch das TraversalCriteria - Interface der Durchlauf des Graphen gesteuert. Zu jeder Kante eines Graphen wird über dieses Interface geklärt, ob der Durchlauf bei einem der nächsten Knoten fortgesetzt werden soll oder nicht. In Abhängigkeit von dieser Festlegung wird entschieden, ob eine Kante in die Ergebnismenge ausgegeben wird und bei welchem Knoten die Suche fortgesetzt werden soll. 20 GDV 1999

25 Das objektorientierte technische Referenzmodell Die technische Architektur der VAA Beispiel Ein Beispiel für den Base Relationship Service wurde bereits durch die dreiwertige Relation Konto-Vertrag-Person gegeben. Einsatzbeispiele zur zweiten Stufe - den Graphs of related Objects - des Relationship Services sind: Distributed Desktops: Ordner und Objekte werden über Graphen miteinander verknüpft. Ordner referenzieren Objekte und andere Objekte. Letztere könne über mehrere Maschinen verteilt sein. Compound Documents: Eine Compound Document Architektur verknüpft Texte, Tabellen, Graphiken, Videos etc. Abbildung 8: Beispiele für die Verwendung von "graphs-of-related-objects" Specific Relationships In den Relationship Service wurden zwei spezielle Relationen mit aufgenommen, die von großer allgemeiner Bedeutung sind: Die Containment - Relation Die Reference - Relation Es handelt sich in beiden Fällen um binäre Relationen (Degree = 2), das heißt, es gibt nur zwei Rollen, die miteinander in Relation stehen. Die Containment - Relation ist eine (1 : n) - Relation, das heißt, auf einer Seite der Relation können mehrere Objekte die gleiche Rolle einnehmen. Die Reference Relation ist eine (n : m) - Relation, das heißt auf beiden Seiten können mehrere Objekte die jeweiligen Rollen einnehmen. Wertung Die Nutzung des Relationship - Service ist nicht zwingend erforderlich für verteilte, objektorientierte Systeme, da Rollen und Relationen auch innerhalb des jeweiligen Fachmodells als CORBA-Objekte modelliert werden können. Die Verwendung macht nur dann Sinn, wenn rollenabhängige Beziehungen zwischen Komponenten möglichst flexibel gestaltet werden sollen. Dabei ist abzuwägen zwischen Ansprüchen an Flexibilität und Performance. II Persistence Service Definition Der Persistent Object Service (POS) dient der dauerhaften Speicherung von Objekten in verteilten Systemen. Der Persistent Object Service ermöglicht es Objekten auch dann persistent (dauerhaft) zu existieren, wenn die Applikation, die das Objekt erzeugt hat, oder der Client, der es verwendet hat, beendet wurden. Der Persistent Object Service besteht aus den folgenden Komponenten: GDV

26 Die technische Architektur der VAA Das objektorientierte technische Referenzmodell Client Persistentes Objekt Persistence Data Service Protokoll PO PDS PID POM Persistence-ID Persistence Object- Manager Datenspeicher Abbildung 9: Komponenten des Persistence Service Persistente Objekte (PO) sind Objekte, deren Zustand dauerhaft gespeichert wird. Das PO ist letztendlich für seine Dauerhaftigkeit verantwortlich. D.h. das PO legt fest, welches Datenspeicherungs- Protokoll zu verwenden ist und wieviel Sichtweite es seinem Client einräumt. Manche Objekte machen sich selbst persistent, während andere Objekte diese Funktion ihrem Client überlassen. Mittels der Persistence-ID (PID) identifiziert der Persistent Object Service das Objekt, das gespeichert wird. Ähnlich wie die Objektreferenzen kann das PID in späteren Sessionen benutzt werden. Die PID kann ausschließlich im Kontext vom POS benutzt werden. In der Realität gibt es mehrere Persistenzdienste, Speichermedien und Protokolle. Der Persistence Object Manager (POM) trifft die Entscheidung, welches ausgewählt wird. Der Persistence Data Service (PDS) implementiert die Schnittstelle zum Protokoll, und er führt die aktuelle Speicheroperation aus. Der Datenspeicher kann eine einfache Datei sein oder eine Datenbank. Da einige Datenspeicher passiv sind, benötigen sie den PDS, um die Speicherung und die wiedergewonnenen Operationen zu initialisieren. Wertung Der CORBA-Persistence Service wird aufgrund seiner oberflächlichen Spezifikation und der mangelnden Kompatibilität mit anderen Standards (z.b. der ODMG) von keinem Datenbankhersteller unterstützt. Ein Persistence Service ist für die Architektur der VAA unbedingt notwendig, CORBA s Spezifikationen sind als Basis allerdings nicht ausreichend. Generell geht der Trend hin zu Transaction Frameworks wie Enterprise JavaBeans, die Transaktionsmanagement und Persistenz in einem einheitlichen Rahmen zur Verfügung stellen. Auch die OMG geht mit CORBA 3.0 diesen Weg. 22 GDV 1999