Das Objektorientierte Technische Referenzmodell - GDV
Werbung
VAA 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 Das Objektorientierte Technische Referenzmodell 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 http://www.gdv.de/vaa Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell ü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 http://www.gdv.de/vaa neu neu © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 ..................................................... 91 3.5. Kopplung von Systemen ................................................................................................... 93 3.5.1. Entkopplung und Anpassung von Funktionalität ........................................................ 94 3.5.2. Anpassungen der System- bzw. technischen Architektur .......................................... 94 4. Architekturmodelle im Überblick ......................................................................... 98 4.1. Einordnung ........................................................................................................................ 98 4.2. OMG Vorschläge zur Business Object Architecture ......................................................... 99 4.2.1. Architekturziele und Kontext....................................................................................... 99 4.2.2. Grundmuster der Architektur .................................................................................... 100 4.2.2.1. Definitionen ........................................................................................................ 100 4.2.2.2. Services ............................................................................................................. 103 4.2.2.3. BO- und Type-Manager Interfaces .................................................................... 104 4.2.2.4. Shared Services ................................................................................................ 111 4.2.3. Wertung .................................................................................................................... 114 4.3. IBM San Francisco .......................................................................................................... 114 4.3.1. Architekturziele und Kontext..................................................................................... 114 4.3.2. Grundmuster der Architektur .................................................................................... 115 4.3.2.1. Foundation Layer ............................................................................................... 116 4.3.2.2. Common Business Objects Layer (CBOs) ........................................................ 118 4.3.2.3. Core Business Processes Layer ....................................................................... 118 4.3.3. Wertung .................................................................................................................... 120 4.4. Enterprise JavaBeans ..................................................................................................... 120 4.4.1. Architekturziele und Kontext..................................................................................... 120 4.4.2. Grundmuster der Architektur .................................................................................... 121 4.4.2.1. Komponente ...................................................................................................... 121 4.4.2.2. Container ........................................................................................................... 121 4.4.2.3. Das Komponentenmodell .................................................................................. 121 4.4.2.4. Granularität der Komponenten .......................................................................... 121 4.4.2.5. Standardisierte Schnittstellen ............................................................................ 121 4.4.2.6. Anpassung ohne Änderung im Source Code .................................................... 122 4.4.3. Enterprise JavaBeans Komponentenmodell ............................................................ 122 4.4.3.1. Implizite Services ............................................................................................... 122 4.4.3.2. Portabilitätsschicht ............................................................................................. 122 4.4.3.3. Ausführung der Services ................................................................................... 123 4.4.4. Detaillierte Beschreibung der EJB Architektur ......................................................... 123 ii © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 4.4.4.1. Transiente und persistente Objekte .................................................................. 124 4.4.4.2. Naming und Registry ......................................................................................... 124 4.4.4.3. EJB Objektschnittstelle ...................................................................................... 125 4.4.4.4. Deklarierte Attribute ........................................................................................... 125 4.4.4.5. Kontext Objekt und Environment Objekt ........................................................... 125 4.4.5. Beschreibung der Services ...................................................................................... 125 4.4.5.1. Distribution Services .......................................................................................... 125 4.4.5.2. State Management ............................................................................................ 126 4.4.5.3. Persistence Management .................................................................................. 126 4.4.5.4. Transaction Management .................................................................................. 127 4.4.5.5. Security .............................................................................................................. 128 4.4.6. Enterprise JavaBean Deployment ........................................................................... 128 4.4.7. Wertung .................................................................................................................... 129 5. Ausblick ............................................................................................................... 130 6. Glossar ................................................................................................................ 131 7. Anhang ................................................................................................................ 137 7.1. Charakterisierung der einzelnen CORBA-Services ........................................................ 137 7.1.1.1. Life Cycle Service .............................................................................................. 137 7.1.1.2. Naming Service ................................................................................................. 138 7.1.1.3. Relationship Service .......................................................................................... 140 7.1.1.4. Persistence Service ........................................................................................... 143 7.1.1.5. Transaction Service ........................................................................................... 145 7.1.1.6. Concurrency Service ......................................................................................... 148 7.1.1.7. Trader Service ................................................................................................... 149 7.1.1.8. Collection Service .............................................................................................. 154 7.1.1.9. Property Service ................................................................................................ 156 7.1.1.10. Query Service .................................................................................................. 157 7.1.1.11. Security Service............................................................................................... 160 7.1.1.12. Externalization Service .................................................................................... 161 7.1.1.13. Event Service .................................................................................................. 164 7.2. Verfügbare CORBA Implementierungen und Services .................................................. 166 7.2.1. Cetus – Übersicht über verfügbare CORBA – ORBs .............................................. 166 7.2.2. CORBA Service Implementierungen ....................................................................... 171 7.3. Beispiele für Oberflächenanbindungen .......................................................................... 174 7.3.1. Das archid - Framework als Beispiel einer flexiblen Verteilung von Oberfläche und Anwendungslogik ............................................................................................................... 174 7.3.1.1. Kontext .............................................................................................................. 174 7.3.1.2. Probleme ........................................................................................................... 175 7.3.1.3. Kräfte ................................................................................................................. 175 7.3.1.4. Lösung ............................................................................................................... 177 7.3.1.5. Implementierungsumgebung ............................................................................. 179 7.3.2. Beispiel Präsentation ORACLE: Oracle Business Components for Java ................ 180 7.3.2.1. Konzepte ........................................................................................................... 180 7.3.2.2. Beispiel Kopplung ORACLE: Oracle Integration Server ................................... 182 8. Literatur ............................................................................................................... 187 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 Das Objektorientierte Technische Referenzmodell 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 ..................................................... 83 Abbildung 42: Kompatibilitätsebenen ......................................................................................... 84 Abbildung 43: Business Objects und Presentation Components ................................................. 85 Abbildung 44: Schichtenmodell für die Präsentationsanbindung................................................ 86 Abbildung 45: Beispiel einer Java-Presentation .......................................................................... 88 Abbildung 46: Beispiel einer HTML-Anbindung ....................................................................... 89 Abbildung 47: Konstruktionsprinzip von Präsentationen............................................................ 90 iv © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Abbildung 48: Fat Client ............................................................................................................. 91 Abbildung 49: Thin Client .......................................................................................................... 92 Abbildung 50: Ultra Thin Client ................................................................................................. 93 Abbildung 51: Beispiel einer Systemanbindung durch Fassaden und Adapter .......................... 95 Abbildung 52: Konvergenz der Architekturen ............................................................................ 95 Abbildung 53: Beispiel für die Anbindung eines Legacy – Systems .......................................... 97 Abbildung 54: Einordnung der betrachteten Architektur-Frameworks....................................... 99 Abbildung 55: Interaktion von Business System Domains ....................................................... 101 Abbildung 56: Interface Hierarchie für Business Objects und Type Managers ........................ 103 Abbildung 57: InterOp Services über verschiedene Komponenten .......................................... 104 Abbildung 58: Phasen des Commits im Transaction-Service (Interoperability Specification). 113 Abbildung 59: Ausblick auf die "Multi Layer Architecture" von San Francisco ..................... 115 Abbildung 60: Die San Francisco Architektur ......................................................................... 115 Abbildung 61: Kategorien von Common Business Objects (CBO-Layer) ............................... 118 Abbildung 62: Kern-Geschäftsprozesse in San Francisco ........................................................ 119 Abbildung 63 : Enterprise JavaBeans Container ....................................................................... 123 Abbildung 64: Konvergenz der Komponentenarchitekturen .................................................... 130 Abbildung 65: Beispiel für CORBA Naming Context .............................................................. 139 Abbildung 66: Beispiel für die Verwendung des Relationship Services .................................. 142 Abbildung 67: Beispiele für die Verwendung von "graphs-of-related-objects" ....................... 143 Abbildung 68: Komponenten des Persistence Service .............................................................. 144 Abbildung 69: Komponenten des Transaction Service ............................................................. 146 Abbildung 70: Beispiel CORBA Transaction Service .............................................................. 147 Abbildung 71: Locking Modes des Concurrency Services ....................................................... 149 Abbildung 72: Kommunikation zwischen Trader, Server und Client im Trader Service ......... 150 Abbildung 73: Beispiel Trader Service ..................................................................................... 153 Abbildung 74: Typen von Collections im Collection Service .................................................. 155 Abbildung 75: Beispiel für den Property Service ..................................................................... 157 Abbildung 76: Der CORBA Query Service .............................................................................. 158 Abbildung 77: Beispiel für eine Query mit dem QueryManager .............................................. 160 Abbildung 78: Prinzipieller Ablauf einer Berechtigungsprüfung in CORBA .......................... 161 Abbildung 79: Lesen und Schreiben von Objekten im Externalization Service ....................... 164 Abbildung 80: Beispiel für den Event-Service.......................................................................... 166 Abbildung 81: Beispiel Auftragserfassung .............................................................................. 181 Abbildung 82: Flexible Benutzeroberflächen ........................................................................... 182 Abbildung 83: Hub-and-Spoke Architektur .............................................................................. 183 Abbildung 84: Integrationsmechanismen .................................................................................. 183 Abbildung 85: Integrationsstack ............................................................................................... 184 Abbildung 86: Architekturelemente für die Integration ............................................................ 186 Tabellenverzeichnis Tabelle 1: Kategorien von CORBA-Components ....................................................................... 21 © GDV 2001 v Inhalt Das Objektorientierte Technische Referenzmodell Tabelle 2 : Kompatibilität der Dienste des BO-Frameworks und der CORBA Services ............ 35 Tabelle 3 : Ressourcenzuordnung................................................................................................ 51 Tabelle 4 : Beispiel für Stati einer Vorgangsakte ........................................................................ 54 Tabelle 5: Identity eines Business Objects (Interoperability Specification) .............................. 105 Tabelle 6: Life Cycle Operationen der Interoperability Specification ...................................... 107 Tabelle 7: State Access Operationen der Interoperability Specification ................................... 107 Tabelle 8: Intrinsic events (Interoperability Specification) ....................................................... 108 Tabelle 9: Bedingungen für das Auslösen von Events (Interoperability Specification) ............ 109 Tabelle 10: Bedingungen für die Übermittlung von Events (Interoperability Specification) ... 109 Tabelle 11: Interfaces des Query Service der Interoperability Specification ............................ 110 Tabelle 12: Introspection Interface (Interoperability Specification) ......................................... 111 Tabelle 13: Exception Categories (Interoperability Specification) ........................................... 111 Tabelle 14: Eigenschaften des Transaction Service (Interoperability Specification) ................ 112 Tabelle 15: Operationen des CORBA Naming Service ............................................................ 139 Tabelle 16: Eigenschaften von Diensten beim CORBA-Trader Service ................................... 150 Tabelle 17: Functional Interfaces des CORBA Trader Service ................................................. 152 Tabelle 18: Administration Interfaces des CORBA Trader Service.......................................... 153 Tabelle 19: Merkmale von CORBA Collections ....................................................................... 155 Tabelle 20: Interfaces des CORBA Property Service................................................................ 157 vi © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 8 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt ähnliche Begriffe. Die 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 • ... SystemArchitektur • CORBA Services • • Präsentation • Datenbanken 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 Das Objektorientierte Technische Referenzmodell 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 Systemarchitektur und technischer Architektur: 10 zwischen fachlichen Komponenten, © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Fachliches Referenzmodell Versionierbar (from LibraryPackage) IcisBasis (from LibraryPackage) 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 Referenzmodell 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 Object Request Broker 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 Das Objektorientierte Technische Referenzmodell Fachliches Referenzmodell Technisches 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 Das Objektorientierte Technische Referenzmodell 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 Anwendungssysteme spielt, insbesondere in desktop-orientierten Systemen. Entwicklung verteilter 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 Objektorientierte Technische Referenzmodell 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 Request Broker 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 CORBAServices 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 14 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt der Ebene der IDL-Schnittstellen beschrieben und nicht durch Angabe entsprechender Objektbeziehungen. Für die Implementierung existieren sogenannte Language Binding – Spezifikationen, die beschreiben, auf welche Weise IDL-Aufrufstrukturen und Datentypen auf die Strukturen der jeweiligen Programmiersprache abgebildet werden. Internet 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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-Language-Mapping existiert. Die Spezifikation eines Portable Object Adapters (POA) erlaubt den Einsatz von Komponenten auf unterschiedlichen ORB-Plattformen ohne Neugenerierung der Stubs und Skeletons. Bisher mußten Server-Komponenten für die ORBs unterschiedlicher Hersteller jeweils kompiliert und gebunden werden. POA legt in diesem Zusammenhang die Schnittstelle zwischen ORB, Adapter und den implementierten Objekten eindeutiger fest als dies in CORBA 2.0 der Fall war. Unter POA bleibt eine CORBA-Object Reference unabhängig davon gültig, ob das Server-Objekt aktiv ist oder nicht. Die Spezifikation von Schnittstellen für Internet-Firewalls ermöglicht die Überwachung und gegebenenfalls die Filterung der IIOP-Kommunikation in Netzwerken mit Zugang zum Internet. Das CORBA Component Modell und JavaBeans Die oben aufgeführten Erweiterungen des CORBA-Standadards (vgl. hierzu auch [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 © GDV 2001 17 Inhalt Das Objektorientierte Technische Referenzmodell Entwicklungswerkzeugen definierbar. Der CORBA Event Service definiert bisher zwar den grundlegenden Übertragungsmechanismus, trifft aber keinerlei Festlegung über die Art der Events, die ausgetauscht werden. Durch automatische Verknüpfung von Properties mit Events, wie sie in JavaBeans definiert sind, können zukünftig CORBA-Komponenten über Zustandsänderungen informiert werden, ohne daß die Verknüpfung zwischen Event und Zustandsänderung explizit programmiert werden muß. Durch die Integration von JavaBeans und CORBA ist die Integration von Komponenten in unterschiedlichen Sprach- und ORB-Umgebungen möglich. Komponenten sind nicht nur in Java-Umgebungen interoperabel, sondern auch in gemischten Umgebungen. Im CORBA 3.0 Component Model und in der POA-Spezifikation fehlen Spezifikationen für das Zusammenspiel zwischen Server-Komponenten und einem Transaktionsmanager (OTM). Diese Lücke wird durch das Container-Konzept von Enterprise JavaBeans geschlossen. Der Java Transaction Service (JTS) ist compatibel mit dem CORBA Object Transaction Service (OTS). Durch die Integration können JavaBeans die Dienstpalette und Netzwerkinfrastuktur von CORBA nutzen, einschließlich des verteilten Event Service, des Security Service und des IIOPProtokolls. Wertung Bereits vor dem Erfolg von Java wurde deutlich, daß wichtige Bereiche durch die bestehenden CORBA 2.0 Spezifikationen nicht abgedeckt wurden, insbesondere der Bereich 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 CORBAPlattformen 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 18 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt ● Erweiterung des Metamodells um einen Komponententyp ● 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 Das Objektorientierte Technische Referenzmodell equivalent interface CORBA-Component Receptacle facets Implementierung Implementierung event source 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üsselAttributen 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 Das Objektorientierte Technische Referenzmodell 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 EnterpriseJavaBeansSpezifikation. 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 EJBEntwicklungsumgebungen 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 Das Objektorientierte Technische Referenzmodell 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 22 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt können 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 © GDV 2001 23 Inhalt Das Objektorientierte Technische Referenzmodell 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. 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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. Abbildung 9: Konfiguration von Komponenten 26 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell EntityBO „Partnerrolle = VP“ EntittyBO „Vertrag“ Attribute •VN •Produkt •VersNr •Ablaufdatum •Prämienrechner Funktionen •getVersNr •getAblaufDatum •berechnePrämie EntityBO „Produkt“ Dependent Object „Prämienrechner“ berechne Abbildung 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Business Objects Beziehungen zwischen Relationship Service 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 © GDV 2001 35 Inhalt Das Objektorientierte Technische Referenzmodell des Business Objects, bevor die Ausführung einer Methode an das Business Object weitergeleitet wird. Für das Anwendungsprogramm ist das Proxy-Object völlig unsichtbar. Anwendung Business Object BOPersistenceService BO - Manager -Framework Proxy-Objekt Abbildung 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 BO-Manager - Frameworks). Das BO-Manager Framework übernimmt die Kommunikation mit dem Persistence Service. In diesem Fall muß das Business Object seinen Zustand in standardisierter Form dem BO-Manager zur Verfügung stellen, z.B. durch Implementierung einer serializeMethode. Der BO-Manager ist für die Generierung der Objektreferenz zuständig. Alternativ dazu ist auch die direkte Übergabe des Business Objects an den Persistence Service möglich, sofern dieser in der Lage ist, anhand von Meta-Informationen die Speicherung des Zustands selbst vorzunehmen (Persistence Framework). 36 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 BO-Manager - 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 Das Objektorientierte Technische Referenzmodell 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 40 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Business Objects zu erzeugen. Damit kann ein Business Object als „Single User“ - Objekt realisiert werden. 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: © GDV 2001 41 Inhalt Das Objektorientierte Technische Referenzmodell „Properties“ mit Standardzugriffsmethoden Properties sind Attribute von Business Objects, die von außen über spezielle Zugriffsmethoden gelesen bzw. geändert werden können. Die Zugriffsmethoden sind dabei universell und nicht BOspezifisch. In JavaBeans wird dies durch name patterns erreicht: zu einer Property mit dem Namen XXX gehören die Zugriffsmethoden getXXX bzw. setXXX. Durch Properties können nicht nur aktuelle Zustände eine Business Objects verändert werden, sondern auch dessen generelle Funktionsweise. „Active Properties“ Sogenannte „Active Properties“ lösen bei einer Wertänderung ein Event aus, das über 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 Das Objektorientierte Technische Referenzmodell 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. 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 Das Objektorientierte Technische Referenzmodell ● 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 47 Inhalt Das Objektorientierte Technische Referenzmodell durch spezielle 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 Das Objektorientierte Technische Referenzmodell 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 Activity-Objekten 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 Workflowereignissen. Die folgenden 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, Ressourcenzuordnungen markiert. das Registrierung Ereignistypen die Änderung von sind von 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 Das Objektorientierte Technische Referenzmodell 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 Die Zuordnung Bearbeiterrolle Die Zuordnung eines Users 50 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 einer Über eine Schnittstelle zu einem Berechtigungssystem 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 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). © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Tabelle 3 : Ressourcenzuordnung <<Interf ace>> ExecutionObject <<Interf ace>> Requester <<Interf ace>> Process <<Interf ace>> Activ ity PBO PostkorbAssignment <<Interf ace>> Assignment RollenAsignment Postkorb UserAssignment Rolle User <<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 Das Objektorientierte Technische Referenzmodell <<Interf ace>> Assignment <<Interf ace>> Activ ity Dialogsteuerung RollenAssignment UserAssignment User Rolle <<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 Das Objektorientierte Technische Referenzmodell aRequester : Requester aProcessMgr : Process Manager Inhalt aProcess : Process anActivity : Activity 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Objektorientierte Technische Referenzmodell 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 KomponentenArchitektur wie JavaBeans können diese Elemente als Bean-Properties definiert werden. 56 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Ermittelt Partner Erfaßt A.Daten Do: PBO11 aufrufen Exit: Ergebnis analys. [OK] Do: PBO12 aufrufen Exit: Ergebnis analys. Erfaßt Partner [n. vorh.] Do: PBO13 aufrufen Exit: Ergebnis analys. [OK] [vorh.] Prüft Risiko Ergänzt Partner [OK] Do: PBO14 aufrufen Exit: Ergebnis analys. Tarif-Komponente Do: PBO15 aufrufen Exit: Ergebnis analys. Tarifiert [OK] Do: PBO16 aufrufen Exit: Ergebnis analys. [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, © GDV 2001 57 Inhalt Das Objektorientierte Technische Referenzmodell nicht zu großen Menge 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 Das Objektorientierte Technische Referenzmodell 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 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 Das Objektorientierte Technische Referenzmodell (Transition) 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 Exit: Ergebnis analys. [OK] Do: PBO12 aufrufen Exit: Ergebnis analys. Erfaßt Partner [n. vorh.] Do: PBO13 aufrufen Exit: Ergebnis analys. [OK] [vorh.] Prüft Risiko Ergänzt Partner [OK] Do: PBO14 aufrufen Exit: Ergebnis analys. Do: PBO15 aufrufen Exit: Ergebnis analys. Tarifiert [OK] Do: PBO16 aufrufen Exit: Ergebnis analys. [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 4 Dieser Zustand könnte auch im Petri-Netz modelliert werden, dies ist allerdings im allgemeinen nicht notwendig. 60 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt versicherten 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 drucken. 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 © GDV 2001 61 Inhalt Das Objektorientierte Technische Referenzmodell Verschiedene Arbeitsplatzdrucker (Laser, Tinte, Außendienst, ...) Fax 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 62 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. © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Zusätzlich kann das Dokument noch dem Archivierungsdienst zur Speicherung übergeben werden. Dies ist abhängig von der Dokumentenklasse. 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 © GDV 2001 63 Inhalt Das Objektorientierte Technische Referenzmodell 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. 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 64 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 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. 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 Das Objektorientierte Technische Referenzmodell 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. Abbildung 33: Beispiel für die Berechtigungsprüfung auf dem Server 66 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Haftpflicht-Leistung) ● 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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: ○ Fehler_Text ○ Fehler_Daten TypBezeichnung, ObjectId ( des Objektes das den Fehler ausgibt ) 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 70 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt einen 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. © GDV 2001 71 Inhalt Das Objektorientierte Technische Referenzmodell Es ist in 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 72 ○ Fehler_Art ○ Fehler_Text ○ Fehler_Daten © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Schaden-Nr), 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 Das Objektorientierte Technische Referenzmodell 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 Dokumenten- stellt ein Management 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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 KEY VertragWIT TarifTarifKEY KEY TarifTarifBAT BAT TarifWIT TarifWIT Abbildung 39: interne Struktur für die Historisierung 80 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 Das Objektorientierte Technische Referenzmodell 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. 82 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Konfigurationswerkzeuge für Framework 1 Konfigurationswerkzeuge für Framework 2 Business Object Business Object Business Object Business Object Komponente 1 Business Object Komponente 1 Komponente 2 Business Object Komponente 2 BO - Manager - Framework 1 BO - Manager - Framework 2 • CORBA Services • Präsentation • Datenbanken Technische Dienste Object Request Broker Abbildung 41: Heterogene komponentenorientierte Systeme 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. © GDV 2001 83 Inhalt Das Objektorientierte Technische Referenzmodell 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 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. 84 © GDV 2001 Das Objektorientierte Technische Referenzmodell Presentation Component Business Object Business Object t Komponente 1 Inhalt Presentation Component Business Object Komponente 2 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 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: © GDV 2001 85 Inhalt Das Objektorientierte Technische Referenzmodell 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 einzelnen 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. 86 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 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. © GDV 2001 87 Inhalt Das Objektorientierte Technische Referenzmodell 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. 88 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 89 Inhalt Das Objektorientierte Technische Referenzmodell 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. 90 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 BO-Persistence Service 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. © GDV 2001 91 Inhalt Das Objektorientierte Technische Referenzmodell Presentation Presentation Componente Componente Business Business Object Object Thin Client Server BO-Manager Framework BO-Persistence BO-Persistence Service 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). 92 © GDV 2001 Das Objektorientierte Technische Referenzmodell Server Inhalt 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“. © GDV 2001 93 Inhalt Das Objektorientierte Technische Referenzmodell Ü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 94 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 95 Inhalt Das Objektorientierte Technische Referenzmodell 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: 96 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 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 97 Inhalt Das Objektorientierte Technische Referenzmodell 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 CORBAServices nicht nutzt, sind alternative Dienste und Kommunikationsmechanismen implementiert. Enterprise JavaBeans (EJB) dagegen beschränkt sich auf die Implementierung eines Frameworks für Business-Objects und Komponenten („Beans“) und ist „nach unten“ weitgehend kompatibel mit CORBA-Standards. Allerdings führt die EJB-Spezifikation eine Reihe neuer technischer Dienste ein, bzw. nutzt in manchen Fällen nur eine Untermenge der entsprechenden CORBA-Dienste. Alle drei Modelle lassen sich wie folgt in das Schema des technischen Referenzmodells der VAA einordnen: 98 © GDV 2001 Das Objektorientierte Technische Referenzmodell Business Object Architecture Inhalt San Francisco Fachliches Referenzmodell V ersionierbar (from LibraryP ackage) IcisB asis (from LibraryP ackage) Fachliche Komponentenmodelle Rolle 0..* S tandard P erson S tandard 0..1 * Rufnummer S tandard 0..1 anzuwendendeA nschrift 0..1 A nschrift 0..1 * anzuwendende P artner * B ankverbindung B ankverbindung0..1 0..1 V ersionierbar (from LibraryP ackage) IcisB asis (from LibraryP ackage) A ctor-Role -P attern V ersionierbarerA kteur Fachliche Komponentenmodelle Rolle 0..* S tandard P erson S tandard 0..1 * Rufnummer S tandard 0..1 JurP erson anzuwendendeA nschrift 0..1 A nschrift 0..1 * anzuwendende P artner * B ankverbindung B ankverbindung0..1 0..1 JurP erson V ertragsabhaengigerP artner 0..* S tandard S tandard V ertragsabhaengigerP artner Technisches Referenzmodell V ertragsabhaengigerP artner V ermittler V ermittler V ersicherungsnehmer P roduktpartner V ersicherte P erson V ersicherte P erson S onstigeP artnerrolle partn erart V ersicherungsnehmer P ostempfaenger V ersicherungsnehmer Business Objects und Komponenten P ostempfaenger B eitragszahler BOCA (OMG) SystemArchitektur Dienste Technische Architektur SystemArchitektur IBM San Francisco Business Objects und Komponenten Object Request Broker SystemArchitektur Enterprise JavaBeans Business Objects und Komponenten Dienste Technische Dienste Technische Dienste (CORBA Services) Leistungsempfaenger Leistungsempfaenger Dienste Technische Dienste Technisches Referenzmodell ObjektP artner S onstigeP artnerrolle partn erart Leistungsempfaenger B eitragszahler (CORBA Services) P roduktpartner ObjektP artner P ostempfaenger B eitragszahler anzuwendendeA nschrift 0..1 A nschrift 0..1 * anzuwendende P artner * B ankverbindung B ankverbindung0..1 0..1 NatP erson NatP erson Technisches Referenzmodell ObjektP artner S onstigeP artnerrolle partn erart Fachliche Komponentenmodelle Rolle P erson S tandard 0..1 * Rufnummer JurP erson P roduktpartner V ersicherte P erson IcisB asis (from LibraryP ackage) A ctor-Role -P attern V ersionierbarerA kteur 0..1 NatP erson V ermittler Fachliches Referenzmodell Fachliches Referenzmodell V ersionierbar (from LibraryP ackage) A ctor-Role -P attern V ersionierbarerA kteur Enterprise Java Beans Technische Architektur (CORBA Services) Technische Architektur Object Request Broker Object Request Broker 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“ OOADModell von UML und dem implementierungsorientierten CORBA-Metamodell. BOCA definiert eine Component Definition Language (CDL), mit deren Hilfe Komponenten für Geschäftsanwendungen mit den Konstrukten des BOCA-Metamodells präzise beschrieben werden können. Die Interoperabilität von Komponenten, die mit CDL beschrieben sind, kann dadurch relativ zuverlässig gewährleistet werden. BOCA setzt zwar die Existenz von technischen Diensten für Datenmanagement und Transaktionsverwaltung voraus, liefert allerdings keine Beschreibungen, wie diese Dienste in das Metamodell integriert werden sollen. © GDV 2001 99 Inhalt Das Objektorientierte Technische Referenzmodell 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 MetaType BocaType. InterOp und BOCA können aufgrund dieser losen Zuordnung unabhängig voneinander verwendet werden. Eine vollständige Durchgängigkeit des Entwicklungsprozesses und die Interoperabilität entsprechender Komponenten könnte durch die Umsetzung beider Standards möglich werden, wenngleich die intellektuellen Anforderungen an Systementwickler sehr hoch sind. Voraussetzung dafür ist allerdings eine breite Unterstützung der Hersteller von Entwicklungsumgebungen für diese Standards. BOCA konnte im Rahmen des Arbeitsauftrages der Projektgruppe „Technisches Referenzmodell“ aufgrund seines umfassenden Anspruchs nicht in die Analyse einbezogen werden, da fachliches und technisches Referenzmodell gleichzeitig betrachtet werden müßten. Aufgrund des vorläufigen Charakters der BOCA-Spezifikation erscheint dies zum heutigen Zeitpunkt auch nicht sinnvoll. Die folgende Übersicht befaßt sich deshalb ausschließlich mit den Inhalten der Interoperability Specification. 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. 100 © GDV 2001 Das Objektorientierte Technische Referenzmodell Personnel Inhalt 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 © GDV 2001 101 Inhalt Das Objektorientierte Technische Referenzmodell 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 102 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt BocaGenericDataType::BocaObject BocaTransactions::TransactionalObject BocaNotif ication::Consumer BocaNotif ication::Supplier BocaObjects::StateAccess BocaGenericDataTypes::DependentObject BocaObjects::Lif eCycleObject 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 © GDV 2001 103 Inhalt Das Objektorientierte Technische Referenzmodell 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 104 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Persistence ID ist implementierungsabhängig. Um eine vollständige Transparenz des Objektzugriffs zu erreichen, empfiehlt InterOp die Erweiterung der CORBA-Reference um die Persistent ID des BOs (s.u.) BocaObjectKey Der BocaObjectKey ist die Menge der BO-Attribute, die das BO eindeutig identifizieren („Sekundärschlüssel“). Der BocaObjectKey ermöglicht es dem Type Manager über die identifizierenden Attribute ein BO zu finden. External ID Die External ID ist ein sprechender Schlüssel des Objekts, der über den Naming Service von CORBA an ein BO gebunden werden kann (siehe Abschnitt „Naming Service“, unten). Die External ID kann verwendet werden, um einen Objektschlüssel für den Anwender darzustellen. Qualified Name Der Qualified Name eines BO besteht aus einem Naming Context und dem BocaObjectKey oder der External ID. Durch den Naming Context können gleichlautende Schlüssel in unterschiedlichen Domänen genutzt werden (Beispiel: identische Vertragsnummern in allen Sparten, die Spartenzugehörigkeit wird über unterschiedliche Naming Contexts definiert - „LV/1234567“ und „KFZ/1234567“). Um Qualified Names darzustellen, erweitert InterOp den CORBA Naming Service (s.u.) Foreign Object ID Die Foreign Object ID stellt den Schlüssel eines BOs in einer anderen BSD dar. Die Umsetzung zwischen Foreign Object ID und tatsächlichem Schlüssel erfolgt durch den Adaptor (s.o.) Tabelle 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. © GDV 2001 105 Inhalt Das Objektorientierte Technische Referenzmodell Mit Ausnahme der Persistent ID - Problematik ist der Persistence Service nicht Bestandteil der InterOp - Interfaces und Spezifikationen. InterOp ist allerdings kompatibel mit dem CORBA Persistence Service und allen anderen Persistence Services, die das Transaction Service Protokoll von CORBA unterstützen. LifeCycle InterOp vereinfacht den LifeCycle - Service von CORBA und fügt neue, im BO - Kontext benötigte Funktionen hinzu. Der InterOp Life Cycle Service ist aber nach wie vor konsistent mit den CORBA Spezifikationen, da die InterOp - Funktionen innerhalb des Type Managers beziehungsweise des BOs auf die CORBA Life Cycle - Interfaces abgebildet werden können. Generell bestehen die folgenden Unterschiede zwischen den CORBA- und InterOp - Spezifikationen InterOp definiert wie CORBA create, copy, move und delete - Operationen für BOs, die Interfaces sind jedoch nicht von den CORBA Interfaces abgeleitet (im Sinne der Interface-Vererbung) Die Funktionen copy und move haben einfachere Ortsangaben (Factory selection anstatt Factory finding) Die Erzeugung von BOs erfolgt über den Type Manager, die komplexen CORBA-Factory Interfaces sind auf InterOp-Ebene unsichtbar Im wesentlichen entsprechen die Life Cycle Operationen von InterOp der CORBA-Funktionalität, wenngleich sich die Interfaces voneinander unterscheiden: Delete Die Delete-Operation wird durch das BO selbst implementiert, sie ist im BO-Interface definiert. Nach erfolgreichem Delete ist kein Zugriff auf das Objekt mehr möglich, das explizite Löschen aus dem Speicher und der Datenbank erfolgt allerdings erst beim Transaktionsende (vgl. Transaction Service). Empfänger von Events, die das gelöschte Objekt erzeugt, werden vor dem Löschen informiert (siehe „Events“: intrinsic events). Copy Die Copy-Operation wird durch das BO selbst implementiert. Copy erzeugt ein Replikat des Objektes im selben BSD (welcher allerdings aus unterschiedlichen Adressräumen bestehen kann!). Relationships werden traversiert, wobei der grundsätzliche Ablauf in InterOp definiert ist, nicht jedoch die Details der Auflösung von Beziehungen. Bei Beziehungen, deren Knoten nicht mit kopiert werden sollen, wird ein COPY-Event an alle verbundenen Objekte gesendet (siehe „Events“: intrinsic events). 106 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Event-Verbindungen zu anderen Objekten werden nicht kopiert. Move Analog Copy mit anschließendem Delete Create Das Erzeugen neuer BOs eines bestimmten Typs erfolgt durch die Create-Operation des zugehörigen Type Managers. Das Create-Interface von InterOp ist erheblich einfacher als das entsprechende CORBAInterface, da der Weg über FactoryFinder und Factory durch den Type Manager übernommen wird. Als Parameter des CreateInterfaces müssen lediglich Erzeugungsort (ein spezieller Objekttyp) und die Initialwerte der BO-Attribute (sofern notwendig) übergeben werden. Das Interface ist generisch, da für die Übergabe der Initialwerte die gleiche Struktur wie beim State Access verwendet wird (s.u.) Das copy_from_object-Interface erzeugt ein neues BOs, bei dem Initialwerte vom angegebenen Objekt übernommen werden Tabelle 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 © GDV 2001 107 Inhalt Das Objektorientierte Technische Referenzmodell InterOp spezifiziert eigene Interfaces zur Kommunikation zwischen Business-Objects. Das „Supplier“-Interface (für die Sender-Seite) ist nicht vom entsprechenden CORBA-Interface abgeleitet, sondern neu definiert. Für die Empfänger („Consumer“) eines Events verwendet InterOp das Consumer-Interface des CORBA Event Services. Generell ist der InterOp Event Service nicht auf CORBA eingeschränkt, sondern läßt sich auch mit anderen Event Services integrieren. Im Gegensatz zum CORBA Event Service liegt InterOp weniger Wert auf den Verteilungsmechanismus, sondern auf die Spezifikation unterschiedlicher Eventtypen und den Bedingungen für das Auftreten eines Events. InterOp unterscheidet zwischen folgenden Event-Typen: Intrinsic events werden von allen BOs ausgelöst und sind vordefiniert (siehe Tabelle). Implicit events werden ausgelöst, wenn sich Attribute oder Beziehungen von BOs ändern Programmed events sind BO-Typ-spezifische Ereignisse, die abhängig sind von fachlichen Bedingungen innerhalb der BO-Logik. Event Name Description Moved Occurs on commit of a move operation. Delivery is only on precommit or post commit (not immediate). Created Provided only by type managers when an instance of the type is created. The notice will only be issued for occurrence after and delivery pre-commit or post-commit (not immediate). Deleted* Occurs when an object is logically deleted from the business system domain. This notifies a dependent consumer that the object it is dependent upon no longer exists. This event does not apply to typebased notification requests. Polling* This is an event an implementation may choose to use. It might be issued to determine if the consumer still exists. The consumer should simply return from a Polling notice; the supplier will receive an exception if the consumer is no longer available. Committed Occurs when an object is committed by a transaction. Delivery is only on pre-commit or post commit (not immediate). RolledBack Occurs when an object is restored to its last committed state by a transaction. This event is only available for immediate delivery. Tabelle 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. 108 © GDV 2001 Das Objektorientierte Technische Referenzmodell Occurrence Description Before An immediate, synchronous message is sent before an action is performed. This does not apply to intrinsic or programmed events, but only to implicit events, and it does not apply to pre-commit or post-commit delivery.. After A message is sent after the event has occurred. The notification may be immediate, pre-commit or post_commit. For operations, an after notice is issued when a normal return occurs. Failed A notice is issued if the action failed to complete, i.e., raised an exception. Inhalt 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 © GDV 2001 109 Inhalt Das Objektorientierte Technische Referenzmodell notwendig. Nicht spezifiziert ist allerdings, was bei der Änderung von Attributen geschieht, InterOp geht offenbar davon aus, daß nur identifizierende Schlüssel (die sich während der Lebenszeit eines Objektes nicht ändern) als Attribute in die Beziehung eingehen. Sollte dies nicht gewährleistet sein, so muß das Partner-Objekt bei Attribut-Änderungen benachrichtigt werden (siehe Events: implicitevents). Der Type Manager eines Business-Objekts enthält die Methode get_related_objects, die alle Partner der angegebenen Beziehung zurückliefert. Dabei kann eine Sortierreihenfolge auf Basis der in der Beziehung definierten Attribute angegeben werden. Query Der Type Manager stellt Interfaces für Queries von Business-Objekten seines Typs oder abgeleiteten Typen zur Verfügung. query Liefert einen Iterator zurück, mit dessen Hilfe über die Ergebnismenge iteriert werden kann (ein Iterator entspricht in etwa einem Datenbank-Cursor in relationalen Datenbanken). Neben den Objektreferenzen enthält die Ergebnismenge auch Attribute der gefundenen Objekte, sofern diese in der Query angegeben wurden. Die Methode query akzeptiert einen Query-String in einer in InterOp definierten Syntax. Für den zurückgelieferten Iterator ist ein analoges query-Interface definiert, damit die Ergebnismenge weiter eingeschränkt werden kann. extent_iterator Liefert einen Iterator über die Menge aller Business-Objekte dieses Typs und seiner abgeleiteten Typen zurück. Tabelle 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 BusinessObjekte müssen immer auf Basis des gleichen Frameworks implementiert werden. Introspection Das Introspection Interface wird vom Type Manager eines Business-Objects implementiert. Es dient dazu, allgemeine Informationen über die BOs dieses Types zu erhalten. InterOp definiert die folgenden Methoden im Introspection Interface: get_class 110 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 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt an. Danach muß das Meta-Object zumindest Informationen über Attribute, Relationships und Events des zugehörigen BO-Typs liefern. get_key_class Liefert eine Referenz auf das „Meta-Object“ des Schlüssels eines BOs des zugehörigen Typs (vgl. BocaObjectKey) get_key_elements Liefert eine Liste der Attributnamen, die im Schlüssel eines BOs des zugehörigen Typs auftreten (vgl. BocaObjectKey). Tabelle 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. © GDV 2001 111 Inhalt Das Objektorientierte Technische Referenzmodell Darüber hinaus definiert InterOp eine Reihe von Mechanismen, die für das Zusammenspiel von BOs innerhalb einer BSD und einer Transaktion notwendig sind. Deshalb ist der Transaction Service als Shared Service konzipiert, d.h. BOs teilen sich einen Transaktionskontext. Analog zum CORBAService, muß der „Benutzer“ eines BO nur Anfang und Ende einer Transaktion spezifizieren, den Rest erledigt die Logik innerhalb des BO (die eigentliche Speicherung) bzw. der CORBA-Service. Natürlich sind auch verschachtelte Transaktionen möglich. Folgende zusätzliche Eigenschaften des CORBA Transaction Service werden in InterOp spezifiziert: Session InterOp spezifiziert ein Session Object mit frei wählbaren Attributen (named values), das dazu dienen soll, Transaktionsinformationen zwischen BSDs (und unterschiedlichen Implementierungen eines Transaktionsframeworks) auszutauschen. Deadlock detection and Definiert einen Mechanismus, um dead locks zwischen gekoppelten Tx (in verschiedenen BSDs bzw. Tx-Frameworks) resolution aufzulösen BOCA-Exceptions BOCA – Fehlermeldungen als Erweiterung der CORBAExceptions Weitere Phasen Neben Prepare und Commit spezifiziert InterOp noch die Phasen Propagate, Validate und Synchronize, um die Möglichkeiten der automatischen Konsolidierung von Informationen zwischen Bos zu erweitern (siehe Bild unten) Dispatch Service Der Dispatch Service dient zum Anstoß von Folgetransaktionen nach Abschluß der aktuellen Transaktion. Damit ist zum Beispiel die asychnrone Koppelung unterschiedlicher BSDs möglich. Der Anstoß der Folgetransaktion kann auf unterschiedliche Weise erfolgen: Unmittelbar nach dem Commit (post_commit_request) Nach einer definierten Zeitspanne (time_delay_request) Durch ein CORBA-Event (event_delivery_request) Während die ersten beiden Möglichkeiten voraussetzen, daß das Zielobjekt des Folgetransaktionsaufrufs das DispatchTarget Interface von InterOp implementiert, kann mit der dritten Möglichkeit jedes beliebige CORBA-Objekt benachrichtigt werden. Tabelle 14: Eigenschaften des Transaction Service (Interoperability Specification) 112 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 1: commit() Steuerlogik der Anwendung (Prozeß) ideEffects () ag 2: 3a: checkS ate Transaction Manager (CORBA) p pro 4: v () alid ate( ) 5: validateInternalStateBeforeUpdate() BO 3b: BO (im Tx-Context registriert) che ckI nte niz rna lRu les e () ro ch yn s 6: () 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 © GDV 2001 113 Inhalt Das Objektorientierte Technische Referenzmodell 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 4.3.1. Architekturziele und Kontext IBM verfolgt mit San Francisco das strategische Ziel, Softwarehäusern eine Basis zur Entwicklung von Geschäftsanwendungen zu geben. Die erstellten Softwarekomponenten bilden sogenannte Tower, die sich auf Basisfunktionalität von San Francisco (Foundation Layer mit Persistenz, Transaktionen usw.) und auf von IBM entwickelten Kernkomponenten (Common Business Objects, z.B. BusinessPartner) und Kernprozessen (Core Business Processes, z.B. Buchhaltung, Einkauf, Verkauf, Lagerverwaltung) abstützen. 114 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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. 4.3.2. Grundmuster der Architektur Abbildung 60: Die San Francisco Architektur © GDV 2001 115 Inhalt Das Objektorientierte Technische Referenzmodell 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 116 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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ß © GDV 2001 117 Inhalt Das Objektorientierte Technische Referenzmodell 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 118 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt definiert 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 © GDV 2001 119 Inhalt Das Objektorientierte Technische Referenzmodell für 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 4.4.1. Architekturziele und Kontext Die Enterprise JavaBeans (EJB) Technologie definiert ein Modell für die Entwicklung und Benutzung von wiederverwendbaren Java Serverkomponenten. Unter einer Komponente versteht man Softwareeinheiten, die realisiert wurden und zu einem Anwendungssystem zusammengefügt werden können. Das Komponentenmodell der Java Technologie heißt JavaBeans. JavaBeans stellt wiederverwendbare Softwarekomponenten zur Verfügung. Die Enterprise JavaBeans (EJB) Architektur erweitert das JavaBeans Komponentenmodell um die Unterstützung von Serverkomponenten. Serverkomponenten werden ausschließlich auf dem Anwendungsserver bereitgestellt. EJB unterstützt die Entwicklung von verteilten Anwendungen, die auf unterschiedlichen Plattformen lauffähig sind. Die Funktionalität liegt überwiegend auf der Serverseite. Die Anwendungslogik wird auf mehrere Objekte aufgeteilt, die auf dem Anwendungsserver zur Verfügung stehen. In der Java Philosophie ist der Satz “Write once, run anywhere” einer der grundlegenden Prinzipien. Existiert eine Java Virtuelle Maschine (VM) auf einem beliebigen Betriebssystem, so kann dort eine Java Anwendung ausgeführt werden. Die Übertragung dieses Prinzips auf die Serverkomponenten ist 120 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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. Grundmuster der Architektur 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 entwickeln sind. Es ermöglicht den Komponenten, zu einer größeren Anwendung zusammengestellt zu werden. Dabei ist es nicht erforderlich, daß die Komponenten von einem Herstellern realisiert wurden. 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. © GDV 2001 121 Inhalt Das Objektorientierte Technische Referenzmodell 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. 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 122 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt (portability layer) implementiert wird. Jede Enterprise Bean kann auf jedem Anwendungsserver laufen, der EJB Kontrakte unterstützt. 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 Client EJB Objekt (Client view) 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. © GDV 2001 123 Inhalt Das Objektorientierte Technische Referenzmodell Der EJB Server stellt einen oder mehrere Container zur Verfügung, die Enterprise Bean Objekte verwalten. Der Container ist verantwortlich für: die Registrierung der Objekte die Erzeugung und Löschung der Objektinstanzen Sicherheitsprüfungen für Objekte Verwaltung der aktiven Zustände im Objekt Koordinierung verteilter Transaktionen. 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 124 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 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. 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 © GDV 2001 125 Inhalt Das Objektorientierte Technische Referenzmodell 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. 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 126 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 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. 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. © GDV 2001 127 Inhalt Das Objektorientierte Technische Referenzmodell 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. 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 128 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt 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. 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. © GDV 2001 129 Inhalt Das Objektorientierte Technische Referenzmodell 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. 130 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 131 Inhalt Das Objektorientierte Technische Referenzmodell transparenter Kommunikationsbus zwischen den Objekten fungiert und die CORBA-Services, die definierte 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 132 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Von IBM entwickeltes Komponentenmodell, das einen Satz von in wechselseitiger Beziehung stehenden Geschäftsobjekten und Anwendungsdiensten bereitstellt. Das Komponentenmodell dient Softwarehäusern als Basis zur Entwicklung von Geschäftsanwendungen. Es enthält allgemeingültige Geschäftsanwendungen (z.B. Buchhaltung, Einkauf, Verkauf, Lagerverwaltung), Basisfunktionen (z.B. Persistenz, Transaktionen usw.) und von IBM entwickelte Kernkomponenten (z.B. Partner). Interface Definition Language (IDL) Sprach- und systemunabhängige Beschreibungssprache für Interfaces. Sie erlaubt es, alle CORBAObjekte gleich zu beschreiben. Internet Inter-ORB Protocol (IIOP) Es legt fest, wie GIOP- (General Inter-ORB Protocol) Nachrichten über ein TCP-IP-Netzwerk ausgetauscht werden können. GIOP definiert eine Menge von Nachrichtenformaten und Datendarstellungen für die Kommunikation zwischen den ORBs. Interoperability Specification Definition von Kategorien von Objekten inklusive ihres grundlegende Verhaltens Strukturvorgaben.(„Systemarchitektur„) und die benötigten technischen Funktionen Datenspeicherung und Transaktionsmanagement auf die CORBA - Dienste Interfacespezifikationen abzubilden („Technische Architektur„). und wie und 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 © GDV 2001 133 Inhalt Das Objektorientierte Technische Referenzmodell Das Modell enthält den funktionalen Kern der Anwendung. Es kapselt die entsprechenden Daten und bietet Operationen an, welche die für die Anwendung spezifische Verarbeitungen vornimmt. MVC - Model View Controller Das Model-View-Controller-Konzept (MVC) unterteilt eine interaktive Anwendung in drei Komponenten. Das Modell enthält die Kernfunktionalität und die Daten. Die Ansichten (Views) präsentieren dem Anwender Informationen. Kontrollkomponenten sind für Bedienereingaben verantwortlich. Ansichten und Kontrollkomponenten zusammen umfassen die Bedienerschnittstelle. Ein Mechanismus zur Benachrichtigung über Änderungen sichert die Konsistenz zwischen der Bedienerschnittstelle und dem Modell. Namenskontext Ein Namenskontext ist ein Lebensraum von Objekten, in dem der Name eines Objekts eindeutig festgelegt ist. Der Namenskontext ist vergleichbar mit einer Verzeichnisstruktur. Innerhalb des gleichen Verzeichnisses können keine zwei Dateien mit dem selben Namen existieren. Objektreferenz Die Objektreferenz stellt Informationen zur Verfügung, die benötigt werden, um ein Objekt in einem verteilten System eindeutig zu identifizieren. OMG Die Object Management Group (OMG) ist ein Konsortium verschiedener Unternehmen der Computerindustrie, die mit der CORBA-Spezifikation eine Beschreibung für eine Middleware- und Komponentenarchitektur vorgelegt hat. Object Request Broker (ORB) Der Object Request Broker (ORB) ist der Kommunikationsbus, auf dem Client-Objekte mit verteilten Server-Objekten plattformunabhängig kommunizieren können. Er ist unter anderem zuständig für die Übertragung der Aufrufparameter, der plattformabhängigen Formatierung der Werte und der Erzeugung einer system-übergreifenden Objektreferenz Präsentationsebene Die Präsentationsebene bündelt die Aufgaben des Views und des Controllers gemäß des MVCEntwurfsmusters. Sie übernimmt eigenständig alle Aufgaben, die zur Präsentation von Business Objects benötigt werden. Jedes Business Object kann eine oder mehrere Präsentationen haben. Process Business 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. 134 © GDV 2001 Das Objektorientierte Technische Referenzmodell Inhalt Unified Modelling Language (UML) Die UML ist eine Modellierungssprache für objektorientierte Paradigmen. Sie besteht aus Modellierungsdiagrammen und dem UML-Metamodell. Virtual Machine (VM) Von Sun für die Java Programmierumgebung neu belebter Begriff. Eine Virtual Machine agiert als Schnittstelle zwischen kompilierten Java Binärkode und dem Prozessor oder der Hardwareplattform, auf der die Programminstruktionen direkt ablaufen. Sobald für eine Plattform eine Java Virtual Machine zur Verfügung steht, können alle Javaprogramme (Bytecodes) auf dieser Plattform ausgeführt werden. Wrapper Durch die Verwendung von Wrappern für Softwarekomponenten, werden diese mit einer Objektschnittstelle entsprechend der CORBA-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 © GDV 2001 135 Das Objektorientierte Technische Referenzmodell 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 137 Anhang Das Objektorientierte Technische Referenzmodell 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 138 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 139 Anhang Das Objektorientierte Technische Referenzmodell 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: 140 Erzeugen eines Rollen- oder Relationenobjektes (fällt in die Zuständigkeit der Rollen- oder Relationen-Factory). © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 141 Anhang Das Objektorientierte Technische Referenzmodell Rolle: Konto von Rolle: Kontoinh. Person Konto Relation Girokonto Rolle: Beitragszahler Vertrag Relation Beitragsverhältnis Rolle: Beitragspflichtiger Vertrag Rolle: Beitragskonto für Vertrag Relation Girokonto VU Konto Rolle: Konto von Rolle: Kontoinh. In diesem Beispiel hat die Relation "Beitragsverhältnis“ den Degree 3 und die Relation „Girokonto“ den Degree 2. Die Kardinalität der Rolle "Konto von" wäre 1 und der Rolle „Eingangskonto“ wäre die Kardinalität n zuzuordnen. Abbildung 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 werden soll oder nicht. In Abhängigkeit von dieser Festlegung wird entschieden, ob eine 142 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang 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 143 Anhang Das Objektorientierte Technische Referenzmodell 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 Datenspeicherungs-Protokoll zu verwenden ist und wieviel Sichtweite es seinem Client einräumt. Manche Objekte machen sich selbst persistent, während andere Objekte diese Funktion ihrem Client überlassen. Mittels der Persistence-ID (PID) identifiziert der Persistent Object Service das Objekt, das gespeichert wird. Ähnlich wie die Objektreferenzen kann das PID in späteren Sessionen benutzt werden. Die PID kann ausschließlich im Kontext vom POS benutzt werden. In der Realität gibt es mehrere Persistenzdienste, Speichermedien und Protokolle. Der Persistence Object Manager (POM) trifft die Entscheidung, welches ausgewählt wird. Der Persistence Data Service (PDS) implementiert die Schnittstelle zum Protokoll, und er führt die aktuelle Speicheroperation aus. Der Datenspeicher kann eine einfache Datei sein oder eine Datenbank. Da einige Datenspeicher passiv sind, benötigen sie den PDS, um die Speicherung und die wiedergewonnenen Operationen zu initialisieren. Wertung Der CORBA-Persistence Service wird aufgrund seiner oberflächlichen Spezifikation und der mangelnden Kompatibilität mit anderen Standards (z.B. der ODMG) von keinem Datenbankhersteller unterstützt. Ein Persistence Service ist für die Architektur der VAA unbedingt notwendig, CORBA´s Spezifikationen sind als Basis allerdings nicht ausreichend. Generell geht der Trend hin zu Transaction Frameworks wie Enterprise JavaBeans, die Transaktionsmanagement und Persistenz in einem einheitlichen Rahmen zur Verfügung stellen. Auch die OMG geht mit CORBA 3.0 diesen Weg. 144 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 ACID-Charakteristika erfüllt sind: 1. Eine Transaktion ist atomar (atomic), wenn bei einer Unterbrechung aufgrund eines Fehlers sämtliche Auswirkungen bis zu diesem Zeitpunkt zurückgesetzt (rolled back) werden. 2. Eine Transaktion liefert konsistente (consistent) Ergebnisse. 3. Eine Transaktion ist isoliert (isolated). Ihre Zwischenstände sind für andere Transaktionen nicht sichtbar. Sie laufen vordergründig seriell ab, obwohl sie konkurrierend zu anderen Transaktionen stehen. 4. Eine Transaktion ist dauerhaft (durable), wenn die Folgen einer abgeschlossenen Transaktion persistent sind. Eine Transaktion kann auf zweifache Weise enden: sie wird entweder commited oder rolled back. Commited heißt, daß sämtliche Änderungen permanent werden, anderenfalls werden die Veränderungen auf ihren ursprünglichen Ausgangsstand zurückgesetzt (rolled back). Jede Transaktion besteht aus dem Start, einer Zahl von Transaction-Events (z.B. DB Updates) und einem definierten Ende. Der CORBA Transaction Service beschreibt Interfaces, die verteilten Objekten erlauben atomar zu sein. Die Interfaces gestatten es den Objekten, gemeinsam Transaktionen per commit oder rollback abzuschließen. Insbesondere bietet der Transaction Service: Transaktionen an, die unterschiedliche verteilte ACID-Objekte einschließen. die Option, Objekte und Ressourcen aus der Nicht-Objektwelt zu integrieren. Die Sychronisation der an einer Transaktion beteiligten Objekte und dem Transaction Service erfolgt mit Hilfe eines Transaction Context, der von den beteiligten Objekten gemeinsam genutzt wird. Der Transaction Context wird bei jedem Methodenaufruf tranparent für den Client vom ORB als Parameter übergeben. Die vom Transaction Service unterstützten Anwendungen bestehen aus folgenden Komponenten: Der Transactional Client (TC) in Form eines Programms kann Operationen auf verschiedenen Transactional Objects in einer einzigen Transaktion durchführen und ist verantwortlich für das Auslösen und Beenden einer Transaktion. Ein Objekt, dessen internes Verhalten von der Teilnahme an einer Transaktion beeinflußt wird, muß das Interface TransactionalObject implementieren. TransactionalObject ist ein abstraktes Interface, das selbst keine Operationen definiert. Es dient lediglich dem ORB als Kennzeichen, daß das betroffene Objekt an einer Transaktion teilnehmen soll. Ein Recoverable Object ist ein Objekt, das an einer Transaktion beteiligt ist und dessen Zustand in einer Resource (eine Datei oder eine Datenbank) gespeichert wird. Ein © GDV 2001 145 Anhang Das Objektorientierte Technische Referenzmodell Recoverable Object muß deshalb sowohl das TransactionalObject- als auch das Resource-Interface 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. 146 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 147 Anhang Das Objektorientierte Technische Referenzmodell 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 EnterpriseJavaBeans spezifizieren sollen. Mit entsprechenden Submissions ist noch im Jahre 1999 zu rechnen. Durch die Unterstützung aller namhafter ORB-Hersteller und deren Zusammengehen mit Herstellern von Transaktionsmonitoren wird OTS und OTM daher die für große Anwendungen notwendige Reife in den nächsten Jahren erreichen. Insgesamt bleibt unter dem Gesichtspunkt einer zeitlich lang andauernden und auch über eine Vielzahl von Clients und Servern verteilten Transaktion die Performance-Frage zu verifizieren. Der eher konservative CORBA-Ansatz kann durch verschiedene Redesigns (in der Versionierung) inzwischen gute Performance-Werte liefern. 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: 148 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 149 Anhang Das Objektorientierte Technische Referenzmodell 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 2 3 Der Server bietet dem Trader einen Dienst an (Export) Der Client fragt den Trader nach einem geeigneten Dienst (Import) Der Trader vermittelt und der Client bedient sich direkt des ermittelten Dienstes Client Abbildung 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 150 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang aufwendig und resourcenintensiv werden. Deshalb bestehen Möglichkeiten, eingeschränktes Suchen mittels Berechtigungen, Restriktionen oder Preferenzen vorzunehmen. Mit Policies kann vorgegeben werden wie die Suche durchzuführen ist sowie die Zahl der zu prüfenden Dienste. Mittels Constraints lassen sich Suchkriterien auf der Basis einer Constraint Language definieren. So kann z.B. SQL als Constraint Language gewählt werden. Preferences legen fest, in welcher Reihenfolge passende Angebote zurückgegeben werden sollen. Policies, Constraints oder Preferences sind Parameter des Suchvorganges, der durch den Aufruf der Lookup-Schnittstelle angestoßen wird. Der Trader Service ist durch zwei Gruppen von Interfaces beschrieben: Functional Interfaces Administration Interfaces © GDV 2001 151 Anhang Das Objektorientierte Technische Referenzmodell Functional Interfaces sind: Lookup-Interface Die Lookup-Schnittstelle verfügt nur über die Methode QUERY, mit der Clients Dienste anfordern und importieren können. Die Suche kann durch Vorgabe von Restriktions-Parametern eingeschränkt werden. OfferIterator-Interface Über die Lookup-Schnittstelle wird eine Menge von gewünschten Diensten geliefert. Mit den Methoden max_left, next_n oder destroy kann in der gelieferten Menge navigiert werden bzw. diese gelöscht werden. Register-Interface Mit der Methode export offeriert ein Exporteur seine Dienste dem Trader, der vergibt dann eine eindeutige Referenz (OfferId). Mit withdraw kann ein bereits angebotener Dienst zurückgenommen werden. Mit der Methode modify kann ein angebotener Dienst geändert werden und mit describe wird eine Beschreibung eines offerierten Dienstes vom Trader geliefert. Link-Interface Diese Schnittstelle ermöglicht einem Trader, die Dienste eines anderen Traders zu verwenden (Trader-Pool). In diesem Pool kann dann mit der Methode query nach gewünschten Diensten nachgefragt werden, um diese zu importieren. Proxy-Interface Mit diesen speziellen Methoden wird einem Trader ermöglicht, Objektreferenzen zur Angebotszeit zu ermitteln, die einen Dienst bereitstellen können, aber es de facto noch nicht getan haben. Aus diesem Grunde kann der Trader auch noch nicht über die Objektreferenz des Dienstes verfügen, sondern erhält diese über ein Proxy-Objekt, welches intern mittels query-Methode auf ein LookupObjekt die Offer-Id ermittelt. Proxies sind nützlich, um angebotene Dienste z.B. unter Berücksichtigung einer performanten Verteilung dynamisch berücksichtigen zu können. DynamicPropEval Dynamische Eigenschaften ermöglichen frühzeitige Informationen über potentielle Dienste, gehen aber dafür eindeutig zu Lasten der Performance. Der Trader verwendet die Methode evalDP, um den Wert einer dynam. Eigenschaft eines Dienstes zur Angebotszeit aufzulösen, ehe dieser importiert wird. Tabelle 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. 152 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 153 Anhang Das Objektorientierte Technische Referenzmodell 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 154 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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: Ordered Sorted Sequential Multiple Unique Multiple Multiple Unordered Unique Element Map Relation Sorted Map Sorted Relation Key No Element KeysSet KeyBag KeysSet KeyBag Quality No Key Element Quality No Element Quality Set Bag Set Bag Heap Equality Sequence Sequence Abbildung 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 155 Anhang Das Objektorientierte Technische Referenzmodell 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: 156 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang Normal: es bestehen keine Manipulations-Einschränkungen. Neue Werte zu bestehenden Eigenschaften können definiert oder Eigenschaft löschen werden. Readonly: Property-Informationen können nur gelesen oder gelöscht werden. 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 Eigenschafts-Editoren zur Konfigurationszeit anzupassen. In der kommenden CORBA Beans Spezifikation sollen allerdings CORBA-Beans als direkt als JavaBeans einsetzbar sein, so daß deren Möglichkeiten auch für CORBA-Objekte zur Verfügung stehen. Generell erscheint das Property-Modell von JavaBeans vor allem unter dem Gesichtspunkt der Komponentenorientierung heute ausgereifter und vollständiger als die CORBA-Spezifikation. 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 © GDV 2001 157 Anhang Das Objektorientierte Technische Referenzmodell einer OODB, einer RDB, einem File oder in einer anwendungsinternen Collection gespeichert sind. Neben dem rein lesenden Zugriff auf die Objekte stellt der Service Operationen bereit, die Objekte aus der Collection zu entfernen, Objekte in der Collection ändern etc. Zur Formulierung der Queries können folgende Sprachen genutzt werden: 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 158 CollectionFactory; zum Erzeugen einer Collection © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang Collection; repräsentiert die Collection Iterator; ermöglicht das navigieren in der Collection Der Typ Query Framework wird in dem Modul CosQuery spezifiziert und enthält folgende Interfaces QueryLanguageType; definiert die Query Language QueryEvaluator; repräsentiert den Query Auswerter 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. © GDV 2001 159 Anhang Das Objektorientierte Technische Referenzmodell 4. Mittels get_result kann der Client erfahren, ob seine Query erfolgreich ausgeführt wurde. 5. Um über die Ergebnismenge zu navigieren wird durch die Methode create_iterator ein Iterator erzeugt. 6. Durch die next-Methode des Iterators kann von einem Ergebnis zum anderen gesprungen werden. Abbildung 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 160 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang Sicherheitsmechanismen in CORBA integriert sind: 1. Der Client muß gegenüber einem Beglaubigungssystem (PrincipalAuthenticator) seine Identität nachweisen. Als Bestätigung seiner Identität erhält der Client ein Dokument, das seine Identität und seine Rechte (evtl. zeitlich befristet) nachweist (Credential). Die Erstellung der Credentials kann das Sicherheitssystem auch ohne explizite Aufforderung vom Betriebssystem ermitteln. 2. Diese Credentials werden - für den Client transparent - über den COBRBA::CURRENT Kontext zusammen mit der eigentlichen Nachricht zum Server übermittelt. Verschlüsselung und Quersummenbildungen (ParityCheck) sorgen dabei für eine sichere Kommunikation zwischen Client und Server. 3. Das Server-Objekt hat die Aufgabe zu überprüfen, ob die angeforderte Operation vom Aufrufer (Client) ü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. © GDV 2001 161 Anhang Das Objektorientierte Technische Referenzmodell Der Externalization Service ist funktional eine Untermenge des Persistence Service, da er ebenfalls den Zustand eines Objektes dauerhaft speichert, Änderungen des Zustands jedoch nicht automatisch berücksichtigt. Um ein Objekt auszulagern, wird der Zustand des Objektes in Form eines Datenstromes („Streams“) aufgezeichnet. Dieser Datenstrom kann je nach Anwendung im Speicher gehalten, auf einen externen Datenträger geschrieben oder über ein Netzwerk versandt werden. Der so entstandene Datenstrom kann in Form eines neuen Objektes in denselben oder einen anderen Prozeß wiedereingelagert werden. Der Externalization Service benutzt den Relationship Service um Gruppen von in Beziehung zueinander stehenden Objekten innerhalb des gleichen Streams auszulagern und Interfaces des LifeCycle Services um aus einem Stream Objekte zu erzeugen. Der Kern des Service manifestiert sich in dem sogenannten Stream Objekt. 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 162 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang müssen dieses Interface implementieren. Das auzulagernde Objekt ruft seinerseits die Methoden des StreamIO - Interface auf, um seinen Zustand in einen Datenstrom zu schreiben oder von ihm zu lesen. Dieses Interface wird durch den Stream Service implementiert; er stellt Operationen zum Lesen und Schreiben aller IDL-Datentypen zur Verfügung. Das Stream Objekt implementiert dieses Interface entweder selbst, oder übergibt eine Objektreferenz darauf, wenn es das auszulagernde Objekt aufruft. Um ein Objekt aus einem Datenstrom wiedereinzulagern, ruft der Benutzer die internalize -Methode des Stream-Objektes auf. Das Stream-Objekt muß ein Streamable-Objekt identifizieren, daß seinen Zustand aus einem Datenstrom wiedereinlagern kann; es benutzt das StreamableFactory Interface um das Objekt zu erzeugen. Das Stream-Objekt ruft dann die internalize_from_stream - Methode des Streamable-Objektes auf. Selbstverständlich benutzt das Streamable-Objekt das StreamIO Interface um den Datenstrom zu lesen. Beispiel Das folgende Sequenzdiagramm stellt den prinzipiellen Ablauf der Externalization und Internalization über einen Stream dar: 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 © GDV 2001 163 Anhang Das Objektorientierte Technische Referenzmodell Abbildung 79: Lesen und Schreiben von Objekten im Externalization Service Wertung Der Stream-Mechanismus des Externalization Services ist aufgrund seiner Einfachheit sehr robust und universell einsetzbar und hat sich aus diesem Grund in der Objektwelt generell eingesetzt, um Objekte in sequentiellen Dateien zu speichern oder von einer Anwendung zur anderen - auch über ein Netzwerk - zu transportieren. Streams werden außer in CORBA auch in Java und in Microsofts COMArchitektur zur Übertragung oder Speicherung von Objekten genutzt, die verwendeten Formate sind allerdings unterschiedlich. Zur einfachen Speicherung von Daten ist der CORBA Externalization Service insbesondere in heterogenen Systemumgebungen gut geeignet, in reinen Java- oder COM-Umgebungen empfiehlt sich der Einsatz der jeweiligen Technologie, da diese besser durch Frameworks unterstützt werden. Für die Übertragung von Objekten als Parameter in Methodenaufrufen ist der Externalization Service zwar ebenfalls geeignet, wird aber in CORBA 3.0 durch die einfacher zu handhabende „Pass-By-Value“ Option obsolet. 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. 164 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang Der Event Service ist skalierbar und als verteilter Service realisiert, d.h. es gibt keine zentrale Stelle an der Event Channels verwaltet werden. Event Channels lassen sich zu einer Kette verbinden, d.h. Event Channel Server können durch die Verbindung von unabhängig implementierten Event Channels miteinander kommunizieren. Events sind in der einfachen Form des Event Services nicht typisiert, d.h. die Interpretation und Festlegung von Typ und Inhalt eines Events obliegt der jeweiligen Anwendung. Der Event Service unterstützt allerdings auch typisierte Events in Form von Subtypen des einfachen Event-Interfaces. In CORBA werden zwei Module definiert, die die Schnittstellen des Event Service beschreiben Das CosEventChannelAdmin - Modul Enthält Interfaces zum Aufbau eines Event Channels und zur Ermittlung eines bestehenden Event Channels Das CosEventComm - Modul Enthält Interfaces zum Austausch von Events über einen bestehenden Event Channel Beispiel Zur Illustration folgt ein Sequenzdiagramm, das den Aufbau eines Event Channels für ein Push-Event und die entsprechende Nutzung durch einen Client beschreibt. 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 © GDV 2001 165 Anhang Das Objektorientierte Technische Referenzmodell aufgebaut wird 2. mit obtain_push_consumer erhält der Supplier ein Proxy-Objekt als Platzhalter für Consumer 3. Mit connect_push_supplier registriert sich der Supplier beim Event Channel 4. Analog verbindet sich ein Consumer mit einem Event Channel (der über seinen Namen mit Hilfe des Naming Service gefunden werden kann) durch Aufruf von for_consumers, obtain_push_supplier und connect_push_consumer 5. Sobald der Supplier ein Event auslöst durch Aufruf der push-Methode des ProyPushConsumer, wird dies über den Event Channel zu den ProyPushSupplier-Objekten weitergereicht, die ihrerseits das angebundene Consumer-Objekt informieren. Abbildung 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. ○ 166 Arachne (Decision Systems Group) − Product C++, Extensions − CORBA Services: Naming, Lifecycle, Property, Relationships, Externalization © GDV 2001 Das Objektorientierte Technische Referenzmodell ○ BEA WebLogic Server and BEA WebLogic Enterprise (was Object Broker, was M3 ) (BEA) − Product (BEA WebLogic Enterprise) Product (BEA WebLogic Server) − C++, Java, Active X Bridge, MOM, Extensions, Security − CORBA Services: Naming, Transaction − ObjectBroker page (Compaq-CERN Joint Project) ○ 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 − ○ Anhang (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) © GDV 2001 167 Anhang Das Objektorientierte Technische Referenzmodell ○ Enterprise JavaBeans - siehe JavaIDL ○ Flick (Flux Project at the University of Utah) − ○ Fnorb (DSTC) − ○ ○ − Product C++, Java , Smalltalk − CORBA Services : Naming, Events, Notification, Persistence, Lifecycle, Transaction, Concurrency Hardpack (Lockheed Martin) Product Dylan, Common Lisp, POA ILU (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 (France-Télécom/CNET) − 168 Product C, C++, Ada83, Ada95, RealTime, Fault Tolerant Harlequin (Harlequin) − ○ Product Python GemORB (GemStone) − ○ Product C++, C - Flexible and optimizing IDL compiler kit Product Java © GDV 2001 Das Objektorientierte Technische Referenzmodell ○ Jorba (Roland Turner) − Product Java − CORBA Services : Naming ○ JYLU - see ILU ○ Krypton (now part of Continuous eCommerce Platform) − ○ 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 − CORBA Services : Naming OAK C, C++, Java, POA, interoperability with COM (Camros Software) − Product − CORBA Services : Naming, Events C++, Objective-C, (Java) ○ Object Broker - siehe BEA WebLogic Enterprise ○ ObjectBus - siehe TIB/ObjectBus ○ ObjectDirector (Fujitsu) ○ ○ (TANTAU Software) Product C, C++, Java, COBOL ○ ○ Anhang − 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 − CORBA Services : Naming ORBacus © GDV 2001 (Object-Oriented Concepts) 169 Anhang Das Objektorientierte Technische Referenzmodell − Product C++, Java, Extensions, (Security), − CORBA Services : Naming, Events, Notification , Prsperty, Trader, − ORBAsec : Security Service (Adiron) ○ ORBAsec - siehe ORBacus Security ○ ORBexpress ○ − 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) ○ ○ 170 (Objective Interface Systems) − 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 Smalltalk, Extensions ○ SOMobjects ○ SORBET (obsolete) (Siemens Nixdorf ) ○ TAO ( Distributed Object Computing Group at Washington University - siehe ComponentBroker © GDV 2001 Das Objektorientierte Technische Referenzmodell ○ ○ − Product C++, Real-time, POA − 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 − CORBA Services : Naming, Events ○ TME 10 (obsolete) (Tivoli Systems) ○ UNAS (TRW) ○ ○ Anhang − Product C++, Ada95, MOM, Extensions − CORBA Services : Naming 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 171 Anhang Das Objektorientierte Technische Referenzmodell − ○ Concurrency Service − ○ ○ − NetEvents (Exemplar Development) Java implementation of the Event Service. − OpenFusion Event Service (PrismTech) Event Service with Java & C++ bindings. Lifecycle Service ○ ○ 172 OpenFusion Lifecycle Service (PrismTech) Lifecycle Service with Java & C++ bindings. Licensing Service − ○ OpenFusion Concurrency Service (PrismTech) Concurrency Service with Java & C++ bindings. Event Service − ○ OpenFusion Collection Service (PrismTech) Collection Service with Java & C++ bindings. 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) C++ implementation of the Notification Service. − Orbital Notification Service (NEC) C++ implementation of the Notification Service. Patient Identification Service © GDV 2001 Das Objektorientierte Technische Referenzmodell − ○ ○ ○ ○ ○ ○ Patient Identification Service (LANL) Persistent Object Service − ○ Anhang 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) C++ implementation of the Trading Object Service. − Trader (Washington University in St. Louis) C++ implementation of the Trading Object Service. Transaction Service © GDV 2001 173 Anhang Das Objektorientierte Technische Referenzmodell − 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. 174 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 © GDV 2001 175 Anhang Das Objektorientierte Technische Referenzmodell größer sein dürfen, sofern dadurch Server-Zugriffe eingespart werden können, da jeder einzelne Server-Zugriff 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. 176 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang 7.3.1.4. Lösung Das nachfolgende Schaubild stellt die wesentlichen Elemente der Architektur dar: Verwaltung main() Applet LogIn / LogInFrame Start Anwendung GUIFactory Server View View Client Server Activity GUIFactory main() LogIn Server / Connection Application Activity BusinessProcess Manager BusinessProcess Database Manager Business Object Business Object Business Object Datenbank 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 Client-Maschine läuft. ● GUIFactoryServer Der GUIFactoryServer existiert in der Präsentationsschicht und wird von der GUIFactory ange- 7 Java virtual machine © GDV 2001 177 Anhang Das Objektorientierte Technische Referenzmodell 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 ● 8 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 Auch im Event-Konzept des JDK gibt es das Konzept des unicast-Events, das nur an einen Listener geht. 178 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang übergeordneten 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 179 Anhang Das Objektorientierte Technische Referenzmodell 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 180 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 181 Anhang Das Objektorientierte Technische Referenzmodell 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. 182 © GDV 2001 Das Objektorientierte Technische Referenzmodell Anhang 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 183 Anhang Das Objektorientierte Technische Referenzmodell 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 XML-Dokumente ineinander überführen kann. 184 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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 185 Anhang Das Objektorientierte Technische Referenzmodell 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 186 © GDV 2001 Das Objektorientierte Technische Referenzmodell 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“, 2 nd 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 187 Literatur Das Objektorientierte Technische Referenzmodell [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 188 © GDV 2001
