III. Die Systemarchitektur der VAA - GDV

Gesamtverband der Deutschen
Versicherungswirtschaft e.V.
Prozesse
Objekte
Funktionen
Daten
Komponenten
Request Broker
VA A
Edition
1999
Die Anwendungsarchitektur der Versicherungswirtschaft
DAS OBJEKTORIENTIERTE
TECHNISCHE
REFERENZMODELL
VERSION 1.0
OBJEKTORIENTIERT
© GDV 1999
http://www.gdv.de/vaa
Autoren:
Das Projektteam "Objektorientiertes technisches Referenzmodell"
Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin
http://www.gdv.de/vaa
© GDV 1999
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 http://www.gdv.de/vaa) 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 1999
http://www.gdv.de/vaa
Das objektorientierte technische Referenzmodell
Dokumentenstruktur der VAA Edition 1999
Anforderungen und Prinzipien
neu
Glossar
überarbeitet
VAA prozedural (pVAA) Version 2.1
Prozeduraler Rahmen
neu
Fachliche Beschreibung
Inkasso/Kontokorrent
neu
Partner
Partner/Anhang
Provision
überarbeitet
Schaden/Leistung
Vertrag
Technische Beschreibung
Datenmanager
Datenmanager/Anhang
Dialogmanager
Parametersystem
Workflow-/Vorgangsmanager
VAA objektorientiert (oVAA) Version 1.0
Objektorientiertes fachliches Referenzmodell
Hauptdokument
neu
Anhang A – Use-Case-Modell –
neu
Anhang B – Klassenmodell –
neu
Modell in Rational-Rose-Format
neu
Objektorientiertes technisches Referenzmodell
neu
Produkt
neu
http://www.gdv.de/vaa
© GDV 1999
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 ................................................................. 11
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.1.3.1.
Life Cycle Service ....................................................................................................... 15
II.1.3.2.
Naming Service ........................................................................................................... 16
II.1.3.3.
Relationship Service ................................................................................................... 17
II.1.3.4.
Persistence Service .................................................................................................... 21
II.1.3.5.
Transaction Service .................................................................................................... 23
II.1.3.6.
Concurrency Service ................................................................................................... 26
II.1.3.7.
Trader Service............................................................................................................. 27
II.1.3.8.
Collection Service ....................................................................................................... 31
II.1.3.9.
Property Service.......................................................................................................... 33
II.1.3.10.
Query Service ............................................................................................................. 34
II.1.3.11.
Security Service .......................................................................................................... 37
II.1.3.12.
Externalization Service ................................................................................................ 38
II.1.3.13.
Event Service .............................................................................................................. 41
II.1.4.
II.2.
CORBA 3.0 und Java .......................................................................................................... 43
Distributed Internet Architecture (DNA) ....................................................................................... 45
II.2.1.
Definition und Grundbegriffe ............................................................................................... 45
II.2.2.
Komponenten ...................................................................................................................... 45
III.
II.2.2.1.
Präsentation ................................................................................................................ 46
II.2.2.2.
Anwendungsservice .................................................................................................... 47
Die Systemarchitektur der VAA ..................................................................... 48
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.2.3.1.
Entity Business Object (EBO) ..................................................................................... 51
III.2.3.2.
Process Business Object (PBO) ................................................................................. 52
III.2.4.
© GDV 1999
Dienste ................................................................................................................................ 53
i
Inhalt
Das objektorientierte technische Referenzmodell
III.2.4.1.
BO-Manager - Framework und BO-Persistence Service ............................................. 54
III.2.4.2.
Transparenter Zugriff auf Methoden eines Business Objects ...................................... 56
III.2.4.3.
Transparentes Speichern von Business Objects ......................................................... 56
III.2.4.4.
Suchen von Business Objects ..................................................................................... 58
III.2.4.5.
Erzeugen von Business Objects .................................................................................. 59
III.2.4.6.
Löschen von Business Objects ................................................................................... 59
III.2.4.7.
Transaktionsmanagement ........................................................................................... 60
III.2.4.8.
Verwalten von BO-Beziehungen ................................................................................. 61
III.2.4.9.
Parametrisierung von Business Objects ...................................................................... 62
III.2.4.10.
Benachrichtigungsdienst zwischen Business Objects ................................................. 62
III.2.5.
III.2.5.1.
Vom Business Object zur Komponente ....................................................................... 63
III.2.5.2.
Allgemeine Typen von Objekten .................................................................................. 64
III.3.
Präsentationskomponente ....................................................................................................... 65
III.4.
Verteilung von Präsentation und Business Object................................................................... 68
III.5.
Kopplung von Systemen ......................................................................................................... 70
III.5.1.
Entkoppelung und Anpassung von Funktionalität ................................................................ 71
III.5.2.
Anpassungen der System- bzw. technischen Architektur .................................................... 71
IV.
Architekturmodelle im Überblick ................................................................... 75
IV.1.
Einordnung .............................................................................................................................. 75
IV.2.
OMG Vorschläge zur Business Object Architecture ................................................................ 76
IV.2.1.
Architekturziele und Kontext ................................................................................................ 76
IV.2.2.
Grundmuster der Architektur ............................................................................................... 77
IV.2.2.1.
Definitionen ................................................................................................................. 77
IV.2.2.2.
Services....................................................................................................................... 80
IV.2.2.3.
BO- und Type-Manager Interfaces .............................................................................. 81
IV.2.2.4.
Shared Services .......................................................................................................... 88
IV.2.3.
IV.3.
Wertung ............................................................................................................................... 91
IBM San Francisco .................................................................................................................. 91
IV.3.1.
Architekturziele und Kontext ................................................................................................ 91
IV.3.2.
Grundmuster der Architektur ............................................................................................... 92
IV.3.2.1.
Foundation Layer ........................................................................................................ 93
IV.3.2.2.
Common Business Objects Layer (CBOs) .................................................................. 95
IV.3.2.3.
Core Business Processes Layer ................................................................................. 95
IV.3.3.
IV.4.
ii
Business Objects und Komponenten .................................................................................. 63
Wertung ............................................................................................................................... 97
Enterprise JavaBeans ............................................................................................................. 97
IV.4.1.
Architekturziele und Kontext ................................................................................................ 97
IV.4.2.
Grundmuster der Architektur ............................................................................................... 98
IV.4.2.1.
Komponente ................................................................................................................ 98
IV.4.2.2.
Container ..................................................................................................................... 98
IV.4.2.3.
Das Komponentenmodell ............................................................................................ 98
IV.4.2.4.
Granularität der Komponenten .................................................................................... 98
© GDV 1999
Das objektorientierte technische Referenzmodell
IV.4.2.5.
Standardisierte Schnittstellen ...................................................................................... 98
IV.4.2.6.
Anpassung ohne Änderung im Source Code .............................................................. 98
IV.4.3.
Enterprise JavaBeans Komponentenmodell ....................................................................... 99
IV.4.3.1.
Implizite Services ........................................................................................................ 99
IV.4.3.2.
Portabilitätsschicht ...................................................................................................... 99
IV.4.3.3.
Ausführung der Services ........................................................................................... 100
IV.4.4.
Detaillierte Beschreibung der EJB Architektur .................................................................. 100
IV.4.4.1.
Transiente und persistente Objekte .......................................................................... 101
IV.4.4.2.
Naming und Registry ................................................................................................. 101
IV.4.4.3.
EJB Objektschnittstelle ............................................................................................. 102
IV.4.4.4.
Deklarierte Attribute .................................................................................................. 102
IV.4.4.5.
Kontext Objekt und Environment Objekt ................................................................... 102
IV.4.5.
Inhalt
Beschreibung der Services ............................................................................................... 102
IV.4.5.1.
Distribution Services ................................................................................................. 102
IV.4.5.2.
State Management .................................................................................................... 103
IV.4.5.3.
Persistence Management ......................................................................................... 103
IV.4.5.4.
Transaction Management ......................................................................................... 104
IV.4.5.5.
Security ..................................................................................................................... 105
IV.4.6.
Enterprise JavaBean Deployment ..................................................................................... 105
IV.4.7.
Wertung ............................................................................................................................ 106
V. Ausblick ............................................................................................................ 107
VI.
Glossar........................................................................................................... 109
VII.
Literatur ......................................................................................................... 114
© GDV 1999
iii
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
Das objektorientierte technische Referenzmodell
Abbildung 48: Kern-Geschäftsprozesse in San Francisco
Abbildung 49 : Enterprise JavaBeans Container
Abbildung 50: Konvergenz der Komponenten-Architekturen
Inhalt
96
100
107
Verzeichnis der Tabellen
Tabelle 1: Operationen des CORBA Naming Service
Tabelle 2: Eigenschaften von Diensten beim CORBA-Trader Service
Tabelle 3: Functional Interfaces des CORBA Trader Service
Tabelle 4: Administration Interfaces des CORBA Trader Service
Tabelle 5: Merkmale von CORBA Collections
Tabelle 6: Interfaces des CORBA Property Service
Tabelle 7 : Kompatibilität der Dienste des BO-Frameworks und der CORBA Services
Tabelle 8: Identity eines Business Objects (Interoperability Specification)
Tabelle 9: Life Cycle Operationen der Interoperability Specification
Tabelle 10: State Access Operationen der Interoperability Specification
Tabelle 11: Intrinsic events (Interoperability Specification)
Tabelle 12: Bedingungen für das Auslösen von Events (Interoperability Specification)
Tabelle 13: Bedingungen für die Übermittlung von Events (Interoperability Specification)
Tabelle 14: Interfaces des Query Service der Interoperability Specification
Tabelle 15: Introspection Interface (Interoperability Specification)
Tabelle 16: Exception Categories (Interoperability Specification)
Tabelle 17: Eigenschaften des Transaction Service (Interoperability Specification)
© GDV 1999
17
28
29
30
32
34
56
82
84
84
85
86
86
87
88
88
89
v
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
Die Anwendungsarchitektur der Versicherungswirtschaft
Grundlagen und Prinzipien
beschrieben.
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
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 1999
7
Einführung und Überblick
Das objektorientierte technische Referenzmodell
Technisches Referenzmodell
Dienste
Business Objects und Komponenten
• BO-Transaktionen
• BO-Persistenz
• BO-Beziehungen
• Parametrisierung
• Events
• ...
• Suchen
• Erzeugen
• Löschen
Technische Dienste
• CORBA Services
• Präsentation
• Datenbanken
SystemArchitektur
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
8
© GDV 1999
Das objektorientierte technische Referenzmodell
Einführung und Überblick
Objekte 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
Systemarchitektur und technischer Architektur:
zwischen
fachlichen
Komponenten,
Fachliches Referenzmodell
V ersionierbar
(from LibraryP ackage)
IcisB asis
(from LibraryP ackage)
A ctor-Role
-P attern
V ersionierbarerA kteur
Fachliche
Komponentenmodelle
Rolle
0..*
S tandard
0..1
P erson
S tandard
0..1
*
Rufnummer
S tandard
0..1
JurP erson
anzuwendendeA nschrift
A nschrift
0..1
*
anzuwendende
*
B ankverbindung
B ankverbindung
0..1
P artner
NatP erson
V ertragsabhaengigerP artner
V ermittler
Dienste
P roduktpartner
V ersicherte P erson
Technisches Referenzmodell
ObjektP artner
S onstigeP artnerrolle
partn
erart
V ersicherungsnehmer
P ostempfaenger
B eitragszahler
Leistungsempfaenger
Business Objects und Komponenten
• BO-Transaktionen
• BO-Persistenz
• BO-Beziehungen
• Suchen
• Erzeugen
• Löschen
Technische Dienste
• Parametrisierung
• Events
• ...
• CORBA Services
• Präsentation
• Datenbanken
SystemArchitektur
Technische
Architektur
Object Request Broker
Abbildung 3: Zusammenhang der Modelle und Architekturen
© GDV 1999
9
Einführung und Überblick
Das objektorientierte technische Referenzmodell
Basisdienste wie Betriebssysteme, Netzwerkprotokolle bzw. -Infrastruktur und HardwareEigenschaften 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
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 VAAReferenzmodells ist vor allem das Zusammenspiel zwischen Fachlogik, Steuerung und Präsentation
© GDV 1999
11
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 CORBAServices spezifizieren Verhalten und Schnittstellen verteilter Objektsysteme hinsichtlich
Transaktionsmanagement, Objekterzeugung, Persistenz u.ä.
12
© GDV 1999
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 1999
13
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 ClientObjekt 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
Server
static invocation
1. Objekt erzeugen mit
Angabe der Referenz
2. Aufruf method()
Implementierung der
Klasse von "aObj"
Stub von "aObj"
method()
Client ORB
Skeleton
Server-ORB
Anwendungsobjekt
dynamic invocation (DII)
Anwendungsobjekt
1. aObj, Parameter,
method() dem reqObjekt mitteilen;
2. Aufruf req.invoke()
Request - Objekt
invoke()
Client 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
14
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Vereinbarung, 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.1.3.1. 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
© GDV 1999
15
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
des 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.1.3.2. 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
Eine Namen-Objekt Zuordnung wird für einen bestimmten
Kontext erzeugt.
Name resolution
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
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Unbinding
Die Zuordnung Objekt – Name wird für einen bestimmten
Kontext aufgehoben.
Creating naming contexts
Anlegen neuer Namenskontexte
Deleting contexts
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.1.3.3. Relationship Service
Definition
© GDV 1999
17
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 IDLSchnittstellen 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
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 1999
19
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Rolle: Konto von
Rolle: Kontoinh.
Person
Konto
Relation Girokonto
Rolle: Beitragszahler
Vertrag
Relation Beitragsverhältnis
Rolle: Beitragspflichtiger Vertrag
Rolle: Beitragskonto für Vertrag
Relation Girokonto
VU
Konto
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
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.1.3.4. 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 1999
21
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Client
Persistentes
Objekt
PO
Protokoll
Persistence
Data Service
PID
POM
Persistence-ID
Persistence
ObjectManager
PDS
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
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
II.1.3.5. Transaction Service
Definition
Der Object Transaction Service (OTS) von CORBA unterstützt das allgemeine
Transaktionskonzept, d.h. ein Arbeitsschritt ist dann eine Transaktion, wenn die folgenden
grundlegenden ACID-Charakteristika erfüllt sind:
1. Eine Transaktion ist atomar (atomic), wenn bei einer Unterbrechung aufgrund eines Fehlers
sämtliche Auswirkungen bis zu diesem Zeitpunkt zurückgesetzt (rolled back) werden.
2. Eine Transaktion liefert konsistente (consistent) Ergebnisse.
3. Eine Transaktion ist isoliert (isolated). Ihre Zwischenstände sind für andere Transaktionen
nicht sichtbar. Sie laufen vordergründig seriell ab, obwohl sie konkurrierend zu anderen
Transaktionen stehen.
4. Eine Transaktion ist dauerhaft (durable), wenn die Folgen einer abgeschlossenen Transaktion
persistent sind.
Eine Transaktion kann auf zweifache Weise enden: sie wird entweder commited oder rolled back.
Commited heißt, daß sämtliche Änderungen permanent werden, anderenfalls werden die
Veränderungen auf ihren ursprünglichen Ausgangsstand zurückgesetzt (rolled back).
Jede Transaktion besteht aus dem Start, einer Zahl von Transaction-Events (z.B. DB Updates) und
einem definierten Ende.
Der CORBA Transaction Service beschreibt Interfaces, die verteilten Objekten erlauben atomar zu
sein. Die Interfaces gestatten es den Objekten, gemeinsam Transaktionen per commit oder rollback
abzuschließen. Insbesondere bietet der Transaction Service:

Transaktionen an, die unterschiedliche verteilte ACID-Objekte einschließen.

die Option, Objekte und Ressourcen aus der Nicht-Objektwelt zu integrieren.
Die Sychronisation der an einer Transaktion beteiligten Objekte und dem Transaction Service erfolgt
mit Hilfe eines Transaction Context, der von den beteiligten Objekten gemeinsam genutzt wird. Der
Transaction Context wird bei jedem Methodenaufruf tranparent für den Client vom ORB als
Parameter übergeben.
Die vom Transaction Service unterstützten Anwendungen bestehen aus folgenden Komponenten:

Der Transactional Client (TC) in Form eines Programms kann Operationen auf
verschiedenen Transactional Objects in einer einzigen Transaktion durchführen und ist
verantwortlich für das Auslösen und Beenden einer Transaktion.

Ein Objekt, dessen internes Verhalten von der Teilnahme an einer Transaktion beeinflußt
wird, muß das Interface TransactionalObject implementieren. TransactionalObject ist ein
abstraktes Interface, das selbst keine Operationen definiert. Es dient lediglich dem ORB als
Kennzeichen, daß das betroffene Objekt an einer Transaktion teilnehmen soll.

Ein Recoverable Object ist ein Objekt, das an einer Transaktion beteiligt ist und dessen
Zustand in einer Resource (eine Datei oder eine Datenbank) gespeichert wird. Ein
Recoverable Object muß deshalb sowohl das TransactionalObject- als auch das
Resource-Interface implementieren. Ein Recoverable Object beteiligt sich am Transaction
© GDV 1999
23
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Service Protokoll, in dem sich beim Service registrieren läßt. Der Service aktiviert das
Commit Protokoll durch Requests an die registrierte Resource.

Ein Transactional Server besteht aus Objekten, deren Verhalten von der Transaktion
beeinflußt wird, die aber selbst keinen transaktionsrelevanten Zustand besitzen. Der Server
ist nicht an der Vollendung einer Transaktion beteiligt, kann aber aufgrund fachlicher
Zusammenhänge einen Rollback erzwingen.

Der Recoverable Server verwaltet ein oder mehrere Recoverable Objects und ihre
Resources.

Der Transaction Service selbst besteht vor allem aus den Interfaces Current und
Coordinator. Current stellt im wesentlichen das Interface für den Transactional Client
zum Transaction Service dar, der Coordinator verwaltet das Zusammenspiel zwischen den
Transactional Objects.
Abbildung 10: Komponenten des Transaction Service
Der Transaction Service unterstützt zwei verteilte Transaktionsmodelle:
1. Flache (Flat) Transaktionen. Das flache Transaktionsmodell ist abgeleitet von den
Definitionen des X/Open DTP (Distributed Transaction Processing) Transaktionsmodells. Es
besteht aus einer Haupttransaktion, die keine Child-Transaktion haben darf.
2. Geschachtelte (Nested) Transaktionen. Geschachtelte Transaktionen erlauben eine feinere
Granularität beim Rollback mit dem Ziel, daß nicht effiziente Teile der Transaktion
unberücksichtigt bleiben können. In einer Geschachtelte Transaktionen (Parent) kann die
Anwendung eine eingebettete, eigene Transaktion (Child) aufrufen. Mehrere Transaktionen
lassen
sich
somit
vertikal
und
horizontal
zusammenfassen.
Eine Transaktion kann nur dann commited werden, wenn ihre Child-Transaktionen selbst
commited wurden. Eine Vorteil liegt in der Fehlerkorrektur von Parent-Transaktionen im Falle
eines Rollbacks einer Child-Transaktion.
Ein Two-Phase Commit setzt immer dann sämtliche Veränderungen zurück, wenn eine einzige
Ressource einen Fehler dokumentiert bekommen hat.
24
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Beispiel
Das folgende Sequenzdiagramm stellt einen transaktionsgesicherten Überweisungsvorgang zwischen Konten von
Bank 1 und Bank 2 dar.
Transactional
Client
Resource
Resource
(recoverable object)
(recoverable object)
Current
Coordinator
begin
abheben
get_control
register_resource
einzahlen
get_control
register_resource
commit
prepare
prepare
commit
commit
Revocerable
Server Bank 1
Revocerable
Server Bank 2
Transaction Service
Erläuterungen:



Der Client startet die Transaktion durch Aufruf der begin-Methode des Current-Interfaces
Durch Aufruf der abheben-Methode des Kontos in Bank 1 wird automatisch die zugeordnete Resource mit
register_resource beim Transaction Service (Interface Coordinator) registriert, da das Konto ein recoverable
object ist. Durch den Aufruf von get_control erhält ein recoverable object eine Referenz zum zugeordneten
Coordinator.
Nach Beenden der Transaktion durch Aufruf der commit-Methode des Current-Interfaces durch den Client führt
der Transaction Service ein Two-Phase-Commit auf beiden Resourcen durch (Aufruf von prepare und commit
für jede registrierte Resource)
Abbildung 11: Beispiel CORBA Transaction Service
Wertung
Der CORBA Transaction Service ist essentiell für die Gestaltung verteilter, objektorientierter
Systeme.
Allerdings sind die Spezifikationen von OTS für verteilte Objektsysteme mit hohen Transaktionsraten
nicht ausreichend. Für große OLTP-Systeme ist nicht nur die Verwaltung der Daten-Resourcen und
ihre Transaktionssicherung wichtig, sondern vor allem das Management der Resourcen der beteiligten
Anwendungsserver und die Anbindung an traditionelle TP-Monitore wie CICS. Dies geht weit über
die in OTS definierten Standards hinaus. In der Literatur hat sich hierfür der Begriff Object
© GDV 1999
25
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Transaction Monitor (OTM) eingebürgert. Da bisher keine Spezifikationen der OMG für OTMs
vorliegen, wurden von verschiedenen ORB und TP-Monitor-Herstellern CORBA-Erweiterungen in
Richtung OTM vorgenommen. Beispiele hierfür sind der Component Broker von IBM oder BEAs
Iceberg. Diese Erweiterungen sind allerdings nicht kompatibel. Derzeit sind bei der OMG und
wichtigen Herstellern Aktivitäten im Gange, die einen CORBA-OTM auf Basis von EnterpriseJavaBeans spezifizieren sollen. Mit entsprechenden Submissions ist noch im Jahre 1999 zu rechnen.
Durch die Unterstützung aller namhafter ORB-Hersteller und deren Zusammengehen mit Herstellern
von Transaktionsmonitoren wird OTS und OTM daher die für große Anwendungen notwendige Reife
in den nächsten Jahren erreichen.
Insgesamt bleibt unter dem Gesichtspunkt einer zeitlich lang andauernden und auch über eine Vielzahl
von Clients und Servern verteilten Transaktion die Performance-Frage zu verifizieren. Der eher
konservative CORBA-Ansatz kann durch verschiedene Redesigns (in der Versionierung) inzwischen
gute Performance-Werte liefern.
II.1.3.6. Concurrency Service
Definition
Der Concurrency Control Service versetzt verschiedene Clients in die Lage eine gemeinsam zu
nutzende Resource zu verwalten. Bei im Konfikt stehenden Zugriffen auf eine Resource hat der
Service die Aufgabe, die Resource in einem konsistenten Zustand zu belassen.
Eine direkt konkurrierende Nutzung wird über Locks geregelt. Dabei steht jeder einzelne Lock in
Verbindung mit einem Client und einer Resource.
Der Service verfügt über verschiedene Interfaces; der Anwender hat die Wahl zwischen:

Transactual Mode: der Transaction Service (s.o.) regelt die Locks gemäß dem Ausgang
der Einzeltransaktionen (Commit oder Rollback).

Non-Transactual Mode: die Verantwortung liegt nicht im Transaction Service sondern
allein im Concurrency Control Service.
Der Concurrency Control Service definiert die folgenden Locking Modes:
Abbildung 12: Locking Modes des Concurrency Services
26
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Die Tabelle stellt die Kompatibilität zwischen unterschiedlichen Locking Modes dar, wobei ein *
einen Konflikt darstellt. Wenn beispielsweise ein Client ein Lock auf eine Ressource absetzen will, die
von einem anderen Client im gleichen Mode gehalten wird, so liegt ein Konflikt vor. Der anfordernde
Client muß warten, bis der erste Client die Ressource wieder freigibt.
Wertung
Der Concurrency Service ist im Zusammenhang mit dem Transaction Service unbedingt notwendig.
Durch das in CORBA vorgesehene Zusammenspiel zwischen diesen Diensten bleibt die Verwaltung
von Zugriffskonflikten transparent für den Client.
II.1.3.7. Trader Service
Definition
Der Trader-Service hat die Aufgabe, Objekte anhand ihrer verfügbaren Dienste und Dienstearten zu
finden.
Ein Trader ist ein besonderes Objekt, das für andere Objekte „passende“ Dienste bereitstellt bzw.
vermittelt. Der Trader Service fungiert dabei als „Vermittler“.
Der Trader arbeitet mit zwei Arten von Objekten, den Diensteanbietern bzw. Exporteuren und
Dienstenutzern bzw. Importeuren. Dienstanbieter bieten dem Trader ihre Dienste einschließlich
deren Beschreibung an. Dienstenutzer erfragen und erhalten gewünschte Dienste durch den Trader.
Hauptaufgabe eines Traders ist, Dienstleistungen zu vermitteln, die als Serverobjekte auf einem
beliebigen Knoten in einem verteilten Rechnernetz liegen und von Clientobjekten transparent
angefordert werden können. Transparent bedeutet, die Clients melden die gewünschten Dienste beim
Trader an, alles weitere obliegt dem Trader. Dieser ermittelt den passenden Diensteanbieter bzw. das
entsprechende Serverobjekt einschließlich seiner angebotenen Methoden. Diese Zuordnung geschieht
dynamisch.
Clients können beim Trader auch nach einer bestimmten Art von Dienst fragen, der am besten zum
Kontext des angefragten Dienstes und zum Angebot des Providers paßt.
Ein Serverobjekt meldet seine Methoden beim Trader an und übergibt ihm die folgenden
Informationen:
Objektreferenz
Name und Art des Dienstes
Informationen über Methoden, die der Dienst implementiert
einschließlich der Parameter und Ereignistypen. Zusätzlich
stehen Informationen über unterschiedliche Eigenschaften im
Trading-Kontext zur Verfügung.
Eigenschaften des Dienstes
Enthält individuelle Werte bezogen auf die Eigenschaften
eines offerierten Dienstes, den ein Exporteur (Serverobjekt)
bereitstellt. Eigenschaften (properties) können obligatorisch
oder optional sein. Der Exporteur muß obligatorische
Eigenschaften mit Werten vorbelegen.
© GDV 1999
27
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Tabelle 2: Eigenschaften von Diensten beim CORBA-Trader Service
1.
2.
Trader
3.
1
Server
2
3
Der Server bietet dem Trader
einen Dienst an (Export)
Der Client fragt den Trader nach
einem geeigneten Dienst (Import)
Der Trader vermittelt und der
Client bedient sich direkt des
ermittelten Dienstes
Client
Abbildung 13: Kommunikation zwischen Trader, Server und Client im Trader Service
Durch die Zuordnung individueller Eigenschaften können unterschiedliche Ausprägungen eines
Dienstes formuliert werden, die als Dienstetypen bezeichnet werden.
Der Trader verwaltet in einem Verzeichnis, dem Service Type Repository, die verschiedenen
Dienstetypen der Dienste. Im Service Type Repository sind jeweils die Schnittstelle des Dienstes
sowie eine Anzahl von Eigenschaften, die diesen Dienst beschreiben, enthalten.
Es besteht auch die Möglichkeit, einem Dienst weitere Eigenschaften dynamisch zuzuordnen. Dies
geschieht zu dessen Laufzeit, wenn der Dienst von einem Client aktiviert wird. Diese Form der
dynamischen Zuordnung obliegt dem Evaluator, einer Unterfunktion des Traders. Diensteobjekte, die
Instanzen der im Service Type Repository gespeicherten Dienstearten sind, werden vom Trader in
einer speziellen Datenbank verwaltet.
Die Suche nach einem gewünschten Dienst in einem Trader oder in einem Trader - Verbund, in dem
die Dienste gemeinsam in einem Pool koordiniert zur Verfügung gestellt werden, kann
recht
aufwendig und resourcenintensiv werden. Deshalb bestehen Möglichkeiten, eingeschränktes Suchen
mittels Berechtigungen, Restriktionen oder Preferenzen vorzunehmen.
Mit Policies kann vorgegeben werden wie die Suche durchzuführen ist sowie die Zahl der zu
prüfenden Dienste. Mittels Constraints lassen sich Suchkriterien auf der Basis einer Constraint
Language definieren. So kann z.B. SQL als Constraint Language gewählt werden. Preferences legen
fest, in welcher Reihenfolge passende Angebote zurückgegeben werden sollen.
Policies, Constraints oder Preferences sind Parameter des Suchvorganges, der durch den Aufruf der
Lookup-Schnittstelle angestoßen wird.
Der Trader Service ist durch zwei Gruppen von Interfaces beschrieben:

Functional Interfaces

Administration Interfaces
28
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Functional Interfaces sind:
Lookup-Interface
Die Lookup-Schnittstelle verfügt nur über die Methode QUERY,
mit der Clients Dienste anfordern und importieren können. Die
Suche
kann
durch
Vorgabe von Restriktions-Parametern
eingeschränkt werden.
OfferIterator-Interface Über die Lookup-Schnittstelle wird eine Menge von gewünschten
Diensten geliefert. Mit den Methoden max_left, next_n oder
destroy kann in der gelieferten Menge navigiert werden bzw. diese
gelöscht werden.
Register-Interface
Mit der Methode export offeriert ein Exporteur seine Dienste dem
Trader, der vergibt dann eine eindeutige Referenz (OfferId). Mit
withdraw kann ein bereits angebotener Dienst zurückgenommen
werden. Mit der Methode modify kann ein angebotener Dienst
geändert werden und mit describe wird eine Beschreibung eines
offerierten Dienstes vom Trader geliefert.
Link-Interface
Diese Schnittstelle ermöglicht einem Trader, die Dienste eines
anderen Traders zu verwenden (Trader-Pool). In diesem Pool kann
dann mit der Methode query nach gewünschten Diensten nachgefragt
werden, um diese zu importieren.
Proxy-Interface
Mit diesen speziellen Methoden wird einem Trader ermöglicht,
Objektreferenzen zur Angebotszeit zu ermitteln, die einen Dienst
bereitstellen können, aber es de facto noch nicht getan haben. Aus
diesem Grunde kann der Trader auch noch nicht über die
Objektreferenz des Dienstes verfügen, sondern erhält diese über ein
Proxy-Objekt, welches intern mittels query-Methode auf ein LookupObjekt die Offer-Id ermittelt.
Proxies sind nützlich, um angebotene Dienste z.B. unter
Berücksichtigung einer performanten Verteilung dynamisch
berücksichtigen zu können.
DynamicPropEval
Dynamische Eigenschaften ermöglichen frühzeitige Informationen
über potentielle Dienste, gehen aber dafür eindeutig zu Lasten der
Performance.
Der Trader verwendet die Methode evalDP, um den Wert einer
dynam. Eigenschaft eines Dienstes zur Angebotszeit aufzulösen, ehe
dieser importiert wird.
Tabelle 3: Functional Interfaces des CORBA Trader Service
Die Administrations-Schnittstelle des Traders und die dort definierten Methoden dienen der
Verwaltung des Service Type Repository, in welchem die inviduellen Ausprägungen der angebotenen
Dienste, die Dienstetypen, enthalten sind.
© GDV 1999
29
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Administration Interfaces sind:
ServiceTypeRepository-Interface Die Methoden für das Dienstearten-Verzeichnis
(ServiceTypeRepository)
können
dessen
Inhalt
manipulieren. Es können Dienstearten hinzugefügt,
entfernt oder aufgelistet werden, mit oder ohne
Beschreibung. Ebenso können vorhandene Dienstetypen
durch Maskieren nicht mehr zur Verfügung stehen.
Maskierte Services können wieder aktiv gesetzt werden.
Die zahlreichen Aufrufe (Methoden) an die
Administrations-Schnittstelle Admin erlauben es dem
Administrator, das System zu konfigurieren und
verschiedene Parameter zu setzen, um z.B. die Suche
nach gewünschten Diensten einzuschränken bzw.
ressourcen-intensives Recherchieren zu begrenzen.
Admin-Interface
Tabelle 4: Administration Interfaces des CORBA Trader Service
Beispiel
1. Der Besitzer eines italienischen Restaurants wendet sich an den Verlag der Gelben Seiten, um sich mit
seinem Restaurant (Service Type) aufnehmen zu lassen.
2. Die individuellen Besonderheiten seines Restaurants übermittelt er an den Verlag.
3. Ein Interessent durchsucht die Gelben Seiten, um in einem Restaurant mit italienischen Spezialitäten essen
zu gehen.
4. Der Interessent findet die Rubrik „italienische Restaurants“ .
5. Er wählt ein Restaurant in seiner Nähe, das auch in der Mittagszeit geöffnet hat.Er greift zum Telefon und
bestellt einen Tisch.
Client - Objekt
Lookup
Register
ServiceTypeRepository
Server - Objekt
Kunde
Auswahl
Verlag
Gelbe
Seiten
Restaurant
1. add_type
2. export
3. list_types
4. describe_type
5. query
6. Aufruf der Methoden
Abbildung 14: Beispiel Trader Service
30
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Wertung
Insbesondere für konfigurierbare, komponentenorientierte Anwendungssysteme ist der Trader-Service
ein geeignetes Werkzeug für die dynamische Koppelung von Diensten und Komponenten. Allerdings
wird seine zukünftige Relevanz durch die Entwicklungen der Java-Komponentenmodelle und deren
Konvergenz mit CORBA in Frage gestellt.
II.1.3.8. Collection Service
Definition
Objekte können aufgrund bestimmter Gruppen-Charakteristiken zu Objektgruppen, den Collections,
zusammengefaßt werden. Beispiele für Collections sind Warteschlangen, Stapel, Listen, Felder,
Bäume und Mengen.
Methoden des Collection Services beziehen sich auf eine Gruppe, nicht auf den Inhalt einzelner
Objekte innerhalb der Gruppe. Aufrufe des Collection Services erlauben nur, Collections zu erzeugen
bzw. Elemente zu einer existierenden Collection hinzuzufügen oder daraus zu löschen. Das
Manipulieren einzelner Elemente in der Gruppe ist nicht möglich, weil der Collection Service keine
Interfaces, um auf einzelnen Objekten innerhalb der Collection operieren zu können.
Eine Untermenge des Collection Service wird vom Query-Service verwendet, der als Ergebnis einer
Abfrage eine Collection von Objekten zurückgibt, die den in der Abfrage definierten Suchkriterien
entsprechen.
Als Collectiontyp wird eine Objektgruppe definiert, die ein typisches Gruppenmerkmal besitzt,
welches sein Verhalten prägt. Dieses Merkmal ist nicht vom Datentyp der Elemente in der Collection
abhängig. Ein typisches Gruppierungsmerkmal ist z.B., daß auf die Elemente eines bestimmten
Collectiontyps nur mittels Schlüssel zugegriffen werden kann und nicht direkt über die Position in der
Collection.
In CORBA können Collections mit folgenden Basis-Gruppenmerkmalen definiert werden:
Reihenfolge der Elemente
Die Reihenfolge der Elemente innerhalb einer
Collection kann geordnet oder ungeordnet
sein. Ist die Reihenfolge der Elemente
geordnet, so können diese in sequentieller oder
sortierter Reihenfolge vorliegen.
Zugriff über Schlüssel
Der Zugriff auf die Elemente einer Collection
kann wahlweise mit Schlüssel oder ohne
Schlüssel erfolgen. Eine Collection, die über
einen Schlüssel definiert wird, ermöglicht
einen direkten Zugriff auf ihre Elemente.
Elementgleichheit
Ermöglicht es, die Elemente einer Collection
auf ihre Gleichheit zu testen
Eindeutigkeit der Einträge
Bestimmt, ob ein beliebiges Element innerhalb
© GDV 1999
31
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
einer Collection nur genau einmal (unique)
oder auch mehrfach (multiple) vorkommen
darf.
Tabelle 5: Merkmale von CORBA Collections
Diese Eigenschaften bzw. Basis-Gruppenmerkmale können kombiniert werden, um eine ganze Reihe
von unterschiedlichen Collection-Typen zu definieren. Für jeden Collection-Typ existiert ein
entsprechendes Interface.. Die folgende Matrix zeigt die Kombinationsmöglichkeiten die sich für
Typen von Collections ergeben:
Ordered
Sorted
Sequential
Multiple Unique Multiple Multiple
Unordered
Unique
Element
Map
Relation
Sorted
Map
Sorted
Relation
Key
No Element
KeysSet KeyBag KeysSet KeyBag
Quality
No
Key
Element
Quality
No Element
Quality
Set
Bag
Set
Bag
Heap
Equality
Sequence
Sequence
Abbildung 15: Typen von Collections im Collection Service
Da Collections Basisklassen für einen breiten Bereich von Applikationen sind, müssen sie Elemente
beinhalten können, die durchaus unterschiedlichen Datentyps sind. Das ist deshalb möglich, weil
Operationen des Collection Services nicht auf den Inhalt der Objekte zugreifen, d.h. die Daten bleiben
verborgen.
Collections verfügen über eine einheitliche Schnittstelle, deren Operationen add, replace, retrieve,
remove und insert sich auf Elemente der Collection beziehen, aber nicht den Inhalt (Daten, etc.) eines
einzelnen Objektes manipulieren können.
Collections verfügen über Zähler, die sogenannten Iteratoren, die es ermöglichen, durch die
Collection zu navigieren und auf Elemente darin zuzugreifen. Zusätzlich können Zähler dazu benutzt
werden, gezielt Elemente zu lesen, zu ersetzen, zu löschen oder hinzuzufügen.
Der Collection Service hat zusätzlich eine CollectionFactory, die die Instanziierung von Collection
ermöglicht.
Wertung
Im allgemeinen stehen in jeder objektorientierten Programmiersprache Bibliotheken mit den oben
aufgeführten Collection-Typen zur Verfügung (zum Beispiel die Standard Template Library oder die
Microsoft Foundation Classes für C++ und teilweise auch in JDK). Der Collection Service von
CORBA ist ein Versuch, die Vielzahl teilweise unterschiedlicher Typen von Collections zu
vereinheitlichen und die Verwendung von sprach- und systemunabhängigen, verteilbaren Collections
zu ermöglichen.
32
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Sinnvoll sind sprach- und systemunabhängige Collections in Zusammenhang mit dem Query Service
(s.u.) und in komponentenorientierten Anwendungssystemen, in denen strukturierte Mengen zwischen
unabhängig implementierten Komponenten ausgetauscht werden müssen.
Dennoch ist der Collection Service für die Gestaltung verteilter Anwendungssysteme nicht unbedingt
notwendig, wenn nicht gleichzeitig der Query Service eingesetzt wird. In den meisten Fällen genügt
für den Austausch von Daten der in CORBA definierte Datentyp Sequence.
II.1.3.9. Property Service
Definition
Einem CORBA-Objekt können Eigenschaften in Form von Attributen zugeordnet werden. Ein
Attribut im CORBA-Sinn ist eine Variable, die normalerweise im Interface eines CORBA-Objekts
definiert ist und anschließend kompiliert wird. Die Variable besteht aus dem Namen (Typ string),
einem Wert (Typ any) und wahlweise einem Modus. Sie ist mit einem Objekt assoziiert. Die
Zuordnung von Eigenschaften zu einem Objekt zur Compilierungszeit wird als statische Zuweisung
bezeichnet.
Zum Zeitpunkt der Compilierung werden die Werte zugeordneter Properties einer Typprüfung
unterzogen, um Unstimmigkeiten rechtzeitig erkennen zu können.
Manchmal ist es aber notwendig, eine Eigenschaft einem Objekt zuzuordnen, dessen IDL-Definitionen
bereits compiliert vorliegen. Genau hier greift der Property Service. Er macht es möglich, dynamisch
Attribute zur Laufzeit, ohne Hilfe von IDL zu definieren um sie dann bestehenden Objekten
zuzuordnen. Diese Zuordnung wird als dynamische Zuweisung von Eigenschaften bezeichnet.
Sobald diese Eigenschaften definiert sind, können sie instanziiert, manipuliert und gelöscht werden,
was bei statischer Zuordnung nicht möglich ist.
Dynamische Zuweisung von Eigenschaften zu Objekten bedeutet aber auch, daß die Eigenschaftswerte
keiner Typenprüfung durch den IDL-Precomiler unterzogen werden. Die Zuordnung außerhalb des
IDL-Typensystems ist möglich, weil Eigenschaften unabhängig von Objekten verwaltet werden
können.
Die zwei Hauptschnittstellen des Property Services sind das PropertySet-Interface und das
PropertySetDef-Interface.
PropertySet-Interface
stellt Methoden bereit, mit denen Eigenschaften definiert,
gelöscht, gezählt und auf Existenz geprüft werden können.
PropertySetDef-Interface
stellt Methoden bereit, mit denen Eigenschaftsmodi kontrolliert
bzw. verändert werden können. Es bestehen fünf sich
gegenseitig ausschließende Property-Modi:
Normal: es bestehen keine Manipulations-Einschränkungen.
Neue Werte zu bestehenden Eigenschaften können definiert oder
Eigenschaft löschen werden.
Readonly: Property-Informationen können nur gelesen oder
gelöscht werden.
© GDV 1999
33
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Fixed_Normal: Eigenschaften können nicht gelöscht werden,
aber neue Werte zu bestehenden Eigenschaften dürfen definiert
werden.
Fixed_Readonly: Eigenschaften können nicht gelöscht werden,
lesender Zugriff erlaubt.
Undefined: gilt nicht für eine einzelne Eigenschaft, nur für
Gruppen erlaubt.
Tabelle 6: Interfaces des CORBA Property Service
Beispiel
In den OMG-Unterlagen wird anhand eines Objektes mit dem Namen „Dokument“ die Bedeutung von attributähnlichen Eigenschaften demonstriert:
Ein Dokument kann z.B. wichtig oder unwichtig sein. Über den Property-Service ist es möglich, diese Eigenschaft
wichtig oder unwichtig einem existierenden Objekt namens „Dokument“ zur Laufzeit für Archivierungszwecke
zuzuordnen, um das Objekt, falls es den Wert wichtig beinhaltet, zu archivieren. Die Archivinformation wird dem
Objekt nur assoziiert, wird also nicht Bestandteil der Typen des Objekts selbst.
Abbildung 16: Beispiel für den Property Service
Wertung
Der CORBA Property Service bietet ein Grundgerüst für die Verwaltung von Eigenschaften
beliebiger, verteilter Objekte. Besonders die Möglichkeit, Eigenschaften zu bestehenden Objekten
zuzuordnen, ohne deren Implementierung zu ändern, macht den Einsatz dieses Services für
komponentenorientierte Systeme interessant. Dem CORBA Property Service fehlen allerdings die in
JavaBeans enthaltenen Möglichkeiten, Properties direkt mit Ereignissen (Events) zu verbinden, die bei
einer Wertänderung ausgelöst werden. Außerdem fehlen Spezifikationen, um Properties über
Eigenschafts-Editoren zur Konfigurationszeit anzupassen. In der kommenden CORBA Beans Spezifikation sollen allerdings CORBA-Beans als direkt als JavaBeans einsetzbar sein, so daß deren
Möglichkeiten auch für CORBA-Objekte zur Verfügung stehen.
Generell erscheint das Property-Modell von JavaBeans vor allem unter dem Gesichtspunkt der
Komponentenorientierung heute ausgereifter und vollständiger als die CORBA-Spezifikation.
II.1.3.10. Query Service
Definition
Der Query Service hat die Aufgabe, die Objekte zu finden, deren Attribute den vorgegebenen
Suchbedingungen genügen. Dabei ist es für den Nutzer des Services transparent, ob die Objekte in
einer OODB, einer RDB, einem File oder in einer anwendungsinternen Collection gespeichert sind.
Neben dem rein lesenden Zugriff auf die Objekte stellt der Service Operationen bereit, die Objekte aus
der Collection zu entfernen, Objekte in der Collection ändern etc.
Zur Formulierung der Queries können folgende Sprachen genutzt werden:

34
OQL – ODMG-93 Objekt Query Language
© GDV 1999
Das objektorientierte technische Referenzmodell

SQL mit objektorientierten Erweiterungen

Eine Mischung aus den SQL und OQL
Die technische Architektur der VAA
Schematische Darstellung des Ablaufes:
Client
Query Evaluator
Query Evaluator
Query Evaluator
Native Query System
Objekt
Abbildung 17: Der CORBA Query Service
Das Ergebnis einer Query ist eine Collection, die auch Basis für weitere Suchoperationen sein kann.
Mit Hilfe von Iteratoren können die Collections durchlaufen werden.
Sollen diese Collections wiederum die Basis für neue Queries auf der zugehörigen Objektmenge sein,
müssen diese Collections die Eigenschaft besitzen, QueryEvaluator zu sein. Man spricht dann von
einer QueryableCollection. Das QueryableCollection-Interface verfügt über eine evaluate-Methode,
mit deren Hilfe Queries (übergeben in Form eines SQL- oder OQL-Statements) direkt ausgeführt
werden können. Wie jede Collection stellt auch QueryableCollection einen Iterator zur Verfügung, mit
dem über die Ergebnismenge navigiert werden kann.
Da die Bearbeitung einer Abfrage u.U. sehr zeit- und ressourcenintensiv ist, bietet der Query Service
einen Mechanismus in Form des Query - Interfaces an. Ein Query-Object, das von einem
QueryManager, einer mächtigeren Form des QueryEvaluators, erzeugt wird, vermag eine übergebene
Query (in Form eines SQL- oder OQL-Statements) zunächst zu kompilieren und sie nach Bedarf
beliebig oft ausführen.
Um den unterschiedlichen Konstruktionen Rechnung zu tragen, wird in CORBA zwischen dem
Service vom Typ Collections und dem Service vom Typ Query Framework unterschieden.
Der Typ Collection wird in dem Module CosQueryCollection spezifiziert und enthält die Interfaces

CollectionFactory; zum Erzeugen einer Collection

Collection; repräsentiert die Collection

Iterator; ermöglicht das navigieren in der Collection
Der Typ Query Framework wird in dem Modul CosQuery spezifiziert und enthält folgende
Interfaces

QueryLanguageType; definiert die Query Language

QueryEvaluator; repräsentiert den Query Auswerter
© GDV 1999
35
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell

QueryableCollection; Ergebnis-Collection und Basis neuer Queries

QueryManager; erzeugt ein Query Object

Query; repräsentiert ein Query Object
Beispiel
Das folgende Sequenzdiagramm stellt den Ablauf einer Query mit Hilfe eines Query-Objects dar:
Client
QueryManager
Query
create
QueryableCollection
create
create
prepare
execute
Iterator
get_result
create
create_iterator
next
usw...
1. Der Client ruft die Methode create des Query Managers auf, der seinerseits das QueryObject erzeugt und
die Referenz auf das Objekt zurückgibt.
2. Die Query wird mittels prepare compiliert (aber noch nicht ausgeführt), wobei als Parameter ein Statement
in SQL- oder OQL-Syntax mitgegeben wird.
3. Die Query wird mittels execute ausgeführt und dabei die Ergebnismenge in der Queryable Collection
hinterlegt.
4. Mittels get_result kann der Client erfahren, ob seine Query erfolgreich ausgeführt wurde.
5. Um über die Ergebnismenge zu navigieren wird durch die Methode create_iterator ein Iterator erzeugt.
6. Durch die next-Methode des Iterators kann von einem Ergebnis zum anderen gesprungen werden.
Abbildung 18: Beispiel für eine Query mit dem QueryManager
Wertung
36
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Bei einer Datenbankabfrage (Query) ist der Object Query Service abhängig vom Datenschema und
dem zugrunde liegenden Datenmodell. Damit wird die Flexibilität und die Performance des Services
stark eingeschränkt. Damit bietet der Query Service wenig Vorteile. Dies ist sicherlich auch ein
Grund, warum die meisten CORBA ORB Hersteller diesen Service noch nicht implementiert haben.
II.1.3.11. Security Service
Definition
Der Security Service von CORBA definiert Schnittstellen mit denen Sicherheitsmechanismen bzw. –
technologien in einem Object Request Broker integriert werden können. Dieser Dienst ist - analog
zum Transaktionsdienst - für die Client- und die Serverobjekte transparent, d.h. der Dienst muß nicht
explizit aufgerufen werden, sondern führt seine Aufgaben im „Hintergrund“ durch. Nur für spezielle
Absicherungen von Programmteilen kann der Sicherheitsdienst explizit aufgerufen werden.
Folgende Aufgabenstellungen werden vom Security Service unterstützt, um eine sichere
Kommunikation in einer verteilten Umgebungen zu ermöglichen:

Die Überprüfung der Identität des Clients bzw. des Benutzers einer Client-Anwendung
(Authentication)

Die Absicherung der Nachrichtenübermittlung gegen Abhören und Manipulation.
(Security of Communication)

Die Überprüfung, ob ein Client berechtigt ist, die aufgerufene Operation des betreffenden
Objekts zu benutzen. (Authorization)

Aufzeichnung von sicherheitsrelevanten Aktionen, für die der Benutzer später
verantwortlich gemacht werden kann. (Auditing)

Nachweis, daß eine Kommunikation zwischen Client und Server unwiderlegbar
stattgefunden hat. (Non-Repudiation)

Zusammenarbeit mit anderen Systemen, die keine bzw. andere Sicherheitsverfahren
besitzen. (Interoperability)
Der CORBA Security Service wurde so konzipiert, daß er nicht an spezielle Verfahren und
Technologien gebunden ist, sondern für die Einbindung von allen Arten von Sicherungssystemen
offen ist.
Beispiel
Anhand einer schematischen Darstellung des Ablaufes einer Berechtigungsprüfung wird hier gezeigt, wie die
Sicherheitsmechanismen in CORBA integriert sind:
1. Der Client muß gegenüber einem Beglaubigungssystem (PrincipalAuthenticator) seine Identität
nachweisen. Als Bestätigung seiner Identität erhält der Client ein Dokument, das seine Identität und seine
Rechte (evtl. zeitlich befristet) nachweist (Credential). Die Erstellung der Credentials kann das
Sicherheitssystem auch ohne explizite Aufforderung vom Betriebssystem ermitteln.
2. Diese Credentials werden - für den Client transparent - über den COBRBA::CURRENT Kontext zusammen
mit der eigentlichen Nachricht zum Server übermittelt. Verschlüsselung und Quersummenbildungen (ParityCheck) sorgen dabei für eine sichere Kommunikation zwischen Client und Server.
3. Das Server-Objekt hat die Aufgabe zu überprüfen, ob die angeforderte Operation vom Aufrufer (Client)
© GDV 1999
37
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
überhaupt verwendet werden darf. Dazu reicht der ORB das mitgelieferte
Zugriffsentscheidung des Sicherheitsdienstes (AccessDecision) weiter. Hinter
Schnittstellen verbirgt sich das eigentliche Autorisierungsverfahren, das ermittelt ob
seine Identität und Rollen für die betreffenden Ressource (Server-Objekt) berechtigt
Operation auszuführen.
Credential an die
dieser abstrakten
der Aufrufer durch
ist, die gewünschte
4. Zusätzlich erfragt der ORB beim Sicherheitsdienst, ob das gerade eingetretene Ereignis sicherheitsrelevant
war (AuditDecision) und daher vom ORB im Protokollkanal (AuditChannel) abgelegt werden muß.
5. Je nachdem, ob die gewünschte Operation abgelehnt oder ausgeführt wurde, wird an den Client eine
Sicherheitsausnahme (Security-Exception) oder das Ergebnis der Operation zurückgegeben.
Tritt ein Objekt in einer Aufrufkette als Client und als Server auf, so kann im Sicherheitsdienst festgelegt werden, ob
nur die Credentials des Aufrufers, nur die Credentials des Aufgerufenen oder eine Zusammenfassung aus beiden an
den nächsten Server weitergeleitet werden.
Zur Kooperation mit anderen ORBS und anderen Sicherheitssystemen werden alle Informationen des
Sicherheitskontextes in das IIOP-Protokoll eingebettet.
Weitere Details können der Security Service Spezifikation (Kapitel 15 der CORBAServices) entnommen werden.
Abbildung 19: Prinzipieller Ablauf einer Berechtigungsprüfung in CORBA
Wertung
Sicherheit ist eine der essentiellen Anforderungen an verteilte Systeme, insbesondere wenn ihre
Kommunikation z.T. in öffentlichen Netzen stattfindet (Internet). Zur Einbindung der verschieden
Sicherheitssystems RACF, Windows NT und UNIX bietet der CORBA Sicherheitsdienst sicherlich
flexiblere Möglichkeiten als das Sicherheitsmodell vom DCOM. Dennoch ist man bei der
Bereitstellung eines solchen Service auf die Verfügbarkeit von Produkten angewiesen, da der
Aufwand einer eigenen Implementierung des Sicherheitsdienstes im Rahmen der VAA viel zu hoch
wäre.
II.1.3.12. Externalization Service
Definition
Der Externalization Service beschreibt die erforderlichen Interfaces, Protokolle und Vereinbarungen
zur Auslagerung (externalize) und Wiedereinlagerung (internalize) von Objekten. Aus
Portabilitätsgründen nutzen alle CORBA - konformen Implementierungen dieses Services ein
standardisiertes Datenformat, daß als Teil dieses Dienstes definiert ist. In diesem Rahmen können
viele verschiedene Datenformate und Speichermedien unterstützt werden.
Der Externalization Service ist funktional eine Untermenge des Persistence Service, da er ebenfalls
den Zustand eines Objektes dauerhaft speichert, Änderungen des Zustands jedoch nicht automatisch
berücksichtigt. Um ein Objekt auszulagern, wird der Zustand des Objektes in Form eines
Datenstromes („Streams“) aufgezeichnet. Dieser Datenstrom kann je nach Anwendung im Speicher
gehalten, auf einen externen Datenträger geschrieben oder über ein Netzwerk versandt werden. Der so
entstandene Datenstrom kann in Form eines neuen Objektes in denselben oder einen anderen Prozeß
wiedereingelagert werden.
Der Externalization Service benutzt den Relationship Service um Gruppen von in Beziehung
zueinander stehenden Objekten innerhalb des gleichen Streams auszulagern und Interfaces des
LifeCycle Services um aus einem Stream Objekte zu erzeugen. Der Kern des Service manifestiert sich
in dem sogenannten Stream Objekt.
38
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Im Rahmen des Externalization Service sind die folgenden drei Sichten und Verantwortlichkeiten mit
jeweils eigenen, standardisierten Interfaces definiert.
1. Die Sicht des Benutzers des Services, die sich aus den Interfaces zusammensetzt, die benutzt
werden, um Objekte auszulagern und wiedereinzulagern. Diese Sicht ist durch das Stream
Interface definiert.
2. Die Sicht des auszulagernden Objektes, die sich aus den Interfaces zusammensetzt, die von
auslagerbaren Objekten benutzt werden, um ihren Zustand in einem oder aus einem externen
Datenstrom aufzuzeichnen oder wiederherzustellen. Diese Sicht ist im StreamIO Interface
definiert.
3. Die Sicht des Stream Objektes, die sich aus den Interfaces zusammensetzt, die von ihm benutzt
werden, um den Zustand auslagerbarer Objekte oder auslagerbarer Objektgruppen aus
untereinander abhängigen Objekten in einem oder aus einem externen Datenstrom
aufzuzeichnen oder wiederherzustellen. Diese Sicht ist durch die Interfaces Streamable, Node,
Role und Relationship definiert.
Darüber hinaus sind einige Factory-Objekte mit create - Schnittstellen im Konzept vorgesehen.
Die Benutzersicht der Auslagerung von Objekt Zuständen ist sehr simpel. Ein Benutzer erzeugt ein
Stream-Objekt und übergibt ihm ein oder mehrere Objekte zur Auslagerung. Ein Stream Objekt wird
erzeugt durch den Aufruf einer StreamFactory. Man kann ebenso einen Datenstrom für die
Auslagerung in eine Datei erzeugen. Dazu wird eine FileStreamFactory aufgerufen. Durch den
Aufruf der Methode externalize mit der Objektreferenz des auszulagernden Objektes wird das Stream
Objekt aufgefordert, den Zustand des Objektes in einem Datenstrom („Stream“) auszulagern. Ebenso
kann der Zustand mehrerer Objekte gemeinsam in einem Datenstrom ausgelagert werden. Dazu wird
zu Beginn die Methode begin_context, nachfolgend für jedes auszulagernde Objekt die Methode
externalize und zum Abschluß die Methode end_context des Stream-Objektes aufgerufen. Es wird
dasselbe Interface zur Auslagerung eines einzelnen Objektes oder einer Gruppe von abhängigen
Objekten benutzt.
Wenn das Stream-Objekt den Aufruf von externalize registriert, veranlaßt es seinerseits den Aufruf der
Methode externalize_to_stream des Streamable Interface des Zielobjektes. Alle auslagerbaren Objekte
müssen dieses Interface implementieren. Das auzulagernde Objekt ruft seinerseits die Methoden des
StreamIO - Interface auf, um seinen Zustand in einen Datenstrom zu schreiben oder von ihm zu
lesen. Dieses Interface wird durch den Stream Service implementiert; er stellt Operationen zum Lesen
und Schreiben aller IDL-Datentypen zur Verfügung. Das Stream Objekt implementiert dieses Interface
entweder selbst, oder übergibt eine Objektreferenz darauf, wenn es das auszulagernde Objekt aufruft.
Um ein Objekt aus einem Datenstrom wiedereinzulagern, ruft der Benutzer die internalize -Methode
des Stream-Objektes auf. Das Stream-Objekt muß ein Streamable-Objekt identifizieren, daß seinen
Zustand aus einem Datenstrom wiedereinlagern kann; es benutzt das StreamableFactory Interface um
das Objekt zu erzeugen. Das Stream-Objekt ruft dann die internalize_from_stream - Methode des
Streamable-Objektes auf. Selbstverständlich benutzt das Streamable-Objekt das StreamIO Interface
um den Datenstrom zu lesen.
Beispiel
Das folgende Sequenzdiagramm stellt den prinzipiellen Ablauf der Externalization und Internalization über einen
Stream dar:
© GDV 1999
39
Die technische Architektur der VAA
Client
Das objektorientierte technische Referenzmodell
StreamFactory
1 create
Streamable
StreamIO
Stream
2 externalize
3 externalize_to_stream
4 write_<type>
4 write_object
4 write_graph
5 internalize
Streamable
6 internalize_from_stream
7 read_<type>
7 read_object
7 read_graph
Abbildung 20: Lesen und Schreiben von Objekten im Externalization Service
Wertung
Der Stream-Mechanismus des Externalization Services ist aufgrund seiner Einfachheit sehr robust und
universell einsetzbar und hat sich aus diesem Grund in der Objektwelt generell eingesetzt, um Objekte
in sequentiellen Dateien zu speichern oder von einer Anwendung zur anderen - auch über ein
Netzwerk - zu transportieren. Streams werden außer in CORBA auch in Java und in Microsofts COMArchitektur zur Übertragung oder Speicherung von Objekten genutzt, die verwendeten Formate sind
allerdings unterschiedlich.
Zur einfachen Speicherung von Daten ist der CORBA Externalization Service insbesondere in
heterogenen Systemumgebungen gut geeignet, in reinen Java- oder COM-Umgebungen empfiehlt sich
der Einsatz der jeweiligen Technologie, da diese besser durch Frameworks unterstützt werden. Für die
Übertragung von Objekten als Parameter in Methodenaufrufen ist der Externalization Service zwar
ebenfalls geeignet, wird aber in CORBA 3.0 durch die einfacher zu handhabende „Pass-By-Value“ Option obsolet.
40
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
II.1.3.13. Event Service
Definition
Der Event Service bietet die Basis, auf der Dienste wie die asynchrone Verarbeitung von Ereignissen,
Notification usw. beschrieben werden können. Der CORBA Event Service erfüllt dabei die folgenden
Anforderungen:

Die Schnittstellen des Event Service sind so flexibel gehalten, daß Event Services mit
verschiedenen qualitativen Merkmalen mit diesen Schnittstellen implementiert werden
können.

Der Event Service enthält keine spezielle, fachliche Logik um seine Flexibilität in
verschiedenen Einsatzfeldern nicht zu beeinträchtigen

Sowohl Push- als auch Pull-Event-Verarbeitung werden unterstützt, d.h. entweder wird
der Empfänger eines Events durch den Service informiert, oder der Client besorgt sich
seine Informationen selbst vom Event Service.

Das Objekt das einen Event auslöst (Supplier) braucht die Identität des Empfängers
(Consumer) nicht zu kennen und umgekehrt braucht der Empfänger die Identität des
Senders nicht zu kennen.

Der Event Service bedient sich bei der Erledigung seiner Aufgaben eines Event Channels,
durch den die Entkoppelung zwischen Consumer und Supplier erreicht wird. Jedem
Consumer steht ein sogenanntes Supplier-Proxy zur Verfügung, das als Platzhalter für den
Supplier des Events fungiert. Analog steht dem Supplier ein Consumer-Proxy zur
Verfügung, das die Übermittlung des Events initiiert. Die Consumer-Supplier Interfaces
sind symmetrisch.

Der Event Service ist skalierbar und als verteilter Service realisiert, d.h. es gibt keine
zentrale Stelle an der Event Channels verwaltet werden. Event Channels lassen sich zu
einer Kette verbinden, d.h. Event Channel Server können durch die Verbindung von
unabhängig implementierten Event Channels miteinander kommunizieren.

Events sind in der einfachen Form des Event Services nicht typisiert, d.h. die Interpretation
und Festlegung von Typ und Inhalt eines Events obliegt der jeweiligen Anwendung. Der
Event Service unterstützt allerdings auch typisierte Events in Form von Subtypen des
einfachen Event-Interfaces.
In CORBA werden zwei Module definiert, die die Schnittstellen des Event Service beschreiben

Das CosEventChannelAdmin - Modul
Enthält Interfaces zum Aufbau eines Event Channels und zur Ermittlung eines bestehenden
Event Channels

Das CosEventComm - Modul
Enthält Interfaces zum Austausch von Events über einen bestehenden Event Channel
Beispiel
Zur Illustration folgt ein Sequenzdiagramm, das den Aufbau eines Event Channels für ein Push-Event und die
entsprechende Nutzung durch einen Client beschreibt.
© GDV 1999
41
Die technische Architektur der VAA
Consumer
Das objektorientierte technische Referenzmodell
EventChannnel
Supplier
for_suppliers
SupplierAdmin
Obtain_push_consumer
ProxyPushConsumer
for_consumers
ConsumerAdmin
Connect_push_supplier
Obtain_push_supplier
ProxyPushSupplierr
Connect_push_consumer
push
1. Ein Supplier fordert mit for_suppliers ein SupplierAdmin-Objekt an, mit dessen Hilfe der Event Channel
aufgebaut wird
2. mit obtain_push_consumer erhält der Supplier ein Proxy-Objekt als Platzhalter für Consumer
3. Mit connect_push_supplier registriert sich der Supplier beim Event Channel
4. Analog verbindet sich ein Consumer mit einem Event Channel (der über seinen Namen mit Hilfe des
Naming Service gefunden werden kann) durch Aufruf von for_consumers, obtain_push_supplier und
connect_push_consumer
5. Sobald der Supplier ein Event auslöst durch Aufruf der push-Methode des ProyPushConsumer, wird dies
über den Event Channel zu den ProyPushSupplier-Objekten weitergereicht, die ihrerseits das angebundene
Consumer-Objekt informieren.
Abbildung 21: Beispiel für den Event-Service
Wertung
Der Event Service von CORBA stellt grundlegende Funktionalität eines objektorientierten Messaging
Systems zur Verfügung. Es fehlen allerdings in CORBA 2.0 weitere wichtige Eigenschaften wir die
sichere Übertragung von Messages, die Priorisierung und die Filterung von Messages. Entsprechende
Standardisierungen sind allerdings im Gange (siehe Kapitel II.1.4). Ebenfalls wünschenswert ist die
Verbindung von Messages mit Properties, wie dies in JavaBeans realisiert ist und die Definition von
generellen Event-Typen. Durch das angestrebte Zusammenwachsen von JavaBeans und CORBA
sollen diese Mängel behoben werden. Umgekehrt werden dadurch JavaBeans-Events
plattformunabhängig und können auch über ein Netzwerk übertragen werden.
42
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
Vor allem bei Anwendungen, in denen eine große Zahl unterschiedlicher Systeme sporadisch über
Zustandsänderungen benachrichtigt werden müssen, bietet sich die Verwendung des CORBA EventService an. Er ermöglicht eine lose Koppelung völlig unterschiedlicher Systeme. In Zusammenhang
mit Beans bietet er darüber hinaus in Zukunft einfache, werkzeugunterstütze
Verbindungsmöglichkeiten für Komponenten unterschiedlicher Hersteller.
II.1.4. CORBA 3.0 und Java
Übersicht
Die in den vorangegangenen Abschnitten beschriebenen CORBA-Dienste und ORB-Funktionen
beschränken sich auf die zur Zeit verfügbaren Spezifikationen CORBA 2.x. Die OMG kündigte für
das erste Halbjahr 1999 die endgültige Version von CORBA 3.0 an. Im Fokus von CORBA 3.0 stehen
insbesondere Spezifikationen bezüglich CORBA-Komponenten und verteilten Internet-Anwendungen:






Das CORBA Component Model definiert ein Framework für die Realisierung und Konfiguration
von Business Komponenten und ist sehr stark an die JavaBeans - Spezifikationen angelehnt.
Durch CORBA Messaging (MOM) ist auch die asychrone, zeitverzögerte Kommunikation
zwischen verteilten Objekten möglich. MOM bietet damit vergleichbare Dienste an wie IBM´s
Messaging and Queueing.
CORBA 3.0 unterstützt den Transfer von Objekten als Parameter von Methodenaufrufen durch die
Object-by-Value - Spezifikationen. Neben dem Transfer des Objektzustandes (d.h. der
Objektdaten) ist auch ein Protokoll für den Austausch des zum Objekt gehörenden Programmcodes
definiert.
Java-to-IDL - Mapping bildet das gebräuchliche und einfach zu verwendende RMI-Protokoll auf
CORBA-IDL ab. Dadurch entfällt das explizite Erstellen der Interface-Beschreibungen. Die IDLDefinition eines Java-Objektes wird aus der Objektdefinition generiert. Durch die Verbindung von
RMI mit CORBA können Java-Anwendungen über RMI nicht nur mit Java-Objekten
kommunizieren, sondern es stehen ihnen alle Sprachplattformen zur Verfügung, für die ein
CORBA-Language-Mapping existiert.
Die Spezifikation eines Portable Object Adapters (POA) erlaubt den Einsatz von Komponenten
auf unterschiedlichen ORB-Plattformen ohne Neugenerierung der Stubs und Skeletons. Bisher
mußten Server-Komponenten für die ORBs unterschiedlicher Hersteller jeweils kompiliert und
gebunden werden. POA legt in diesem Zusammenhang die Schnittstelle zwischen ORB, Adapter
und den implementierten Objekten eindeutiger fest als dies in CORBA 2.0 der Fall war. Unter POA
bleibt eine CORBA-Object Reference unabhängig davon gültig, ob das Server-Objekt aktiv ist oder
nicht.
Die Spezifikation von Schnittstellen für Internet-Firewalls ermöglicht die Überwachung und
gegebenenfalls die Filterung der IIOP-Kommunikation in Netzwerken mit Zugang zum Internet.
Das CORBA Component Modell und JavaBeans
Die oben aufgeführten Erweiterungen des CORBA-Standadards (vgl. hierzu auch [xi]) führen CORBA
sehr nahe an JavaBeans beziehungsweise EnterpriseJavaBeans heran. Insbesondere die
Spezifikationen zu Java-to-IDL - Mapping, POA und Objects-by-Value sind Grundvoraussetzungen
für eine weitgehende Kompatibilität beider Welten.
© GDV 1999
43
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Die Integration von CORBA und JavaBeans liefert Spezifikationen für eine Reihe „weißer Flecken“ in
den bisherigen Versionen beider Standards:







CORBA verfügte bisher über keine Tool-Interfaces, die das werkzeugunterstützte Konfigurieren
von beliebigen Komponenten ermöglichen. Tool-Interfaces dienen dazu, Entwicklungswerkzeugen
Informationen über eine Komponente auf standardisierte Art und Weise zur Verfügung zu stellen.
Durch die Adoption von entsprechenden Entwurfsmustern aus JavaBeans, können CORBAKomponenten zukünftig auf die gleiche Weise konfiguriert und integriert werden, wie dies heute
mit Beans-orientierten Entwicklungsumgebungen möglich ist.
CORBA-Komponenten können zukünftig als eigenständige Pakete ausgeliefert und installiert
werden. Der Mechanismus entpricht dem JavaBeans-Packaging in JAR-Files.
Durch die Definition von Events, die Komponenten untereinander austauschen können, ist die
Interaktion von CORBA-Komponenten wie bei JavaBeans mit Hilfe von visuellen
Entwicklungswerkzeugen definierbar. Der CORBA Event Service definiert bisher zwar den
grundlegenden Übertragungsmechanismus, trifft aber keinerlei Festlegung über die Art der Events,
die ausgetauscht werden.
Durch automatische Verknüpfung von Properties mit Events, wie sie in JavaBeans definiert sind
(sogenannte bount oder contraint properties) können zukünftig CORBA-Komponenten über
Zustandsänderungen informiert werden, ohne daß die Verknüpfung zwischen Event und
Zustandsänderung explizit programmiert werden muß.
Durch die Integration von JavaBeans und CORBA ist die Integration von Komponenten in
unterschiedlichen Sprach- und ORB-Umgebungen möglich. Komponenten sind nicht nur in
Java-Umgebungen interoperabel, sondern auch in gemischten Umgebungen.
Im CORBA 3.0 Component Model und in der POA-Spezifikation fehlen Spezifikationen für das
Zusammenspiel zwischen Server-Komponenten und einem Transaktionsmanager (OTM).
Diese Lücke wird durch das Container-Konzept von Enterprise JavaBeans geschlossen. Der Java
Transaction Service (JTS) ist compatibel mit dem CORBA Object Transaction Service (OTS).
Durch die Integration können JavaBeans die Dienstpalette und Netzwerkinfrastuktur von
CORBA nutzen, einschließlich des verteilten Event Service, des Security Service und des IIOPProtokolls.
Wertung
Bereits vor dem Erfolg von Java wurde deutlich, daß wichtige Bereiche durch die bestehenden
CORBA 2.0 Spezifikationen nicht abgedeckt wurden, insbesondere der Bereich InternetAnwendungen, Komponentenmodell, portable Adapter, OTM´s und komponentenbasierte
Benutzeroberflächen. Die Entscheidung der OMG, anstelle einer eigenständigen Konzeption
Entwurfsmuster und Techniken aus JavaBeans zu adoptieren, erleichtert die Akzeptanz der CORBAStandards erheblich. Aus der Sicht der Anwendungsentwicklung bedeutet die Konvergenz zwischen
Java und CORBA vor allem größeren Entscheidungsspielraum: Dort wo heute Java aufgrund
mangelnder Reife, Performance oder Verfügbarkeit noch nicht eingesetzt werden kann, ist die
Entwicklung auf Basis anderer CORBA-Plattformen möglich, ohne daß auf zukünftige
Interoperabilität mit Java-Komponenten verzichtet werden muß.
Dies bedeutet nicht, daß eine spätere Migration oder Interoperabilität im Sinne eines „Plug-and-Play“
erreicht werden kann. Da derzeit noch keine CORBA 3.0 - Implementierungen verfügbar sind und
gleichzeitig die Enterprise JavaBeans - Spezifikationen noch keinen stabilen Stand erreicht haben, ist
44
© GDV 1999
Das objektorientierte technische Referenzmodell
Die technische Architektur der VAA
mit einigem Anpassungsaufwand beim Übergang oder der Integration zu rechnen. Die Konformität
der Entwurfsmuster beider Spezifikationen macht allerdings Änderungen im größeren Stil (Redesign
von Teilen einer Anwendung) voraussichtlich unnötig.
II.2. Distributed Internet Architecture (DNA)
II.2.1. Definition und Grundbegriffe
Die Plattform für Microsoft Anwendungen besteht aus einem mehrschichtigen, verteilten
Anwendungs-Modell und der darin enthaltenen Infrastruktur- und Anwendungsservices. Die Windows
Distributed InterNet Applications Architecture (DNA) soll sowohl die besten Services von Clients,
Anwendungsservern und Mainframes als auch die Internet-Technologie zu einer allgemeinen,
Komponenten basierten Anwendungsarchitektur vereinen.
Bei der Erstellung der DNA-Anwendungen sind folgende Grundprinzipien zu beachten:

Internet Verfügbarkeit
Anwendungen sollten die Vielfalt der Plattformen hinsichtlich ihrer globalen Kommunikationsmöglichkeiten nutzen.

Schnellere Time to Market
Anwendungen müssen schnell entwickelt werden ohne Paradigmenwechsel für die Entwickler.
Viele Services und Funktionalitäten sollten durch Schichten bereitgestellt werden, auf denen die
Anwendung basiert.

Richtige Interoperabilität
Interoperabilität in allen Schichten muß gewährleistet sein, so daß Funktionalität leicht ergänzt
werden kann. Die Nutzung von offenen Protokollen und Standards gewährleistet die Integration
anderer Systeme, auch von anderen Herstellern .

Reduktion der Komplexität
Schlüsselservices (z.B. Transaction, Message Queuing, Security) werden direkt im Betriebssystem
verankert; sie lassen sich auf einfache Weise ohne Spezialistenwissen nutzen.

Unabhängigkeit von Sprache, Tool- und Hardwareausstattung
Entwickler arbeiten auf einem sprachneutralen Komponentenmodell. Sie setzen entsprechende
Tools auf einer breiten Hardwarebasis ein.

Verringerung der Total Cost of Ownership
Anwendungen lassen sich einfach entwickeln, managen und ändern.
II.2.2. Komponenten
Die DNA-Strategie beruht auf kooperierenden Komponenten, die auf einem Binärstandard, dem
Component Object Model (COM), basieren. Die nach COM erstellten Software-Komponenten sind
kompatibel und können auf jeder Schicht innerhalb der DNA ablaufen. Beispielsweise lassen sich
User Interfaces oder fachliche Kernfunktionen in einzelnen Komponenten kapseln. Anschließend
können diese zu einer Gesamtanwendung zusammenfügt und auf unterschiedliche Plattformen verteilt
werden.
© GDV 1999
45
Die technische Architektur der VAA
Das objektorientierte technische Referenzmodell
Auf Komponenten basierende Anwendungen und DNA bedienen sich dabei einer allgemeinen
Infrastruktur sowie der Netzwerkdienste, die durch das Betriebssystem Windows bereitgestellt
werden..
II.2.2.1. Präsentation
Der Anwender erwartet heutzutage Anwendungen mit funktional hochwertigen User Interfaces. Diese
müssen performant, verteilbar und kompatibel auf Windows und Non-Windows Plattformen zur
Verfügung stehen. Sie sollten vom Laptop bis zur High-End Workstation auf, wenn möglich allen,
Browsern einsetzbar sein.
Abbildung 22: Präsentation in der DNA
DNA sieht vor, daß Windows Entwickler ihre Anwendung, nach Prüfung von fachlichen und
Effizienz-Kriterien, mit einer Windows oder Internet-Technologie ihrer Wahl umsetzen. Hierbei
stehen ihnen vier Ansätze zur Auswahl:

Browser Neutral
HTML als eine standardisierte und leicht erlernbare Beschreibungssprache verhält sich neutral auf
allen Browsern. Der Funktionsumfang für einen Einsatz auf einem Thin Client ist teilweise
eingeschränkt.

Browser Enhanced
Mehr Funktionalität bieten Browser Enhanced Anwendungen, die die speziellen Technologien
(Add-Ons) der Browser ausnutzen. Mit Dynamic HTML (DHTML) und Scripting lassen sich die
Objekte auf den Web-Seiten programmieren. Diese arbeiten unabhängig von der virtuellen
Maschine und dem Betriebssystem. Falls keine DHTML-Unterstützung vorliegt, so führt der
Browser die Seite in verminderter Qualität (HTML) aus.

Internet Reliant
Aufbauend auf dem Browser Enhanced Ansatz ist es Client-Anwendungen erlaubt, eine Mischung
aus HTML, DHTML, Scripting und ActiveX-Controls zu nutzen, um den Browserkontext optimal
zu unterstützen. Die zugrundeliegende Hardware mit dem Betriebssystem wird sinnvoll eingesetzt.
Gleichzeitig ist auch die volle Integration in die Remote-Services des Internets garantiert.
46
© GDV 1999
Das objektorientierte technische Referenzmodell

Die technische Architektur der VAA
Internet Enhanced
Mit WIN32 API entwickelte Anwendungen sind Internet Enhanced, wenn sie sich die SystemFeatures sichern und gleichzeitig mit dem Internet kommunizieren können. Beispielsweise sind im
Entwicklungssystem Visual Studio 98 Hyperlinks zum Connect mit unterstützenden Web-Sites
integriert. Die Präsentation erfolgt standardmäßig mit dem Browser, Produktupdates sind per
Download aus dem Internet möglich.
II.2.2.2. Anwendungsservice
Die in Komponenten gepackte spezifische Businesslogik liegt als Kern der Gesamtanwendung
zwischen der Client-Plattform und der Datenhaltungsumgebung. Diese Anwendungsplattform verfügt
über Web Services, Messaging Services und Component Services.

Web Services
Als Bindeglied zwischen dem Browser-User Interface und den fachlichen Komponenten
liegt der Internet Information Server IIS. Innerhalb des IIS können Anwendungen
transaktionsgesichert ablaufen. Um vom IIS einzelne fachliche Komponenten zu nutzen,
können Active Server Pages ASP eingesetzt werden. ASP’s sind sprachneutral, müssen
nicht compiliert werden und verstehen unterschiedliche Script-Sprachen. Innerhalb der
ASP-Anwendungen kann die Anwendung anwendungsglobale und Session-spezifische
Daten nutzen.

Component Services
Eine Erweiterung des COM Modells stellt der Microsoft Transaction Server MTS dar. Er
bietet Dienste für die Erstellung, die Verteilung und Administration von Komponentenbasierten Anwendungen an. Der nächste Entwicklungsschritt wird COM+ sein, das die
Dienste von COM und MTS vereinigt und einige neue anbietet, wie z.B. Einbeziehung
von Komponenten in andere Transaktions Manager, verbesserte Security, zentrale
Administration oder Load Balancing

Messaging Services
Microsoft Message Queue Server MSMQ stellt eine Kommunikation im Netzwerk auf
Basis des Message Queueing Modells bereit. Anwendungen lassen sich durch das Pushen
von Nachrichten (Messages) miteinander koppeln, auch wenn das Netzwerk, das die
Anwendungsserver verbindet aktuell nicht zur Verfügung steht. Messages können in den
Transaktionskontext mit einbezogen werden. MSMQ bietet Interfaces zu anderen
Messaging-Systemen und ermöglicht somit eine Integration z.B. in die Mainframe-Welt.
© GDV 1999
47
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
III. Die Systemarchitektur der VAA
Komponenten-basierte Softwarearchitekturen sollen die Wartbarkeit, Pfege, Überprüfbarkeit und
Anpaßbarkeit von Software erleichtern sowie den Entwicklungsprozeß beherrschbarer machen. Die
Systemarchitektur der VAA unterstützt eine komponenten-basierte Softwareentwicklung. Bevor
jedoch auf die Definition einer Komponente eingegangen werden kann, muß zunächst die für
Komponenten nötige Umgebung definiert werden.
Als „äußere Grenze“ existiert das Softwaresystem. Ein Softwaresystem stellt ein ausführbares,
integriertes System dar, das einen bestimmten Geschäftsbereich abbildet (vgl. hierzu auch den Begriff
Business System Domain der Interoperability Specification, Kapitel IV.2.2.1). Es beinhaltet in der
Regel ein oder mehrere Subsysteme.
Ein Subsystem ist eine Unterteilung des Systems und beinhaltet eine oder mehrere Komponenten.
Jedes Subsystem ist getrennt von einander entwickelbar und kommuniziert mit anderen Subsystemen
über definierte Schnittstellen. Innerhalb eines Subsystems ist der Namensraum für Objekte eindeutig.
Grundsätzlich kann der Begriff des Subsystems und der der Komponente schwer von einander
getrennt werden. Der Unterschied liegt darin, daß Subsysteme in eine Kontext gesetzt sind, während
Komponenten vom Kontext unabhängig sein sollten.
Beispiele für Systeme und Subsysteme sind:

ein KFZ-Bestandssystem mit den Subsystemen Inkasso, Partner, Provision, usw.

SAP mit seinen Subsystemen Vermögensverwaltung, Finanzbuchhaltung, Data Warehouse.
III.1. Komponente
„Eine Komponente ist ein funktional in sich abgeschlossener Softwarebaustein, der über
wohldefinierten Schnittstellen mit seiner Umgebung in Beziehung tritt und dabei in der Lage sein muß,
in unterschiedliche nicht vorhersagbare Anwendungskontexte eingebettet zu werden.“ 1
Eine Komponente stellt also eine fachliche oder technische, funktional abgeschlossene
Problemlösung mit „Black-Box“ -Wiederverwendung dar. Sie kann im allgemeinen unter
Verwendung einer beliebigen Programmiersprache implementiert werden, objektorientiert oder
prozedural. Die Interaktion mit anderen Komponenten wird durch die definierten Schnittstellen
gewährleistet.
Komponenten sind vermarktbare Software-Einheiten, deren Einsatzkontext zum Zeitpunkt der
Entwicklung nicht unbedingt vorhersagbar ist. Sie lassen sich zu größeren Einheiten zusammenbauen,
die wiederum Komponenten, Subsysteme oder Systeme sind (Baukastenprinzip).
Komponenten sind Bauteile, die durch Konfiguration den unternehmensspezifischen Bedürfnissen
angepaßt werden können und u.U. dadurch eigenständige Subsysteme oder Systeme werden können
(z.B. kann die Komponente Partnerverwaltung ein eigenes System sein).
1
Aus „Des Knaben Wunderhorn“ von Michael Stal, ObjektSpektrum 01/99
48
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Die übergreifenden Aktivitäten der einzelnen Komponenten müssen aufeinander abgestimmt sein.
Dies setzt Vereinbarungen zwischen Komponenten voraus, die vorgeben, wie übergreifende
Funktionen (z.B. Transaktionsmanagement) realisiert werden.
In der Nutzung von Komponenten sollten keine Überschneidungen von Funktionalitäten erfolgen. Das
obliegt jedoch der Verantwortung des Komponentennutzers. Eine Redundanzfreiheit der
Funktionalitäten mehrerer Komponenten kann nicht gewährleistet werden.
III.2. Business Object
Die in einer Komponente realisierte abgeschlossene Problemlösung besteht aus Einzelteilen, die
fachliche Logik repräsentieren. Die kleinste Einheit fachlicher Logik im Rahmen der
Systemarchitektur bildet das Business Object. Die Granularität einer Komponente ist in der Regel
gröber als die eines Business Objects, muß es jedoch nicht sein.
III.2.1. Definition
Ein Business Object (BO) repräsentiert einen fachlichen Ablauf oder eine fachliche Entität.
Ein fachlicher Ablauf ist dabei im Sinne eines Geschäftsvorfalls zu verstehen, wie er in VAA 2.0
definiert ist (Beispiel: „Erhöhung der Versicherungssumme eines Vertrages“).
Eine fachliche Entität stellt eine fachlich orientierte Einheit von Daten und darauf operierender
Funktionen dar, wie zum Beispiel Vertrag oder Partner.
Ein Business Object ist innerhalb des Systems, in dem es definiert ist, eindeutig identifizierbar.
Das heißt, es verfügt über einen Schlüssel, mit dem es jederzeit – unabhängig von anderen Objekten –
ermittelt werden kann. Bei diesem Schlüssel handelt es sich entweder um einen durch ein
Schlüsselsystem vergebenen technischen Schlüssel oder um einen fachlich motivierten Schlüssel in
Form von kombinierten Attributen. Der Schlüssel bleibt für die Lebenszeit des Business Objects
immer eindeutig.
Der Schlüssel ist nicht identisch mit der Objektreferenz eines Business Objects. Die Objektreferenz
dient dem Direktzugriff auf dessen Methoden und ist gültig, unabhängig davon, ob das Business
Object sich im Speicher befindet oder nicht (Persistent ObjectID). Die Objektreferenz eines Business
Objects ist über die gesamte Lebenszeit eines Business Objects eindeutig und wird auch nach dessen
Löschen nicht wiederverwendet.
Ein Business Object muß eine Methode bereitstellen, die den Test auf Gleichheit mit einem anderen
Business Object (des gleichen Typs) erlaubt. Im einfachsten Fall verbirgt sich dahinter lediglich die
Prüfung des Schlüssels, es sind aber auch komplexere Fälle denkbar, z.B. dann, wenn sich hinter
einem Business Object mehrere Versionen verbergen.
Ein Business Object nimmt an Transaktionen teil. Das heißt, Änderungen am Zustand eines Business
Objects werden in einem Transaktionskontext durchgeführt.
Ein Business Object ist in der Regel persistent. Das heißt, Änderungen am Zustand eines Business
Objects werden nach erfolgreicher Beendigung der Transaktion gespeichert.
© GDV 1999
49
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Ein Business Object kann Beziehungen zu anderen Business Objects enthalten. Da Business Objects
unabhängig voneinander existieren, werden Beziehungen als Schlüssel oder Objektreferenzen im
obigen Sinn innerhalb des Business Objects gespeichert.
Präsentationskomponenten können Business Objects zugeordnet werden..
III.2.2. Struktur eines Business Objects
Ein Business Object repräsentiert Fachlogik, die im allgemeinen durch mehr als ein Objekt dargestellt
wird. Von außen betrachtet wird ein Business Object jedoch durch ein Objekt repräsentiert. Dieses
Objekt trägt den Schlüssel und stellt die öffentlichen Methoden des Business Objects zur Verfügung.
Es ist gewissermaßen eine Fassade des Modells nach außen.
Ein Business Object kann Referenzen auf andere Business Objects sowie Objekte beinhalten, die im
Gegensatz zum Business Object allein im System weder eindeutig identifizierbar noch speicherbar
sind. Wir nennen diese Art von Objekten Dependent Objects. Dependent Objects können als
Parameter zwischen Business Objects ausgetauscht werden.
Beispielsweise enthält des Business Object Vertrag ein Dependent Objekt Ablaufdatum und hält eine
Referenz zum Versicherungsnehmer, einem Business Object des Typs Partnerrolle.
BO
„Partnerrolle“
Business Object
„Vertrag“
Attribute
•Produkt
•VN
•VersNr
•Ablaufdatum
•...
Funktionen
•getVersNr
•getAblaufDatum
•...
systemweite Objektreferenz/ Objekt-ID
lokale Objektreferenz
Dependent
Object
„Ablaufdatum“
Definition Dependent Object:
i.a. Attribut eines BO
nicht eindeutig identifizierbar
Transaktionen nur in
Zusammenhang mit BO
hat i.a. Zustände und Attribute
ist persistent nur als Attribut
eines BO
Im allgemeinen wird der Zustand eines Business Objects durch die Werte aller Attribute bestimmt. In
den meisten Fällen ist es jedoch zweckmäßig, explizite Zustandsvariablen einzuführen, die den nach
außen relevanten Zustand eines Business Objects bestimmen (z.B. Vertragszustände: „geprüft“,
„ungeprüft“, „freigegeben“, “storniert“ usw.).
Methoden können den Zustand sowie die Attribute eines Business Objects ändern und werden deshalb
im allgemeinen innerhalb eines Transaktionskontextes ausgeführt.
50
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Im Rahmen der persistenten Speicherung eines Business Objects werden alle intern als persistent
gekennzeichneten Objekte samt ihrer Attribute einschließlich der Schlüssel nach erfolgreicher
Beendigung der Transaktion gespeichert. Welche Objekte innerhalb eines Business Objects persistent
gespeichert werden, ist von außen nicht sichtbar.
III.2.3. Typisierung
Anwendungssysteme der Versicherungswirtschaft sind geprägt durch Geschäftsvorfälle, die einerseits
sehr komplex und variantenreich sein können, andererseits aber meist auf den gleichen „Daten“
operieren. Um diesen Anforderungen gerecht zu werden, ist es sinnvoll, zwei Kategorien von Business
Objects zu definieren:

Entity Business Objects (EBO),
die die zu logischen Einheiten zusammengefaßten Daten (Attribute) einschließlich der ihnen
zugeordneten Funktionen (Methoden) repräsentieren.

Process Business Objects (PBO),
die Geschäftsvorfälle repräsentieren.
Business
Object
Process
BO
Entity
BO
Abbildung 23: Kategorien von Business Objects
Damit soll keine Trennung zwischen Funktionen und Daten eingeführt werden. Process Business
Objects dienen vielmehr dazu, Abläufe, die mehrere Business Objects betreffen und die abhängig sind
von äußeren Gegebenheiten, zu modellieren und zu implementieren. Process Business Objects
erhöhen damit die Wiederverwendbarkeit von Entity Business Objects.
III.2.3.1. Entity Business Object (EBO)
Ein EBO repräsentiert eine fachlich orientierte Einheit von Daten und darauf operierender Funktionen,
wie zum Beispiel Vertrag oder Partner.
Ein EBO kann weitere Entity Business Objects aufrufen und benutzen. Im untern dargestellten,
vereinfachten Beispiel ruft die Methode berechnePrämie des EBO Vertrag über sein Dependent
Object Prämienrechner Methoden der Business Objects Versicherte Person und Produkt auf. Ein
alternatives Vorgehen könnte sein, daß Vertrag über die Methode getPrämeinerechner das Dependent
Object Präemenrechner zurückliefert (samt der Referenzen zu den assozierten Business Objects). Die
Berechnung kann daraufhin durch den Aufrufer zu beliebigen Zeitpunkten geschehen.
© GDV 1999
51
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
EntityBO
„Partnerrolle
= VP“
EntittyBO
„Vertrag“
Attribute
•VN
•Produkt
•VersNr
•Ablaufdatum
•Prämienrechner
Funktionen
•getVersNr
•getAblaufDatum
•berechnePrämie
EntityBO
„Produkt“
Dependent
Object
„Prämienrechner“
berechne
Abbildung 24: Entity Business Object
III.2.3.2. Process Business Object (PBO)
Ein PBO repräsentiert einen fachlichen Ablauf im Sinne eines Vorgangs, Geschäftsvorfalls oder
Geschäftsprozesses. Das bedeutet, daß es über Attribute verfügt, die den aktuellen Fortschritt
innerhalb des Vorgangs repräsentieren sowie die Übergangsbedingungen von einem Schritt zum
nächsten definieren.
Ein PBO bildet einen Geschäftsgang ab, innerhalb dessen Entity Business Objects aktiviert werden.
Ein PBO bildet den Transaktionskontext eines Prozesses.
Process Business Objects können sehr komplexe Prozesse abbilden, aber auch elementare Teilprozesse
darstellen. Ein PBO kann selbst andere Process Business Objects als „Teilvorgänge“ benutzen.
Ab einer bestimmten Ebene von Geschäftsprozessen sollten PBOs bestimmte gemeinsame Dienste
nutzen, z.B. Ablaufverfolgung, Prozeßsteuerungsdienst, Postkorb, Terminverwaltung. Die bis dahin
fest „verdrahtete“ Struktur von PBO wird durch die Nutzung solcher Dienste dynamisiert.
PBO steuern Abläufe und haben in der Gesamtheit ein komplexes Wissen der Ablauforganisation.
52
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Entitäts-BO
„Vertrag“
Prozeß-BO
„Versicherungssumme
erhöhen“
Attribute
•AktSchritt
•EBOVertrag
•PBORisikoPrüfung
•Provision
•...
Funktionen
•start
•setTxContext
•...
Prozeß-BO
„RisikoPrüfung“
Dependent
Objekt
„Provision
ermitteln“
„(Teil-)Vorgang“
Andere
Business Objects
„Vorgang“
Abbildung 25: Process Business Object
In vielen Fällen besteht die fachliche Anforderung, Funktionen zu modellieren, die auf Basis von
Attributen vieler Business Objects Berechnungen oder Prüfungen vornehmen, aber keine eigenen
Zustände kennen und ohne Unterbrechung ablaufen. Ihrer Natur nach handelt es sich um Objekte, die
einem EBO zugeordnet (vgl. das Objekt Prämienrechner im vorangegangenen Abschnitt) oder als
eigenständige PBO realisiert werden können, oder sogar als konstantes „Einmal“-Objekt („Singleton“,
vgl. [xii]) systemweit zur Verfügung stehen.
Abläufe innerhalb der Domäne eines EBO werden als Methoden innerhalb des betreffenden EBO
modelliert. Die Funktionalität eines EBO ist also implizit unabhängig vom Kontext in dem es sich
befindet. Der erforderliche fachliche Kontext wird über die benutzenden PBO hergestellt. Dies gilt
auch dann, wenn mehrere EBO betroffen sind, der Ablauf aber unabhängig vom aktuellen
Geschäftsvorfall immer gleich bleibt (Beispiel: die Zuordnung des Versicherungsnehmers zu einem
Vertrag oder die Erzeugung einer neuen Vertragsversion bei Vertragsänderungen).
Dabei sollte das rufende Objekt nicht Daten von beteiligten Objekten holen, um Aufgaben
auszuführen, sondern die Aufgaben in Teile zerlegen und für jeden dieser Teile den richtigen
Adressaten aufrufen (vgl. Entwurfsmuster „Vermittler“ in [xii]).
III.2.4. Dienste
Die in der technischen Architektur beschriebenen CORBA-Dienste sind die technische Basis für das
Management und die Interaktion von Business Objects. Allerdings gibt es zu viele Freiheitsgrade bei
der Gestaltung des Zusammenspiels zwischen den CORBA-Diensten und den Objekten, die diese
Dienste nutzen. Beispielsweise ist in CORBA nicht definiert, welche Typen von Events zwischen
Business Objects ausgetauscht werden können. Dadurch ist die einheitliche Gestaltung von Business
Object - Komponenten unterschiedlicher Hersteller nicht ohne weiteres gegeben.
Höherwertige Dienstspezifikationen dieser Art sind deshalb unverzichtbarer Bestandteil von
Komponentenarchitekturen wie (Enterprise) JavaBeans, DCOM und (zukünftig) CORBA Beans. Da
ein diesbezüglich einheitlicher Standard heute noch fehlt, beschränken wir uns an dieser Stelle auf die
Beschreibung der Mindestfunktionalität von Diensten, wie sie Business Objects im oben definierten
Sinne benötigen. Diese Mindestfunktionalität kann jederzeit auf die Funktionen eines ausgewählten
Komponenten-Frameworks abgebildet werden.
© GDV 1999
53
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Folgende Dienste sind für das Zusammenwirken und die Verwaltung von Business Objects in einem
Anwendungssystem unerläßlich:

Transparentes Speichern von Business Objects („Persistence Service“)

Dienste zum Suchen, Erzeugen und Löschen von Business Objects („LifeCycle Services“)

Verwaltung von Transaktionen („Transaction Service“)

Benachrichtigungsdienst zwischen Business Objects („Event Service“)

Verwaltung von BO-Beziehungen („Relationship Service“)

Parametrisierung von Business Objects („Property Service“)

Verwaltung von Mengen von Business Objects („Collection Service“) und Bereitstellung
entsprechender Iteratoren
III.2.4.1. BO-Manager - Framework und BO-Persistence Service
Ein Business Object kann sich nicht selbst erzeugen oder suchen, genausowenig kann die Verwaltung
von Transaktionen ausschließlich den Business Objects überlassen werden, da in der Regel mehrere
Business Objects an einer Transaktion teilnehmen. Für die Realisierung dieser Dienste sind also nicht
nur BO-spezifische, sondern auch BO-übergreifende Schnittstellen notwendig.
Wir werden diese Schnittstellen und ihre Implementierungen unter dem Begriff BO-Manager Framework zusammenfassen. In den meisten Fällen existiert in derartigen Frameworks ein Objekt als
zentrale Anlaufstelle für Management-Funktionen. Wir werden im folgenden dafür einheitlich den
Begriff BO-Manager verwenden. Beispiele für BO-Manager sind:

Container in Enterprise JavaBeans [xiii]

BaseFactory/Container in SanFrancisco [xiv]

TypeManager in der Interoperability Spezifikation [ix]
Das BO-Manager - Framework ist für die folgenden Aufgaben zuständig:

Transaction-Management und Resource-Management (im Sinne eines Object Transaction
Monitors)

Bereitstellung von Schnittstellen zum Suchen bzw. Erzeugen von Business Objects

Unterstützung bei der Speicherung von Business Objects


Beschaffung von Meta-Informationen zu einem Business Object, wie sie zum Beispiel zur
Implementierung von Trader-Services benötigt werden
Bereitstellung von Security- und Licensing- Mechanismen
Das BO-Manager-Framework stellt also den Lebensraum von Business Objects zur Verfügung. Im
allgemeinen setzt die Implementierung der oben angeführten Funktionen eine enge Kooperation
zwischen Business Objects und BO-Manager-Framework voraus.
Eine ebenfalls enge Kooperation besteht zwischen Business Objects bzw. BO-Manager - Framework
und dem BO-Persistence Service. Der BO-Persistence Service bildet die Schnittstelle zwischen
54
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Datenbank und Business Object und ist für die folgenden Aufgaben zuständig (siehe Abschnitt
III.2.4.3):

Abbildung von Datenbankstrukturen in Objektstrukturen (Schema - Mapping)

Kapselung des Zugriffs auf unterschiedliche Datenquellen

Bereitstellung von Suchmechanismen

Bereitstellung von Sperrverfahren bei konkurrierenden Zugriffen
Als Datenquellen sollten grundsätzlich berücksichtigt werden:

Relationale Datenbanken

Hierarchische Datenbanken

Objektorientierte Datenbanken

CICS- oder IMS-Transaktionen

Dateisysteme
Die Kooperation zwischen Business Objects, BO-Manager - Framework und BO-Persistence Service
wird durch Schnittstellenvereinbarungen geregelt, für die wir, in Anlehnung an Enterprise JavaBeans,
im weiteren den Begriff Contracts verwenden (siehe Abbildung 26).
Die Vereinbarungen, die über Contracts geregelt werden, sind abhängig von der jeweiligen Aufgabe.
Elemente dieser Contracts werden deshalb bei der Darstellung der Dienste in den folgenden
Abschnitten beschrieben.
Business
Object
BOPersistenceService
BO - Manager -Framework
Abbildung 26: Contracts zwischen Business Objects, BO-Manager - Framework und BO-Persistence Service
Kompatibilität mit CORBA Services
Business Objects, die für unterschiedliche BO-Manager - Frameworks entwickelt wurden, können in
der Regel nicht einfach ausgetauscht werden. Allerdings ist eine Kommunikation zwischen Business
Objects unterschiedlicher Frameworks über CORBA-ORBs möglich, sofern die im BO-Manager Framework realisierten Dienste CORBA-kompatibel sind.
Um Interoperabilität über Framework-Grenzen hinaus zu gewährleisten, ist mindestens die
Kompatibilität folgender Dienste erforderlich:
© GDV 1999
55
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Dienste des Frameworks
CORBA Service
Erzeugen und Löschen von Business Objects
Life Cycle Service
Transaktionsmanagement
Transaction Service
Benachrichtigungsdienst zwischen Business Event Service
Objects
Verwaltung von
Business Objects
Beziehungen
zwischen Relationship Service
Tabelle 7 : Kompatibilität der Dienste des BO-Frameworks und der CORBA Services
Darüber hinaus sollten BO-Management - Frameworks die CORBA Naming und Trading Services zur
Identifikation und Suche von Diensten und Business Objects, sowie den Licensing und Security
Service unterstützen.
III.2.4.2. Transparenter Zugriff auf Methoden eines Business Objects
Für das Anwendungsprogramm ist ein Zugriff auf die Methoden eines Business Objects jederzeit über
die Objektreferenz möglich, unabhängig davon, wo sich das Business Objekt befindet. Dies gilt auch
dann, wenn das Business Object in einer Datenbank gespeichert ist und zuerst geladen werden muß.
Während der Object Request Broker für die Ortstransparenz sorgt, ist das BO-Manager - Framework
dafür zuständig, daß ein noch gespeichertes oder ausgelagertes Objekt in den aktiven Zustand versetzt
wird, bevor ein Methodenaufruf ausgeführt werden kann. Im allgemeinen wird deshalb das BOManager - Framework ein Proxy-Objekt zur Verfügung stellen, das in seiner Schnittstelle alle
Methoden des Business Objects repräsentiert. Das Proxy-Object veranlasst gegebenfalls das Laden des
Business Objects, bevor die Ausführung einer Methode an das Business Object weitergeleitet wird.
Für das Anwendungsprogramm ist das Proxy-Object völlig unsichtbar.
Anwendung
Business
Object
BOPersistenceService
BO - Manager -Framework
Proxy-Objekt
Abbildung 27: Proxy-Objekte für Business Objects
III.2.4.3. Transparentes Speichern von Business Objects
Änderungen am Zustand eines Business Objects müssen bei Abschluß einer Transaktion gespeichert
werden, ohne daß ein expliziter Aufruf durch das Anwendungsprogramm notwendig ist. Auch Art und
Ort des Speichermediums sollten zumindest für den Anwender eines Business Objects transparent
sein, im allgemeinen auch für das Business Object selbst.
56
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Zur Erfüllung dieser Anforderungen ist eine Kooperation zwischen BO-Manager - Framework,
Business Objects und dem BO-Persistence Service notwendig. Da CORBA selbst noch keine
durchgängige Spezifikation dieses Zusammenspiels bietet, sind dem Austausch von Business Objects
derzeit enge Grenzen gesetzt.
Folgende grundlegenden Anforderungen müssen die Contracts zwischen den beteiligten Komponenten
erfüllen:
Contract zwischen BO-Manager - Framework und Business Object

Da Business Objects auch in Umgebungen mit eingesetzt werden müssen, die auf Basis
unterschiedlicher BO- Manager - Frameworks arbeiten (z.B. Außendienst-Labtops und
Bestandsführung), sollten Business Objects und BO-Manager - Frameworks zwei unterschiedliche
Persistenzstrategien unterstützen:
 Das Business Object kommuniziert direkt mit dem Persistence Service.
Der BO - Manager initiiert lediglich das Laden bzw. Speichern durch den Aufruf
einer allgemeinen load/store - Methode. Das Business Object ist auch für die
Generierung der Objektreferenz zuständig (ggf. unterstützt durch Hilfsfunktionen des
BO-Manager - Frameworks).
 Das BO-Manager Framework übernimmt die Kommunikation mit dem Persistence
Service.
In diesem Fall muß das Business Object seinen Zustand in standardisierter Form dem
BO-Manager zur Verfügung stellen, z.B. durch Implementierung einer serializeMethode. Der BO-Manager ist für die Generierung der Objektreferenz zuständig.
Alternativ dazu ist auch die direkte Übergabe des Business Objects an den Persistence
Service möglich, sofern dieser in der Lage ist, anhand von Metainformationen die
Speicherung des Zustands selbst vorzunehmen (Persistence Framework).


Das Business Object muß sich beim BO-Manager registrieren, damit es an Transaktionen
teilnehmen kann.
Das Business Object muß die Caching-Mechanismen des BO-Manager-Framework unterstützen.
Für große Anwendungssysteme sind Mechanismen notwendig, aktive Business Objects temporär
auszulagern und bei Bedarf wieder zu aktivieren. Das Business Object muß dafür vorgesehene
Schnittstellen unterstützen.
Contract mit dem BO-Persistence Service
Je nach Persistenzstrategie muß das Business Object selbst oder der BO-Manager mit dem BOPersistence Service kooperieren.
Der BO-Persistence Service muß auf Basis weniger und einfacher Schnittstellen die folgende
Funktionalität bereitstellen:



Abbildungsfunktionen (dynamisch oder generierbar) für die Abbildung der Objektzustände auf die
Speicherstruktur
Bereitstellung einer eindeutigen, persistenten Objekt-ID.
Die persistente Objekt-ID wird zur Generierung der Objektreferenz eines Business Objects
benötigt.
Elementare Zugriffsfunktionen über Schlüssel und persistenter Objekt-ID.
© GDV 1999
57
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Darüber hinaus muß der BO-Persistence Service CORBA bzw. X/Open - konforme Schnittstellen für
das Transaktionsmanagement dem BO-Manager - Framework zur Verfügung stellen.
Beispiel
Das folgende Beispiel illustriert das Zusammenspiel zwischen Business Object, BO-Manager und BO-Persistence
Service für den Fall, daß das Business Object selbst die Persistenz initiiert.
1.
Die Anwedung ruft die Methode getAblaufdatum des EBO Vertrag auf. Vertrag wird repräsentiert durch ein
Proxy-Object.
2.
Da das EBO Vertrag nicht im Speicher vorhanden ist, erzeugt das Proxy-Objekt eine neue Instanz von Vertrag
und übergibt dieser die Objektreferenz.
3.
Das Proxy-Objekt ruft die load-Methode von Vertrag auf.
4.
Vertrag beauftragt den BO-Persistence Service, die Daten zu laden
5.
Das Proxy-Objekt ruft die Methode getAblaufdatum auf und liefert das Ergebnis an die Anwendung zurück.
Anwendung
Proxy-Objekt
Vertrag
BO-Persistence Service
create
EBO
Vertrag
getAblaufdatum
load
loadFromDB
getAblaufdatum
III.2.4.4. Suchen von Business Objects
Aus Sicht der Anwendung ist das Suchen von Business Objects die Aufgabe des BO-ManagerFrameworks. Es muß für jeden Typ von Business Objects eine Finder - Schnittstelle zur Verfügung
stellen.
Die Finder - Schnittstelle sollte die folgenden Arten von Suchoperationen unterstützen:


58
Suchen anhand des Schlüssels
Aufruf einer Finder-Methode der Art findByKey(IN Schlüssel). Diese Methode liefert eine
Objektreferenz für das gesuchte Business Object.
Suchen über Merkmale eines Business Objects
Der Finder muß eine Schnittstelle für die Übergabe von Suchkriterien oder Such-Ausdrücken zur
Verfügung stellen oder eine Liste vorgefertigter Anfragen, die durch Angabe der Werte für
Suchvariablen präzisiert werden kann.
Bei mehrdeutigen Ergebnissen liefert der Finder anstelle der Objektreferenz einen Iterator zurück,
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
mit dessen Hilfe über die Ergebnismenge navigiert werden kann. Auch die direkte Übergabe einer
Liste von Objektreferenzen ist bei kleinen Mengen möglich.
Hinweis: In der Versicherungswirtschaft steht man häufig vor dem Problem, daß der Schlüssel zwar grundsätzlich eindeutig
ist, daß aber zu einem Business Object mehrere Versionen existieren. Möchte man nicht immer alle Versionen des Objects
laden, so kann z.B. die o.a. Finder-Methode durch eine Methode findByKey(IN Schlüssel, Gültigkeitsdatum) ergänzt werden.
Damit wird nur die Version des BO erzeugt, die zum angegebenen Datum gültig war.
Contracts
Die Contracts zwischen BO-Manager - Framework, BO-Persistence Service und Business Object sind
stark abhängig von der Implementierung des BO-Manager - Frameworks und des BO-Persistence
Service.
Folgende Varianten sind möglich:



Das Business Object stellt dem Finder entsprechende Suchfunktionen über ein Interface zur
Verfügung.
Dies ist möglich, wenn das Business Object selbst die Kommunikation mit dem Persistence Service
übernimmt.
Der BO-Persistence Service verfügt über eine objektorientierte Abfragesprache wie OQL oder
stellt für jeden Objekttyp Standardabfragen zur Verfügung. Der Persistence Service liefert
Objektreferenzen der gefundenen Business Objects.
Diese Variante ist insbesondere beim Einsatz von objektorientierten Datenbanken oder Persistence
- Frameworks geeignet.
Business Object und BO-Persistence Service stellen dem Finder Metainformationen zur
Verfügung, aus denen dieser Suchanfragen generieren kann, die der Persistence Service ausführt.
Diese Variante eignet sich für den direkten Zugriff auf relationale Datenbanken oder HostTransaktionen.
III.2.4.5. Erzeugen von Business Objects
Aus Sicht der Anwendung ist das Erzeugen von Business Objects die Aufgabe des BO-ManagerFrameworks. Es muß für jeden Typ von Business Objects eine Factory - Schnittstelle zur Verfügung
stellen (vgl. Factory-Entwurfsmuster [xii]). Die Factory erzeugt eine Instanz des Business Objects und
liefert eine Objektreferenz an die Anwendung zurück.
Der Grundmechanismus für die Erzeugung eines Business Objects ist der CORBA Life Cylce Service
und, bei verbundenen Business Objects, der Compound Life Cycle Service. Das BO-Manager Framework kapselt die Schnittstelle zu diesen Services und ergänzt sie teilweise, z.B. durch die
Übergabe von Kontextinformationen an das erzeugte Business Object oder durch die Zuordnung eines
Schlüssels. Um die Kompatibilität mit dem CORBA LifeCycle Service zu gewährleisten, sollte das
BO-Manager - Framework die Standard CORBA - Factory Interfaces weiterhin unterstützen.
III.2.4.6. Löschen von Business Objects
Jedes Business Object muß über eine standardisierte Delete - Schnittstelle verfügen, mit der es
gelöscht werden kann. Das Löschen der zugehörigen Datenquelle kann alternativ durch das Business
Object selbst oder durch das BO-Manager - Framework erfolgen (vgl. Abschnitt III.2.4.3).
© GDV 1999
59
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Unabhängig davon obliegt dem BO-Manager - Framework die Transaktionssicherung der
Löschoperation.
Die Objektreferenz wird gelöscht und steht im folgenden nicht mehr zur Verfügung. Der BO-Manager
ist für das Ressourcenmanagement und somit für die Freigabe der Objektressourcen zuständig. Sollten
in anderen Business Objects Referenzen auf das gelöschte BO bestehen, so wird diese Referenz beim
nächsten Zugriff auf das Business Object ungültig.
Der Benachrichtigungsdienst (vgl. Abschnitt III.2.4.10) stellt einen Eventtyp zur Verfügung, der die
automatische Benachrichtigung verbundener Business Objects bei Löschoperationen erlaubt.
III.2.4.7. Transaktionsmanagement
Business Objects nehmen in der Regel an Transaktionen teil, d.h. Änderungen ihres Zustandes müssen
gemeinsam mit anderen Business Objects festgeschrieben bzw. rückgängig gemacht werden. Ein
Business Object kann darüber hinaus gleichzeitig von mehreren Benutzern angefordert werden.
Es ist Aufgabe des BO-Manager - Frameworks, die Konsistenz von Business Objects innerhalb einer
Transaktion zu garantieren und parallele Anforderungen an ein Business Object zu verwalten.
Transaktionsmanagement setzt eine enge Kooperation zwischen Framework, Business Object und BOPersistence Service voraus. Dieses enge Zusammenspiel geht über die CORBA-Spezifikationen zum
Transaction und Concurrency Service hinaus und ist momentan noch nicht standardisiert. An dieser
Stelle können deshalb nur die grundlegenden Mechanismen, die die Beteiligten zur Verfügung stellen
müssen, dargestellt werden.
In dem hier beschriebenen Transaktionsmodell gehen wir von flachen Transaktionen aus.
Contract zwischen Business Object und BO-Manager - Framework
Die folgenden Elemente sind Bestandteil des Contracts zwischen Business Object und BO-Manager Framework:

Festlegung des Transaktionsverhaltens
Generell sollten mindestens die folgenden Transaktionsmodi unterstützt werden:
 BO nimmt grundsätzlich nicht an Transaktionen teil
 BO muß immer transaktionsgesichert bearbeitet werden
 BO verwaltet seine eigene Transaktion (d.h. andere Business Objects sind nicht in der
selben Transaktionsklammer enthalten)
In diesem Fall muß der BO-Manager dem Business Object einen eigenen
Transaktionskontext zur Verfügung stellen.

Der BO-Manager muß ein BO, daß an einer Transaktion teilnimmt, vor dem Einleiten des
Transaktionsendes und nach Abschluß der Transaktion informieren.
Contract zwischen Business Object und BO-Manager - Framework

60
Der BO-Persistence Service bzw. die zugrundeliegenden Datenbanken müssen Commit/Rollback Protokolle (X/Open) unterstützen
© GDV 1999
Das objektorientierte technische Referenzmodell

Die Systemarchitektur der VAA
Sperrmechanismen des Persistence Service müssen sinnvoll mit dem Transaktionsmanagement
zusammenarbeiten.
Transparenz bezüglich paraller Zugriffe
Die Tatsache, daß ein Business Object in einer Mehrbenutzerumgebung eingesetzt ist, muß sowohl für
den Business Object - Entwickler, als auch für die Anwendung transparent sein. Das in Abschnitt
III.2.4.2 beschriebene Proxy-Objekt des BO-Manager - Frameworks dient dazu, gleichzeitige
Anforderungen an ein Business Object zu serialisieren oder gegebenenfalls. mehrere Instanzen eines
Business Objects zu erzeugen. Damit kann ein Business Object als „Single User“ - Objekt realisiert
werden.
III.2.4.8. Verwalten von BO-Beziehungen
Verbindungen zwischen Business Objects können auf verschiedene Weise gestaltet werden:



Durch direkte Fremdschlüsselbeziehungen auf Basis der Objektreferenz
Das verbundene Business Object speichert die Objektreferenz als Attribut
Durch direkte Fremdschlüsselbeziehungen auf Basis des Schlüssels
Das verbundene Business Object speichert den Schlüssel als Attribut
Über den CORBA Relationship Service (vgl. Kapitel II.1.3.3) bzw. seine Abbildung im BOManagement Framework
Direkte Fremdschlüsselbeziehungen über die Objektreferenzen sind einfach und performant zu
realisieren, sind aber nicht in jedem Fall einsetzbar. Voraussetzung für ihren Einsatz ist die
Kompatibilität der Objektreferenzen zwischen den beteiligten Business Objects. Diese ist im
allgemeinen bei CORBA-basierten Systemen gegeben, nicht jedoch generell. Darüber hinaus kann es
sinnvoll sein, auf eine direkte Koppelung zu verzichten, zum Beispiel dann, wenn eine möglichst
große Unabhängigkeit zwischen Systemen gefordert ist.
Fremdschlüsselbeziehungen auf Basis der Schlüssel sind flexibler, was die Wahl der technologischen
Plattform der Verbindungspartner betrifft, erfordern aber einen größeren Aufwand bei der Navigation,
da aus dem Schlüssel zunächst die Objektreferenz ermittelt werden muß. Beide Varianten können bei
der Anbindung von Systemen gemischt werden: die Verbindungspartner halten eine Objektreferenz zu
Adaptern, die ihrerseits automatisch die Umsetzung auf die Objektreferenzen des anderen Systems
über Schlüssel besorgen (vgl. Abschnitt III.5).
Beziehungen auf Basis des Relationship Service sind für die folgenden Fälle besonders geeignet:

Bei mehr als zwei Beziehungspartnern (z.B. bei einer ternären Relation)

Bei n:m - Relationen

Bei Relationen, in denen die Verbindungspartner mehrere unterschiedliche Rollen einnehmen
können
Der Relationship Service erlaubt die Gestaltung komplexer Beziehungen, ohne daß diese durch die
beteiligten Business Objects selbst verwaltet werden müssen. Gleichzeitig lassen sich
wiederverwendbare Navigationsmechanismen aufbauen, die die Navigation durch ein Objektnetz
erlauben, ohne Kenntnis der Funktion beteiligter Business Objects.
© GDV 1999
61
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
III.2.4.9. Parametrisierung von Business Objects
Business Objects sind in der Regel Bestandteil von Komponenten. Eine wichtiger Aspekt bei der
Gestaltung von Komponenten ist die Unvorhersagbarkeit der tatsächlichen Einsatzumgebung.
Komponenten
(und
die
unterstützenden
Frameworks)
verfügen
deshalb
über
Konfigurationskomponenten und Parametrisierungsmöglichkeiten, die eine Anpassung an die
Einsatzumgebung ermöglichen (vgl. BeanDescriptor- und Customizer- Objekte in JavaBeans). Als
Bestandteile von Komponenten müssen Business Objects mindestens über die folgenden
grundlegenden Parametrisierungsmechanismen verfügen:

„Properties“ mit Standardzugriffsmethoden
Properties sind Attribute von Business Objects, die von außen über spezielle Zugriffsmethoden
gelesen bzw. geändert werden können. Die Zugriffsmethoden sind dabei universell und nicht BOspezifisch. In JavaBeans wird dies durch name patterns erreicht: zu einer Property mit dem Namen
XXX gehören die Zugriffsmethoden getXXX bzw. setXXX. Durch Properties können nicht nur
aktuelle Zustände eine Business Objects verändert werden, sondern auch dessen generelle
Funktionsweise.

„Active Properties“
Sogenannte „Active Properties“ lösen bei einer Wertänderung ein Event aus, das über assozierte
EventListener an andere Business Objects verteilt werden kann. Durch diesen Mechansimus
können vorab nicht bekannte Abhängigkeiten zwischen Business Objects (in unterschiedlichen
Komponenten) geschaffen werden, ohne daß in die Funktionalität eines Business Objects
eingegriffen werden muß
Die Einbettung von Business Objects in ein BO-Manager - Framework erfolgt im allgemeinen
ebenfalls durch die Variation von Konfigurationsparametern mittels vordefnierter Methoden und
Schnittstellen (vgl. DeploymentDescriptor in Enterprise JavaBeans). Diese Verfahren sind jedoch
nicht standardisiert. Wichtige Konfigurationsparameter dieser Art sind z.B.:


Festlegungen über die Art der Speicherung (Wahl der Datenbank, des Ortes usw.)
Festlegungen über die Art des Transaktionsmanagments (ohne Transaktionskontext, BO-eigener
Transaktionskontext usw.)

Festlegung über Sicherheitsverfahren

Festlegungen über die Suchstrategien, Namenskontext usw.
III.2.4.10. Benachrichtigungsdienst zwischen Business Objects
Basis des Benachrichtigungsdienstes ist der CORBA Event Service. Dieser stellt jedoch lediglich die
Infrastruktur für die Übermittlung von Events zur Verfügung, definiert jedoch keine Event-Typen.
Bestehende BO-Management - Frameworks wie San Francisco und (Enterprise) JavaBeans definieren
entsprechende Eventtypen, es gibt allerdings noch keine übergreifenden Standards. Generell sollte
jedes Framework die folgenden Eventtypen unterstützen:


62
„Property Changed Events“
Events, die gefeuert werden, wenn sich eine Eigenschaft („Property“) eines Business Objects
ändert
LifeCyle Events
Events, die gefeuert werden, wenn ein Business Object erzeugt oder gelöscht wird. Dabei sollten
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Schnittstellen definiert sein, die im Zusammenhang mit dem CORBA Relationship Service
automatisch Verbindungspartner benachrichtigen.

Transaction Events
Events, die zum Abschluß oder Abbruch einen Transaktion gefeuert werden. Insbesondere
sogenannte Pre-Commit - Events erlauben es verbundenen Business Objects, ihre jeweiligen Stati
vor dem Commit zu konsolidieren.
Generell muß es möglich sein, Events vor oder nach Eintreten des auslösenden Ereignisses zu
versenden.
III.2.5. Business Objects und Komponenten
III.2.5.1. Vom Business Object zur Komponente
Im Rahmen der Dienstespezifikation und der Beschreibung des BO-Manager - Frameworks wurden
bereits die Bedingungen an die „Umwelt“ eines Business Objects genannt, die unbedingt für eine
Interoperabilität erforderlich sind:



Interoperable Business Objects müssen die Schnittstellen für Events, Relationships usw.
implementieren
Zwischen Business Objects, BO-Manager - Framework und BO-Persistence Service müssen
Contracts für gemeinsame Aufgaben wie Transaktionsmanagement und Datenspeicherung
existieren
Business Objects, die auf Basis unterschiedlicher Frameworks implementiert wurden, können
miteinander kooperieren, wenn die wichtigsten CORBA-Services (vgl. Abschnitt III.2.4.1) wie
Naming, Transactions, Events usw. unterstützt werden.
Um ein Business Object oder eine Gruppe von Business Objects in eine auslieferbare SoftwareKomponente zu verwandeln, sind noch eine Reihe weiterer Hilfsmittel erforderlich:


Werkzeuge, um BO-Komponenten an die Systemumgebung wie Datenbanken, Security-Systeme
usw. anzupassen
Werkzeuge, um Komponenten-Eigenschaften an die fachlichen Anforderungen des Zielsystems
anzupassen und die Komponente mit anderen zu verbinden
Im allgemeinen liefern die Hersteller von Komponenten - Frameworks die entsprechenden Werkzeuge
bzw. die Hilfsmittel zu ihrer Erstellung mit (z.B. Enterprise JavaBeans, siehe Kapitel IV.4).
Komponenten unterschiedlicher Frameworks erfordern jedoch auch unterschiedliche Werkzeuge.
Trotz der in Aussicht gestellten Konvergenz von Architekturen wie Enterprise JavaBeans,
SanFrancisco und CORBABeans sind dem freien Austausch von BO-Komponenten also noch
Grenzen gesetzt.
© GDV 1999
63
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Konfigurations
Werkzeuge
Business
Object
Business
Object
Business
Object
Komponente 2
Komponente 1
BO - Manager -Framework (Komponenten Framework)
Abbildung 28: Business Objects als Komponenten
Die folgende Abbildung zeigt ein heterogenes, komponentenorientiertes System. Ein Mindestmaß an
gemeinsamen technischen Diensten ist für die Interoperabilität der Komponenten erforderlich: neben
den CORBA Services unter Umständen auch Präsentationsumgebung und Datenbanksysteme.
Konfigurationswerkzeuge für Framework 1
Konfigurationswerkzeuge für Framework 2
Business
Object
Business
Object
Business
Object
Business
Object
Komponente 1
Business
Object
Komponente 1
Komponente 2
Business
Object
Komponente 2
BO - Manager - Framework 1
BO - Manager - Framework 2
• CORBA Services
• Präsentation
• Datenbanken
Technische Dienste
Object Request Broker
Abbildung 29: Heterogene komponentenorientierte Systeme
III.2.5.2. Allgemeine Typen von Objekten
Die zwischen Business Objects ausgetauschten Parameter sind Objekttypen die standardisiert sein
müssen, damit BO-Komponenten unterschiedlicher Hersteller kooperieren können. Dabei gibt es
verschiedene Qualitäten von Typen, die in Beziehung zur Mächtigkeit der Komponenten stehen:



Technical Interface Types, die sich aus der Definition der CORBA-Dienste und der Dienste der
Systemarchitektur ergeben, z.B. Key, Exceptions, State, Event.
Common Business Domain Types, z.B. Datum, Uhrzeit, Währung, Organisationseinheit, Firma,
Adresse, Konto.
Insurance Domain Types, z.B. Partner, Termin, Ereignis, Schaden, Produkt, Vertrag.
Diese Typen bauen aufeinander auf und stellen eine zunehmende Spezialisierung dar. Anhand dieser
Typ-Hierarchie ist die Definition von Kompatibilitätsebenen unterschiedlicher Komponentenmodelle
möglich:
64
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
1. Die Kompatibilität der Technical Interface Types gewährleistet die prinzipielle
Interoperabilität aus technischer Sicht. Auf dieser Ebene müssen alle fachlichen
Informationen, die zwischen Business Objects ausgetauscht werden, durch eine Folge
elementarer Datentypen ausgedrückt werden. Die Zufälligkeit, mit der diese Folgen definiert
sind, macht die direkte Interoperabilität von Business Objects unwahrscheinlich.
2. Die Kompatibilität der Common Business Domain Types erlaubt bereits den Austausch
einfacher fachlicher Objekte, komplexere Typen wie zum Beispiel Schadenmeldung müssen
noch in elementarere Bestandteile zerlegt werden.
3. Die Kompatibilität der Insurance Domain Types ermöglicht den direkten Austausch von
Komponenten ohne Anpassungen. Auf dieser Ebene können BO-Komponenten verschiedener
Hersteller Informationen wie Schadenmeldung, Vertragsklausel usw. austauschen.
Die folgende Abbildung zeigt die Kompatibilitätsebenen, sowie bestehende Ansätze verschiedener
Hersteller und Gremien durch entsprechende Plattformen und Standards Interoperabilität zu erzielen.
Insurance
Domain
Types
•VAA Fachliches Referenzmodell
Common Business
Domain Types
•OMG BODTF* und FDTF**
•IBM SanFrancisco
Technical Interface Types
•Enterprise JavaBeans
•CORBA Beans
•IBM SanFrancisco
•ActiveX/DNA
* Business Objects Domain Task Force
** Financial Domain Task Force
Abbildung 30: Kompatibilitätsebenen
Das fachliche Referenzmodell der VAA gewährleistet die maximale Kompatibilität von
Komponenten. Für „Plug & Play“ - Kompatibilität ist jedoch auch die gleiche Wahl der Plattform für
die tiefer liegenden Ebenen erforderlich.
III.3. Präsentationskomponente
Model-View-Controller
Zur Darstellung der Informationen von Business Objects werden Sichten (Views) benötigt. Im Sinne
des MVC-Konzeptes (Model-View-Controller) ist eine View die Darstellung von Informationen
eines Business Objects. Ein Business Object kann durch mehrere Views visualisiert werden, die
unterschiedliche Sichtweisen auf das Business Object darstellen. Business Objects sind unabhängig
von Präsentations- und Benutzerschnittstellen und wissen nichts über ihre Präsentationen.
© GDV 1999
65
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Der Controller ist für die Interaktion zwischen Benutzer und Anwendung verantwortlich. Er stellt den
Kontext dar, in dem verschiedene Views und Modelle zueinander stehen. Darüber hinaus veranlaßt er
aufgrund von Benutzereingaben das Business Object zu Änderungen. Zu jedem Zeitpunkt ist genau
ein Controller für die Interaktionsverarbeitung zuständig.
Abbildung 31: Zusammenhänge im MVC-Konzept
Durch die Entkopplung muß sich das Business Object nicht um seine Präsentation kümmern. Es
können mehrere Views zu einem Business Object verwendet werden und die Views können verändert
werden, ohne das Business Object zu beeinflussen. Ein Controller ist immer genau einer View
zugeordnet. Hier herrscht eine enge Kopplung. View und Controller werden als Delegate (Delegierter
des Business Objects) oder Benutzerschnittstelle bezeichnet.
In Abbildung 31 werden die Zusammenhänge dargestellt. Benutzereingaben werden vom Controller
entgegengenommen und Änderungen an das Business Object weitergeleitet. Aufgrund von
Mitteilungen des Controllers oder anderer Objekte führt das Business Object die entsprechenden
Änderungen durch und benachrichtigt die von ihm abhängigen Views über einen generellen Event
Mechanismus. Die Views stellen nach Rückfrage beim Business Object die Informationen dar.
Business Objects und Präsentationskomponente
Im Sinne der VAA werden die Aufgaben des Views und des Controllers in der
Präsentationskomponente zusammengefaßt. Diese Ebene übernimmt eigenständig alle Aufgaben, die
zur Präsentation von Business Objects benötigt werden.
Jedes Business Object kann sich in einer oder mehreren Präsentationskomponenten darstellen.
Präsentationskomponenten sind eng an das zugehörige Business Object gekoppelt. In der Regel haben
Business Objects eine Standard-Präsentationskomponente. Unter Umständen kann auch gänzlich auf
eine Präsentation verzichtet werden. Dies trifft beispielsweise auf Process Business Objects zu, die
Hintergrundprozesse darstellen (z.B. Jahreshauptfolge).
66
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Es muß grundsätzlich möglich sein, bei einem Business Object Präsentationskomponenten
auszutauschen oder hinzuzufügen, bzw. die Präsentationskomponente zu konfigurieren.
Wünschenswert ist ein Grundgerüst für ein Standardprotokoll zwischen Business Object und
Präsentationskomponente sowie Präsentationskomponenten mit generischen Eigenschaften. So können
beispielsweise durch die Konfigurierbarkeit bzw. Generik Präsentationskomponenten an
unternehmesspezifische Standards (Kopf- und Fußzeilen, Titel, usw.) angepaßt werden. Darüber
hinaus sollte es möglich sein, mit Hilfe eines Standardprotokolls unternehmensspezifische
Präsentationskomponenten einem gekauften Business Object hinzuzufügen und diesem das
unternehmensspezifische „Look & Feel“ zu verleihen.
View
View
Controller
Controller
Business
Object
Business
Object
Business
Object
Komponente 2
Komponente 1
BO - Manager -Framework (Komponenten Framework)
Abbildung 32: Business Objects und Präsentationskomponenten
Baukastenprinzip
Ein weiterer Aspekt der Präsentationskomponente ist das „Baukastenprinzip“ von Präsentationen.
Einzelnen Präsentationskomponenten, die einem Business Object zugeordnet sind, sollten analog der
Datennormalisierung redundanzfrei sein, d.h. eine Präsentationskomponente kann sich aus anderen
zusammensetzten (siehe Abbildung 33).
© GDV 1999
67
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Toolbar
UserInfo
Panel
NameInfo
Panel
ButtonBar
Abbildung 33: Konstruktionsprinzip von Präsentationen
Die Präsentationen zerfallen also in kleinere Teile, wobei dies jedoch nicht impliziert, daß es zu jedem
Attribut eines Business Objects eine Präsentation geben muß (vgl. Composite-Entwurfsmuster [x]).
Die Granularität der Präsentation variiert je nach Modellierung (d.h. zwischen allen Attributen eines
Business Objects bis hin zum Anzeigen einzelner Attribute). Ziel ist es, eine Wiederverwendbarkeit
von Präsentationen und eine bessere Wartbarkeit zu erreichen.
Präsentationen, die ein EBO zur Darstellung und Anbindung von Attributen und Methoden benötigen,
können auch direkt dem EBO zugeordnet sein. Dabei wird ein EBO (sofern es überhaupt
Präsentationen benötigt) typischerweise mehrere Präsentationen besitzen. Für den
Versicherungsnehmer könnte es zum Beispiel eine Präsentation für die Pflege seiner Anschrift geben
und gleichzeitig eine Präsentation um den Versicherungsnehmer im Rahmen eines Vertrages oder
eines Schadenfalls auszuweisen. Wichtig ist dabei, daß der Zugriff und die Bearbeitung eines EBO nur
über die ihm unmittelbar zugeordneten (elementaren) Präsentationen erfolgt. Komplexere und
weitergehende Präsentationen, die auf spezielle Geschäftsvorgänge (PBO) zugeschnitten sind,
verwenden für die Anbindung der beteiligten EBOs nur noch deren vorgefertigte Präsentationen.
Vorteil dieser Vorgehensweise ist, daß Änderungen und Korrekturen einheitlich durchgeführt werden
können und die Darstellung in allen Anwendungen konsistent ist.
III.4. Verteilung von Präsentation und Business Object
In einer verteilten Umgebung mit grafischer Oberfläche kommunizieren die auf dem Client
befindlichen Präsentationskomponenten mit den Business Objects auf einem oder mehreren
Applikationsservern, die Speicherung kann auf einem separaten Datenbankserver erfolgen (Three-Tier
Architecture).
Je nach Arbeitsumfeld der Anwendung sind unterschiedliche Clientkonfigurationen sinnvoll, die
unterschiedlichen
Kommunikationsaufwand
bedeuten
und
damit
verschiedene
Datenübertragungsstrategien erforderlich machen.
68
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
Fat Client
Beim Fat Client befinden sich Präsentation und Business Objects komplett auf dem Client. Nur die
Datenhaltung findet auf einem entfernten Server statt.
Präsentations
Präsentations
Komponente
Komponente
Business
Business
Object
Object
Fat Client
BO-Manager Framework
BO-Persistence
BO-PersistenceService
Service
Server
Abbildung 34: Fat Client
Thin Clients
Thin Clients enthalten die Präsentationskomponente inklusive Controller und kommunizieren mit
entfernten Business Objects auf den Applikationsservern.
Präsentations
Präsentations
Komponente
Komponente
Business
Business
Object
Object
Thin Client
Server
BO-Manager Framework
BO-Persistence
BO-PersistenceService
Service
Abbildung 35: Thin Client
Ultra Thin Clients
Ultra Thin Clients übernehmen reine Darstellungsfunktionen. Controller befinden sich bereits auf
einem Applikationsserver, der seinerseits mit anderen Servern kommunizieren kann. Bei Ultra Thin
Client Architekturen muß eine Optimierung bezüglich der Kommunikationshäufigkeit vorgenommen
werden. Andernfalls ist die Performance dieser Architektur nicht akzeptabel, da die Anzahl der
Nachrichtenpakete zwischen View und Controller insbesondere bei zusammengesetzten
Präsentationskomponenten stark ansteigt (siehe Abbildung).
© GDV 1999
69
Die Systemarchitektur der VAA
Server
Das objektorientierte technische Referenzmodell
View
View
View
View
Controller
Controller
Controller
Controller
BO
BO
BO
BO
UltraThin
Client
BO-Manager - Framework
Abbildung 36: Ultra Thin Client
Die Systemarchitektur der VAA ist flexibel und ermöglicht alle diese Szenarien. Damit eine
Verteilung möglich wird, wird CORBA als Kommunikationskanal genutzt. Es macht jedoch Sinn,
nicht direkt die Objekte mit Hilfe von CORBA IDL zu verteilen, sondern ihre Funktionalität vorher in
Form von Wrappern oder Smart Proxies zu kapseln.
III.5. Kopplung von Systemen
Die bisher definierten Interaktionsmechanismen zwischen Business Objects beziehungsweise
Komponenten betrachteten die Kopplung unter dem Gesichtspunkt einer einheitlichen
Systemarchitektur für alle Komponenten und Business Objects. Im allgemeinen ist diese
Voraussetzung aber nicht gegeben. Neben bereits bestehenden Legacy-Anwendungen, die
eingebunden werden müssen, sind auch kommerzielle Systeme mit abweichender Systemarchitektur
zu berücksichtigen.
Selbst wenn eine vollständige Kompatibilität gegeben ist, kann es wünschenswert sein, Business
Objects und Komponenten unterschiedlicher Systeme voneinander so weit wie möglich zu entkoppeln,
um Anpassungen bei Änderungen oder bei Systemwechsel zu minimieren.
In vielen Fällen stellt ein anzubindendes System Informationen oder Funktionalität nicht in der
gewünschten Form zur Verfügung, die erforderlichen Anpassungen möchte man jedoch in keinem der
beiden Systeme vornehmen, sondern in einer getrennten „Koppelungsschicht“.
Über die Definition von Interaktionsmechanismen auf Komponenten- und Business Object - Ebene
hinaus sind also Festlegungen für die Koppelung von Systemen notwendig. Dabei müssen zwei
unterschiedliche Aspekte betrachtet werden:

70
Entkoppelung und Anpassung von Funktionalität
Durch Entkopplung von Systemen sollen Anpassungskosten minimiert werden, die Anpassung der
Funktionalitäten soll gleichzeitig so erfolgen, daß keine oder nur geringe Eingriffe in die Systeme
selbst notwendig sind.
© GDV 1999
Das objektorientierte technische Referenzmodell

Die Systemarchitektur der VAA
Anpassungen der Systemarchitektur bzw. technischen Architektur
Systeme auf Basis einer anderen System- oder technischen Architektur müssen durch geeignete
Adaptoren an die VAA-Architektur angepasst werden.
III.5.1. Entkoppelung und Anpassung von Funktionalität
In der objektorientierten Literatur [x, xv, xvi] finden sich eine Reihe von Entwurfsmustern und
Verfahren zur Entkopplung von Teilmodellen bzw. Komponenten mit unterschiedlichen
Schwerpunkten. Die für die Koppelung voneinander unabhängig entwickelter Systeme geeignetsten
Muster sind:

Objekt-Adapter

Fassaden
Objekt-Adapter stellen die Funktionalität eines Objekts des Fremdsystems in anderer oder
erweiterter Form dar. Der Adapter ist in der Lage, Methodennamen und Parameter zu transformieren
und enthält gegebenenfalls auch funktionale Erweiterungen, die das Objekt selbst nicht bietet. Der
Objekt-Adapter hält eine Referenz des fremden Objektes, ist aber selbst im Fremdsystem nicht
bekannt. Für Schnittstellen, die in einem Fremdsystem durch einfache Objekte repräsentiert werden,
ist ein Objektadapter das geeignete Entwurfsmuster. Er erlaubt Anpassungen und Erweiterungen an
der Schnittstelle ohne daß das Fremdsystem angepaßt werden muß. Gleichzeitig kapselt er alle
schnittstellenspezifischen Besonderheiten.
Fassaden sind Objekte, die die extern benötigte Funktionalität eines Objektnetzes in einem einzigen
Schnittstellenobjekt zusammenfassen. Die Fassade sorgt für die Navigation durch das Objektnetz, faßt
Methodenaufrufe zusammen und sorgt gegebenenfalls dafür, daß Konsistenzbedingungen innerhalb
des Objektnetzes eingehalten werden. Fassaden sind im Vergleich zu Objekt-Adaptern in der Lage,
auch komplexe Schnittstellen zu kapseln und funktionell anzupassen und können grundsätzlich auf
beiden Seiten gekoppelter Systeme eingesetzt werden.
III.5.2. Anpassungen der System- bzw. technischen Architektur
Objekt-Adapter und Fassaden können nicht nur die fachliche Funktionalität eines Fremdsystems
integrieren, sondern sind auch dazu geeignet, Systemarchitekturen bzw. die zugehörigen Frameworks
aneinander anzupassen. So können durch Ableitung der Fassaden und Adapter von den Basisklassen
des Frameworks „fremde“ Business Objects so behandelt werden, als gehören sie zum eigenen
System. Dienste des Frameworks zum Erzeugen oder Suchen von Business-Objekten können ebenfalls
durch entsprechende Adapter auf die Dienste des Fremdsystems angepasst werden (siehe Abbildung
37). Die Systemarchitektur der VAA bietet gerade für diese Aufgaben eine gute Ausgangsbasis: auf
ihrer Grundlage ist der Entwurf eines frameworkunabhängigen Schnittstellenmodells zur Anpassung
unterschiedlicher Systeme möglich.
© GDV 1999
71
Die Systemarchitektur der VAA
vaaBO
Das objektorientierte technische Referenzmodell
vaaBOManager
xxBO
xxBOFactory
Annahme:
das Partnersystem verfügt
über eine Factory für alle BO
vaaPartnerMgr
(Objekt-Adapter)
xxPartner
vaaPartner
(Fassade)
xxPartnerRolle
Abbildung 37: Beispiel einer Systemanbindung durch Fassaden und Adapter
Der Aufwand für die Realisierung von Schnittstellen mittels Adaptern und Fassaden hängt deshalb
hauptsächlich von der Kompatibilität der technischen Architektur ab.
CORBA-basierte Systeme
CORBA-basierte Fremdsysteme oder Systeme, die über CORBA-Schnittstellen verfügen, bieten die
einfachsten Integrationsmöglichkeiten. Im wesentlichen müssen die höheren Dienste und Strukturen
der Systemarchitektur auf Basis der jeweils verwendeten Frameworks durch Adapter angepaßt
werden. Die für die nächsten Jahre erwartete Konvergenz zwischen Enterprise JavaBeans, CORBA
Beans und auch SanFrancisco wird den dafür notwendigen Aufwand weiter reduzieren, sofern eine
dieser Technologien Basis der Implementierung bildet (siehe Abbildung 38).
Konvergenz
der Architekturen
SanFrancisco
?
Enterprise
JavaBeans
CORBA
Component Model
1998
1999
2000
Abbildung 38: Konvergenz der Architekturen
Transaktionsmanagement
72
© GDV 1999
Das objektorientierte technische Referenzmodell
Die Systemarchitektur der VAA
In vielen Fällen stellt die Kooperation unterschiedlicher Transaktionsmanager bei der Integration von
Systemen ein Problem dar, weil ein übergreifender Transaktionskontext und damit ein gemeinsames
Commit/Rollback - Protokoll nicht definiert ist. Oft sind auch die Antwortzeiten bei synchroner
Kopplung zwischen Systemen unbefriedigend oder es können Deadlock-Situationen nicht vermieden
werden.
In diesen Fällen bieten sich asychrone Kopplungsverfahren an, wie sie auf Basis von Messaging Protokollen realisiert werden können. Wichtige Aspekte bei der Konzeption entsprechender Adapter
sind :



Definition eines Sitzungskontexts
Durch die Definition eines Sitzungskontext - Objekts können Sitzungsinformationen (Benutzer,
Berechtigungsschlüssel usw.) zwischen Transkationsmanagern ausgetauscht werden.
Deadlock Resolution
Es muß ein Verfahren definiert werden, das Deadlocks zwischen unterschiedlichen Systemen
auflöst.
Dispatch - Mechanismus
Der Zeitpunkt des Anstosses einer Transaktion im Fremdsystem sollte auf unterschiedliche Weise
definierbar sein:
 Über einen definierten Event-Typ
 Unmittelbar nach einer Transaktion
 Zeitgesteuert zu einer bestimmten Uhrzeit oder mit einer bestimmten
Verzögerung

Rückmeldungen
Rückmeldungen über den Erfolg oder Mißerfolg der angestossenen Transaktion erfolgen
sinnvollerweise über einen Event, dessen Empfänger der Systemadapter ist.
Beispiel: Anbindung eines Legacy - Buchhaltungssystems
Um beispielsweise ein Buchhaltungssystem, das als klassische Hostanwendung vorhanden ist, in die
Systemarchitektur der VAA zu integrieren, wird das Buchhaltungssystem durch die Komponente „Anbindung
Buchhaltung“ im System repräsentiert.
Die Komponente kennt u.a. die zwei Methoden setBuchung(KontoInformation) und getBuchung(KontoInformation).
Die Komponente selbst stellt einen Adapter zur Legacy-Anwendung dar und kann, je nach den technischen
Möglichkeiten in unterschiedlichen Transaktionsklammern ausgeführt werden:


Eine Transaktionsklammer über beide Systeme
Dies setzt eine entsprechende Zusammenarbeit der verwendeten Transaktionsmanager voraus.
Eine gemeinsame Transaktionsklammer nur für die Komponenten Schaden und Buchhaltung.
In diesem Fall wird eine asynchrone Nachricht (transaktionsgesichert) an das Buchhaltungssytem versandt, der
Erfolg der Buchung selbst ist allerdings nicht gesichert. Das Buchhaltungssystem sendet nach Bearbeitung der
Buchung eine „Quittungsnachricht“ an die Komponente Buchhaltung, die diese an die Schadenkomponente
weiterreicht. Die Nachricht („Event“) initiiert zum Beispiel einen Statuswechsel im zugehörigen Business Object
der Schadenkomponente oder veranlasst die Erzeugung eines Wiedervorlagetermins in einer Terminkomponente.
© GDV 1999
73
Die Systemarchitektur der VAA
Das objektorientierte technische Referenzmodell
Präsentation
Präsentation
Schaden
Schaden
Business-Objects
Business-Objects
Schaden
Schaden
Komponente
Komponente
Buchhaltung
Buchhaltung
BuchhaltungsBuchhaltungssystem
system
(Legacy)
(Legacy)
Komponente
Schaden
Mögliche Transaktionsklammern
Abbildung 39: Beispiel für die Anbindung eines Legacy - Systems
74
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
IV. Architekturmodelle im Überblick
IV.1. Einordnung
Die Arbeitsgruppe „Technisches Referenzmodell“ verfolgte das Ziel, ein Architekturmodell zu
gestalten, das sich an vorhandenen Standards und Lösungsansätzen orientiert. Während bei der
technischen Architektur herstellerneutrale Standards existieren, beginnen sich diese bezüglich der
Systemarchitektur erst langsam zu formieren (vgl. CORBA-Beans). Die Nachfrage nach Architekturen
und Frameworks für kommerzielle, verteilte Anwendungen stieg in den letzten Jahren allerdings stark
an. Dies ist vor allem darauf zurückzuführen, daß der Bedarf an Internet/Intranet-Anwendungen mit
Anbindung an die unternehmensweite DV stark gestiegen ist. Aus diesem Grund entstanden eine
Reihe konkurrierender Frameworks und Architekturen, die alle das Ziel verfolgen, die Realisierung
unternehmensweiter, verteilter Geschäftsanwendungen zu vereinfachen. Die Arbeitsgruppe wählte für
die Analyse vorhandener Systemarchitekturen drei ihrer Ansicht nach typische Vertreter aus:

Die OMG - Vorschläge zur Business Object Architecture (BOCA)

IBM´s San Francisco Framework

Sun´s Enterprise Java Beans (EJB)
Für die Gestaltung der VAA-Systemarchitektur wurden Definitionen, Konzepte und Entwurfsmuster
dieser Architekturen analysiert und miteinander verglichen. Dabei zeigte sich, daß auf Ebene der
grundlegenden Definitionen von Business Objects oder Komponenten eine weitgehende
Übereinstimmung besteht. Abweichungen gibt es natürlich bei der konkreten Gestaltung der
Interfaces, Dienste und Frameworks, aber auch beim Umfang an bereitgestellter Funktionalität.
Während die OMG-Vorschläge ein allgemeines Metamodell für Business Objects und BusinessKomponenten definieren (aufbauend auf der technischen Architektur von CORBA), geht
SanFrancisco einen Schritt weiter: das Framework enthält bereits eine Reihe Business Objects, die
fachliche Funktionalität abbilden (z.B. Account Management). Da San Francisco derzeit die CORBAServices nicht nutzt, sind alternative Dienste und Kommunikationsmechanismen implementiert.
Enterprise JavaBeans (EJB) dagegen beschränkt sich auf die Implementierung eines Frameworks für
Business-Objects und Komponenten („Beans“) und ist „nach unten“ weitgehend kompatibel mit
CORBA-Standards. Allerdings führt die EJB-Spezifikation eine Reihe neuer technischer Dienste ein,
bzw. nutzt in manchen Fällen nur eine Untermenge der entsprechenden CORBA-Dienste.
Alle drei Modelle lassen sich wie folgt in das Schema des technischen Referenzmodells der VAA
einordnen:
Business Object Architecture
© GDV 1999
San Francisco
Enterprise Java Beans
75
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Business Object Architecture
San Francisco
Fachliches Referenzmodell
V ersionierbar
(from LibraryP ackage)
IcisB asis
(from LibraryP ackage)
V ersionierbarerA kteur
Fachliche
Komponentenmodelle
Rolle
0..*
S tandard
P erson
S tandard
0..1
*
Rufnummer
S tandard
0..1
anzuwendendeA nschrift
0..1
A nschrift
0..1
*
anzuwendende
P artner
*
B ankverbindung
B ankverbindung0..1
0..1
V ersionierbar
(from LibraryP ackage)
IcisB asis
(from LibraryP ackage)
A ctor-Role
-P attern
V ersionierbarerA kteur
Fachliche
Komponentenmodelle
Rolle
0..*
S tandard
P erson
S tandard
0..1
*
Rufnummer
S tandard
0..1
JurP erson
anzuwendendeA nschrift
0..1
A nschrift
0..1
*
anzuwendende
P artner
*
B ankverbindung
B ankverbindung0..1
0..1
V ersionierbarerA kteur
S tandard
V ertragsabhaengigerP artner
NatP erson
Technisches Referenzmodell
V ertragsabhaengigerP artner
V ermittler
V ermittler
V ersicherungsnehmer
P roduktpartner
V ersicherte P erson
V ersicherte P erson
S onstigeP artnerrolle
partn
erart
V ersicherungsnehmer
P ostempfaenger
V ersicherungsnehmer
P ostempfaenger
B eitragszahler
B eitragszahler
Business Objects und Komponenten
SystemArchitektur
Dienste
Technische
Architektur
Leistungsempfaenger
Leistungsempfaenger
SystemArchitektur
IBM San Francisco
Business Objects und Komponenten
Dienste
Technische Dienste
Technische Dienste
(CORBA Services)
Object Request Broker
SystemArchitektur
Enterprise JavaBeans
Business Objects und Komponenten
Dienste
Technische Dienste
Technisches Referenzmodell
ObjektP artner
S onstigeP artnerrolle
partn
erart
Leistungsempfaenger
BOCA (OMG)
(CORBA Services)
P roduktpartner
ObjektP artner
P ostempfaenger
B eitragszahler
anzuwendendeA nschrift
0..1
A nschrift
0..1
*
anzuwendende
P artner
*
B ankverbindung
B ankverbindung0..1
0..1
NatP erson
Technisches Referenzmodell
ObjektP artner
S onstigeP artnerrolle
partn
erart
Fachliche
Komponentenmodelle
Rolle
0..*
S tandard
P erson
S tandard
0..1
*
Rufnummer
JurP erson
JurP erson
V ertragsabhaengigerP artner
P roduktpartner
V ersicherte P erson
IcisB asis
(from LibraryP ackage)
A ctor-Role
-P attern
0..1
NatP erson
V ermittler
Fachliches Referenzmodell
Fachliches Referenzmodell
V ersionierbar
(from LibraryP ackage)
A ctor-Role
-P attern
Enterprise Java Beans
Technische
Architektur
(CORBA Services)
Technische
Architektur
Object Request Broker
Object Request Broker
Abbildung 40: Einordnung der betrachteten Architektur-Frameworks
IV.2. OMG Vorschläge zur Business Object Architecture
Innerhalb der Business Object Domain Task Force (BODTF) der OMG werden derzeit zwei
Standardisierungsvorschläge zu einer Business Object Architecture bearbeitet:


Die Interoperability Specification (InterOp), ein gemeinsamer Vorschlag von IBM, EDS, Iona u.a.
Die Business Object Component Architecture (BOCA), ein gemeinsamer Vorschlag der gleichen
Firmen, jedoch ohne IBM
IV.2.1. Architekturziele und Kontext
Beide Vorschläge verfolgen das Ziel, ein Metamodell für Business-Objekte zu spezifizieren. Analog
zum technischen Referenzmodell der VAA geht es darum, Kategorien von Objekten, ihr
grundlegendes Verhalten und Strukturvorgaben zu definieren („Systemarchitektur“) und die
benötigten technischen Funktionen wie Datenspeicherung und Transaktionsmanagement auf die
CORBA - Dienste und Interface-Spezifikationen abzubilden („Technische Architektur“).
Mit den BODTF-Spezifikationen soll vor allem die Standardisierung von Business-Komponenten
ermöglicht und der Einsatz der CORBA-Dienste für den Anwendungsentwickler vereinfacht werden.
Die bisherigen Spezifikationen der OMG erlauben zu viele Freiheitsgrade in der Gestaltung von
Business-Komponenten, so daß Interoperabilität auf Komponentenebene meist nur auf Basis einer
einzigen Systemumgebung gewährleistet ist.
Die o.a. Standardisierungsvorschläge sind nicht konkurrierend, sondern setzen unterschiedliche
Schwerpunkte. BOCA konzentriert sich auf die Beschreibung von Kategorien und Verhalten von
Business-Objekten mittels eines abstrakten Metamodells. Dieses Metamodell ist eine Erweiterung des
CORBA-Metamodells, das CORBA-IDL und dem CORBA-Interface-Repository zugrunde liegt. Das
Metamodell von BOCA ist dadurch stark orientiert am Analyse- und Design-Prozeß von
Geschäftsanwendungen und spielt den Vermittler zwischen dem „anwendungsneutralen“ OOADModell von UML und dem implementierungsorientierten CORBA-Metamodell. BOCA definiert eine
Component Definition Language (CDL), mit deren Hilfe Komponenten für Geschäftsanwendungen
mit den Konstrukten des BOCA-Metamodells präzise beschrieben werden können. Die
Interoperabilität von Komponenten, die mit CDL beschrieben sind, kann dadurch relativ zuverlässig
gewährleistet werden. BOCA setzt zwar die Existenz von technischen Diensten für Datenmanagement
und Transaktionsverwaltung voraus, liefert allerdings keine Beschreibungen, wie diese Dienste in das
Metamodell integriert werden sollen.
76
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
Die Integration der Corba-Services in eine Systemarchitektur für Geschäftsanwendungen und das
Zusammenspiel zwischen ORB-Funktionen und Business-Objekten ist der Schwerpunkt der
Interoperability-Specification. InterOp vereinfacht die Verwendung bestehender CORBA-Services
durch Kapselung der Implementierungsdetails in Steuerobjekten und Basisklassen. Manche Dienste
wurden erweitert und es kommen neue hinzu, um den besonderen Anforderungen von
Geschäftsanwendungen Rechnung zu tragen. InterOp ist weniger abstrakt wie BOCA und stärker
technisch orientiert, insbesondere verfügt es nicht über eine formale Spezifikation eines Metamodells
für Geschäftsobjekte. Die in InterOp definierten Kategorien von Objekten werden in Form von
CORBA-Interfaces beschrieben. Sie lassen sich allerdings zumindest grundsätzlich entsprechenden
Meta-Types2 in BOCA zuordnen. So entspricht das InterOp - Object BocaObject dem BOCA MetaType BocaType.
InterOp und BOCA können aufgrund dieser losen Zuordnung unabhängig voneinander verwendet
werden. Eine vollständige Durchgängigkeit des Entwicklungsprozesses und die Interoperabilität
entsprechender Komponenten könnte durch die Umsetzung beider Standards möglich werden,
wenngleich die intellektuellen Anforderungen an Systementwickler sehr hoch sind. Voraussetzung
dafür ist allerdings eine breite Unterstützung der Hersteller von Entwicklungsumgebungen für diese
Standards.
BOCA konnte im Rahmen des Arbeitsauftrages der Projektgruppe „Technisches Referenzmodell“
aufgrund seines umfassenden Anspruchs nicht in die Analyse einbezogen werden, da fachliches und
technisches Referenzmodell gleichzeitig betrachtet werden müßten. Aufgrund des vorläufigen
Charakters der BOCA-Spezifikation erscheint dies zum heutigen Zeitpunkt auch nicht sinnvoll. Die
folgende Übersicht befaßt sich deshalb ausschließlich mit den Inhalten der Interoperability
Specification.
IV.2.2. Grundmuster der Architektur
IV.2.2.1. Definitionen
Business System Domain (BSD)
Die Interoperability Specification definiert sogenannte Business System Domains (BSD) als
Lebensraum von verteilten Objekten. Eine BSD repräsentiert ein in sich konsistentes und sicheres (im
Sinne von recoverable) verteiltes Objektsystem für eine bestimmte business domain (Geschäftsfeld).
Ein Business-Object, das in mehreren Domains gebraucht wird, ist immer einer primären Domain
zugeordnet (und ist nur dort gespeichert). Der Anschluß an andere Domains geschieht durch sog.
Adaptoren, die die Interfaces innerhalb der anderen Domains darstellen.
2
Ein Meta-Type ist die formale Beschreibung der Eigenschaften aller Objekte eines bestimmten Types.
© GDV 1999
77
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Personnel
Adaptors
Business Objects
Production Scheduling
Supplier
Customer
Abbildung 41: Interaktion von Business System Domains
Im Rahmen des BSD-Konzeptes existieren für einzelne CORBA-Services Einschränkungen und neue,
in CORBA bisher nicht vorhandene Konzepte bzw. Kontrollobjekte werden definiert:
Name Scope
Definierter Namensbereich innerhalb einer Domaine
Relations
Beziehungen zwischen BOs können nur innerhalb einer BSD
erstellt werden. Adaptoren können allerdings Beziehungen zu
BOs ihrer Domäne haben
Recoverabiltiy
Recoverabilty im strengen CORBA-Sinne (Tranaktions) ist nur
innerhalb einer BSD definiert. Allerdings bietet die Erweiterung
des Transaction-Service (s.u.) in InterOp Möglichkeiten, eine
BSD-übergreifende Transaktionsverwaltung zu gewährleisten.
Role
Die Ausprägung eines BO je nach dem Prozeß, an dem es
teilnimmt wird Role genannt
Extent
Der Extent ist die Menge aller Objekte eines Typs innerhalb
einer BSD. Er definiert damit den Rahmen aller möglichen
Queries bezüglich eines Typs. Der Extent wird durch ein
einziges BO-Framework innerhalb jedes BSD verwaltet.
Domain Manager Object
Jedem BSD ist ein Domain Manager Object zugeordnet, das
alle zentralen Aktivitäten kontrolliert
Type Manager und Businesskomponenten
Business-Objekten eines Typs ist ein Type Manager zugeordnet, der für Operationen wie Suchen,
Erzeugen, Relationenaufbau usw. für den betroffenen Typ zuständig ist. Der Type Manager benutzt –
wo möglich – die CORBA-Services, vereinfacht aber ihre Verwendung im Kontext mit BOs.
Type Manager und zugehöriges BO bilden eine Businesskomponente.
Business-Object und Dependent Type
78
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
InterOp unterscheidet zwischen Business-Objects und Dependent Types. Business-Objects sind
charakterisiert durch die folgenden Eigenschaften:

Ein BO ist identifizierbar über einen (fachlichen) Schlüssel

Ein BO nimmt an Transaktionen teil

Ein BO kann persistent sein

Ein BO besitzt Attribute und Zustände3

Ein BO kann Beziehungen zu anderen BOs haben

Ein BO verfügt über Methoden

Ein BO kann Events auslösen und das Ziel von Events sein

Ein BO kann Properties besitzen, die ohne Änderungen des BO-Interfaces dynamisch
ergänzt werden können

Ein BO kann Exceptions auslösen. Diese Exceptions werden in einer Stack-Liste verwaltet,
so daß die gesamte Fehlerkette an einer definierten Stelle bearbeitet werden kann.
Dependent Objects sind üblicherweise Attribute eines BO und sind nur zusammen mit dem BO
persistent und transaktionsfähig. Sie werden in der Regel by value und nicht by reference in
Aufrufparametern übertragen (im Gegensatz zu Business-Objects).
InterOp definiert die folgenden Typen von Dependent Objects:

Primitive - einfache Datentypen wie Interger, String usw.

Elementary objects - Objekte, die als Instanzvariable einen Primitive Type besitzen, dessen
Bedeutung durch das Elementary-Object und seine Methoden erst charakterisiert wird
(z.B. Maßeinheiten)

Foreign object identifier objects - Enthalten Fremdschlüssel auf andere Business- Objects

Composite objects - aus einfachen Dependent Objects zusammengesetzte Dependent
Objects

Immutable objects - Objekte, die nicht by value, sondern by reference übertragen werden,
obwohl es sich nicht um BOs handelt. Beispiele: Graphiken, Bild- und Audiodaten.
Interface-Hierarchie für Business-Objekts und Type Managers
3
InterOp unterscheidet zwischen Attributen und Zuständen: Zustände sind spezielle numerische Attribute, deren Werte bestimmte Zustände
des BOs charakterisieren
© GDV 1999
79
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
BocaGenericDataType::BocaObject
BocaTransactions::TransactionalObject
BocaNotif ication::Consumer
BocaNotif ication::Supplier
BocaObjects::StateAccess
BocaGenericDataTypes::DependentObject
BocaObjects::Lif eCycleObject
BocaObjects::IndependentObject
BocaObjects::BusinessObject
BocaObjects::TypeManager
Abbildung 42: Interface Hierarchie für Business Objects und Type Managers
User-Interface- und Thin Client-Support
InterOp selbst liefert keine Spezifikationen für das User Interface. Es beschäftigt sich ausschließlich
mit präsentationslosen Business-Objekten und ihrer Interaktion untereinander.
Allerdings definiert InterOp zwei grundlegende Interaktionsmodelle für eine Thin-Client-Architektur
und gibt dazu eine Grundstruktur der Interfaces an:

Das Application Control Interface


Das Application Control Interface ist ein client-basiertes Business-Object, das den Vermittler
zwischen Präsentation und anderen Bos darstellt. Es verfügt über zwei grundsätzliche
Methoden:
- getValidOps, zur Ermittlung der aktuell gültigen Methoden der zugeordneten Bos
– setCheckpoint, zum Setzen eines Transaktions-Checkpoints
Das Command Object

Das Command Object enthält die Ablauflogik und Methoden zur Aufnahme von Daten vom
User Interface und zum Editieren von Daten via UI. Es wird zu Beginn der Eingaben vom
Server zum Client kopiert und nach Abschluß der Eingaben per „execute“ zum Server kopiert
und die Ablauflogik dort ausgeführt.
IV.2.2.2. Services
Eines der Hauptziele der Interoperability Specification ist die Kompatibilität von Komponenten, auch
wenn diese nicht mit Hilfe des gleichen Entwicklungs-Frameworks erstellt wurden. Wie bereits im
ersten Abschnitt erwähnt, reicht CORBA-Konformität allein nicht aus, da CORBA viele Konzepte, die
80
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
für die Erstellung von Business-Komponenten benötigt werden, nicht definiert. InterOp geht deshalb
davon aus, das im extremsten Fall jedes Business-Object mit einem anderen Framework erstellt
wurde. Lediglich der für das BO zuständige Type Manager muß zusammen mit diesem im gleichen
Framework implementiert sein. BO und Type Manager bilden zusammen eine Business-Komponente.
Services werden gemäß dieser Konzeption in InterOp auf zweierlei Weise definiert:


Als CORBA-Interfaces für Business-Objects und Type Manager, über die Komponenten
(bestehenden aus BO und Type Manager) direkt miteinander kommunizieren
Als Shared Services für jene Funktionen, die nur komponentenübergreifend gestaltet werden
können, wie zum Beispiel die Transaktionsverwaltung.
Implementation A
Customer
Type Manager
Customer
Business Object
Transactional
Persistent
Identity
Life cycle
Attributes
States
Relationships
Implementation B
Operations
Notification
Events
Queries
Introspection
Exceptions
Order
Business Object
Order
Type Manager
Transactional
Persistent
Shared Services
Transaction Service
Name Service
Security Service
Event Service
Collection Service
Abbildung 43: InterOp Services über verschiedene Komponenten
IV.2.2.3. BO- und Type-Manager Interfaces
Identity
InterOp spezifiziert unterschiedliche Formen, die Identität eines Business-Objects zu definieren. Sie
können alle nebeneinander in einem Anwendungssystem genutzt werden.
CORBA Reference
Die Standard-CORBA-Reference wird (wie in allen CORBASystemen) zum Zugriff auf die Methoden eines aktiven BOs
verwendet und vom Type Manager bei der Erzeugung eines BOs
zurückgegeben.
Persistent ID
Die Persistent ID ist der Schlüssel, der das BO innerhalb einer
© GDV 1999
81
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Datenbank eindeutig identifiziert („Primärschlüssel“). Mit Hilfe der
Persistent ID kann der Type Manager das BO über den zugeordneten
Persistence Manager aus der Datenbank laden. Die Form der
Persistence ID ist implementierungsabhängig. Um eine vollständige
Transparenz des Objektzugriffs zu erreichen, empfiehlt InterOp die
Erweiterung der CORBA-Reference um die Persistent ID des BOs
(s.u.)
BocaObjectKey
Der BocaObjectKey ist die Menge der BO-Attribute, die das BO
eindeutig identifizieren („Sekundärschlüssel“). Der BocaObjectKey
ermöglicht es dem Type Manager über die identifizierenden Attribute
ein BO zu finden.
External ID
Die External ID ist ein sprechender Schlüssel des Objekts, der über
den Naming Service von CORBA an ein BO gebunden werden kann
(siehe Abschnitt „Naming Service“, unten). Die External ID kann
verwendet werden, um einen Objektschlüssel für den Anwender
darzustellen.
Qualified Name
Der Qualified Name eines BO besteht aus einem Naming Context und
dem BocaObjectKey oder der External ID. Durch den Naming Context
können gleichlautende Schlüssel in unterschiedlichen Domänen
genutzt werden (Beispiel: identische Vertragsnummern in allen
Sparten, die Spartenzugehörigkeit wird über unterschiedliche Naming
Contexts definiert - „LV/1234567“ und „KFZ/1234567“).
Um Qualified Names darzustellen, erweitert InterOp den CORBA
Naming Service (s.u.)
Foreign Object ID
Die Foreign Object ID stellt den Schlüssel eines BOs in einer anderen
BSD dar. Die Umsetzung zwischen Foreign Object ID und
tatsächlichem Schlüssel erfolgt durch den Adaptor (s.o.)
Tabelle 8: Identity eines Business Objects (Interoperability Specification)
Persistence
InterOp spezifiziert keinen eigenen Persistence Service, sondern verfolgt das Prinzip der transparenten
Speicherung, das heißt:


Der Zugriff auf Methoden eines BOs muß unabhängig davon sein, ob sich das BO gerade im
Speicher befindet oder nicht.
Das Speichern eines BOs wird nicht explizit angestoßen, sondern erfolgt automatisch nach
Abschluß einer Transaktion (vgl. Transaction Service, s.u.)
Der transparente Zugriff auf ein BO setzt voraus, daß eine Persistent ID existiert, die einem
Persistence Manager ermöglicht, ein BO bei Bedarf aus der Datenbank zu laden. InterOp spezifiziert
eine Persistent ID für BOs, über die der Type Manager bei Bedarf das Objekt anfordern kann. Eine
vollständige Orts-Transparenz, wie sie die CORBA-Reference von Objekten darstellt, ist damit noch
nicht erreicht, sie wäre erst möglich, wenn die CORBA Reference selbst eine Persistent ID beinhalten
würde. InterOp erkennt dieses Problem und schlägt eine entsprechende Erweiterung der CORBAReference vor.
82
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
Mit Ausnahme der Persistent ID - Problematik ist der Persistence Service nicht Bestandteil der
InterOp - Interfaces und Spezifikationen. InterOp ist allerdings kompatibel mit dem CORBA Persistence Service und allen anderen Persistence Services, die das Transaction Service Protokoll von
CORBA unterstützen.
LifeCycle
InterOp vereinfacht den LifeCycle - Service von CORBA und fügt neue, im BO - Kontext benötigte
Funktionen hinzu. Der InterOp Life Cycle Service ist aber nach wie vor konsistent mit den CORBA Spezifikationen, da die InterOp - Funktionen innerhalb des Type Managers beziehungsweise des BOs
auf die CORBA Life Cycle - Interfaces abgebildet werden können.
Generell bestehen die folgenden Unterschiede zwischen den CORBA- und InterOp - Spezifikationen



InterOp definiert wie CORBA create, copy, move und delete - Operationen für BOs, die Interfaces
sind jedoch nicht von den CORBA Interfaces abgeleitet (im Sinne der Interface-Vererbung)
Die Funktionen copy und move haben einfachere Ortsangaben (Factory selection anstatt Factory
finding)
Die Erzeugung von BOs erfolgt über den Type Manager, die komplexen CORBA-Factory
Interfaces sind auf InterOp-Ebene unsichtbar
Im wesentlichen entsprechen die Life Cycle Operationen von InterOp der CORBA-Funktionalität,
wenngleich sich die Interfaces voneinander unterscheiden:
Delete
Die Delete-Operation wird durch das BO selbst
implementiert, sie ist im BO-Interface
definiert. Nach erfolgreichem Delete ist kein
Zugriff auf das Objekt mehr möglich, das
explizite Löschen aus dem Speicher und der
Datenbank erfolgt allerdings erst beim
Transaktionsende (vgl. Transaction Service).
Empfänger von Events, die das gelöschte
Objekt erzeugt, werden vor dem Löschen
informiert (siehe „Events“: intrinsic events).
Copy
Die Copy-Operation wird durch das BO selbst
implementiert. Copy erzeugt ein Replikat des
Objektes im selben BSD (welcher allerdings
aus unterschiedlichen Adressräumen bestehen
kann!).
Relationships werden traversiert, wobei der
grundsätzliche Ablauf in InterOp definiert ist,
nicht jedoch die Details der Auflösung von
Beziehungen. Bei Beziehungen, deren Knoten
nicht mit kopiert werden sollen, wird ein
COPY-Event an alle verbundenen Objekte
gesendet (siehe „Events“: intrinsic events).
Event-Verbindungen zu anderen Objekten
© GDV 1999
83
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
werden nicht kopiert.
Move
Analog Copy mit anschließendem Delete
Create
Das Erzeugen neuer BOs eines bestimmten
Typs erfolgt durch die Create-Operation des
zugehörigen Type Managers.
Das Create-Interface von InterOp ist erheblich
einfacher als das entsprechende CORBAInterface, da der Weg über FactoryFinder und
Factory
durch
den
Type
Manager
übernommen wird. Als Parameter des CreateInterfaces müssen lediglich Erzeugungsort (ein
spezieller Objekttyp) und die Initialwerte der
BO-Attribute (sofern notwendig) übergeben
werden. Das Interface ist generisch, da für die
Übergabe der Initialwerte die gleiche Struktur
wie beim State Access verwendet wird (s.u.)
Das copy_from_object-Interface erzeugt ein
neues BOs, bei dem Initialwerte
vom
angegebenen Objekt übernommen werden
Tabelle 9: Life Cycle Operationen der Interoperability Specification
State Access
Das State Access Interface dient dazu, beliebige Attribute (einschließlich Relationship-Attributen, die
eine Fremdschlüsselbeziehung darstellen) eines Business-Objects zu lesen oder zu setzen. Dieses
Interface muß von allen Business-Objects, kann aber auch von anderen Objekten implementiert
werden. Durch die Verwendung des State Access Interfaces wird die Anzahl der Methoden eines BOs
verringert, da nicht für jedes Attribut eine Zugriffsmethode definiert werden muß.
Das State Access Interface beinhaltet die folgenden Methoden:
Get
Liefert eine Liste von Attributwerten samt ihren Namen.
Eingangsparameter ist die Liste der angeforderten Attributnamen.
Falls ein Attribut aus mehreren Elementen besteht, wird ein Iterator
zurückgeliefert, der dazu dient, nacheinander jedes Element
auszulesen.
Set
Setzt eine Liste von Attributen auf die übergebenen Werte.
Eingangsparameter ist eine Liste von Attributen, bestehend aus dem
jeweiligen Namen und Wert. Falls ein Attribut aus mehreren
Elementen besteht, wird ein Iterator übergeben, der dazu dient,
nacheinander jedes Element zu setzen.
Tabelle 10: State Access Operationen der Interoperability Specification
Events
84
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
InterOp spezifiziert eigene Interfaces zur Kommunikation zwischen Business-Objects. Das
„Supplier“-Interface (für die Sender-Seite) ist nicht vom entsprechenden CORBA-Interface abgeleitet,
sondern neu definiert. Für die Empfänger („Consumer“) eines Events verwendet InterOp das
Consumer-Interface des CORBA Event Services. Generell ist der InterOp Event Service nicht auf
CORBA eingeschränkt, sondern läßt sich auch mit anderen Event Services integrieren.
Im Gegensatz zum CORBA Event Service liegt InterOp weniger Wert auf den
Verteilungsmechanismus, sondern auf die Spezifikation unterschiedlicher Eventtypen und den
Bedingungen für das Auftreten eines Events.
InterOp unterscheidet zwischen folgenden Event-Typen:

Intrinsic events werden von allen BOs ausgelöst und sind vordefiniert (siehe Tabelle).

Implicit events werden ausgelöst, wenn sich Attribute oder Beziehungen von BOs ändern

Programmed events sind BO-Typ-spezifische Ereignisse, die abhängig sind von fachlichen
Bedingungen innerhalb der BO-Logik.
Event Name
Description
Moved
Occurs on commit of a move operation. Delivery is only on precommit or post commit (not immediate).
Created
Provided only by type managers when an instance of the type is
created. The notice will only be issued for occurrence after and
delivery pre-commit or post-commit (not immediate).
Deleted*
Occurs when an object is logically deleted from the business system
domain. This notifies a dependent consumer that the object it is
dependent upon no longer exists. This event does not apply to typebased notification requests.
Polling*
This is an event an implementation may choose to use. It might be
issued to determine if the consumer still exists. The consumer should
simply return from a Polling notice; the supplier will receive an
exception if the consumer is no longer available.
Committed
Occurs when an object is committed by a transaction. Delivery is
only on pre-commit or post commit (not immediate).
RolledBack
Occurs when an object is restored to its last committed state by a
transaction. This event is only available for immediate delivery.
Tabelle 11: Intrinsic events (Interoperability Specification)
Intrinsic und implicit Events übermitteln eine standardisierte EventNotice, die ohne Kenntnis des
Objekttyps des Senders verarbeitet werden kann.
Bei der Registrierung von Events können vordefinierte Bedingungen unter denen ein Event auftreten
bzw. wann es übermittelt werden soll, angegeben werden (siehe Tabellen unten).
InterOp sieht persistente Events vor, die auch nach Ausfall des Systems erhalten bleiben. Es geht
dabei in Richtung eines sicheren Message-Service, ohne jedoch näher auf die damit
zusammenhängenden Fragen (wie z.B. das Löschen irrelevanter Nachrichten) einzugehen.
© GDV 1999
85
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Occurrence
Description
Before
An immediate, synchronous message is sent before an action is performed. This does not apply to
intrinsic or programmed events, but only to implicit events, and it does not apply to pre-commit or
post-commit delivery..
After
A message is sent after the event has occurred. The notification may be immediate, pre-commit or
post_commit. For operations, an after notice is issued when a normal return occurs.
Failed
A notice is issued if the action failed to complete, i.e., raised an exception.
Tabelle 12: Bedingungen für das Auslösen von Events (Interoperability Specification)
Delivery
Description
Immediate
An immediate registration of interest produces synchronous notices. An immediate registration of
interest will be discarded if the supplier or the consumer becomes unavailable, i.e., either one is
deleted.
Pre-commit
For a pre-commit registration of interest, events of interest which have occurred to an object during a
transaction are communicated during the Propagation phase. The occurrence specification is restricted
to after. The messages will be delivered within the context of the transaction about to commit so their
effects can be similarly committed or rolled back. Only those events that occurred within the context
of a transaction and after interest was registered will be communicated.
Post-commit
For a post-commit registration of interest, events of interest which have occurred to an object during a
transaction are communicated after the transaction commits. The occurrence specification is restricted
to after. The messages will be delivered within the context of a new, top-level transaction. Only those
events that occurred within the context of a transaction and after interest was registered will be
communicated.
Tabelle 13: Bedingungen für die Übermittlung von Events (Interoperability Specification)
Relationship
InterOp übernimmt nicht die komplexen Spezifikationen des CORBA-Relationship-Service (s.o),
sondern beschränkt sich auf zweiwertige 1:1 – und 1:n – Beziehungen. Damit entfällt das in CORBA
definierte Rollen-Objekt für die Verwaltung von Beziehungen mit n:m – Kardinalität (das in InterOp
spezifizierte Role-Object hat eine andere Funktion). Sofern n:m – Beziehungen notwendig sind,
können sie auf 1:n – Beziehungen abgebildet werden, indem ein explizites Rollenobjekt eingeführt
wird. Dieses Vorgehen trägt der Tatsache Rechnung, daß höherwertige Beziehungen einen komplexen
fachlichen Hintergrund besitzen, der ohnehin zur Einführung fachlich motivierter Rollenobjekte führt
(Beispiel: die Rollen in Partner – Beziehungen), wogegen bei einfachen 1:n – Beziehungen ein
zusätzliches Rollenobjekt lediglich Implementierungs-Oberhead bedeutet.
In InterOp ist jeder Beziehung ein Relationshipname zugeordnet. In den Business-Object – Methoden
für die Verwaltung von Beziehungen wird dieser Name an definierten Stellen in den Methodennamen
eingefügt (analog der Property-„Reflection“ – Technik bei JavaBeans).
Beispiele:

get_Vertrag_sequence liefert die Menge aller Vertrag-Objekte des aktuellen Business-Objects

add_to_Vertrag fügt einen neuen Vertrag in die Beziehung ein

remove_from_Vertrag entfernt den angegebenen Vertrag aus der Beziehung.
Beziehungen werden dargestellt durch die PersistentID des Beziehungspartners und einem Tuple von
Attributen, die zu diesem Partner gehören. Die wichtigsten Attribute eines Beziehungspartners können
86
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
damit direkt in der Beziehung angegeben werden, das heißt ein Zugriff auf das Objekt selbst ist nicht
notwendig. Nicht spezifiziert ist allerdings, was bei der Änderung von Attributen geschieht, InterOp
geht offenbar davon aus, daß nur identifizierende Schlüssel (die sich während der Lebenszeit eines
Objektes nicht ändern) als Attribute in die Beziehung eingehen. Sollte dies nicht gewährleistet sein, so
muß das Partner-Objekt bei Attribut-Änderungen benachrichtigt werden (siehe Events: implicitevents).
Der Type Manager eines Business-Objekts enthält die Methode get_related_objects, die alle Partner
der angegebenen Beziehung zurückliefert. Dabei kann eine Sortierreihenfolge auf Basis der in der
Beziehung definierten Attribute angegeben werden.
Query
Der Type Manager stellt Interfaces für Queries von Business-Objekten seines Typs oder abgeleiteten
Typen zur Verfügung.
query
Liefert einen Iterator zurück, mit dessen Hilfe
über die Ergebnismenge iteriert werden kann
(ein Iterator entspricht in etwa einem
Datenbank-Cursor
in
relationalen
Datenbanken). Neben den Objektreferenzen
enthält die Ergebnismenge auch Attribute der
gefundenen Objekte, sofern diese in der Query
angegeben wurden. Die Methode query
akzeptiert einen Query-String in einer in
InterOp definierten Syntax.
Für den zurückgelieferten Iterator ist ein
analoges query-Interface definiert, damit die
Ergebnismenge weiter eingeschränkt werden
kann.
extent_iterator
Liefert einen Iterator über die Menge aller
Business-Objekte dieses Typs und seiner
abgeleiteten Typen zurück.
Tabelle 14: Interfaces des Query Service der Interoperability Specification
InterOp spezifiziert nicht, auf welche Weise ein Type Manager Queries ausführt, dies liegt in der
Verantwortung des Implementierungs-Frameworks. Da Queries immer auf einen Type beschränkt
sind, ist eine solche Spezifikation auch nicht notwendig: Type Manager und zugehörige BusinessObjekte müssen immer auf Basis des gleichen Frameworks implementiert werden.
Introspection
Das Introspection Interface wird vom Type Manager eines Business-Objects implementiert. Es dient
dazu, allgemeine Informationen über die BOs dieses Types zu erhalten. InterOp definiert die
folgenden Methoden im Introspection Interface:
get_class
© GDV 1999
Liefert eine Referenz auf das „Meta-Object“ des Business-Objects.
Die Struktur und Methoden dieses Meta-Objects wird von InterOp
nicht näher spezifiziert. InterOp gibt lediglich Mindestanforderungen
87
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
an. Danach muß das Meta-Object zumindest Informationen über
Attribute, Relationships und Events des zugehörigen BO-Typs liefern.
get_key_class
Liefert eine Referenz auf das „Meta-Object“ des Schlüssels eines BOs
des zugehörigen Typs (vgl. BocaObjectKey)
get_key_elements
Liefert eine Liste der Attributnamen, die im Schlüssel eines BOs des
zugehörigen Typs auftreten (vgl. BocaObjectKey).
Tabelle 15: Introspection Interface (Interoperability Specification)
Exception
InterOp spezifiziert eine von CORBA-Exceptions abweichende Fehlerbehandlung. Die wesentlichen
Unterschiede sind:

InterOp-Exceptions sind nicht einzelne Fehlernachrichten, sondern können aus einer Liste von
„Error-Objects“ bestehen. Damit kann die gesamte Historie einer Fehlersituation protokolliert
werden (Stack von Fehlermeldungen)

Im „Error-Object“ können weitere Informationen mitgeliefert werden: das Objekt, das den Fehler
auslöste, die „Exception Category“, sowie eine Erläuterung des Fehlers
InterOp definiert die folgenden „Exception Categories“:
Category
Description
Environment
These exceptions are raised by the language.
Normal
Exceptions which have not been explicitly specified otherwise.
Data Entry
Exceptions detected in data entry.
Rule
Violation
Exceptions raised by invariants.
Integrity
Exception raised when the integrity of the model has been
compromised.
Service
Exception raised when a CORBA service fails or is unavailable.
Tabelle 16: Exception Categories (Interoperability Specification)
IV.2.2.4. Shared Services
Transaction Service (und Dispatch Service)
Der InterOp Transaction Service erweitert den CORBA-Transactions Service vor allem in Richtung
der Transaktionssicherheit über BSD-Grenzen hinweg. InterOp geht nämlich davon aus, daß pro BSD
ein in der Regel unterschiedlicher Transaktionsservice implementiert ist, der auch nicht in jeder
Hinsicht CORBA-konform sein muß. Deshalb favorisiert InterOp eine eher lose Koppelung zwischen
88
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
BSDs und definiert lediglich Minimalanforderungen bezüglich verteilter Transaktionen zwischen
BSDs.
Darüber hinaus definiert InterOp eine Reihe von Mechanismen, die für das Zusammenspiel von BOs
innerhalb einer BSD und einer Transaktion notwendig sind. Deshalb ist der Transaction Service als
Shared Service konzipiert, d.h. BOs teilen sich einen Transaktionskontext. Analog zum CORBAService, muß der „Benutzer“ eines BO nur Anfang und Ende einer Transaktion spezifizieren, den Rest
erledigt die Logik innerhalb des BO (die eigentliche Speicherung) bzw. der CORBA-Service.
Natürlich sind auch verschachtelte Transaktionen möglich.
Folgende zusätzliche Eigenschaften des CORBA Transaction Service werden in InterOp spezifiziert:
Session
InterOp spezifiziert ein Session Object mit frei wählbaren
Attributen (named values), das dazu dienen soll,
Transaktionsinformationen
zwischen
BSDs
(und
unterschiedlichen
Implementierungen
eines
Transaktionsframeworks) auszutauschen.
Deadlock detection and Definiert einen Mechanismus, um dead locks zwischen
gekoppelten Tx (in verschiedenen BSDs bzw. Tx-Frameworks)
resolution
aufzulösen
BOCA-Exceptions
BOCA – Fehlermeldungen als Erweiterung der CORBAExceptions
Weitere Phasen
Neben Prepare und Commit spezifiziert InterOp noch die Phasen
Propagate, Validate und Synchronize, um die Möglichkeiten der
automatischen Konsolidierung von Informationen zwischen Bos
zu erweitern (siehe Bild unten)
Dispatch Service
Der Dispatch Service dient zum Anstoß von Folgetransaktionen
nach Abschluß der aktuellen Transaktion. Damit ist zum Beispiel
die asychnrone Koppelung unterschiedlicher BSDs möglich. Der
Anstoß der Folgetransaktion kann auf unterschiedliche Weise
erfolgen:

Unmittelbar nach dem Commit (post_commit_request)

Nach einer definierten Zeitspanne (time_delay_request)

Durch ein CORBA-Event (event_delivery_request)
Während die ersten beiden Möglichkeiten voraussetzen, daß das
Zielobjekt des Folgetransaktionsaufrufs das DispatchTarget Interface von InterOp implementiert, kann mit der dritten
Möglichkeit jedes beliebige CORBA-Objekt benachrichtigt
werden.
Tabelle 17: Eigenschaften des Transaction Service (Interoperability Specification)
© GDV 1999
89
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
1: commit()
Steuerlogik
der Anwendung
(Prozeß)
ideEffects
()
ag
2:
3a: checkS
ate
Transaction
Manager
(CORBA)
p
pro
ate(
alid
4: v
()
)
5: validateInternalStateBeforeUpdate()
BO
3b:
BO
(im Tx-Context
registriert)
c he
c kI
nte
niz
r na
lRu
les
e ()
ro
ch
yn
s
6:
()
7: storeState()
Storage Manager
Abbildung 44: Phasen des Commits im Transaction-Service (Interoperability Specification)
Naming Service
Der InterOp Naming Service ist eine Erweiterung des CORBA Naming Service. Zusätzliche
Methoden im CosNaming - Interface von CORBA erlauben die Zuordnung von sogenannten
BocaQualifiedNames zu Business-Objekten.
Ein BocaQualifiedName ist ein String bestehend aus einem NamingContext- und einem Key-Teil. Der
NamingContext ist eine vereinfachte Form des CORBA-NamingContexts. Der Key-Teil identifiziert
das BO innerhalb des Naming Contexts eindeutig. InterOp erlaubt zwei unterschiedliche
Ausprägungen dieses Keys:

Als BocaObjectKey

Als External Identifier
Der BocaObjectKey ist ein Dependent Object jedes BO und repräsentiert den eindeutigen Schlüssel
des Business Objekts. Der BocaObjectKey ist vergleichbar mit den Schlüsselfeldern in einer
relationalen Datenbank, die ein bestimmtes Tupel eindeutig identifizieren. Diese Schlüsselfelder
werden in Form eines zusammengesetzten Strings als BocaObjectKey vom jeweiligen BO geliefert.
Ein external identifier ist ein über den CORBA-Name Service frei definierbarer Schlüssel des BO, der
innerhalb eines bestimmten Kontextes gültig ist und auch nur dort verwendet werden darf. Beispiel:
eine virtuelle Vertragsnummer, die mittels eines Nummerngenerators erzeugt wird, die aber nicht
identisch ist mit dem identifizierenden Schlüssel des Vertrages im Vertragsbestand.
90
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
Security Service
InterOp spezifiziert keine über CORBA hinausgehenden Security - Eigenschaften und Funktionen von
Business-Objekten.
Event Service
InterOp spezifiziert keinen vollständigen Event Service, sondern lediglich die Event-Interfaces, die
Business Objects implementieren müssen, sowie Typen von Events (s.o.). Für die Verteilung der
Events zwischen Sender und Empfänger bestehen keine expliziten Vorgaben, für diesen Zweck ist
aber der Event Channel Mechanismus von CORBA einsetzbar.
Collection Service
InterOp spezifiziert keinen Collection Service, erwähnt aber, daß unter Umständen die Verwaltung
von Collections von BOs zu einem späteren Zeitpunkt standardisiert werden müßte.
IV.2.3. Wertung
Die Interoperability Specification enthält eine Reihe von Definitionen und Entwurfsmustern, die für
die Entwicklung eines Referenzmodells nützlich sind. Insbesondere werden Struktur und
Eigenschaften von Business Objekten und übergreifenden Diensten zum ersten Mal konsistent und
übergreifenden beschrieben. Dennoch wird die Interoperability Specification aufgrund des Erfolg des
JavaBeans - Komponentenmodells in dieser Form nicht als Standard verabschiedet werden. Die in
1999 erwarteten CORBA Component Modell - Spezifikationen werden sich an JavaBeans bzw.
Enterprise JavaBeans orientieren. Das CORBA Component Modell macht die meisten der oben
angeführten Spezifikationen überflüssig. Allerdings fehlen im Component Modell eine Reihe von
Spezifikationen, die in der Interoperability Specification berücksichtigt wurden, namentlich die
Adaption von Fremdsystemen, die standardisierte Behandlung von Vor- und Nachbedingungen bei
Methodenaufrufen, sowie die Detaillierung von Phasen beim Abschluß einer Transaktion. Sofern diese
Aspekte eines verteilten, objektorientierten Systems beim Entwurf einer Anwendungsarchitektur eine
Rolle spielen, bietet die Interoperability Specification so etwas wie ein Nachschlagewerk für
Lösungsmuster. In diesem Sinne wurde sie auch bei der Definition der VAA-Anwendungsarchitektur
benutzt.
IV.3. IBM San Francisco
IV.3.1. Architekturziele und Kontext
IBM verfolgt mit San Francisco das strategische Ziel, Softwarehäusern eine Basis zur Entwicklung
von Geschäftsanwendungen zu geben. Die erstellten Softwarekomponenten bilden sogenannte Tower,
die sich auf Basisfunktionalität von San Francisco (Foundation Layer mit Persistenz, Transaktionen
usw.) und auf von IBM entwickelten Kernkomponenten (Common Business Objects, z.B.
BusinessPartner) und Kernprozessen (Core Business Processes, z.B. Buchhaltung, Einkauf, Verkauf,
Lagerverwaltung) abstützen.
© GDV 1999
91
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Abbildung 45: Ausblick auf die "Multi Layer Architecture" von San Francisco
Durch die vorgefertigten Komponenten sollen sich bis zu 40% des Aufwands zur Erstellung eines
Anwendungstowers einsparen lassen.
San Francisco ist bis auf die Datenbankschicht in Java implementiert und definiert keine Schnittstellen
zu anderen Systemen, die über den Umfang von Java RMI hinausgehen. Der Foundation Layer stellt
zusätzliche Basisklassen wie Country, Currency, Company, Date, Time zur Verfügung und definiert
ein Framework zur Erstellung eigener persistenter Komponenten in den Towern.
San Francisco definiert zusätzlich eine detaillierte Vorgehensweise bei der Erstellung von
Anwendungskomponenten. Diese Vorgehensweise erstreckt sich von der Modellierung in Rational
Rose bis zur Nutzung von vorgefertigten Komponenten und Design Patterns in Verbindung mit einem
detaillierten Programmiermodell.
IV.3.2. Grundmuster der Architektur
92
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
Abbildung 46: Die San Francisco Architektur
Die San Francisco – Architektur besteht aus drei Schichten wiederverwendbarer Systemkomponenten:



Die unterste Schicht (Foundation Layer) enthält alle Superklassen von Objekten, Interfaces und
Protokolle, die das grundlegende technische Verhalten aller Objekte definieren. Der Foundation
Layer stellt Infrastruktur und Dienste zur Kapselung der technischen Details des
Transaktionsmanagements, der Verteilung, Persistenz und anderer Konzepte zur Verfügung.
Damit kann Komplexität einer auf mehreren Plattformen im Netzwerk verteilten Anwendung für
den Anwendungsentwickler reduziert werden.
Common Business Objects (CBO) stehen als Basisklassen für die höherliegenden Schichten zur
Verfügung und stellen Kernfunktionalität wie Business Partner zur Verfügung. Die CBOs stehen
in jeder San Francisco - Anwendung in gleicher Weise zur Verfügung. Sie können für die
Kommunikation zwischen Anwendungen dienen, bei denen komplexe Informationen ausgetauscht
werden müssen. Die Objekte sind im allgemeinen recht abstrakt und zur Laufzeit parametrisierbar.
Dabei kommen Designpatterns wie Property Container und Chain of Responsibility zur
Anwendung.
Die Core Business Processes bilden Kerngeschäftsprozesse ab, die in unterschiedlichen
Unternehmen einsetzbar sind. Business Partner Applications sind Anwendungen auf Basis der
Core Business Processes, die von Softwarehäusern erstellt werden. Dies könnten im Rahmen von
VAA zum Beispiel Partnersystem, Vertragssystem oder Schadensystem sein.
San Francisco ist durchweg in Java implementiert und damit prinzipiell portabel auf eine Vielzahl von
Plattformen (momentan wird Windows NT, AIX, AS/400, HP-UX und Solaris unterstützt). Damit
können die Anwendungsentwickler zusätzlich zu den Funktionen des San Francisco - Frameworks
auch den gesamten Vorrat an Java-Bibliotheken und Werkzeugen nutzen (z.B. visuelle GUI-Builder).
IV.3.2.1. Foundation Layer
Der Foundation Layer stellt die Infrastruktur für die Common Business Objects und Core Business
Processes bereit und definiert eine konsistente Programmierschnittstelle und Struktur für die
Anwendung. Die Infrastruktur besteht dabei aus Foundation Object Model Classes und Utilities.
Zusätzlich steht eine Vielzahl von Kernfunktionen (Kernel Services) zur Realisierung von mission
critical verteilten Anwendungen. Diese Kernel Services werden in der Regel vor dem
Anwendungsentwickler verborgen und werden nur indirekt von den Object Model Interfaces benutzt.
Die Kernel Services umfassen Transaktionsdienste, Collections, Kommunikation zwischen verteilten
Objekten und Persistenzverwaltung und basieren konzeptionell auf den Servicedefinitionen der OMG.
San Francisco enthält allerdings keinen CORBA kompatiblen Object Request Broker und kombiniert
die von der OMG definierten Funktionen mit den in Java bereitgestellten Funktionen. Die OMG
Definitionen werden vereinfacht und wenn nötig ergänzt. Z.B. wird nur optimistisches Locking
unterstützt. Neue Entwicklungen im Bereich der Industriestandards wie die Konvergenzbemühungen
im Bereich CORBA, Java, IIOP und RMI sollen in San Francisco einfließen.
Basis der Kommunikationsinfrastruktur ist Javas Remote Method Invocation (RMI), das im Bereich
des Serverprocess-Management erweitert wurde. Für Kernel Services wie Lizensierung und
Verschlüsselung will man sich auf Produkte von Drittanbietern stützen.
Foundation Object Model Classes
© GDV 1999
93
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Die Foundation Object Model Classes stellen die Basisstruktur für alle San Francisco Objekte und
Frameworks dar und definieren das gesamte Applikationsmodell. Diese Klassen enthalten sowohl
konkrete Implementationen kompletter Methoden als auch abstrakte Schnittstellendefinitionen, die
vom Anwendungsentwickler noch gefüllt werden müssen. Diese abstrakten Schnittstellendefinitionen
erzwingen die Einhaltung bestimmter Nachrichtenprotokolle zwischen Objekten und Diensten, auf
denen das San Francisco Framework aufbaut..
Das konsistente Object Model dieser Klassen soll für eine großen Bereich verteilter Anwendungen
geeignet sein und eigene Architekturüberlegungen auf dieser technischen Ebene überflüssig machen.
Die wichtigsten Konzepte sind dabei:

Command – Eine Gruppe von Operationen auf einem Objekt oder einer Menge von Objekten.
Commands kapseln Anwendungslogik, die nicht direkt einem Business Object zugeordnet werden
kann. Commands können dabei zwischen Clients und Servern transparent verteilt werden.

Entity – Entities sind unabhängige Objekte (Personen, Dinge) die im Verlauf eines
Geschäftsprozesses benutzt werden. Entitäten enthalten oft die Kerndaten einer Applikation und
können persistent sein, d.h. sie sind mit einem Speichermechanismus auf einem Server verbunden,
oder auch transient. Entitäten können auch temporär auf den Client geladen werden. Die
Methoden einer Entität beschäftigen sich generell mit dem Lesen und Schreiben von Attributen
oder Geschäftslogik, die sich nur auf dieses eine Objekt bezieht. Die Unterklasse DynamicEntity
der Klasse Entity ermöglicht die dynamische Zuordnung von Attributen und ihren Werten zu einer
Entity zur Laufzeit und ermöglicht so große Flexibilität bei der Parametrisierung von Entitäten für
spezielle Anforderungen.

Dependent – Sogenannte Dependents sind abhängige Objekte mit erheblich weniger
Systemoverhead als Entitäten. Sie können nicht außerhalb von Entitäten existieren und nicht ohne
sie an Transaktionen teilnehmen. Dependents enthalten zusätzliche Detailinformationen über die
sie umfassenden Entitäten.

Collection/Iterator – gruppieren Mengen von Objekten und stellen Methoden zur Aufzählung der
Objekte einer Menge zur Verfügung. Collections können auch so strukturiert sein, daß die
einzelnen Elemente über einen Schlüssel identifiziert werden. Zugriff auf die Elemente wird durch
Iteratoren realisiert, die Methoden bereitstellen um durch die Menge zu navigieren.

Factory – Factories verwalten die Objektinstanzen während der Ausführungszeit innerhalb des
Frameworks. Die Factory stellt die zur Verwaltung von Business Objects nötigen Funktionen zur
Verfügung. Dies umfaßt insbesondere das Erzeugen und Löschen von Entitäten, Commands und
Collections und definiert eine Abstraktionsstufe für den Persistence Layer.
Utilities
Die vom Foundation Layer bereitgestellten Utilities stellen Dienste zur Verfügung, die von den
meisten Anwendungen benötigt werden. Im Unterschied zu den Foundation Object Model Classes
sind sie vollständig ausprogrammiert und sollten direkt eingesetzt und nicht erweitert oder modifiziert
werden.
Unterstützt wird die Definition und Verwaltung von Anwendungssicherheit und Informationen über
die Systemkonfiguration. Mittels Conflict Control kann der Systemadministrator verhindern, daß
Commands zur Ausführung gelangen, die nicht gleichzeitig mit anderen ablaufen dürfen. Weiterhin
können Audit Trails eine Historie der Zugriffe der Anwender auf Objekte protokollieren.
94
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
Viele
dieser
Funktionen
sind
relative
dünne
Schichten
oberhalb
bestehender
Betriebssystemfunktionalität, die aber von San Francisco in integrierter Form und mit einheitlicher
Schnittstelle angeboten werden.
IV.3.2.2. Common Business Objects Layer (CBOs)
Auch der nächste San Francisco Layer zerfällt in mehrere unabhängige Frameworks von
Applikationsdiensten und daneben einer Sammlung von Common Business Objects, die auf dieser
Ebene noch unabhängig vor der speziellen Anwendungsdomäne sind. Business Objects sind dabei die
Entitäten, die von den Fachleuten einer Anwendungsdomäne bei der Beschreibung eines fachlichen
Geschäftsvorfalls benutzt werden. Die Applikationsdienste dienen eher als Ansatz zur
Automatisierung von Prozessen.
Abbildung 47: Kategorien von Common Business Objects (CBO-Layer)
Als Beispiel für ein solches übergreifendes Business Object kann der Business Partner dienen. Er
kapselt die Charakteristika eines Kunden oder Lieferanten wie z.B. Währung, Beschreibung,
Sprachen. Das Business Object Address definiert eine generische Adresse zur Beschreibung eines Orts
inklusive postalischer Information. Vom Typ Appliaktionsdienst dagegen ist z.B. die Definition der
Klasse Decimal, die Funktionen für Rundung und Ausgabeformatierung enthält.
Viele dieser Common Business Objects enthalten einen allgemeinen Teil, dessen Grundstruktur und
Verhalten allen Applikationsdomänen gemeinsam ist und einen speziell Teil, der spezifische
Funktionalität für eine ganz konkrete Anwendung umfaßt. Während zum Beispiel die Teile eines
Business Partners in Verbindung mit Währungen, Ländern, Sprachen und Adressen allgemein sind,
sind Rollen wie „Beitragszahler“ oder „Geschädigter“ spezifisch für die Versicherungsbranche.
IV.3.2.3. Core Business Processes Layer
Der oberste Layer umfaßt die zentralen Kernprozesse einer Geschäftanwendung. Hierbei handelt es
sich aber nicht um fertige Realisierungen, sondern mehr um die Definition von Basisschnittstellen, die
im konkreten Fall mit Leben versehen werden müssen. Die mitgelieferten Implementationen tun zwar
irgendetwas, können aber nur als Referenz dienen. Die Erweiterungspunkte sind allerdings klar
definiert und so können unterschiedliche Implementationen eines Kernprozesses ohne Änderung der
eigentlichen Anwendung verwendet werden.
© GDV 1999
95
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Abbildung 48: Kern-Geschäftsprozesse in San Francisco
Die folgenden Applikationsdomänen sind in den anfänglichen Designphasen von San Francisco
identifiziert worden und stehen momentan in unterschiedlichem Detaillierungsgrad zur Verfügung:

Business financials (Eingangs-, Ausgangskonten und allgemeine Buchhaltung)

Order Management (Sales Orders und Purchase Orders)

Warehouse Management.
Die obige Abbildung gibt einen groben Überblick der Frameworkstruktur auf dieser Ebene.

Die Eingangs/Ausgangskontenverwaltung enthält die Strukturen und das
Standardverhalten für das Führen von Eingangs-/Ausgangskonten. Unterstützt werden
Geschäftsfunktionen wie Einzahlungen und Auszahlungen, sowie Überweisungen
zwischen internen Konten oder zu Konten von Geschäftspartnern.

Allgemeine Buchhaltung (General Ledger) umfaßt die Struktur und das allgemeine
Verhalten für die Konten einer allgemeinen Buchhaltung ein Firma oder einer ganzen
Hierarchie von Firmen (Company, Enterprise). Beispiele für Geschäftsprozesse wären die
Unterstützung von Journalen und Abschlüssen.

Verkauf (Sales Order Management) umfaßt die Struktur und das allgemeine Verhalten im
Zusammenhang mit der Anlage und Verwaltung von Angeboten und Bestellungen.
Unterstützt werden Geschäftsprozesse wie die Preis- und Rabattermittlung und die
Erstellung von Verträgen und ihre Zuordnung zu Kunden.

Einkauf (Purchase Order Management) umfaßt die Struktur und das allgemeine Verhalten
für im Zusammenhang mit der Anlage und Verwaltung von Bestellungen und den
zugrundeliegenden Verträgen in ihrem gesamten Lebenszyklus.

Bestellwesen (Order Management) umfaßt die Struktur und das gemeinsame Verhalten der
obigen Frameworks für Einkauf und Verkauf. Hierzu gehören z.B. Definitionen für den
Austausch von Daten mit anderen Unternehmen oder Anwendungen. Daten können vor der
Verarbeitung in einem Fremdsystem selektiert und normalisiert werden.

Lagerverwaltung (Warehouse Management) umfaßt die Struktur und das allgemeine
Verhalten für die logistischen Aufgaben eines Lagers. Beispiele für seine Funktionen
wären z.B. das Verschieben von Lagerteilen zwischen einzelnen Lagern und Unterstützung
für die Stücklistenverwaltung. Die Lagerverwaltung definiert auch das Business Object
Product.
96
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
IV.3.3. Wertung
Der Einsatz von San Francisco impliziert momentan eine starke Bindung an IBM und das Framework
im speziellen. Grund dafür ist die durchgehende Konzeption von San Francisco von Modellierung bis
zum Laufzeitsystem inklusive unterstützten Betriebssystemen und Datenbanken. Für viele Dinge
mußten in San Francisco ad hoc - Lösungen gefunden werden, die jetzt mit neuen Standards aus dem
Java Bereich kollidieren. IBM bietet selbst mit dem Component Broker ein Produkt an, das sich
zumindest in Teilen vom Funktionsumfang her mit San Francisco überschneidet. Component Broker
löst z.B. das Persistenzproblem und unterstützt durch seine CORBA-Architektur auch Fremdsysteme.
IBM will sich aber mit San Francisco in Richtung Enterprise JavaBeans entwickeln.
Problematisch ist momentan die Überschneidung mit neuen Entwicklungen im Java-Bereich. JDBC
wird noch nicht unterstützt und das neue Komponentenmodell Enterprise Java Beans konnte bei der
Konzeption von San Francisco noch keine Berücksichtigung finden. San Francisco enthält z.B. eine
umfangreichen und komplexen Persistence Service zur Abbildung persistenter Klassen auf relationale
Datenbanktabellen in DB2 oder Oracle, der sich mit dem Einsatz von EJB-Containern kaum
vereinbaren läßt.
Die grundsätzliche Unterscheidung von Entitäten und Dependents findet sich analog zu den
Vorschlägen der OMG. Hier scheint es sich um ein generell akzeptiertes Konzept zu handeln.
Enterprise JavaBeans definieren ebenfalls Entity Beans.
IBM San Francisco definiert eine Komponentenarchitektur nur im Rahmen des Frameworks und kann
deshalb momentan nicht Basis eines VAA-Referenzmodells sein. Die Kategorisierung der Klassen
einer Anwendung in unterschiedliche Schichten (Foundation, Common, Core, Tower) ist allerdings
ein höherliegendes Konzept, das auch in der VAA-Referenzarchitektur berücksichtigt wird.
IV.4. Enterprise JavaBeans
IV.4.1. Architekturziele und Kontext
Die Enterprise JavaBeans (EJB) Technologie definiert ein Modell für die Entwicklung und
Benutzung von wiederverwendbaren Java Serverkomponenten.
Unter einer Komponente versteht man Softwareeinheiten, die realisiert wurden und zu einem
Anwendungssystem zusammengefügt werden können. Das Komponentenmodell der Java Technologie
heißt JavaBeans. JavaBeans stellt wiederverwendbare Softwarekomponenten zur Verfügung. Die
Enterprise JavaBeans (EJB) Architektur erweitert das JavaBeans Komponentenmodell um die
Unterstützung von Serverkomponenten.
Serverkomponenten werden ausschließlich auf dem Anwendungsserver bereitgestellt. EJB
unterstützt die Entwicklung von verteilten Anwendungen, die auf unterschiedlichen Plattformen
lauffähig sind. Die Funktionalität liegt überwiegend auf der Serverseite. Die Anwendungslogik wird
auf mehrere Objekte aufgeteilt, die auf dem Anwendungsserver zur Verfügung stehen.
In der Java Philosophie ist der Satz “Write once, run anywhere” einer der grundlegenden Prinzipien.
Existiert eine Java Virtuelle Maschine (VM) auf einem beliebigen Betriebssystem, so kann dort eine
Java Anwendung ausgeführt werden. Die Übertragung dieses Prinzips auf die Serverkomponenten ist
nicht ohne weiteres möglich, da diese zusätzliche Dienste benötigen, die von der VM nicht
bereitgestellt werden. Diese Dienste werden entweder vom Anwendungsserver oder von einer
Infrastruktur für verteilte Objekte, wie CORBA oder DCOM, bereitgestellt.
© GDV 1999
97
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Das EJB Modell für Serverkomponenten definiert eine Sammlung herstellerunabhängiger
Schnittstellen für alle Java Anwendungsserver. Dadurch ist gewährleistet, daß Serverkomponenten auf
allen Java-fähigen Anwendungsservern laufen.
IV.4.2. Grundmuster der Architektur
IV.4.2.1. Komponente
Eine Komponente ist eine wiederverwendbare Softwareeinheit. Sie besteht aus gekapseltem
Anwendungscode, der mit weiteren Komponenten oder mit individuellem Code erweitert werden
kann.
IV.4.2.2. Container
Komponenten werden innerhalb eines Containers ausgeführt. Er stellt einen Anwendungskontext für
eine oder mehrere Komponenten bereit und übernimmt deren Verwaltung und Kontrolle. Mit anderen
Worten, der Container stellt die Umgebung (i.a. mehrere Ausführungsfäden (Threads) bereit, in dem
die Komponenten ausgeführt werden.
Die Komponenten auf dem Client werden in der Regel im Rahmen eines visuellen Containers wie
Form, Compound Document oder Web Site eingesetzt.
Die Serverkomponenten dagegen sind in der Regel nicht visualisierbar und werden in einem Container
ausgeführt, der vom Anwendungsserver (z.B. TP-Monitor, Web-Server oder Datenbanksystem)
bereitgestellt wurde.
IV.4.2.3. Das Komponentenmodell
Das Komponentenmodell definiert die Basisarchitektur der Komponenten. Es beschreibt ihre
Schnittstellen und den Mechanismus, wie eine einzelne Komponente mit dem Container oder mit
anderen Komponenten zusammenarbeitet. Außerdem enthält es Richtlinien, wie die Komponenten zu
entwickeln sind. Es ermöglicht den Komponenten, zu einer größeren Anwendung zusammengestellt
zu werden. Dabei ist es nicht erforderlich, daß die Komponenten von einem Herstellern realisiert
wurden.
IV.4.2.4. Granularität der Komponenten
Die Komponenten können unterschiedlich hinsichtlich ihrer Komplexität und Größe sein. Bezüglich
der Granularität werden im Komponentenmodell keine Einschränkungen getroffen.
IV.4.2.5. Standardisierte Schnittstellen
Eine Komponente muß ihre Schnittstellen in standardisierter Form bereitstellen, damit ihre Methoden
von anderen Teilen der Anwendung aufgerufen, und ihre Daten bearbeitet werden können. Die
Struktur der einzelnen Schnittstellen wird im Komponentenmodell beschrieben.
IV.4.2.6. Anpassung ohne Änderung im Source Code
Komponenten werden durch eine Anzahl von externen Parametern an die speziellen Anforderungen
der Anwendung angepaßt. Es muß dafür keine Änderung im Source Code vorgenommen werden.
98
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
IV.4.3. Enterprise JavaBeans Komponentenmodell
Das Enterprise JavaBeans Komponentenmodell ist die logische Erweiterung des JavaBeans
Komponentenmodells.
Das JavaBeans Komponentenmodell definiert standardisierte Mechanismen für die Entwicklung von
wiederverwendbaren, portierbaren Java Softwareeinheiten wie z.B. Buttons oder Controls. Die
JavaBeans Technologie wird in der Regel in einer integrierten Entwicklungsumgebung (Integrated
development environment, IDE) für visuelle Java Technologie, wie z.B. IBM Visual Age oder
Symantec Visual Cafe, benutzt. Java Entwickler benutzen ein visuelles Java IDE, um Java Klassen,
Java Applets, Java Anwendungen oder Java Komponenten zu erzeugen.
Eine JavaBeans Komponente (Bean) ist eine spezielle Java Klasse, die zu einem
Entwicklungsprojekt hinzugefügt und dann von einer IDE bearbeitet werden kann. Eine Bean stellt
spezielle Einstiegspunkte (Hooks) bereit, um Inhalte und Verhalten der Bean zu prüfen und
anzupassen, ohne den Sourcecode zu modifizieren. Es können mehrere Beans kombiniert werden, um
ein Java Applet / Anwendung zu erstellen oder eine JavaBeans Verfeinerung vorzunehmen.
Das EJB Komponentenmodell ist die Erweiterung des JavaBeans Komponentenmodells um die
Unterstützung der Serverkomponenten. Sie sind ähnlich den Entwicklungskomponenten, aber in der
Regel größer und komplexer und können mit anderen Serverkomponenten kombiniert werden. Die
Enterprise JavaBeans Komponenten (Enterprise Beans) konnten bisher nicht durch eine visuelle Java
IDE bearbeitet werden (Tools diesbezüglich sind in der Entwicklung). Statt dessen wurden sie
während ihrer Installation (deployment time) durch Tools bearbeitet, die ein EJB kompatibler
Anwendungsserver zur Verfügung stellt.
IV.4.3.1. Implizite Services
Die Enterprise JavaBeans Architektur stellt ein integriertes Anwendungsframework zur Verfügung,
das die Entwicklung von Enterprise Klassen wesentlich vereinfacht. Der EJB Server verwaltet
automatisch zahlreiche Middleware Services, die von den Anwendungskomponenten angestoßen
werden. Die Designer der Komponenten können sich somit mehr auf die Implementierung der
Fachlogik konzentrieren. Die unterstützten Middleware Services sind insbesondere Life Cycle,
Transaction, Distribution, Persistence, und Security.
Diese Services werden implizit ausgeführt, der Container führt sie automatisch für die Enterprise
Beans aus.
IV.4.3.2. Portabilitätsschicht
Das EJB Modell legt die Beziehung zwischen der Enterprise Bean Komponente und dem Container
fest. EJB Komponenten sind nicht verpflichtet, ein spezielles Containersystem zu benutzen. Ein
Hersteller kann den Anwendungsserver an die EJB Technologie anpassen, indem er den Support für
die in der Spezifikation beschriebenen Services zusätzlich implementiert. Die Sevices definieren einen
Kontrakt zwischen der Enterprise Bean und dem Container, der als Portabilitätsschicht (portability
layer) implementiert wird. Jede Enterprise Bean kann auf jedem Anwendungsserver laufen, der EJB
Kontrakte unterstützt.
© GDV 1999
99
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
IV.4.3.3. Ausführung der Services
Ein EJB kompatibler Anwendungsserver (EJB Server) muß eine Standardmenge von Services zur
Verfügung stellen, um die EJB Komponenten zu unterstützen. EJB Komponenten sind
transaktionsorientiert: d.h., daß ein EJB Server einen Zugriff auf einen Service für verteilte
Transaktionen bereitstellen muß. Zusätzlich muß der EJB Server einen Container für die Enterprise
Beans liefern: den EJB Container. Der EJB Container implementiert die Services für Verwaltung und
Kontrolle von einer oder mehreren Klassen der EJB Objekte. Außerdem muß der EJB Container
Dienste für die Verwaltung der impliziten Dienste bereitstellen.
IV.4.4. Detaillierte Beschreibung der EJB Architektur
Der EJB Server stellt EJB Container zur Verfügung, die die Ausführung von EJB Anwendungen
unterstützten. Er verwaltet und koordiniert die Belegung der Ressourcen für die Anwendung.
Das folgende Bild zeigt den Aufbau des EJB Containers.
Enterprise JavaBeans Container
Deployment
Descriptor
Client
EJB Objekt
(Client view)
Enterprise bean
EJB Home
(bean identifier)
Environment
Abbildung 49 : Enterprise JavaBeans Container
Enterprise Beans werden in einem EJB Container genutzt, der auf dem EJB Server zur Verfügung
steht. Der Container dient als Verbindung zwischen dem Client und der Enterprise Bean. Während der
Installation der Enterprise Bean (deployment time) erzeugt der Container einmalig und automatisch
die EJB Home Schnittstelle und die EJB Objekt Schnittstelle für jede Enterprise Bean Instanz.
Die EJB Home Schnittstelle identifiziert die Enterprise Bean Klasse und wird verwendet, um eine
Enterprise Bean Instanz zu finden, erzeugen oder löschen.
Die EJB Objekt Schnittstelle gewährt Zugriff auf die Methoden der Enterprise Bean. Alle
Anforderungen des Clients, die an die beiden Schnittstellen gerichtet werden, werden durch den EJB
Container abgefangen. Sie werden durch die impliziten Dienste ergänzt.
Der EJB Server stellt einen oder mehrere Container zur Verfügung, die Enterprise Bean Objekte
verwalten. Der Container ist verantwortlich für:
100
© GDV 1999
Das objektorientierte technische Referenzmodell

die Registrierung der Objekte

die Erzeugung und Löschung der Objektinstanzen

Sicherheitsprüfungen für Objekte

Verwaltung der aktiven Zustände im Objekt

Koordinierung verteilter Transaktionen.
Architekturmodelle im Überblick
Optional kann der Container die persistenten Daten im Objekt verwalten.
Bezüglich der Anzahl der installierten EJB Klassen in einem EJB Container gibt es keine
Einschränkung. Es ist ebenfalls nicht festgelegt, wie der Container implementiert werden muß. Er
kann als eine physikalische Einheit integriert werden, wie z.B. ein multithreaded Prozeß auf dem EJB
Server, oder auch als logische Einheit, die unter mehreren Systemen und Prozessen aufgeteilt wird.
IV.4.4.1. Transiente und persistente Objekte
Die EJB Technologie unterstützt sowohl transiente (nicht dauerhafte) als auch persistente (dauerhafte)
Objekte. Transiente Objekte werden als Session Bean, und persistente Objekte als Entity Bean
bezeichnet.
Die Session Beans werden in der Regel vom Client erzeugt und existieren in den meisten Fällen nur
für die Dauer einer einzelnen Client-Server Sitzung. Eine Session Bean führt Operationen wie z.B.
Datenbankzugriff oder Rechenschritte aus, die vom Client initiiert werden. Eine Session Bean kann
nach einem Systemausfall nicht wiederhergestellt werden. Eine Session Bean hat in der Regel keinen
definierten Zustand, kann aber Zustände über Methoden und Transaktionen haben, die sich aus der
Kommunikation zwischen Client und Server ergeben (conversational state). Falls die Session Bean
solche Kommunikationszustände hat und dann gelöscht wird, dann geht die Verwaltung der Zustände
auf den Container über. Eine Session Bean muß ihre eigenen persistenten Daten selbst verwalten.
Eine Entity Bean ist die Objektrepräsentation von persistenten Daten, die z.B. in einer Datenbank
hinterlegt wurden. Ein Primärschlüssel identifiziert jede Instanz einer Entity Bean. Sie werden
entweder durch Einfügen von Daten in die Datenbank, oder durch eine Object Factory Methode
erzeugt. Die Entity Beans sind transaktionsgesichert und lassen sich nach einem Systemausfall
wiederhergestellt werden. Entity Beans verwalten ihre Persistenz selbst oder deligieren die
Verwaltung an den Persistenzdienst ihrer Container. In diesem Fall führt der Container automatisch
alle Operationen für das Auffinden und Speichern der Entity Bean aus.
In der Version 1.0 ist die Unterstützung der Session Beans obligatorisch, die Unterstützung der Entity
Beans und der vom Container verwalteten Persistenz ist optional. In den künftigen Versionen werden
diese Features fester Bestandteil der EJB Spezifikation sein.
IV.4.4.2. Naming und Registry
Für jede im Container angelegte Klasse registriert der Container automatisch die EJB Home
Schnittstellen in einem Verzeichnisdienst mittels JNDI API (Java Naming and Directory Interface).
Durch JNDI kann der Client die EJB Home Schnittstelle finden, die es ihm dann ermöglicht eine
bestehende Bean Instanz zu finden oder eine neue zu erzeugen. Wenn der Client eine Bean erzeugt
oder findet, liefert der Container eine EJB Objektschnittstelle zurück.
© GDV 1999
101
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
IV.4.4.3. EJB Objektschnittstelle
Die EJB Objektschnittstelle ermöglicht dem Client den Zugriff auf die Businessmethoden der
Enterprise Bean. Das EJB Objekt repräsentiert die Client View der Enterprise Bean. Es veröffentlicht
alle anwendungsrelevanten Schnittstellen des Objekts, mit Ausnahme derer, die dem EJB Container
die Verwaltung und Kontrolle über das Objekt erlauben. Mittels eines EJB Object Wrapper fängt der
Container alle Operationen auf, die an die Enterprise Bean gerichtet werden. Nachdem der Client eine
Methode auf dem EJB Objekt aufgerufen hat, geht zuvor die Anforderung über den EJB Container,
um sie anschließend an die Enterprise Bean weiterzuleiten. Der EJB Container implementiert die
Dienste State Management, Transaction, Security und Persistence sowohl für den Client als auch für
die Enterprise Bean.
IV.4.4.4. Deklarierte Attribute
Die mit der Enterprise Bean gemeinsam verwalteten Regeln zu Lifecycle, Transaction, Security und
Persistence werden in einem getrennten Deployment Descriptor definiert. Diese Regeln werden
größtenteils deklarativ zur Installationszeit und weniger programmtechnisch während der Entwicklung
definiert. Während der Laufzeit führt der EJB Container automatisch die Dienste mit den Parametern
aus, die im Deployment Descriptor für die Enterprise Bean hinterlegt wurden.
IV.4.4.5. Kontext Objekt und Environment Objekt
Für jede aktive Enterprise Bean Instanz erstellt der EJB Container ein Kontext Objekt, in dem die
Informationen über die Verwaltungsregeln und den aktuellen Zustand der Instanz gehalten werden.
Eine Session Bean benutzt einen SessionContext, eine Entity Bean benutzt einen EntityContext. Das
Kontext Objekt wird von der Enterprise Bean und dem EJB Container benutzt, um Transaktionen und
Dienste zu koordinieren. Zudem werden die Eigenschaften der Enterprise Bean in einer Tabelle - dem
Environment Objekt - hinterlegt: Dieses Objekt sichert die Zusände des Zusammenstellungsprozeß
(assembly process) oder des Installationsprozeß (deployment process) der Enterprise Bean.
IV.4.5. Beschreibung der Services
IV.4.5.1. Distribution Services
Die EJB Technologie benutzt die Java Remote Method Invocation (RMI) API, um auf die
Enterprise Beans zuzugreifen. Der Designer muß für jede Enterprise Bean eine RMI Remote
Schnittstelle definieren, woraus der Container die EJB Objektschnittstelle generiert.
RMI ist eine Programmschnittstelle, die den Ort des Servers für den Client transparent macht. Der
RMI Compiler generiert ein Stub Objekt für jede entfernte Schnittstelle (Remote Interface). Das Stub
Objekt ist auf dem Client installiert (oder wird zur Laufzeit heruntergeladen), und stellt einen lokalen
Stellvertreter (Proxy) für den Client dar. Das Stub Objekt implementiert alle entfernten Schnittstellen
und delegiert alle Methodenaufrufe zum fernen Objekt durch das Netz.
Die EJB Spezifikation stellt keine Anforderungen an das Protokoll für verteilte Objekte. RMI
unterstützt mehrere Protokolle. Das Java Remote Method Protokoll basiert auf dem RMI Protokoll.
Die nächste Version von RMI unterstützen zusätzlich die Kommunikation mittels CORBA Protokoll
und Internet InterORB Protokoll (IIOP). IIOP unterstützt fast alle Funktionen von RMI. Enterprise
Beans, die sich nur auf die Untermenge RMI/IIOP von RMI stützen, sind für beide Protokolle
geeignet.
102
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
IIOP ermöglicht eine einfache Integration von CORBA und EJB Systemen. Enterprise Beans können
damit auf CORBA Server zugreifen und CORBA Clients können auf Enterprise Beans zugreifen.
Mittels COM/CORBA Internetworking Service können ActiveX Clients auf Enterprise Beans
zugreifen, und Enterprise Beans können auch umgekehrt auf die Dienste eines DCOM Servers
zugreifen. Die Kommunikation zwischen ActiveX Komponenten und Enterprise Java Beans ist
möglich. Enterprise Java Beans können aber nicht ohne weiteres in einem DCOM Server installiert
werden.
IV.4.5.2. State Management
Individuelle EJB Serversysteme implementieren verschiedene Vorgehensweisen. Unabhängig davon
muß jeder EJB Server einen Statusmanager (state manager) für die Verwaltung der Zustände der EJB
Objekte bereitstellen.
Eine Session Bean stellt einen Arbeitsschritt dar, der von einem Client ausgeführt wird. In manchen
Fällen kann dieser Schritt in einem einzigen Methodenaufruf erledigt werden. In anderen Fällen sind
mehrere Methodenaufrufe nötig. Bei solchen Fällen muß der Zustand (state) des Objektes zwischen
den Methodenaufrufen gespeichert werden. Die Optionen für die Zustandsverwaltung für eine Session
Bean werden im Attribut StateManagementType im Deployment Descriptor Objekt definiert.
Die Entity Beans behalten ihren Zustand.
Behält ein Objekt seinen Zustand nicht, setzt der Container den Zustand der Objektinstanz automatisch
nach jedem Methodenaufruf neu. Wenn ein Session Objekt seinen Zustand behält, hält der Container
diesen Zustand automatisch, sobald das Session Objekt zerstört oder temporär aus dem Speicher
enfernt wird. Das EJB Modell kapselt diese Funktionen in die Methoden ejbLoad, ejbStore,
ejbActivate und ejbPassivate in jeder Enterprise Bean Klasse.
IV.4.5.3. Persistence Management
Eine Entity Bean stellt persistente Daten dar. Ein Entitätsobjekt existiert generell über eine längere
Zeit hinaus und kann von vielen Clients benutzt werden. Die EJB Technologie stellt ein einfaches
Programmiermodell dar, um die Persistenz von Objekten zu verwalten. Persistenzfunktionen müssen
ausgeführt werden, wenn Objekte erstellt, gelöscht, geladen oder aus dem Hauptspeicher entfernt
werden. Das EJB Modell kapselt diese Funktionen in die Methoden ejbCreate, ejbPostCreate,
ejbRemove, ejbLoad, ejbStore, ejbActivate und ejbPassivate in jeder Enterprise Bean Klasse.
Ein Entitätsobjekt kann seine Persistenz selbst verwalten oder die Verwaltung an seinen Container
delegieren. Die Optionen für die Persistenz einer Entity Bean sind im Attribut
ContainermanagedFields im Deployment Descriptor Objekt definiert.
Wenn das Entitätsobjekt seine Persistenz selbst verwaltet, muß der Enterprise Bean Designer
Persistenzoperationen (JDBC oder embedded SQL Aufrufe) in die Klassenmethoden der Enterprise
Bean aufnehmen.
Wenn das Entitätsobjekt die Persistenz an den Container delegiert, verwaltet der EJB Container
implizit und transparent die Persistenz. Der Designer der Enterprise Bean muß selbst keine
Zugriffsmethoden in die Enterprise Bean Klassenmethoden aufnehmen. Die erste Version EJB
Spezifikation legt nicht fest, wie der EJB Container die Persistenz der Objekte verwalten soll. Es wird
dem Hersteller überlassen, ob er eine einfache Serialisierung der Zustände in den Container
© GDV 1999
103
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
implementiert oder einen optimaleren Service nimmt, wie z.B. die Hinterlegung der persistenten Daten
des Objekts in die Spalten einer relationalen Datenbank.
Die Session Objekte sind nach Definition nicht persistent. Sie können jedoch Informationen enthalten,
die persistent gemacht werden müssen. Ähnlich wie bei den Entitätsobjekten können die Session
Objekte persistente Operationen direkt in der Enterprise Bean implementieren. Die Session Objekte
halten häufig gecachte Datenbankinformationen bereit, die mit der Datenbank synchronisiert werden
müssen, z.B. wenn eine Transaktion gestartet, abgebrochen oder beendet wird. Der Entwickler der
Enterprise Bean kann die Methoden für das Synchronisieren der Transaktionen mittels der
Schnittstelle SessionSynchronisation direkt in die Enterprise Bean Klasse aufnehmen. Die afterBeginn,
beforeCompletion und afterCompletion Aufrufe bezeichnen Markierungspunkte, die dem Objekt
erlauben, gegebenenfalls aus der Datenbank zu lesen oder in die Datenbank zu schreiben.
IV.4.5.4. Transaction Management
Obwohl die EJB Technologie durchaus für die Implementierung nicht transaktionsgesicherter Systeme
verwendet werden kann, wurde sie für die Unterstützung von verteilten Transaktionen entworfen. Die
EJB Technologie benötigt einen verteilten Transaktionsmonitor, der ein Two Phase Commit Protokoll
für nicht geschachtelte Transaktionen unterstützt.
Die EJB Spezifikation legt die Verwendung von Transaktionen aus der Java Transaction Service
(JTS) API nahe, schreibt sie aber nicht dringend vor. JTS ist eine Implementierung des CORBA
Object Transaction Service (OTS) in Java. JTS unterstützt verteilte Transaktionen, die mehrere
Datenbanken auf verschiedenen Systemen umfassen können, die wiederum von mehreren
Transaktionsmanagern verwaltet werden. Mittels JTS stellt ein EJB Server sicher, daß seine
Transaktionen mehrere EJB Server umfassen können.
Die EJB Anwendungen kommunizieren mit dem Transaktionsservice mittels Java Transaktion API
(JTA). JTA stellt eine Programmierschnittstelle für Start, Wechseln, Commit und Rollback einer
Transaktion bereit.
Die EJB Technologie vereinfacht die Entwicklung von Anwendungen mit verteilten Transaktionen.
Alle Transaktionsfunktionen können implizit vom EJB Container und dem EJB Server ausgeführt
werden. Einzelne Enterprise Beans brauchen keine Java-Statements für Transaktionsmarkierungen in
ihren Code aufzunehmen. Da kein Transaktionscode in der Anwendungslogik erscheint, sind die
Enterprise Beans einfacher zu implementieren und zu portieren. Die Transaktionsregeln für eine
Enterprise Bean werden eher deklariert als programmiert. Zur Laufzeit implementiert der EJB
Container automatisch die Transaktionsservices, wie sie im Attribut TransactionAttribute im
Deployment Descriptor Objekt festgelegt wurde.
Das EJB Modell unterstützt sechs verschiedene Transaktionsregeln:



TX_BEAN_MANAGED. Mit TX_BEAN_MANAGED verwaltet die Enterprise Bean ihre
Transaktionskontrolle manuell. Die Abgrenzung der Transaktion erfolgt mittels Java Transaction
API.
TX_NOT_SUPPORTED. Mit TX_NOT_SUPPORTED wird die Enterprise Bean im Kontext der
Transaktion nicht ausgeführt. Falls der Client bereits eine Transaktion beim Start der Enterprise
Bean mitbringt, setzt der Container die Transaktion für die Dauer des Methodenaufrufs aus.
TX_SUPPORTS. TX_SUPPORTS bedeutet, daß die Enterprise Bean mit oder ohne
Transaktionskontext ausgeführt werden kann. Falls der Client bereits eine Transaktion beim Start
104
© GDV 1999
Das objektorientierte technische Referenzmodell
Architekturmodelle im Überblick
der Enterprise Bean mitbringt, wechselt die Methode in den Transaktionskontext des Clients,
anderenfalls läuft der Methodenaufruf ohne Transaktion ab.



TX_REQUIRED. TX_REQUIRED fordert die Ausführung einer Enterprise Bean in einem
Transaktionskontext. Falls der Client bereits eine Transaktion beim Start der Enterprise Bean
mitbringt, wechselt die Methode in den Transaktionskontext des Clients, ansonsten wird eine neue
Transaktion gestartet.
TX_REQUIRES_NEW. TX_REQUIRES_NEW fordert die Ausführung einer Enterprise Bean in
einem neuen Transaktionskontext. Falls der Client bereits eine Transaktion beim Start der
Enterprise Bean mitbringt, setzt der Container diese Transaktion für die Dauer des
Methodenaufrufs aus und startet eine neue Transaktion.
TX_MANDATORY. TX_MANDATORY fordert die Ausführung der Enterprise Bean im Kontext
der Transaktion des Clients. Falls der Client bereits eine Transaktion beim Start der Enterprise
Bean mitbringt, gibt der Container die Fehlermeldung TransactionRequired aus und die
Anforderung wird abgewiesen.
IV.4.5.5. Security
Das EJB Modell verwendet die Java Sicherheitsdienste, die vom Java Development Kit (JDK) 1.1.x
unterstützt werden. Die Java Plattformsicherheit unterstützt Berechtigungs- und Autorisierungsdienste,
um Zugriff auf geschützte Objekte zu unterbinden. Die EJB Technologie automatisiert die Benutzung
der Java Plattformsicherheit, so daß die Enterprise Bean nicht mit Sicherheitsroutinen ausgestattet
werden muß. Die Sicherheitsregeln für jede Enterprise Bean werden in mehreren AccessControlEntry
Objekten im Deployment Descriptor Objekt hinterlegt. Ein AccessControlEntry Objekt ordnet einer
Methode die Liste der Benutzer zu, die berechtigt sind, diese Methode anzuwenden. Der EJB
Container benutzt AccessControlEntry, um Sicherheitsprüfungen für die Enterprise Bean auszuführen.
IV.4.6. Enterprise JavaBean Deployment
Die Komponenten der EJB können als einzelne oder als Kollektion von Enterprise Beans, sowie als
ein komplettes Anwendungssystem verpackt werden. EJB Komponeten werden im Java Archive
(JAR) File Format (ejb-jar file) ausgeliefert. Diese Datei enthält ein Verzeichnis über den Inhalt der
Datei, die Enterprise Bean Klassen, die Deployment Descriptor Objekte und optional die
EnvironmentProperties Objekte.
Die Deployment Descriptor Objekte werden verwendet, um die Laufzeiteinstellungen einer
Enterprise Bean festzulegen. Diese Einstellungen teilen dem EJB Container mit, wie die Enterprise
Bean zu verwalten ist. Gesetzt werden diese Werte beim Konfigurieren (Application Assembly Time)
oder während der Installation (Application Deployment Time) der Anwendung.
Deployment Descriptor Objekte definieren unter anderem den Klassennamen der Enterprise Bean, den
JNDI Namen, der den Container repräsentiert, den Namen des Home Interface, des Remote Interface
und des Environment Properties Objekts. Das Deployment Descriptor Objekt enthält ein Array von
ControlDescriptor Objekten, das die Transaktionsregeln festlegt. Für die Hinterlegung der
Sicherheitsregeln enthält es außerdem das Array von AccessControlEntry Objekten.
Session Beans und Entity Beans haben verschiedene Typen von Deployment Descriptor Objekte.
Das SessionDescriptor Objekt erweitert das Deployment Descriptor Objekt um die Attribute, in
denen gespeichert wird, ob die Session Bean ihren Zustand behalten soll oder nicht.
© GDV 1999
105
Architekturmodelle im Überblick
Das objektorientierte technische Referenzmodell
Das EntityDescriptor Objekt erweitert das Deployment Descriptor Objekt um die Attribute, in denen
gespeichert wird, welches Feld automatsch vom Container persistent gemacht wird.
IV.4.7. Wertung
Die Spezifikation der Enterprise JavaBeans ist in sich stimmig und empfiehlt sich zur Konzeption von
Serveranwendungen. Es handelt sich aber nicht um ein fertiges Produkt und somit hängt der Erfolg der
Spezifikation von der Qualität der einzelnen Herstellerimplementationen ab.
Die aktuelle Version 1.0 enthält noch nicht alle Dienste, die zur Erstellung von Applikationen
erforderlich sind. Für diese Version gibt es inzwischen schon einige Implementation, z.B. innerhalb
von Oracle 8i, Oracle Application Server, IBM WebSphere Advanced Edition, BEA WebLogic
Tengah und den von SUN aufgekauften Server von NetDynamics. Anwendungssoftwarehersteller, die
EJB Komponenten implementieren, sind z.B. IBM San Francisco Frameworks, Athena Design Integer
und Oracle Applications (ERP).
Gerade die geplante Unterstützung von EJB im Rahmen des San Francisco Projektes erscheint
vielversprechend, denn bei einem Auseinanderlaufen dieser beiden Architekturen wäre fraglich, ob der
Markt sowohl den Foundation Layer der San Francisco Frameworks als auch die konkurrierende EJB
Architektur akzeptieren würde.
Durch die an sich zu begrüßende Offenheit der Spezifikation sind Entscheidungen bezüglich
Realisierung der einzelnen Komponenten langwierig. Das verzögert die Produktion einzelner Teile der
Spezifikation, wie man an der aktuellen Roadmap für die Version 2.0 sieht. Gelegentlich werden Teile
der Spezifikation gar nicht erst realisiert, da sich die Anforderungen des Marktes inzwischen geändert
haben.
106
© GDV 1999
Das objektorientierte technische Referenzmodell
Ausblick
V. Ausblick
Technisches und fachliches Referenzmodell bilden die Grundlage für die Definition und Realisierung
versicherungsfachlicher Softwarekomponenten. Der Grad der Detaillierung wurde im technischen
Referenzmodell so gewählt, daß unterschiedliche Implementierungsplattformen auf Basis der
CORBA-Services möglich sind. Noch läßt der Stand des Standardisierungsprozesses eine genauere
Spezifikation nicht zu, es zeichnet sich jedoch eine Konvergenz unterschiedlicher KomponentenArchitekturen ab. Dadurch scheint die Schaffung austauschbarer Softwarekomponenten für die
Versicherungswirtschaft erstmals realisierbar zu werden.
Konvergenz
der Architekturen
SanFrancisco
?
Enterprise
JavaBeans
CORBA
Component Model
1998
1999
2000
Abbildung 50: Konvergenz der Komponenten-Architekturen
Neben der Kompatibilität von Komponenten auf technischer Ebene sind einheitliche Schnittstellen auf
fachlicher Ebene notwendig. Die Basis hierfür schafft das fachliche Referenzmodell. Derzeit ist dessen
Detaillierungsgrad nicht ausreichend für eine präzise Schnittstellendefinition versicherungsfachlicher
Komponenten, eine Verfeinerung in diese Richtung ist für 1999 bereits vorgesehen.
An der Schnittstelle zwischen technischen und fachlichen Modellen stehen eine Anzahl von Diensten
und Verfahren, deren Gestaltung eines der Themen für die Weiterentwicklung des technischen
Referenzmodells in 1999 sein wird:
-
Hilfedienst
-
Ordnungsbegriffe
-
Protokollierung/Journal
-
Print/Dokumentation
-
Terminverwaltung
-
Benutzerverwaltung und Kompetenzregelungen
-
Fehlerbehandlung
-
Objektversionierung und Historisierung
-
Prozeßsteuerung und Ablaufverfolgung
© GDV 1999
107
Ausblick
Das objektorientierte technische Referenzmodell
-
Archivierung
-
Postkorbverwaltung
Auch die Gestaltung dieser Dienste und Verfahren wird sich an allgemeinen Standards oder Standards
der Versicherungswirtschaft orientieren.
108
© GDV 1999
Das objektorientierte technische Referenzmodell
Glossar
VI. Glossar
Folgende Begriffe wurden in das Glossar aufgenommen:
 Allgemeine Begriffe aus der objektorientierten Welt
 Begriffe aus der objektorientierten Entwicklung
 neue Definitionen der objektorientierten VAA-Referenzarchitektur
Active X
Micosofts Bezeichnung für seine strategischen objektorientierten Technologien und Werkzeuge.
Zentrale Technologie ist das Component Object Model (COM). Aus COM wird im Netzwerk mit
Verzeichnisdiensten und weiterer Unterstützung das Distributed Component Object Model (DCOM).
ActiveX - Komponenten heißen ActiveX - Controls oder ActiveX - Documents und sind grob
vergleichbar mit Suns Java Applets. Sie sind die Weiterführung der mit Object Linking and
Embedding (OLE) entwickelten Compound Document Architecture von Microsoft.
Basic Objekt Adapter (BOA)
Ein von CORBA definierter Objektadapter, den alle ORB’s unterstützen müssen. Dieser hat die
Aufgabe, ein Implememtierungsverzeichnis bereitzustellen, das es ermöglicht, alle
Objektimplementierungen zu installieren und zu registrieren. Zusätzlich stellt er Mechanismen bereit,
Objektreferenzen zu generieren und zu interpretieren um Objektimplementierungen zu aktivieren oder
zu deaktivieren.
Business Object (BO)
Ein Business Object (BO) repräsentiert einen fachlichen Ablauf oder eine fachliche Entität. Ein
fachlicher Ablauf ist dabei im Sinne eines Geschäftsvorfalls zu verstehen, wie er in VAA 2.0 definiert
ist (Beispiel: „Erhöhung der Versicherungssumme eines Vertrages„). Eine fachliche Entität stellt eine
fachlich orientierte Einheit von Daten und darauf operierender Funktionen dar, wie zum Beispiel
Vertrag oder Partner.
Business Object Component Architecture (BOCA)
Von der BODTF definiertes Metamodell für Business Objects. Dieses Metamodell ist eine
Erweiterung des CORBA-Metamodells, das CORBA-IDL und dem CORBA-Interface-Repository
zugrunde liegt
Business Object - Manager (BO-Manager)
Er stellt den Lebensraum eines Business Objects zur Verfügung, weiß aber nichts über den internen
Aufbau eines Business Objects.
Component Object Model (COM)
COM ist Microsofts Framework zur Entwicklung von Komponenten. Die Zielrichtung ist vergleichbar
mit der von JavaBeans. COM stellt Services wie Life Cycle Management, Licensing, Event für
Microsofts Compound Document Architecture OLE zu Verfügung.
© GDV 1999
109
Glossar
Das objektorientierte technische Referenzmodell
CORBA
CORBA ist eine Spezifikation der Object Management Group (OMG), die die Interoperabilität von
verteilten Objekten beschreibt. Bestandteile sind der Objekt Request Broker (ORB), der als
transparenter Kommunikationsbus zwischen den Objekten fungiert und die CORBA-Services, die
definierte Dienste zur Verfügung stellen, die auf der Systemebene des ORB´s agieren. Zusätzlich
beinhaltet CORBA die CORBA-Facilities, die Services auf der Anwendungsebene bereitstellen sowie
die CORBA-Business Objects (Geschäftsobjekte).
Distributed Component Object Model (DCOM)
DCOM ist Microsofts Framework zur Entwicklung von verteilten Komponenten und die direkte
Weiterentwicklung von COM mit einem mit CORBA vergleichbaren Funktionsumfang.
Distributed Internet Architecture (DNA)
Anwendungs-Architektur von Microsoft, die in einem Framework von verteilten Einzellösungen das
Internet mit einer Client-/Server-Architektur integriert. Sie ist ein Multi-Tier Anwendungsmodell und
Bestandteil der Microsoft Applikations-Plattform. DNA vereint die besten Services von Clients,
Anwendungsservern
und
Mainframes
zu
einer
allgemeinen,
komponentenbasierten
Anwendungsarchitektur.
Dynamic Invocation Interface (DII)
DII ist ein Bestandteil von CORBA, der es dem Client erlaubt, sich zur Laufzeit ein Zielobjekt
auszuwählen und seine Methoden dynamisch aufzurufen.
Dynamic Skeleton Interface (DSI)
DSI ist das Gegenstück zu DII auf dem Server. Es ermöglicht die dynamische Verknüpfung von
Servern zur Laufzeit, die eingehende Methodenaufrufe der Komponenten bearbeiten müssen, die keine
IDL-basierten Schnittstellen haben.
Enterprise JavaBeans
Die Enterprise JavaBeans (EJB) Technologie definiert ein Modell für die Entwicklung und Benutzung
von
wiederverwendbaren
Java-Serverkomponenten.
Es
definiert
eine
Sammlung
herstellerunabhängiger Schnittstellen für alle Java-Anwendungsserver. Dadurch ist gewährleistet, daß
Serverkomponenten auf allen Java-fähigen Anwendungsservern laufen.
Entity Business Objekt (EBO)
Faßt Daten (Attribute) und die ihnen zugeordneten Funktionen (Methoden) zu logischen Einheiten
zusammen.
Factory
Eine Factory ist ein Entwurfsmuster für die Erzeugung von Objekten. Es ermöglicht die dynamische
Wahl eines Objekttyps abhängig von Parametern oder Konfigurationseinstellungen.
Framework
110
© GDV 1999
Das objektorientierte technische Referenzmodell
Glossar
Ein Framework ist eine Anzahl kooperierender Klassen, die einen wiederverwendbaren Entwurf für
eine besondere Art von Software darstellen. Es legt die Architektur einer Anwendung fest. Ein
Framework ist jedoch mehr als eine Klassenbibliothek, es ist vielmehr eine Miniaturanwendung mit
sowohl vollständiger dynamischer als auch statischer Struktur.
IBM San Francisco
Von IBM entwickeltes Komponentenmodell, das einen Satz von in wechselseitiger Beziehung
stehenden Geschäftsobjekten und Anwendungsdiensten bereitstellt. Das Komponentenmodell dient
Softwarehäusern als Basis zur Entwicklung von Geschäftsanwendungen. Es enthält allgemeingültige
Geschäftsanwendungen (z.B. Buchhaltung, Einkauf, Verkauf, Lagerverwaltung), Basisfunktionen
(z.B. Persistenz, Transaktionen usw.) und von IBM entwickelte Kernkomponenten (z.B. Partner).
Interface Definition Language (IDL)
Sprach- und systemunabhängige Beschreibungssprache für Interfaces. Sie erlaubt es, alle CORBAObjekte gleich zu beschreiben.
Internet Inter-ORB Protocol (IIOP)
Es legt fest, wie GIOP- (General Inter-ORB Protocol) Nachrichten über ein TCP-IP-Netzwerk
ausgetauscht werden können. GIOP definiert eine Menge von Nachrichtenformaten und
Datendarstellungen für die Kommunikation zwischen den ORB’s.
Interoperability Specification
Definition von Kategorien von Objekten inklusive ihres grundlegende Verhaltens und
Strukturvorgaben.(„Systemarchitektur„) und die benötigten technischen Funktionen wie
Datenspeicherung und Transaktionsmanagement auf die CORBA - Dienste und InterfaceSpezifikationen abzubilden („Technische Architektur„).
Ziel ist die Integration der Corba-Services in eine Systemarchitektur für Geschäftsanwendungen und
das Zusammenspiel zwischen ORB-Funktionen und Business-Objekten. InterOp vereinfacht die
Verwendung bestehender CORBA-Services durch Kapselung der Implementierungsdetails in
Steuerobjekten und Basisklassen.
Iterator
Iteratoren sind Zähler, die es ermöglichen, durch eine Anzahl von Objekten zu navigieren und auf
Elemente darin zuzugreifen. Zusätzlich können Zähler dazu benutzt werden, gezielt Elemente zu lesen,
zu ersetzen, zu löschen oder hinzuzufügen.
Komponente
Eine Komponente ist ein gekapselter Teil eines Software-Systems, die eine Schnittstelle hat, die den
Zugang zu ihren Methoden ermöglicht. Komponenten sind die Bausteine für die Struktur eines
Systems.
Language Binding Spezifikation
Für die Implementierung von IDL-Schnittstellen benutzte Beschreibung, die festlegt, auf welche
Datentypen und Strukturen der jeweiligen Programmiersprache die IDL-Spezifikationen abgebildet
werden.
© GDV 1999
111
Glossar
Das objektorientierte technische Referenzmodell
Look & Feel
Look & Feel einer graphischen Oberfläche legt fest, wie die Masken aufgebaut sind, welche
Fenstertechnik verwendet wird und welche Elemente (Push-Buttons, List-Boxes, etc.) diese enthalten.
Modell
Das Modell enthält den funktionalen Kern der Anwendung. Es kapselt die entsprechenden Daten und
bietet Operationen an, welche die für die Anwendung spezifische Verarbeitungen vornimmt.
MVC - Model View Controller
Das Model-View-Controller-Konzept (MVC) unterteilt eine interaktive Anwendung in drei
Komponenten. Das Modell enthält die Kernfunktionalität und die Daten. Die Ansichten (Views)
präsentieren dem Anwender Informationen. Kontrollkomponenten sind für Bedienereingaben
verantwortlich. Ansichten und Kontrollkomponenten zusammen umfassen die Bedienerschnittstelle.
Ein Mechanismus zur Benachrichtigung über Änderungen sichert die Konsistenz zwischen der
Bedienerschnittstelle und dem Modell.
Namenskontext
Ein Namenskontext ist ein Lebensraum von Objekten, in dem der Name eines Objekts eindeutig
festgelegt ist. Der Namenskontext ist vergleichbar mit einer Verzeichnisstruktur. Innerhalb des
gleichen Verzeichnisses können keine zwei Dateien mit dem selben Namen existieren.
Objektreferenz
Die Objektreferenz stellt Informationen zur Verfügung, die benötigt werden, um ein Objekt in einem
verteilten System eindeutig zu identifizieren.
OMG
Die Object Management Group (OMG) ist ein Konsortium verschiedener Unternehmen der ComputerIndustrie, die mit der CORBA-Spezifikation eine Beschreibung für eine Middleware- und
Komponentenarchitektur vorgelegt hat.
Object Request Broker (ORB)
Der Object Request Broker (ORB) ist der Kommunikationsbus, auf dem Client-Objekte mit verteilten
Server-Objekten plattformunabhängig kommunizieren können. Er ist unter anderem zuständig für die
Übertragung der Aufrufparameter, der plattformabhängigen Formatierung der Werte und der
Erzeugung einer systemübergreifenden Objektreferenz
Präsentationsebene
Die Präsentationsebene bündelt die Aufgaben des Views und des Controllers gemäß des MVCEntwurfsmusters. Sie übernimmt eigenständig alle Aufgaben, die zur Präsentation von Business
Objects benötigt werden. Jedes Business Object kann eine oder mehrere Präsentationen haben.
Process Business Objekt (PBO)
Ein
PBO
repräsentiert
einen
fachlichen
Ablauf
im
Sinne
eines
Vorgangs/Geschäftsvorfalls/Geschäftsprozesses. Es verfügt auch über Attribute, die den aktuellen
112
© GDV 1999
Das objektorientierte technische Referenzmodell
Glossar
Schritt innerhalb des Vorganges repräsentieren, sowie über Übergangsbedingungen von einem Schritt
zum nächsten.
Remote Method Invocation (RMI)
Die RMI ermöglicht dem Anwendungsentwickler die Erstellung von verteilten JAVA-Anwendungen.
Dabei können JAVA-Objekte von anderen virtuellen Maschinen oder auch von entfernten Rechnern
aufgerufen werden. RMI dient als Kommunikationsverbindung von verteilen JAVA-Objekten.
Unified Modelling Language (UML)
Die UML ist eine Modellierungssprache für objektorientierte Paradigmen. Sie besteht aus
Modellierungsdiagrammen und dem UML-Metamodell.
Virtual Machine (VM)
Von Sun für die Java Programmierumgebung neu belebter Begriff. Eine Virtual Machine agiert als
Schnittstelle zwischen kompilierten Java Binärkode und dem Prozessor oder der Hardwareplattform,
auf der die Programminstruktionen direkt ablaufen. Sobald für eine Plattform eine Java Virtual
Machine zur Verfügung steht, können alle Javaprogramme (Bytecodes) auf dieser Plattform
ausgeführt werden.
Wrapper
Durch die Verwendung von Wrappern für Softwarekomponenten, werden diese mit einer
Objektschnittstelle entsprechend der CORBA-Interface Definition Language (IDL) versehen und vom
ORB wie „echte“ Objekte angesehen.
X/Open DTP (Distributed Transaction Processing)
Transaktionsmodell, das aus einer Haupttransaktion ohne Child-Transaktionen besteht
© GDV 1999
113
Literatur
Das objektorientierte technische Referenzmodell
VII. Literatur
i
„Das objektorientierte fachliche Referenzmodell“, Version 1.0, März 1999, GDV
ii „CORBAservices: Common Object Services Specification“, Updated Edition, Dezember 1998, Object
Management Group
iii „The Common Object Request Broker - Architecture and Specification“, Revision 2.2, Februar 98, Object
Management Group
iv „Common Facilities Architecture“, Revision 4.0, November 1995, Object Management Group
v „Die Anwendungsarchitektur der Versicherungswirtschaft - Grundlagen und Prinzipien“, GDV, 1999
vi „CORBA vs. DCOM“, Meta Group Consulting, March 20, 1998
vii „Client/Server Programming with Java and CORBA“, 2nd Edition, R.Orfali u.a., 1998
viii „Business Object Component Architecture (BOCA)“, Revision 1.1, OMG Business Domain Task Force,
BODTF-RFP 1 Submission, OMG document bom/98-01-07, Object Management Group
ix „Interoperability Specification“, OMG Business Domain Task Force, BODTF-RFP 1 Submission, Feb. 5,
1998, Object Management Group
x „Entwurfsmuster“, E. Gamma u.a., 1996
xi OMG document orbos/97-11-24, Object Management Group
xii „Entwurfsmuster“, E. Gamma u.a., 1996
xiii
Enterprise JavaBeans Specification, Version 1.0, www.javasoft.com/products/ejb/docs.html
„IBM SanFrancisco Project Technical Summary“, www.ibm.com/java/Sanfrancisco/technical.html,
xiv
IBM
xv „Pattern-orientierte Software-Architektur“, F. Buschmann u.a., 1998
xvi
„Wiederverwendung von Softwarekomponenten durch entkoppelte Schnittstellen“, G. Wanner & K.-D.
Jäger in OBJEKTspektrum 1/99
114
© GDV 1999