| Inhalt
Einleitung
Grundlagen
Historie
OMA CORBA
Entwurf
Spezifikation
Arbeitsweise
Ausblicke
Anhang
Literatur
Vortrags-Folien
|
Object Managment Architecture (OMA)
als CORBA
spezifiziert
Entwurf
Laut OMA gibt es den Object Request Broker (ORB) und die Interfaces.
Der ORB ist das von der OMA vorgesehene universelle Kommunikationsmedium
für beliebig geartete Objekte in verteilten heterogenen Systemen.
Seit Sommer 1997 existiert nunmehr die Version 2.1 von CORBA, sie
zeichnet sich durch folgende Eigenschaften aus:
- Objektorientierung.
Die grundlegenden Einheiten der Architektur sind Objekte,
wobei ein Objekt im Sinne der OMA eine beliebige,
eindeutig identifizierbare Einheit ist,
also nicht notwendigerweise ein Objekt im Sinne einer Programmiersprache.
- Verteilungstransparenz.
CORBA-Programme greifen auf entfernte Objekte mit denselben
Mechanismen zu, wie auf lokale Objekte.
Der genaue Aufenthaltsort eines Objekts bleibt
für seine Klienten in der Regel unbekannt.
- Effizienz.
Die Architektur für den ORB ist von der OMG bewußt so gehalten,
daß effiziente Implementationen möglich sind,
die z.B. im Falle rein lokaler Kommunikation dem traditionellen
Funktionsaufruf nur unwesentlich nachstehen.
- Hardware-, Betriebssystem- und
Sprachunabhängigkeit.
Die Komponenten eines CORBA-Programms können auf verschiedenen
Betriebssystemen, Hardwarearchitekturen
und mit verschiedenen Programmiersprachen realisiert werden.
- Offenheit.
Über den ORB können Programme verschiedener Hersteller
zusammenarbeiten und sogar ORB's verschiedener Hersteller miteinander
kommunizieren.
Der Anwender erhält dadurch die Freiheit,
jede Komponente einzusetzen,
die seinen individuellen Bedürfnissen am besten gerecht wird.
Softwareentwickler erhalten die Chance, am zukunftsweise und unabhängig zu
programmieren und
Angebote großer Firmen mit spezialisierten Produkten zu ergänzen.
Überblick über die Spezifikation
Laut CORBA-Spezifikation existieren folgende Komponenten:
Object Request Broker (ORB)
Stellt Dienste zur Verfügung, über die die Kommunikation zwischen
Clients (Einheiten, die von Objekten bereitgestellte Methoden nutzen) und
Server (Objektimplementierungen) abgewickelt wird. Diese Dienste legt CORBA
1.x fest. CORBA 2.0 spezifiziert zusätzlich den
Kommunikationsmechanismus zwischen ORBs verschiedener Hersteller.
Object Services
Grundlegende Operationen für die logische Modellierung und
physikalische Speicherung von Objekten (z.B Funktionen zur
Erstellung, Modifizierung, Kopie, Bewegung und Löschung von Objekten,
automatische dauerhafte Aufbewahrung von Objekten auf
Speichermedien). Die Object Services werden mit der Common Object Services
Spezification (COSS) von der OMG festgelegt.
Common Facilities
Sammlung von Klassen und Objekten, die allgemein nützliche,
höherwertige Dienste für unterschiedliche Anwendungsarten (z.B.
CAD/FiBu) bzw. mehrere Programmdienste (z.B. GUI-Funktionalität,
Druckerdienste) enthalten. Im Gegensatz zu den Object Services müssen
diese nicht in jedem OMG-konformen Produkt bereitstehen. Ein Beispiel
hierfür ist OpenDoc, ein offener Standard für Verbunddokumente
basierend auf IBM's SOM/ DSOM und Apples Bento-Technologie.
Application Objects
Stellen die eigentlichen Anwendungsobjekte wie Textverarbeitung oder CAD
dar. Sie unterliegen keiner Standardisierung.
Arbeitsweise
Der ORB fungiert als Telefonzentrale in einem verteilten System. Er stellt
Dienste für die Initialisierung und Auffindung von Zielobjekten und
für die Übermittlung von Methodenaufrufen (requests) und deren
Resultaten zwischen Clients und Zielobjekten zur Verfügung.
Die Schnittstelle, die der Client sieht, ist unabhängig von der
Position des Zielobjektes und von der Programmiersprache, in der das
Zielobjekt realisiert ist. Dieses Ziel wird über die
Schnittstellen-Definitionssprache IDL (Interface-Definition-Language)
erreicht. Diese beschreibt Zielobjekte mit ihren Methoden und Attributen
(Werten) in einer programmiersprachenunabhängigen Form, die aber
keinerlei Anweisungen enthält. Die Bereitstellung der Dienste des ORB
erfolgt in Form von Objekten, die ebenfalls mit Hilfe der IDL definiert
wurden.
Die IDL ähnelt der Struktur von in C++ realisierten
Klassendefinitionen. Das CORBA-Objektmodell unterstützt Einfach- auch und
Mehrfachvererbung, Attribute und Methoden können allerdings nicht
überladen werden.
Aus der Beschreibung eines Zielobjektes mittels IDL erstellt der
IDL-Compiler IDL-Stubs (werden für den Aufrufer benötigt) sowie
IDL-Skeletons (für die Objektimplementierung benötigt) in der
verwendeten Programmiersprache.
Ein Methodenaufruf spezifiziert einen Methodennamen, das Zielobjekt,
Parameter und einen optionalen Kontext. Dieser Kontext enthält
Informationen über die Position des Aufrufers. Ausserdem werden hier
eventuelle Fehlerrückmeldungen übergeben.
Ein Client hat zwei Möglichkeiten einen Methodenaufruf an ein
Zielobjekt zu übermitteln:
- über den vom IDL-Compiler erstellten IDL-Stub, der zur
Kompilierzeit zu seinem Code dazugebunden wird.
- über eine Abfrage des ORB nach Informationen
über vorhandene Schnittstellen und Objekte. Mit diesen Informationen
kann der Client mit Hilfe des Dynamic Invocation Interface (DII) dynamisch
einen Methodenaufruf aufbauen und übermitteln.
Zusätzlich kann ein Client verschiedene Dienste des ORBs über das
ORB Interface nutzen (Objekte erstellen und löschen, Referenzen bzw.
Namen von Objekten zur Wiederauffindung abfragen, u.a.).
CORBA ist prinzipiell auf synchrone Nachrichtenübermittlung ausgelegt.
Das heißt eine Aufruf an ein Objekt wird es mit der Rückgabe der Wert
beendet.
Es kann aber ein One-way-request ausgelöst werden, bei dem der
Aufrufer die Beendigung nicht abwarten muß, es dürfen aber von
der Methode keine Ergebnisse zurückgeliefert werden. Zudem kann ein
'deferred synchronous request' erzeugt werden, bei dem der Aufrufer
weiterarbeiten kann und später das Ergebnis der Methodenausführung
abfragt.
|
