2.1 Object Management Architecture (OMA)

Die Arbeit der Object Management Group (OMG) beschäftigt sich mit objektorientierten verteilten Systemen. Die OMG ist ein herstellerübergreifendes Konsortium mit über 500 Mitgliedern. Sie wurde 1989 mit dem Ziel gegründet, Standards für verteilte objektorientierte Anwendungen zu entwickeln. Hierbei stehen vor allem drei Anforderungen im Vordergrund der Bestrebungen: Interoperabilität, Wiederverwendbarkeit und Portabilität der Software.

Die Basisarchitektur für diese Ziele wurde im Object Management Architecture Guide ([OMG 92]) veröffentlicht. Die OMA hat folgende Bestandteile :

 

Abbildung 2.1: Die Object Management Architecture der OMG

1.

Der Object Request Broker (ORB) ist ein Kommunikationsmechanismus für verteilte Objekte. Er ermöglicht flexible Client-Server-Beziehungen zwischen Objekten, indem er Methodenaufrufe von Clients zu Server-Objekten vermittelt und dafür sorgt, daß die Ergebnisse zum Aufrufer zurückgeleitet werden. Die Architektur und Funktion des ORBs ist in der Common Object Request Broker Architecture (CORBA) ([OMG 93a]) festgelegt. CORBA wird im nächsten Abschnitt ausführlicher behandelt.

2.

CORBAservices sind Dienste, die von speziell dafür bestimmten Objekten erbracht werden. Sie erweitern die Basisfunktionalität des ORBs und ermöglichen die Interoperabilität von verteilten Objekten auf der Anwendungsebene. Der relevante Standard dafür ist die Common Object Services Specification [OMG 94]. Momentan sind folgende Dienste standardisiert:

• Der Lifecycle Service definiert, wie Objekte erzeugt, kopiert, bewegt und gelöscht werden können.
• Der Persistence Service ermöglicht das persistente Speichern von Objekten. Dafür können z.B. objektorientierte Datenbanken, relationale Datenbanken und einfache Dateien verwendet werden.
• Der Naming Service dient zur Zuweisung von Namen zu Objekten. Dabei kann auf existierenden Verzeichnisdiensten wie ISO X.500 aufgesetzt werden.
• Der Event Service erlaubt das Erzeugen und Versenden von Nachrichten zwischen Objekten.
• Der Concurrency Service regelt den gleichzeitigen Zugriff auf Objekte durch mehrere Clients.
• Der Transaction Service stellt eine Möglichkeit dar, Transaktionen auf Objekten durchzuführen unter Berücksichtigung der ACID Eigenschaften.
• Mit dem Relationship Service können Assoziationen und Beziehungen zwischen Objekten definiert werden.
• Der Externalization Service behandelt die externe (in einem übertragbaren Format) und interne Darstellung von Objekten.

Weitere Dienste, wie z.B. Security, Time und Trader befinden sich zur Zeit in der Standardisierungsphase.

3.

CORBAfacilities sind Dienste, die für viele unterschiedliche Anwendungen nützliche Funktionalität zur Verfügung stellen. Sie werden in zwei Bereiche unterteilt:

• Horizontal Facilities erstrecken sich über mehrere Anwendungsdomänen. Sie werden untergliedert in:
  • User Interface definiert den Zugriff auf ein grafisch orientiertes Informationssystem.
  • Information Management spezifiziert die Modellierung, Definition, Speicherung, Wiedergewinnung, Verwaltung und Austausch von Information. Hierzu gehören z.B. Mechanismen zum Speichern von Compound Documents.
  • Systems Management Services erlauben das Management von verteilten Objektsystemen.
  • Task Management ermöglicht die Automatisierung von Tasks in Form von Benutzer- und Systemprozessen.
• Vertical Facilities (auch Domain Interfaces genannt) stellen Basisfunktionalität für unterschiedliche Anwendungsdomänen wie z.B. CAD- oder Finanzanwendungen bereit.

Der Unterschied zwischen den CORBAservices und den CORBAfacilities besteht darin, daß letztere anwendungsnäher und spezifisch für bestimmte Anwendungsbereiche sind, während erstere eher eine Erweiterung der Infrastruktur des ORB-Systems darstellen. Die CORBAfacilities befinden sich erst am Anfang der Standardisierungsphase.

4.

Application Objects bilden die eigentlichen Anwendungen. Sie verwenden die Dienste, die vom ORB, den CORBAservices und den CORBAfacilities zur Verfügung gestellt werden.

Folgende Ziele sollen durch die OMA verwirklicht werden (vgl. [OMG 92] S. 13 ff.):

• Interoperabilität von Anwendungen, die unabhängig voneinander entwickelt wurden.
• Einbindung bereits existierender Anwendungen.
• Wiederverwendbarkeit von existierenden Softwarekomponenten und damit geringere Kosten und weniger Zeitbedarf bei der Enwicklung von neuen Anwendungen.
• Transparenz in Bezug auf Programmiersprachen, Betriebssysteme und Netztechnologien.
• Allgemeine Dienste, die von unterschiedlichen Anwendungen in Anspruch genommen werden können.
• Möglichkeit der Weiterentwicklung und Erweiterung bestehender Anwendungen.