next up previous contents index
Next: Die Bestandteile von CORBA Up: Common Object Request Broker Previous: Common Object Request Broker

Das OMG-Referenzmodell

  Die Object Management Architecture (OMA)  [#!oma95!#] der OMG für verteilte objektorientierte Programmierung erlaubt ortsungebundene Kooperation von Objekten in verteilter Umgebung. Je nach Implementierung können diese Objekte die Rolle eines Clients, eines Servers oder beide Rollen zugleich übernehmen. Im Gegensatz zum Manager/Agent-Paradigma, das im OSI-Management und im SNMP-basierten Management verwendet wird, liegen hier symmetrische Kooperationsbeziehungen zwischen einzelnen Objekten vor. Die OMA bildet den Rahmen für die fünf folgenden Teilaspekte und deren Architekturen (siehe auch Abbildung [*]).


  
Abbildung: Object Management Architecture

Der Object Request Broker (ORB)  bildet das Kommunikationsmedium für verteilte Objekte und leitet Anfragen bzw. Resultate in heterogener Umgebung von einem Objekt zu einem anderen weiter. Seine Hauptaufgabe besteht in der Abstraktion von Systemspezifika wie die verwendeten Netzprotokolle, Betriebssysteme und Programmiersprachen, in denen Objekte implementiert werden und verschattet somit die Heterogenität der einzelnen Ablaufumgebungen. Die Architektur, die die dafür notwendige Infrastruktur spezifiziert, wird Common Object Request Broker Architecture (CORBA)  [#!corba22!#] genannt. 

Die Object Services Architecture (OSA)  [#!omg95147!#] umfaßt grundlegende Dienste, die Basisfunktionalität bereitstellen, um Objekte in verteilter Umgebung überhaupt nutzen zu können. Hierzu zählen z.B. Dienste zur Instantiierung, Namensgebung und zur dauerhaften Speicherung von Objekten sowie zum Empfang bzw. Versand von Ereignismeldungen. CORBAservices[*] werden von der OMG genormt und sind für CORBA-konforme Systeme verbindlich. Bisher sind im Rahmen der Common Object Services Specification (COSS)  [#!sspec97!#] insgesamt 18 CORBAservices spezifiziert worden. Weitere elementare Objektdienste befinden sich in der Normierungsphase. Nützliche Managementfunktionalität für einzelne Objekte wird beispielsweise von den Diensten Property, Query, Licensing oder Change Management bereitgestellt.

Die darauf aufbauenden CORBAfacilities  (früher: Common Facilities) sind universell verwendbare höherwertige Dienste, die für eine Vielzahl von Applikationen notwendig sind. Sie werden innerhalb der Common Facilities Architecture (CFA)  [#!omg9512!#] spezifiziert, die insgesamt vier Arten von CORBAfacilities beinhaltet. Sie werden in die Bereiche User Interface, Information Management, Task Management und Systems Management eingeteilt. Letztere bilden die Grundlage, um Managementdienste in das Rahmenwerk der OMG einzubringen; bestehende und neue Dienste, die für unsere Aufgabenstellung relevant sind, werden in Abschnitt [*] sowie Kapitel [*] vorgestellt.

Domain Interfaces (kurz: CORBAdomains)  sind Dienste, die lediglich innerhalb eines bestimmten Anwendungsbereichs relevant sind. Beispiele hierfür sind Dienste für das Gesundheitswesen, die Telekommunikation, Echtzeitanwendungen oder die Finanzwelt. Die Dienstkategorie CORBAdomains wurde im Zuge der OMG-Restrukturierung im Juni 1995 von den CORBAfacilities getrennt, um Endanwendern im Rahmen sogenannter ,,Domain Task Forces``  (DTF) eine geeignete Plattform zur Spezifikation von Diensten zu bieten, die ihre bereichsspezifischen Anforderungen berücksichtigen. Der Erfolg dieser Maßnahme zur Einbeziehung von Anwendern läßt sich an der hohen Zahl der DTFs ablesen, die gegenwärtig ein Dutzend übersteigt. Nicht zuletzt ist die objektorientierte Analyse- und Designmethodik Unified Modeling Language (UML), die als Nachfolger von OMT gedacht ist, mit dem die in dieser Arbeit vorgestellten Objektmodelle entworfen wurden, zu einem OMG-Standard herangereift. Naturgemäß ist die Zahl der CORBAdomains ist im Vergleich zu den beiden vorigen Dienstarten a priori unbeschränkt, da sich in ihnen die Vielfalt der möglichen Anwendungsbereiche widerspiegelt. CORBAdomains durchlaufen einen ähnlichen Standardisierungsprozeß wie CORBAservices und CORBAfacilities, sind jedoch optional für CORBA-konforme Implementierungen.


  
Abbildung: Vererbungsbeziehungen zwischen OMA-Dienstekategorien

Für das integrierte Management besonders interessant ist die Telecom DTF , welche sich zum Ziel gesetzt hat, CORBA-basierte Dienste für den Bereich der Telekommunikation zu definieren. Diese umfassen sowohl die Erweiterung von CORBA zur Überwachung von Audio/Videoströmen als auch Dienste zur Ereignisfilterung oder Topologieverwaltung. In jüngster Zeit bildet diese Task Force das Zentrum der Bemühungen, CORBA für den Bereich der intelligenten Netze zu nutzen und Übergänge zwischen CORBA und TMN zu schaffen.

Den letzten Teilaspekt, der unter dem Gesichtspunkt der OMA behandelt wird, stellen die Application Objects  dar. Sie unterliegen aufgrund ihrer Vielfalt keiner Normierung durch die OMG und bilden somit auch keine eigenständige Teilarchitektur der OMA. Sie sind die eigentlichen Anwendungen wie zum Beispiel CAD-Systeme, CASE-Tools und Netzmanagement-Plattformen.

Zwischen den OMA-Teilarchitekturen bestehen Abhängigkeitsbeziehungen (siehe Abb. [*]), die sich dank der Vererbungseigenschaften objektorientierter Systeme einfach implementieren lassen. Die Wurzel der Vererbungshierarchie stellen die CORBAservices dar, da sie die grundlegenden Funktionen bereitstellen, um Objekte in einer CORBA-Umgebung überhaupt nutzen zu können. Darauf bauen die CORBAfacilities auf, die die zugrundeliegenden Objektdienste verwenden und um höhere Funktionalität erweitern. Natürlich können auch zwischen Objektklassen, die zur gleichen Dienstkategorie gehören, Vererbungsrelationen bestehen. Die höchste Kategorie besteht aus den Application Objects, die sich aus CORBAfacilities und gegebenenfalls zusätzlichen CORBAservices sowie dem eigentlichen Programmcode zusammensetzen. Die Abgrenzungen zwischen Application Objects, CORBAdomains, CORBAfacilities und CORBAservices sind natürlich nicht exakt festlegbar. Häufig in Applikationen vorkommende Softwaremodule sind potentielle Kandidaten für neue CORBAdomains oder CORBAfacilities; ebenso ist es möglich, daß Funktionalität von den CORBAfacilities hin zu den CORBAservices verlagert wird.


next up previous contents index
Next: Die Bestandteile von CORBA Up: Common Object Request Broker Previous: Common Object Request Broker
Copyright Munich Network Management Team