otrm - GDV-Online Homepage

Transcrição

Final Edition
Das Objektorientierte Technische Referenzmodell
Version 2.0
Autoren:
Das Projektteam "OO technische Referenzmodell"
Administration, Koordination: Gesamtverband der Deutschen Versicherungswirtschaft e.V., Berlin
http://www.gdv.de/vaa
© GDV 2001
Willkommen bei VAA Final Edition!
Liebe Leserin, lieber Leser,
haben Sie bereits eine der Broschüren der VAA Final Edition gelesen? Dann können Sie gleich weiter
blättern, denn dieses Kapitel steht gleichlautend am Anfang jedes Dokuments dieser VAA-Edition.
Wir freuen uns über Ihr Interesse an der Versicherungs-Anwendungs-Architektur und gratulieren
Ihnen zu Ihrer Entscheidung, sich mit diesem Thema zu beschäftigen. Daran haben wir seit Jahren mit
Engagement und Spaß gearbeitet, was in der Qualität der Ergebnisse seinen Niederschlag findet, wie
wir glauben.
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 auf der VAA-CD und im Internet
(Adresse http://www.gdv.de/vaa) nachlesen.
Nun zur Sache:
Wir können die erfreuliche Mitteilung machen, daß die VAA-Initiative erfolgreich zum Abschluß
gekommen ist. Nachdem wir in einer ersten Arbeitsphase von ca. 1994 bis 1997 die sog. prozedurale
Architektur (pVAA) konzipiert und beschrieben haben, entwickelten wir im Anschluß daran im
Zeitraum von 1997 bis 2000 die objektorientierte Architektur (oVAA) als fachliches und technisches
Referenzmodell und darauf aufbauend das VAA-Komponentenmodell.
Alle Arbeitsergebnisse wurden abschließend dokumentiert. Dabei entstand eine Reihe von zum Teil
sehr umfangreichen Dokumenten, die auf drei Wegen veröffentlicht werden:
•
CD-ROM,
•
Internet
•
und zum Teil als gebundene Broschüren in Papierform.
Um Ihnen die Orientierung zu erleichtern, haben wir als Übersicht über die verfügbaren
Dokumentationen der VAA Final Edition einen grafischen Wegweiser erstellt, den Sie auf der
nächsten Seite finden können. Möglicherweise kann er Ihnen dabei behilflich sein, Ihre Sie
interessierenden Schwerpunktthemen schnell zu finden.
Viel Spaß beim Studium der VAA-Unterlagen.
© GDV 2001
Dokumentenstruktur der VAA Final Edition
Management Summary
neu
Anforderungen und Prinzipien
überarbeitet
Glossar
VAA prozedural (pVAA) Version 2.1
Prozeduraler Rahmen
überarbeitet
Technische Beschreibung
Datenmanager
Datenmanager Historienführung und Anhang
Dialogmanager
Parametersystem
Workflow-/Vorgangsmanager
Fachliche Beschreibung
Inkasso/Kontokorrent
Partner
Partner/Anhang
Produkt
Provision
Schaden/Leistung
Vertrag
VAA objektorientiert (oVAA) Version 2.0
überarbeitet
Das Objektorientierte Fachliche Referenzmodell
überarbeitet
Fachliche Modelle in MID-Innovator-Format
neu
Fachliche Modelle in HTML-Format
neu
Fachliches Referenzmodell aus Edition 1999
Generischer Produktansatz
Das Fachliche Komponentenmodell
neu
neu
© GDV 2001
Inhalt
Inhaltsverzeichnis
1. Einführung und Überblick ........................................................................................ 7
1.1. Kontext ................................................................................................................................ 7
1.2. Elemente des technischen Referenzmodells...................................................................... 8
1.2.1. Die technische Architektur............................................................................................ 9
1.2.2. Die Systemarchitektur ................................................................................................ 10
1.2.3. Fachliche Komponenten und technisches Referenzmodell ....................................... 10
2. Die technische Architektur der VAA ..................................................................... 13
2.1. Die Object Management Architecture (OMA) ................................................................... 14
2.1.1. Definitionen und Grundbegriffe .................................................................................. 14
2.1.2. Der Object Request Broker (ORB) ............................................................................. 16
2.1.3. CORBA 3.0 und Java ................................................................................................. 16
2.1.4. CORBA Components ................................................................................................. 18
2.2. Distributed Internet Architecture (DNA)........................................................................... 22
2.2.1. Definition und Grundbegriffe ...................................................................................... 22
2.2.2. Komponenten ............................................................................................................. 22
2.2.2.1. Präsentation......................................................................................................... 23
2.2.2.2. Anwendungsservice............................................................................................. 24
3. Die Systemarchitektur der VAA ............................................................................. 25
3.1. Komponente...................................................................................................................... 25
3.2. Business Object ................................................................................................................ 27
3.2.1. Definition..................................................................................................................... 27
3.2.2. Struktur eines Business Objects ................................................................................ 28
3.2.3. Typisierung ................................................................................................................. 29
3.2.3.1. Entity Business Object (EBO).............................................................................. 29
3.2.3.2. Process Business Object (PBO).......................................................................... 30
3.2.4. Interfaces von Business Objects ................................................................................ 31
3.2.5. Dienste ....................................................................................................................... 33
3.2.5.1. BO-Manager - Framework und BO-Persistence Service .................................... 33
3.2.5.2. Transparenter Zugriff auf Methoden eines Business Objects ............................. 35
3.2.5.3. Transparentes Speichern von Business Objects................................................. 36
3.2.5.4. Suchen von Business Objects ............................................................................. 38
3.2.5.5. Erzeugen von Business Objects.......................................................................... 38
3.2.5.6. Löschen von Business Objects............................................................................ 39
3.2.5.7. Transaktionsmanagement ................................................................................... 39
3.2.5.8. Verwalten von BO-Beziehungen ......................................................................... 41
3.2.5.9. Parametrisierung von Business Objects.............................................................. 41
3.2.5.10. Benachrichtigungsdienst zwischen Business Objects....................................... 42
3.2.6. VAA Business Object Metamodell.............................................................................. 43
3.3. Fachlich motivierte Dienste ............................................................................................... 43
3.3.1. Prozeßsteuerung ........................................................................................................ 43
3.3.1.1. Problemstellung ................................................................................................... 43
3.3.1.2. Standards der WfMC und OMG........................................................................... 44
3.3.1.3. Abbildung auf das VAA - Referenzmodell ........................................................... 47
3.3.1.4. Prozesszustände ................................................................................................. 48
3.3.1.5. Administration und Überwachung........................................................................ 49
3.3.1.6. Zuordnung von Ressourcen ................................................................................ 50
3.3.1.7. Informationstransport im Prozess: die Vorgangsakte.......................................... 52
3.3.1.8. Implementierung einer Prozesssteuerung........................................................... 54
3.3.1.9. Vom Prozessdesign zum PBO ............................................................................ 57
3.3.2. Dokumentenerstellung ............................................................................................... 60
3.3.2.1. Technischer Dienst „Print“ ................................................................................... 61
3.3.2.2. Fachlicher Dienst „Dokumentenerstellung“ ......................................................... 62
3.3.3. Benutzer / Kompetenzdienst ...................................................................................... 64
3.3.3.1. Berechtigung / Authentifikation ............................................................................ 64
© GDV 2001
i
Inhalt
3.3.3.2. Vollmachten .........................................................................................................67
3.3.3.3. Systeme mit eigener Berechtigungsprüfung........................................................67
3.3.3.4. Berechtigungsklassen ..........................................................................................68
3.3.3.5. Interfaces .............................................................................................................68
3.3.4. Ausnahme und Fehlerbehandlung .............................................................................69
3.3.4.1. Definition: .............................................................................................................69
3.3.4.2. Beschreibung .......................................................................................................69
3.3.5. Postkorb......................................................................................................................73
3.3.5.1. Beschreibung des Postkorbs ...............................................................................73
3.3.5.2. Funktionalität des Postkorbs................................................................................74
3.3.5.3. Termin und Wiedervorlage...................................................................................75
3.3.5.4. Schnittstellen........................................................................................................75
3.3.5.5. Beispielablauf.......................................................................................................75
3.3.6. Historisierung..............................................................................................................76
3.3.6.1. Fachlicher Aspekt.................................................................................................76
3.3.6.2. Ein möglicher konkretes Lösungsansatz .............................................................79
3.3.7. Suchdienst ..................................................................................................................81
3.3.8. Event-Manager ...........................................................................................................81
3.3.9. Business Objects und Komponenten .........................................................................81
3.3.9.1. Vom Business Object zur Komponente ...............................................................81
3.3.9.2. Allgemeine Typen von Objekten ..........................................................................83
3.4. Präsentation und Business Objects ..................................................................................84
3.4.1. Anbindung von Presentations an Business Objects...................................................85
3.4.2. Verteilung von Präsentation und Business Object .....................................................90
3.5. Kopplung von Systemen ...................................................................................................92
3.5.1. Entkopplung und Anpassung von Funktionalität ........................................................93
3.5.2. Anpassungen der System- bzw. technischen Architektur ..........................................93
4. Architekturmodelle im Überblick ...........................................................................97
4.1. Einordnung ........................................................................................................................97
4.2. OMG Vorschläge zur Business Object Architecture .........................................................98
4.2.1. Architekturziele und Kontext.......................................................................................98
4.2.2. Grundmuster der Architektur ......................................................................................99
4.2.2.1. Definitionen ..........................................................................................................99
4.2.2.2. Services .............................................................................................................102
4.2.2.3. BO- und Type-Manager Interfaces ....................................................................103
4.2.2.4. Shared Services.................................................................................................110
4.2.3. Wertung ....................................................................................................................113
4.3. IBM San Francisco ..........................................................................................................113
4.3.1. Architekturziele und Kontext.....................................................................................113
4.3.2. Grundmuster der Architektur ....................................................................................114
4.3.2.1. Foundation Layer ...............................................................................................115
4.3.2.2. Common Business Objects Layer (CBOs) ........................................................117
4.3.2.3. Core Business Processes Layer........................................................................117
4.3.3. Wertung ....................................................................................................................119
4.4. Enterprise JavaBeans .....................................................................................................119
4.4.1. Architekturziele und Kontext.....................................................................................119
4.4.2. Grundmuster der Architektur ....................................................................................120
4.4.2.1. Komponente.......................................................................................................120
4.4.2.2. Container............................................................................................................120
4.4.2.3. Das Komponentenmodell...................................................................................120
4.4.2.4. Granularität der Komponenten...........................................................................120
4.4.2.5. Standardisierte Schnittstellen ............................................................................120
4.4.2.6. Anpassung ohne Änderung im Source Code ....................................................120
4.4.3. Enterprise JavaBeans Komponentenmodell ............................................................121
4.4.3.1. Implizite Services ...............................................................................................121
4.4.3.2. Portabilitätsschicht .............................................................................................121
4.4.3.3. Ausführung der Services....................................................................................122
4.4.4. Detaillierte Beschreibung der EJB Architektur .........................................................122
ii
© GDV 2001
Inhalt
4.4.4.1. Transiente und persistente Objekte................................................................... 123
4.4.4.2. Naming und Registry ......................................................................................... 123
4.4.4.3. EJB Objektschnittstelle ...................................................................................... 124
4.4.4.4. Deklarierte Attribute ........................................................................................... 124
4.4.4.5. Kontext Objekt und Environment Objekt ........................................................... 124
4.4.5. Beschreibung der Services ...................................................................................... 124
4.4.5.1. Distribution Services .......................................................................................... 124
4.4.5.2. State Management ............................................................................................ 125
4.4.5.3. Persistence Management .................................................................................. 125
4.4.5.4. Transaction Management .................................................................................. 126
4.4.5.5. Security .............................................................................................................. 127
4.4.6. Enterprise JavaBean Deployment............................................................................ 127
4.4.7. Wertung .................................................................................................................... 128
5. Ausblick ................................................................................................................. 129
6. Glossar................................................................................................................... 130
7. Anhang................................................................................................................... 135
7.1. Charakterisierung der einzelnen CORBA-Services ........................................................ 135
7.1.1.1. Life Cycle Service .............................................................................................. 135
7.1.1.2. Naming Service ................................................................................................. 136
7.1.1.3. Relationship Service .......................................................................................... 138
7.1.1.4. Persistence Service ........................................................................................... 141
7.1.1.5. Transaction Service ........................................................................................... 143
7.1.1.6. Concurrency Service ......................................................................................... 146
7.1.1.7. Trader Service ................................................................................................... 147
7.1.1.8. Collection Service .............................................................................................. 152
7.1.1.9. Property Service ................................................................................................ 154
7.1.1.10. Query Service .................................................................................................. 155
7.1.1.11. Security Service............................................................................................... 158
7.1.1.12. Externalization Service .................................................................................... 159
7.1.1.13. Event Service................................................................................................... 162
7.2. Verfügbare CORBA Implementierungen und Services................................................... 164
7.2.1. Cetus – Übersicht über verfügbare CORBA – ORBs............................................... 164
7.2.2. CORBA Service Implementierungen........................................................................ 169
7.3. Beispiele für Oberflächenanbindungen........................................................................... 172
7.3.1. Das archid - Framework als Beispiel einer flexiblen Verteilung von Oberfläche und
Anwendungslogik ............................................................................................................... 172
7.3.1.1. Kontext............................................................................................................... 172
7.3.1.2. Probleme............................................................................................................ 173
7.3.1.3. Kräfte ................................................................................................................. 173
7.3.1.4. Lösung ............................................................................................................... 175
7.3.1.5. Implementierungsumgebung ............................................................................. 177
7.3.2. Beispiel Präsentation ORACLE: Oracle Business Components for Java ................ 178
7.3.2.1. Konzepte............................................................................................................ 178
7.3.2.2. Beispiel Kopplung ORACLE: Oracle Integration Server.................................... 180
8. Literatur ................................................................................................................. 185
Abbildungsverzeichnis
Abbildung 1: Weg zu SW-Komponenten...................................................................................... 8
Abbildung 2: Das technische Referenzmodell der VAA............................................................... 9
Abbildung 3: Zusammenhang der Modelle und Architekturen ................................................... 11
Abbildung 4: Gegenüberstellung der Schichten des fachlichen und technischen Referenzmodells12
Abbildung 5: OMG-Architektur verteilter Systeme .................................................................... 14
© GDV 2001
iii
Inhalt
Abbildung 6: Kommunikation zwischen Client- und Serverobjekten mit Hilfe des ORBs.........16
Abbildung 7: Die CC-Schnittstellen: Die Ports ...........................................................................20
Abbildung 8: Präsentation in der DNA.......................................................................................23
Abbildung 9: Konfiguration von Komponenten ..........................................................................26
Abbildung 10: Beispiel für ein Dependent Object.......................................................................28
Abbildung 11: Kategorien von Business Objects ........................................................................29
Abbildung 12: Entity Business Object.........................................................................................30
Abbildung 13: Process Business Object ......................................................................................31
Abbildung 14: : Interfaces von Business Objects ........................................................................32
Abbildung 15: Contracts zwischen Business Objects, BO-Manager - Framework und BO-Persistence
Service ..................................................................................................................................35
Abbildung 16: Proxy-Objekte für Business Objects....................................................................36
Abbildung 17: Das VAA Business Object Metamodell ..............................................................43
Abbildung 18: Elemente der Prozeßsteuerung ............................................................................45
Abbildung 19: Das Objektmodell der Workflow Management Facility der OMG,  by OMG.46
Abbildung 20: Abbildung auf das VAA-Referenzmodell ...........................................................47
Abbildung 21: Integration von Activity-Objekten.......................................................................48
Abbildung 22: Prozesszustände ...................................................................................................49
Abbildung 23: Zuordnung von Ressourcen zu PBO....................................................................51
Abbildung 24: Zuordnung von Ressourcen zu Dialogen.............................................................52
Abbildung 25: Austausch von Prozessinformation......................................................................53
Abbildung 26: Beispielprozess "Angebotserstellung " ................................................................54
Abbildung 27: Kombination von Steuerungsvarianten................................................................56
Abbildung 28: Beispiel für Prozesskomponenten........................................................................57
Abbildung 29: Beispielprozeß LV-Angebot, oberste Ebene .......................................................58
Abbildung 30: Teilprozess Angebot erstellen..............................................................................59
Abbildung 31: State Diagram "Angebot erstellen"......................................................................60
Abbildung 32: Beispiel für den Aufbau des Berechtigungsobjekts .............................................66
Abbildung 33: Beispiel für die Berechtigungsprüfung auf dem Server.......................................66
Abbildung 34: Klassenmodell für den Fehlerdienst ....................................................................71
Abbildung 35: Sequenzdiagramm: Beispiel Fehlerfall................................................................73
Abbildung 36: Überblick über die Schnittstellen eines Postkorbsystems....................................75
Abbildung 37: Beispiel Temporal Property .................................................................................78
Abbildung 38: Beispiel zu Snapshot............................................................................................79
Abbildung 39: interne Struktur für die Historisierung.................................................................80
Abbildung 40: Business Objects als Komponenten.....................................................................82
Abbildung 41: Heterogene komponentenorientierte Systeme .....................................................82
Abbildung 42: Kompatibilitätsebenen .........................................................................................83
Abbildung 43: Business Objects und Presentation Components .................................................84
Abbildung 44: Schichtenmodell für die Präsentationsanbindung................................................85
Abbildung 45: Beispiel einer Java-Presentation ..........................................................................87
Abbildung 46: Beispiel einer HTML-Anbindung........................................................................88
Abbildung 47: Konstruktionsprinzip von Präsentationen............................................................89
iv
© GDV 2001
Inhalt
Abbildung 48: Fat Client ............................................................................................................. 90
Abbildung 49: Thin Client........................................................................................................... 91
Abbildung 50: Ultra Thin Client ................................................................................................. 92
Abbildung 51: Beispiel einer Systemanbindung durch Fassaden und Adapter........................... 94
Abbildung 52: Konvergenz der Architekturen ............................................................................ 94
Abbildung 53: Beispiel für die Anbindung eines Legacy – Systems .......................................... 96
Abbildung 54: Einordnung der betrachteten Architektur-Frameworks ....................................... 98
Abbildung 55: Interaktion von Business System Domains ....................................................... 100
Abbildung 56: Interface Hierarchie für Business Objects und Type Managers ........................ 102
Abbildung 57: InterOp Services über verschiedene Komponenten........................................... 103
Abbildung 58: Phasen des Commits im Transaction-Service (Interoperability Specification) . 112
Abbildung 59: Ausblick auf die "Multi Layer Architecture" von San Francisco...................... 114
Abbildung 60: Die San Francisco Architektur ......................................................................... 114
Abbildung 61: Kategorien von Common Business Objects (CBO-Layer)................................ 117
Abbildung 62: Kern-Geschäftsprozesse in San Francisco......................................................... 118
Abbildung 63 : Enterprise JavaBeans Container ....................................................................... 122
Abbildung 64: Konvergenz der Komponentenarchitekturen..................................................... 129
Abbildung 65: Beispiel für CORBA Naming Context .............................................................. 137
Abbildung 66: Beispiel für die Verwendung des Relationship Services................................... 140
Abbildung 67: Beispiele für die Verwendung von "graphs-of-related-objects"........................ 141
Abbildung 68: Komponenten des Persistence Service .............................................................. 142
Abbildung 69: Komponenten des Transaction Service ............................................................. 144
Abbildung 70: Beispiel CORBA Transaction Service .............................................................. 145
Abbildung 71: Locking Modes des Concurrency Services ....................................................... 147
Abbildung 72: Kommunikation zwischen Trader, Server und Client im Trader Service ......... 148
Abbildung 73: Beispiel Trader Service ..................................................................................... 151
Abbildung 74: Typen von Collections im Collection Service................................................... 153
Abbildung 75: Beispiel für den Property Service...................................................................... 155
Abbildung 76: Der CORBA Query Service .............................................................................. 156
Abbildung 77: Beispiel für eine Query mit dem QueryManager .............................................. 158
Abbildung 78: Prinzipieller Ablauf einer Berechtigungsprüfung in CORBA........................... 159
Abbildung 79: Lesen und Schreiben von Objekten im Externalization Service ....................... 161
Abbildung 80: Beispiel für den Event-Service.......................................................................... 164
Abbildung 81: Beispiel Auftragserfassung............................................................................... 179
Abbildung 82: Flexible Benutzeroberflächen............................................................................ 180
Abbildung 83: Hub-and-Spoke Architektur .............................................................................. 181
Abbildung 84: Integrationsmechanismen .................................................................................. 181
Abbildung 85: Integrationsstack................................................................................................182
Abbildung 86: Architekturelemente für die Integration ............................................................ 184
Tabellenverzeichnis
Tabelle 1: Kategorien von CORBA-Components ....................................................................... 21
© GDV 2001
v
Inhalt
Tabelle 2 : Kompatibilität der Dienste des BO-Frameworks und der CORBA Services ............35
Tabelle 3 : Ressourcenzuordnung................................................................................................50
Tabelle 4 : Beispiel für Stati einer Vorgangsakte ........................................................................54
Tabelle 5: Identity eines Business Objects (Interoperability Specification)..............................104
Tabelle 6: Life Cycle Operationen der Interoperability Specification.......................................106
Tabelle 7: State Access Operationen der Interoperability Specification ...................................106
Tabelle 8: Intrinsic events (Interoperability Specification) .......................................................107
Tabelle 9: Bedingungen für das Auslösen von Events (Interoperability Specification) ............108
Tabelle 10: Bedingungen für die Übermittlung von Events (Interoperability Specification)....108
Tabelle 11: Interfaces des Query Service der Interoperability Specification ............................109
Tabelle 12: Introspection Interface (Interoperability Specification)..........................................110
Tabelle 13: Exception Categories (Interoperability Specification)............................................110
Tabelle 14: Eigenschaften des Transaction Service (Interoperability Specification) ................111
Tabelle 15: Operationen des CORBA Naming Service.............................................................137
Tabelle 16: Eigenschaften von Diensten beim CORBA-Trader Service ...................................148
Tabelle 17: Functional Interfaces des CORBA Trader Service .................................................150
Tabelle 18: Administration Interfaces des CORBA Trader Service..........................................151
Tabelle 19: Merkmale von CORBA Collections .......................................................................153
Tabelle 20: Interfaces des CORBA Property Service................................................................155
vi
© GDV 2001
Inhalt
1. Einführung und Überblick
1.1. Kontext
Das technische und fachliche Referenzmodell [oFRM01] 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. Es definiert auch, an welcher Stelle im System sich welche Systemteile einklinken können und wie diese interagieren. 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ß.
© GDV 2001
7
Inhalt
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
1.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. In dem Dokument „Die Anwendungsarchitektur der Versicherungswirtschaft - Grundlagen und Prinzipien“ findet man ähnliche Begriffe. Die
8
© GDV 2001
Inhalt
Systemarchitektur wird synonym verwendet, während die technische Architektur der Komponentenarchitektur entspricht.
Technisches Referenzmodell
Dienste
BusinessObjects und Komponenten
• BO-Transaktionen • Suchen
• BO-Persistenz
• Erzeugen
• BO-Beziehungen • Löschen
Technische Dienste
• Parametrisierung
• Events
• ...
• CORBA Services
• Präsentation
• Datenbanken
SystemArchitektur
Technische
Architektur
Object Request Broker
Abbildung 2: Das technische Referenzmodell der VAA
1.2.1. Die technische Architektur
Basis der technischen Architektur des Referenzmodells ist die Object Management Architecture der
OMG (OMA), die Spezifikationen der CORBA-Services [OMG98a] und des Object Request Brokers
[OMG98a]. 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. Über die IDL ist es möglich, Komponenten zu entkoppeln
und über CORBA-Mechanismen miteinander interagieren zu lassen.
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.
© GDV 2001
9
Inhalt
1.2.2. Die Systemarchitektur
Das grundlegende Strukturelement der Systemarchitektur ist das Business Object (Geschäftsobjekt).
Die Systemarchitektur definiert den Begriff Business Object und beschreibt dessen innere Struktur,
arbeitet verschiedene Typen von Business Objects heraus und definiert Anforderungen an Komponenten und deren Interaktion. Sie stellt somit ein Metamodell für die Realisierung fachlicher Objekte
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 der Common Facilities Architecture (CORBAFacilities) [OMG95].
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.
1.2.3. Fachliche Komponenten und technisches Referenzmodell
Die folgende Abbildung zeigt den Zusammenhang zwischen fachlichen Komponenten, Systemarchitektur und technischer Architektur:
10
© GDV 2001
Inhalt
Fachliches
Versionierbar
(from LibraryPackage)
IcisBasis
Actor-Role
-Pattern
VersionierbarerAkteur
Fachliche
Komponentenmodelle
Rolle
0..*
Standard
anzuwendendeAnschrift
0..1
Anschrift
Person
Standard
0..1
*
Rufnummer
0..1
*
0..1
JurPerson
anzuwendende
Bankverbindung
*
Standard
Bankverbindung
Partner
0..1
NatPerson
Technisches
VertragsabhaengigerPartner
Vermittler
Dienste
Produktpartner
Versicherte Person
ObjektPartner
SonstigePartnerrolle
Versicherungsnehmer
Postempfaenger
partn
erart
Beitragszahler
Leistungsempfaenger
Business Objects und Komponenten
• BO-Transaktionen
• Parametrisierung
• Suchen
• BO- Persistenz
• Events
• Erzeugen
• BO-Beziehungen
• ...
• Löschen
Technische Dienste
• CORBA Services
• Präsentation
• Datenbanken
SystemArchitektur
Technische
Architektur
Abbildung 3: Zusammenhang der Modelle und Architekturen
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.
Folgende Übersicht verdeutlicht das Zusammenspiel der einzelnen Ebenen am besten:
© GDV 2001
11
Inhalt
Fachliches Referenzmodell
Fachliches
Komponenten-Metamodell
VAA Business Object Metamodell
Geschäftsprozesse
(Use-Case-Modell)
Fachliches
Komponentenmodell
(AWKs und PKs)
Technisches
Komponenten-Metamodell
Fachliche Dienste
(Requirements)
Fachliche Dienste
(Implementierung)
Fachmodell
(EBOs und PBOs)
Technische Architektur (OMA)
Technische Dienste (Corba)
Abbildung 4: Gegenüberstellung der Schichten des fachlichen und technischen Referenzmodells
Das fachliche Komponenten-Metamodell benutzt die Definitionen des VAA Business Object Metamodells. Die fachlichen Komponenten (vgl. [oFRM01]) bestehen aus Business Objects und verwenden die im VAA Business Object Metamodell spezifizierten Schnittstellen.
Die fachlichen Komponenten, die Prozesskomponenten (PKs) und Anwendungskomponenten
(AWKs) sind eine fachliche Klassifizierung des technischen Komponentenbegriffs.
Die im fachlichen Referenzmodell benutzten und benötigten fachlichen Dienste werden im technischen Referenzmodell spezifiziert und in die technische Infrastruktur eingebettet (Anmerkung: Es
wurden nicht alle fachlichen Dienste spezifiziert).
Die untersten Schichten (Fachmodell und technische Architektur) bilden bei beiden Referenzmodellen
jeweils das Fundament, auf dem die anderen Schichten aufbauen.
12
© GDV 2001
Inhalt
2. 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
[GDV99]:
•
•
•
•
•
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. Darüber hinaus stellt CORBA Messaging Mechanismen 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. [Meta98] und [Orfali98]).
Weitere Elemente der technischen Architektur
Die CORBA Standards enthalten keine Spezifikationen zur Benutzerschnittstelle. Angaben dazu in
den CORBA Facilities [OMG95] haben lediglich Definitionscharakter. Wichtig aus Sicht des VAAReferenzmodells ist vor allem das Zusammenspiel zwischen Fachlogik, Steuerung und Präsentation
unter Verteilungsaspekten (siehe hierzu Kapitel 3.3.6 und 3.4), die Präsentationstechnik selbst ist nicht
Gegenstand des Referenzmodells.
© GDV 2001
13
Inhalt
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 3.2.5.1).
2.1. Die Object Management Architecture (OMA)
2.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).
Application
Interfaces
Domain
Interfaces
Common
Facilities
Object Services
Abbildung 5: OMG-Architektur verteilter Systeme
Object Request Broker und CORBA Services
Im Mittelpunkt der OMA-Architektur steht der Object Request Broker (ORB). Seine Funktionsweise
und Systemeinbettung bildet einen der Hauptbestandteile der CORBA-Spezifikation. Unter dem
Sammelbegriff CORBA 2.0 werden neben der reinen Broker-Funktionalität auch eine Reihe allgemeiner technischer Dienste verstanden, die sogenannten CORBA-Services (s.u.). Die CORBA-Services
spezifizieren Verhalten und Schnittstellen verteilter Objektsysteme hinsichtlich Transaktionsmanagement, Objekterzeugung, Persistenz u.ä.
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
14
© GDV 2001
Inhalt
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 Inter-ORB Protocol (IIOP)
Für die Kommunikation verwenden Object Request Broker heutzutage vor allem das ebenfalls von der
OMG spezifizierte Internet Inter-ORB 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 4.2):
•
Interoperability Specification [OMG98c]
•
Business Object Component Architecture (BOCA) [BOCA98]1
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 2001 OMG-Spezifikationen vorliegen werden, die sich stark an JavaBeans
und Enterprise-JavaBeans orientieren (siehe Kapitel 2.1.3). Aus diesem Grund wurden bei der Definition des technischen Referenzmodells die JavaBeans- und Enterprise-JavaBeans - Spezifikationen
besonders berücksichtigt (siehe Kapitel 4.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.x Spezifikation läßt zuviel Raum für ORB-Hersteller bei der Gestaltung der Objekt- und
Transaktionsverwaltung auf der Serverseite, wodurch Implementierungen mit unterschiedlichen ORBs
nicht kompatibel sind. Diese Mängel sollen durch CORBA 3.0 (siehe Kapitel 2.1.3) und vor allem
durch das Zusammenwachsen von CORBA und Enterprise-JavaBeans behoben werden.
1
Die Business Object Component Architecture (BOCA) wurde Mitte 1998 von der OMG aufgegeben. Nachfolger wurde in der BODTF die
Business Object Initiative (BOI). Im Referenzmodell wird jedoch weiterhin Bezug auf BOCA genommen, da die Grundlagen speziell der
InterOp bei der Erstellung der des technischen Referenzmodells der VAA größeren Einfluß hatten.
© GDV 2001
15
Inhalt
2.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
Implementierung der
Klasse von "aObj"
Stub von "aObj"
1. Objekt erzeugen mit
Angabe der Referenz
2. Aufruf method()
method()
Client ORB
Skeleton
Server-ORB
Anwendungsobjekt
dynamic invocation (DII)
Anwendungsobjekt
Request - Objekt
1. aObj, Parameter,
method() dem reqObjekt mitteilen;
2. Aufruf req.invoke()
invoke()
Client ORB
aObj
method()
IIOP
IIOP
Abbildung 6: Kommunikation zwischen Client- und Serverobjekten mit Hilfe des ORBs
2.1.3. CORBA 3.0 und Java
Übersicht
Die in den vorangegangenen Abschnitten beschriebenen CORBA-Dienste und ORB-Funktionen beschränken sich auf die zur Zeit (oVAA 1.0) verfügbaren Spezifikationen von CORBA 2.x.. Im Fokus
von CORBA 3.0 (aktuell 02/2001 ist die Spezifikation von CORBA 2.4.2) stehen insbesondere Spezifikationen bezüglich CORBA-Komponenten und verteilten Internet-Anwendungen:
16
© GDV 2001
•
•
•
•
•
•
Inhalt
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 (siehe
auch 2.1.4).
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-LanguageMapping 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 [OMG97]) 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.
Die Integration von CORBA und Enterprise JavaBeans zeigt eine Reihe „weißer Flecken“ in den bisherigen Versionen beider Standards auf:
•
•
•
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
© GDV 2001
17
Inhalt
Ü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, 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 JavaUmgebungen 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 Internet, 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 CORBA-Standards 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
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.
2.1.4. CORBA Components
Überblick
Mit der Spezifikation der CORBA-Components (CC) [OMG99] im Rahmen der CORBA 3.0Spezifikation [iX2000] hat die OMG ein Komponentenmodell für server-seitige Komponenten vorgelegt. Sie ist einerseits und erklärtermaßen stark an Sun Microsystems EnterpriseJavaBeansArchitektur angelehnt, andererseits, gemäß der OMG-Grundsätze, hersteller- und plattformunabhängig. Sie ist eine Obermenge der EJB-Spezifikation.
CORBA-Components liefern im wesentlichen eine
Erweiterung des Metamodells um einen Komponententyp
18
© GDV 2001
Inhalt
Definition der Schnittstellen(-architektur) von CORBA-Components
Einführung der Component-IDL, einer Erweiterung der Interface Definition Language (IDL)
um Elemente zur Beschreibung von Komponenten.
Definition der Laufzeitumgebung (Container) für CC und deren Schnittstellen.
Erweiterung um ein Auslieferungs(deployment)-Modell innerhalb der OMA.
Beschreibung des Mappings von CC auf EnterpriseJavaBeans
Anpassungen der bestehenden CORBA-Services an CC
CORBA-Components (CC) sind eine Erweiterung und Spezialisierung des Object-Metatyps, die eine
Reihe von Schnittstellen unterstützen. CC-Instanzen haben eine eindeutige Referenz, die eine Spezialisierung der object-Referenz ist. Die IDL wurde um Möglichkeiten zur Beschreibung der CC und
deren Schnittstellen erweitert. CC benutzen die Systemdienste.
Die Schnittstellen
Wesentliches Merkmal einer CC ist ihre „Oberfläche“, das heißt die Menge ihrer Schnittstellen. Als
Oberbegriff für alle Arten von CC-Schnittstellen wurde der Begriff „port“ eingeführt. Die Definition
kennt vier Arten von ports:
1. Facetten (facets): Facets sind bestimmte, mit einem Namen versehene, Schnittstellen, die
die Komponenten für die Interaktion mit dem Client zur Verfügung stellen.
2. Receptacle (receptacles): Ein Receptacle ist eine Schnittstelle, die eine CC nicht selbst implementiert, sondern importieren möchte.
3. Ereignis-Quellen (event sources) : Event sources sind, mit einem Namen versehene, Verbindungsstellen, an denen die Komponente Ereignisse aussendet. Als Empfänger der Ereignisse können ein oder mehrere Empfänger oder ein Ereigniskanal (event channel) auftreten.
4. Ereignis-Senken (event sinks): Event sink sind, mit einem Namen versehene, Eingangsstellen für Ereignisse.
Es gibt eine herausragende Schnittstelle, die so genannte Äquivalenzschnittstelle (equivalence interface). Diese ist die zentrale Schnittstelle der Komponente, in der die Sicht des Clients auf die Komponente beschrieben ist. Über sie erhalten Clients Referenzen auf alle Ports einer CC-Instanz. Diese ermöglichen es Clients, zwischen den verschiedenen Ports zu navigieren und sich mit diesen zu verbinden.
© GDV 2001
19
Inhalt
equivalent interface
CORBA-Component
Receptacle
facets
Implementierung
Implementierung
event
event sink
Abbildung 7: Die CC-Schnittstellen: Die Ports
Die Implementierungen der Facets sind innerhalb der Komponente gekapselt. Die Referenzen auf Facets sind eindeutig, so dass Clients immer die Möglichkeit haben zu erkennen, ob zwei Referenzen zur
gleichen Instanz gehören oder nicht. Die Lebensdauer der Referenzen ist gleich der Lebensdauer der
Komponente. CORBA-Components können Primärschlüssel zugeordnet werden.
Wie auch EnterpriseJavaBeans sind CORBA-Components genau einem Home-Interface des Containers zugeordnet. Dieses Interface enthält alle Methoden, die zur Instanziierung der jeweiligen Komponenten-Klasse benötigt werden. Insbesondere kann hier die Zuordnung von Primärschlüssel-Attributen
zu bestimmten Komponenten-Instanzen vorgenommen werden. Die Spezifikation beschreibt die Finder-Methoden, die Clients nutzen können, um bestimmte CC-Instanzen zu finden.
CORBA-Components-Container
Die CC-Spezifikation kennt zwei verschiedene Kategorien von Containern für CC. Die Unterschiede
liegen im Lebenszyklus der von ihnen unterstützten Komponenten. Persistente Container unterstützen persistente Referenzen auf Komponenten. Transiente Container unterstützen dies nicht.
Die Rahmenbedingungen für die Interaktion, genannt Implementierungstypen (container implementation types) zwischen Container und Komponente werden weiter spezifiziert. Transiente Container
werden in zwei Implementierungstypen spezifiziert.
Zustandslos (stateless): Bei statuslosen Containern findet die Interaktion zwischen Komponente
und Container über einen POA (portable object adapter) statt, der alle Instanzen eines Komponententyps präsentiert.
Dialogorientiert (conversational): Bei ‘conversational’ Containern ist für jede KomponentenInstanz ein eigener, dedizerter POA zuständig, über den die Interaktion läuft.
Für persistente Container gibt es nur einen Implemetierungstyp:
Dauerhaft (durable): Bei dauerhaften Komponenten ist jede Instanz mit einer dauerhaften und
Referenz versehen. Die Interaktion läuft über einen dedizierten POA.
Nur bei persistenten Containern und dem Implementierungstyp „dauerhaft“ ist die Zuordnung von
Primärschlüsseln zu CC-Instanzen möglich.
Mit diesen Begriffen, lassen sich folgende vier Kategorien von CORBA-Components ableiten:
20
© GDV 2001
Inhalt
Kategorie
Containertyp
Implementierungstyp
Primärschlüssel
EJB-Pendant
Service
transient
stateless
nein
-
Session
transient
conversational
nein
session
Process
persistent
durable
nein
-
Entity
persistent
durable
ja
entity
Tabelle 1: Kategorien von CORBA-Components
Service-Komponenten sind zustandslos und hängen so nicht von einem bestimmten Client ab. SessionKomponenten sind fest an einen Client gebunden und hängen in ihrem Zustand von diesem ab.
Process-Komponenten sind ebenfalls mit einem Client fest verbunden. Auf Entity-Komponenten ist
über ihren Primärschlüssel ein Zugriff von beliebigen Clients möglich.
Zwischen Komponente und Container gibt es eine Reihe weiterer in der Spezifikation beschriebener
Schnittstellen, die bei Bedarf verwendet werden können:
Methoden, mit denen die Komponente die eigene Referenz und die ihrer Home-Schnittstelle
erfragen kann.
Transaktionsschnittstelle
Die Transaktionsschnittstelle enthält die Methoden, die für die Teilnahme einer Komponente
in einem Transaktionskontext benötigt werden.
Sicherheitsschnittstelle
Die Sicherheitsschnittstelle dient der Authentifizierung und Authorisierung des Aufrufers.
Ereignissschnittstelle
Die Ereignisschnittstelle enthält die Methoden, die zur Verarbeitung von Ereignissen benötigt
werden.
Wertung
Mit CORBA-Components füllt die OMG die Lücke der serverseitigen Komponenten in ihren bisherigen Spezifikationen. Sie bildet dabei bewusst eine Obermenge der EnterpriseJavaBeans-Spezifikation.
Derzeit fehlen noch umfangreichere Implementierungen von CORBA-Components basierten Anwendungssystemen, so dass noch nicht viele Erfahrungen aus der Projektpraxis vorliegen.. Die Nähe zu
EnterpriseJavaBeans macht es für EJB-Entwickler jedoch verhältnismässig einfach, CC-basierte Systeme zu entwickeln. Auch ist zu erwarten, dass die Entwickler von EJB-Entwicklungsumgebungen
und EJB-Containern diese um die Möglichkeiten zur Entwicklung und Nutzung von CC erweitern
werden.
In der Vergangenheit hat sich in verschiedenen Projekten gezeigt, dass CORBA-basierte Systeme sehr
„verwaltungslastig“ wurden und dadurch Performance-Probleme auftraten. Es ist nicht zu erwarten,
dass die Spezifikation der CC daran etwas ändert – weder im positiven, noch im negativen. Sie stellen
eine reine konzeptionelle Ergänzung um bisher fehlendes dar.
© GDV 2001
21
Inhalt
Zum Zeitpunkt der Erstellung des Dokumentes lag noch keine entgültige CCM-Spezifikation der
OMG vor. Aktuelle Informationen über den Stand der Spezifikation sowie über Produkte zum CCM
findet man unter www.omg.org .
2.2. Distributed Internet Architecture (DNA)
Im Rahmen der Produktentwicklung von Windows 2000 wurde die DNA von Microsoft überarbeitet.
Diese Änderungen sind nicht in den DNA-Überblick eingeflossen. Aktuelle Informationen bezüglich
DNA und Biztalk findet man unter www.microsoft.com und www.biztalk.org.
2.2.1. Definition und Grundbegriffe
Die Plattform für Microsoft Anwendungen besteht aus einem mehrschichtigen, verteilten Anwendungs-Modell und den 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.
2.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ön22
© GDV 2001
Inhalt
nen diese zu einer Gesamtanwendung zusammenfügt und auf unterschiedliche Plattformen verteilt
werden.
Auf Komponenten basierende Anwendungen und DNA bedienen sich dabei einer allgemeinen Infrastruktur sowie der Netzwerkdienste, die durch das Betriebssystem Windows bereitgestellt werden..
2.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 8: 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.
© GDV 2001
23
Inhalt
•
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.
2.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 Komponenten-basierten 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.
24
© GDV 2001
Inhalt
3. Die Systemarchitektur der VAA
Komponenten-basierte Softwarearchitekturen sollen die Wartbarkeit, Pflege, Ü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 4.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 Komponente schwer von einander getrennt
werden. Der Unterschied liegt darin, daß Subsysteme in einen 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.
3.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.“ 2 [Stal99]
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).
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.
2
Aus „Des Knaben Wunderhorn“ von Michael Stal, ObjektSpektrum 01/99
© GDV 2001
25
Inhalt
Bei der Nutzung von Komponenten sollten keine Überschneidungen von Funktionalitäten erfolgen.
Dies obliegt jedoch der Verantwortung des Komponentennutzers. Eine Redundanzfreiheit der Funktionalitäten mehrerer Komponenten kann nicht gewährleistet werden.
Entsprechend wird eine technische Komponente im Referenzmodell der VAA definiert. Eine technische VAA-Komponente enthält beliebig viele Business Objects (Im Vergleich dazu wird eine fachliche VAA-Komponente differenzierter definiert. Siehe dazu „Das fachliche Referenzmodell der VAA“
[oFRM01]). Sie erfüllt folgende Kriterien:
Sie enthält beliebig viele Entity Business Objects (EBO) und Process Business Objects (PBO)
(vgl. Definition und Kategorisierung von Business Objects in 3.2)
Es handelt sich um eine verkaufbare Software-Einheit
Die technische VAA-Komponente ist in beliebigen Kontexten einsetzbar und in sich funktional
abgeschlossen
Sie besitzt wohldefinierte Schnittstellen, über die die einzelnen Funktionalitäten der Komponente
abgerufen werden können und
Sie ist mit Hilfe von Konfigurations-Werkzeugen konfigurierbar.
Die Konfiguration von Komponenten kann nur an deren Schnittstellen durchgeführt werden. Komponenten müssen, wie zuvor definiert, bestimmte Schnittstellen zur Verfügung stellen. Letztlich werden
diese Schnittstellen von den in der Komponente vorhandenen BOs zur Verfügung gestellt und im
Kontext der Komponente veröffentlicht.
Diese Schnittstellen sind zweigeteilt. Es existieren
•
fachlich notwendige Schnittstellen, die Funktionalität und Services zur Verfügung stellen und
•
sogenannte Framework-abhängige Schnittstellen, die benötigt werden, damit sich die Komponente
in das benutzte Framework, welches die Infrastruktur (z.B. BO-Manager und Persistence-Service)
bereitstellt, einfügen kann.
Komponente
KonfigTools
BO
BOManager
Konfiguriert
alle Interfaces
Persistence-Service
Framework-abhängig
Fachl.
Fachl. abhängig
Abbildung 9: Konfiguration von Komponenten
26
© GDV 2001
Inhalt
Konfigurationswerkzeuge müssen Framework-spezifisch erstellt werden. Sie sind in der Lage, die von
der Komponente zur Verfügung gestellten Schnittstellen zu konfigurieren (siehe auch Abbildung 9).
Komponenten müssen dazu beispielsweise über einen Introspection-Mechanismus ihre Funktionalität
„nach außen“ bekannt geben können.
Weiterführende Literatur zu Software Komponenten findet sich u.a. in [Szyp98].
3.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 (vgl. [Eeles98]), muß es jedoch nicht sein.
3.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.
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äsentationen können Business Objects zugeordnet werden..
© GDV 2001
27
Inhalt
3.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 das 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
Abbildung 10: Beispiel für ein Dependent Object
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.
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.
28
© GDV 2001
Inhalt
3.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 zu logischen Einheiten zusammengefaßte 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 11: 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.
3.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 unten 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ämienrechner das Dependent Object Prämienrechner zurückliefert (samt der Referenzen zu den assozierten Business Objects). Die Berechnung kann daraufhin durch den Aufrufer zu beliebigen Zeitpunkten geschehen.
© GDV 2001
29
Inhalt
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 12: Entity Business Object
3.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 fachlichen 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.
Ein PBO identifiziert einen bestimmten fachlichen Vorgang eindeutig (z.B. „Antrag Maier, Hugo vom
14.07.2000“). In einfachen Fällen kann ein PBO auch den technischen Transaktionskontext darstellen
(im Sinne des ACID-Prinzips). Bei Prozessen, die aus hierarchisch gegliederten PBOs bestehen, werden im allgemeinen jedoch mehrere technische Transaktionen beteiligt sein (z.B. Partnerdatenänderung und Vertragsdatenänderung).
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.
30
© GDV 2001
Inhalt
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 13: 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ändiges PBO realisiert werden können, oder sogar als konstantes „Einmal“-Objekt („Singleton“, vgl.) 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 PBOs hergestellt. Dies gilt auch
dann, wenn mehrere EBOs 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 jede Teilaufgabe den richtigen Adressaten aufrufen (vgl. Entwurfsmuster „Vermittler“ in [Gamma96]).
3.2.4. Interfaces von Business Objects
Die verschiedenen Kategorien von Business Objects stellen definierte Interfaces (IFCs) für die Benutzung zur Verfügung. Dabei gibt es notwendige (muß) und optionale Interfaces, d.h. gewisse Grundfunktionalität muß bei einem Business Object implementiert werden und gewisse Funktionalitäten
müssen nicht von jedem, sondern nur von bestimmten Business Objects bereit gestellt werden. Eine
Übersicht gibt Abbildung 14.
© GDV 2001
31
Inhalt
BO
implementiert
EBO
implementiert
PBO
implementiert
implementiert
implementiert
Histo
IFC
Simple
IFC
WF
IFC
GUI
IFC
Simple
IFC
optional
muß
optional
optional
muß
Abbildung 14: : Interfaces von Business Objects
Das EBO stellt zunächst zwei Interfaces zur Verfügung. Das „Simple Interface“ des EBO stellt die
Basisfunktionalität eines EBO am Interface bereit.
Darüber hinaus kann das „Historisierung Interface“ implementiert werden. Mit Hilfe dieses Interfaces
kann ein EBO historisiert werden (vgl. Dienst Historisierung in 3.3.6).
Auch das PBO implementiert bestimmte Interfaces. Zunächst muß jedes PBO das Interface „Simple
Interface“ implementieren, d.h. die entsprechende Basisfunktionalität zur Verfügung stellen (vgl.
3.2.3.2 und 3.2.5). D.h. die geforderten Eigenschaften der PBOs (transaktional, etc.) müssen an diesem
Interface zur Verfügung stehen.
Da grundsätzlich Präsentationen innerhalb eines PBO-Kontextes definiert werden, jedoch nicht jedes
PBO unbedingt eine Präsentation haben muß (z.B. Batch-Abläufe ohne expliziten Output), besteht die
Notwendigkeit, einem PBO eine Präsentation zuzuordnen. Um die Konfiguration durchzuführen und
die Präsentation anzusprechen, muß ein PBO, welches eine Darstellung „hat“, das „Presentation Interface“ (GUI-IFC) implementieren. Die Entkopplung des PBO von der Präsentation bleibt weiterhin
durch die Verwendung von Presentation-Controllern (siehe 3.4) gewahrt.
Prozessobjekte, die innerhalb eines Geschäftsprozesses von der Workflow-Engine direkt gesteuert
werden (vgl. Dienst Prozesssteuerung in 3.3.1) besitzen drüber hinaus das „Workflow-Interface“(WFIFC), damit die benötigte Funktionalität an dieser Schnittstelle bereitgestellt werden kann.
Mit Hilfe der vorher kurz beschriebenen Interfaces lässt sich somit eine weitere Kategorisierung der
Business Objects vornehmen. Dieses Konzept lässt beispielsweise dem Modellierer bzw. Implementierer eines konkreten VU-Systems die Freiheit, die Granularität einer Historisierung oder einer Macrosteuerung per Workflow-Engine selbst zu bestimmen. Das technische Referenzmodell kann an dieser
Stelle nur die Mechanismen hierfür bereitstellen.
32
© GDV 2001
Inhalt
3.2.5. 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 Components. 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 einer ausgewählten
Komponentenarchitektur abgebildet werden.
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
3.2.5.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 [SUN00]
•
BaseFactory/Container in SanFrancisco [IBM]
•
TypeManager in der Interoperability Spezifikation [OMG98c]
Das BO-Manager - Framework ist für die folgenden Aufgaben zuständig:
© GDV 2001
33
Inhalt
•
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 Datenbank und Business Object und ist für die folgenden Aufgaben zuständig (siehe Abschnitt 3.2.5.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 15).
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.
34
© GDV 2001
Inhalt
Business
Object
BOPersistenceService
BO - Manager -Framework
Abbildung 15: 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:
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 Beziehungen zwischen Busi- Relationship Service
ness Objects
Tabelle 2 : 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.
3.2.5.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 Object 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 gegebenenfalls das Laden des
© GDV 2001
35
Inhalt
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 16: Proxy-Objekte für Business Objects
3.2.5.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.
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-Laptops 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 BOManager - 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 Meta-Informationen die
Speicherung des Zustands selbst vorzunehmen (Persistence Framework).
36
© GDV 2001
•
•
Inhalt
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.
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 Anwendung 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
© GDV 2001
37
Inhalt
3.2.5.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:
•
•
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,
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 Persistenz Frameworks geeignet.
Business Object und BO-Persistence Service stellen dem Finder Meta-Informationen 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.
3.2.5.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
38
© GDV 2001
Inhalt
stellen (vgl. Factory-Entwurfsmuster [Gamma96]). 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 BOManager - Framework die Standard CORBA - Factory Interfaces weiterhin unterstützen.
3.2.5.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 3.2.5.3). 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 3.2.5.10) stellt einen Eventtyp zur Verfügung, der die
automatische Benachrichtigung verbundener Business Objects bei Löschoperationen erlaubt.
3.2.5.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.
„Lange“ und ACID-Transaktionen
Innerhalb eines durch ein PBO implementierten Vorganges können verschiedene Typen von Transaktionen vorkommen. ACID – Transaktionen dienen vor allem dazu, die Konsistenz eines Netzes aus
Business Objects zu gewährleisten. Lange Transaktionen bezeichnen Geschäftsprozesse oder Vorgänge, die aus einer Reihe eigenständiger ACID-Transaktionen bestehen. Für diese Vorgänge besteht
meist weder die technische Möglichkeit noch die Notwendigkeit einer Einhaltung der ACID – Prinzipien. In vielen Fällen sind sie sogar unerwünscht: eine Aktualisierung der Partnerdaten im Rahmen
eines Angebotsprozesses wird man auch dann nicht zurücknehmen, wenn kein Vertrag zustande
kommt.
Lange Transaktionen wird man deshalb bei der Modellierung der Prozesse oder Anwendungssysteme
explizit berücksichtigen, z. B. durch geeignete Status-, Historisierungs- bzw. Schwebekonzepte.
Bei den an dieser Stelle behandelten Transaktionen handelt es sich deshalb um ACID-Transaktionen.
Die Abgrenzung zu langen Transaktionen erfolgt auf der Ebene der PBOs:
•
Ein PBO kann eine ACID Transaktion klammern, d.h. alle beteiligten EBOs und untergeordneten
PBO nehmen an ihr teil, sofern sie dazu in der Lage sind (siehe Festlegung des Transaktionsverhaltens unten).
© GDV 2001
39
Inhalt
•
Klammert ein PBO eine lange Transaktion, ist zwar sein eigener Zustand transaktionsgesichert, es
stellt jedoch keinen Transaktionskontext für untergeordnete PBO oder EBOs zur Verfügung. Die
Klammer der langen Transaktion wird hergestellt durch (anwendungsspezifische) Schlüsselinformationen (z.B. Status, Version, Datum), mit deren Hilfe die zu dieser Transaktion gehörenden
Daten identifiziert werden können.
ACID – Transaktionen und BO-Manager - Framework
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-Persistence Service
•
•
Der BO-Persistence Service bzw. die zugrundeliegenden Datenbanken müssen Commit/Rollback Protokolle (X/Open) unterstützen
Sperrmechanismen des Persistence Service müssen sinnvoll mit dem Transaktionsmanagement
zusammenarbeiten.
Transparenz bezüglich paralleler 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
3.2.5.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.
40
© GDV 2001
Inhalt
3.2.5.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 7.1.1.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 3.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.
3.2.5.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
© GDV 2001
41
Inhalt
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 assoziierte
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 vordefinierter 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.
3.2.5.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:
•
•
•
„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
Schnittstellen definiert sein, die im Zusammenhang mit dem CORBA Relationship Service automatisch Verbindungspartner benachrichtigen.
Transaction Events
Events, die zum Abschluß oder Abbruch einer 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.
42
© GDV 2001
Inhalt
3.2.6. VAA Business Object Metamodell
Aus den vorher beschriebenen Eigenschaften von Business Objects läßt sich das VAA Business Object Metamodell ableiten. Die Abbildung gibt eine Übersicht über das Zusammenspiel der verschiedenen Objekte.
Lebensraum
eines BO
BOBOManager
Business Object
BO
Dependent
Object
hat
Dienste
EBO
PBO
Fachl.
Fachl.
Entität
Fachl.
Fachl.
Ablauf
hat
Dependent
Object
Abbildung 17: Das VAA Business Object Metamodell
Der Lebensraum eines Business Objects wird also durch den BO-Manager bzw. das BO-ManagerFramework beschrieben und verwaltet. Das BO selbst kann entweder fachliche Entitäten in Form von
EBO oder aber fachliche Abläufe in Form von PBO darstellen.
3.3. Fachlich motivierte Dienste
3.3.1. Prozeßsteuerung
3.3.1.1. Problemstellung
Im VAA technischen Referenzmodell werden Geschäftsabläufe generell durch Process Business Objects (PBO) abgebildet. Von außen betrachtet stellt ein PBO die gesamte Logik eines Geschäftsablaufs
dar. Die bisherigen Ausführungen zu PBO (vgl. Kapitel 3.2.3.2) definieren dazu die grundlegenden
Eigenschaften von Process Business Objects.
Um Process Business Objects im Rahmen einer Architektur zu implementieren, sind eine Reihe weiterer Konzepte und Rahmenbedingungen zu definieren, die über die grundlegenden Eigenschaften hinausgehen. Dazu gehören insbesondere:
Standardisierung der Schnittstellen zwischen PBOs untereinander, zu EBOs und zu kommerziellen
Workflowsystemen.
Verknüpfung fachlicher Teilprozesse mit Hilfe von PBOs auch über System- und Unternehmensgrenzen hinweg.
© GDV 2001
43
Inhalt
Spezifikationen von Anwenderdiensten wie Postkorb, Terminverwaltung usw.
Schnittstellen zur Überwachung und Administration von Prozessen, einschließlich der Schnittstellen für die Zuordnung von Ressourcen.
Möglichkeiten der Erzeugung oder Steuerung von PBOs mit Hilfe formaler Prozessdefinitionen.
Eine detaillierte Behandlung der Themen ist im Rahmen einer allgemeinen Systemarchitektur nicht
möglich. Dieses Dokument beschränkt sich deshalb auf grundlegende Konzepte und ihre Anwendbarkeit innerhalb der VAA Referenzarchitektur. Ziel ist ein allgemeiner Leitfaden für das Design von
prozessorientierten Anwendungen, der eine Realisierung auf unterschiedlichen Plattformen ermöglicht.
Um eine möglichst breite Anwendbarkeit zu gewährleisten, basieren die vorgestellten Konzepte auf
den Architekturmodellen und Schnittstellenspezifikationen der Workflow Management Coalition
(WfMC) beziehungsweise deren objektorientierter Version, die von der OMG aufgenommen wurde.
3.3.1.2. Standards der WfMC und OMG
Die Workflow Management Coalition (WfMC) adressierte eine Reihe der oben angeführten Fragestellungen im Rahmen ihres Workflow-Referenzmodells [WfMC94] und definierte Schnittstellen zwischen Komponenten workflowbasierter Systeme [WfMC96a],[WfMC96b],[WfMCc]. Der Versuch,
diese Spezifikationen als OMG-Standard festzulegen, scheiterte zunächst [Sch+98]. Das WfMC - Modell ging von einer monolithischen Workflowmaschine aus und berücksichtigte nicht das offene Business Object Model der OMG [Sch98]. Nachdem die OMG im Mai 1997 einen RFP (request for proposal) für die Workflow Management Facility veröffentlichte, kam es letztlich zu einer Joint Submission
mehrerer Hersteller [OMG98b], die die Vorgaben der OMG stärker berücksichtigt und gleichzeitig
konform ist zu den WfMC- Schnittstellenbeschreibungen. Die OMG - Submission basiert auf dem
Business Object Model der OMG, das auch in wesentlichen Teilen die Grundlage des technischen
Referenzmodells von VAA bildet (vgl. Kapitel 2). Insbesondere verwenden die OMG Spezifikationen
eine zu VAA konforme Definition von BO, PBO und EBO.
Aufgrund des Bezugs zum OMG - Business Object Metamodell sind diese Spezifikationen nicht nur
auf der Workflowebene anwendbar, sondern auf allen Ebenen der Prozeßsteuerung. Ihre Anwendung
hat den Vorteil, daß dadurch ein über alle Steuerungsebenen einheitliches Verhalten realisiert werden
kann. Der Verzicht auf eine formale Trennung zwischen unterschiedlichen Steuerungsebenen ist unseres Erachtens auch deshalb sinnvoll, da die DV-technische Unterstützung von Geschäftsprozessen
sehr unterschiedlich sein kann. So können in Zukunft manche Geschäftsprozesse von Anfang bis Ende
durch automatisch ablaufende DV-Vorgänge realisiert sein (z.B. Internet-Geschäftsprozesse), während
andere Prozesse durch eine Workflow-Anwendung unterstützt sind. Trotzdem ist es oft wünschenswert, in beiden Prozessen die gleichen Prozessbausteine - allerdings auf unterschiedlichen Ebenen - zu
verwenden. Ein Worklflow Management System muß interne alsauch externe Geschäftsvorfälle unterstützen
Die in diesem Kapitel vorgestellten Schnittstellen und Konzepte zur Prozeßsteuerung basieren deshalb
auf den OMG-Spezifikationen. Im Sinne einer breiteren Verwendbarkeit haben wir auf die CORBASpezifika verzichtet, ohne jedoch die grundsätzliche Struktur der Schnittstellen und der beteiligten
Objekte zu verändern. Eine Kurzbeschreibung der OMG-Spezifikation findet sich zum Beispiel in
[OOPS97]
.
44
© GDV 2001
Inhalt
Die folgende Abbildung stellt das Referenzmodell der WfMC in einer für unsere Belange passenden
Form dar:
Prozessdefinitionen
Prozeßsteuerung
Administration
Überwachung
PBO
AnwenderDienste
(Postkorb, Termin usw.)
„externe“
Steuerungen
PBO
ausführende
Komponenten
Abbildung 18: Elemente der Prozeßsteuerung
Unter den einzelnen Komponenten des Referenzmodells ist folgendes zu verstehen:
Prozessdefinitionen
Formale Spezifikation von Prozessen und die Verwendung der
Spezifikationsdaten in der Steuerung.
Prozeßsteuerung
„Run Time“ der Prozeßsteuerung. Sie besteht aus den PBOs selbst
sowie allen weiteren Hilfsfunktionen bzw. -objekten, die für ihre
Ausführung erforderlich sind (entspricht dem „Workflow
Enactment System“ im Referenzmodell der WfMC)
„externe“ Steuerungen
Im WfMC - Referenzmodell werden Schnittstellen zwischen
Workflowsteuerungen unterschiedlicher Hersteller definiert. Diese
Spezifikationen können auch für die Schnittstellen zwischen PBOs
verallgemeinert werden.
ausführende Komponenten
Im WfMC - Referenzmodell sind ausführende Komponenten Anwendungen, die in den einzelnen Prozeßschritten ausgeführt werden. Die Spezifikationen der Schnittstellen zu diesen Anwendungen kann auch für die Schnittstellen zwischen PBO und EBO verwendet werden.
Anwender - Dienste
Client-Anwendungen des Workflowsystems zur Steuerung der
Prozesse und Verwaltung der Arbeitsaufträge. Das WfMC Modell
definiert Schnittstellen zu dieser Art von Anwendungen.
Administration / Überwachung
Das WfMC – Modell definiert Schnittstellen zur Steuerung und
Überwachung des Workflowsystems.
Die folgende Abbildung zeigt das Objektmodell der Workflow Management Facility der OMG. Es
dient als Ausgangspunkt der VAA-Spezifikationen.
© GDV 2001
45
Inhalt
Abbildung 19: Das Objektmodell der Workflow Management Facility der OMG,  by OMG
Gemäß dieser Abbildung definiert das OMG – Modell die folgenden Kern-Schnittstellen eines
Workflowsystems:
WfRequester
Schnittstelle für den „Aufrufer“ eines Geschäftsprozesses. Über
diese Schnittstelle informiert ein Geschäftsprozess seinen „Aufrufer“ über Statusänderungen.
WfProcessMgr
„Factory“ – Schnittstelle zur Erzeugung und Suche von Prozessobjekten (analog dem BO-Manager Interface) eines bestimmten Typs.
WfProcess
Schnittstelle eines jeden Prozessobjekts. Über diese Schnittstelle
wird der Prozeß von seinem „Requester“ gesteuert.
WfActivity
Schnittstelle eines Prozessschrittes. WfActivity ist abgeleitet aus
WfRequester, d.h. ein Prozessschritt kann selbst als „Requester“
eines Teilprozesses dienen.
WfExecutionObject
Abstrakte Basisklasse aus der WfProcess und WfActivity abgeleitet
wird. Sie definiert die grundlegenden Eigenschaften, die Prozessen
und Prozessschritten gemeinsam sind. Dazu gehören u.a. Name,
eine ID und eine Beschreibung des aktuellen Prozesses und Angaben über die Priorität.
46
© GDV 2001
Inhalt
WfAssignment
Definiert die Verbindung zwischen Aktivitäten (Prozessschritten)
und Ressourcen.
WfResource
Schnittstelle zur Repräsentation der Person oder des Systems, das
eine Aktivität ausführt oder zulässt (Schnittstelle zu Berechtigungssystemen!)
WfEventAudit
Allgemeine Schnittstelle für die Registrierung von WorkflowEreignissen. Für diese Schnittstelle existieren verschiedene Spezialisierungen, abhängig vom Typ des Ereignisses.
Die Dualität von Aktivitäten, die sowohl als Aufrufer von Prozessen als auch als Prozessschritte erscheinen können, erleichtert die hierarchische Strukturierung von Prozessen durch Teilprozesse. Die
Differenzierung zwischen WfProcess, WfRequester und WfActivity ermöglicht zudem die Anbindung
von Anwendungskomponenten, die nicht über Workflowschnittstellen verfügen bzw. die Koppelung
verschiedener Workflowsysteme (in unterschiedlichen Umgebungen). WfActivity fungiert dabei als
Adapterschnittstelle zwischen Aufrufer und Prozess. Da einem WfRequester mehr als ein WfProcess
zugeordnet werden kann, ist auch auf dieser Ebene eine Zusammenfassung von Teilprozessen möglich.
WfProcess, WfRequester und WfProcessMgr verfügen über Methoden, mit denen durch den Prozessbaum navigiert werden kann.
3.3.1.3. Abbildung auf das VAA - Referenzmodell
Die im vorherigen Abschnitt beschriebene OMG-Spezifikation kann auf relativ einfache Weise auf das
VAA-Referenzmodell abgebildet werden (siehe 3.2.3). Das Interface WfProcessMgr kann durch eine
Spezialisierung des BO-Managers oder durch diesen selbst implementiert werden. In einer EJBImplementierung kann dieses Interface durch das Home – Interface des zugeordneten Prozessobjektes
realisiert werden, da dieses als BO-Manager fungiert.
Auf analoge Weise realisieren PBOs die Interfaces WfRequester, WfProcess und WfActivity. Dadurch
können PBOs direkt als Teilprozesse in andere PBOs integriert werden.
<<In terface >>
Exe cutionObject
BOManager
<<In terface >>
Req uester
PBOManager
<<In terface >>
P rocess
<<In terface >>
Activity
<<In terface >>
ProcessManager
P BO
Abbildung 20: Abbildung auf das VAA-Referenzmodell
Diese einfache Abbildung muss für komplexere Anwendungssysteme erweitert werden. In dialogorientierten Systemen besteht ein Prozess im allgemeinen aus dialogorientierten Teilen und automatisierten Schritten („Dunkelverarbeitung“). Dialogsequenzen werden dann sinnvollerweise durch spezi© GDV 2001
47
Inhalt
elle Activity-Objekte repräsentiert (siehe Abbildung 21). Erst wenn diese sich im Status Completed
(siehe nächsten Abschnitt) befinden, schreitet der Prozess fort.
Aktivitäten wie Prämienberechnung, Druckausgabe oder Deckungsprüfung können auf die gleiche
Weise über Activity-Objekte eingebunden werden. Der Vorteil gegenüber einer direkten Einbindung in
das PBO liegt in der Universalität der WfActivity-Schnittstelle. Auf diese Weise eingebundene Komponenten sind in jeder Umgebung, die diese Spezifikation erfüllt, einsetzbar.
Einbindung von EBOs
Die Bearbeitung, Speicherung und Transaktionssicherung von Entity Business Objects ist gemäß der
OMG-Spezifikation nicht durch das Workflow-Management zu leisten. Die OMG – Spezifikation
konzentriert sich auf die Prozesssicht eines Anwendungssystems. Diese Abgrenzung ist deshalb sinnvoll, weil sie die Anwendbarkeit der Spezifikation auf allen Prozessebenen erlaubt. Im VAAReferenzmodell sind EBOs PBOs zugeordnet, die Transaktionsgrenzen werden von den PBOs bestimmt. Das Transaktionsverhalten kann unabhängig von den benannten Prozessschittstellen gestaltet
werden.
<< Inte rf ac e> >
ExecutionObject
<<Interface>>
Requester
<<Interface>>
Process
<<Interface>>
Activity
PBO
Dialogsteuerung
SystemA da pt er
De ck ungsP ru ef er
DruckOutput
PrämienServer
Abbildung 21: Integration von Activity-Objekten
3.3.1.4. Prozesszustände
Das OMG-Modell definiert einen hierarchischen Satz von Systemzuständen, der nach unten beliebig
erweitert werden kann:
48
© GDV 2001
open
Inhalt
closed
not_running
completed
not_started
running
terminated
suspended
aborted
Abbildung 22: Prozesszustände
Für eine detaillierte Beschreibung dieser Systemzustände sei auf die OMG-Dokumentation verwiesen[OMG98b]. Die benannten Zustände sind als IDL-Datentypen spezifiziert, der aktuelle Zustand eines
Prozessobjektes kann durch Aufruf entsprechender Methoden, die in WfExecutionObject spezifiziert
sind, ermittelt werden. Diese Methoden und Zustände müssen von allen Prozess- und ActivityObjekten unterstützt werden. Eine hierarchische Erweiterung dieser Zustände ist möglich, sie werden
durch eine Punktnotation dargestellt:
MyState = open.running.my_spezial_running_substate
Die in der OMG – Spezifikation definierten Zustände und auch die möglichen Erweiterungen sind
wenig geeignet, fachliche Zustände von Prozessen abzubilden. Fachliche Zustände sollten deshalb als
Elemente des ProcessData Datentyps definiert werden. Dieses Verfahren ist in Abschnitt 3.3.1.7 beschrieben.
3.3.1.5. Administration und Überwachung
Für die Überwachung von Systemzuständen definiert das OMG-Modell eine Reihe von Ereignistypen:
WfEventAudit
Allgemeine Schnittstelle für die Registrierung von Workflowereignissen. Die folgenden Ereignistypen sind Spezialisierungen von
WfEventAudit.
WfStateEventAudit
Schnittstelle für ein Ereignis, das Zustandsänderungen eines Prozess markiert.
WfCreateProcessEventAudit
Schnittstelle für ein Ereignis, das die Erzeugung eines Prozesses
markiert
WfDataEventAudit
Schnittstelle für ein Ereignis, das die Änderung von Prozessdaten
markiert.
WfAssignmentEventAudit
Schnittstelle für ein Ereignis, das die Änderung von Ressourcenzuordnungen markiert.
WfEventAudit – Events und seine Spezialisierungen werden über einen Notification Service (z.B. als
StructuredEvents der OMG) von Prozessen, Aktivitäten und Ressourcen an Überwacher („Listener“)
verschickt. Die Überwachung selbst wird von der OMG als interne Funktion eines WorkflowManagement-Systems angesehen und ist deshalb nicht Bestandteil der Spezifikation.
© GDV 2001
49
Inhalt
Die WfEventAudit – Schnittstelle definiert Methoden, die eine Navigation über eine zusammengehörende Kette von Ereignissen erlauben. Ereignisse sind darüber hinaus persistent und ihr Lebenszyklus
ist von dem des auslösenden Prozesses unabhängig.
Das Ereignismodell der OMG kann direkt auf das VAA-Referenzmodell übertragen werden. PBOs
fungieren dabei als Ereignisquellen. Für die Überwachung fachlicher Vorgänge oder Geschäftsprozesse sind die im OMG – Modell definierten Ereignistypen nicht ausreichend. Für die Verfolgung
eines Vorganges aus fachlicher Sicht („Vorgangshistorie“) sind WfDataEventAudits geeignet. Fachliche Vorgangsbeschreibungen sind dabei als Prozessdaten (Typ ProcessData) hinterlegt. Gegebenenfalls ist auch eine Spezialisierung des Typs WfDataEventAudit möglich. Auch die Fehlerbehandlung
(siehe Kapitel 3.3.4) kann über diese Ereignisschnittstelle abgewickelt werden.
Schnittstellen zur Administration der Prozesssteuerung sind derzeit von der OMG noch nicht definiert. Die Administration selbst ist aus Sicht der OMG (und WfMC) eine interne Funktion des
Workflowsystems.
3.3.1.6. Zuordnung von Ressourcen
Die Zuordnung von Ressourcen, die für die Bearbeitung einer Activity benötigt werden, ist im OMGModell nur rudimentär durch die Schnittstellen WfAssignment und WfResource definiert. Vorgangssteuerungs- und Workflowsysteme müssen diese Schnittstellen spezialisieren. Ein entsprechendes RFP
(Request for Proposal) für die Ressourcenzuordnung wurde in 2000 von der OMG veröffentlicht
[OMG2000].
Abbildung 23 stellt das prinzipielle Schema der Zuordnung von Ressourcen zu PBOs dar. Abhängig
vom Typ der Ressource wird die WfAssignment und WfResource – Schnittstelle durch unterschiedliche
Klassen implementiert. Die Abbildung stellt in vereinfachter Form drei Szenarien dar:
Die Zuordnung eines Postkorbs
Da die WfResource – Schnittstelle über Methoden verfügt
um alle der Ressource zugeordneten Aktivitäten zu ermitteln und zu ändern, kann durch dieses Verfahren eine
Postkorbanwendung implementiert werden
Die Zuordnung einer Bearbeiter- Über eine Schnittstelle zu einem Berechtigungssystem
rolle
kann ein PBO alle zulässigen Rollen ermitteln und entsprechende RollenAssignment – Objekte erzeugen (lassen). Den RollenAssigment – Objekten sind die entsprechenden Rollen – Objekte zugeordnet. Durch die Verwendung der OMG-Schnittstellen ist dieses Verfahren auch in
heterogenen Systemumgebungen einsetzbar. Gegebenenfalls müssen entsprechende WfAssignment und WfResource-Adapter für Rollenobjekte implementiert werden.
Die Zuordnung eines Users
Die Zuordnung eines Users zu einem PBO geschieht in
analoger Weise wie die Zuordnung einer Bearbeiterrolle.
Eine Berechtigungsprüfung gegenüber der zugeordneten
Rolle kann ebenfalls erfolgen (siehe unten).
Tabelle 3 : Ressourcenzuordnung
50
© GDV 2001
Inhalt
<<In ter f ac e>>
ExecutionObject
<<In ter f ac e>>
Requester
<<Interf ace>>
Process
<<Interf ace>>
Activ ity
PBO
Postko rbAssi gnment
<<In ter f ac e>>
Assignment
Ro llenAs ignme nt
Postkorb
UserAssignment
Rolle
Us er
<<Interf ace>>
Resource
Abbildung 23: Zuordnung von Ressourcen zu PBO
Das gleiche Verfahren kann angewandt werden, wenn die Activity – Schnittstelle nicht durch ein PBO,
sondern durch andere Komponenten (Dialogsteuerung, Fremdsystem-Adapter usw.) implementiert
wird (siehe Abbildung 24). So wird z.B. die Zugriffsberechtigung für einen Dialog von einer dem
Dialog zugeordneten Rolle (z.B. Angebotsersteller.Aussendienst) und vom aktuellen Anwender (z.B.
Hugo Maier) abhängig sein. User und Rolle implementieren beide die WfResource – Schnittstelle, die
Zuordnung zum Dialog geschieht über die Relationen UserAssignment und RollenAssignment, beide
implementieren die WfAssignment – Schnittstelle. Durch die (dem Dialog nicht transparente) UserRollen – Zuordnung im Berechtigungssystem kann das UserAssignment gegebenenfalls abgewiesen
werden (durch eine in WfAssignment definierte InvalidResource – Exception, die beim Zuordnungsversuch ausgelöst wird).
© GDV 2001
51
Inhalt
<<Interf ace>>
Activ ity
<<Interf ace>>
Assignment
Dialogsteuerung
RollenAssignment
UserAssignment
User
Ro lle
<<Interf ace>>
Resource
Abbildung 24: Zuordnung von Ressourcen zu Dialogen
3.3.1.7. Informationstransport im Prozess: die Vorgangsakte
Analog ihrem Vorbild aus der „realen“ Welt dient die Vorgangsakte der „Speicherung“ und Übermittlung aller Informationen, die für Aktivitäten bzw. Teilprozesse notwendig sind. Sie repräsentiert
gleichzeitig den aktuellen fachlichen Bearbeitungsstand des Vorganges. Dieser fachliche Status fungiert als Schaltbedingung für den Zustandswechsel innerhalb eines Vorgangs. Davon unabhängig fungiert der oben beschriebene Status eines Prozesses als Trigger für den Zustandswechsel. Er teilt mit,
dass ein Prozess begonnen, beendet oder abgebrochen wurde. Daraufhin ermittelt der übergeordnete
Prozess anhand des fachlichen Status den nächsten Prozessschritt.
Im OMG-Modell wird die Vorgangsakte als ProcessData – Objekt zwischen Requester, Process und
Activity ausgetauscht. Die Strukturbeschreibung des ProcessData – Objektes ist als ProcessDataInfo
– Objekt vom WfProcessMgr zu ermitteln. ProcessData – Objekte sind Sequenzen von Name-Value –
Paaren. Der zulässige Typ eines Values wird dessen Namen zugeordnet. Diese Zuordnung erfolgt in
der ProcessDataInfo – Struktur.
Bei der Initialisierung eines Prozessobjektes werden Vorgangsinformationen mit set_context() dem
Prozess übermittelt. Das Ergebnis nach Beenden des Prozesses erhält man durch Aufruf von result(),
siehe Abbildung 25.
52
© GDV 2001
aRequester :
Requester
aProcessMgr : Process
Man ager
Inhalt
aProcess : Process
anActi vi ty : Act ivit y
get_context_signature( )
set_context( )
start( )
set_context( )
result( )
result( )
Abbildung 25: Austausch von Prozessinformation
Es ist unmittelbar einsichtig, dass die Sammlung aller Informationen zu einem Vorgang in einem einzigen globalen „Datentopf“ weder praktikabel noch wünschenswert ist. Zum einen werden in Geschäftsprozessen Anwendungen mit völlig unterschiedlichen Datenstrukturen (auf unterschiedlichen
Systemen) zum Einsatz kommen, zum anderen erzeugt ein globaler Datentopf unzulässige Abhängigkeiten zwischen Aktivitäten und Teilprozessen, die die Wiederverwendung bzw. Änderung von Prozessen erschweren.
Der Kontext eines Prozesses sollte deshalb lediglich die ihm zugeordneten Informationen beinhalten,
d.h. den eigenen fachlichen Status und alle Schlüsselinformationen, die zur Identifikation seiner Daten
und zur Initialisierung untergeordneter Prozesse notwendig sind. Die gesamte Vorgangsakte kann
durch Navigation durch den Prozessbaum ermittelt werden.
Der gesamte fachliche Status ist also hierarchisch gegliedert und bestimmt zusammen mit dem hierarchischen Prozessstatus (im Sinne des OMG-Modells) den Gesamtzustand des Prozesses, wie
Abbildung 26 beispielhaft zeigt. In diesem Beispiel wird angenommen, dass der Prozess Angebotserstellung aus den Teilprozessen Angebotsdaten erfassen, Partnerdaten erfassen, Risiko prüfen und Tarifieren besteht. Partnerdaten erfassen besteht seinerseits aus den Teilprozessen Partner suchen und
alternativ Partner ergänzen bzw. Partner anlegen. Der fachliche Status des Teilprozesses Partner
suchen (nach dessen Beendigung) legt fest, ob ein Partner ergänzt oder neu angelegt werden muss.
© GDV 2001
53
Inhalt
Angebotsdaten
erfassen
Angebotserstellung
Partner suchen
Completed
Completed
Running
Neukunde
OK
In Bearbeitung
Partner ergänzen
Partnerdaten
erfassen
Not_started
Running
-
In Bearbeitung
Partner anlegen
Suspended
PLZ falsch
Risiko prüfen
Tarifieren
Not_started
Not_started
-
-
Legende:
OMG-Status
Fachlicher Status
Abbildung 26: Beispielprozess "Angebotserstellung "
Eine Darstellung des Status eines Vorgangs auf dem Bildschirm des Sachbearbeiters könnte dann so
aussehen:
Vorgang
Status
Angebot „Hugo Maier vom 19.12.2000“
In Bearbeitung
Angebotsdaten erfassen
Partnerdaten erfassen
Partner suchen
Partner anlegen
Risiko prüfen
Tarifierung
OK
In Bearbeitung
Neukunde
Wartend (PLZ falsch)
Offen
Offen
Tabelle 4 : Beispiel für Stati einer Vorgangsakte
3.3.1.8. Implementierung einer Prozesssteuerung
Die vorangegangenen Abschnitte beschreiben, wie das OMG-Modell auf das VAA-Referenzmodell
abgebildet werden kann. Damit ist allerdings nur das Zusammenspiel einzelner Komponenten wie
PBOs, Dialogsteuerung und Berechtigungssystem beschrieben und dies auch nur soweit, wie es die
OMG-Spezifikationen bereits vorsehen. Für die Implementierung einer Prozesssteuerung sind neben
den PBOs selbst auch alle benötigten Dienstkomponenten zu realisieren:
Administrations und Überwachungssystem
Anwendungsdienste wie Postkorb, Berechtigungssystem, Termin/Wiedervorlage-System usw.
54
© GDV 2001
Inhalt
Prozeßdefinitions-System und die Bereitstellung eines Prozessmodells für die Laufzeitumgebung
der Prozesssteuerung
Eine Laufzeit-Umgebung, die Basisdienste für PBOs zur Verfügung stellt wie z.B. Funktionen
zum Suchen von Prozessobjekten, Notification Service für Prozessereignisse, Weiterleitung von
Vorgangsakten usw.
Anwendungsdienste sind in anderen Kapiteln dieses Dokuments beschrieben, die Administrationsund Überwachungsfunktionen können im Rahmen dieses Referenzmodells nicht weiter ausgeführt
werden.
Derzeit liegen keine OMG-Spezifikationen über die Schnittstellen zwischen Prozessdefinitionssystem
und Laufzeitsystem (Workflow Enactment Service) vor. Dementsprechend fehlt auch ein Metamodell
für Prozessbeschreibungen. Die Definition eines VAA-Prozess-Metamodells würde den Rahmen dieses Dokuments sprengen und ist auch wenig sinnvoll, da eine Konformität mit zukünftigen Standards
nicht gegeben wäre. Zudem ist nicht in allen Anwendungsfällen und auf allen Steuerungsebenen der
Einsatz eines universellen Prozessdefinitionssystems sinnvoll, zu unterschiedlich sind die Anforderungen und Plattformen. Wo angemessen wird deshalb der Einsatz kommerzieller Workflowsysteme
empfohlen.
In anderen Fällen, insbesondere bei Vorgangssteuerungen innerhalb von Anwendungssystemen (d.h.
unterhalb der klassischen Workflowebene), muss die Prozesslogik auf andere Weise implementiert
werden. Liegt ein Modell eines Teilprozesses in Form eines State Diagrams vor, so lässt sich das zugehörige PBO prinzipiell auf die folgende Weise implementieren (siehe auch Abschnitt 3.3.1.9):
durch Programmierung des PBO „von Hand“.
durch Code-Generierung aus dem Modell (auf Basis entsprechender Templates).
durch Schaffung generischer Prozessobjekte mit einem parametrisierbaren (z.B. tabellengesteuerten) Zustandsautomaten.
Grundsätzlich ist keine dieser Vorgehensweisen „effizienter“ oder empfehlenswerter als die anderen.
Eine Programmierung „von Hand“ kann mit entsprechenden Sprachen und Frameworks sehr effizient erfolgen. Man vermeidet damit die Entwicklung bzw. Implementierung komplexer Generatoren
oder Regelsysteme und ist nicht von deren Funktionalität und Weiterentwicklung abhängig.
Der Einsatz von Generatoren bietet eine bessere Dokumentation der Anwendung und reproduzierbare Qualität. Gleichzeitig lässt sich die erforderliche PBO-Laufzeit-Umgebung mit generieren.
Parametrisierbare Zustandsautomaten ermöglichen es Fachbereichen, Prozesse in gewissem Rahmen selbst zu gestalten. So können beispielsweise produktabhängige Vorgänge wie die Angebotserstellung durch einen produktabhängigen Zustandautomaten gesteuert werden.
Die Wahl der Implementierungsmethode beeinflusst also die Wartbarkeit der Prozessobjekte und ist
gleichzeitig abhängig von den Einsatzbereichen und gewählten Plattformen. Das technische Referenzmodell der VAA schreibt keine bestimmte Implementierungsmethode vor. Meistens werden innerhalb einer Anwendungslandschaft alle Varianten parallel auftreten, da eine Vereinheitlichung aufgrund unterschiedlicher Plattformen, Entwicklungsumgebungen und eingebundener kommerzieller
Lösungen kaum mit vertretbarem Aufwand möglich ist.
© GDV 2001
55
Inhalt
Das oben beschriebene Schnittstellen-Modell erlaubt jedoch die Koexistenz unterschiedlicher Varianten wie Abbildung 27 zeigt.
PBOs können als Aktivitäten in ein Workflowsystem eingebunden werden (zum Beispiel als WorkPerformer in Filenet), sofern dieses die WfActivity- oder eine vergleichbare Schnittstelle unterstützt. Der
Prozessablauf, d.h. die Folge von Aktivitäten wird dabei durch das im Workflowsystem abgelegte
Prozeß-, Rollen,- und Organisationsmodell gesteuert. Das aufgerufene PBO übermittelt lediglich den
Status und das Ergebnis (als ProcessData – Variable) an den Workflow zurück. Der Workflow steuert
auch die Ressourcenzuordnung an den Prozess über die Activity – Schnittstelle. Bei PBOs, die an ein
Workflowsystem angebunden werden, ist deshalb vorab festzulegen, welche Ressourcen über den
Workflow vermittelt und welche intern zugeordnet werden. Unabhängig davon kann ein PBO über
eine interne, dem Workflow nicht transparente Steuerung verfügen.
PBOs mit interner Steuerung (generiert oder programmiert) können beliebige andere PBOs über die
gleiche Schnittstelle aufrufen. PBOs können auch externe Regelsysteme (z.B. einen Produktserver)
nutzen, um regelabhängige Zustandswechsel durchzuführen. PBOs mit externer Steuerung verfügen
über keine interne Repräsentation ihres Zustandes, können diesen aber vom Zustandsautomaten ermitteln. Der Zustandsautomat übernimmt in diesem Fall auch die Aktivierung weiterer Teilprozesse,
ordnet diese aber auch dem PBO zu, um eine Navigation über die WfActivity – Schnittstelle zu ermöglichen. Das PBO selbst fungiert in diesem Szenario lediglich als Container für Teilprozesse oder assoziierte EBOs. Die Schnittstelle zwischen Zustandsautomat und PBO ist bidirektional. Ihre jeweilige
Ausprägung ist systemabhängig.
Workflow-System
WfActivity
WfActivity
PBO
PBO
Externe Strg.
(generiert/progammiert)
(Zustandautomat)
PBO
PBO
PBO
erz
eu
gt
Interne Strg.
Externer
Zustandsautomat
Regelsystem
PBO
Abbildung 27: Kombination von Steuerungsvarianten
Die Allgemeingültigkeit der Activity- und Process-Schnittstelle erleichtert die Gestaltung kontextunabhängiger Komponenten. In der folgenden Abbildung besteht ein PBO „Angebotserstellung“ aus
einer Vielzahl von Teilprozessen, die als Komponenten integriert werden können. Anstelle der generischen Prozessstati des OMG-Modells setzt eine solche Integration im allgemeinen fachlich motivierte
Stati voraus, wie in der Abbildung angedeutet. Diese fachlichen Stati werden über ProcessData – Elemente zwischen den Komponenten vermittelt. In einer Komponenten-Architektur wie JavaBeans können diese Elemente als Bean-Properties definiert werden.
56
© GDV 2001
Inhalt
Aus Prozesssicht fungieren die generischen Stati des OMG – Modells daher als Trigger für Zustandswechsel. Die fachlichen Stati entsprechen den Schaltbedingungen eines Übergangs, die festlegen, welcher Folgezustand einzunehmen ist.
Angebot wird erstellt
Partner-Komponente
Angebots-Komponente
Do: PBO11 aufrufen
Exit: Ergebnis analys.
Erfaßt Partner
Ermittelt Partner
Erfaßt A.Daten
[OK]
Do: PBO12 aufrufen
[n. vorh.]
Do: PBO13 aufrufen
[OK]
[vorh.]
Prüft Risiko
Ergänzt Partner
[OK]
Do: PBO14 aufrufen
Tarif-Komponente
Do: PBO15 aufrufen
Tarifiert
[OK]
Do: PBO16 aufrufen
[OK]
Fehler:
Daten unvollständig
Angebot ist erstellt
Abbildung 28: Beispiel für Prozesskomponenten
3.3.1.9. Vom Prozessdesign zum PBO
Es existieren eine Vielzahl unterschiedlicher Methoden für die Darstellung von Geschäftsprozessen.
Die gebräuchlichsten Darstellungen verwenden Varianten des Petri-Netz-Modells [Bal96]. Im Rahmen
der UML-Spezifikation sind Activity Diagrams [Fow+97] dafür vorgesehen Prozesse zu modellieren.
Sie sind derzeit jedoch noch nicht geeignet, alle Aspekte der Prozessmodellierung abzudecken, entsprechende Erweiterungen sind jedoch geplant [OMG98]. Wir verwenden für die hier angeführten
Beispiele eine Petri-Netz-Notation.
Die folgende Abbildung zeigt das (vereinfachte) Modell eines Geschäftsprozesses „LV-Angebot“ auf
hoher Ebene mit Hilfe eines Petri-Netzes (genauer: Prädikat-Transitionsnetz, Pr/T-Netz, [Bal96]).
Pr/T-Netze erlauben es, die für die Modellierung von PBOs wichtigsten Eigenschaften eines Prozesses
in übersichtlicher Form darzustellen:
Kreise repräsentieren Zustände innerhalb des Prozesses (Schaltstellen)
Rechtecke repräsentieren Aktivitäten der beteiligten Systeme oder Personen. Aktivitäten führen
zu Zustandsübergängen (Transitionen) innerhalb des Prozesses.
Ein schwarzer Punkt (Token) innerhalb eines Zustandes stellt in einem Geschäftsprozess den aktuellen Ort einer (oder mehrerer) durchlaufenden Vorgangsakten dar. Aktivitäten können Attribute der Vorgangsakte ändern (und sogar neue Akten erzeugen). Im OMG-Modell werden Vorgangsakten als ProcessData – Objekte abgebildet (siehe Abschnitt 3.3.1.7).
Eine Aktivität kann nur ausgeführt werden, wenn in dem davor liegenden Zustand eine Vorgangsakte vorliegt. In Pr/T-Netzen können darüber hinaus noch Schaltbedingungen angegeben werden,
die zusätzlich erfüllt sein müssen. Diese Schaltbedingungen können mit Hilfe von Attributen (Prädikaten) der Vorgangsakte formuliert werden. In Fällen mit einer endlichen, nicht zu großen Men© GDV 2001
57
Inhalt
ge von Ausprägungen der Schaltbedingungen genügt die Einführung eines fachlichen Status zur
Unterscheidung unterschiedlicher Schaltbedingungen. Im unteren Beispiel wird die Transition
„Angebot erstellen“ nur dann ausgeführt, wenn es sich bei der Vorgangsakte um ein Angebot handelt, gekennzeichnet durch die Schaltbedingung „[Angebot]“. Andernfalls muss eine andere (hier
nicht dargestellte) Aktivität die Akte „abholen“.
[Sonstiges]
PostEingang
[Fehler]
Archivierung
Manuelle
Vorerfassung
(autom.)
Weiterleitung
Angebot
erstellen
Drucken/
Versenden
ArchivAnwendung
BestandsKompon.
WorkflowKompon.
BestandsKompon.
TextSystem
PBO1
InternetAnfrage
Autom.
Vorprüfung
[Angebot]
BestandsKompon.
Wiedervorl.
setzen
TerminSystem
Modellierung als Prädikat-Transitions-Netz (Pr/T - Netz)
Token stellt durchlaufende „Akte“ dar
In den Transitionen angegebene Anwendungen sind als Beispiele zu verstehen
Abbildung 29: Beispielprozeß LV-Angebot, oberste Ebene
Ein Geschäftsprozeß kann also charakterisiert werden durch:
Eine Menge von Zuständen, die von Vorgangsakten durchlaufen werden
Aktivitäten, die zu einem Zustandswechsel führen
(Schalt-)Bedingungen, die gegebenenfalls die Auswahl von Aktivitäten bestimmen. Diese Bedingungen nutzen Attribute der Vorgangsakte.
Soll ein Geschäftsprozeß durch ein PBO abgebildet werden, so bedeutet dies:
Ein PBO realisiert intern einen Zustandsautomaten, der abhängig vom aktuellen Zustand und
definierten Schaltbedingungen Aktivitäten ausführt
Der Prozeß innerhalb des PBO wird mittels einer Vorgangsakte angestossen
Das PBO kann Attribute der Vorgangsakte für die Auswertung von Schaltbedingungen nutzen.
Aktivitäten können die Attribute der Vorgangsakte ändern.
Die folgende Abbildung zeigt die Dekomposition der Aktivität „Angebot erstellen“ als Teilprozess
von „LV-Angebot“. „Angebot erstellen“ wird durch ein PBO realisiert (PBO1):
58
© GDV 2001
Inhalt
Angebot
erstellen
BestandsKompon.
[Fehler]
[Fehler]
[Fehler]
[nicht vorhanden]
PBO11
PBO12
PBO13
PBO15
PBO16
BestandsKompon.
Partner
Kompon.
PartnerKompon.
PrüfKompon.
TarifKompon.
Angebotsdaten
erfassen
Partner
ermitteln
Neue Partner
erfassen
(Risiko-)
Prüfung
Tarifierung
PBO14
[vorhanden]
PartnerKompon.
Partnerdaten
abgleichen/ergänzen
PBO1
Abbildung 30: Teilprozess Angebot erstellen
PBO1 ruft abhängig vom eigenen Zustand und den Attributen der durchlaufenden Vorgangsakte andere PBOs auf, die Teilprozesse darstellen (z.B. das PBO13 für die Partnererfassung). Die Vorgangsakte
wird diesen PBOs übergeben. Analog dazu ist der Anstoß von PBO1 das Bereitstellen einer Vorgangsakte „Geschäftsereignis von außen“.
Durch die Dekomposition des Geschäftsprozesses entstehen zusätzliche Zustände: Auf der höchsten
Ebene um die Aktivität „Angebot erstellen“ herum sind lediglich die Zustände „Weitergeleitet [Angebot, Sonstiges]“ und „Angebotserstellung fertig [Angebot erstellt, Fehler]“ definiert, im Teilprozess
selbst gibt es dazwischen noch die Zustände3:
Angebotsdaten erfaßt [OK, Fehler]
Partner ermittelt [vorhanden, nicht vorhanden]
Partner erfaßt [OK, Fehler]
Risikoprüfung durchgeführt [OK, Fehler]
Tarifierung durchgeführt [OK, Fehler]
Es ist im allgemeinen nicht sinnvoll, diese Unterzustände bereits in den oberen Ebenen zu definieren,
da hierdurch die Wiederverwendbarkeit von Teilprozessen (s.u.) stark eingeschränkt wird und Änderungen auf unterster Ebene sich auf allen Ebenen auswirken. Auf oberer Ebenen genügt es den Zustand „Angebot wird erstellt“ zu definieren. Er drückt die Tatsache aus, daß die Aktivität (Transition)
3
Aus Gründen der Übersichtlichkeit wird hier nicht unterschieden zwischen verschiedenen Arten von „Fehlern“, z.B. „Daten unvollständig“
oder „zu hohes Risiko“ usw.
© GDV 2001
59
Inhalt
zwischen den Zuständen „Weitergeleitet“ und „Angebotserstellung fertig“ gerade durchgeführt wird4.
Auf der Ebene des Teilprozesses spricht man von einem „Superstate“.
State Diagrams für die Detailspezifikation von PBOs
Für die detaillierte, objektorientierte Modellierung von PBOs ist die Darstellung des Teilprozesses als
UML-State-Diagram [Fow+97] sinnvoller. State Diagrams sind eine OO-Variante der Statecharts
[Har87] mit deren Hilfe sich Zustandsautomaten beschreiben lassen. State Diagrams ermöglichen eine
konsistente Dokumentation mit anderen UML-Darstellungsformen wie Collaboration und Class Diagrams.
Angebot wird erstellt
Ermittelt Partner
Erfaßt A.Daten
Do: PBO11 aufrufen
[OK]
Do: PBO12 aufrufen
Erfaßt Partner
[n. vorh.]
Do: PBO13 aufrufen
[OK]
[vorh.]
Prüft Risiko
Ergänzt Partner
[OK]
Do: PBO14 aufrufen
Do: PBO15 aufrufen
Tarifiert
[OK]
Do: PBO16 aufrufen
[OK]
Angebotserstellung
fertig [Fehler]
Angebotserstellung
fertig [OK]
Abbildung 31: State Diagram "Angebot erstellen"
Durch den Übergang zu State Diagrams ändert sich die Betrachtungsweise: Zustände können nicht nur
Endzustände von Zustandsübergängen sein, sondern selbst Aktivitäten. Zustände, in denen der Prozeß
nichts „tut“ werden durch einfache, gerundete Rechtecke beschrieben, Zustände, in denen der Prozeß
etwas „tut“ enthalten als Zustandsbeschreibung eine Tätigkeit (z.B. „Prüft Risiko“) und zusätzlich
noch Beschreibungen, was genau getan wird („Do: PBO15 aufrufen“) und ggf. noch Definitionen, was
zu Beginn und vor dem Verlassen des Zustandes getan werden muß (z.B. Exit: Ergebnis analysieren“).
Diese Betrachtungsweise ist für die Realisierung von PBOs von Vorteil, da sie die Darstellung von
Zuständen ermöglicht, die nicht ununterbrechbar ablaufen, sondern die zum Beispiel von Benutzereingaben abhängig sind. So kann zum Beispiel dem Zustand „Ermittelt Partner“ direkt ein Dialogobjekt
zugeordnet werden, das eine Partner-Suchmaske steuert.
3.3.2. Dokumentenerstellung
Gerade im Versicherungswesen nimmt das Thema „Dokumentenerstellung“ eine zentrale Rolle ein.
Verträge, Anschreiben, Werbeaktionen, Angebote sind nur Beispiele für die Vielfalt der Dokumente,
die erstellt werden müssen. Da diese Dokumente beispielsweise Produkt-, Tarif- und Partnerabhängig
erstellt werden, muß der Kontext, in dem sich gerade ein Vertrag oder ein Angebot mit der versicher-
4
Dieser Zustand könnte auch im Petri-Netz modelliert werden, dies ist allerdings im allgemeinen nicht notwendig.
60
© GDV 2001
Inhalt
ten Person bzw. dem Versicherungsnehmer befindet, in die Auswahl der Darstellung und die Wahl des
Textes einbezogen werden. In bestimmten Situationen müssen aufgrund rechtlicher Belange bestimmte Textpassagen angedruckt werden, wie beispielsweise das Sonderkündigungsrecht bei Tarifänderungen. Trotzdem muß durch die ganze Dokumentenvielfalt auch das unternehmensweite „Look
& Feel“ sowie eine produktspezifische Einheitlichkeit gewährleistet sein, auch wegen der Übersichtlichkeit für den Kunden.
Neben der Notwendigkeit, Ergebnisse von Geschäftsprozessen zu dokumentieren, beispielsweise das
Ausstellen eines Versicherungs- oder Änderungsscheins, müssen diese Dokumente in verschiedensten
Organisationsstrukturen erstellbar bzw. auch erzeugbar sein. Ein Sachbearbeiter in einer zentralen
Bestandsabteilung sollte also ebenso wie ein Vermittler, der sich vor Ort beim Kunden befindet, ein
schriftliches Angebot erstellen und ausdrucken können. Darüber hinaus könnte dieser Dokumentendienst genutzt werden, um für Internet-Interessenten oder –Kunden den Output diverser Druckstücke
für den heimischen Drucker zur Verfügung zu stellen (etwa solche , die online verfügbar sein sollten,
wie beispielsweise ein Angebot über eine Kfz-Versicherung oder eine „Grüne Karte“). Das bedeutet,
daß Dokumente auf den verschiedensten Druckplattformen zur Ausgabe gebracht werden müssen.
Aufgrund der verschiedenen Anforderungen ergibt sich eine Aufteilung der Dienstes „Dokumentenerstellung“ in einen technischen (siehe 3.3.2.1) und einen fachlichen Teil (siehe 3.3.2.2). Der
technische Teil beschreibt, wie konzeptionell verschiedene technische Voraussetzungen behandelt
werden können. Der „Print“ Dienst wird jedoch nur kurz konzeptionell erläutert. Fachliche Aspekte
bei der Dokumentenerstellung werden im fachlichen Druck-Dienst behandelt.
3.3.2.1. Technischer Dienst „Print“
Der technische Dienst ist grundsätzlich für die Ansteuerung verschiedener Druckarten zuständig. Dies
muß völlig vor dem Benutzer verborgen werden. Lediglich eine Output-Klasse und evtl. noch ein
Standort muß für den technischen Dienst ausreichend sein, um das entsprechende Dokument zu drukken. Der Print-Dienst muß auch technische Besonderheiten, wie beispielsweise die Zuführung von
Beilagen berücksichtigen.
Die zu druckenden Dokumente müssen dem technischen Druckdienst in einer einheitlichen plattformübergreifenden Informationsstruktur übergeben werden. Als plattformübergreifende Repräsentation mit Metadaten eignet sich beispielsweise XML sehr gut. Das übergebene Dokument wird dann
entsprechend dem angegebenen Endgerät in einen Druckoutput (Präsentationsformat) umgewandelt,
beispielsweise Postscript 2 oder PCL 5 und dann an das jeweilige Endgerät direkt geschickt.
Druckarten
Zentral:
•
Druckstraße
•
Endlosdruck
•
Faxversand
•
u.v.m.
Dezentral
•
Verschiedene Arbeitsplatzdrucker (Laser, Tinte, Außendienst, ...)
•
Fax
© GDV 2001
61
Inhalt
•
Email
•
u.v.m..
Dieser technische Dienst wird vom fachlichen Print-Dienst implizit genutzt. Die Angabe der OutputKlasse wird vom technischen Dienst interpretiert. Eine Umsetzung auf die verschiedenen Drucksprachen und –treiber findet direkt durch den technischen Dienst statt.
3.3.2.2. Fachlicher Dienst „Dokumentenerstellung“
Motivation
In Versicherungsunternehmen besteht die Notwendigkeit, formalisierte Druckstücke aufgrund von
Vertrags- und sonstigen Daten automatisch zu erstellen. Diese Druckstücke sollen einem einmal definierten Standard / Rahmen genügen und mit Hilfe der gespeicherten Daten angereichert werden. Abhängig von diesen Daten kann sich der Inhalt eines Druckstückes individuell verändern, ohne dabei
den Rahmen zu ändern.
Beispiel für solchen Dokumente sind: Verträge / Policen, Angebote aller Sparten, Standard-Schreiben,
Werbeanschreiben, Kontostände, Abrechnungen, Kündigungen, Anforderungen von zusätzlichen oder
fehlenden Unterlagen, Schadensmeldungen / -abrechnungen, spartenübergreifende Anschreiben, ....
Beispiel / Szenario
Druck eines Lebensversicherungsvertrages:
Abhängig vom Vertrag müssen die verschiedenen Produktkomponenten wie BUZ, Dynamik, Zu- und
Abschläge, Risikoausschlüsse, Versicherungsart (Risiko / ...) individuell angedruckt werden. Ebenso
ändert sich aufgrund dieser Produktkomponenten der Druck der Tarife und evtl. sogar die Darstellung.
Bei bestimmten Risikogruppen muß ein Haftungsausschluß angedruckt werden.
Beschreibung
Der fachliche Print / Dokumentationsdienst stellt mehrere Interfaces zur Verfügung:
•
Interface 1: Drucke
•
Parameter:
Õ Objekte, die zu drucken sind (z.B. Partner, Vertrag, Konto)
Õ Dokumentenklasse (Vertrag, Angebot, ...)
Õ Output-Klasse (evtl. mit Druckeradresse oder –standort)
Õ Liste der Adressaten
Õ Zuzuführende Beilagen
Aufgrund der definierten Dokumentenklasse ist dem Dokumentenerstellungs-Dienst bekannt, was
zu drucken ist. Mit der Dokumentenklasse wird das Dokument in Form eines Meta-Dokumentes
(beispielsweise als XML-Dokument) aufbereitet (evtl. Textbausteine sind der Dokumentenklasse
bekannt) und dann zusammen mit der Output-Klasse dem technischen Print-Dienst übergeben. Zusätzlich kann das Dokument noch dem Archivierungsdienst zur Speicherung übergeben werden.
Dies ist abhängig von der Dokumentenklasse.
62
© GDV 2001
Inhalt
Die Liste der Adressaten beschreibt die Empfänger der oder des Dokumentes. Dabei wird neben
der Adresse des Adressaten auch die Versandart (Protokoll) ermittelt, die von der Dokumentenklasse ebenso abhängig ist, wie vom Empfänger.
Der letzte Parameter beschreibt, ob dem Dokument Beilagen zuzuführen sind und um welche Beilagen es sich handelt.
•
Output:
Õ Das fertige Dokument, beispielsweise als XML-Dokument
Das fertige Dokument wird an das technische „Print“-Interface übergeben.
•
Interface 2: Zusammenführen von Dokumenten
•
Parameter:
Õ Liste von Adressaten, dessen Dokumente zusammengeführt werden sollen
Õ Zeitraum, über den verschiedene Dokumente eines Adressaten zusammengeführt
werden.
Werden für einen Adressaten mehrere Dokumente erstellt, besteht die Möglichkeit, über diesen
Dienst die verschiedenen Dokumente zusammenzuführen und als ein Schriftstück zu versenden.
Dabei wird geprüft, ob ein angegebener Adressat im spezifizierten Zeitraum mehrere Dokumente
erhalten würde.
Bevor diese Dokumente zusammengeführt werden können, muß geprüft werden, ob die technischen und organisatorischen Voraussetzungen für eine Zusammenführung erfüllt sind. Dabei werden auch Kosten- Nutzen Betrachtungen angestellt (soweit implementiert). Beispielsweise macht
die Zusammenführung von zwei an verschiedenen Orten dezentral gedruckten Dokumenten, die
auch noch über räumlich verschiedene Versandsysteme verschickt werden, keinen Sinn. Bei mehreren beispielsweise zentral gedruckten Rechnungen (z.B. Jahresinkasso im Januar) ist es evtl. kostengünstiger, nur ein Dokument zu versenden.
Bei der Prüfung, ob Dokumente überhaupt zusammengefaßt werden dürfen, sind auch rechtliche
Belange zu betrachten, beispielsweise beim Versand von Dokumenten verschiedener Gesellschaften, z.B. einer Lebensversicherungsgesellschaft und der Krankenversicherungsgesellschaft.
All diese Parameter müssen dem Dienst bekannt sein, damit eine effektive Prüfung sowie Zusammenführung erfolgen kann.
•
Interface 3: Individuelle Schreiben / Text
•
Parameter
Õ Objekte, die beim Druck zu berücksichtigen sind (z.B. Partner, Vertrag, Konto)
Õ Output-Klasse (evtl. mit Druckeradresse oder –standort)
Õ Liste der Adressaten
Õ Zuzuführende Beilagen
Hier kann ein Objekt zur individuellen Textverarbeitung angefordert werden (Teilprozeß wird gestartet). Evtl. sind in dieser Textverarbeitung ebenfalls Textbausteine vorhanden. Das fertige Dokument wird an das technische „Print“-Interface übergeben.
© GDV 2001
63
Inhalt
Denkbar an dieser Stelle wäre das Einbinden von ganzen Textsystemen, z.B. Papyrus oder auch nur
Textverarbeitungen wie beispielsweise Microsoft Word oder Lotus WordPro.
•
Interface 4: Preview-Funktionen für die Interfaces 1 und 3
•
Parameter
Õ Interface IFC1 / IFC 3
Õ Output-Klasse (standardmäßig: Bildschirm)
Es besteht die Möglichkeit, die über Interface 1 und Interface 3 erstellten Dokumente vor dem
Versenden zu betrachten, um beispielsweise Korrekturen vorzunehmen. Dabei wird der Preview
standardmäßig auf dem Bildschirm dargestellt. Es besteht jedoch auch die Möglichkeit, das Dokument beispielsweise auf einen lokalen Drucker auszugeben.
•
Interface 5: Administration Dokumentenklasse
•
Parameter
Õ Dokumentenklasse
Das Anlegen und Bearbeiten von Dokumentenklassen wird über dieses Interface zur Verfügung
gestellt. Dabei wird im Rahmen der Ordnungsmäßigkeit eine Versionierung der bearbeiteten Dokumentenklassen durchgeführt, um zeitliche Änderungen an diesen Klassen zu dokumentieren.
Hierbei wird die Historisierungs- und Versionierungs-Eigenschaft von Business Objects genutzt.
•
Interface 6: Administration Textbausteine
•
Parameter
Õ Liste von Textbausteinen
Textbausteine können über dieses Interface angelegt, gepflegt und gelöscht werden. Dabei wird im
Rahmen der Ordnungsmäßigkeit eine Versionierung der bearbeiteten Textbausteine durchgeführt,
um zeitliche Änderungen an Texten zu dokumentieren. Hierbei wird die Historisierungs- und Versionierungs-Eigenschaft der Business Objects genutzt.
3.3.3. Benutzer / Kompetenzdienst
Der Kompetenzmanager hat als Ausgangspunkt die zwei Hauptkomponenten Berechtigung und Vollmacht.
Die Berechtigung, oder Benutzerverwaltung stellt fest, welche Benutzer lokal auf dem Server arbeiten
dürfen und welche remote einen physischen Zugang erhalten.
Vollmachten legen fest, welcher Benutzer auf welche Server-Ressource zugreifen darf. Zusätzlich
regeln Vollmachten die Art und Weise, wie der Benutzer zugreifen darf.
3.3.3.1. Berechtigung / Authentifikation
Anmeldung
Der Benutzer meldet sich mit seiner Benutzeridentifikation und seinem Passwort am System an. Die
Anmeldung des Benutzers wird im System gehalten, bis eine Abmeldung erfolgt.
64
© GDV 2001
Inhalt
Durch die Anmeldung am System erhält der Server die Identität des Clients. Der Benutzer erhält ein
Berechtigungsobjekt, daß die dem Benutzer zugeteilten Berechtigungen enthalten. Dem Anwendungsprogramm obliegt es nun, den jeweiligen Kontext zu setzen, indem die Berechtigungen gültig sind.
Somit ist durch die Anmeldung sowohl die Identifizierung am Server als auch die Definition der entsprechenden Berechtigungen am Client bekannt.
Zugang zu Programmen
Die Prüfung des Zugangs zu den Anwendungsprogrammen findet an der Benutzerschnittstelle statt. In
den meisten Anwendungen wird über die entsprechende View geregelt, welche Programme ein Benutzer ausführen darf.
Über das Berechtigungsobjekt wird festgelegt, welche Programme ein Benutzer ausführen darf. Dabei
gibt es folgende Stufen:
keine Berechtigung
Berechtigung für Anzeige
Berechtigung für Bearbeiten.
Die Darstellung an der Benutzeroberfläche erfolgt so, daß der Benutzer die zugelassenen Wahlmöglichkeiten an der Benutzeroberfläche aktiviert bzw. die nicht zugelassenen Möglichkeiten deaktiviert
angeboten bekommt. Die Umschaltung des Modus auf Bearbeiten bzw. Anzeigen erfolgt je nach Berechtigungsstufe im jeweiligen View.
Zugang zu Daten
Optional kann zusätzlich zum Zugang zu den Anwendungsprogrammen der Zugang zu Anwendungsdaten geschützt werden. Dieser Schutz ist individuell einzurichten. Als Prüfmerkmal können Attribute
der Anwendungsdatenbank verwendet werden. Bei Eingabe eines Ordnungsbegriffes wird während
des Zugriffs auf die Datenbank geprüft, welche Berechtigung ein Benutzer hat, um auf Anwendungsdaten zuzugreifen. Diese sind:
keine Berechtigung
Berechtigung zum Anzeigen
Berechtigung zum Bearbeiten
Diese Berechtigung „überschreibt“ den Zugang zu Programmen, da ein Zugriff auf Anwendungsdaten
höher zu bewerten ist. Beispiel: Der für einen Versicherungsvertrag zuständige Betreuer im Außendienst darf nur von ihm betreute Verträge bearbeiten.
© GDV 2001
65
Inhalt
Anwendung
BerechtigungsSystem
BerechtigungsObjekt
Anmeldung
beauftragt
initialisiert
stellt bereit
gibt zurück
Abbildung 32: Beispiel für den Aufbau des Berechtigungsobjekts
Um die Berechtigungsprüfung zu vervollständigen, setzt der Client nun den Berechtigungskontext in
dem die Berechtigung gültig ist und referenziert dabei auf das Berechtigungsobjekt. Der Server prüft
die Anfragen des Clients in dem er auf den Kontext und das Berechtigungsobjekt Bezug nimmt.
Client
Server
BerechtigungsObjekt
Aufruf Methode
prüft gegen
Stellt Ergebnis
bereit
Abbildung 33: Beispiel für die Berechtigungsprüfung auf dem Server
66
© GDV 2001
Inhalt
3.3.3.2. Vollmachten
Im Gegensatz zu Berechtigungen gehen Vollmachten einen Schritt weiter. Vollmachten regeln, welche
fachlichen Operationen ein Benutzer durchführen darf. Diese Prüfungen finden auf dem Server statt.
Solche Vollmachten werden in Form von Zugriffslisten abgelegt, die hauptsächlich die folgenden drei
Attribute enthalten:
Benutzer oder Benutzergruppen.
Rollen der Benutzer. Dies können eine oder mehrere Rollen sein, die typisch sind für die Aufgabenfunktion des Anwenders (z.B. Sachbearbeiter für Haftpflicht-Vertrag oder für HaftpflichtLeistung)
Vollmacht. Jeder Rolle wird eine entsprechende Vollmacht zugeteilt.
Das Hauptaugenmerk ist hierbei auf die Rolle gelegt, die ein Sachbearbeiter im Unternehmen hat.
Über eine Rolle wird festgelegt, welche Prozesse ein Sachbearbeiter ausführen darf und welche Vollmachten ihm innerhalb des Prozesses zugeordnet werden.
Die Zugriffslisten sind in der Lage festzulegen, welcher Kategorie von Benutzer Zugriff auf welche
Kategorie von Objekten gewährt wird.
Es wird geprüft, ob der Benutzer eine Methode ausführen darf. Im Unterschied zum Programmzugang
erhält er dazu im voraus keine Information. Die Informationen, welche die Vollmachtprüfung auslösen, sind während einer Operation anhand der entsprechend definierten Datenobjekte zu ermitteln.
Beispiel: Für den Sachbearbeiter in der Krankenversicherung gibt es die Vollmacht, Leistungen bis
2000 Euro auszuzahlen. Diese Vollmacht wird als Grundvollmacht beschrieben. Optional zur Grundvollmacht können Zusatzvollmachten je nach Versicherungsart, –zweig bzw. Anwendungsgebiet eingerichtet werden. Im obigen Beispiel ist eine Staffelung der Auszahlungsgrenze bis 10 000 Euro bzw.
ab 10 0000 Euro denkbar.
Die Zusatzvollmacht wird im Sonderfall neben der standardmäßigen Vollmachtenprüfung wirksam
und realisiert die Einhaltung des festgelegten Vollmachtumfangs. Prinzipiell ist jedes Datenattribut für
die Sondervollmachten geeignet.
3.3.3.3. Systeme mit eigener Berechtigungsprüfung
Als Systeme mit eigener Berechtigungsprüfung sind in diesem Zusammenhang z.B. CICS Transaction
Server, DB2 und Oracle8i als Datenbankserver oder andere Anwendungssysteme wie etwa ein
Text/Drucksystem zu sehen. Diese Aufzählung ist nicht unbedingt vollständig.
Es wird davon ausgegangen, daß diese Systeme eine Einrichtung zur Berechtigungsprüfung aufweisen, die den genannten Anforderungen genügen.
Der Zugang zu Systemen wird je System pauschal für die Benutzer einer oder mehrerer Anwendungen
definiert. Dies erfolgt mit einer Benutzeridentifikation für die ganze Benutzergruppe einer Anwendung
bzw. mehrerer Anwendungen. Die Benutzeridentifikation, die der Benutzergruppe für die Berechtigungsprüfung zugeordnet wurde, wird in allen Systemen verwendet. Diese Berechtigung wird im Berechtigungsobjekt gehalten und steht jedem System zur Verfügung.
© GDV 2001
67
Inhalt
3.3.3.4. Berechtigungsklassen
Eine Berechtigungsklasse mit den erforderlichen Methoden ist sowohl für den Client als auch für den
Server zu identifizieren.
Bei der Erzeugung der Berechtigungsobjekte, in denen die Berechtigungsprofile vorgehalten werden,
muß auf die extern gespeicherten Daten zu den entsprechenden Profilen zugegriffen werden. Der variable Umfang der Profile muß abgedeckt werden können.
Zusätzlich müssen jederzeit neu zu schützende Ressourcentypen in das Berechtigungsprofil aufgenommen werden können. Es ist letztendlich festzulegen, welche Prüfungen auf Client- bzw. Serverseite ablaufen werden. Dabei wird folgende Verteilung vorgesehen:
Berechtigung auf Client
Vollmachten auf Server
Subsysteme auf Server
Berechtigungsobjekte werden bei der Anmeldung des Benutzers erzeugt. Ihnen wird eine Lebensdauer
und die entsprechenden Entstehungs- und Endezeitpunkte zugeordnet.
Attributabhängige Berechtigungen, die über fachliche Kombinationsprüfungen geprüft werden, müssen über die jeweiligen EBOs abgebildet werden, da ein Berechtigungsdienst kein Wissen über die
fachliche Struktur des BOs hat. Beispielsweise wird in einem EBO erkannt, daß für einen bestimmten
Prozeß eine Berechtigung der Rolle Gruppenleiter benötigt wird. Das EBO erkennt die dazu notwendigen Attributkombinationen und ermittelt daraus die entsprechende Rolle. Mit der Rolle prüft das
EBO gegen das Berechtigungsobjekt, ob dem angemeldeten Sachbearbeiter die entsprechende Rolle
zugewiesen wird.
3.3.3.5. Interfaces
Folgende Interfaces sind denkbar:
Berechtigungsobjekt für einen User
Für einen Sachbearbeiter wird ein komplettes Berechtigungsobjekt instanziiert, gegen daß sich
prüfen läßt, welche Berechtigungen und Vollmachten ein einzelner Sachbearbeiter hat.
Prüfung auf Berechtigung
Es wird gegen das Berechtigungsobjekt geprüft, ob ein Sachbearbeiter Zugänge zu bestimmten
EBOs und PBOs hat.
Prüfung einer Rolle
Die aus einer fachlichen Prüfung hervorgehende Rolle wird gegen das Berechtigungsobjekt geprüft, der Rückgabewert ist entweder ja oder nein.
Weitere Schnittstellen sind denkbar, wenn ein VU über das Rollenkonzept die gesamte Aufbauorganisation des Unternehmens abbilden will. Dann sind Interfaces denkbar, die z.B. die Bearbeitung eines
Prozesses an eine höherwertige Rolle delegieren.
68
© GDV 2001
Inhalt
3.3.4. Ausnahme und Fehlerbehandlung
3.3.4.1. Definition:
Die Ausnahme- und Fehlerbehandlung stellt ein Verfahren dar, das teilweise auf der Ebene der Business Objects (BO) und teilweise auf der Ebene der Prozeßsteuerung abgehandelt wird. Zu diesem
Zweck steht den BOs ein eigener Fehlerdienst zur Verfügung, der weitgehend unabhängig von den
BOs konfiguriert werden kann.
3.3.4.2. Beschreibung
Jedes BO, das innerhalb eines Systems angelegt wird, stellt bestimmte Anforderungen an seine Umgebung, damit es existieren und seine Methoden ausführen kann. Sind diese Bedingungen nicht erfüllt,
werden diese entweder nachträglich hergestellt oder das entsprechende Objekt wird aus dem System
entfernt. Ferner kann die Situation auftreten, daß ein BO bedingt durch einen internen Fehler seine
Verarbeitung abbricht bzw. von Seiten des Systems eliminiert wird.
In allen beschriebenen Situationen ist es erforderlich, den Fehler selbst zu dokumentieren und – soweit
möglich – die Information an eine zuständige Stelle weiterzuleiten. Zusätzliche Vorkehrungen sind zu
treffen, wenn die Verarbeitung nicht ab- sondern nur unterbrochen wird. Hier muß das BO, das in die
Fehlersituation gelaufen ist, mit Unterstützung eines Dienstes zur Fehlerbehandlung die Situation soweit klären, daß die normale Verarbeitung fortgesetzt werden kann.
Beispiel
In einem Versicherungsunternehmen ist eine Zahlung über eine Bankverbindung eingegangen, die einem Partner zugeordnet
werden kann. Da zur Zeit keine Forderungen gegenüber diesem Partner bestehen, und da der Zahlungsbeleg keine weiteren
Hinweise enthält, führt die Zahlungsverarbeitung zu einem fachlichen Fehler. Das Process Business Object, das für die
Zahlungsverarbeitung verantwortlich ist, ermittelt einen Fehlerdienst, der für die Verarbeitung solcher Vorgänge verantwortlich ist. Im Rahmen dieser Fehlerbehandlung wird über ein maschinelles Zuordnungsverfahren ein Sachbearbeiter
eingeschaltet, der die näheren Umstände analysiert und dabei feststellt, dass in den nächsten Tagen eine Sollstellung aufgebaut wird, die dem überwiesenen Betrag entspricht. Er legt einen Termin fest zu dem die Zahlung verarbeitet werden kann.
Zum vorgegebenen Termin wird das Process Business Object zur Zahlungsverarbeitung wieder aktiviert und arbeitet die
vorliegende Zahlung entsprechend seiner normalen Verarbeitungslogik ab.
Zur Abhandlung des umrissenen Verfahrens, wird eine Struktur aufgebaut, die im wesentlichen folgende Komponenten enthält.
Eine Fehler_Kontext Klasse, die es einem BO ermöglicht, einen Fehler in standardisierter Form
darzustellen.
Einen Dienst zur Ausnahme und Fehlerbehandlung, der es ermöglicht einen Ausnahmefall ggf.
auch über mehrere Zwischenschritte an eine Instanz weiter zu leiten, welche die nötigen Kompetenzen zur Fehlerbehandlung besitzt
Ein Rollenkonzept, das es ermöglicht, die Ausgabe und Annahme von Aufträgen zur Fehlerbehandlung zu steuern.
© GDV 2001
69
Inhalt
Fehler_Kontext Klasse
Die Kontext Klasse erhält eine Struktur, die es erlaubt den Fehler und die Aufruf-Hierarchie in der der
Fehler entstanden ist, darzustellen. Der Fehlerkontext wird beim Aufruf des Fehlerdienstes und bei der
Ausgabe von Exceptions mit übergeben.
Timestamp
Fehler_Art
Fehler_Object:
TypBezeichnung, ObjectId ( des Objektes das den Fehler
ausgibt )
Fehler_Text
Fehler_Daten
Liste von Objekten mit TypBezeichnung und ObjectId
(weitere Objekte die den Kontext beschreiben )
Fehler_Sequenz
Liste von Fehlerkontexten
( d.h. Fehlerkontexte von tieferen Ebenen in der
Aufruf-Hierarchie )
Wenn z.B. auf einer unteren Ebene eine Exception geworfen und diese Exception auf einer höheren
Ebene abgefangen wird, legt das BO der höheren Ebene ein eigenes Fehlerkontext Objekt an. Dabei
werden die Attribute 1 – 5 mit den eigenen Daten versorgt, während die Fehler_Sequenz mit den
Werten aus der abgefangenen Exception gefüllt wird. Dabei wird der Kontext der abgefangenen Exception selbst an den Anfang dieser Liste gestellt. Durch diese Vorgehensweise kann die gesamte Aufruf-Hierarchie dokumentiert werden, sofern die entsprechenden Exceptions auf jeder Ebene abgefangen und mit den relevanten Informationen angereichert werden. Ein Fehlerkontext kann von allen BOs
angelegt werden.
Der Dienst zur Ausnahmen- und Fehlerbehandlung
Wenn ein BO eine kritische Situation nicht auflösen kann, besteht die Möglichkeit, daß dieses eine
Exception wirft und dabei den Fehler_Kontext an das aufrufende Object weitergibt, ( -> Adressat unbestimmt da ein BO normalerweise nicht weiß von wem es aufgerufen wurde, Übergabe der Kontrolle
an aufrufendes Objekt ) oder daß es sich mit dem bereits beschriebenen Fehler_Kontext an ein spezielles Interface seiner Prozeßsteuerung wendet. Die Prozeßsteuerung überprüft an Hand der Rolle des
aufrufenden BOs ( s.u. ) , ob letzteres dafür zuständig ist, eine Fehlerbehandlung zu veranlassen. Diese
Aufgabe wird in Zusammenarbeit mit dem Berechtigungssystem gelöst. In Abhängigkeit vom Ergebnis wird eine der beiden folgenden Vorgehensweisen durchgeführt.
1. Das aufrufende BO ist in seiner Umgebung dafür zuständig, eine Fehlerbearbeitung zu
veranlassen. Dann wird der entsprechende Fehler_Kontext direkt an einen Fehlerdienst
übergeben.
2. Das aufrufende BO hat keine eigene Zuständigkeit zur Fehlerbehandlung. Die Prozeßsteuerung weist die Fehlerbehandlung ab. Das BO erhält eine entsprechende Rückmeldung und
wirft eine Exception. Auf der Ebene des aufrufenden Objektes läuft dann die gleiche Logik
ab wie bei dem gerade betrachteten BO.
Der Dienst zur Fehlerbehandlung wird entsprechend dem Pattern Chain of Responsibility und Composite organisiert ( Vgl.[Gamma96]). Dies bedeutet, daß sich ein BO mit dem Fehler_Kontext an einen
70
© GDV 2001
Inhalt
spezialisierten Fehlerdienst wenden kann, der das Problem unter Umständen ohne Hilfe eines Sachbearbeiters löst. Falls dieser Versuch fehlschlägt wird der Fehler solange an andere, allgemeinere Dienste weitergereicht bis das Problem gelöst ist. Es muß sichergestellt sein, daß ein derartiger Fehler nach
einer endlichen Zahl von Schritten bei einer zuständigen Instanz („Mensch als letzte Instanz“) ankommt, die eine wie auch immer geartete Lösung findet.
Prozeßobjekt
Nacnfolger
Fehler_Behandlung
BehandelnFehler()
Fehler_Behandlung_1
Fehler_Behandlung_2
BehandelnFehler()
BehandelnFehler()
Abbildung 34: Klassenmodell für den Fehlerdienst
Verarbeitung nach der Ausnahme und Fehlerbehandlung
Nach Durchführung der Fehlerbehandlung muß die normale Verarbeitung wieder aufgenommen werden. Dabei sind unterschiedliche Vorgehensweisen denkbar:
1. Ein Prozeßobjekt fragt bei der Prozeßsteuerung den Stand der Fehlerbearbeitung ab und setzt
nach erfolgreichem Abschluß dieser Verarbeitung die normale Verarbeitung fort.
2. Der unterbrochene Prozeß bleibt so lange inaktiv, bis er von der Prozeßsteuerung wieder angestoßen wird.
Falls eine eindeutige Entscheidung zwischen diesen Alternativen nicht möglich ist, muß auch an dieser
Stelle über ein entsprechendes Rollenobjekt festgelegt werden, welche Funktionen ein Business Object
bei der Wiederaufnahme der Verarbeitung zu übernehmen hat.
Rollenkonzept
Bei der Ausgabe von Fehlern stellt sich die Frage an welcher Stelle ein Aufruf des Fehlerdienstes erfolgen soll und wer für die Bearbeitung eines Fehlers zuständig ist. Weil ein BO nicht weiß, aus welchem Kontext heraus es aufgerufen wird, kann es auch nicht wissen, ob es über die nötigen Informationen verfügt, eine Fehlerbehandlung auszuführen. Es kann sein, daß eine Lösungsstrategie, die mit
den Daten des Objektes arbeitet, von dem es aufgerufen wurde, viel erfolgversprechender ist. Es ist in
© GDV 2001
71
Inhalt
diesem Falle also sinnvoller wenn das BO eine kritische Situation per Exception an das aufrufende
Objekt meldet und diesem die Fehlerbehandlung überläßt.
Nach Klärung dieser ersten Frage ist wiederum über das Berechtigungs- und Zuständigkeitssystem ein
Zuständiger für die Bearbeitung zu ermitteln. Dazu muß die Prozeßsteuerung eine Zuordnung von
Fehler_Art ( ggf. mit weiteren Parametern ) und den vorhandenen Fehlerdiensten vornehmen. Der
aufgerufene Fehlerdienst steht selbst auch wieder vor der Aufgabe den Fehler an eine zuständige Instanz, z.B. einen Sachbearbeiter, weiterzuleiten.
Die beschriebenen Probleme können über ein Rollenkonzept gelöst werden. Nach diesem Konzept
werden Klassen, einzelnen Business Objects oder bestimmten Sachbearbeitern spezielle Zuständigkeiten übertragen. Die Zuordnung dieser Rollen kann die Prozeßsteuerung und anschließend der Fehlerdienst in Zusammenarbeit mit dem Berechtigungs- und Zuständigskeits-Dienst vornehmen. Das
Business Object selbst erfährt nichts über diese Zuordnung.
Durch die Vergabe entsprechender Rollen kann gesteuert werden, welches Business Objects welche
Fehlerbearbeitung anstoßen, ausführen und weiterleiten dürfen. Letztendlich werden auch entsprechende Zuständigkeiten von Sachbearbeitern auf diesem Wege geregelt.
Da die Rollenvergabe zur Fehlerbehandlung über das Berechtigungs- und Zuständigkeitssystem geregelt wird, ohne daß die BOs direkt einbezogen werden, stellt dies ein flexibles Verfahren dar, um BOs
aus Kaufkomponenten in die (VAA-) Infrastruktur des IT-Systems eines VUs zu integrieren.
Spezifikation von Ausnahme- und Fehlersituationen
Vor dem Hintergrund des oben beschriebenen Verfahrens zur Fehlerbehandlung kann nun auch beschrieben werden, was beim fachlichen Entwurf eines Business Objects im Hinblick auf die Fehlerbehandlung zu unternehmen ist. Im wesentlichen muß nur beschrieben werden wie das Fehler_Kontext
Objekt zu füllen ist. Die weitere Handhabung des Fehlerkontextes wird durch den Fehlerdienst geregelt.
Bei der Anlage des Fehlerkontextes ist ein Teil der anzugebenden Daten per Definition vorgegeben:
Timestamp
Fehler_Object: TypBezeichnung, ObjectId ( des Objektes das den Fehler ausgibt )
Dagegen müssen die folgende Attribute beim Design gesondert festgelegt werden
Fehler_Art
Fehler_Text
Fehler_Daten
72
© GDV 2001
Inhalt
Ablauf bei einem Fehlerfall
Prozess_
Steuerung
Zahlung_Bearbeitung
(PBO)
Zahlung
(EBO)
Beitrags_Konto
(EBO)
Fehler_Kontext
(EBO)
Ausnahme_
FehlerBehandlung
(PBO)
Zahlung_Bearbeitung()
Ermitteln_Bankverbindung()
Buchen( Zahlung )
Zuordnen_Sollst ( Zahlung )
Fehler_Kontext()
Exception(Fehler_Kontext )
Fehler_Kontext_Ergänzen()
Exception(Fehler_Kontext)
Ausnahme_Fehler_Behandlung ( Fehler_Kontext) = 2. Alternative
Ausnahme_Fehler_Behandlung ( Fehler_Kontext) = 1. Alternative
Abbildung 35: Sequenzdiagramm: Beispiel Fehlerfall
3.3.5. Postkorb
Der Postkorb erlaubt die Verwaltung und Visualisierung der Arbeitsaufträge der Sachbearbeiter. Ein
Sachbearbeiter sieht sofort, welche Arbeitsaufträge für ihn zur Abarbeitung bereit stehen, er kann sie
sich nach definierbaren Kriterien auflisten lassen.
Aus dem Postkorb heraus können die zur Bearbeitung eines Auftrags notwendigen Bestandssysteme
direkt aufgerufen werden. Die in dem Auftrag gespeicherten, verarbeitungsrelevanten Daten werden
dem Bestandssystem dabei direkt übergeben. Mit Aufruf eines Bestandssystems geht die Kontrolle des
Geschäftsvorgangs an dieses über.
3.3.5.1. Beschreibung des Postkorbs
Ein Postkorb ist ein Sammelordner für Aufträge, welche einem bestimmten Bearbeiter, einer Gruppe
von Bearbeitern oder einem System zugeordnet sind.
Es gibt folgende Arten von Postkörben:
•
Benutzerpostkörbe oder Userpostkörbe: Die Postkörbe eines einzelnen Benutzers.
•
Gruppenpostkörbe: Die Sammelpostkörbe von Gruppen
•
Abteilungspostkörbe: Die Sammelpostkörbe von Abteilungen
•
Systempostkörbe: In diesen speziellen Postkörben werden die Aufträge für Systeme gesammelt;
sie können nur von Systemen eingesehen werden. Systempostkörbe sind an der Oberfläche nicht
sichtbar
© GDV 2001
73
Inhalt
Im Postkorbsystem (PKS) ist der gesamte Arbeitsvorrat für Sachbearbeiter und Bestandsführungssysteme in Form von Aufträgen hinterlegt. Aufträge im Postkorb sind noch nicht beendet. Im Postkorb
wird dem Sachbearbeiter in unterschiedlichen Sichten der Arbeitsvorrat aufgelistet. Diese Aufträge
setzen sich aus beschreibenden Attributen und Verknüpfungen zu Eingangsdokumenten (digitalisierte
Post) zusammen und können in unterschiedliche Zustände (Status) kategorisiert werden. Aus diesem
aufgelisteten Arbeitsvorrat wird durch Auswahl eines Auftrags in die entsprechende Anwendung (z.B.
Bestand) verzweigt. Im Postkorb ist immer der aktuelle Bearbeitungsstand eines Auftrags erkennbar
vgl. 3.3.1.7 – aktueller Status der Vorgangsakte). Neben den reinen Auftragsdaten können in einer
detaillierten Ansicht auch alle zum Auftrag zugehörigen Dokumente und weiterführende Verweise
angesehen werden. Ein Auftrag im PK verweist auf beliebig viele Dokumente im Archiv. Diese sind
zur Bearbeitung des Auftrags relevant.
Eng verwandt zum Postkorbsystem ist das Geschichtsbuch (Vorgangsakte im Endstadium). Im Geschichtsbuchsystem (GB) werden alle beendeten Aufträge aus dem PKS abgelegt. Ein GB-Auftrag
verweist ebenfalls auf die für ihn relevanten Dokumente im Archiv. Das Geschichtsbuch listet alle
Informationen zu abgeschlossenen Aufträgen auf. Beim Abschluß eines Auftrags durch eine Anwendung werden entsprechend alle Daten zu dem Auftrag aus dem Postkorb in das Geschichtsbuch übertragen. Über eine Suchfunktion können die Daten im Geschichtsbuch jederzeit nach den Ordnungsbegriffen recherchiert werden. Weiterhin können von den Bestandssystemen direkt Eintragungen im
Geschichtsbuch vorgenommen werden, um durchgeführte und beendete Arbeitsaufträge zu dokumentieren.
3.3.5.2. Funktionalität des Postkorbs
Ein Postkorb enthält Aufträge als Arbeitsaufträge für Sachbearbeiter, die im Postkorb- / Geschichtsbuchsystem verschiedene Zustände einnehmen können.
Aufträge werden meist durch ein Ereignis ausgelöst (Anschreiben, Ergebnis eines Batchlaufes, etc.).
Denkbar ist ein Dokumentenmanagementsystem, daß eingehende Post scannt und als „Images“ ins
Archiv einstellt. Daraus wird dann ein Auftrag erzeugt, der im Postkorb visualisiert wird.
Die so im Postkorbsystem erzeugten Aufträge werden der Bearbeitung durch den Sachbearbeiter zugeführt. Beim Anlegen der Aufträge im Postkorb erhalten sie ihre Auftragsnummer. Die Versicherungsscheinnummer des Auftrags oder ein artverwandter Ordnungsbegriff (z.B. Partner-Nr. oder SchadenNr), sofern bekannt, wird bei Anlage des Auftrags im Postkorb an das zuständige Bestandssystem
übergeben. Durch diese Information können, vor dem eigentlichen Beginn der Bearbeitung, im Bestandssystem Funktionalitäten wie z.B. Inkassostop aktiv werden.
Die Reihenfolge der Abarbeitung dieser Aufträge durch Sachbearbeiter kann nicht beeinflusst werden.
Aufträge können anhand der zu ihrer Abarbeitung notwendigen Tätigkeiten zu Auftragsarten gruppiert
werden, z.B. ”Neuantrag” oder ”Adressänderung”. Jedes Bestandssystem definiert im Prinzip seine
Auftragsarten. Eine Standardisierung von Auftragsarten sollte jedoch angestrebt werden. Letzteres
erhöht die Handhabbarkeit bei den Sachbearbeitern.
Darüber hinaus sollte es möglich sein, nicht nur Aufträge im Postkorb zu visualisieren, sondern auch
eingehende Post oder Emails. Denkbar wäre zusätzlich, im Postkorb Informationen zu hinterlegen, die
sich der entsprechende Sachbearbeiter abholen kann. Dies könnten neue Tarifregeln, gesetzliche Änderungen oder Änderungen in der System- oder Produktdokumentation sein.
74
© GDV 2001
Inhalt
3.3.5.3. Termin und Wiedervorlage
Über den Postkorb muss es möglich sein, bestimmten Aufträgen bestimmte Terminen zuzuordnen. So
muss es möglich sein, einen Auftrag auf Wiedervorlage zu setzen. Innerhalb des Postkorbs wird das
Zustelldatum eines bestimmten Auftrags zeitlich nach hinten gesetzt um auf noch fehlende Informationen zur Bearbeitung eines Auftrags zu warten. Zum Beispiel setzt ein Sachbearbeiter eines Kranken-Neuantrags den Auftrag auf Wiedervorlage um auf bestimmte Risikodaten zu warten.
Dieser Auftrag sollte aus dem Postkorb verschwinden um die Übersichtlichkeit der tatsächlich zu bearbeitenden Aufträge zu gewährleisten. Er wird mit einem entsprechenden (Bearbeitungs-) Statusattribut versehen werden. Zum gesetzten Wiedervorlagedatum erscheint dieser dann wieder im Postkorb.
Denkbar wäre hier, den Sachbearbeiter direkt auf die Wiedervorlage hinzuweisen. Dieser hat u.U.
hunderte von Aufträgen in seinem Postkorb und kann über akustische oder visuelle Informationen auf
die Wiedervorlage hingewiesen werden.
Eine weitere Einsatzmöglichkeit des Postkorbs könnte die Terminverwaltung des einzelnen Sachbearbeiters sein. So ist es denkbar wichtige Termine des Betriebs (Jahresabschluß, Stichtage, Altersumstufungen) im Postkorb bekanntzugeben. Desweiteren können persönliche Termine des Sachbearbeiters
(Gruppen-, Abteilungsbesprechungen, Schulungen, Urlaub) über den Postkorb verwaltet werden.
3.3.5.4. Schnittstellen
Einen kurzen Überblick über die Schnittstellen eines Postkorbsystems und die Einbindung in einen
Gesamtkontext gibt die folgende Darstellung:
Postkorb
Komm.
Fachl.
Komponente
Komm. Geschichtsbuch
verweist auf
verweist auf
erzeugt
DokumentenManagement
stellt
Archiv
Abbildung 36: Überblick über die Schnittstellen eines Postkorbsystems
3.3.5.5. Beispielablauf
Dieser Abschnitt beschreibt den grundlegenden, typischen Arbeitsablauf bei der Arbeit mit einem
Postkorbsystem aus der Sicht eines Sachbearbeiters:
© GDV 2001
75
Inhalt
Ein eingehendes Kundenschreiben wird in der Poststelle geöffnet und eingescannt. Die entstehenden
„Images“ werden in das Archiv eingestellt, und es wird im Postkorb des zuständigen Sachbearbeiters
ein Auftrag zur Bearbeitung angelegt, welcher auf dieses Dokument verweist.
Der Sachbearbeiter öffnet das Postkorbsystem und schaut in seinen Postkorb; dort kann er sich die von
ihm zu erledigenden Aufträge nach gewissen Kriterien anzeigen lassen.
Er wählt einen Auftrag aus und kann die relevanten Daten des Auftrags lesen und die dem Auftrag
zugeordneten Dokumente anzeigen lassen.
Ein Doppelklick auf den Auftrag öffnet die Fachkomponente, in welchem dieser Auftrag abgearbeitet
wird. Das Bestandssystem kann während der Arbeit Daten im Geschichtsbuch (Vorgangsspeicher)
einstellen oder Schriftstücke an den Kunden erzeugen (siehe 3.3.2), welche auch im Archiv abgelegt
werden.
Es besteht die Möglichkeit, dass der Auftrag nicht komplett von dem Sachbearbeiter abgearbeitet werden kann; er kann ihn entweder für eine spätere Bearbeitung auf Wiedervorlage legen oder ihn – falls
seine Vollmacht zum Abschluss des Vorgangs nicht ausreicht – in den Postkorb eines Sachbearbeiters
mit höherer Vollmachtsstufe weiterleiten (siehe 3.3.3).
Wenn ein Sachbearbeiter einen Auftrag erfolgreich abarbeiten konnte, dann wird der Auftrag beendet
und ins Geschichtsbuch übertragen. Dort ist er jederzeit über die Suche nach Ordnungsbegriffen wieder anzeigbar; er wurde während seiner Bearbeitungen um Informationen aus dem bearbeitenden Bestandssystem und um Verweise auf etwaige bei der Bearbeitung entstandene Druckstücke ergänzt.
3.3.6. Historisierung
Die „Historisierung“ stellt ein Verfahren bereit, um auf den Zustand eines Bos zu einem bestimmten
Zeitpunkt zugreifen zu können.
3.3.6.1. Fachlicher Aspekt
Wenn man von Historisierung spricht meint man im Sinne des technischen Referenzmodells die Historisierung von EBOs, da die PBO nach ihrer Durchführung nicht mehr modifiziert werden, sondern
lediglich in Form eines Journal auf einem anderem Medium dokumentiert werden
Im Zusammenhang mit Historisierung unterscheiden versicherungstechnische Anwendungen grundsätzlich zwischen zwei Typen von EBOs:
solche, die einmal erstellt werden und den Zustand aktuell oder storniert haben, d.h. diese
EBOs haben den Charakter eines Buchungssatzes. Beispiel aus der LV hierfür ist das Technikkonto
solche, die sich über die Zeitachse verändern, d.h. aufgrund einzelner Geschäftsvorfälle ändern sich einzelne Werte von Attributen.
Im folgenden wird der Typ 2 (historisierbares EBO) näher betrachtet.
Bei diesem Typ ist zu berücksichtigen, daß Historisierung ein zweidimensionales Gebilde ist. Man
unterscheidet die Bearbeitungsterminhistorie (BAT), d.h. welchen Zustand hatte das BO zu dem
Termin, als dem der Prozess (Geschäftsvorfall) das BO persistent abgelegt hat. Die zweite Dimension
ist die Wirksamkeitshistorie (WIT), d.h. unabhängig davon, wann der Vorgang durchgeführt wurde,
kann der zum Betrachtungszeitraum korrekte Zustand des BOs bereitgestellt werden.
76
© GDV 2001
Inhalt
Beispiel
BAT
V4
1.6.
V3
1.5.
1.4.
V2
1.3.
V1
1.2.
WIT
1.3.
1.4.
1.5.
1.6.
1.7.
1.8.
1.9.
Das obige Beispiel stellt die Historie für ein BO (z.B. Vertrag) dar. Es ist folgendermaßen zu interpretieren:
Am 1.3. erzeugt der Sachbearbeiter (SB) das BO mit dem Wirksamkeitsbeginn ab 1.3. (Version 1)
Ab dem 1.6. soll eine Änderung am BO wirksam werden, die der SB am 1.4. durchführt (Version 2)
Am 1.5. äußert der Kunde den Wunsch, zum ersten 1.4. seinen Vertrag zu ändern, d.h. es handelt sich um eine
rückwirkende Änderung (Version 3) Å(was geschieht mit den Änderungen der Version 2)
Am 1.6. läuft ein Dynamik-Batch ( Version 4)
Betrachte man das BO zum Zeitpunkt 1.7. bezügl. seiner Wirksamkeit, so sieht man die Versionen 1,3 und 4; d.h. die
Version 2 existiert nicht.
Betrachte man das BO zum Zeitpunkt 1.7. bezügl. seiner Bearbeitungshistorie, so sieht man die Versionen 1, 2 ,3 und 4.
Im Zusammenhang mit der Wirksamkeit ist zusätzlich noch zu überlegen, ob es im „Leben“ des BOs
auch Lücken geben kann. Beispiel: ein Tarif war vom 1.1. – 1.8. eingeschlossen und vom 1.10.-31.12.
In diesem Fall benötigt man zusätzlich ein Wirksamkeitsende.
Aus diesen Überlegungen folgt, dass zum Auffinden eines BOs neben dem fachlichen Schlüssel auch
der Betrachtungszeitpunkt angegeben werden muss, um den korrekten Zustand des BOs zu konstruieren
Zu nutzende Patterns:
•
“Temporal Property” und “Temporal Association” [Fowl97], [PLoP2000]
Im ersten Pattern geht es darum, Attribute eines BO – sofern die Inhalte der Attribute von der Zeit
abhängen – durch einen Set von Ausprägungen dieses Attributes zu ersetzen. Jeder Ausprägung
wird ein Gültigkeitszeitraum zugeordnet
© GDV 2001
77
Inhalt
Beispiel: EBO Vertrag
Vertrag
Der Beitrag ist Abhängig von der gesamten
Vertragskonstellation, daher werden alle jemals
gültigen Zustände des Attributes BEITRAG mit
einem „Zeitstempel“ versehen und in einem
separaten Set gespeichert
Beginn :: Date
Beitrag :: Euro
Vertrag
Beginn :: Date
1
0 .. n
Beitrag
1
1
Gültigkeit
Anfang
Ende
Euro
Abbildung 37: Beispiel Temporal Property
•
Pattern: Snapshot [Fowl97], [PLoP2000]
Das zweite Pattern ist dem ersten sehr ähnlich. Allerdings geht es in diesem Pattern um die Gültigkeit
von (m:n)-Beziehungen zwischen unterschiedlichen BOs. Auch hier wird die Beziehung mit einem
Gültigkeitszeitraum versehen.
78
© GDV 2001
Inhalt
Beispiel:
Kunde
1
0 .. n
Rolle
0 .. n
1
Vertrag
Rolle
0 .. n
1
Vertrag
Erweitert um den Gültigkeitszeitraum
Kunde
1
0 .. n
1
1
Gültigkeit
Anfang
Ende
Abbildung 38: Beispiel zu Snapshot
Die obigen Pattern lösen zwar das Problem sowohl Attribute als auch Beziehung eindimensional zeitraumbezogen zu speichern, allerdings wird der „Zugriff“ auf die Informationen aus Sicht eines Clients, der das BO nutzen will, komplexer, d.h. um den Zustand des BOs zu einem bestimmten Zeitpunkt herzustellen, muss der Client durch das Geflecht navigieren.
Idee des Snapshot-Patterns ist es, dem Client ein Interface bereitzustellen, das in der Lage ist für einen
bestimmten Zeitpunkt die zugehörigen Attributwerte und Beziehungen bereitzustellen. Die Information wird durch eine Navigation hinter der Schnittstelle dynamisch bereitgestellt.
3.3.6.2. Ein möglicher konkretes Lösungsansatz
Betrachtet man EBOs im Versicherungsumfeld, so ist die Beziehung innerhalb des EBOs in der Regel
hierarchisch, d.h. der fachliche Schlüssel eines Dependent Object in der Hierarchie setzt sich immer
aus den Schlüsseln der Parents und dem eigentlichen Schlüssel des Objektes zusammen (z.B. ein KVVertrag enthält 1:n versicherte Personen, die wiederum 1:n Tarife haben).
Die Beziehungen zwischen den Objekten ändert sich über den gesamten Lebenszyklus des Vertrages
nicht.
Beispiel:
© GDV 2001
79
Inhalt
Innerhalb des KV-Vertrages ist ein bestimmter Tarif abgeschlossen worden. Es gibt lediglich Zeitpunkte, zu denen der Tarif noch nicht aktiv war (er wurde es nachträglich abgeschlossen) bzw. Zeitpunkte, in denen der Tarif nicht mehr aktiv war (er wurde storniert).
Idee des Lösungsansatzes
Alle Attribute, die über den gesamten Lebenszyklus des EBOs unverändert bleiben, werden zusammen
mit dem fachlichen Schlüssel in einer gemeinsamen Klasse gespeichert. (KEY-Object)
Alle Attribute, die lediglich vom Bearbeitungszeitpunkt abhängen, werden zusammengefasst, um den
Bearbeitungstermin ergänzt und als BAT-Object gespeichert .
Attribute, die sowohl vom Bearbeitungstermin als auch vom Wirksamkeitstermin abhängen, werden
im WIT-Object gespeichert. Das KEY-Object besitzt einen Set, in dem alle BAT-Objects zu dem
KEY-Object enthalten sind und ein Set mit allen WIT-Objects. Dies entspricht von der Grundidee dem
Pattern 1; allerdings sind in dem Set nicht nur die Werte eines einzelnen Attributes enthalten, sondern
es werden aus Effizienzgründen alle Attributwerte zu einem Bezugspunkt in einem gemeinsamen Objekt zusammengefasst. Darüber hinaus müssen die Methoden im WIT-Set beide Zeitdimensionen berücksichtigen.
Weiterhin gibt es zu jeder Ausprägung des obersten KEY-Objects z.B. KV-Vertrag ein Logbuch, in
dem jegliche Änderungen an dem BO festgehalten werden, d.h. wer war Auslöser der Änderung (Prozess), damit unter Umständen bei rückwirkenden Änderungen der Prozess automatisch wieder durchgeführt werden kann, wann wurde der Prozess durchgeführt und welche neuen WIT- und BATObjects wurden bei der Verarbeitung des Prozesses in die Sets eingefügt. (Idee des ChangeLog).
Den Nutzern des EBOs werden Interfaces bereitgestellt, die von der internen Navigation frei sind und
lediglich zusätzlich zum fachlichen Schlüssel den Bezugspunkt in Form von Wirksamkeits- und Bearbeitungsdatum als Input benötigen. (vgl. Pattern 2).
Unter dem Gesichtspunkt der Komponentenbildung müssen die Schnittstellen der Komponenten frei
von jeglicher Navigationslogik in der Historie sein, um von den – von Komponente zu Komponente
unterschiedlichen Verfahren – unabhängig zu sein.
LOGBUCH
VertragKey
VertragBAT
VertragWIT
TarifTarifKEY
KEY
TarifTarifBAT
BAT
TarifWIT
TarifWIT
Abbildung 39: interne Struktur für die Historisierung
80
© GDV 2001
Inhalt
3.3.7. Suchdienst
Der Suchdienst bedient sich des Objektgeflechts, auch komponenten-übergreifend. Das Ergebnis des
Suchdienstes ist das „Bekannt sein“ des gesuchten Objektes einschließlich der referenzierten Objekte („Objektgeflecht“). Es können also im nächsten Schritt Attributinhalte aus referenzierten Objekten mittels „...bereitstellen“ angezeigt werden.
Der Suchdienst erhält als Input Attributinhalte des gesuchten Objektes (bzw. referenzierter Objekte).
Er liefert als Output das gesuchte Objekt (bzw. die gesuchten Objekte), d. h. eine eindeutige Referenz
auf das Objekt.
Der Suchdienst muß so parametrisierbar sein, daß er nicht nur auf Gleichheit, sondern auch auf hinreichende Ähnlichkeit suchen kann (Lautähnlichkeit, x-prozentige Übereinstimmung in n von m
Attributen). Ihm ist also eine Anforderungsart (oder „Suchart“) mitzugeben.
Speziell im Bereich Partner ersetzt der Suchdienst die Dublettenprüfung, indem man auf hinreichende
Ähnlichkeit sucht. Um eine Suchart „mit Dublettenkandidaten“ verwenden zu können, muß der Begriff des Dublettenkandidaten (ggf. unternehmensspezifisch) definiert sein.
Allgemeine Definition des Begriffs „Dublettenkandidat“:
Ein Objekt ist Dublettenkandidat zu einem anderen Objekt, wenn für eine festzulegende Anzahl bestimmter Attributinhalte (und/oder Referenzen auf andere Objekte) eine festzulegende Vergleichbarkeit vorliegt.
Vergleichbarkeit bedeutet die Erfüllung ein oder mehrerer der folgenden Kriterien:
- Lautähnlichkeit
Beispiel: Meier und Mayer
- Gleichheit
- x-prozentige Übereinstimmung
Beispiel: Engelen-Kefer und Engelen-Kiefer: Übereinstimmung > 90%
- beschränkte Abweichung
Beispiel: 01.10.1964 und 19.10.1964: Abweichung < 1 Monat
3.3.8. Event-Manager
Der Event-Manager muß in der Lage sein, aus dem Ergebnis eines Service (z.B. bei Partner: Änderung
des Familienstandes) den Auslöser einer notwendigen Folgeaktivität zu generieren (z. B. die Prüfung
auf Versicherungsfähigkeit, nachdem der Familienstand des Versicherten geändert wurde).
In Phase 1 wurde (in Anhang D der Dokumentation „Das objektorientierte fachliche Referenzmodell)
diese Anforderung unter der Bezeichnung Termin/Ereignisverwaltung beschrieben.
3.3.9. Business Objects und Komponenten
3.3.9.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
© GDV 2001
81
Inhalt
•
•
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 3.2.5.1) wie Naming,
Transaction, Event usw. unterstützt werden.
Um ein Business Object oder eine Gruppe von Business Objects in eine auslieferbare Softwarekomponente (BO-Komponente) zu verwandeln, sind noch eine Reihe weiterer Hilfsmittel erforderlich:
•
•
Werkzeuge, um BO-Komponenten an die Systemumgebung wie Datenbanken, Security-Systeme
usw. anzupassen
Werkzeuge, um Komponenteneigenschaften 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. bei Enterprise JavaBeans, siehe Kapitel 4.4). Komponenten unterschiedlicher Frameworks erfordern jedoch auch unterschiedliche Werkzeuge. Trotz der
in Aussicht gestellten Konvergenz von Architekturen wie Enterprise JavaBeans, SanFrancisco und
CORBA Components sind dem freien Austausch von BO-Komponenten also noch Grenzen gesetzt.
Konfigurations
Werkzeuge
Business
Object
Business
Object
Business
Object
Komponente 2
Komponente 1
BO - Manager -Framework (Komponenten Framework)
Abbildung 40: 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
Technische Dienste
• CORBA Services
• Präsentation
• Datenbanken
Abbildung 41: Heterogene komponentenorientierte Systeme
82
© GDV 2001
Inhalt
3.3.9.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:
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 ist, 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 Schadensmeldung, 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
Common Business
Domain Types
•VAA Fachliches Referenzmodell
•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 42: Kompatibilitätsebenen
© GDV 2001
83
Inhalt
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.
3.4. Präsentation und Business Objects
Die bisher besprochenen Konzepte für Business Objects behandelten nur Ablaufsteuerung, Transaktionskonzepte, Dienstkonzepte sowie Datenspeicherung. Das VAA Business Object Metamodell geht
ebenfalls nicht näher auf die Präsentation von Business Objects ein. In diesem Kapitel wird nun die
Präsentation von Informationen eines Business Objects definiert und erläutert.
Grundsätzlich gehört eine Präsentation nicht zum Business Object dazu. Präsentationen sind jedoch
sehr eng an das zugehörige Business Object gekoppelt und sind in aller Regel austausch- bzw. konfigurierbar. Business Objects stellen sich also durch Präsentationen dar. Jedes Business Object kann
sich also in einer oder mehreren Präsentationen darstellen. In der Regel haben Business Objects eine
Standardpräsentation. 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). Abbildung 43 zeigt den Zusammenhang zwischen Business Object und der Präsentation, die im folgenden Presentation Component genannt wird. Beide Begriffe (Presentation und
Presentation Component) sind synonym verwendbar. Der Begriff Presentation Component jedoch
drückt die spezifischen Eigenschaften der VAA Präsentation besser aus. Diese Eigenschaften werden
in 3.4.1 spezifiziert.
Presentation
Component
Business
Object
Business
Object
Presentation
Component
Business
Object
Komponente
Komponente
BO - Manager -Framework (Komponenten Framework)
Abbildung 43: Business Objects und Presentation Components
Präsentationen bzw. Presentation Components sind zunächst keine bestimmte Art der Darstellung,
wie beispielsweise GUI, 3270, Java, HTML, Text. Das Konzept der Präsentation von Business Objects
sollte grundsätzlich von der verwendeten Technik bzw. Programmiersprache oder Verteilungsstrategie
frei sein.
Grundsätzlich muss es möglich sein, bei einem Business Object Präsentationen auszutauschen oder
hinzuzufügen, bzw. die Präsentation zu konfigurieren. Wünschenswert ist ein Grundgerüst für ein
Standardprotokoll zwischen Business Object und Präsentationskomponente sowie eine Präsentation
mit generischen Eigenschaften. So können beispielsweise durch die Konfigurierbarkeit bzw. Generik
84
© GDV 2001
Inhalt
Präsentationen an unternehmensspezifische Standards (Kopf- und Fußzeilen, Titel, usw.) angepaßt
werden. Darüber hinaus sollte es möglich sein, mit Hilfe eines Standardprotokolls unternehmensspezifische Präsentationen einem gekauften Business Object hinzuzufügen und diesem dadurch das unternehmensspezifische „Look & Feel“ zu verleihen.
3.4.1. Anbindung von Presentations an Business Objects
Grundsätzlich werden Informationen im Rahmen von Prozessen und Abläufen dargestellt. D.h., dass
der Präsentationskontext immer bei einem PBO liegt. EBOs haben in der Regel nur Standardpräsentationen für die einzelnen Daten oder Aspekte, die sie im Rahmen von Abläufen zur Ansicht bzw. Bearbeitung bereitstellen. Das bedeutet, dass die eigentliche Zuordnung einer Präsentation zu dem steuernden PBO gehört. Ebenso muß die Steuerung der Präsentation mit dem PBO gekoppelt werden, Informationen, die die Gesamtheit der Präsentation betreffen, wie beispielsweise das Schließen eines Fensters, muß somit dem steuernden PBO mitgeteilt werden. Änderungen an dargestellten Informationen,
z.B. die Eingabe eines Namens, muß wiederum an das betroffene BO, zumeist ein EBO, weitergeleitet
werden.
Daraus ergibt sich folgende Anbindung von Präsentationen an Business Objects:
Presentation
Benachrichtigt
Initiert Start
PresentationComponent
Presentation-Controller
Fachliche
Events
startet
PBO
benutzt
EBO
Abbildung 44: Schichtenmodell für die Präsentationsanbindung
Die Aufgaben der einzelnen Schichten sind wie folgt:
Presentation : Die Presentation ist die eigentliche, sichtbare Darstellung. Hierbei kann es sich
um die verschiedensten Arten der Darstellung handeln, beispielsweise HTML, Java-Application,
Java-Applet, XML [Mart2000], 3270-Stream, ASCII-Text, etc. Durch die Entkopplung der Presentation vom Business Object mit der Presentation-Controller Schicht können die verschiedensten Oberflächen mit ihren Verteilstrategien (stateless, stateful) realisiert werden.
Presentation-Controller : Dient der Entkopplung der eigentlichen Darstellung vom BO. Einerseits werden fachliche Events zwischen dem Presentation-Controller und dem PBO ausgetauscht. Andererseits ist der Presentation-Controller für den Aufbau der Verbindung zu den ein-
© GDV 2001
85
Inhalt
zelnen Datenfeldern / Bildschirmfeldern zuständig. Jede Presentation hat genau einen Presentation-Controller.
Presentation Component: Zusammenfassung der Presentation und des PresentationControllers. Diese Komponente stellt logisch die Präsentation eines Business Objects dar, denn
jeder Presentation ist genau ein Presentation-Controller zugeordnet. Die Zusammenfassung von
Presentation und Presentation Controller sagt jedoch noch nichts über die Verteilung bzw. Lokalität der einzelnen Komponenten aus. Mit diesem Konzept sind sowohl stateful als auch stateless
Clients realisierbar. Diese Ebene übernimmt eigenständig alle Aufgaben, die zur Präsentation von
Business Objects benötigt werden.
PBO : Gesamtkontext der Präsentation. Das PBO ist für den Start des Presentation Controllers
verantwortlich. Das PBO und der Presentation Controller tauschen fachliche Events aus. Beispielsweise wird das PBO informiert, wenn innerhalb einer Präsentation der „OK“-Button gedrückt wird. Dies impliziert die Aktion: „Accept“ bzw. „Commit“ und muß anschließend das
Schließen der Presentation über den Presentation Controller veranlassen.
EBO : enthält die einzelnen Informationen, die dargestellt werden sollen. Das EBO wird vom
Process Business Object innerhalb dessen Kontext benutzt.
Die Anbindung von anzuzeigenden Aspekten, beispielsweise der Nachname eines Partners wird, wie
beschrieben, durch den Presentation-Controller angestoßen.
Die Anbindung von Aspekten an die Oberfläche kann unterschiedlich erfolgen. Eine Lösung wäre z.B.
die Verwendung des „Aspect-Adaptor Patterns“ [PLoP95]. Hierfür wird der zu beobachtende Aspekt,
beispielsweise das Attribut eines Business Objects über ein Aspekt-Adaptor Object mit dem Anzeigeobjekt der Presentation verknüpft. Je nach Ausprägung des Aspekt-Adaptors (beobachtbar, nicht beobachtbar) zeigen sich Änderungen im Modell, also am Attribut des Business Objects an der Presentation. Eingaben an der Oberfläche werden an das Business Object ebenfalls weiter propagiert.
86
© GDV 2001
Inhalt
Beispiel
Java Swing JFrame
Presentation
Nachname
Vorname
AspektAdaptor
Vorname
AspektAdaptor
Nachname
EBO Partner
String Nachname
String Vorname
......
Die Presentation ist ein JFrame, der Presentation-Controller befindet sich mit dem JFrame auf dem Client. Die Business
Objects alufen auf dem Application Server ab.
Es sollen der Nachname und der Vorname des EBOs Partner angezeigt werden. Die Verknüpfung wird vom Presentation-Controller nach dem Starten der Presentation aufgebaut.
Nachdem die Aspekt-Adaptoren vorhanden und verknüpft sind (Zustand in der Skizze), werden Änderungen am beobachteten Aspekt (Nachname bzw. Vorname im EBO Partner) an die Oberfläche weitergereicht. Ebenso werden Änderungen oder Eingaben von der Presentation an den Aspekt im EBO Partner weitergereicht.
Abbildung 45: Beispiel einer Java-Presentation
Wann diese Propagierung durchgeführt wird, ist von der Presentation-Component abhängig. Beispielsweise können Änderungen bei einer Java-basierten Presentation direkt über Events weitergereicht werden („Propagation on lost focus“). Bei HTML-Oberflächen (stateless client) können diese
Änderungen erst bei Abschicken der gesamten Maske vom Webserver empfangen und nach Auswertung weitergeleitet werden.
© GDV 2001
87
Inhalt
Beispiel
Presentation
HTML Frame im Browser
auf dem Client
Nachname
Vorname
Fasadenobjekt
Oberfläche
AspektAdaptor
Vorname
AspektAdaptor
Nachname
EBO Partner
String Nachname
String Vorname
......
In diesem Beispiel ist die Presentation ein HTML Dokument. Da es sich um einen stateless Client handelt, ist in diesem
Fall der Presentation-Controller, der in Form einer Java Server Page implementiert ist, auf dem Web- oder Application
Server vorhanden. Ebenso auf dem Web- oder Application Server existiert ein Fasadenobjekt, welches alle Attribute der
Oberfläche enthält. Diese Attribute sind die Aspekte, die von den Aspect-Adaptoren nun beobachtet werden.
Wird ein HTML-Dokument zum Client-Browser geschickt, so werden die entsprechenden Anzeigefelder vor dem Verschicken aus dem Fasadenobjekt gefüllt. Anschließend wird das Dokument auf dem Client angezeigt.
Eingaben vom Client können erst weitergereicht werden, wenn das HTML-Dokument zum Server geschickt wurde. Hier
wird das Fasadenobjekt mit den Inhalten des HTML-Dokumentes gefüllt, die Aspekt-Adaptoren erkennen eine Änderung und propagieren diese an das EBO weiter.
Änderungen am Aspekt eines EBO können jedoch nicht sofort an den HTML-Client weitergereicht werden. Hierfür muß
bei Änderungen am Modell und an der Oberfläche eine Strategie zur Fehlerbehebung implementiert werden.
Abbildung 46: Beispiel einer HTML-Anbindung
Baukastenprinzip
Ein weiterer Aspekt der Präsentationskomponente ist das „Baukastenprinzip“ von Präsentationen.
Einzelnen Presentation-Components, die einem Business Object zugeordnet sind, sollten analog der
88
© GDV 2001
Inhalt
Datennormalisierung redundanzfrei sein, d.h. eine Präsentationskomponente kann sich aus anderen
zusammensetzten.
Daten vom
PBO
„Beschwerdelaufzettel
bearbeiten“
Daten vom
EBO „Partner“
Daten vom EBO „Partner-Adresse“
Standard-Buttonleiste für ein
„Bearbeiten“ - PBO
Abbildung 47: 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
[Gamma96]). 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.
© GDV 2001
89
Inhalt
3.4.2. Verteilung von Präsentation und Business Object
In einer verteilten Umgebung mit grafischer Oberfläche kommunizieren die auf dem Client befindlichen Presentation-Components 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 Client-Konfigurationen sinnvoll, die
unterschiedlichen Kommunikationsaufwand bedeuten und damit verschiedene Datenübertragungsstrategien erforderlich machen.
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.
Presentation
Presentation
Component
Component
Business
Business
Object
Object
Fat Client
BO-Manager Framework
BO-Persistence
Service
Server
Abbildung 48: Fat Client
Vorteil dieser Verteilungsstrategie besteht in der lokalen Kommunikation der Business Objects und
der Presentation Component, da sich Geschäftslogik und Oberflächen auf einem Client befinden.
Nachteil besteht in der Notwendigkeit der Verteilung der Anwendung (beispielsweise ist bei Versionswechsel von Anwendungen eine Verteilung der Anwendung auf alle Clients notwendig). Zudem
sind zumeist höhere Hardwareanforderungen an den Client notwendig.
Diese Verteilungsstrategie ist eigentlich nur für Intranets geeignet.
Thin Clients
Thin Clients enthalten die Presentation Component und kommunizieren mit entfernten Business Objects auf den Applikationsservern.
90
© GDV 2001
Presentation
Presentation
Componente
Componente
Business
Business
Object
Object
Inhalt
Thin Client
Server
BO-Manager Framework
BO-Persistence
Service
Abbildung 49: Thin Client
Der Server beinhaltet die gesamte Geschäftslogik, Clients haben „nur“ eine Oberflächenfunktion.
Vorteil dieser Lösung ist, daß nicht die komplette Anwendung an den Client verteilt werden muß. Mit
Verteilmechanismen, wie sie beispielsweise Java zur Verfügung stellt, können die Presentation Components bei Bedarf über das Netzwerk geladen und am Client ausgeführt werden. Diese Lösung ist
grundsätzlich Intranet-geeignet. Für die Verwendung als Internet-Plattform stellen sich hier vornehmlich zwei Probleme:
Zum einen kommuniziert die Presentation Component recht häufig mit dem BO (je nach Anbindung
kann sogar bei jedem „Lost-Focus“ ein Event gefeuert werden). Diese Kommunikation ist für eine
Internet-Plattform unbrauchbar. Es müssen hierfür Optimierungen bezüglich der Kommunikation Präsentation – BO durchgeführt werden.
Darüber hinaus muß die Oberfläche komplett geladen werden. Dies kann u.U. bei „großen“ Oberflächen längere Ladezeiten mit sich ziehen. Im firmeninternen Intranet kann dies aufgrund der zumeist
verfügbaren Bandbreite akzeptiert werden. Für einen Internet-Kunden sind diese Ladezeiten jedoch
nicht immer akzeptabel. Unter Umständen wird auch bestimmte oberflächennahe Prüflogik auf dem
Client durchgeführt, da es sich um einen stateful Client handelt. Dies kann dazu führen, daß firmeninternes Know-how auf beliebiege Clients verteilt werden müßte.
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 Presentation und Presentation-Controller insbesondere bei zusammengesetzten
Presentation-Components stark ansteigt (siehe Abbildung).
© GDV 2001
91
Inhalt
Server
Presentation
Presentation
UltraThin
Presentation
Presentation Client
P-Controller
P-Controller
P-Controller
P-Controller
BO
BO
BO
BO
BO-Manager - Framework
Abbildung 50: Ultra Thin Client
Diese Verteilung entspricht zumeist der einer Internet-Anbindung. An den Clients werden beispielsweise von einem Web Server HTML-Dokumente gesendet, die komplett ausgefüllt an den Web Server
zurückgeschickt werden. Die Anbindung der Oberfläche an die Geschäftslogik erfolgt dann wie in
3.4.1 beschrieben.
Vorteil dieser Lösung ist die Größe des zu verteilenden Clients. HTML-Dokumente beispielsweise
sind sehr schnell verfügbar, die gesamt Geschäftslogik einschließlich Prüfungen kann am Server stattfinden. Es muß keinerlei versicherungstechnisches Know-how (Tarifmodule etc.) am Client vorhanden
sein. Darüber hinaus ist die Anforderung an einen solchen Client relativ gering, was u.a. einer hohen
Verfügbarkeit in privaten Haushalten entspricht.
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.
3.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“.
92
© GDV 2001
Inhalt
Ü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:
•
•
Entkopplung 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.
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.
3.5.1. Entkopplung und Anpassung von Funktionalität
In der objektorientierten Literatur [Busch98], [Wann99] 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:
•
Objektadapter
•
Fassaden
Objektadapter 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 Objektadapter
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 Objektadaptern in der Lage,
auch komplexe Schnittstellen zu kapseln und funktionell anzupassen und können grundsätzlich auf
beiden Seiten gekoppelter Systeme eingesetzt werden.
3.5.2. Anpassungen der System- bzw. technischen Architektur
Objektadapter 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 Objects können ebenfalls
durch entsprechende Adapter auf die Dienste des Fremdsystems angepasst werden (siehe Abbildung
51). Die Systemarchitektur der VAA bietet gerade für diese Aufgaben eine gute Ausgangsbasis: Auf
© GDV 2001
93
Inhalt
ihrer Grundlage ist der Entwurf eines frameworkunabhängigen Schnittstellenmodells zur Anpassung
unterschiedlicher Systeme möglich.
vaaBO
vaaBOManager
xxBO
xxBOFactory
Annahme:
das Partnersystem verfügt
über eine Factory für alle BO
vaaPartnerMgr
(Objekt-Adapter)
xxPartner
vaaPartner
(Fassade)
xxPartnerRolle
Abbildung 51: Beispiel einer Systemanbindung durch Fassaden und Adapter
Der Aufwand für die Realisierung von Schnittstellen mittels Adaptern und Fassaden hängt 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 Components und auch SanFrancisco wird den dafür notwendigen Aufwand weiter reduzieren, sofern eine
dieser Technologien Basis der Implementierung bildet (siehe Abbildung 52).
Konvergenz
der Architekturen
SanFrancisco
?
Enterprise
JavaBeans
CORBA
Component Model
1998
2000
2002
Abbildung 52: Konvergenz der Architekturen
94
© GDV 2001
Inhalt
Transaktionsmanagement
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 Sitzungskontextes
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 Eventtyp
Õ 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 2001
95
Inhalt
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 53: Beispiel für die Anbindung eines Legacy – Systems
96
© GDV 2001
Inhalt
4. Architekturmodelle im Überblick
4.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 CORBA-Services
nicht nutzt, sind alternative Dienste und Kommunikationsmechanismen implementiert. Enterprise
JavaBeans (EJB) dagegen beschränkt sich auf die Implementierung eines Frameworks für BusinessObjects und Komponenten („Beans“) und ist „nach unten“ weitgehend kompatibel mit CORBAStandards. 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:
© GDV 2001
97
Inhalt
Business Object Architecture
San Francisco
Versionierbar
Standard
Person
Standard
0..1
Fachliche
Komponentenmodelle
an
0..1
Anschrift
0..1
*
an
*
Ba
Bankverbindung0..1
0..1
Versionierbar
Actor-Role
-Pattern
Standard
Person
Standard
0..1
anz
0..1
Anschrift
0..1
*
an
*
Ba
Bankverbindung0..1
0..1
SystemArchitektur
Dienste
Actor-Role
-Pattern
Standard
Person
Standard
0..1
*
Rufnummer
Standard
0..1
an
0..1
Anschrift
0..1
*
an
*
Ba
Bankverbindung0..1
0..1
SystemArchitektur
IBM San Francisco
Technische
Architektur
SystemArchitektur
Enterprise JavaBeans
Dienste
Technische Dienste
Technische Dienste
(CORBA Services)
Fachliche
Komponentenmodelle
Dienste
Technische Dienste
(CORBA Services)
Fachliche
Komponentenmodelle
Standard
0..1
*
Rufnummer
BOCA (OMG)
Versionierbar
Actor-Role
-Pattern
Standard
0..1
*
Rufnummer
Enterprise Java Beans
Technische
Architektur
(CORBA Services)
Technische
Architektur
Abbildung 54: Einordnung der betrachteten Architektur-Frameworks
4.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
4.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“ OOAD-Modell 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.
98
© GDV 2001
Inhalt
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-Types5 in BOCA zuordnen.
So entspricht das InterOp - Object BocaObject dem BOCA Meta-Type 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.
4.2.2. Grundmuster der Architektur
4.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.
5
Ein Meta-Type ist die formale Beschreibung der Eigenschaften aller Objekte eines bestimmten Types.
© GDV 2001
99
Inhalt
Personnel
Adaptors
Business Objects
Production Scheduling
Supplier
Customer
Abbildung 55: 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
100
© GDV 2001
Inhalt
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ände6
•
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
6
InterOp unterscheidet zwischen Attributen und Zuständen: Zustände sind spezielle numerische Attribute, deren Werte bestimmte Zustände
des BOs charakterisieren
© GDV 2001
101
Inhalt
BocaGenericDataType::BocaObject
BocaTransactions::TransactionalObject
BocaNotification::Consumer
BocaNotification::Supplier
BocaObjects::StateAccess
BocaGenericDataTypes::DependentObject
BocaObjects::LifeCycleObject
BocaObjects::IndependentObject
BocaObjects::BusinessObject
BocaObjects::TypeManager
Abbildung 56: 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.
4.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
für die Erstellung von Business-Komponenten benötigt werden, nicht definiert. InterOp geht deshalb
102
© GDV 2001
Inhalt
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 57: InterOp Services über verschiedene Komponenten
4.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 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
© GDV 2001
103
Inhalt
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 5: 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.
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
104
© GDV 2001
Inhalt
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). EventVerbindungen zu anderen Objekten werden
nicht kopiert.
© GDV 2001
105
Inhalt
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 Create-Interfaces
müssen lediglich Erzeugungsort (ein spezieller
Objekttyp) und die Initialwerte der BOAttribute (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 6: 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 7: State Access Operationen der Interoperability Specification
Events
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 Consumer106
© GDV 2001
Inhalt
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 8: 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.
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
© GDV 2001
107
Inhalt
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 9: 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 10: 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
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).
108
© GDV 2001
Inhalt
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 11: 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 Business-Objekte
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
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
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
© GDV 2001
109
Inhalt
zugehörigen Typs auftreten (vgl. BocaObjectKey).
Tabelle 12: 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 13: Exception Categories (Interoperability Specification)
4.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
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:
110
© GDV 2001
Session
Inhalt
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) aufzulösen
resolution
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 14: Eigenschaften des Transaction Service (Interoperability Specification)
© GDV 2001
111
Inhalt
1: commit()
Steuerlogik
der Anwendung
(Prozeß)
2
ate
ag
ro p
p
:
Transaction
Manager
(CORBA)
()
a
4: v
3a: check
SideEffec
ts()
lida
te()
5: validateInternalStateBeforeUpdate()
BO
BO
(im Tx-Context
registriert)
3b:
che
ckI
nte
rna
lRu
les
()
s
6:
yn
ize
ro n
ch
()
7: storeState()
Storage Manager
Abbildung 58: 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.
Security Service
112
© GDV 2001
Inhalt
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.
4.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 übergreifend
beschrieben. Dennoch wird die Interoperability Specification aufgrund des Erfolg des JavaBeans Komponentenmodells in dieser Form nicht als Standard verabschiedet werden. Die in 2001 erwarteten
CORBA Components Model - Spezifikationen werden sich an JavaBeans bzw. Enterprise JavaBeans
orientieren. Das CORBA Components Model macht die meisten der oben angeführten Spezifikationen
überflüssig. Allerdings fehlen im Components Model 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.
4.3. IBM San Francisco
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 2001
113
Inhalt
Abbildung 59: 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.
Abbildung 60: Die San Francisco Architektur
114
© GDV 2001
Inhalt
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).
4.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 2001
115
Inhalt
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ß
116
© GDV 2001
Inhalt
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.
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.
4.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 61: 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.
4.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 defi-
© GDV 2001
117
Inhalt
niert und so können unterschiedliche Implementationen eines Kernprozesses ohne Änderung der eigentlichen Anwendung verwendet werden.
Abbildung 62: 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
118
© GDV 2001
Inhalt
die Stücklistenverwaltung. Die Lagerverwaltung definiert auch das Business Object Product.
4.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.
4.4. Enterprise JavaBeans
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
© GDV 2001
119
Inhalt
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.
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.
4.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.
4.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, Webserver oder Datenbanksystem) bereitgestellt wurde.
4.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 entwikkeln 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.
4.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.
4.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.
4.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.
120
© GDV 2001
Inhalt
4.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, Symantec Visual Cafec , SUN Forte oder Borland JBuilder, 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.
4.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.
4.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 Services 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 2001
121
Inhalt
4.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.
4.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
EJB Objekt
(Client view)
Client
Enterprise bean
EJB Home
(bean identifier)
Environment
Abbildung 63 : 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:
•
122
die Registrierung der Objekte
© GDV 2001
•
die Erzeugung und Löschung der Objektinstanzen
•
Sicherheitsprüfungen für Objekte
•
Verwaltung der aktiven Zustände im Objekt
•
Koordinierung verteilter Transaktionen.
Inhalt
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.
4.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 delegieren 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.
4.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 2001
123
Inhalt
4.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.
4.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.
4.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.
4.4.5. Beschreibung der Services
4.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.
124
© GDV 2001
Inhalt
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.
4.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 entfernt wird. Das EJB Modell kapselt diese Funktionen in die Methoden ejbLoad, ejbStore, ejbActivate
und ejbPassivate in jeder Enterprise Bean Klasse.
4.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 implementiert oder einen
optimaleren Service nimmt, wie z.B. die Hinterlegung der persistenten Daten des Objekts in die Spalten einer relationalen Datenbank.
© GDV 2001
125
Inhalt
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.
4.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 der Enterprise
Bean mitbringt, wechselt die Methode in den Transaktionskontext des Clients, anderenfalls läuft
der Methodenaufruf ohne Transaktion ab.
126
© GDV 2001
•
•
•
Inhalt
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.
4.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.
4.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 Komponenten 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.
Das EntityDescriptor Objekt erweitert das Deployment Descriptor Objekt um die Attribute, in denen
gespeichert wird, welches Feld automatisch vom Container persistent gemacht wird.
© GDV 2001
127
Inhalt
4.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.
Es gibt inzwischen schon einige Implementierungen, u.a. z.B. innerhalb von Oracle 8i, Oracle 9i
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
E-Business Suite (ERP, CRM) . Die meisten dieser Implementierungen stützen sich (zumind. zum
Zeitpunkt der Erstellung des Dokumentes) auf die Version 1.x von EJB. In dieser Version waren einige Dienste, die zur Erstellung von Applikationen erforderlich sind, noch nicht spezifiziert bzw. enthalten. Die o.g. Produkte haben die fehlenden Dienste mit eingener Logik gefüllt. Es bleibt abzuwarten, inwieweit die vorliegende Version 2.0 der EJB-Spezifikation, die nun vollständiger ist, Änderungen in den o.g. Produkten nach sich zieht.
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.
128
© GDV 2001
Inhalt
5. 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
1999
2000
2001
2002
Abbildung 64: Konvergenz der Komponentenarchitekturen
Neben der Kompatibilität von Komponenten auf technischer Ebene sind einheitliche Schnittstellen auf
fachlicher Ebene notwendig. Die Basis hierfür schafft das fachliche Referenzmodell. Die im fachlichen Referenzmodell beschriebenen fachlichen Komponenten sollten gemeinsam mit dem technischen
Referenzmodell für zukünftige Implementierungen in der Versicherungswirtschaft als Basis dienen.
© GDV 2001
129
Inhalt
6. 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
Microsofts 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 Object Adapter (BOA)
Ein von CORBA definierter Objektadapter, den alle ORBs 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.
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
130
© GDV 2001
Inhalt
Dienste zur Verfügung stellen, die auf der Systemebene des ORBs agieren. Zusätzlich beinhaltet
CORBA die CORBAFacilities, 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)
Anwendungsarchitektur von Microsoft, die in einem Framework von verteilten Einzellösungen das
Internet mit einer Client-/Server-Architektur integriert. Sie ist ein Multitier 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 Object (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
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 Softwa© GDV 2001
131
Inhalt
rehä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 ORBs.
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 Objects. 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 Softwaresystems, 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.
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
132
© GDV 2001
Inhalt
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 Object (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 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.
© GDV 2001
133
Inhalt
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-Interfaces 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
134
© GDV 2001
Anhang
7. Anhang
7.1. Charakterisierung der einzelnen CORBA-Services
Generell bestehen alle CORBA-Spezifikationen aus Schnittstellenbeschreibungen, die sogenannten
Interface Definitions. In einem verteilten, plattformunabhängigen System sind die in IDL definierten
Interfaces das einzige, was ein Objekt von einem Service wissen muß. Der Ort des Objektes, das einen
Service implementiert, ist völlig transparent.
CORBA Services bestehen in vielen Fällen aus Interface - Beschreibungen von Objekten, die den betreffenden Service implementieren und Beschreibungen von Interfaces, die ein Objekt, das den Service
nutzen will, selbst implementieren muß. Es handelt sich also um eine wechselseitige Vereinbarung,
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 Interfacebeschreibungen werden in sogenannten Modulen zusammengefaßt. So enthält zum
Beispiel das Modul cosRelationships alle Interfacebeschreibungen des Relationship Service.
Hinweis: Die Beschreibung der Services beruht auf der CORBA Spezifikation 2.2, da für diese Spezifikation die meisten Produkte zum Zeitpunkt der Dokumentenerstellung verfügbar waren. Neuere
CORBA Spezifikationen sind unter www.omg.org jederzeit im Web einsehbar. Darüber hinaus kann
und will diese Beschreibung der Services nicht mit der derzeit vorhandenen Fachliteratur zu CORBA
konkurrieren. Sie erhebt auch keinen Anspruch auf Vollständigkeit, da Services, die nicht als Produkt
verfügbar waren (Stand der Dokumentenerstellung) in die Betrachtung einbezogen wurden. Vielmehr
soll mit dieser Auflistung dem Leser eine Übersicht über die vorhandenen und benötigten Services
vermittelt werden. Weiterführende Literatur siehe [OMG98a][Orfali98] [Orfali97] [Orfal98b]
[Mow97] [Orfali96].
Eine Auflistung über die Verfügbarkeit der verschiedenen Services ist unter 7.2 zu finden.
7.1.1.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.
© GDV 2001
135
Anhang
Objekte werden durch sogenannte Factories erzeugt. Factories sind Objekte, die über Methoden verfügen um ein Objekt eines bestimmten Typs zu erzeugen [Gamma96]. Um ein neues Objekt zu erzeugen, muß ein Client zunächst die zugehörige Factory finden. Dazu benutzen Clients entweder
Suchmechanismen, wie den Trader Service oder das FactoryFinder - Interface oder sie erhalten
Factory-Objekte als Parameter von Operationen.
Es gibt kein Standard Interface für eine Factory. Sie sind abhängig von der Objektimplementierung,
d.h. verschiedene Objektimplementierungen können verschiedene Factory Interfaces definieren.
Da es kein Standard Interface für eine Factory gibt, existiert ein Generic Factory Interface, das eine
generische Operation zur Erzeugung von Objekten bereitstellt.
Um ein Objekt zu erzeugen, muß der Client eine Objekt Referenz für eine Factory (entweder generische Factory oder objektspezifische Factory) besitzen und einen create - Request an diese absetzen.
Als Ergebnis auf den create - Aufruf wird ein neues Objekt von der Factory erzeugt und die Objektreferenz an den Client zurückgeliefert. Die Factory ist für die Bereitstellung der benötigten Ressourcen
verantwortlich.
Um ein Objekt zu löschen, muß der Client einen remove - Request an das Objekt absetzen. Dieses
Objekt muß jedoch das LifeCycleObject Interface unterstützen. Die Objektreferenz wird ungültig,
der Client ist jedoch nicht für das Freigeben der Ressourcen verantwortlich.
Um Objekte zu kopieren oder zu verschieben, muß der Client einen copy- oder move - Request an das
Objekt absetzen. Auch hier muß das Objekt wieder das LifeCycleObject Interface unterstützen.
Zunächst wird ein neues Objekt im Bereich des Factory Finders angelegt. Der Factory Finder definiert eine Schnittstelle, um Factories zu finden. Bei einem copy oder move wird demnach mit Hilfe des
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.
Obwohl in vielen CORBA-Produkten der Lifecycle noch nicht Einzug gefunden hat, gibt es doch Implementierungen auf dem Markt, die auch genutzt werden sollten, da der Life-Cycle einen wichtigen
Dienst darstellt.
7.1.1.2. Naming Service
Definition
136
© GDV 2001
Anhang
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.
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 15: 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.
Abbildung 65: 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.
© GDV 2001
137
Anhang
7.1.1.3. Relationship Service
Definition
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:
•
138
Erzeugen eines Rollen- oder Relationenobjektes (fällt in die Zuständigkeit der Rollen- oder
Relationen-Factory).
© GDV 2001
Anhang
•
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).
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 2001
139
Anhang
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 66: 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
140
© GDV 2001
Anhang
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.
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 67: 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.
7.1.1.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 2001
141
Anhang
Client
Persistentes
Objekt
PO
Protokoll
Persistence
Data Service
PID
POM
Persistence-ID
Persistence
ObjectManager
PDS
Datenspeicher
Abbildung 68: 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 DatenspeicherungsProtokoll 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.
142
© GDV 2001
Anhang
7.1.1.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 ACIDCharakteristika 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 Reco-
© GDV 2001
143
Anhang
verable Object muß deshalb sowohl das TransactionalObject- als auch das ResourceInterface implementieren. Ein Recoverable Object beteiligt sich am Transaction 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 69: 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.
144
© GDV 2001
Anhang
Ein Two-Phase Commit setzt immer dann sämtliche Veränderungen zurück, wenn eine einzige Ressource einen Fehler dokumentiert bekommen hat.
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 70: 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
© GDV 2001
145
Anhang
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 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 Enterprise-JavaBeans 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.
7.1.1.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:
146
© GDV 2001
Anhang
Abbildung 71: Locking Modes des Concurrency Services
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.
7.1.1.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.
© GDV 2001
147
Anhang
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.
Tabelle 16: Eigenschaften von Diensten beim CORBA-Trader Service
1.
2.
Trader
3.
1
Server
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
2
3
Client
Abbildung 72: 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 aufwen-
148
© GDV 2001
Anhang
dig 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
© GDV 2001
149
Anhang
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 Lookup-Objekt 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 17: 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.
150
© GDV 2001
Anhang
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 18: 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 73: Beispiel Trader Service
© GDV 2001
151
Anhang
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.
7.1.1.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
152
© GDV 2001
Anhang
Bestimmt, ob ein beliebiges Element innerhalb
einer Collection nur genau einmal (unique)
oder auch mehrfach (multiple) vorkommen
darf.
Eindeutigkeit der Einträge
Tabelle 19: 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:
2UGHUHG
6RUWHG
6HTXHQWLDO
0XOWLSOH 8QLTXH 0XOWLSOH 0XOWLSOH
8QRUGHUHG
8QLTXH
(OHPHQW
0DS
6RUWHG 6RUWHG
5HODWLRQ 0DS
5HODWLRQ
.H\
1R(OHPHQW
.H\V6HW .H\%DJ .H\V6HW .H\%DJ
4XDOLW\
1R
.H\
(OHPHQW
4XDOLW\
1R(OHPHQW
4XDOLW\
6HW
%DJ
6HW
%DJ
+HDS
(TXDOLW\
6HTXHQFH
6HTXHQFH
Abbildung 74: 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
© GDV 2001
153
Anhang
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.
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.
7.1.1.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
154
© GDV 2001
Anhang
Eigenschaft löschen werden.
Readonly: Property-Informationen können nur gelesen oder
gelöscht werden.
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 20: 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 75: 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 EigenschaftsEditoren 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.
7.1.1.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.
© GDV 2001
155
Anhang
Zur Formulierung der Queries können folgende Sprachen genutzt werden:
•
OQL – ODMG-93 Objekt Query Language
•
SQL mit objektorientierten Erweiterungen
•
Eine Mischung aus den SQL und OQL
Schematische Darstellung des Ablaufes:
Client
Query Evaluator
Query Evaluator
Query Evaluator
Native Query System
Objekt
Abbildung 76: 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
156
© GDV 2001
Anhang
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
•
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.
© GDV 2001
157
Anhang
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 77: Beispiel für eine Query mit dem QueryManager
Wertung
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.
7.1.1.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 nachwei-
158
© GDV 2001
Anhang
sen. 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)
überhaupt verwendet werden darf. Dazu reicht der ORB das mitgelieferte Credential an die Zugriffsentscheidung des Sicherheitsdienstes (AccessDecision) weiter. Hinter dieser abstrakten Schnittstellen verbirgt
sich das eigentliche Autorisierungsverfahren, das ermittelt ob der Aufrufer durch seine Identität und Rollen
für die betreffenden Ressource (Server-Objekt) berechtigt ist, die gewünschte Operation auszuführen.
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 78: 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.
7.1.1.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,
© GDV 2001
159
Anhang
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.
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.
160
© GDV 2001
Anhang
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:
Client
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 79: Lesen und Schreiben von Objekten im Externalization Service
© GDV 2001
161
Anhang
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.
7.1.1.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.
162
© GDV 2001
•
Anhang
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.
Consumer
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
© GDV 2001
163
Anhang
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 80: 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 2.1.3). 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.
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.
7.2. Verfügbare CORBA Implementierungen und Services
Die folgenden Listen erheben keinen Anspruch auf Vollständigkeit noch ergibt sich aus der Liste eine
Wertung für ein Produkt oder einen Hersteller. Diese Listen soll einzig und allein dem Betrachter einen ersten Überblick über die Verfügbarkeit von CORBA-Implementierungen, unterstützten Sprachen
sowie implementierten Services zu geben. Ein aktueller Überblick ist im WWW unter
http://www.cetus-links.org/oo_object_request_brokers.html verfügbar. Die folgenden Übersichten
wurden mit freundlicher Genehmigung von Cetus zur Verfügung gestellt.
7.2.1. Cetus – Übersicht über verfügbare CORBA – ORBs
Folgende Auflistung soll eine Übersicht über die derzeit verfügbaren CORBA ORB Implementierungen bieten. Bei den entsprechenden Produkten ist außerdem ersichtlich, welche Programmiersprachen
und Features unterstützt werden.  2000 by Cetus Team.
Arachne
(Decision Systems Group)
í
Product C++, Extensions
í
CORBA Services: Naming, Lifecycle, Property, Relationships, Externalization
BEA WebLogic Server and BEA WebLogic Enterprise (was Object Broker, was M3 )
(BEA)
í
164
Product (BEA WebLogic Enterprise) Product (BEA WebLogic Server)
© GDV 2001
í
C++, Java, Active X Bridge, MOM, Extensions, Security
í
CORBA Services: Naming, Transaction
í
ObjectBroker page (Compaq-CERN Joint Project)
Anhang
Bionic Buffalo - siehe Tatanka
BlueORB
í
(Berry Software)
Product Java
ChorusORB (Sun)
í
Product C++, real-time embedded systems
í
CORBA Services: Naming, (other non-standard)
Component Broker/DSOM
(IBM)
í
Product C++, Java, Smalltalk, COBOL, ActiveX Bridge, Extensions
í
CORBA Services: Naming, Events, LifeCycle, Transaction, Externalization,
Concurrency, Identity, Query, Security, (other non-standard)
í
Redbook
Cool ORB - siehe ChorusORB
COPE
(Bart Schuller)
CORBAplus
(ExperSoft)
í
Product C++, Java, ActiveX Bridge
í
CORBA Services: Naming, Events, Relationship, Notification, Trader, Transaction
Corbus
(obsolete)
(BBN)
DAIS - siehe LiveContent BROKER
DIMMA (ANSA)
í
Product Download (zipped) C++
í
Specialised ORB for multi-media and real-time applications
Distributed Smalltalk (ObjectShare)
í
Product Smalltalk
í
CORBA Services: Naming, Events, Transaction, Concurrency
DOME
í
(Object Oriented Technologies)
Product C, C++
Electra
(Silvano Maffeis)
í
Product C++, (Tcl/Tk)
í
Specialised for fault-tolerant systems such as Horus and Ensemble.
í
CORBA Services : Naming, (Events)
Enterprise JavaBeans - siehe JavaIDL
Flick
í
(Flux Project at the University of Utah)
Product C++, C - Flexible and optimizing IDL compiler kit
© GDV 2001
165
Anhang
Fnorb
í
(DSTC)
Product Python
GemORB
(GemStone)
í
Product C++, Java , Smalltalk
í
CORBA Services : Naming, Events, Notification, Persistence, Lifecycle, Transaction,
Concurrency
Hardpack
í
(Lockheed Martin)
Product C, C++, Ada83, Ada95, RealTime, Fault Tolerant
Harlequin
í
Product
ILU
í
(Harlequin)
Dylan, Common Lisp, POA
(Xerox Parc)
Product C++, ( C , Java, Python, Lisp, Perl, Modula-3 )
Interbroker - see DOME
ISP
í
(Russian Academy of Science)
Product C++
JacORB
(Gerald Brose)
í
Product Java
í
CORBA Services : Naming, Events
JADE
(APM)
JavaBeans - siehe JavaIDL
JavaIDL (and Enterprise JavaBeans) (JavaSoft)
í
JavaIDL Enterprise JavaBeans Java, ActiveX Bridge
í
CORBA Services : Naming, (Transactions)
JavaORB
(Distributed Objects Group)
í
Product Java, POA, OBV, Thread Policies, Interceptors
í
CORBA Services : Naming, Event, Notification, Trading, Transactions, Security,
Persistence, Property, Collection
JBroker
(ObjectEra, now Silverstream (was ObjectEra)
í
Product Java, POA, RMI translator
í
CORBA Services : Naming, Security, (Transactions)
Joe - siehe NEO
Jonathan
í
Product Java
Jorba
166
(France-Télécom/CNET)
(Roland Turner)
í
Product
í
CORBA Services : Naming
Java
© GDV 2001
Anhang
JYLU - see ILU
Krypton (now part of Continuous eCommerce Platform) (TANTAU Software)
í
Product C, C++, Java, COBOL
LiveContent BROKER (was DAIS)
(Peerlogic)
í
Product C, C++ , Java , ActiveX Bridge , POA
í
CORBA Services: Naming, Events, Security, Transaction
M3 - siehe BEA Object Broker
MICO
(University of Frankfurt)
í
Product C++, (Perl, Tcl/Tk, POA)
í
CORBA Services : Naming, Events, Time, (Property)
NEO (Obsolete)
(Sun Microsystems)
Netscape Internet Service Broker (Netscape)
í
Product C++ , Java - siehe auch VisiBroker
Nouveau
(Roguewave)
í
Product
í
OAK
C, C++, Java, POA, interoperability with COM
(Camros Software)
í
Product
í
C++, Objective-C, (Java)
Object Broker - siehe BEA WebLogic Enterprise
ObjectBus - siehe TIB/ObjectBus
ObjectDirector
(Fujitsu)
í
Product C, C++, Java, ActiveX Bridge, Extensions
í
CORBA Services : Naming, Events, Lifecycle, Persistent Object, Transaction,
Externalization, Concurrency, Relationship, (Time, Properties, Security, Query,
Licensing)
í
OmniBroker - siehe ORBacus
í
omniORB2
í
Product C++, Python
í
CORBA Services : Naming, Property
OrbAda
(AT&T Laboratories )
(Top Graph’X)
í
Product Ada95
í
ORBacus
(Object-Oriented Concepts)
í
Product C++, Java, Extensions, (Security),
í
CORBA Services : Naming, Events, Notification , Prsperty, Trader,
© GDV 2001
167
Anhang
í
ORBAsec : Security Service (Adiron)
ORBAsec - siehe ORBacus Security
ORBexpress
(Objective Interface Systems)
í
Product C++, Ada 95, Embedded Systems, Real-Time,
í
CORBA Services : Naming, Time
ORBit
(RHAD Labs , GNOME Project )

Product C and others under development, e.g.: C++ ,
http://www.alphalink.com.au/%7Etabbycat/ORBit-Eiffel/index.htmlPython ,
Perl , Eiffel
Orbix (Iona Technologies)
í
Product C++, Java, COM-Corba Bridge, Cobol, PL/I, Embedded Systems
í
CORBA Services : Naming, Events, Security, Trader, Transaction, (Notification)
í
CORBA Distributed Objects, using Orbix (Sean Baker)
í
Lumos TMS CORBA-Based TL1 Management Solution (Lumos Technologies)
í
CORBA-to-CMIP Gateway (UHC)
ORB Plus (Obsolete) (HP)
í
Product C++, ActiveX Bridge
í
CORBA Services: Events, Naming, Lifecycle
RCP-ORB (Obsolete) (NORTEL)
ROBIN (Jim Pangburn, FermiLab)
í
Product C, C++, Java (unofficial mappings)
í
CORBA Services: (coming soon...)
Secant Extreme Enterprise Server (Secant )
í
Product C++, Java, Extensions
í
CORBA Services : Events, Concurrency, Persistence, Transaction, Security, (Query),
(Externalization)
í
Rose Secant Extreme Link
SmalltalkBroker
(Promia (formerly DNS Technologies))
í
Product
í
CORBA Services : Naming, Events, Lifecycle, Transaction, (Security),
í
Visual Enterprise Information Server
SOMobjects
Smalltalk, Extensions
- siehe ComponentBroker
SORBET (obsolete) (Siemens Nixdorf )
TAO
í
168
( Distributed Object Computing Group at Washington University
Product C++, Real-time, POA
© GDV 2001
Anhang
í
CORBA Services : Naming, Events, Trader, Lifecycle, Property, Concurrency, A/V
Streaming
í
Support for ACE from Riverace
í
Support for ACE from OCI
Tatanka
(Bionic Buffalo )
í
Product C, (C++, Java), POA
í
CORBA Services : Naming, Events, Time, Externalization, Trader, Lifecycle, Persistence,
Property, Relationship, Concurrency, Security, Transaction
TIB/ObjectBus
(TIBCO)
í
Product C++, Java, MOM
í
TME 10 (obsolete)
UNAS
(Tivoli Systems)
(TRW)
í
Product C++, Ada95, MOM, Extensions
í
VisiBroker
(Borland)
í
Products C++, Java, COM/CORBA Bridge, Extensions
í
CORBA Services : Naming, Events, Transaction
í
Grasshopper - a mobile agent (IKV)
í
Highlander Communications’ products based on VisiBroker (Highlander
Communications)
í
Installing VisiBroker 3.2 for Java on "unsupported" systems (Hauke Fath)
í
Programming with VisiBroker (Doug Pedrick, Wiley)
í
MakoServer CICS Bridge (Saga Software (was Blue Lobster))
Voyager ORB
(ObjectSpace)
í
Product Java, CORBA-enabled Mobile Agent
í
CORBA Services : Naming, Security, Transaction
í
Aliens3D - Multiuser world with VRML/EAI and Java Voyager ORB
í
Technical White Papers
í
Jini Voyager (Gamelan, Mar 1999)
7.2.2. CORBA Service Implementierungen
Die folgenden CORBA Services werden zusätzlich zu den in 7.2.1 aufgeführten ORB Implementierungen Herstellern angeboten. Auch hier wird wieder keine Garantie auf Vollständigkeit übernommen.
Die Auflistung soll lediglich zur Orientierung dienen:
Collection Service
© GDV 2001
169
Anhang
í
OpenFusion Collection Service (PrismTech)
Collection Service with Java & C++ bindings.
Concurrency Service
í
OpenFusion Concurrency Service (PrismTech)
Concurrency Service with Java & C++ bindings.
Event Service
í
NetEvents (Exemplar Development)
Java implementation of the Event Service.
í
OpenFusion Event Service (PrismTech)
Event Service with Java & C++ bindings.
Lifecycle Service
í
OpenFusion Lifecycle Service (PrismTech)
Lifecycle Service with Java & C++ bindings.
Licensing Service
í
SilkMeter (Segue Software)
C++ and Java implementations of the Licensing Service.
Naming Service
í
DSTC Scalable Naming Service (DSTC)
C++ implementation of the Naming Service
í
ENames - CORBA Naming Service Browser [German] (Entrance Software)
Java / Swing Naming Service Browser
í
jNames (OutBack Resource Group)
Java implementation of the Naming Service
í
OpenFusion Naming Service (PrismTech)
Naming Service with Java & C++ bindings
í
ORBacus Names (OOC)
Java implementation of the Naming Service
í
TRC Naming Service (Technical Resource Connection)
Java implementation of the Naming Service.
Notification Service
í
DSTC Notification Service (DSTC)
C++ implementation of the Notification Service.
í
OpenFusion Notification Service (PrismTech)
Notification Service with Java & C++ bindings.
í
ORBacus Notify (OOC)
í
Orbital Notification Service (NEC)
Patient Identification Service
170
© GDV 2001
í
Anhang
Patient Identification Service (LANL)
Persistent Object Service
í
Secant Extreme Persistent Object Service for C++ and Java (Secant)
Persistent Object Service with Java & C++ bindings.
Property Service
í
OpenFusion Property Service (PrismTech)
Property Service with Java & C++ bindings.
í
Property Service (Carsten Zerbst)
Property Service implemented using Tcl and Mico.
Relationship Service
í
Enabled Systems Persistent Relationship Service (Enabled Systems)
Relationship Service with Java & C++ bindings.
í
OpenFusion Relationship Service (PrismTech)
Relationship Service with Java & C++ bindings.
Security Service
í
ORBAsec (Adiron)
Java implementation of the Security Service (Level 1 and Level 2)
í
SecureBroker (Promia)
Java implementation of the Security Service (Level 1 and Level 2)
Time Service
í
OpenFusion Time Service (PrismTech)
Time Service with Java & C++ bindings.
í
Time Service (Carsten Zerbst)
Time Service implemented using C++.
Trading Service
í
DSTC Object Trader (DSTC)
C++ implementation of the Trading Object Service.
í
JTrader (Bruno Böttcher)
Java Trading Service, implementing Manager - Factory pattern
í
OpenFusion Trading Service (PrismTech)
Trading Object Service with Java & C++ bindings.
í
ORBacus Trader (OOC)
Java implementation of the Trading Object Service.
í
TOI (IKV)
í
Trader (Washington University in St. Louis)
Transaction Service
© GDV 2001
171
Anhang
í
CORBAplus Transaction Service (Expersoft)
C++ implementation of the Object Transaction Service.
í
Java Transaction Service (JTS) (JavaSoft)
Java implementation of the Object Transaction Service.
í
JTSArjuna (Arjuna Solutions)
Java implementation of the Java Transaction Service
í
OTSArjuna (Arjuna Solutions)
C++ implementation of the Object Transaction Service.
í
TPBroker (Hitachi)
C++ implementation of OTS, and Java Implementation of OTS and JTS.
í
VisiBroker ITS (Borland)
Implementation of CORBA OTS and JTS
7.3. Beispiele für Oberflächenanbindungen
7.3.1. Das archid - Framework als Beispiel einer flexiblen Verteilung von
Oberfläche und Anwendungslogik
7.3.1.1. Kontext
Außendienstsysteme im Versicherungsbereich unterliegen steigenden Anforderungen bezüglich Flexibilität, Konnektivität und Kosten. Neue Versicherungsprodukte müssen schnell und flexibel in Außendienstsysteme integriert werden, um die Mitarbeiter vor Ort zu unterstützen.
Kann zusätzlich mit diesem System die Unterstützung unterschiedlicher Vertriebswege gewährleistet
werden, lassen sich große Kostenvorteile für Entwicklung und Einarbeitung erzielen.
Das archid-Framework des debis Systemhauses definiert eine Architektur, die speziell für die Anforderungen moderner Außendienstsystemplattformen entwickelt wurde und diesen Rechnung trägt. Diese Anforderungen sind im Einzelnen:
• Die Architektur muß ohne Änderungen in den Betriebsarten: Standalone (Fat Client), Client/Server (Thin Client) und Browser-Betrieb (Web, Thin Client) lauffähig sein.
• Sie muß eine horizontale Trennung zwischen Präsentations- und Logikschicht bieten.
• Sie muß eine horizontale Trennung zwischen Logik- und Datenzugriffsschicht bieten.
• Sie muß parallel laufende Anwendungsmodule ermöglichen.
• Sie muß die Erstellung von wiederverwendbaren Komponenten ermöglichen.
• Sie muß die Produktivität der Anwendungsentwickler unterstützen, indem viele Basisfunktionalitäten in der Architektur bereits implementiert sind.
• Sie muß prozeßorientiert arbeiten. Die Prozesse müssen mindestens per Filetransfer auf ein anderes System übertragbar sein.
Das Framework, das die archid-Architetur umsetzt, ist in Java implementiert.
172
© GDV 2001
Anhang
Die Architektur inkl. Framework wird derzeit erfolgreich für die Entwicklung der neuen Außendienstplattformen von Gerling und der Aachener und Münchener eingesetzt.
Im weiteren werden speziell die Funktionalitäten und Konzepte für die Verbindung der Oberflächenschicht mit der Anwendungslogik beschrieben.
7.3.1.2. Probleme
Betriebsarten
Für die Unterstützung der verschiedenen Betriebsarten, im speziellen der Thin-Client-Bertriebsart,
muß die Anwendung in den Oberflächenanteil und die fachliche Anwendungslogik aufgeteilt werden.
Im Thin-Client-Betrieb ergibt sich dann die klassische Ausprägung des Client-/Server-Betriebes mit
der Oberflächenschicht auf dem Client und der Awendungslogik auf dem (Applikations-) Server.
Kommunikaton
Die Aufteilung in Oberfläche und Anwendungslogik zieht Folgeprobleme hinsichtlich der Kommunikation nach sich. Die fachlichen Daten müssen in einfacher, kompakter Form als möglichst kleine
Datenpakete vom Server zum Client transportiert werden. Dazu sollen idealerweise möglichst wenig
Serverzugriffe nötig sein.
Das bedeutet auch, daß Events der Oberfläche nicht über das Netz propagiert werden dürfen, weil sich
sonst der Kommunikationsaufwand in unzumutbarer Weise erhöht.
Der Datenzugriff muß in den verscheidenen Betriebsarten einheitlich sein, damit die Betriebsarten für
die Anwendung transparent sind. Zusätzlich soll der Datenzugriff möglichst einfach und übersichtlich
sein. Damit darf die Zahl der Komunikationsschnittstellen nicht zu stark ansteigen.
Wiederverwendbarkeit
Die fachlichen Anwendungskomponenten der Anwendung sollen wiederverwendbare Komponenten
bilden. Da die Anwendungskomponenten aber zur Bearbeitung Daten benötigen, ergeben sich
zwangsläufig Verbindungen zur Umwelt, die die Wiederverwendbarkeit nicht einschränken dürfen.
7.3.1.3. Kräfte
Kommunikation
Für die Übertragung der fachlichen Daten vom Server in die Oberflächenschicht sollen möglichst
kompakte Datenpakete geschnürt werden, damit die Anzahl der Serverzugriffe gering gehalten wird.
Aufgrund dieser Anforderung und der Anforderung für den einfachen Zugriff auf diese Daten bietet
sich die Übertragung der Daten in Form von Kopieren der BO’s über das Netz an. Dabei werden die
BO’s automatisiert serialisiert und übertragen. Wird ein BO übertragen, so werden automatisch auch
alle Objekte übertragen, auf die von dem betreffenden BO referenziert werden. Zumeist werden diese
referenzierten Objekte aber in der View nicht benötigt. Es werden folglich zu viele Daten übertragen.
Es muß darauf geachtet werden, daß die Menge der übertragenen Daten in einem gesunden Verhältnis
zu der Anzahl der Server-Zugriffe stehen. Dabei gilt in der Tendenz, daß die übertragenen Daten grö© GDV 2001
173
Anhang
ßer sein dürfen, sofern dadurch Server-Zugriffe eingespart werden können, da jeder einzelne ServerZugriff einen nicht zu unterschätzenden Protokolloverhead erzeugt.
Business Objects
Die Übertragung der BO’s ermöglicht einen einfachen und komfortablen Zugriff auf die fachlichen
Daten. Damit die BO’s für den Client-/Server-Betrieb möglichst klein sind, dürfen die BO’s nur wenig
Logik enthalten. Sie dürfen insbesondere keine Funktionalitäten beinhalten, die zur Ausführung Funktionalitäten des Servers aufrufen, da diese auf dem Client nicht verfügbar sind. Damit werden die
BO’s im Extremfall zu einfachen „Datenhaltern“, während die Fachlogik in anderen Anwendungsbereichen untergebracht wird.
Schnittstellen
Für den Zugriff der Oberflächenschicht auf den Server muß eine Zugriffsmöglichkeit definiert werden,
die von der reinen Netzwerkfunktionalität abstrahiert. Dafür bietet sich CORBA an.
CORBA definiert für alle entfernten Zugriffe Schnittstellen, sogenannte Interfaces, über die der Zugriff erfolgen kann. Für die spezifischen Serverfunktionalitäten bedeutet das, daß in der Implementierung jeweils Interfaces für den Zugriff des Client zu erzeugen sind. Nach kurzer Zeit kann die Anzahl
der spezifischen Interfaces eine Größenordnung erreichen, die die Übersichtlichkeit verringern und
den Verwaltungsaufwand erhöhen.
Alternative ist ein einheitliches generisches Interface, daß die gesamte Kommunikation zwischen der
Oberfläche und dem Server abdeckt. Dabei geht aber die Typsicherheit sowohl für den Aufruf als auch
für die Übergabeparameter verloren.
Wiederverwendbarkeit
Wiederverwendbare Komponenten gehen davon aus, daß keinerlei Informationen über den Kontext, in
dem sie sich befinden in der Komponente enthalten sind.
Benötigt eine wiederverwendbare Komponente während ihrer Ausführung Daten oder Services, die sie
nur vom Kontext erhalten kann, ergibt sich automatisch eine Abhängigkeit vom Kontext.
Eine vollständige Unabhängigkeit erhält man nur, wenn die Komponente Daten oder Services zur
Verfügung gestellt bekommt, und sie sie nicht aktiv ermittelt. Dies erhöht aber den Verwaltungsaufwand des Kontextes und schränkt die (automatisierbare) Funktionsweise der Komponente ein.
174
© GDV 2001
Anhang
7.3.1.4. Lösung
Das nachfolgende Schaubild stellt die wesentlichen Elemente der Architektur dar:
V e r w a ltu n g
m a in ( )
A p p le t
L ogIn /
L o g In F ram e
S ta r t
A n w en d u n g
G U IF a c to ry
S e rv e r
V ie w
V ie w
C li e n t
S erver
A c tiv ity
G U IF a c to ry
m a in ( )
L ogIn
S erv er /
C o n n e c tio n
A p p lic a tio n
A c tiv ity
B u s in e s s P r o c e s s
M anager
B u s in e s s P r o c e s s
D a ta b a s e
M anager
B u s in e s s
O b je c t
B u s in e s s
O b je c t
B u s in e s s
O b je c t
D a te n b a n k
Abb. 1 Architektur archid
Auf der linken Seite sind die Elemente, die verwaltenden Charakter haben, dargestellt. Diese Objekte
existieren im System nur einmal und haben die Aufgabe, die anderen Objekte zu verwalten.
Auf der rechten Seite sind die Objekte dargestellt, aus denen die eigentliche Anwendung besteht. Bei
diesen Objekten stellt die Architektur die Basisklassen oder Interfaces bereit. Die fachlichen Inhalte
müssen in Ableitungen oder konkreten Ausprägungen implementiert werden.
Der untere Teil der Abbildung enthält die Elemente, die auf einem Applicationserver eingesetzt werden, der obere Teil die Elemente des Clients. Im "Standalone-Modus" liegen alle Objekte auf dem
selben Computer und werden auch von der gleichen Virtuellen Maschine (JVM7) ausgeführt.
Verwaltungsobjekte
Im folgenden sind nur die für die Unterstützung der Oberflächenschicht notwendigen Elemente näher
beschrieben.
GUIFactory:
Die GUIFactory dient dazu, zu jeder Activity die dazugehörige View zu finden. Dazu hält die
GUIFactory eine Liste aller Activities und der dazugehörigen Views. Sie zeigt die Views allerdings nicht selber an, sondern überläßt diese Aufgabe dem GUIFactoryServer, der auf der ClientMaschine läuft.
GUIFactoryServer
Der GUIFactoryServer existiert in der Präsentationsschicht und wird von der GUIFactory ange-
7
Java virtual machine
© GDV 2001
175
Anhang
sprochen, wenn eine Activity eine View erzeugen möchte. In diesem Fall erhält der GUIFactoryServer den Namen der View, die er dann erzeugt und darstellt.
Außerdem verwaltet der GUIFactoryServer die Liste aller aktiven Views und die Beziehung zu
deren "Vater"-Views.
Anwendungselemente
Activity / ActivityProvider
Eine Activity enthält fachliche Logik und stellt eine wiederverwendbare Komponente mit exakt
umrissenen Aufgabenbereich dar.
Die Activity erzeugt über die GUIFactory ihre dazugehörige View und wird ab dann von dieser
aus aufgerufen. Sie stellt dazu ein einheitliches generisches Interface zur Verfügung, daß für alle
Activities gilt, damit die spezifischen Activities kein eigenes Interface definieren müssen, und die
Netzwerkanbindung transparent ist.
Eine Activity muß keine View haben wenn sie zum Beispiel nur eine Berechnung durchführt.
Eine Activity ist so implementiert, daß sie die Klasse, von der sie aufgerufen wird, nicht kennen
muß. So ist gewährleistet, daß sie in einem anderen Zusammenhang vollständig einsetzbar ist.
Allerdings ist es notwendig, daß eine Activity von ihrem "Kontext" (also in diesem Fall dem
BusinessProcess) Daten nachfragen kann. Daher gibt es zu jeder Activity ein ActivityProviderInterface, das die Methoden enthält, die die Activity in ihrem Kontext aufrufen möchte. Dieses
Interface muß von der aufrufenden Klasse implementiert werden. Die Activity greift also nur über
das ActivityProvider-Interface auf den Kontext zu.
Das Konzept des ActivityProviders ist an dem Observer-Design-Pattern angelehnt und entspricht
grundsätzlich der Listener-Logik seit JDK 1.1: Das Listener-Interface definiert eine Schnittstelle
für alle Klassen, die sich für Informationen aus dem Source-Objekt interessieren. Alle Klassen, die
diese Informationen bekommen wollen, müssen das Listener-Interface implementieren und sich
beim Source-Objekt anmelden.
Im Falle des Activity-Providers ist die Activity das Source-Objekt. Es definiert das Interface für
alle, die diese Activity verwenden wollen. Dies können Business-Prozesse oder übergeordnete
Activities sein. Diese müssen das Interface für die Activity implementieren. Der Unterschied zu
Listenern liegt darin, daß jeder Aufrufer einer Activity automatisch als ‚Listener‘ angemeldet
wird, und daß es pro Activity nur einen ‚Listener‘ in Form des Providers gibt.8 Ein weiterer Unterschied ist der, daß die Methoden des ActivityProviders Rückgabewerte haben können, was bei
Methoden eines Listeners nicht der Fall ist.
Das jeweilige Provider-Interface ist spezifisch für diese Activity. Die Activity greift über das Interface auf Daten der übergeordneten Komponente zu und kann sich so selbständig mit den erforderlichen Daten versorgen. Dies hat Vorteile, wenn Activity-Daten erneuert werden müssen, da
sich Daten geändert haben. Den Zeitpunkt für den Refresh kennt nur die Activty, nicht die übergeordnete Komponente. Durch den Provider kann sich die Activity zu jedem Zeitpunkt die benötigten Daten holen ohne die übergeordnete Komponente zu benachrichtigen. Dadurch, daß die
Activity nicht auf die übergeordnete Komponente (BusinessProcess oder Activity) direkt zugreift,
sondern nur auf den jeweiligen Provider ist die Unabhängigkeit der Activity von der übergeord8
Auch im Event-Konzept des JDK gibt es das Konzept des unicast-Events, das nur an einen Listener geht.
176
© GDV 2001
Anhang
neten Komponente gewährleistet.
Activities können als wiederverwendbare Einheiten auch Bestandteil weiterer Activities sein. In
diesem Kontext sind sie Subactivities ihrer übergeordneten Activity. Die aufrufende Activity muß
lediglich das ActivityProvider-Interface der aufgerufenen Activity implementieren. Eine Activity
kann aus mehreren Subactivities bestehen, die die fachliche Funktionalität beinhalten, sie selbst
dient nur als Gruppierungsmechanismus. Damit wird die Implementierung neuer fachlicher Funktionalitäten durch Zusammenstellen von verschiedenen Activities nach dem Baukastenprinzip
möglich. Da mit den Subactivities auch Views verbunden sein können, muß auch die Einbindung
der Subviews in die übergeordnete View ermöglicht werden.
View
Eine View ist eine Klasse, die einen Dialog oder einen Teil eines Dialoges darstellt und bearbeitet.
Die View enthält nur so viel fachliche Funktionen, wie aus Performacegründen notwendig ist. Für
alle anderen Funktionen ruft die View Methoden der Activity auf und benutzt deren Rückgabewerte. Die Activity ist der „fachlliche Controller“ der View.
Die Event-Verarbeitung erfolgt innerhalb der View, d.h. der „Oberfächencontroller“ ist Bestandteil der View, und nicht extrahiert (vor allem nicht auf den Server), um die Netzzugriffe einzuschränken.
Eine View kann weitere Views verwenden, die sie allerdings nicht selber erzeugt, sondern sich
von der Activity erzeugen läßt.
Business Object
Business Objects sind, wie im allgemeinen Sprachgebrauch üblich, die Abbildung der fachlichen
Datenstrukturen. Das BO enthält genau die Datenfelder (Attribute), die zu einem fachlichen Objekt (Angebot, Person, Adresse etc.) gehören.
Zusätzlich werden im BO auch Funktionen (Methoden) definiert, die auf diesen diesen Daten operieren (Plausibilitäten, Berechnungen, Initialisierungen usw.). Damit sind Funktionalitäten, die für
das BO gelten, unabhängig von der jeweiligen Programmsituation.
In archid werden Business Objects zur Übertragung der Daten von der Activity zur View benutzt. Im C/S – Modus geschieht diese Übertragungen über die CORBA – Schnittstelle. Wird ein
BO übertragen, so werden automatisch auch alle Objekte übertragen, auf die von dem betreffenden BO referenziert werden.
Um die Datenübertragungsmenge zu minimieren, werden alle nicht benötigten Objekt-Referenzen
abgeschnitten und nur die Rohdaten, die sogenannten „Kerndaten“ übertragen. Jedes BO muß dafür die Methoden setKerndaten/getKerndaten implementieren.
7.3.1.5. Implementierungsumgebung
Das archid-Framework ist in Java implementiert, um Portabilität und Web-Unterstützung zu gewährleisten.
Java hat sich als gut strukturierte und robuste Programmiersprache erwiesen, die in zunehmendem
Maß durch entsprechende Klassenbibliotheken umfangreich ergänzt wird.
© GDV 2001
177
Anhang
Für die Kommunikation zwischen View und Activity sind wahlweise CORBA (Visigenic Visibroker
als ORB) und RMI einsetzbar. Beide Varianten erwiesen sich für diesen Anwendungszweck als robust
und performant genug.
Das Framework hat gezeigt, daß es sowohl im Standalone, als auch im Client-/Server-Betrieb performant läuft. Der reine Web-Betrieb ist aber für den Endanwender noch unbefriedigend, da die neuesten
Java-VM’s noch nicht standardmäßig in den Browsern enthalten sind, und damit umfangreiche Klassenbibliotheken oder ganze VM’s (in Form eines Plu-gIn) heruntergeladen werden müssen. Dies erfordert erhöhte Start-Wartezeiten für den ersten Betrieb. Denkbar ist hier, statt der Oberfläche (View)
in Form eines Applet HTML-Seiten einzubinden.
Im Intranet-Bereich ist die WEB-Variante aber dank möglicher Vorinstallationen der VM gut einzusetzen. Hierbei sollte aber beachtet werden, daß diese Umgebung nicht für die Versorgung von sehr
vielen Clients (größer 20) ausgelegt ist. Für diese Versorgung sollten mehrere Applikationsserver parallel zur Verfügung gestellt werden. Ein Load-Balancing kann dann über die Middleware efolgen.
7.3.2. Beispiel Präsentation ORACLE: Oracle Business Components for
Java
Das Beispiel von ORACLE für heutiges GUI-Design ist die Realisierung im Rahmen des Business
Components for Java (BC4J) Frameworks.
BC4J ist ein Komponenten-Framwork für die Programmiersprache Java. Objekte wie beispielsweise
Geschäftsregeln werden auf einer Meta-Ebene durch XML beschrieben. Die Anpassung und Konfiguration dieser Objekte läßt sich auf der XML-Ebene ohne Eingriff in den Java-Code vornehmen.
7.3.2.1. Konzepte
Entity Object
Entity Objects bilden eine Abstraktion der Information vor technischen Diensten wie Datenzugriff
(JDBC), Caching etc. und erleichtern so die Kommunikation mit einem DatenbankManagementsystem für den Anwendungsentwickler. Über den Business Component Typ Association
lassen sich verschiedene Entity Objects in Beziehung setzen und traversieren.
An einzelne Attribute eines Entity Objects können vordefinierte Validierungsregeln (Business Component Typ Validation Rules) angehängt werden. Komplexere Validierungsregeln (z.B. korrektes
Format einer Telefonnummer) lassen sich mittels Domains (separater Business Component Typ) umsetzen.
View Object
View Objects stellen verschiedene Sichten (Filterungs-, Sortierungsmechanismen) auf die Informationen bereit, die sich je nach Einsatz in Application Moduln zusammenstellen lassen.
View Links Objekte spezifizieren Beziehungen zwischen verschiedenen View Objects.
Application Module
178
© GDV 2001
Anhang
Ein Application Module ist ein logischer Container für Instanzen von View Objekten und View Links.
Geschäftslogik die sich aus Entity und View Objekten zusammensetzt lassen sich in Application Moduln zusammenfassen, die wiederum als EJB- oder CORBA-Komponente in die Laufzeitumgebung
(z.B.: Application Server oder Data Server) verteilt werden kann.
View
Objekt
Applikationsmodul
Auftragserfassung
Kunde
View Link
Auftrag
Entity
Objekt
Kunde
Assoziation
Auftrag
Abbildung 81: Beispiel Auftragserfassung
Benutzeroberfläche
Ein gutes Design sollte jede Art von Repräsentation und GUI ermöglichen ausgehend von den Nutzeranforderungen. So soll die grafische oder akustische Repräsentation unabhängig vom Endgerät (PC,
Laptop, Mobiletelefon, Palmtop, Telefon) möglich sein.
Die Darstellung von Informationen für den Anwender am Client basiert auf der Repräsentation durch
HTML, Java oder auch XML.
Vor allem darstellungsunabhängig in XML repräsentierte Information läßt sich durch geeignete XSL
Transformationen mittels entsprechender Stylesheets in beliebige Repräsentation bringen (HTML,
Sprache, WML, Word etc.). Das Oracle XML Developer Kit (XDK) stellt Basisfunktionalitäten für
die XML-Verarbeitung bereit (technet.oracle.com/tech/xml/).
Technologien die heute ihren Einsatz finden sind beispielsweise im Bereich Java die Servlets oder
auch Java Server Pages (JSPs) die Informationen in einen HTML-Strom umwandeln und an den Client
weiterleiten. Auch lassen sich die GUI-Designelemente die Java mit den Swing-Klassen bietet nutzen.
© GDV 2001
179
Anhang
Abbildung 82: Flexible Benutzeroberflächen
7.3.2.2. Beispiel Kopplung ORACLE: Oracle Integration Server
Kopplung bzw. Integration ist ein komplexes Gebiet welches aus verschiedenen Blickwinkeln zu betrachten ist. Ein wichtiger Aspekt ist die Motivation die hinter dem Wunsch auf Integration von Systemen steckt. Häufig geht es darum, ein existierendes System, daß eine bestimmte Funktionalität
bietet in ein neues Gesamtsystem zu integrieren. Hierbei wäre die Neuentwicklung zu kostenintensiv
oder zu zeitaufwendig. Was letzten Endes angestrebt wird ist die Integration der Teilprozesse des bestehenden Systems in den Gesamtprozess. Von IT werden allerdings häufig nur die Systemaspekte
betrachtet.
Letztendlich ist ein evolutionärer Ansatz welcher sauber zwischen den Chancen und Risiken abwägt
der einzige der in der Realität tragfähig und akzeptabel ist. Ein System das heute eine bestimmte
Funktionalität als Dienst erbringt soll sich zukünftig bei Bedarf durch ein neues Teilsystem ersetzen
lassen.
Häufig geht es darum die internen und externen Prozesse des Unternehmens vollständig zu automatisieren und damit zu beschleunigen, neue Prozesse für neue Vertriebskanäle zu etablieren oder interne
Prozesse nach Außen abzubilden. Dabei finden offene Internet-Technologien ihre Anwendung.
Außerdem läßt sich unterscheiden zwischen taktischer Integration die ein spezifisches Teilproblem
löst und strategischer Integration zur Neuausrichtung der IT auf flexible Geschäftsprozesse.
180
© GDV 2001
Anhang
Application
Adapter
Application
Spoke
Application
Adapter
Adapter
Spoke
Spoke
XML-Dokument
Hub
Abbildung 83: Hub-and-Spoke Architektur
Bei der Integration lassen sich grundsätzlich drei Ebenen unterscheiden:
•
Daten-
•
Komponenten (Anwendungs)-
•
(Geschäfts)-prozessintegration
Jede dieser Ebenen nutzt andere Sichtweisen und Technologien zur Umsetzung und findet in anderen
Szenarien sein Einsatzgebiet.
Prozess
Integration
Messaging,
Business Events
Komponenten Integration
RPC, CORBA, COM, Java RMI
Daten Integration
Gateways, Replication, Database Events
Abbildung 84: Integrationsmechanismen
Topologien für die Integration sind ein Hub-and-Spoke Ansatz oder der Bus-Ansatz.
© GDV 2001
181
Anhang
Integrationsstack
Für eine flexible Integration ist eine Anzahl von Funktionalitäten notwendig die sich durch einen
Stack darstellen lassen.
Integration Server
Business Process Intelligence
Geschäftsprozessmodellierung
Prozess Management
Transformations Technologie
Business Event Management
Kommunikation/Adapter
Abbildung 85: Integrationsstack
Beim Kommunikationsmodell läßt sich zwischen synchronen (enge Kopplung) und asynchronen (lose
Kopplung) Mechanismen unterscheiden. Synchron wäre etwa ein Aufruf über RPC. Asynchron wäre
der Informationsaustausch auf Basis von Nachrichten (Messages).
Interfacemechanismen
Nach dem Pull-Modell lassen sich hier Dienste (Methoden, Argumente) beschreiben die ein Objekt
auf Anfrage leistet. Dieses Modell findet sich bei OMG CORBA bei den IDL-Interfacebeschreibung
oder beim Komponentenmodell von J2EE Enterprise JavaBeans durch das Remote Interface.
Beim Push-Modell ist das System aktiv in der Lage Informationen sobald sie entstehen, an andere
Systeme die sich für diese Information interessieren aufgrund von entsprechenden Abonnements (inhalts- oder themenbasiert) weiterzugeben.
Transformation
Für die Umwandlung von Informationen zwischen verschiedenen Systemen ist häufig eine Transformation notwendig. Objekte werden verschieden modelliert. Daten verschieden repräsentiert und formatiert. Eine mögliche Technologie ist die semantische Transformation mittels XSLT (Extensible
Stylesheet Language Transformations, siehe auch: www.w3.org/TR/xslt) die verschiedene XMLDokumente ineinander überführen kann.
182
© GDV 2001
Anhang
Adapter
Zur Integration werden Adapter eingesetzt die auf bestimmte Anwendungen/Protokolle zugeschnitten
sind und nur noch konfiguriert werden müssen. Der Einsatz ist vor allem dann sinnvoll, wenn eine
Entwicklung zeitkritisch ist.
Business Event Modellierung
Ein Business Event (Geschäftsereignis) ist grundsätzlich eine Information (ein Geschäftsdokument
wie z.B. ein „Vertrag“) mit einem Ereignis (z.B. Vertrag „anbieten“).
Die Modellierung auf Basis der Business Events bietet den Vorteil, das sie domänenübergreifend und
auch technologieunabhängig tragfähig ist. Auch Prozesse mit Organisationseinheiten in deren Systeme
kein Eingriff möglich ist, lassen sich dadurch modellieren. Auch die OMG hat die Bedeutung von
Event-basierten Architekturen erkannt und im März 2000 ein entsprechendes RFP (Request for Proposal) veröffentlicht [OMG2000b].
Wesentlich dabei ist, daß die Verwaltung der Business Events von der Infrastruktur als Dienst bereitgestellt wird, um die hohen nichtfunktionale Anforderungen eines geschäftskritischen Systems zu
erfüllen. Dies wird bei Oracle durch die Implementierung eines Message Queuing Systems (Oracle
Advanced Queuing) innerhalb des Datenbank-Managementsystem Oracle8i gewährleistet (Business
Event Management). Dadurch lassen sich die bewährten Eigenschaften der Datenbank wie Transaktionsschutz, Backup, Recovery, Sicherheit, Hochverfügbarkeit und Skalierbarkeit auf das Management
von Business Events übertragen. Dies spielt bei zukünftigen automatisierten Geschäftsprozessen zwischen einem Versicherungsunternehmen und seinen Partnern, wobei Millionen von geschäftsrelevanten Ereignissen verwaltet, dokumentiert und analysiert werden müssen, eine wesentliche Rolle für eine
stabile und kosteneffiziente Umsetzung.
Einsatzgebiet kann zum einen die interne Integration von Systemen sein. Auch die externe Integration
wie etwa bei der VU - Endkunden Beziehung, oder zwischen Unternehmen (z.B. für VU - Rückversicherer, VU - Banken Beziehungen) im Bereich Business-to-Business (B2B) läßt sich dadurch realisieren.
Information Interface
Grundsätzlich erfolgt die Integration durch den Austausch von Informationen (Information Sharing).
Dies läßt sich heute auf Basis von semantisch abgestimmten in XML-kodierten Dokumenten (z.B.
Vorgangsakte, Vertrag) sowie standardisierten domainspezifischen regionalen Prozessen (beispielsweise Prozesse für Versicherungen in Deutschland) durchführen. Beispiele für die Spezifikation von
solchen Dokumenten (Business Object Documents, BOD) sind die Definitionen der Open Applications Group (www.openapplications.org). Beispiele für die Definition von Prozessen wären etwa die
Partner Interface Processes (PIP) von RosettaNet (www.rosettanet.org).
Ein wichtiger Teilaspekt dabei sind die nichtfunktionalen Eigenschaften eines Systems (Performance,
Skalierbarkeit, Verfügbarkeit, Ausfallsicherheit). Diese beeinflussen die Lösungsrealisierung entscheidend.
© GDV 2001
183
Anhang
Um etwa performant Informationen über ein größeres Informationsobjekt bereitzustellen bietet sich
das Design eines Information Interface an. An dieser Schnittstelle wird etwa ein Produktobjekt komplett als ein in XML repräsentiertes Dokument (z.B. ein Vertrag) übergeben, um zu vermeiden, das die
Information über Dutzende von Aufrufen bestehend aus einer Vielzahl von Einzelaufrufen über eine
unübersichtlich breite Schnittstelle zusammengestellt werden muß.
Wesentlich für den Erfolg eines solchen Integrationsansatzes ist die Einigung auf die Struktur dieser
Dokumente innerhalb einer Versicherungsorganisation (zwischen Abteilungen) aber auch zwischen
VUs und weiteren Partnern.
Operations
Mgmt
Analyse
Tools
Anwendungen
Prozess
Management
Kommunikation (wie ?)
In nachfolgender Abbildung sind zusammenfassend die wesentlichen funktionalen Komponenten einer
tragfähigen Integrationsarchitektur dargestellt.
Business Event Management
(Was wurde kommuniziert ?)
Partner Informationen (Präferenzen etc.)
(Directory Service)
Abbildung 86: Architekturelemente für die Integration
184
© GDV 2001
Literatur
8. Literatur
[oFRM01] „Das objektorientierte fachliche Referenzmodell“, Version 2.0, März 2001, GDV
[OMG98a] Object Management Group: „CORBAservices: Common Object Services Specification“, Updated
Edition, Dezember 1998
[OMG95] Object Management Group : „Common Facilities Architecture“, Revision 4.0, November 1995
[GDV99] „Die Anwendungsarchitektur der Versicherungswirtschaft - Grundlagen und Prinzipien“, GDV, 1999
[Meta98] „CORBA vs. DCOM“, Meta Group Consulting, March 20, 1998
[Orfali98] R.Orfali u.a. „Client/Server Programming with Java and CORBA“, 2nd Edition, John Wiley & Son
1998
[OMG98c] Object Management Group : „Interoperability Specification“, OMG Business Domain Task Force,
BODTF-RFP 1 Submission, Feb. 5, 1998
[BOCA98] Object Management Group : „Business Object Component Architecture (BOCA)“, Revision 1.1,
OMG Business Domain Task Force, BODTF-RFP 1 Submission, OMG document bom/98-01-07, 1998
[OMG97] Object Management Group : OMG document orbos/97-11-24, 1997
[OMG99] Object Management Group: CORBA Components, Joint Revised Submission 1999
[iX2000] „Episode 3“ – CORBA 3, Teil 1, Komponenten, i’X 04/2000, Heise Verlag 2000
[Stal99] Michael Stal: „Des Knaben Wunderhorn“, Objekt Spektrum 01/1999
[Szyp98] Clemens Szyperski : “Component Software : Beyond Object Oriented Programming”, AddisonWesley 1998
[Eeles98] Peter Eeles, Oliver Sims : «Building Business Objects », John Wiley & Sons 1998
[SUN00] Enterprise JavaBeans Specification, Version 2.0, www.javasoft.com/products/ejb/docs.html
[IBM] „IBM SanFrancisco Project Technical Summary“, www.ibm.com/java/Sanfrancisco/technical.html, IBM
[WfMC94] The Workflow Reference Model, Version 1.1., 1994, WfMC-TC-1003
[WfMC96a] WfMC: Workflow Client Application Programming Interface (WAPI) Specification, Version 1.2,
1996, WfMC-TC-1009
[WfMC96b] WfMC: Workflow Interoperability - Abstract Specification, Version 1.0, 1996, WfMC-TC-1012
[WfMCc] WfMC: Audit Data Specification, WfMC-TC-1015
[Sch+98] W. Schulze u.a.: Standardising on Workflow-Management - The OMG Workflow Management Facility, ACM SIGGROUP Bulletin, Vol. 19 (3), April 1998
[Sch98] W. Schulze: Relationship of Business Objects and the Workflow Facility, BODTF-Präsentation beim
OMG Technical Meeting, Tampa, Jan. 1997
© GDV 2001
185
Literatur
[OMG98b] Object Management Group: OMG BODTF RFP #2 Submission Workflow Management Facility,
OMG Document bom/98-06-07
[OOPS97] OOPSLA ´97 Workshop on Business Object Design and Implementation III, OOPSMessanger,
ACM/SIGPLAN 1998 ( www.jeffsutherland.org/oopsla97/oo97final.html )
[OMG2000] Object Management Group: Workflow Resource Assignment Interfaces (RAI), Request For Proposal, OMG Document bom/2000-01-03
[Bal96] Balzert, Helmut: Lehrbuch der Software-Technik: Software-Entwicklung, Spektrum Akad. Verlag, 1996
[Fow+97] Fowler, Martin with Kendall, Scott: UML Distilled, Addison Wesley, 1997
[OMG98] Object Management Group: Suggested Revisions to Activity Models for Business Process Modelling,
OMG Document ad/98-06-13
[Bal96] Balzert, Helmut: Lehrbuch der Software-Technik: Software-Entwicklung, Spektrum Akad. Verlag, 1996
[Fow+97] Fowler, Martin with Kendall, Scott: UML Distilled, Addison Wesley, 1997
[Har87] Harel, D.: Statecharts: A Visual Formalism for Complex Systems, in: Science of Computer Programming, Elsevier Science Publishers, 1987
[Fowl97] Martin Fowler, „Analysis Patterns“, Addison-Wesley, Reading Massachusetts 1997
[PLoP2000] N.Harrison, B.Footh, H.Rohnert (Eds) : „Pattern Language of Program Design 4“ (PloP 4),
Addison-Wesley 2000
[Mart2000] Didier Martin usw.: “Professional XML”, Wrox Press, Birmingham 2000
[PLoP95] J.Coplien, Douglas C.Schmidt (Eds): „Pattern Languages of Program Design 1“ (PloP 1), AddisionWesley 1995
[Busch98] F. Buschmann u.a : „Pattern-orientierte Software-Architektur“, 1998
[Wann99] „Wiederverwendung von Softwarekomponenten durch entkoppelte Schnittstellen“, G. Wanner & K.D. Jäger in OBJEKTspektrum 1/99
[Orfali97] Orfali, Harley, Edwards: „Abenteuer Client/Server“ Addison-Wesley 1997
[Orfal98b] Orfali, Harley, Edwards: „Instant CORBA“, Addison-Wesley, Bonn 1998
[Mow97] T. Mowbray, W. Ruh: „Inside CORBA“, Addison-Wesley 1997
[Orfali96] Orfali, Harkey, Edwards: „The Essential Distributed Object Survival Guide“, John Wiley & Sons
1996
[Gamma96] E.Gamma, Helm, Vlissides, Johnson „Entwurfsmuster“, Addison-Wesley, 1996
[OMG2000b] Object Management Group: UMLTM Profile for Event-based Architectures in Enterprise Application Integration (EAI), OMG Document: ad/2000-03-07, 2000
186
© GDV 2001