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.
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.