Entwicklung verteilter Systeme mit CORBA

Universität Hannover
Lehrgebiet Rechnernetze und Verteilte Systeme
Prof. Dr.-Ing. H. Pralle
Diplomarbeit
Entwicklung verteilter
Systeme mit CORBA
am Beispiel eines
Konferenz-Management-Systems
Verfasser:
Betreuer:
Erst-Prüfer:
Zweit-Prüfer:
Datum:
Bernd Böker
Dipl.-Ing. L. Grüneberg
Prof. Dr.-Ing. H. Pralle
Prof. Dr.-Ing. C.-E. Liedtke
17. Juni 1996
Hiermit versichere ich, daß ich diese Arbeit selbständig verfaßt habe und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet wurden.
Hannover, den 17. Juni 1996
Bernd Böker
Inhaltsverzeichnis
Inhaltsverzeichnis
i
Abbildungsverzeichnis
vii
Tabellenverzeichnis
x
1
Einleitung
1
2
Analyse eines Konferenz-Management-Systems
4
2.1
2.2
Funktionen des Konferenz-Management-Systems Confman . .
5
2.1.1
Arbeitsweise des Benachrichtigungssystems . . . . . .
5
2.1.2
Ermitteln eines Konferenz-Servers . . . . . . . . . . .
7
2.1.3
Unterstützung von Konferenzen mir mehreren Servern
7
2.1.4
Verwalten der Konfigurationsdateien . . . . . . . . . .
8
2.1.5
Einbinden eines Terminkalenders . . . . . . . . . . . .
8
Zusammenfassung der Analyse . . . . . . . . . . . . . . . . .
9
i
Inhaltsverzeichnis
3
ii
Klassische Mechanismen
3.1
3.2
3.3
4
Remote Procedure Call
10
. . . . . . . . . . . . . . . . . . . . .
10
3.1.1
Client-Server-Modell . . . . . . . . . . . . . . . . . . .
10
3.1.2
Funktionsweise des Remote Procedure Calls . . . . . .
11
3.1.3
ONC-RPC . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.4
Bewertung
. . . . . . . . . . . . . . . . . . . . . . . .
16
ToolTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.1
Arbeitsprinzip . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
Prozeßorientierte Kommunikation . . . . . . . . . . . .
18
3.2.3
Objektorientierte Kommunikation . . . . . . . . . . .
19
3.2.4
ToolTalk-Architektur . . . . . . . . . . . . . . . . . . .
20
3.2.5
Bewertung
. . . . . . . . . . . . . . . . . . . . . . . .
21
Object Linking and Embedding . . . . . . . . . . . . . . . . .
22
3.3.1
Zusammengesetzte Dokumente mit OLE . . . . . . . .
22
3.3.2
Interprozeßkommunikation mit OLE . . . . . . . . . .
23
3.3.3
OLE/COM als Basis für verteilte Objekte . . . . . . .
23
3.3.4
Bewertung
24
. . . . . . . . . . . . . . . . . . . . . . . .
Common Object Request Broker Architecture
25
4.1
Object Management Architecture . . . . . . . . . . . . . . . .
26
4.2
Das OMG Objekt-Modell . . . . . . . . . . . . . . . . . . . .
27
4.3
Die Struktur eines Object Request Broker . . . . . . . . . . .
27
4.4
Interface Definition Language . . . . . . . . . . . . . . . . . .
30
Inhaltsverzeichnis
5
iii
4.4.1
Typenwerte . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4.2
Module . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.3
Interface . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.4
Attribute . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.5
Operationen . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4.6
Vererbung . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.5
Dynamic Invocation Interface . . . . . . . . . . . . . . . . . .
34
4.6
Basic Object Adapter . . . . . . . . . . . . . . . . . . . . . .
36
4.7
Object Services . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.8
Bereitstellen von Objekten . . . . . . . . . . . . . . . . . . . .
38
4.9
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.10 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Eigenschaften von Solaris NEO
42
5.1
Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2
Services und Name Space . . . . . . . . . . . . . . . . . . . .
44
5.3
Implementierung eines NEO-Objektes . . . . . . . . . . . . .
45
5.3.1
Erzeugen und Registrieren des Interfaces . . . . . . . .
45
5.3.2
Persistente Daten . . . . . . . . . . . . . . . . . . . . .
46
5.3.3
Erzeugen des Sample-Server-Codes . . . . . . . . . . .
47
5.3.4
Einfügen der Objekt-Funktionalität
. . . . . . . . . .
49
5.3.5
Erzeugen und Registrieren des Server-Objektes . . . .
50
5.4
Zugriff auf ORB Objekte
. . . . . . . . . . . . . . . . . . . .
51
Inhaltsverzeichnis
6
iv
5.4.1
Auffinden von Diensten . . . . . . . . . . . . . . . . .
51
5.4.2
Erzeugen des Client-Code . . . . . . . . . . . . . . . .
51
5.5
Dynamic Notification . . . . . . . . . . . . . . . . . . . . . . .
53
5.6
Probleme mit grafischen Benutzeroberflächen . . . . . . . . .
57
5.7
Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Java und CORBA
6.1
Die Entwicklung des World-Wide-Web . . . . . . . . . . . . .
60
6.1.1
Dynamisch generierte WWW-Seiten . . . . . . . . . .
61
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.2.1
Integration von Java ins WWW . . . . . . . . . . . . .
62
6.2.2
Java-Interpreter
. . . . . . . . . . . . . . . . . . . . .
63
6.2.3
Java – Die Sprache . . . . . . . . . . . . . . . . . . . .
63
6.3
Joe – Verbindung zwischen Java und CORBA . . . . . . . . .
65
6.4
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.2
7
60
Entwurf einer CORBA-Erweiterung f ür Confman
69
7.1
Entwurfsziele und Rahmenbedingungen . . . . . . . . . . . .
69
7.2
Umgebungsmodell . . . . . . . . . . . . . . . . . . . . . . . .
70
7.3
Ereignistabelle . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.4
Datenmodell
. . . . . . . . . . . . . . . . . . . . . . . . . . .
71
7.5
Datenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.5.1
Konferenzdaten . . . . . . . . . . . . . . . . . . . . . .
72
7.5.2
Konferenzteilnehmerdaten . . . . . . . . . . . . . . . .
74
Inhaltsverzeichnis
v
7.5.3
Konferenzwerkzeugdaten . . . . . . . . . . . . . . . . .
75
Partitionierung der Ereignisse . . . . . . . . . . . . . . . . . .
75
7.6.1
Auffinden von Teilnehmern . . . . . . . . . . . . . . .
76
7.6.2
Verwaltung der Daten . . . . . . . . . . . . . . . . . .
76
7.6.3
Erzeugen und Entfernen von Datenobjekten . . . . . .
78
7.6.4
Starten und Beenden einer Konferenz . . . . . . . . .
78
7.6.5
Starten einer zeitgesteuerten Konferenz . . . . . . . .
80
7.6.6
Beitreten und Verlassen einer Konferenz . . . . . . . .
80
7.7
Objektmodell nach der Object Modeling Technique . . . . . .
80
7.8
Ermitteln eines Konferenz-Servers
. . . . . . . . . . . . . . .
86
Wegefindung bei Konferenzen mit mehreren Servern .
87
Schnittstellen und Datenbeschreibungen . . . . . . . . . . . .
90
7.10 Design-Änderungen gegenüber Confman . . . . . . . . . . . .
94
7.6
7.8.1
7.9
7.10.1 Toolbutton-Leiste
8
. . . . . . . . . . . . . . . . . . . .
95
7.10.2 Quit-Funktionen . . . . . . . . . . . . . . . . . . . . .
95
7.10.3 Adreßeditor . . . . . . . . . . . . . . . . . . . . . . . .
95
Laufzeitverhalten von ConfmanNEO
96
8.1
Aktivierung und Deaktivierung von NEO Objekten . . . . . .
96
8.2
Programmstart von ConfmanNEO . . . . . . . . . . . . . . .
97
8.3
Auffinden von Objekt-Instanzen . . . . . . . . . . . . . . . .
98
8.4
Auswirkung der Dynamic Notification . . . . . . . . . . . . .
98
8.5
Reaktivierung nach längerer Pause . . . . . . . . . . . . . . .
99
Inhaltsverzeichnis
9
vi
8.6
Speicherbedarf . . . . . . . . . . . . . . . . . . . . . . . . . .
99
8.7
Weitere Optimierungsmethoden . . . . . . . . . . . . . . . . .
99
8.8
Vergleich Confman vs. ConfmanNEO . . . . . . . . . . . . . .
100
8.9
Zusammenfassung der Meßergebnisse . . . . . . . . . . . . . .
101
Ergebnisse und Ausblick
102
9.1
Entwicklung verteilter Systeme mit CORBA . . . . . . . . . .
102
9.2
Erfahrungen mit Solaris NEO . . . . . . . . . . . . . . . . . .
103
9.3
Weiterentwicklung der Produktionslinie ConfmanNEO . . . .
104
9.4
Übernahme der Entwicklungsergebnisse zu dem nicht auf
CORBA basierenden Confman . . . . . . . . . . . . . . . . .
104
9.4.1
Personenfindung . . . . . . . . . . . . . . . . . . . . .
104
9.4.2
Wegefindung bei Serverkonferenzen . . . . . . . . . . .
106
10 Zusammenfassung
107
Glossar
109
Literaturverzeichnis
112
Index
117
Abbildungsverzeichnis
3.1
Das Client-Server-Modell
. . . . . . . . . . . . . . . . . . . .
10
3.2
Netzwerkverbindung mit RPC . . . . . . . . . . . . . . . . . .
11
3.3
Funktionweise des RPC . . . . . . . . . . . . . . . . . . . . .
12
3.4
Erzeugen RPC-basierter Systeme . . . . . . . . . . . . . . . .
16
3.5
Nachrichtenübertragung mit ToolTalk . . . . . . . . . . . . .
17
3.6
ToolTalk-Objekt-Daten
. . . . . . . . . . . . . . . . . . . . .
20
3.7
ToolTalk-Service Architektur . . . . . . . . . . . . . . . . . .
21
4.1
OMA-Referenzarchitektur . . . . . . . . . . . . . . . . . . . .
26
4.2
Eine Anfrage an ein Objekt durchläuft den ORB . . . . . . .
28
4.3
Schnittstellen des Object Request Broker . . . . . . . . . . .
29
4.4
Anfragemöglichkeiten eines Client . . . . . . . . . . . . . . . .
30
4.5
Eine Objektimplementierung empfängt eine Anfrage . . . . .
31
4.6
In IDL definierte Werte . . . . . . . . . . . . . . . . . . . . .
31
4.7
Beispiel zur Mehrfachvererbung . . . . . . . . . . . . . . . . .
34
vii
Abbildungsverzeichnis
viii
4.8
Kommunikation über In Line Bridges . . . . . . . . . . . . . .
39
4.9
Kommunikation über Request Level Bridges . . . . . . . . . .
40
5.1
Name Space: Namensraum von NEO-Objekten . . . . . . . .
45
5.2
Generierung des IDL-Stubs . . . . . . . . . . . . . . . . . . .
46
5.3
Registrierung des Interfaces . . . . . . . . . . . . . . . . . . .
47
5.4
Erzeugen des Sample-Server-Codes . . . . . . . . . . . . . . .
49
5.5
Registrieren des Server-Objektes . . . . . . . . . . . . . . . .
51
5.6
Erzeugen des Clients . . . . . . . . . . . . . . . . . . . . . . .
53
5.7
Dynamic Notification: Methodenaufruf von Client-Objekten
über Objektreferenzen . . . . . . . . . . . . . . . . . . . . . .
54
6.1
Der Weg eines Java-Applets . . . . . . . . . . . . . . . . . . .
62
6.2
Kommunikation zwischen Java-Applet und NEO-Objekten . .
65
6.3
Entwicklung eines CORBA-Objektes mit Joe . . . . . . . . .
66
7.1
Kontextdiagramm der Netzwerkerweiterung . . . . . . . . . .
70
7.2
ER-Diagramm Konferenzteilnehmer/Konferenz . . . . . . . .
71
7.3
ER-Diagramm Konferenz/Konferenzwerkzeug . . . . . . . . .
72
7.4
Objektmodell ConfmanClient . . . . . . . . . . . . . . . . . .
76
7.5
Datenobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.6
Objekt-Instanzen im NEO-Namensraum . . . . . . . . . . . .
78
7.7
Instanzendiagramm zum Konferenz-Start . . . . . . . . . . .
79
7.8
Einladen der Konferenzteilnehmer . . . . . . . . . . . . . . .
79
7.9
OMT-Diagramm: ConfMember . . . . . . . . . . . . . . . . .
81
Abbildungsverzeichnis
ix
7.10 OMT-Diagramm: Referenzieren des ConfMember-Objektes .
82
7.11 OMT-Diagramm: ConfMemberClientCallBack . . . . . . . . .
82
7.12 OMT-Diagramm: Callback-Funktion . . . . . . . . . . . . . .
83
7.13 OMT-Diagramm: ConfmanClient . . . . . . . . . . . . . . . .
84
7.14 Konferenz-Server-Objekte . . . . . . . . . . . . . . . . . . . .
84
7.15 Start einer Server-Konferenz . . . . . . . . . . . . . . . . . . .
85
7.16 Datenverteilung einer Server-Konferenz mit mehreren Servern
87
7.17 Verteilungsstruktur nach Zeitmessungen mit UDP-Paketen
91
.
Tabellenverzeichnis
7.1
Datenverzeichnis der Konferenzdaten . . . . . . . . . . . . . .
73
7.2
Datenverzeichnis der Konferenzteilnehmerdaten . . . . . . . .
74
7.3
Datenverzeichnis der Konferenztooldaten . . . . . . . . . . . .
75
7.4
Beispielwerte zur Berechnung des Qualitätswertes . . . . . . .
86
7.5
Versuch: Zeitmessungen mit UDP-Paketen . . . . . . . . . . .
90
8.1
Programmstartzeiten bei lokalem Server . . . . . . . . . . . .
97
8.2
Programmstartzeiten bei Server über NFS . . . . . . . . . . .
98
8.3
Zeiten zum Öffnen des Adreßbuches . . . . . . . . . . . . . .
98
8.4
Zeit für dynamische Benachrichtigung . . . . . . . . . . . . .
98
8.5
Wartezeiten bei Confman . . . . . . . . . . . . . . . . . . . .
101
x
Kapitel 1
Einleitung
The CPU as an island, contained and valuable in
”
itself, is dying in the nineties. The next paradigm of
computing is distributed. This is driven by the very
real demands of corporations recognizing information
as an asset, perhaps their most important asset.
To make use of information effectivly, it must be accurate and accessible across the department, even across
the world. This means that CPUs must be intimately
linked to the networks of the world and be capable of
freely passing and receiving information, not hidden
behind glass and cooling ducts or the complexities of
the software that drives them.“
Object Management Group: Object Management Architecture Guide.
Revision 2.0, September 1992 [OMG92]
Durch die zunehmende Bedeutung von Rechnernetzen steigt auch die Anzahl
verteilter Systeme stetig an. Dabei basiert der klassische Ansatz zur Entwicklung verteilter Systeme auf dem Client-Server-Modell. Eines der bekanntesten
Mechanismen, das auf diesem Modell aufsetzt, ist der Remote Procedure Call
(RPC).
Mit den weiter steigenden Anforderungen an diese Systeme zeichnet sich jedoch ab, daß die klassischen Mechanismen den heutigen Ansprüchen nicht
mehr gerecht werden. Daher gibt es Bestrebungen, modernere Mechanismen
zu etablieren.
1
Einleitung
2
Zu den wichtigsten Zielen moderner Mechanismen gehört die Interoperabilität
zwischen verschiedenen Anwendungen in einer heterogenen Umwelt. Darüber
hinaus ist es von großen Interesse, die Wiederverwendbarkeit und Portabilität
von Programmsegmenten zu fördern.
Eine standardisierte Schnittstelle zur Kommunikation zwischen Prozessen hat
die Firma SunSoft mit dem ToolTalk-Service bereitgestellt, mit der Applikationen in lokalen Netzwerken Nachrichten austauschen können. Dabei werden
die Nachrichten gewöhnlich innerhalb einer Sitzung weitergereicht, d. h. an
die Prozesse, die der Benutzer1 auf dem Bildschirm dargestellt bekommt.
ToolTalk bietet außerdem die Möglichkeit, Nachrichten an Objekte zu verschicken. Dabei hat das System jedoch ein eigenes Verständnis von Objekten
und der Zusammenarbeit zwischen Anwendungen.
Mit dem Zusammenschluß verschiedener Software-Firmen zur Object Management Group (OMG) und der Veröffentlichung der Object Management
Architecture (OMA) ist die Grundlage für eine Infrastruktur verteilter, objektorientierter Systeme gelegt worden, deren Schwerpunkte in der Interoperabilität, Wiederverwendbarkeit und Portabilität von Software-Komponenten
liegen. Zu den Besonderheiten dieser Architektur gehört, daß Objekte in Anwendungen eingebunden werden können, ohne über deren Aufenthaltsort im
Netzwerk oder deren Realisierung – wie z. B. in einer spezifischen Programmiersprache – Kenntnis zu haben.
Kernstück dieser Architektur ist der Object Request Broker (ORB), der als
Vermittlungszentrale zwischen den Objekten dient. Er nimmt die Anfrage an
ein Objekt entgegen, lokalisiert das Objekt und übermittelt die Anfrage sowie
das Ergebnis der Operation.
Der ORB ist standardisiert worden unter dem Namen Common Object Request Broker Architecture (CORBA). Mit der zuletzt vorgestellten Spezifikation CORBA 2.0 ist es gelungen, einen Standard für die Kommunikation
zwischen Systemen verschiedener Hersteller auf heterogenen Plattformen zu
finden. Damit ist es erstmals möglich, daß Anwendungen auf Server-Dienste
fremder Software-Hersteller zugreifen, die unter unterschiedlichen Betriebssystemen arbeiten.
Ein weiterer Vorteil dieser Architektur ist, daß Anwendungen, die einen Service in Anspruch nehmen, auch gleichzeitig Dienste für andere Anwendungen
bereitstellen können. Somit ist die klassische Client-Server-Architektur durchbrochen; der Client wird gleichzeitig zum Server.
1
Alle Personenbezeichnungen sind geschlechtsneutral zu verstehen, auch wenn in dieser
Arbeit in der Regel die männliche Bezeichnung verwandt wird. Die Leserinnen mögen mir
dies verzeihen. Bitte lesen Sie die Benutzerin oder der Benutzer“.
”
Einleitung
3
Am Beispiel des in vorangegangenen Studienarbeiten entwickelten KonferenzManagement-Systems Confman2 sollen die Fähigkeiten der Common Object
Request Broker Architecture im Rahmen einer Technologiestudie herausgestellt und bewertet werden. Es wird eine Netzwerkerweiterung für Confman
entworfen, die auf die Dienste von CORBA aufbaut. Dazu ist eine Analyse
des Konferenz-Management-System notwendig.
Um die theoretischen Grundlagen von Netzwerkdiensten verständlicher zu
machen, wird eine kurze Einführung in die Mechanismen des Remote Procedure Call sowie ToolTalk gegeben. Auch das von Microsoft entwickelte Object
Linking and Embedding (OLE) wird kurz betrachtet, da es Ansätze für ein
verteiltes Objekt-Modell enthält. Anschließend werden die Fähigkeiten von
CORBA sowie des CORBA-basierten Entwicklungssystems Solaris NEO von
SunSoft vorgestellt.
Durch die momentan große Beliebtheit der Programmiersprache Java gewinnt eine weitere Entwicklung an Bedeutung, die die Verbindung zwischen
Java und CORBA-Objekten herstellt. Unter dem Namen Joe ist eine Erweiterung der Sprache Java angekündigt, die eine vollständige CORBAImplementierung beinhaltet. Auch diese Erweiterung wird kurz vorgestellt,
es können allerdings noch keine praktischen Erfahrungen festgehalten werden.
Im weiteren wird der Entwurf der CORBA-Erweiterung für Confman beschrieben, die in einem Prototypen realisiert worden ist. Den Abschluß dieser
Arbeit bildet eine Versuchsreihe mit Meßergebnissen, die das Zeitverhalten
des Prototypen der Confman-Erweiterung beschreiben.
2
Vergl. [Fri96] und [Ber94].
Kapitel 2
Analyse eines
Konferenz-Management-Systems
Am Lehrgebiet Rechnernetze und Verteilte Systeme (RVS) ist ein KonferenzManagement-System entwickelt worden, mit dessen Hilfe das Planen und Initiieren multimedialer Online-Konferenzen über das Internet sowie das Steuern laufender Konferenzen vereinfacht wird. 1 Im Vordergrund steht dabei die
Benutzerführung. Der Austausch der multimedialen Daten erfolgt über externe Werkzeuge.
Das im Rahmen von zwei Studienarbeiten enstandene System ist unter dem
Namen Confman veröffentlicht worden und wird z. Z. in der Version 1.1 distributiert.
Dieses System wird als Beispielanwendung für eine CORBA-Erweiterung vorhandener Software herangezogen. Dazu ist eine nähere Betrachtung des Systems erforderlich, bei der im besonderen die Punkte herausgestellt werden,
die in der erweiterten Fassung verbessert werden sollen.
Grundlage dieser Analyse ist das Produkt Confman, wie es zu Beginn dieser
Arbeit vorgelegen hat.2
1
2
Siehe hierzu die Arbeiten [Ber94] und [Fri96].
Confman Version 1.0 Beta Patchlevel 1.
4
Analyse eines Konferenz-Management-Systems
2.1
5
Funktionen des Konferenz-Management-Systems
Confman
Die wesentlichste Funktion von Confman ist, dem Benutzer an seinem Arbeitsplatz ein Hilfsmittel für die rechnergestützte, multimediale Kommunikation bereitzustellen, das den Komfort eines modernen Telefons bietet. 3
Die Kommunikation selbst findet über MBone-Tools4 statt. Confman übernimmt lediglich die Steuerung der Tools in einer laufenden Konferenz, ebenso
bietet es Hilfestellung bei der Planung einer Konferenz.
Die Planung von Konferenzen umfaßt das Festlegen der Start- und Stopzeit,
der zu benutzenden Tools und die Auswahl der Teilnehmer. Diese Daten
werden nach Abschluß der Planungsphase an alle Teilnehmer verteilt. Zur
Steuerung der Konferenz gehört das Starten und Beenden der MultimediaTools sowie das Einladen weiterer Teilnehmer.
Aus der Benutzung von Confman ergeben sich fünf Punkte, die in der Weiterentwicklung verbessert oder hinzugefügt werden sollen. Dabei handelt es
sich um
• die Arbeitsweise des Benachrichtigungssystems,
• das Ermitteln eines Konferenz-Servers,
• die Unterstützung von Konferenzen mir mehreren Servern,
• das Verwalten der Konfigurationsdateien sowie
• die Einbindung eines Terminkalenders.
Diese Punkte werden im folgenden näher betrachtet und daraus Ansätze für
die Erweiterung entwickelt.
2.1.1
Arbeitsweise des Benachrichtigungssystems
Finden des Kommunikationspartners
Im Gegensatz zum Telefon verbindet Confman Personen, nicht Nummern.
Alle Personen, die über Confman erreichbar sind, werden in Adreßbüchern“
”
3
4
Vergl. [Grü96].
Vergl. [Fro94].
Analyse eines Konferenz-Management-Systems
6
gespeichert, in denen neben dem Namen auch die Mail-Adresse festgehalten
wird sowie eine Liste der Rechner, an denen die Person häufig tätig ist.
Beim Anrufen einer Person bzw. beim Aufnehmen der Person in die Teilnehmerliste einer Konferenz werden alle Rechner in der Host-Liste abgefragt, ob
auf ihnen Confman mit der Kennung des Benutzers gestartet wurde. Wenn
ein Teilnehmer nicht gefunden werden kann, wird er über Mail eingeladen
und dazu aufgefordert, Confman zu starten.
In der Regel wird bei diesem Verfahren gewünschte der Kommunikationspartner mit großer Wahrscheinlichkeit gefunden. Es hat sich jedoch gezeigt, daß
das Verfahren dann nicht mehr handhabbar ist, wenn ein Benutzer an häufig
wechselnden Arbeitsplätzen arbeitet oder seinen Arbeitzplatz wechselt, ohne
dies vorher bekanntgegeben zu haben. In diesen Fällen geht Confman davon
aus, daß der Benutzer z. Z. nicht erreichbar ist.
Es erscheint daher sinnvoll, Personen auffinden zu können, ohne über deren Arbeitsplatz oder den Rechner, an dem sie arbeiten, Kenntnis haben zu
müssen.
Austausch von Konferenzdaten
Confman unterscheidet zwischen spontanen und zeitgesteuerten Konferenzen.
Eine zeitgesteuerte Konferenz zeichnet sich dadurch aus, daß ihr Startzeitpunkt in der Zukunft liegt und die Konferenzdauer festgelegt wird. Spontane
Konferenzen werden unmittelbar nach ihrer Einrichtung gestartet, ein vorzeitiger Austausch der Konferenzdaten ist hier nicht möglich.
Bei der Einrichtung einer zeitgesteuerten Konferenz ist es notwendig, die Konferenzdaten an alle Teilnehmer zu verteilen. Teilnehmer, die zu diesem Zeitpunkt nicht erreicht werden, werden über Mail benachrichtigt.
Da die Konferenzdaten bei den Benutzern lokal gehalten werden, sind Inkonsistenzen nicht auszuschließen. Die Teilnehmer können sich nur über Änderungen beim Konferenzleiter informieren, sofern dieser Confman gestartet
hat. Hier bietet es sich an, die Konferenzdaten zentral zu verwalten und
die Teilnehmer der Konferenzen über Änderungen direkt zu informieren. Bei
dem Programmstart von Confman ist so die Möglichkeit gegeben, sich über
zukünftige Konferenzen zu informieren, auch wenn der Konferenzleiter nicht
erreichbar ist.
Analyse eines Konferenz-Management-Systems
2.1.2
7
Ermitteln eines Konferenz-Servers
Eine Eigenschaft von Confman ist, geschlossene Konferenzen zu unterstützen.
Eine Konferenz wird als geschlossen bezeichnet, wenn die Daten nicht unmittelbar von Dritten empfangen werden können. Geschlossene Konferenzen mit
drei oder mehr Teilnehmern benötigen einen Konferenz-Server, der die Verteilung der Daten übernimmt.5
Ähnlich wie bei den Adreßbüchern wird eine Liste der Rechner geführt, die
als mögliche Konferenz-Server zur Verfügung stehen. Diese Liste wird von
Confman verwaltet und kann bei jedem Benutzer anders sein. Beim Start
einer Server-Konferenz wird anhand dieser Liste auf den Rechnern nach einem
geeigneten Konferenzraum“ 6 gesucht, der den entsprechenden Server startet.
”
Antwortet einer dieser Rechner nicht, so wird er als möglicher KonferenzServer übergangen. Wird kein Konferenzraum gefunden, kann die Konferenz
nicht gestartet werden.
In der Regel werden Konferenz-Server von Systemadministratoren eingerichtet, sie werden durch einen ständig aktiven UNIX-Prozeß repräsentiert. Damit
hat der Systemadministrator die Aufgabe, alle Benutzer über die Neueinrichtung bzw. die Deaktivierung von Konferenz-Servern zu informieren. Ohne
diese Information können Benutzer keine Server-Konferenzen starten. Auch
hier wäre eine Lösung sinnvoll, die das selbständige Auffinden von Servern
oder ggf. das Starten eines neuen Servers ermöglicht.
2.1.3
Unterstützung von Konferenzen mir mehreren Servern
In der vorliegenden Version bietet Confman nur die Möglichkeit, geschlossene
Konferenzen mit einem Server durchzuführen. Dies führt zu Problemen, wenn
mehrere Konferenzteilnehmer über eine Datenleitung mit geringer Bandbreite
oder hohen Paketverlusten angeschlossen sind.
Ein Beispiel für eine solche, ungünstige Situation ist eine Konferenz zwischen
zwei räumlich entfernten Institutionen, die jeweils mit mehreren Personen
an der Konferenz teilnehmen. Der Konferenz-Server kann nur in einer der
beiden Institutionen gestartet werden, somit werden alle Daten entsprechend
der Anzahl Teilnehmer der anderen Institution mehrfach übertragen.
5
An dieser Stelle wird davon ausgegangen, daß die Daten als Unicast-Pakete verteilt
werden. Eine Konferenz kann auch dann als geschlossen bezeichnet werden, wenn die Daten
per Multicast verteilt und verschlüsselt werden. Dies wird hier aber nicht berücksichtigt, da
bei Multicast-Konferenzen kein Server benötigt wird, Confman aber geschlossene UnicastKonferenzen unterstützen soll. Nähere Informationen hierzu in [Fri96].
6
Ein unter UNIX laufender Prozeß namens meetingroom, der den Konferenz-Server bei
Bedarf startet.
Analyse eines Konferenz-Management-Systems
8
Um die Übertragungswege nicht unnötig zu belasten, sollten die multimedialen Daten nur einmal zwischen den Institutionen ausgetauscht werden.
Die Verteilung der Daten an die Konferenzteilnehmer übernimmt jeweils ein
Konferenz-Server in jeder Institution. Daher sollte Confman in der Lage sein,
Konferenzen mit mehreren Servern zu unterstützen. Dabei sollte die günstigste Verteilungsstruktur von Confman selbständig ermittelt werden und die
Server entsprechend gestartet werden.
2.1.4
Verwalten der Konfigurationsdateien
Um die Nutzungsmöglichkeiten von Confman möglichst variabel zu halten, liest es viele Informationen aus Konfigurationsdateien, die zur Laufzeit
verändert werden können. Dies erweist sich nicht nur für die dynamische Konfiguration der Konferenz-Tools als sinnvoll, sondern es ermöglicht auch eine
reibungsfreie Anpassung an verschiedene Betriebssysteme und Administrationsstrategien.
Confman erlaubt es, mehrere Verzeichnisse anzugeben, aus denen die Konfigurationsdateien gelesen werden sollen. Dies ist für Mehrbenutzerumgebungen
sinnvoll, die eine systemweite Standardkonfiguration vorgeben, die von den
Benutzern individuell verändert werden kann. Dabei erhält der Benutzer für
die systemweiten Dateien nur Leserechte. Änderungen an der Konfiguration werden in einem benutzereigenen Verzeichnis - normalerweise unterhalb
seines Home-Verzeichnisses - abgelegt.
Wird dann die systemweite Konfiguration verändert, wirkt sich diese Änderung nicht auf die persönliche Konfiguration aus. Oft ist der Benutzer dann
genötigt, die eigenen Konfigurationsdateien zu löschen und somit die neue
Konfiguration zu laden. Die selbst eingebrachten Änderungen müssen dann
erneut eingegeben werden.
Hier bietet es sich an, die Daten in einem konsistenten Datensatz zu halten.
Werden an diesen Daten Änderungen vorgenommen, so werden alle Konferenzteilnehmer darüber automatisch informiert.
2.1.5
Einbinden eines Terminkalenders
Die Planung von Konferenzen erfordert Terminabsprachen mit allen Konferenzteilnehmern. Wenn nicht alle Teilnehmer erreichbar sind, kann die Planung umständlich werden. Dies kann durch die Einbindung eines Terminkalenders erleichtert werden.
Analyse eines Konferenz-Management-Systems
9
Der Terminkalender sollte die Möglichkeit unterstützen, Gruppen von Personen anzugeben, denen ein gemeinsamer Termin zugeordnet werden kann.
Außerdem sollte es möglich sein, bei einem persönlichen Termin einer Gruppe
mitzuteilen, welchen Zeitraum die Verhinderung in Anspruch nimmt. Dies ist
sinnvoll, um bei Abwesenheit eine Terminüberschneidung eines persönlichen
Termins mit einer Konferenz zu vermeiden. 7
Es muß eine Schnittstelle vorhanden sein, über die Confman mit dem Terminkalender in Kontakt treten kann.
2.2
Zusammenfassung der Analyse
Aus den oben angegebenen Betrachtungen ergibt sich das Ziel, von HostListen unabhängig zu sein. Benutzer und Konferenz-Server sollten in einem
Netzwerk selbständig gefunden werden, ohne Kenntnis über deren Aufenthaltsort zu haben. Dabei soll es möglich sein, die multimedialen Daten über
mehrere Server zu verteilen.
Weiter wird die Bereitstellung eines konsistenten Datenstammes angestrebt,
dessen Änderung allen Kommunikationspartnern mitgeteilt werden soll.
Durch die Einbindung eines Terminkalenders soll die Planung von Konferenzterminen vereinfacht werden, auch wenn nicht alle Konferenzteilnehmer in der
Terminfindungsphase erreichbar sind.
Da diese Ziele mit herkömmlicher Netzwerkprogrammierung nur unter
großem Aufwand zu erreichen sind, soll eine moderne Netzwerktechnologie
eingesetzt werden. Von besonderem Interesse ist hier das Konzept der Object
Management Group, die Object Management Architecture.
Um die Vor- und Nachteile dieser Architektur gegenüber herkömmlichen Konzepten abschätzen zu können, sollen zunächst der Remote Procedure Call,
sowie die Möglichkeiten vorgestellt werden, die sich aus dem Einsatz von
ToolTalk ergeben.
7
Dieses Thema wird auch ausführlich in der Literatur behandelt, die sich mit Groupware
beschäftigt. Vergl. [DiL94].
Kapitel 3
Klassische Mechanismen
Dieses Kapitel beschäftigt sich mit klassischen Methoden der Programmierung verteilter Systeme. Dabei wird zunächst der entfernte Prozeduraufruf
(Remote Procedure Call) betrachtet, der als Grundlage für verschiedene Netzwerkdienste dient und von einer großen Anzahl von Betriebssystemen und
Netzwerk-Produkten unterstützt wird.1 Ein weiterer Abschnitt beschäftigt
sich mit den Möglichkeiten zur Kommunikation mit Hilfe von ToolTalk, um
es für die Tauglichkeit der Einbindung eines Terminkalenders zu untersuchen.
3.1
3.1.1
Remote Procedure Call
Client-Server-Modell
Verteilte Systeme sind in der Regel unsymmetrisch. Es existiert ein Prozeß,
der Dienstleistungen anbietet (Server), und ein Prozeß, der eine Dienstleistung in Anspruch nimmt (Client). Der Client übermittelt an den Server eine
Anfrage, dieser antwortet mit den gewünschten Ergebnissen. Dieses Modell
wird Client-Server-Modell genannt (Abb. 3.1).
Anfrage
Client
Server
Ergebnisse
Abbildung 3.1: Das Client-Server-Modell
1
RPC ist als Transport-independent Remote Procedure Call (TI-RPC) in das Betriebssystem UNIX System V Release 4 (SVR4) eingegangen ist. Vergl. [SunS95k].
10
Klassische Mechanismen
11
Durch die Trennung von Client und Server auf verschiedene HardwareSysteme ist es somit möglich, zentrale Ressourcen zu verwalten. Dies wird
beispielsweise für Datei-Server-Dienste oder zentrale Namens- und Informationsdienste genutzt.2
3.1.2
Funktionsweise des Remote Procedure Calls
Nahezu alle Ansätze für die Entwicklung verteilter Client-Server-Systeme basieren auf der Aufteilung der Aufgaben auf verschiedene Module. Bei der
Behandlung von RPC werden sie auch Funktionen oder Prozeduren genannt.
Der Programmierer hat dabei zu entscheiden, welche der Prozeduren lokal
und welche auf einem entfernten System aufgerufen werden.
Das Ziel des Remote Procedure Calls ist es, einen entfernten Prozeduraufruf
so einfach wie einen lokalen zu gestalten. Für den Anwender bleibt dabei
verborgen, ob eine Funktion lokal oder auf einem anderen System ausgeführt
wird.
Zeit
Host A
Host B
Server
Prozess
Client
Programm
RPC Aufruf
Vorbereiten des
Funktionsaufrufes
Funktionsaufruf
Funktionsausführung
Ergebnis
Ende des
Requests
Rückgabe des Ergebnisses
Client setzt
Programmausführung fort
Abbildung 3.2: Netzwerkverbindung mit RPC
RPC ermöglicht den Aufruf von Funktionen auf entfernten Rechnern, wobei
die darunterliegenden Netzwerkmechanismen verborgen bleiben. Es stellt ein
logisches Client-Server Kommunikationssystem zur Verfügung, das speziell
2
Beispiele für diese Dienste sind das Network File System (NFS) oder das Network
Information System (NIS).
Klassische Mechanismen
12
Netzwerkanwendungen unterstützt. RPC ist unabhängig von der vorliegenden
Transportschicht. Obwohl hier in der Regel TCP/IP benutzt wird, sind auch
andere Protokolle nutzbar.
In Abb. 3.2 ruft der Client eine Funktion auf, die einen Request an den Server
sendet und den Client für weitere Programmabläufe blockiert. Wenn der Request den Server erreicht, führt dieser den Funktionsaufruf durch und wartet
das Ergebnis der Funktion ab. Dieses wird dann an den Client zurückgeschickt.
Client
Server
Anwendungsebene
Stub-Prozedur
Argumente
Stub-Prozedur
Ergebnis
Codieren
Ergebnis
RPC-Bibliothek
Argumente
Decodieren
Abbildung 3.3: Funktionweise des RPC
Die Transparenz der Netzwerkverbindung wird durch Bibliotheksfunktionen erreicht, die die Übertragung der Argumente über das Netzwerk, die
Ausführung der Prozedur und die Rückgabe des Ergebnisses übernehmen
(Abb. 3.3). Auf der Anwendungsebene erfolgt der Aufruf einer RPC-StubFunktion auf traditionelle Weise. Funktionen der RPC-Bibliothek sorgen für
die Konvertierung der Argumente in eine definierte Darstellungsform 3 und die
Übertragung der Daten auf den Server-Rechner. Dort wird die Konvertierung
in die lokale Darstellungsform durchgeführt und schließlich die gewünschte
Funktion aufgerufen. Entsprechend wird das Ergebnis zum Client zurückgeliefert. Die Erstellung von RPC-Funktionen wird in der Regel durch Entwicklungswerkzeuge unterstützt.4
3.1.3
ONC-RPC
Open Network Computing (ONC) ist der Ansatz der Firma Sun Microsystems,
Inc., für einen offenen Netzwerkstandard, der auf RPC aufbaut. ONC-RPC
3
Diese Darstellungsform ist architekturunabhängig und wird External Data Representation (XDR) bezeichnet. Vergl. [Sri95b].
4
So z. B. durch den RPC-Compiler rpcgen, wie weiter unten beschrieben.
Klassische Mechanismen
13
dient als Grundlage des Network File Systems (NFS) und Network Information Systems (NIS), es ist integraler Bestandteil der UNIX-Betriebssysteme,
die den Standard System V Release 4 erfüllen.5
RPC Programme folgen dem Client-Server-Modell. Sie bieten Netzwerkdienste ohne Kenntnisse über das darunterliegende Netzwerk an. Ein Beispiel ist
die Funktion rusers() aus der Bibliothek librpcsvc, die die Anzahl der
Benutzer auf entfernten Rechnern ermittelt. Dem Aufrufer der Funktion bleiben die Netzwerk-Aktivitäten weitgehend verborgen, er muß sich nicht mit
Transportmechanismen auseinandersetzen.
Im folgenden wird vorgestellt, wie die Programmierung eines verteilten Systems mit ONC-RPC erfolgt.6 Jede RPC-Funktion besitzt genau ein Argument und liefert genau ein Ergebnis. Wenn mehrere Argumente ausgetauscht
werden sollen, müssen sie zu Strukturen, Vektoren oder Feldern zusammengefaßt werden.
Für die Erstellung der Stub-Funktionen wird eine RPC-Protokolldefinitionsdatei benötigt. Sie enthält Informationen über die RPC-Funktionen und die
benutzten Datentypen.
/* Protokolldefinitionsdatei
*
* Author: Christrian Grimm <grimm@garfield>
*
* File:
rpc_demo.x
*
Fri Nov 19 1993
*
* (c) 1993 Lehrgebiet Rechnernetze und Verteilte Systeme
*
Universitaet Hannover, Germany
*/
struct pair {
int val1;
int val2;
};
program RPC_DEMO {
version FIRST {
int
REMOTE_ADD ( struct pair )
string REMOTE_DATE ( void ) = 2;
} = 1;
} = 0x31271966;
5
6
= 1;
/* Prozedurnummern */
/* Versionsnummer */
/* Protokollnummer */
Vergl. [SunS95k].
Das hier vorgestellte Beispiel ist [Gri94] ab Seite 111 entnommen.
Klassische Mechanismen
14
Durch den Aufruf des RPC-Compilers rpcgen werden die Dateien rpc demo.h,
rpc demo clnt.c, rpc demo svc.c und rpc demo xdr.c erzeugt. Sie beinhalten die Definitionen der Stub-Routinen, die Client-Stub-Routinen, die ServerStub-Routinen und die Wandlungsroutinen für das Netzwerk-Datenformat.
Eine Beispielimplementierung der Server-Prozeduren zeigt der folgende Quelltext. Er wird zusammen mit den Server-Stubfunktionen und der RPCLaufzeitbibliothek zum Serverprogramm gebunden.
/* RPC-Serverprozeduren
*
* Author: Christrian Grimm <grimm@garfield>
*
* File:
rpc_serv.c
*
Fri Nov 19 1993
*
* (c) 1993 Lehrgebiet Rechnernetze und Verteilte Systeme
*
Universitaet Hannover, Germany
*/
#include <rpc/rpc.h>
#include "rpc_demo.h"
/* Standard include-Datei von SUN RPC */
/* von RPCGEN erzeugt */
int *remote_add_1 ( value )
struct pair *value;
{
static int result;
result = value->val1 + value->val2;
return ( &result );
}
char **remote_date_1 ( )
{
long timeval;
char *ptr;
timeval = time ( ( long * ) 0 );
ptr = ctime ( &timeval );
return ( &ptr );
}
Das Clientprogramm ruft die Stub-Funktionen aus den oben erzeugten Dateien auf. Diese sind nicht von lokalen Funktionsaufrufen zu unterscheiden.
Zusätzlich werden einige RPC-Funktionen benötigt, die den Verbindungsaufbau realisieren. Eine grafische Übersicht über die Entwicklungsschritte zeigt
Abb. 3.4.
Klassische Mechanismen
15
/* RPC-Client
*
* Author: Christrian Grimm <grimm@garfield>
*
* File:
rpc_clie.c
*
Fri Nov 19 1993
*
* (c) 1993 Lehrgebiet Rechnernetze und Verteilte Systeme
*
Universitaet Hannover, Germany
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include "rpc_demo.h"
int main ( argc, argv )
int argc;
char *argv[];
{
CLIENT
*cl;
char
*server;
struct pair
args;
int
*result;
char
**datum;
/* Standard include-Datei von SUN RPC */
/* von RPCGEN erzeugt */
/* RPC-Deskriptor */
/* Argument fuer remote_add_1 () */
/* Ergebnis von remote_add_1 () */
/* Ergebnis von remote_date_1 () */
if ( argc != 2 ) {
printf ( "Usage: %s hostname\n", argv [0] );
exit ( 1 );
}
server = argv [1];
if ( ( cl = clnt_create ( server, RPC_DEMO, FIRST, "udp" ) ) == NULL ) {
clnt_pcreateerror ( server );
exit ( 2 );
}
args.val1 = 12;
args.val2 = 7;
result = remote_add_1 ( &args, cl );
if ( result == NULL ) {
clnt_perror ( cl, server );
exit ( 3 );
}
printf ( "%s says: %d+%d=%d\n", server, args.val1, args.val2, *result );
datum = remote_date_1 ( NULL, cl );
if ( datum == NULL ) {
clnt_perror ( cl, server );
Klassische Mechanismen
16
exit ( 4 );
}
printf ( "Today’s date and time on host %s: %s", server, *datum );
}
Client
RPC-Stub
Server
rpc_demo.x
rpc_client.c
rpc_server.c
rpcgen
rpc_demo_svc.c
rpc_demo_clnt.c
rpc_demo_xdr.c
make
rpc_demo_.h
RPCLaufzeitbibliothek
rpc_client
make
rpc_server
Abbildung 3.4: Erzeugen RPC-basierter Systeme
3.1.4
Bewertung
Der Remote Procedure Call ist ein leistungsfähiges Werkzeug zur Programmierung verteilter Systeme, er setzt allerdings genaue Kenntnisse über die
Server voraus.
Bei Aufruf der RPC-Stub-Funktion wird der Name des Rechners benötigt,
der die Aufgabe des Servers übernehmen soll. Es besteht jedoch nicht die
Möglichkeit, nach Funktionen zu suchen oder Objekte in einem Netzwerk zu
lokalisieren. Damit bietet es nicht die Diensleistungen, die für die Erfüllung
der gestellten Aufgaben in der Analyse des Konferenz-Management-Systems
benötigt werden.
Klassische Mechanismen
3.2
17
ToolTalk
Zusammenarbeit zwischen verschiedenen Anwendungen ist für UNIX-Applikationen immer noch keine Selbstverständlichkeit. Konzepte wie der Remote
Procedure Call ermöglichen das Entwickeln verteilter Systeme, setzen aber
genaue Kenntnisse über den Server voraus. Mit dem ToolTalk-Service wird
eine standardisierte Schnittstelle angeboten, die die Kommunikation von Anwendungen untereinander ermöglichen soll.
Dabei dient der ToolTalk-Service als Vermittler zwischen den Anwendungen,
die auf dem Bildschirm des Benutzers dargestellt werden. Die Anwendungen
können auf unterschiedlichen Rechnern innerhalb eines Netzwerkes gestartet
werden.
Der ToolTalk-Service wurde von der Firma Sun entwickelt, wird aber zwischenzeitlich auch von anderen Herstellern UNIX-basierter Betriebssysteme
unterstützt.7
3.2.1
Arbeitsprinzip
Mit Hilfe des ToolTalk-Services können Anwendungen miteinander kommunizieren, ohne genauere Kenntnisse voneinander haben zu müssen. Grundlage
der Kommunikation sind Nachrichten, die von einer Anwendung erzeugt und
an den ToolTalk-Service gesandt werden. ToolTalk ermittelt den Empfänger
und liefert die Nachricht aus.
Anwendung
A
Anwendung
B
Anwendung
C
Anwendung
D
ToolTalk Service
Abbildung 3.5: Nachrichtenübertragung mit ToolTalk
ToolTalk-Nachrichten enthalten Attribute, anhand derer der Empfänger ermittelt werden kann, sowie der Empfänger erkennt, wie er auf diese Nachricht
7
So z. B. Hewlett-Packard, IBM und Silicon Graphics.
Klassische Mechanismen
18
reagieren soll.
Eine sendende Anwendung erzeugt eine neue Nachricht, füllt die Attribute mit
Werten und sendet sie dem ToolTalk-Service. Anwendungen, die Nachrichten
empfangen möchten, melden sich am ToolTalk-Service an und geben ein Muster vor, welche Arten von Nachrichten sie interessieren. Durch Vergleich der
Nachrichten-Attribute mit diesen Mustern entscheidet der ToolTalk-Service,
an wen diese Nachricht ausgeliefert wird.
ToolTalk unterstützt zwei Methoden zur Nachrichtenübermittlung: prozeßorientierte und objektorientierte Kommunikation. Bei der prozeßorientierten
Kommunikation werden Nachrichten an Prozesse adressiert. Anwendungen
können Nachrichten entweder an einen bestimmten Prozeß oder an einen bestimmten Typ von Prozessen senden. Somit besteht die Möglichkeit, daß existierende Anwendugen untereinander kommunizieren.
Mit der objektorientierten Kommunikation werden Nachrichten an Objekte,
die von Anwendungen verwaltet werden, übermittelt. Anwendungen können
Nachrichten erzeugen, die entweder an ein bestimmtes Objekt oder an einen
bestimmten Typ von Objekten gerichtet sind. Objektorientierte Kommunikation ist sinnvoll für Anwendungen, die ToolTalk-Objekte benutzen oder um
ToolTalk-Objekte herum entwickelt worden sind.
Im folgenden werden beide Kommunikationsarten detaillierter vorgestellt.
3.2.2
Prozeßorientierte Kommunikation
Bei der prozeßorientierten Kommunikation wird vom ToolTalk-Service ein
Nachrichtenkanal zur Verfügung gestellt, der Informationen oder Anfragen
für Funktionsaufrufe des empfangenden Prozesses übermittelt. Die prozeßorientierte Kommunikation stützt sich auf die Begriffe
• Prozesse
• Sitzungen
• Dateien
Ein Prozeß repräsentiert die Ausführung eines Programms, das ToolTalk benutzt. Dies entspricht einem UNIX-Prozeß, dem einige Zusatzinformationen
bekannt sind. Wenn eine Anwendung eine Verbindung zu ToolTalk aufbaut,
erhält es von diesem einen Prozeß-Identifikator (procid). Anwendungen, die
Klassische Mechanismen
19
eine Nachricht an einen bestimmte Prozeß senden möchten, benötigen dessen procid. Diese kann von einer vorher empfangenen Nachricht stammen, die
von ToolTalk automatisch mit dem Prozeß-Identifikator des Senders versehen
wird.
Um sich bei ToolTalk als möglicher Nachrichtenempfänger anzumelden, werden Nachrichtenmuster und Anleitungen zum Starten von Anwendungen in
einem Prozeßtyp (ptype) festgehalten. Die Prozeßtyp-Datei wird mit dem
ToolTalk type compiler (tt type comp) zum Zeitpunkt der Installation beim
ToolTalk-Service registriert.
Eine Gruppe von Prozessen, die auf dem gleichen Bildschirm des X-Window-Systems angezeigt werden, werden bei ToolTalk als Sitzung bezeichnet. Dazu gehört auch eine Instanz des ToolTalk-Kommunikationsprogramms
(ttsession).
Wenn ein Prozeß die Verbindung zum ToolTalk-Service aufnimmt, wird ihm
vom ToolTalk-Kommunikationsprogramm ein Prozeß-Identifikator zugewiesen. Die Sitzung, in der diese Zuweisung stattfindet, ist die voreingestellte
Sitzung für den Prozeß.
Das Konzept der Sitzung ist wichtig für die Nachrichtenübermittlung. Absender richten ihre Nachricht an eine Sitzung, und der ToolTalk-Service liefert
diese an alle Prozesse, deren Nachrichtenmuster in der aktuellen Sitzung angemeldet sind.
Eine Datei kann ebenso Empfänger einer Nachricht sein, so daß ToolTalk
sie an alle Prozesse ausliefert, die in ihrem Nachrichtenmuster Referenzen auf
diese Datei eingetragen haben, ohne dabei die Sitzung zu beachten.
3.2.3
Objektorientierte Kommunikation
Für das Verständnis von objektorientierter Kommunikation in ToolTalk ist
es notwendig, mit prozeßorientierter Kommunikation sowie dem Konzept von
ToolTalk-Objekten vertraut zu sein.
ToolTalk-Objekte
Ein ToolTalk-Objekt ist ein Teil von Daten einer Anwendung, für den eine ToolTalk-Objekt-Spezifikation erzeugt worden ist. Objekt-Daten werden
in zwei Teilen gespeichert, dem Objekt-Inhalt und der Objekt-Spezifikation
(Abb. 3.6). Der Objekt-Inhalt wird von der Anwendung verwaltet, die das
Klassische Mechanismen
20
Objekt erzeugt hat. Typischerweise handelt es sich dabei um einen oder mehrere Teile einer Datei, so z. B. einen Absatz, eine Funktion in einem Quellcode
oder einen Zellenbereich einer Tabellenkalkulation.
Objekt
Objekt Spez.
Datei
Objekt Inhalt
verwaltet vom ToolTalk-Service,
gespeichert in der ToolTalk-Datenbank
verwaltet von der Anwendung,
gespeichert in der Datei
Abbildung 3.6: ToolTalk-Objekt-Daten
Die Objekt-Spezifikationen werden ebenfalls von den Anwendungen erzeugt
und in einer Datenbank gespeichert, die von ToolTalk verwaltet wird. Dazu
wird das ToolTalk-Datenbank-Programm (rpc.ttdbserverd) benötigt.
Zur Objekt-Spezifikation gehören einige Standardeigenschaften, wie z. B. Objekttyp, Dateiname mit dem Objektinhalt und Objekteigentümer. Anwendungen können weitere Eigenschaften hinzufügen, wie z. B. die Position des
Objektes innerhalb der Datei. Somit können Objekte in Dateien identifiziert
werden, ohne das Dateiformat ändern zu müssen.
Wenn Nachrichten an Objekte adressiert werden, muß der ToolTalk-Service
wissen, an welche Anwendung die Nachricht ausgeliefert werden soll. Anwendungen unterstützen diese Informationen durch Objekttypen (otypes). Eine
Objekttyp-Datei enthält den Prozeßtyp der Anwendung, die dieses Objekt
verwaltet, und Nachrichtenmuster, die das Objekt betreffen. In diesem Nachrichtenmuster sind Anweisungen enthalten, wie der ToolTalk-Service bei Eintreffen einer Nachricht reagieren soll, wenn die Anwendung nicht gestartet ist.
ToolTalk kann dann die Anwendung starten oder die Nachricht verwerfen.
Die Objekttyp-Datei wird mit ToolTalk type compiler zur Anwendungsinstallation kompiliert, so daß die Informationen im ToolTalk-Service registriert
sind. Bei der Registrierung wird zunächst der Prozeßtyp benötigt, anschließend wird überprüft, ob der Objekttyp den Prozeßtyp beinhaltet.
3.2.4
ToolTalk-Architektur
Zur Kommunikation zwischen Anwendungen und der Verwaltung von Objektinformationen werden die folgenden ToolTalk-Komponenten benötigt:
Klassische Mechanismen
21
• ttsession ist der ToolTalk-Kommunikationsprozeß. Er wird auf jedem
Rechner gestartet und kommuniziert mit anderen ttsession-Prozessen,
wenn Nachrichten zu einer Anwendung einer anderen Sitzung übertragen werden müssen.
• rpc.ttdbserverd ist der ToolTalk-Datenbankserverprozeß. Er wird für
jede Festplattenpartition installiert, die Dateien von ToolTalk-Clients
oder ToolTalk-Objekte enthält.
• libtt ist die ToolTalk-Programmierschnittstelle, die von Anwendungen
benutzt wird, die ToolTalk-Funktionen benutzen.
Der ToolTalk-Service setzt auf SunSofts ONC-RPC für die Kommunikation
zwischen ToolTalk-Komponenten auf verschiedenen Rechnern auf.
Die Prozeß- und Objekttypen-Informationen werden in einer Classing
Engine8 gespeichert. Dateien und ToolTalk-Objektinformationen werden in
einer NetISAM-Datenbank gespeichert, die vom ToolTalk-Datenbankserverprozeß verwaltet wird. Die Classing Engine ist Bestandteil von OpenWindows, RPC und NetISAM werden vom Betriebssystem unterstützt. Abb. 3.7
zeigt eine grafische Darstellung der ToolTalk-Architektur.
Anwendung
libtt
Anwendung
Classing
Engine
libtt
Prozeß und
Objekttypen
ToolTalk Service
ttsession
rpc.ttdbserverd
Datei und
Objektdaten
ONC Remote Procedure Call
Abbildung 3.7: ToolTalk-Service Architektur
3.2.5
Bewertung
ToolTalk ist ein geeignetes Mittel zur Kommunikation zwischen Anwendungen, die in einer Arbeitssitzung“ zur Verfügung stehen. Es bietet die Basis,
”
die für die Einbindung eines Terminkalenders in das Konferenz-ManagementSystem benötigt wird.
8
Eine OpenWindows-Desktop-Datenbank.
Klassische Mechanismen
22
Mit dem Betriebssystem Solaris 2.5 und der grafischen Benutzeroberfläche
Common Desktop Environment (CDE) wird ein Kalender mitgeliefert, der auf
der Basis von ToolTalk Nachrichten empfangen und versenden kann. Er wird
jedoch nicht von allen Betriebssystemen unterstützt, so daß eine Integration
des Kalenders z. Z. nicht vorgesehen ist.
Für weitere Aufgaben – insbesondere bei der Lokalisation von Objekten –
scheidet ToolTalk jedoch aus. ToolTalk bietet zwar die Möglichkeit, Nachrichten an Objekte zu senden, jedoch versteht ToolTalk unter einem Objekt
stets den Inhalt einer Datei oder eines Teils davon. Damit ist es für die Erweiterung eines objektorientierten Systems ebenfalls ungeeignet.
3.3
Object Linking and Embedding
Object Linking and Embedding(OLE) ist als Standard für zusammengesetzte
Dokumente bekannt geworden, der von Microsoft entwickelt wurde. Während
sich die Version 1.0 auf das Zusammenfügen von Dokumenten aus Anwendungen unter Microsoft Windows beschränkte, zeigt die Version 2.0 Ansätze, die
auf ein verteiltes Objekt-Modell deuten.
Dieser Abschnitt beleuchtet die Fähigkeiten von OLE und stellt die Möglichkeiten dar, die es für die Entwicklung verteilter, objektorientierter Systeme
bietet.
3.3.1
Zusammengesetzte Dokumente mit OLE
OLE ist als Standard für zusammengesetzte Dokumente entwickelt worden.
Ein zusammengesetztes Dokument meint in diesem Zusammenhang, daß innerhalb einer Anwendung Dokumente einer anderen Anwendung integriert
werden können, ohne daß ein spezielles Format zum Austausch der DateiInformationen benötigt wird.
Ein Dokument kann in ein anderes eingebettet werden (embedding), es kann
aber auch über eine Referenz verbunden sein (linking). Ein zusammengesetztes Dokument wird als Container bezeichnet, das andere Objekte (auch Dokumente) beinhalten kann. Dabei kann ein eingebundenes Objekt wiederum
ein Container sein.
Mit OLE verfügen Anwendungen über die Fähigkeit, Dokumente verschiedenen Typs verwalten zu können. Microsoft bezeichnet diese Fähigkeit als
in-place activation, es können Änderungen an den Objekten einer anderen
Anwendung vorgenommen werden, ohne das Benutzer-Interface zu wechseln.
Klassische Mechanismen
23
Dabei paßt sich die Benutzerschnittstelle der Funktionalität des aktiven Objektes an, es ändert z. B. seine Menü- und Bildlaufleisten oder Stauszeilen.
Dahinter verbirgt sich die Integration von Teilen einer anderen Anwendung
in die bearbeitende Anwendung. Dies wird auch als application embedding
bezeichnet, eine Anwendung lädt Funktionen oder Objekte einer anderen Anwendungen und erweitert damit seine Funktionalitäten.
Die Basis von OLE ist das Component Object Model (COM). Es definiert die
Schnittstellen für den Zugriff auf OLE-Objekte. Damit ermöglicht es das Erzeugen von Software-Komponenten, die zwischen Anwendungen ausgetauscht
werden können.
Für die Definition der Schnittstellen existiert eine Beschreibungssprache, die
unabhängig von der Wahl der Programmiersprache ist.
3.3.2
Interprozeßkommunikation mit OLE
Für die Kommunikation zwischen Prozessen wird bei OLE auf den Remote
Procedure Call (RPC) zurückgegriffen. Microsoft setzt hier auf den Standard
des DCE-RPC, der um einige objektorientierte Fähigkeiten erweitert wurde. Die Interprozeßkommunikation ist z. Z. noch auf einen Rechner begrenzt,
die Kommunikation zwischen Rechnern ist erst für zukünftige Versionen angekündigt.9
Zu den weiteren Fähigkeiten des erweiterten Objekt-Modells gehört die
Transparenz, ob ein Objekt lokal oder auf einem entfernten Rechner gestartet wird. Ebenso sollen Multi-Threading und einfach zu erstellende ServerVerbindungen zu weiteren Objekten möglich werden.10
3.3.3
OLE/COM als Basis für verteilte Objekte
OLE/COM stellt die Nachfolge-Generation von OLE 2.0 dar, die Dienste wie
Namensdienst, Persistenzdienst und Datenübertragung zur Verfügung stellt.
COM ist in diesem Fall die Abkürzung für Common Object Model, das in
Zusammenarbeit mit Digital Equipment entstanden ist. Es ermöglicht die
Kommunikation zwischen dem Object Broker von Digital und OLE und stellt
damit die Verbindung zwischen Microsoft Windows und verschiedenen UNIXBetriebsystemen her.11
9
Vergl. [Mic95].
Vergl. [Mic96].
11
Vergl. [Dig94].
10
Klassische Mechanismen
24
Die Kommunikationsbasis zwischen OLE und Object Broker ist hier ebenfalls
der DCE-RPC. Der Object Broker wird einige Funktionen von OLE übernehemen, so daß das Referenzieren und Aktivieren von OLE-Objekten (und
damit von Anwendungen) möglich ist.
Digitals Object Broker basiert auf der Common Object Request Broker Architecture, so daß hiermit die Brücke zur Objekt-Welt der OMG geschlagen
wird.
Microsoft und Digital arbeiten daran, diese Technologie auf alle Betriebssystem-Plattformen zu portieren, die DCE-Dienste unterstützen.
3.3.4
Bewertung
OLE in der Version 2.0 ist nicht in der Lage, Objekte über die Rechnergrenze hinaus zu referenzieren. Dies wird erst mit zukünftigen Versionen von
OLE möglich sein. Die angekündigten Erweiterungen unterstützen eine objektorientierte, verteilte Umgebung. Diese beschränkt sich jedoch zunächst
auf Systeme, die als Plattformen für Microsoft Office dienen.12
Erst durch die Zusammenarbeit mit Digital Equipment und den Kommunikationsmöglichkeiten zwischen OLE und Digitals Object Broker werden
Systeme integriert, die nicht direkt von Microsoft unterstützt werden. Da
der Object Broker CORBA-basiert ist, lassen sich somit auch Brücken zu
CORBA-Objekten schlagen.
Die Haltung der Firma Microsoft ist hier ein wenig unklar, da sie sich als Mitglied der Object Management Group für eine Standardisierung von Objekten
in einer verteilten, heterogenen Umwelt einsetzt, andererseits mit OLE ein
eigenes Objekt-Modell vorantreibt, das in Konkurrenz zu den Bestrebungen
der OMG steht.
12
Vergl. [MoZ95].
Kapitel 4
Common Object Request Broker
Architecture
Im Jahre 1989 wurde von den Firmen 3Com Corporation, American Airlines,
Canon, Inc., Data General, Hewlett-Packard Company, Philips Telecommunication, Sun Microsystems und Unisys Corporation die Object Management
Group (OMG) ins Leben gerufen. Ziel dieses Konsortiums ist es, die Portabilität, Wiederverwendbarkeit und Interoperabilität von Software zu maximieren und eine Referenzarchitektur zu finden, auf der weitere Spezifikationen
aufsetzen können. Dabei sollen Objekte in Anwendungen integriert bzw. zur
Verfügung gestellt werden, unabhängig von ihrer Entwicklungsplattform und
-programmiersprache. Darüber hinaus soll für die Objekte verborgen sein, auf
welchen Netzknoten sich der Kommunikationspartner befindet.
So ist im darauffolgenden Jahr der Object Management Architecture Guide 1
veröffentlicht worden, der als Grundlage der weiteren Entwicklung gesehen
werden kann. Kern der Object Management Architecture (OMA) ist der Object Request Broker (ORB), der als erstes Element spezifiziert wurde. Seine zentrale Aufgabe ist die Übermittlung von Methodenaufrufen und deren Ergebnissen zwischen anfragendem und Zielobjekt. Er ist unter dem Namen Common Object Request Broker Architecture (CORBA) standardisiert
worden.2 Seitdem gibt es zahlreiche Entwicklungen, die auf der CORBASpezifikation aufsetzen.3 Die bekanntesten von ihnen sind SolarisNEO von
SunSoft, Inc., Hewlett-Packards Distributed Smalltalk, IBMs SOM/DSOM
und Ionas Orbix.4
1
Vergl.
Vergl.
3
Vergl.
4
Vergl.
2
[OMG92].
[OMG93].
[OMG95].
[SunS96a], [HP96], [IBM95] und [Ion96].
25
Common Object Request Broker Architecture
4.1
26
Object Management Architecture
Mit dem Referenzmodell der Object Management Architecture wird eine
Architektur zur Realisierung verteilter Anwendungen beschrieben. Wie in
Abb. 4.1 zu sehen ist, gliedert sich die OMA in vier Teile: den Object Request
Broker, Object Services, Common Facilities und Application Objects. Dabei
ist zu erkennen, daß der Object Request Broker die zentrale Rolle spielt.
Er bietet die Infrastruktur, die die Kommunikation zwischen Objekten unabhängig von deren Plattformen und Implementierungstechniken ermöglicht.
Mit den Object Services sind Komponenten zur Steuerung der Lebenszyklen
von Objekten standardisiert. Dazu gehören Schnittstellen zum Erzeugen, Kopieren, Verschieben und Zerstören von Objekten sowie zur Zugriffskontrolle.
Ebenso sind ein Persistenzdienst, der das Speichern von Objekten auf externen Speichermedien beschreibt, sowie ein Ereignismeldungsservice für die
asynchrone Meldung von Ereignissen definiert.
Die Common Facilities bieten allgemein nützliche Funktionen an, die in direkterem Bezug zum Benutzer stehen. Dazu gehören z. B. Drucken, Dokumentenverwaltung, Datenbanken und E-Mail-Funktionen. Sie sind allerdings
für ein CORBA-konformes Produkt – anders als bei den Object Services –
nicht unbedingt erforderlich.
Application Objects
Common Facilities
Object Request Broker
Object Services
Abbildung 4.1: OMA-Referenzarchitektur
Unter den Application Objects sind Anwendungen zu verstehen, die auf die
Funktionalitäten der Object Services und Common Facilities zurückgreifen.
Sie werden zur Zeit nicht von der OMG standardisiert.
Common Object Request Broker Architecture
4.2
27
Das OMG Objekt-Modell
Durch die Vielzahl der Entwickler in der OMG war es notwendig, eine gemeinsame Basis für Terminologien und das Verständnis von Objekten zu schaffen.
Aus diesem Grund definiert das OMG Objekt-Modell gemeinsame ObjektSemantiken, die die äußerlich sichtbaren Charakteristiken von Objekten in
einer standardisierten und implementierungsunabhängigen Weise spezifizieren.
Das OMG Objekt-Modell basiert auf den folgenden Grundbegriffen:
• Objekte
• Operationen
• Typen und Subtypen
Ein Objekt kann jede Art von Entität darstellen, so z. B. eine Person, ein Boot
oder ein Dokument. Operationen beziehen sich auf das Objekt und führen
bestimmte Aufgaben wie das Ermitteln des Geburtstages einer Person aus.
Alle Operationen, die mit einem Objekt verknüpft sind, charakterisieren die
Eigenschaften des Objekts.
Objekte werden als Instanzen von Typen erzeugt, so gesehen kann ein Typ als
ein Template für die Objekterzeugung angesehen werden. 5 Der Objekt-Typ
entspricht der Klasse in der Programmiersprache C++. Eine Instanz des Typs
Boot könnte sein: rotes Boot, 10 Meter lang, 6 Sitzplätze. Ein Typ charakterisiert die Eigenschaften seiner Instanz durch Beschreiben der Operationen,
die auf dieses Objekt angewandt werden können. Zwischen Typen können
Beziehungen bestehen: Ein Schnellboot kann aus der allgemeinen Form Boot
hergeleitet sein. Beziehungen werden durch Supertypen und Subtypen definiert. Dies entspricht den Basisklassen und abgeleiteten Klassen in C++.
Die Konzepte des OMG Objekt-Modells müssen von jedem System unterstützt werden, das auf CORBA aufsetzt. Dabei ist es möglich, das ObjektModell durch Erweiterungen um Funktionalitäten zu bereichern.6
4.3
Die Struktur eines Object Request Broker
Abb. 4.2 zeigt den Weg, den die Anfrage eines Clients an eine Objektimplementierung nimmt. Der Client ist hierbei die Entität, die eine Operation
5
6
Vergl. [Pra94b] für eine Definition des Begriffs Typ“.
”
Dieses wird ausführlich in [OMG92] beschrieben.
Common Object Request Broker Architecture
28
Client
Objektimplementierung
Anfrage
ORB
Abbildung 4.2: Eine Anfrage an ein Objekt durchläuft den ORB
eines Objektes ausführen möchte, die Objektimplementierung enthält den Code in Maschinensprache und die Daten für die Ausführung des Objekts. Der
Object Request Broker ist verantwortlich für das Auffinden der Objektimplementierung, die Vorbereitung zum Annehmen der Anfrage und den Datenaustausch zwischen Client und Objektimplementierung. Die Schnittstelle, die
dem Client bereitgestellt wird, ist dabei unabhängig von dem Aufenthaltsort
des Objekts, der Programmiersprache oder der Systemumgebung.
Die Struktur eines ORB wird in Abb.4.3 dargestellt. Die Schnittstellen zum
ORB sind durch die dunkler eingefärbten Boxen kenntlich gemacht, die Pfeile
zeigen an, ob eine Anfrage an den ORB herangetragen wird oder er selbst über
eine Up-Call“-Schnittstelle anfragt.
”
Schnittstellen zu Objekten können auf zwei Arten definiert werden. Zum einen
können sie in einer vorgegebenen Sprache statisch definiert werden, die als
Interface Definition Language (IDL) standardisiert worden ist. Sie beschreibt
Objekte und die Operationen, die mit diesem Objekt verknüpft sind.7
Die Definitionen einer Schnittstelle können in einem Interface Repository gespeichert werden, um so andere Komponenten auf dieses Objekt aufmerksam
zu machen. Damit kann zum andern realisiert werden, daß diese Komponenten auf das neue Objekt zugreifen können, ohne bei deren Entwicklung von
dem Objekt Kenntnis gehabt zu haben. Dies wird über den dynamischen
Aufruf realisiert.8
7
8
Siehe 4.4.
Siehe 4.5.
Common Object Request Broker Architecture
29
Client
dynamischer
Aufruf
IDL
Rumpf
Objektimplementierung
ORB
Schnittstelle
IDL
Skelett
Objekt
Adapter
ORB
Bei allen ORB-Implementierungen identische Schnittstelle
Normale Schnittstelle
Objekt Adapter sind mehrfach vorhanden
Rumpf und Skelett sind vom Objekt abhängig
Up-Call Schnittstelle
ORB abhängige Schnittstelle
Abbildung 4.3: Schnittstellen des Object Request Broker
Clients können für Anfragen den dynamischen Aufruf oder den IDL-Rumpf 9
verwenden. Die Schnittstelle für den dynamischen Aufruf ist für alle Objekte
identisch, der IDL-Rumpf stellt das spezielle Interface des Objektes dar. Für
bestimmte ORB-Funktionen benutzt der Client direkt die Schnittstelle des
ORB.
Die Objektimplementierung empfängt die Anfrage durch das aus der IDL
erzeugte Skelett10 . Während der Bearbeitung der Anfrage kann die Objektimplementierung Funktionen des Object Adapters oder des ORBs aufrufen.
Der Client benötigt für eine Anfrage den Zugriff auf eine Objektreferenz. Er
muß daher von der Art des Objektes sowie der Operation, die er ausführen
möchte, Kenntnis haben. Die Anfrage kann über den Aufruf der RumpfRoutinen ausgeführt werden, der Aufruf kann aber auch dynamisch konstruiert werden (Siehe Abb. 4.4).
Unter einem dynamischen Aufruf ist zu verstehen, daß der Client zur Laufzeit nach verfügbaren Objekten suchen kann und Operationen auf Objekte
ausführt, die zum Zeitpunkt der Entwicklung des Clients noch nicht verfügbar
waren. Der Aufruf über Stub-Routinen kann durchaus mit den Mechanismen
9
10
In der Literatur wird auch häufig der englische Begriff Stub verwendet.
Im englischen wird der Begriff Skeleton verwendet.
Common Object Request Broker Architecture
30
Client
Anfrage
dynamischer
Aufruf
IDL
Rumpf
ORB
Abbildung 4.4: Anfragemöglichkeiten eines Client
des Remote Procedure Call verglichen werden, nur wird hier nicht der Name
des Zielrechners benötigt.
Der ORB lokalisiert die Objektimplementierung und übermittelt ihr den Aufruf mit seinen Parametern über das IDL-Skelett (Siehe Abb. 4.5). Das IDLSkelett ist dabei abhängig vom Interface des Objektes sowie vom Object
Adapter. Für die Ausführung der Anfrage kann die Objektimplementierung
Funktionen des ORB über den Object Adapter in Anspruch nehmen. Nach
Beendigung der Operation werden Steuerdaten und Rückgabewerte an den
Client zurückgegeben.
Für die Objektimplementierung ist es unerheblich, ob die Operation aus einem dynamischen oder statischen Aufruf ausgeführt wurde, beide Aufrufmethoden bieten die gleiche Funktionalität.
4.4
Interface Definition Language
Ein wesentliches Ziel im Entwurf der CORBA-Architektur ist die Programmiersprachenunabhängigkeit von CORBA-Objekten und deren Clients. Daher
ist für die Definition von Schnittstellen eine eigene Sprache entwickelt worden,
die den Namen Interface Definition Language (IDL) erhalten hat. 11 Auffallend ist ihre Ähnlichkeit mit der verbreiteten Programmiersprache C++, al11
Da es mehrere Sprachen zur Beschreibung von Schnittstellen gibt, die den Namen Interface Definition Language tragen, sind hier leicht Verwechslungen möglich. In dieser Arbeit
ist aber immer die IDL gemeint, die von der OMG standardisiert wurde.
Common Object Request Broker Architecture
31
Objektimplementierung
Anfrage
IDL
Skelett
Object
Adapter
ORB
Abbildung 4.5: Eine Objektimplementierung empfängt eine Anfrage
lerdings enthält IDL ausschließlich Syntax zur Datenbeschreibung und keine
Anweisungskonstrukte. Sie ist detailliert in [OMG93] beschrieben, im folgenden sollen nur die wesentlichsten Merkmale der Sprache beschrieben werden.
4.4.1
Typenwerte
IDL unterscheidet Objekte und Werte anderen Typs. In Abb. 4.6 sind die
definierten Typenwerte aufgelistet. Any erlaubt das Verwenden typloser Argumente oder Resultate.
Value
Object Reference
Basic Value
Constructed Value
Struct
Short
Long
UShort
ULong
Float
Double
Char
String Boolean
Octet
Sequence
Enum
Abbildung 4.6: In IDL definierte Werte
Any
Union
Array
Common Object Request Broker Architecture
4.4.2
32
Module
Ein Modul kann mehrere Objekte zusammenfassen, aber selbst keine Operationen oder Attribute enthalten. Module werden über das Schlüsselwort
module definiert:
module DemoModule
{
interface a
{
...
};
interface b
{
...
};
};
4.4.3
Interface
Objekte werden über das Schlüsselwort interface definiert, sie können im
Gegensatz zu Modulen Attribute und Operationen enthalten.
interface demo
{
attribute Short value;
Short return_value();
};
4.4.4
Attribute
In Attributen können Daten eines Objektes gespeichert werden. Sie bezeichnen les- und schreibbare Werte. Attribute werden über das Schlüsselwort
attribute definiert. Sie können die oben angegebenen Werte annehmen. Einige Beispiele für Attribute sind:
interface attribute_demo
{
enum Colors {red, blue, green};
Common Object Request Broker Architecture
33
attribute String name;
attribute Colors pixelcolor;
};
4.4.5
Operationen
Operationen werden ähnlich wie in C++ definiert, allerdings muß bei Parametern angegeben werden, in welche Richtung sie gereicht werden sollen. Dafür
werden den Parametern die Schlüsselworte in, out oder inout vorangestellt.
interface a
{
attribute UShort value;
void set_value(in UShort new_value);
void get_value(out UShort output_value);
void add_to_value(inout UShort value_to_be_added);
};
In der Regel ist CORBA auf synchrone Nachrichtenübermittlung ausgerichtet. Dies bedeutet, der Aufrufer wartet immer solange, bis die Operation
vollständig abgeschlossen ist. Dies ist jedoch nicht immer sinnvoll, daher erlaubt die IDL-Notation durch das Voranstellen des Schlüsselwortes oneway
die asynchrone Bearbeitung der Operation:
oneway void perform_this_operation();
Voraussetzung für die Ausführung einer One-Way-Operation ist, daß die zugehörige Methode keine Werte zurückliefert.
4.4.6
Vererbung
Die IDL-Notation unterstützt auch einfache und mehrfache Vererbung, allerdings ist Implementierungsvererbung nicht möglich. Wird ein Interface von
einem anderen abgeleitet, so spricht man bei diesem vom Basis-Interface. In
dem folgenden Beispiel ist A das Basis-Interface von B und C, D ist ist wieder und C und hat somit auch A als Basis-Interface. Abb. 4.7
um abgeleitet von B
zeigt die Hierarchie grafisch.
interface A {...}
Common Object Request Broker Architecture
34
interface B: A {...}
interface C: A {...}
interface D: B, C {...}
A
B
C
D
Abbildung 4.7: Beispiel zur Mehrfachvererbung
4.5
Dynamic Invocation Interface
Das Dynamic Invocation Interface (DII) des ORB erlaubt das Erzeugen und
Aufrufen von Operationen von Objekten zur Laufzeit von Anwendungen, auch
wenn das Objekt zur Kompilierungszeit des Anwendungsprogramms noch
nicht existierte.
Dazu ist es notwendig, die IDL-Informationen der Objekte in einem Interface
Repository zu speichern. Dieses kann von Clients eingesehen werden, so daß
sie Informationen über alle verfügbaren Objekte erhalten.
Ein dynamischer Aufruf setzt sich zusammen aus einer Objektreferenz, einer
Operation und einer Liste von Parametern. Die implementierungsabhängigen
Aufruf-Prinzipien werden dabei vom ORB verdeckt. Die Parameter werden
an die Struktur NamedValue angepaßt, so daß sie unabhängig von ihrem Typ
werden. Die Struktur ist definiert als:
typedef unsigned long Flags;
struct NamedValue {
Identifier
name;
any
argument;
long
len;
Flags
arg_modes;
};
//
//
//
//
argument name
argument
length/count of argument value
argument mode flags
Sie ist Bestandteil des Moduls CORBA, so daß sie in IDL mit vorangestelltem
CORBA:: referenziert werden müssen.
Common Object Request Broker Architecture
35
In der Struktur NamedValue sind der Argumentname, der Argumentwert (als
Typ any), die Länge des Argumentes und eine Reihe von Argument-Flags.
Unter name wird der Parameter identifiziert, der Datentyp Identifier dient
zum Speichern alphanumerischer Zeichen. Mit dem Datentyp any können beliebige Datentypen gespeichert werden. Wegen der unterschiedlichen Längen
der Datentypen wird die Länge separat festgehalten. arg modes kann die
Werte CORBA::ARG IN, CORBA::ARG OUT oder CORBA::ARG INOUT annehmen,
je nachdem, in welche Richtung das Argument gereicht werden soll.
Für die Übergabe der Parameter wird die Referenz NVList benutzt, die als
Referenz auf NamedValue definiert ist. In der Programmiersprache C wird
NVList definiert als:
CORBA_NamedValue *CORBA_NVList;
Das vorangestellte CORBA symbolisiert das Modul CORBA.
Für den Aufruf einer Operation dient das Pseudo-Objekt Request aus dem
Modul CORBA, das wie folgt definiert ist:
module CORBA {
interface Request {
Status add_arg (
in Identifier
name,
in TypeCode
arg_type,
in void
*value,
in long
len,
in Flags
arg_flags
);
Status invoke (
in Flags
invoke_flags
);
Status delete();
Status send (
in Flags
invoke_flags
);
Status get_response (
in Flags
response_flags
);
};
};
//
//
//
//
//
argument name
argument datatype
argument value to be added
length/count of argument value
argument flags
// invocation flags
// invocation flags
// response flags
Common Object Request Broker Architecture
36
Zusätzlich zu den hier definierten Funktionen wird noch die Operation
create request benötigt, die auf jedes Objekt angewendet werden kann:
Status create_request (
in Context
ctx,
in Identifier
operation,
in NVList
arg_list,
inout NamedValue
result,
out Request
request,
in Flags
req_flags
);
//
//
//
//
//
//
context object for operation
intended operation on object
args to operation
operation result
newly created request
request flags
Mit dieser Funktion wird eine ORB-Anfrage erzeugt. Die Parameter für den
Operationsaufruf können über arg list angegeben werden, sie können aber
auch mit der Funktion add arg hinzugefügt werden.
Der Methodenaufruf erfolgt dann über die Funktion invoke. Mit delete wird
die ORB-Anfrage gelöscht und alle benutzten Speicherbereiche freigegeben.
Soll der Methodenaufruf nicht synchron ablaufen, kann er statt mit invoke
mit der Funktion send einberufen werden. send kehrt sofort zurück, ohne das
Ergebnis der aufgerufenen Funktion abzuwarten. Das Ergebnis kann später
mit get response nachgefragt werden. 12
4.6
Basic Object Adapter
Objektadapter dienen als Schnittstelle zwischen Objektimplementierungen
und Object Request Broker. Grundsätzlich sind verschiedene Implementierungen von Objektadaptern denkbar, sie müssen aber mindestens dem Standard des Basic Object Adapter (BOA) entsprechen.
Der BOA dient hauptsächlich dazu, Objekte administrativ ins CORBARahmenwerk zu integrieren. Im einzelnen bietet er folgende Funktionen:
• Erzeugung und Interpretation von Objektreferenzen
• Identifizierung und Authentisierung des jeweilig aufrufenden Client
• Aktivierung und Deaktivierung der Implementierung
• Methodenaufruf mit Hilfe des generierten Rumpfes
12
Weitere Information können [OMG93] entnommen werden.
Common Object Request Broker Architecture
37
Innerhalb eines CORBA-Rahmenwerkes werden Objekte mit einer eindeutigen Objektreferenz identifiziert. Der BOA erzeugt und verwaltet diese Referenzen.
Zur Aktivierung und Deaktivierung persistenter Objekte gehört, daß Daten
bei der Deaktivierung dauerhaft gespeichert werden müssen, z. B. auf Festplatten. Bei der Aktivierung müssen diese Daten wieder greifbar gemacht
werden.
Bei der Methodenaktivierung gibt es mehrere Varianten. Es ist möglich, jede
Methode eines Objektes mit einem eigenen Programm zu realisieren (Server per method), das dann vom BOA gestartet werden kann. Eine andere
Möglichkeit ist, jedes Objekt durch ein Programm zu implementieren (Unshared Server). Ein Programm kann aber auch ein Object und alle seine
Instanzen repräsentieren (Shared Server). Die Wahl dieser Mechanismen ist
in der CORBA-Spezifikation nicht näher aufgeführt, da sie stark von der jeweiligen Implementierung und dem Betriebssystem abhängig sind.
4.7
Object Services
Mit den Object Services sind eine Reihe verschiedener Dienste standardisiert
worden, die an dieser Stelle kurz vorgestellt werden:
• Naming Service: Objekte können beim Naming Service angemeldet
werden, so daß sie anhand ihres Namens lokalisiert werden können. Der
Naming Service ermittelt zu Objekten die zugehörige Objektreferenz.
• Event Service: CORBA stellt die Möglichkeit zur Übermittlung von
Ereignissen zwischen Erzeugern und Konsumenten zur Verfügung. Die
Übertragung findet asynchron über Ereigniskanäle statt.
• Life Cycle Service: Mit dem Life Cycle Service werden die Funktionen zur Erzeugung sowie zum Kopieren, Bewegen und Löschen von
Objekten bereitgestellt.
• Property Service: Dieser Service erlaubt das dynamische Verknüpfen
von Eigenschaften zu Objekten unabhängig von ihrer Schnittstellendefinition.
• Relationship Service: Hierüber können Beziehungen zwischen Objekten nach dem Entity-Relationship-Modell definiert werden.
• Persistence Service: Er dient zum dauerhaften Speichern und Laden
von Objekten auf bzw. von externen Speichermedien.
Common Object Request Broker Architecture
38
• Concurrency Service: Paralleler Zugriff auf Objekte wird durch Standardmechanismen (Semaphoren und Locks) gesichert.
• Externalization Service: Er realisiert den Datenaustausch von Objekten nach Dateien außerhalb des Objektsystems.
• Transaction Service: Er enthält Techniken zur Durchführung transaktionsgesteuerter Abläufe unter Implementierung eines zweistufigen
Commit.
• Time Service: Der Time Service dient der Synchronisation von Uhren
in einer verteilten Umgebung.
• Security Service: Autorisierungs- und Überwachungsfunktionen auf
Objektebene werden hier zur Verfügung gestellt.
• Licensing Service: Hierin findet sich ein Rahmenwerk für die Spezifikation und das Management von Lizenzierungsdiensten und Benutzerüberwachung.
• Query Service: Hierunter verstehen sich Operationen auf Objektmengen, die eine prädikatenbasierte und deklarative Spezifikation besitzen.
Queries können als Ergebnis Objektmengen zurückliefern.
4.8
Bereitstellen von Objekten
Objektimplementierungen werden bei ihrer Installation am lokalen ORB angemeldet. Dabei werden Informationen über das Object in einem Implementation Repository gespeichert. Dieses wird benötigt zum Auffinden und Aktivieren der Implementierung bei Methodenaufrufen und zum Speichern zusätzlicher Informationen.
4.9
Interoperabilität
Mit der Verabschiedung der CORBA Spezifikation 2.0 im Dezember 1994 ist
die Grundlage für die Interoperabilität von Object Request Brokern verschiedener Hersteller gelegt. Dabei spielt die Fähigkeit von ORBs, auf CORBAObjekte zuzugreifen, die von anderen ORBs verwaltet werden, eine große
Rolle.
Um die Interoperalität zu gewährleisten, werden folgende Fähigkeiten
benötigt:
Common Object Request Broker Architecture
39
• die Möglichkeit, mit ORBs anderer Hersteller zusammenzuarbeiten, ohne deren Implementiertung zu kennen,
• die Unterstützung aller ORB Funktionalitäten und
• die Erhaltung von Inhalt und Semantik ORB-spezifischer Informationen
über ORB-Grenzen hinaus (z. B. Sicherheitsmechanismen).
Dieses bedeutet, daß ein Aufruf zwischen Client- und Server-Objekten davon unabhängig sein muß, ob sie bei einem oder bei verschiedenen ORBs
angemeldet sind.
Der Ansatz der Universal Networked Objects (UNO) 13 unterscheidet zwischen
Stand-Alone-ORBs und Networked-ORBs. Stand-Alone-ORBs entsprechen
den bisherigen CORBA-1.x-Implementierungen, die eine gemeinsame Umgebung für Objekte verwalten, aber nicht mit Produkten anderer Hersteller
zusammenarbeiten können. Networked-ORBs verfügen über Bridges, über die
nach definierten Kommunikationsprotokollen mit anderen ORBs Datenaustausch stattfinden kann. Die Aufgabe der Bridge besteht darin, den Aufruf
in das Format des Aufgerufenen zu konvertieren.
Dabei sind zwei Arten von Bridges definiert, die einen sind innerhalb des ORB
implementiert und werden In Line Bridges bezeichnet, die anderen entsprechen Erweiterungen außerhalb des ORB und heißen Request Level Bridges.
logische Client-Server Verbindung
Client
Server
(DII)
ORB Services
ORB Services
Kernel ORB
Kernel ORB
Abbildung 4.8: Kommunikation über In Line Bridges
In Line Bridges bieten eine direktere Möglichkeit, zwischen ORBS zu vermitteln (Abb. 4.8). Sie nutzen die speziellen Funktionen des ORB.
Eine Request Level Bridge benötigt keinen Zugriff auf ORB-interne Funktionen und bietet daher flexiblere Einsatzmöglichkeiten. Sie besteht aus
13
Vergl. [SunS94].
Common Object Request Broker Architecture
40
zwei Teilen, den Half-Bridges, die über CORBA-Schnittstellen angesprochen werden können (Abb. 4.9). Der Datenaustauch zwischen den HalfBridges erfolgt im General Inter-ORB Protocol (GIOP) oder im EnvironmentSpecific Inter-ORB Protocol (ESIOP). GIOP ist Bestandteil jeder CORBA2-Implementierung, ESIOP optional. In TCP/IP-Netzen wird das Internet
Inter-ORB Protocol (IIOP) verwendet, welches vom GIOP abgeleitet ist.
Sobald ein ORB mit einem anderen in Verbindung tritt, erzeugt die HalfBridge des aufrufenden stellvertretend für das aufrufende Objekt ein ProxyObjekt.
logische Client-Server Verbindung
Client
Server
Bridge
(DII)
DSI
(DII)
ORB Services
ORB Services
Kernel ORB
Kernel ORB
Abbildung 4.9: Kommunikation über Request Level Bridges
Auf der Empfängerseite wird ebenfalls ein Proxy-Objekt erzeugt. Diese steuern den Datenaustausch. Zum Ansteuern der Half-Bridge verwendet der Aufrufer das Dynamic Invocation Interface, auf Empfängerseite existiert eine
neue Komponente: das Dynamic Skeleton Interface (DSI). Dies erlaubt in
Analogie zum DII einem Server-Objekt das Empfangen von Nachrichten, ohne von dem aufrufenden Objekt Kenntnis zu haben.
Der ORB auf der Empfängerseite startet das Server-Objekt und sorgt für den
Aufruf der gewünschten Methode. Das Operationsergebnis wird dann über die
Bridge an den Client zurückgegeben.
Die CORBA-2-Spezifikation wird z. Z. nur von wenigen Anbietern CORBAkonformer Produkte unterstützt, so daß die Zusammenarbeit verschiedener
ORBs erst bei zukünftigen Implementierungen realisiert werden kann.
Common Object Request Broker Architecture
4.10
41
Bewertung
Mit der Common Object Request Broker Architecture wird eine Infrastruktur
für verteilte, objektorientierte Systeme angeboten, die das Lokalisieren von
Objekten im Netzwerk realisiert. Sie bietet Schnittstellen an, die Objekte
unabhängig von ihrer Implementierung zur Verfügung stellt.
Damit sind die Objekte, die einmal im Netzwerk bereitgestellt sind, für alle
Anwendungen erreichbar unabhängig von ihrer Implementierung, ihrer Lokalität im Netzwerk und des Betriebssystems, unter dem sie arbeiten.
CORBA bietet alle Funktionalitäten, die für die Lösung der Aufgaben in
Kapitel 2 benötigt werden. Damit wird es als Basis für die Erweiterung des
Konferenz-Management-Systems herangezogen.
Kapitel 5
Eigenschaften von Solaris NEO
Solaris NEO1 bietet eine Infrastruktur, die auf das Objekt Modell der Object Management Group aufbaut. Es stellt einen CORBA-konformen Object
Request Broker zur Verfügung und realisiert so das Auffinden und Aktivieren von Objekten in einem Netzwerk. Es unterstützt die folgenden CORBA
Services:
• Naming Service
• Event Service
• Life Cycle Service
• Property Service
• Relationship Service
Die Objektdaten werden in Solaris NEO bei einer Objektdeaktivierung in
einem Data Store Management“ gespeichert und bei der Aktivierung wie”
der eingelesen. Administrationswerkzeuge erlauben die Verwaltung der NEOUmgebung über Rechnergrenzen hinaus. Objekte und die dahinter stehenden
Objekt-Server-Prozesse lassen sich zur Laufzeit lokalisieren und verwalten.
Solaris NEO ist eine Weiterentwicklung des Sun-internen Projektes DOE
(Distributed Objects Everywhere/Distributed Objects Environment), es handelt sich dabei um eine Erweiterung des Betriebssystems Solaris 2.4. NEO
1
Entgegen manchen Vermutungen handelt es sich bei der Bezeichnung NEO nicht um
eine Abkürzung.
42
Eigenschaften von Solaris NEO
43
1.0 beinhaltet nur die Infrastruktur für verteilte Objekte, die Integration von
OpenStep Desktop mit seinen Objekt-Klassen ist für eine spätere Version
angekündigt.
Die Entwicklungsumgebung für NEO-Objekte wird unter dem Namen
Workshop NEO angeboten und beinhaltet einen IDL-Compiler, der IDLSchnittstellen in Quelltext der Sprachen C und C++ umsetzt sowie
einen DDL-Compiler, der die Beschreibung von persistenten Daten in
NEO-Objekten unterstützt. Beide entsprechen den CORBA-Spezifikationen.
Darüber hinaus bietet es Entwicklungswerkzeuge zur Vereinfachung der Implementierung von NEO-Objekten. Workshop NEO basiert auf den Entwicklungsumgebungen für C und C++ von SunSoft.
Da die Erweiterung des Konferenz-Management-Systems Confman auf der
Basis von Solaris NEO vorgenommen worden ist, beschäftigt sich dieses Kapitel mit dessen Eigenschaften. Dadurch soll das Verständnis für die Programmierung mit NEO vermittelt werden. Anhand eines Beispiels wird erläutert,
wie auf NEO-Objekte zugegriffen werden kann, wie sie selbst implementiert
und installiert werden und wie Objekte in einem Netzwerk lokalisiert werden.
Als Beispiel dient ein HelloWorld-Objekt, das eine Methode zum Ausgeben
einer Zeichenkette enthält, gleichzeitig einen Zähler verwaltet, der die Anzahl
der Aufrufe dieser Methode mitzählt. Der Zählerstand kann über eine zweite
Methode abgerufen werden.
5.1
Begriffe
Zunächst ist die Klärung einiger Begriffe erforderlich, die im folgenden als
bekannt vorausgesetzt werden. Die Begriffe werden im englischen Original
verwandt, da sie auch im Umgang mit Solaris NEO wieder anzutreffen sind
und daher eine Übersetzung nicht sinnvoll ist.2
Naming Context: NEO-Objekte können in einem Naming Context zusammengefaßt werden. Dadurch werden logische Gruppierungen von Objekten realisiert, Objekte können jederzeit eingefügt oder gelöscht werden.
Dies ermöglicht das Auffinden von Objekten, die erst zur Laufzeit erzeugt werden.
Name Space: Bezeichnet eine Gruppierung von Naming Contexts.
Service: Ein NEO-Objekt, das Dienstleistungen anbietet, wird als Service
bezeichnet. Es wird im Naming Context /machine/services initiali2
Detaillierte Beschreibungen zu den Begriffen können [SunS95e] und [SunS95i] entnommen werden.
Eigenschaften von Solaris NEO
44
siert, wenn es Dienste für den lokalen Rechner anbietet. Im Naming
Context /workgroup/services kann der Dienst von allen Rechnern
der Arbeitsgruppe in Anspruch genommen werden.
Factory Object: Hiermit wird ein Objekt bezeichnet, das andere NEOObjekte eines bestimmten Typs erzeugt. Die Factory selbst wird bei
der Installation erzeugt.
User Program: Hierunter ist eine Anwendung zu verstehen, die mit Objekten über NEO kommuniziert und nicht von diesem gestartet wurde. In
der Regel wird sie von Anwendern oder aus einer anderen Anwendung
heraus gestartet.
User-Started Server: Ein Anwendungsprogramm, das von einem Benutzer oder aus einer anderen Anwendung heraus gestartet wurde, selbst
aber Objekte bereitstellt, die von anderen NEO-Objekten oder Anwendungsprogrammen referenziert werden können. Dies wird für die Dynamic Notification benötigt.3
Workgroup: Verschiedene Rechner werden in einer Arbeitsgruppe zusammengefaßt. Innerhalb der Workgroup können Objekte gemeinsam genutzt werden.
5.2
Services und Name Space
NEO-Objekte, die Dienste anbieten, werden durch ihren Namen identifiziert.
Dieser Name und die dazugehörige Objektreferenz werden in einem gemeinsamen Namensraum festgehalten, dem Name Space. Äußerlich betrachtet
gleicht der Name Space einem Verzeichnisbaum, Abb. 5.1 zeigt eine typische
Struktur.
In der Abbildung ist der Namensraum einer Arbeitsgruppe mit zwei Computern dargestellt. So kann z. B. das Object EventFactory als /machine/services/EventFactory angesprochen werden, wobei /machine/services als Naming Context bezeichnet wird. In einem Naming Context können alle Arten
von NEO-Objekten abgelegt werden, so auch Services. Services werden üblicherweise im Kontext services abgelegt, so daß sie bei der Suche auffindbar
sind.
3
Siehe 5.5.
Eigenschaften von Solaris NEO
45
/ (root)
machine
services
Instanzenname
EventFactory
InterfaceRepository
NamingFactory
NodeFactory
PropertySetFactory
ReferencedByRoleFactory
ReferencesRoleFactory
ReportingCurrencyFactory
ServerAdminFactory
workgroup
admin
machines
services
Objektreferenz
<reference1>
<reference2>
<reference3>
<reference4>
<reference5>
<reference6>
<reference7>
<reference9>
<reference10>
servers
computer1
computer2
Confman
entspricht /machine
auf computer1
ConferenceMembers
Instanzenname
[email protected]
[email protected]
[email protected]
[email protected]
Conferences
Objektreferenz
<reference1>
<reference2>
<reference3>
<reference4>
Abbildung 5.1: Name Space: Namensraum von NEO-Objekten
5.3
Implementierung eines NEO-Objektes
Für die Entwicklung von NEO-Objekten ist es sinnvoll, Interface, Objektimplementierung und Client in verschiedenen Verzeichnissen zu entwickeln.
Im folgenden Beispiel wird das Interface im Verzeichnis ./include abgelegt,
die Objektimplementierung im Verzeichnis ./src/HelloWorldObject. Der
Client befindet sich im Verzeichnis ./src/helloworld.
5.3.1
Erzeugen und Registrieren des Interfaces
Um ein neues ORB-Objekt zu erzeugen, wird zunächst das Interface
benötigt. Das folgende Code-Segment enthält das in IDL geschriebene Interface des HelloWorld-Objektes, das hier und in den weiteren Schritten implementiert und ergänzt werden soll. Es ist unter dem Namen
./include/HelloWorld.idl abgelegt.
module HelloWorlds{
interface HelloWorld
{
string get_string();
short get_number_of_calls();
};
};
Eigenschaften von Solaris NEO
46
Das für die Registrierung des Objektes benötigte Imakefile sieht wie folgt aus.
Es befindet sich ebenfalls im Verzeichnis ./include.
PARAM_ODF_DIR=/opt/SUNWdoe/include/odf
/* Use ODF rules, targets and environment variables for building
programs */
include $(PARAM_ODF_DIR)/Makefiles/Makefile.odf
IDL_Library(HelloWorld)
Interface
Imakefile
HelloWorld.idl
odf
imake
Makefile
make
libHelloWorld.so
HelloWorld.ifr
internal files
odf_ouput/
HelloWorld.hh
Abbildung 5.2: Generierung des IDL-Stubs
Aus dem Imakefile wird mit dem Befehl odfimake das Makefile erzeugt, anschließend mit make die Übersetzung des IDL-Files in C und C++-HeaderFiles sowie die Generierung der dynamischen Bibliotheken vorgenommen.
Diese bilden den IDL-Stub und ermöglichen dem Client den Zugriff auf das
zu erzeugende Objekt. Der Befehl make register sorgt für die Registrierung
des Interfaces im Interface Repository und ist notwendig für die weitere Implementierung des Objektes. Eine grafische Übersicht der Schritte ist in den
Abb. 5.2 und 5.3 zu sehen.
5.3.2
Persistente Daten
Die oben angesprochene Zählervariable soll als persistentes Datum abgelegt werden, daher wird eine Datei zur Datenbeschreibung benötigt, die als
Eigenschaften von Solaris NEO
47
Interface
make
libHelloWorld.so
HelloWorld.ifr
internal files
odf_ouput/
HelloWorld.hh
make
register
IDL ist im
IFR registriert
Abbildung 5.3: Registrierung des Interfaces
./src/HelloWorldObject/HelloWorld.ddl gespeichert wird:
module HelloWorldDDL {
interface HelloWorldData {
attribute short count;
};
};
5.3.3
Erzeugen des Sample-Server-Codes
Für die weitere Implementierung des Server-Objektes ist es sinnvoll,
sich vom ODF-Compiler ein Quelltextgerüst erzeugen zu lassen, das
dann von Hand mit der gewünschten Funktionalität gefüllt wird. Dazu wird ein Implementation-File angelegt. In diesem Beispiel wird es als
./src/HelloWorldObject/HelloWorld.impl abgelegt und sieht wie folgt
aus:
import "HelloWorld.idl";
import "HelloWorld.ddl";
implementation HelloWorldImpl : HelloWorlds::HelloWorld {
persistence = HelloWorldDDL::HelloWorldData;
creator new_object();
Eigenschaften von Solaris NEO
48
service = "HelloWorldObject";
};
Das für die weitere Entwicklung benötigte Imakefile enthält die Angaben für
die Erzeugung der persistenten Daten sowie des Quelltextgerüstes. Es muß
auch der Pfad angegeben werden, in dem die aus dem Interface erzeugten
Header-Files und die dynamischen Bibliotheken zu finden sind.
/* This Imakefile builds the HelloWorldObject server */
PARAM_ODF_DIR=/opt/SUNWdoe/include/odf
/* Use ODF rules, targets and environment variables for building
programs */
include $(PARAM_ODF_DIR)/Makefiles/Makefile.odf
/* This program depends on the following IDL */
SERVER_HelloWorld_LIBS = Cos HelloWorld
/* The include files for the IDL */
INCLUDES += -I../../include -I../../include/odf_output
/* The development libraries for that IDL are found in ../include */
SERVER_HelloWorld_LIBPATH = $(PWD)/../../include
SERVER_HelloWorld_RUNPATH = $(PWD)/../../include
/* Generate code for the HelloWorld’s persistent data, according to
the DDL found in HelloWorld.ddl
*/
DDL_Schema(HelloWorld)
SERVER_HelloWorld_OBJECTS = DDL_Objects(HelloWorld)
/* Name the server program "HelloWorldObject" */
SERVER_HelloWorld_PROGRAM = HelloWorldObject
/* Build the HelloWorldObject program */
BasicServerProgram(HelloWorld)
Auch hier wird mit den Befehl odfimake das Makefile erzeugt, anschließend
mit make copy samples das Quelltextgerüst (C++-Quelltext), die Dateien
HelloWorldImpl.hh und HelloWorldImpl.cc, sowie einige interne Dateien
und Verzeichnisse generiert (Siehe Abb. 5.4).
Eigenschaften von Solaris NEO
Interface
HelloWorld.idl
49
Object Server
HelloWorld.ddl
HelloWorld.impl
Imakefile
odf
imake
Makefile
make
copy_samples
HelloWorldImpl.hh
HelloWorldImpl.cc
interne Dateien
odf_ouput/
HelloWorldImpl.hh
HelloWorldImpl.cc
Abbildung 5.4: Erzeugen des Sample-Server-Codes
5.3.4
Einfügen der Objekt-Funktionalität
Das oben erstellte Quelltextgerüst enthält alle Funktionen, die im IDLFile definiert worden sind, allerdings erzeugen sie die Fehlermeldung
NO IMPLEMENT. Daher ist es vor dem Ausführen weiterer Schritte notwendig, die C++-Quelltextdatei in einem Editor zu bearbeiten. In unserem
Beispiel kann die gewünschte Funktionalität durch Edieren der Funktionen
HelloWorldImpl::get string(), HelloWorldImpl::get number of calls(),
HelloWorldImpl:: initialize new object(), erreicht werden. Die folgende Quelltext-Datei ./src/HelloWorldObject/HelloWorldImpl.cc dient als
Beispiel für eine mögliche Implementierung.
//
// Sample C++ implementation for HelloWorld.impl
// Generated by odfcc version ODFBE_0.25 (version date: 18 Sep 1995)
//
#include "HelloWorldImpl.hh"
#include "odf_output/OdfHelloWorldImpl.hh"
#include "query_registration.hh"
//
// Member functions for HelloWorldImpl class
//
Eigenschaften von Solaris NEO
50
/******************************************************************/
// HelloWorldImpl::get_string
/******************************************************************/
CORBA::String
HelloWorldImpl::get_string(
)
throw(::CORBA::SystemException)
{
::CORBA::String function_result = "Hello World!\n";
// increase count variable
count += 1;
// return the hello string
return function_result;
}
/******************************************************************/
// HelloWorldImpl::get_number_of_calls
/******************************************************************/
CORBA::Short
HelloWorldImpl::get_number_of_calls(
)
throw(::CORBA::SystemException)
{
// return count variable
return count;
}
/******************************************************************/
// HelloWorldImpl::_initialize_new_object
/******************************************************************/
// Called from creator OdfHelloWorldImpl::new_object
void
HelloWorldImpl::_initialize_new_object()
{
count = 0;
}
5.3.5
Erzeugen und Registrieren des Server-Objektes
Nachdem die Quelltextdateien des Server-Objektes um die gewünschte Funktionalität erweitert worden sind, wird mit dem Befehl make das Server-Objekt
erzeugt. make register sorgt für die Registrierung als NEO Objekt und die
Bereitstellung in der Arbeitsgruppe. Abb. 5.5 zeigt die Schritte grafisch.
Eigenschaften von Solaris NEO
51
Interface
libHelloWorld.so
HelloWorld.idl
Object Server
HelloWorld.ddl
HelloWorld.impl
HelloWorldImpl.hh
Makefile
HelloWorldImpl.cc
make
HelloWorldClient
interne Dateien
und
Verzeichnisse
make
register
Server ist beim
ORB registriert
weitere
interne Dateien
Abbildung 5.5: Registrieren des Server-Objektes
5.4
5.4.1
Zugriff auf ORB Objekte
Auffinden von Diensten
Die Funktion ODF find bietet die Möglichkeit, NEO-Objekte innerhalb einer
Arbeitsgruppe von mehreren Rechnern zu lokalisieren. Dazu ist es notwendig,
den Namen zu kennen, unter dem das Objekt registriert wurde. ODF find
liefert die Referenz auf das Objekt zurück, damit kann es wie andere C++Objekte angesprochen werden. Für den Programmierer ist damit transparent,
wo sich das Objekt befindet und wie die Kommunikation über das Netzwerk
stattfindet.
5.4.2
Erzeugen des Client-Code
Das folgende Programm lokalisiert mit Hilfe der Funktion ODF find das NEOObjekt HelloWorld und benutzt dessen Methoden. Wenn bei der Lokalisierung des Objektes Fehler auftreten, so werden sie über die Exception abgefangen. Die Methodenaufrufe unterscheiden sich nicht von denen bekannter
C++-Objekte. Über die include-Direktive werden die Dateien odf.hh und das
vom IDL-Compiler erzeugte Headerfile HelloWorld.hh eingelesen. Das Programm wird unter dem Namen ./src/helloworld/HelloWorldClient.cc
gespeichert.
Eigenschaften von Solaris NEO
#include
#include
#include
#include
52
<stdio.h>
<iostream.h>
<odf/odf.hh>
"HelloWorld.hh"
int
ODF::application_main(int argc, char **argv, char **envp)
{
ODF_ObjRef<HelloWorld> hello;
try {
ODF_find(hello, "HelloWorld");
} catch (ODF::Service::Exception &exc) {
fprintf(stderr, "Cannot find HelloWorld\n");
return 1;
}
cout << hello->get_hello();
cout << "The get_hello function has been called for " <<
hello->get_number_of_calls() << " times.\n";
return 0;
}
Das Client-Programm wird mit dem Befehl make erzeugt. Dafür wird das
folgende Imakefile benötigt. Den grafischen Ablauf zeigt Abb. 5.6.
/* This Imakefile builds the helloworld client. */
PARAM_ODF_DIR=/opt/SUNWdoe/include/odf
/* Use ODF rules, targets and environment variables for building
programs */
include $(PARAM_ODF_DIR)/Makefiles/Makefile.odf
/* Also search ../include and ../include/odf_output for header
files. */
INCLUDES += -I../../include -I../../include/odf_output
/* This program depends on the following IDL */
CLIENT_helloworld_LIBS = HelloWorld
/* The libraries for development mode IDL are found in ../include */
CLIENT_helloworld_LIBPATH = $(PWD)/../../include
CLIENT_helloworld_RUNPATH = $(PWD)/../../include
/* .o files used in this program */
CLIENT_helloworld_OBJECTS = \
Eigenschaften von Solaris NEO
53
Obj/HelloWorldClient.o
/* Suppress inclusion of this directory’s binaries -- only the ones in
* DynamicNotification get packaged. */
CLIENT_helloworld_PACKAGE_OVERRIDE=1
PARAM_PACKAGING_DIR =
$(PWD)/../../packages
/* Build the helloworld program */
BasicClientProgram(helloworld)
Client
Interface
HelloWorldClient.cc
Imakefile
odf
imake
Makefile
libHelloWorld.so
interne Dateien
odf_ouput/
HelloWorld.hh
make
HelloWorldClient
interne Dateien
und
Verzeichnisse
Abbildung 5.6: Erzeugen des Clients
5.5
Dynamic Notification
Das oben erläuterte Beispiel beschreibt einen klassischen Fall eines ClientServer-Modells auf der Basis von Solaris NEO. NEO bietet jedoch auch die
Möglichkeit, Objekte von vom Benutzer gestarteten Anwendungsprogrammen
so bereitzustellen, daß sie von anderen Objekten, so auch von Objekt-Servern,
referenziert werden können. Die Anwendungsprogramme werden dann als
User-Started-Server“ bezeichnet.
”
Die Objekte der User-Started-Server werden nach ihrer Initialisierung bei
einem Server-Objekt in einer Liste mit ihren Referenzen angemeldet, so daß
sie dynamisch zur Laufzeit verfügbar sind. Andere Objekte können durch
Abfragen der Liste die Referenzen auf diese Objekte ermitteln.
Eigenschaften von Solaris NEO
54
Dies soll anhand eines Beispiels aus der CORBA-Erweiterung für Confman
verdeutlicht werden. In Abb. 5.7 ist das NEO-Objekt ConfmanClientObject
abgebildet, das die Liste mit den Referenzen verwaltet. Das Anwendungsprogramm ConfmanNEO, das auf beliebigen Rechnern gestartet werden kann,
erzeugt jeweils ein Callback-Objekt und meldet es bei ConfmanClients an. Die
Auszüge aus den Quelltexten sind dabei auf die für dieses Beispiel wichtigen
Funktionen reduziert worden.
ConfmanNEO
auf Host java.rvs.uni-hannover.de
ConfmanClientCallBack
hostname=java
ConfmanClientObject
auf Host borneo.rvs.uni-hannover.de
ConfmanClients
num_confman_clients = 3
confman_client[1] =
confman_client[2] =
confman_client[3] =
confman_client[4] = 0
confman_client[5] = 0
.
.
.
ConfmanNEO
auf Host molokai.rvs.uni-hannover.de
ConfmanClientCallBack
ConfmanNEO
auf Host kauai.rvs.uni-hannover.de
hostname=molokai
ConfmanClientCallBack
hostname=kauai
Abbildung 5.7: Dynamic Notification: Methodenaufruf von Client-Objekten
über Objektreferenzen
Die folgende Schnittstellenbeschreibung definiert das NEO-Objekt ConfmanClient, das die Liste der Callback-Objekte ConfmanClientCallBack verwaltet. Über die Methoden add confman client und remove confman client
können Callback-Objekte in die Liste aufgenommen bzw. gelöscht werden. Die
Methoden get num confman clients und get confman client callback
dienen zum Auslesen der Objektreferenzen aus der Liste.
#ifndef _CONFMANCLIENT_IDL
#define _CONFMANCLIENT_IDL
#include "ConfmanClientCallBack.idl"
module ConfmanClients{
exception TooMuchInterest{};
exception UnknownId{};
Eigenschaften von Solaris NEO
55
exception AlreadyExists{};
interface ConfmanClient {
// set the reference to the own ConfmanClientCallBack
unsigned long add_confman_client(in ConfmanClientCallBack confman_client)
raises(TooMuchInterest);
// delete ConfmanClientCallBack reference
void remove_confman_client(in ConfmanClientCallBack confman_client)
raises(UnknownId);
// return the number of Confman clienst
unsigned short get_num_confman_clients();
// return the ConfmanClientCallBack reference
ConfmanClientCallBack get_confman_client_callback(in unsigned long id);
};
};
#endif // !defined _CONFMANCLIENT_IDL
Die Liste, in der die Callback-Referenzen gespeichert werden, ist als Sequence 4
realisiert. Das Attribut num confman clients enthält die Anzahl der aktuell eingetragenen Referenzen. Die Liste sowie die Anzahl werden persistent
gespeichert und im folgenden Data-Definition-Language-File definiert.
#ifndef _CONFMANCLIENT_DDL
#define _CONFMANCLIENT_DDL
#include <Cos/Naming.idl>
#include "ConfmanClientCallBack.idl"
module ConfmanClientDDL {
const short max_clients = 128;
typedef sequence<ConfmanClientCallBack, max_clients> ConfmanClientCallBacks;
interface ConfmanClientData {
// list of users confman client callbacks,
// one for every confman he has started,
// and the number of clients
attribute ConfmanClientCallBacks confman_clients;
4
Eine Sequence ist ein IDL-Typenwert, siehe 4.4.1.
Eigenschaften von Solaris NEO
56
attribute unsigned short num_confman_clients;
};
};
#endif // !defined _CONFMANCLIENT_DDL
Die Callback-Objekte werden vom User-Started-Server“ erzeugt und beim
”
Server-Objekt angemeldet. Das ConfmanClientCallBack-Objekt enthält zwei
Methoden, die den Rechnernamen des Client-Hosts und den Benutzernamen
zurückgeben. Die Methode remove dient zum Entfernen des Objektes.
#ifndef _CONFMANCLIENTCALLBACK_IDL
#define _CONFMANCLIENTCALLBACK_IDL
interface ConfmanClientCallBack {
// return the users hostname
string get_hostname();
// return the user name
string get_username();
// remove the callback
void remove();
};
#endif // !defined _CONFMANCLIENTCALLBACK_IDL
Um eine Liste aller Callback-Objekte zu erhalten, kann mit der Funktion
ODF find die Referenz des Server-Objektes ConfmanClients ermittelt werden. Anschließend wird über die Methode get num confman clients die Anzahl der eingetragenen Callback-Objekte angefordert. Diese lassen sich somit
über die Methode get confman client referenzieren. Mit Hilfe des folgenden Programm-Segmentes lassen sich der Benutzer- und Rechnername aller
angemeldeten ConfmanClient-Callback-Objekte ausgeben. 5
void
get_all_confmanclients()
{
ConfmanClients::ConfmanClientRef confmanclient_ref;
ConfmanClientCallBackRef callback_ref = ConfmanClientCallBack::_null();
::CORBA::UShort number_of_callbacks;
5
Eine vertiefende Einführung bietet das NEO Tutorial [SunS95i].
Eigenschaften von Solaris NEO
57
// locate the ConfmanClient object
try {
ODF_find(confmanclient_ref, "ConfmanClients",
ODF::Service::WORKGROUP);
} catch (ODF::Service::Exception) {
cerr << "Unable to find ConfmanClients.\n";
confmanclient_ref = ConfmanClients::ConfmanClient::_null();
return;
}
// try to get the number of callback objects
try {
number_of_callbacks = confmanclient_ref->get_num_confman_clients();
} catch (CORBA::Exception) {
cerr << "Unable to get the number of callback references.\n";
return;
}
for (int i = 0; i < number_of_callbacks; i++) {
try {
callback_ref = confmanclient_ref->get_confman_client(i);
cerr << "ConfmanClientCallBack " << i << " created by "
<< callback_ref->get_username() << " at host "
<< callback_ref->get_hostname() << ".\n";
} catch (CORBA::Exception) {
cerr << "Callback reference " << i << " is not accessible.\n";
}
}
}
5.6
Probleme mit grafischen Benutzeroberflächen
NEO-Applikationen sind multi-threaded-Programme, d. h. die Programme
laufen in mehreren konkurrierenden Ebenen parallel ab. Multi-threadedProgramme benötigen multi-threaded-sichere (MT-sichere) Bibliotheken.
Viele Bibliotheken bieten diese Funktionalität jedoch nicht. Zu den MTunsicheren Bibliotheken gehört auch Motif, so daß dessen Benutzung undefinierte Zustände während der Programmausführung hervorrufen kann.
Um Motif in einer MT-Umgebung einsetzen zu können, müssen folgende
Punkte beachtet werden:
• Synchronisation: Das Hauptproblem MT-unsicherer Bibliotheken ist,
Eigenschaften von Solaris NEO
58
daß sie keine Mechanismen zur Synchronisation 6 von Funktionsaufrufen
besitzen. Es muß daher sichergestellt werden, daß keine zwei Aufrufe aus
diesen Bibliotheken parallel stattfinden. Dies kann über Semaphoren7
realisiert werden, die vor dem Aufruf der Bibliotheksfunktion angefordert und nach dem Beenden wieder freigegeben werden.
• Event Loop: Ein weiteres Problem mit grafischen Benutzeroberflächen
ergibt sich dadurch, daß das Programm sich ständig innerhalb einer
Schleife befindet, die die Event Loop genannt wird. Auch sie ist eine Bibliotheksfunktion, somit wäre der Zugriff auf weitere Bibliotheksfunktionen während der gesamten Laufzeits des Programms blockiert. Daher
ist eine eigene Event Loop notwendig, die den Zugriff freigibt, während
sie auf Ereignisse wartet.
• Deadlocks: Motif-Funktionen werden in der Regel zum einen direkt
aufgerufen, zum anderen aus Callback-Funktionen heraus. In beiden
Fällen ist das Sichern des exklusiven Zugriffs erforderlich. Bei gegenseitigem Aufruf der Funktionen muß deshalb vermieden werden, daß
die Semaphore innerhalb eines Threads mehrfach angefordert wird.
Dies würde zur vollständigen Blockierung des Programms, zu einem
Deadlock8 führen.
Eine Lösung dieser Probleme wird über die Klasse Baton9 angeboten. Sie
bietet über die Methoden grab und ungrab das Sichern des exklusiven Zugriffs
unter Vermeidung von Deadlocks sowie eine eigene Event Loop an.
Innerhalb der Event Loop wird über die Systemfunktionpoll auf Ereignisse
aus der X11-Umgebung gewartet. Damit können allerdings keine TimeOutCallback-Funktionen aus der Xt-Bibliothek benutzt werden, so daß eine
Umwandlung der Funktionalität in eigene Threads erforderlich ist. In der
Confman-Erweiterung ist dies beispielsweise für die Animation im Hauptfenster sowie die Uhr im Conferencemanager notwendig.
5.7
Bemerkungen
Solaris NEO in der vorliegenden Version entspricht der CORBA-Spezifikation
1.2. Es bietet ein Entwicklungssystem für CORBA-basierte Anwendungen,
das Multithreading unterstützt und somit dynamische Rückmeldungen von
Server-Objekten beim Anwendungsprogramm ermöglicht.
6
Vergl.
Vergl.
8
Vergl.
9
Vergl.
7
[Pra94a].
[Par93].
[Pra94a] und [Par93].
[SunS96b]. Baton heißt übersetzt: Taktstock.
Eigenschaften von Solaris NEO
59
In der Version 1.0 werden keine grafischen Benutzeroberflächen unterstützt,
was die Entwicklung von Anwendungen für das X-Window-System kompliziert.
Auch bei der Installation von Solaris NEO gibt es kleinere Schwierigkeiten.
Somit bleiben Wünsche offen, die hoffentlich im nächsten Release erfüllt werden.
Kapitel 6
Java und CORBA
Dieses Kapitel bietet einen kleinen Exkurs in die Welt des World-Wide-Web,
da sich hier einige Neuerungen zeigen, die für CORBA von größerer Bedeutung sein können. Im März 1996 hat die Firma SunSoft, Inc. ein Produkt
angekündigt, das die Verbindung zwischen Solaris NEO und Java herstellen
soll.
Dieses Produkt hat den Namen Joe erhalten, es befindet sich noch in der
Entwicklung. Eine frei verfügbare Beta-Version ist für Juni dieses Jahres angekündigt.1
Dieses Kapitel beschäftigt sich kurz mit der Entwicklung des World-WideWeb, mit der Sprache Java und der Integration von Java im WWW. Anschließend wird Joe vorgestellt.
6.1
Die Entwicklung des World-Wide-Web
In den vergangenen zwei Jahren hat sich das World-Wide-Web (WWW) als
bekanntester Dienst im Internet etabliert. Es stellt ein Informationsmedium
zur Verfügung, das dem Benutzer ein sehr weit gefächertes Angebot an Informationen bietet. Gleichzeitig wird dem Benutzer freigestellt, wann und wie
lange er welche Informationen erhalten möchte.
Aus dem Informationsmedium hat sich mit der Zeit ein Dienstleistungsangebot entwickelt, das sowohl Kundendienstleistungen (z. B. Aktualisierung von
Treibersoftware) als auch Bestellmöglichkeiten über das Internet realisiert.
1
Vergl. [SunS96d].
60
Java und CORBA
61
Durch die Verfügbarkeit grafischer Benutzeroberflächen, die das Heranholen
von Informationen mit einem einfachen Mausklick“ ermöglichen, ist die Be”
liebtheit dieses Dienstes explosionsartig gestiegen.
Die verfügbaren Informationen werden in Seiten gespeichert, die in der HyperText Markup Language (HTML)2 geschrieben sind. Diese werden über das
HyperText Transfer Protokoll (HTTP) 3 über das Netzwerk übertragen und
mit einem speziellen Programm am Arbeitsplatz des Benutzers aufbereitet.
Das derzeit am weitesten verbreitete Programm zum Aufbereiten von HTMLSeiten ist Netscape.4
6.1.1
Dynamisch generierte WWW-Seiten
Die ersten Versionen der Sprache HTML sahen nur vor, statische Seiten bereitzustellen. Eine Seite konnte nicht interaktiv vom Benutzer erzeugt oder
verändert werden. Mit der Einführung von HTML-Forms und CGI-Skripten 5
gab es die ersten Möglichkeiten, interaktive Elemente in WWW-Seiten zu
integrieren. Somit ist es möglich, Formulare zu erstellen, die Eingaben des
Benutzers erwarten, oder aus Datenbankabfragen neue Seiten zu generieren.
Für jede neue Seite ist hierbei ein HTTP-Request erforderlich, d. h. jede Seite
wird über das Netzwerk übertragen.
Mit der Entwicklung von Java und der Integration in das WWW ist es möglich
geworden, eigenständige Programme innerhalb des Benutzerprogramms ablaufen zu lassen, die unabhängig von dem Betriebssystem und der Architektur des Benutzer-Rechners sind. Die mit Java erstellten Programme (auch
Applets genannt) werden ebenfalls vom HTTP-Server übertragen. Sie reservieren sich einen bestimmten Bereich innerhalb des Fensters des Benutzerprogramms, den sie verändern können, ohne Daten über das Netzwerk zu
übertragen. Ein bekanntes Beispiel ist der winkende Duke, das Maskottchen
von Java.6
6.2
Java
Hinter dem Begriff Java verbirgt sich eine Programmiersprache, die für verschiedene Probleme moderner Programmierpraktiken entworfen wurde. Sie
2
Vergl. [BeL95b] und [RRZN95].
Vergl. [BeL95a].
4
Vergl. [Net96].
5
CGI ist die Abkürzung für Common Gateway Interface. Vergl. [Lem95].
6
Siehe Java-Homepage http://java.sun.com.
3
Java und CORBA
62
ist als Teil eines größeren Projektes entstanden, das ursprünglich in dem Bereich Consumer Elektronics“ angesiedelt war. Es verfolgte das Ziel, kleine,
”
zuverlässige, portable, verteilte Echtzeit-Systeme zu entwickeln. 7
Java ist entworfen worden, um Anwendungen über Netzwerke zu verteilen.
Um zu ermöglichen, daß Java-Applikationen auf allen Rechnern innerhalb eines Netzwerkes gestartet werden können, wird der Java-Quellcode von einem
Compiler in ein Hardware-unabhängiges Binärformat übersetzt, das als Architecture Neutral Distribution Format (ANDF) bezeichnet wird. Damit ist
die Voraussetzung für die Portierbarkeit der Applets geschaffen.
Für die Ausführung von Java-Programmen wird ein Interpreter benötigt,
der den Bytecode direkt ausführen kann. Es ist auch möglich, diesen beim
Start des Programms in die Maschinensprache des ausführenden Prozessors
zu übersetzen, um eine Steigerung der Performance zu erzielen (Abb. 6.1).
Entwicklung
Laufzeit
Interpreter
Quelltext
Compiler
Bytecodes
Prüfer
Weg durchs Netzwerk
oder Dateisystem
Lader
Code Generator
Abbildung 6.1: Der Weg eines Java-Applets
6.2.1
Integration von Java ins WWW
Java-Programme können – da sie maschinenunabhängig sind – über Netzwerke verteilt werden, zum Beispiel über das FTP- oder HTTP-Protokoll. Für die
Darstellung grafischer Ausgaben ist ein eigenständiges Programm notwendig,
ein sogenannter Appletviewer.
HotJava ist ein WWW-Client, der in Java geschrieben worden ist. Mit ihm ist
es möglich, Java-Applets direkt von einem HTTP-Server zu laden und sofort
darzustellen. Dies geschieht über das HTML-Tag app, über das das Applet
direkt in WWW-Seiten integriert werden kann. 8
Seit der Version 2.0 wird auch von Netscape die Ausführung von JavaApplets unterstützt, so daß sie damit auf allen gängigen Hardwareplattformen
ausführbar sind.
7
8
Vergl. [Sun95a].
Vergl. [Sun95c].
Java und CORBA
6.2.2
63
Java-Interpreter
Neben der Darstellung von Java-Applets in WWW-Clients besteht die
Möglichkeit, diese mit dem eigenständigen Interpreter java ablaufen zu lassen. Der Interpreter ist Teil des Java-Development-Kits, das z. Z. für verschiedene Plattformen angeboten wird. 9
Java-Programme, die im Interpreter laufen sollen, sind in ihrer Programmierung aber nicht identisch mit denen, die innerhalb eines WWW-Clients laufen
sollen. Sie werden daher hier nicht weiter betrachtet.
6.2.3
Java – Die Sprache
Java ist eine objektorientierte Sprache, die in vielen Punkten der Sprache
C++ ähnlich ist. Ihre Objekte werden durch Klassen definiert, die durch das
Schlüsselwort class deklariert werden. Vererbungen sind mit dem Schlüsselwort extends möglich, allerdings unterstützt Java keine Mehrfachvererbung.
Das folgende Beispiel beschreibt die Definition der Klasse HelloWorld, die
von Applet abgeleitet ist. In ihr sind die Methoden init und paint definiert.
Wird eine Klasse ohne Basisklasse definiert, erbt sie automatisch von der
Superklasse Object.
/**
* A Hello World Example applet for Java
*/
import java.awt.Graphics;
import java.awt.Font;
import java.awt.Color;
public class hello extends java.applet.Applet
{
Font f = new Font("TimesRoman, Font.BOLD, 36);
public void init()
{
resize(150, 25);
}
public void paint(Graphics g)
{
g.setFont(f);
9
So z. B. Solaris, Windows 95/NT und Linux.
Java und CORBA
64
g.setColor(Color.blue);
g.drawString("Hello World!", 50, 25);
}
}
Java unterstützt – wie in C++ – Konstruktoren, es kennt auch die Zugriffskontrollen mit Hilfe der Wörter public, private und protected. Anders als C++
verfügt es über eine Garbage Collection, die nicht mehr referenzierte Objekte
löscht.
Aus der Sprache Objective C sind Interfaces übernommen. Die in einem Interface definierten Methoden werden in der Klasse implementiert, die sie benutzt. Bei Interfaces ist Mehrfachvererbung möglich, folgender Quelltext zeigt
ein Beispiel.10
/**
* A Interface Example for Java
*/
public interface a
{
void method_from_a();
}
public interface b
{
void method_from_b();
}
public class c implements a, b
{
void method_from_a()
{
...
}
void method_from_b()
{
...
}
}
10
Genauere Informationen zur Sprache können [Sun95b] entnommen werden.
Java und CORBA
6.3
65
Joe – Verbindung zwischen Java und CORBA
Joe ist ein in Java geschriebenes Produkt, das die Verbindung zwischen
CORBA-basierten Anwendungen und dem World-Wide-Web herstellen soll.
Es stellt eine einfache Erweiterung der Programmiersprache Java dar und ist
somit für alle Plattformen verfügbar, die Java unterstützen.
Joe enthält einen Object Request Broker, der der Common Object Request
Broker Architecture der Object Management Group entspricht. Damit wird
die Kommunikation mit Solaris NEO ermöglicht, die als vorrangige Basis für
die Entwicklung komplexerer Anwendungen angesehen wird. 11 Der Joe-ORB
wird automatisch mit dem Applet vom WWW-Server geladen. Er stellt die
Verbindung zwischen dem lokalen Java-Objekt und dem entfernten CORBAObjekt her.
Dadurch können bereits bestehende Anwendungen und Objekte ins WWW
integriert werden, ohne neu geschrieben oder kompiliert werden zu müssen.
Java-Applett
WWW-Server
Datennetz
Netscape
Netscape
Some
Text
and blabla
CORBA-Objekte
Clients
CORBA-Objekte
Abbildung 6.2: Kommunikation zwischen Java-Applet und NEO-Objekten
Gleichzeitig findet eine Entlastung des WWW-Servers statt. Eine Anwendung, die einmal vom Server geladen worden ist, kommuniziert mit CORBAObjekten, die auf verschiedenen anderen Rechnern installiert sein können
11
Vergl. [SunS96e].
Java und CORBA
66
(Siehe Abb. 6.2). Dadurch wird die Aufgabe des WWW-Servers auf das Verteilen der Seiten beschränkt. Alle anderen Aufgaben, wie z. B. die Verbindung
zu einer Datenbank, werden von CORBA-Objekten auf anderen Rechnern
übernommen.12
Mit Joe wird die Interaktivität mit dem Benutzer gesteigert. Die Anwendungen greifen dynamisch auf Netzwerkdienste zu, so daß – anders als bei
HTML-Forms und CGI-Skripten – nicht bei jeder Benutzeraktion eine neue
WWW-Seite aufgebaut und über das Netzwerk übertragen werden muß.
Auf der Seite des Benutzers ist keine Administration notwendig, da das Programm vor der Ausführung vom Server neu geladen wird. CORBA-Objekte
können problemlos zur Laufzeit installiert und verwaltet werden.
Zwischen verschieden Java-Objekten bietet Joe die Möglichkeit, über das
CORBA-ESIOP-Protokoll zu kommunizieren. Für den Datenaustausch mit
ORBs anderer Hersteller wird das CORBA 2.0 IIOP unterstützt.13
Für die Entwicklung von CORBA-Objekten enthält Joe einen IDL-Compiler,
der Java-Quelltexte erzeugt. Die damit erstellte Java-Klasse enthält die StubFunktionen, die für die Kommunikation mit dem ORB benötigt wird und
damit den Zugriff auf entfernte Objekte ermöglicht, als wären sie lokale Java-Objekte. Der Java-Stub regelt den Aufruf des entfernten Objektes
einschließlich Datenkonvertierung, Netzwerkkommunikation und Aktivierung
des Serverobjektes. Aus den Stub-Funktionen und den Java-Quelltexten werden zusammen mit den Joe-Klassenbibliotheken Java-Applets mit Zugriff auf
CORBA-Objekte erzeugt (Abb. 6.3).
IDL to Java
IDL
Java
javac
Joe
Class
Library
Java-Applet
mit Joe
Java
Abbildung 6.3: Entwicklung eines CORBA-Objektes mit Joe
Der folgende Quelltext-Auszug verdeutlicht, wie mit einfachen Mitteln auf
bestehende NEO-Objekte zugegriffen werden kann. Das oben beschriebene
Beispiel zur Programmiersprache Java ist um 6 Programmzeilen erweitert
worden. Es werden die Services importiert, die für die CORBA-Erweiterung
benötigt werden. Desweiteren werden Variablen bereitgestellt, in denen das
12
13
Vergl. [SunS96e].
Siehe 4.9.
Java und CORBA
67
mit find lokalisierte NEO-Objekt aus dem vorherigen Kapitel referenziert
wird.
Die Klasse hello ist nicht mehr von java.applet.Applet abgeleitet, stattdessen
von sunw.services.JOEApplet. Das Ausgeben der Zeichenkette geschieht über
den Aufruf der Funktion get hello() des NEO-Objektes.
/**
* A Hello World Example applet for Joe
*/
import
import
import
import
sunw.services.*;
java.awt.Graphics;
java.awt.Font;
java.awt.Color;
public class hello extends sunw.services.JOEApplet
{
sunw.corba.ObjectRef obj;
Hello.HelloWorldRef hello_obj;
Font f = new Font("TimesRoman, Font.BOLD, 36);
public void init()
{
super.init();
resize(150, 25);
obj = find ("HelloWorldObject");
hello_obj = Hello.HelloWorldStub.narrow(obj);
}
public void paint(Graphics g)
{
g.setFont(f);
g.setColor(Color.blue);
g.drawString(hello_obj.get_hello(), 50, 25);
}
}
6.4
Bewertung
Joe ist noch in der Entwicklung. Zum Zeitpunkt dieser Arbeit ist noch keine
Version verfügbar gewesen, mit der die genannten Fähigkeiten getestet werden
konnten. Alle hier genannten Informationen sind Ankündigungen von SunSoft
entnommen.
Java und CORBA
68
Die Erfahrungen, die bisher mit Java gemacht worden sind, lassen jedoch darauf schließen, daß mit Joe ein sehr leistungsfähiges Werkzeug zur Integration
von CORBA-Objekten in das WWW vorliegen wird.
Es bleibt allerdings schwierig zu beurteilen, wie sicher die Anwendungen sind,
die mit Joe über das Netzwerk auf den lokalen Rechner geladen werden.
Gerade im Zuge der jüngsten Diskussionen über die Sicherheit von JavaApplets ist hier sicherlich Vorsicht geboten. 14
Weiter bleibt zu prüfen, ob Joe für den Einsatz in einem weltweiten Netz
geeignet ist, da eine Verbindung zu den CORBA-Objekten aufrecht gehalten
werden muß. Es scheint aber ein sehr geeignetes Mittel für den Einsatz in
lokalen Netzen zu ein.
14
Die aktuellen Sicherheitsprobleme sind in [Jav96] aufgelistet.
Kapitel 7
Entwurf einer CORBA-Erweiterung für
Confman
7.1
Entwurfsziele und Rahmenbedingungen
Ziel der Erweiterung des Konferenz-Management-System Confman ist es, eine
Realisierung für die in Kapitel 2 entwickelten Ansätze zu schaffen. Dabei ist
von besonderer Bedeutung, auf die Benutzung von Host-Listen zu verzichten.
Ebenso soll der Entwurf das selbständige Auffinden von Teilnehmern und
Konferenz-Servern in einem Netzwerk unterstützen.
Die vorangegangen Kapitel haben gezeigt, daß die Common Object Request
Broker Architecture als geeignetes Rahmenwerk für die Erweiterung angesehen wird. Dieser Entwurf stützt sich auf die CORBA-Implementierung Solaris
NEO von SunSoft, da diese als Entwicklungsumgebung zur Verfügung gestanden hat.
Die Einbindung eines Terminkalenders auf der Basis von Solaris NEO ist in
diesem Entwurf nicht mehr berücksichtigt worden, da kein derartiges Produkt
vorgelegen hat, und eine eigenständige Entwicklung im Rahmen dieser Arbeit
nicht zu leisten ist.
Die grafische Benutzeroberfläche von Confman ist dabei bewußt beibehalten
worden, in dieser Arbeit wird lediglich die Netzwerkerweiterung entworfen
und in die bestehende Benutzeroberfläche integriert.
69
Entwurf einer CORBA-Erweiterung für Confman
7.2
70
Umgebungsmodell
Daten
ConfmanBenutzerschnittstelle
Ereignisse
ConfmanCORBAErweiterung
steuert
KonferenzServer
startet, beendet
steuert
definiert
meldet
Ereignisse
multimediale Daten
steuert
KonferenzTeilnehmer
Audio-, Videound sonst. Daten
KonferenzWerkzeuge
Abbildung 7.1: Kontextdiagramm der Netzwerkerweiterung
Das Kontextdiagramm in Abb. 7.1 beschreibt das Umgebungsmodell der
Netzwerkerweiterung für Confman. Wie in der Abbildung zu erkennen ist,
wirken externe Ereignisse nur über die Benutzerschnittstelle auf das System
ein.
Aufgabe der Erweiterung ist, Ereignisse an andere Instanzen des Anwendungsprogramms weiterzugeben, Daten zwischenzuspeichern und die
Konferenz-Server zu steuern. Darüberhinaus werden in der Erweiterung die
Konferenzwerkzeuge definiert, die für die Durchführung einer Konferenz zur
Verfügung stehen.
7.3
Ereignistabelle
In der oben betrachteten Netzwerkerweiterung sind die folgenden Ereignisse
definiert:
1. Erstellen einer Liste aller anwesenden Konferenzteilnehmer
2. Erzeugen eines neuen Konferenz-Eintrages
3. Erzeugen eines neuen Konferenzteilnehmer-Eintrages
4. Erzeugen eines neuen Konferenzwerkzeug-Eintrages
5. Entfernen eines Konferenz-Eintrages
6. Entfernen eines Konferenzteilnehmer-Eintrages
7. Entfernen eines Konferenzwerkzeug-Eintrages
Entwurf einer CORBA-Erweiterung für Confman
71
8. Ändern von Daten an einem Konferenz-Eintrag
9. Ändern von Daten an einem Konferenzteilnehmer-Eintrag
10. Ändern von Daten an einem Konferenzwerkzeug-Eintrag
11. Erstellen einer Liste aller Konferenz-Einträge
12. Erstellen einer Liste aller Konferenzteilnehmer-Einträge
13. Erstellen einer Liste aller Konferenzwerkzeug-Einträge
14. Starten einer Konferenz
15. Beenden einer Konferenz
16. Automatisches Starten einer zeitgesteuerten Konferenz
17. Beitreten eines Teilnehmers zu einer Konferenz
18. Verlassen eines Teilnehmers einer Konferenz
Das Ereignis 16 ist als einziges zeitgesteuert, die übrigen Ereignisse sind flußorientiert.
Die Daten der Konferenzen, Konferenzteilnehmer und -werkzeuge werden innerhalb der Erweiterung gespeichert. Sie werden im Datenmodell detailliert
beschrieben. Im weiteren Entwurf ist dabei berücksichtigt worden, daß die
Benutzerschnittstelle über jede Änderung an den Daten benachrichtigt wird.
7.4
Datenmodell
In den Abbildungen 7.2 und 7.3 werden die Datenstrukturen für Konferenzen,
Teilnehmer und Konferenzwerkzeuge dargestellt. Ein Konferenzteilnehmer
wird charakterisiert durch seine Mail-Adresse, die ihn eindeutig bestimmt.
Die einzelnen Attribute werden im Datenverzeichnis näher erläutert.
nimmt
teil an
Konferenzteiln.
Mail-Adresse
Vorname
Name
Organisation
Position
Login-Name
Konferenz
Identifikator
Status
Titel
Dauer
Startzeit
Abbildung 7.2: ER-Diagramm Konferenzteilnehmer/Konferenz
Entwurf einer CORBA-Erweiterung für Confman
72
Konferenzen werden durch einen eigens erzeugten Identifikator eindeutig voneinander unterschieden. In einer Konferenz können verschiedene Werkzeuge
benutzt werden, die anhand ihres Namens identifiziert werden.
benutzt
Konferenz
Identifikator
Status
Titel
Dauer
Konf.-Werkzg.
Name
Ports
Skript
Signal
Startzeit
Abbildung 7.3: ER-Diagramm Konferenz/Konferenzwerkzeug
7.5
Datenverzeichnis
In den folgenden Datenverzeichnissen sind die Daten der Konferenzen, Teilnehmer und Konferenzwerkzeuge aufgenommen. Dabei handelt es sich im
wesentlichen um die Attribute, die zur Beschreibung einer Konferenz, eines
Konferenzteilnehmers oder eines Konferenzwerkzeuges benötigt werden.
Zusätzlich sind jewils die Listen definiert, bei der sich die Callback-Objekte
der User-Started-Server eintragen können.1 Zu diesen Listen werden Variablen geführt, die die Anzahl der Einträge in Liste festhalten.
Die Listen sind als Sequence2 realisiert worden, da für das Sichern über den
Persistenzdienst die Größe des Speicherplatzes benötigt wird.
7.5.1
Konferenzdaten
Das Datenverzeichnis der Konferenzdaten zeigt Tabelle 7.1. Die Attribute charakterisieren die Instanzen, die von dem Typ Conference erzeugt
werden. Dazu gehören neben einem eindeutigen Identifikator id der Titel der Konferenz title, die Startzeit starttime, Dauer duration und
der Status state (running, stopped, waiting, inactiv, autostart). 3 Die Liste der Teilnehmer sowie die Liste der Werkzeuge werden als Sequence
memberlist und toollist gespeichert, die Anzahl der jeweiligen Einträge ist den Variablen num confmembers und num conftools zu entnehmen. Über conference clients werden die Referenzen auf die Objekte
1
Siehe 7.6.2.
Siehe Abschnitt 4.4.1.
3
Vergl. [Fri96]. Dort ist auch Zustandsübergangsdiagramm abgebildet.
2
Entwurf einer CORBA-Erweiterung für Confman
Begriff
ConferenceData
id
title
starttime
duration
state
memberlist
num confmembers
toollist
num conftools
conference clients
num conference clients
Definition
*Entität ConferenceData*
@id+title+starttime+duration
+state+memberlist+toollist
+conference clients+
+num conference clients
*Konferenz-Id, eindeutig*
*Typ: unsigned long*
*Titel der Konferenz*
*Typ: String*
*Startzeit*
*Typ: unsigned long*
*Dauer der Konferenz*
*Typ: unsigned long*
*Status dieser Konferenz*
*Typ: unsinged short*
*Liste der Teilnehmer*
*Typ: Sequence of Strings*
*Anzahl der Teilnehmer*
*Typ: unsigned short*
*Liste der Konferenz-Tools*
*Typ: Sequence of Strings*
*Anzahl der Tolls*
*Typ: unsigned short*
*Liste der
ConferenceClientCallBacks*
*Typ: Sequence of
ConferenceClientCallBacks*
*Anzahl der Referenzen*
*Typ: unsigned short*
73
benutzt von
Conference
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
ConferenceData
Tabelle 7.1: Datenverzeichnis der Konferenzdaten
Entwurf einer CORBA-Erweiterung für Confman
74
ConferenceClientCallBack verwaltet. Die Variable num conference clients
enthält die Anzahl der Referenzen in conference clients.
7.5.2
Konferenzteilnehmerdaten
Von den Konferenzteilnehmern werden die Mailadresse mailaddress und
der Name seiner Benutzerkennung loginname als Daten für den Betrieb
von Confman benötigt. Optional können Vor- und Nachname (firstname
und lastname) sowie der Name der Organisation organisation und
die Stellung innerhalb der Organisation position angegeben werden.
conference clients enthält die Liste für die Verwaltung der CallbackObjekte sowie num conference clients deren Anzahl, Tabelle 7.2 zeigt das
Datenverzeichnis des Objektes.
Begriff
ConfMemberData
mailaddress
lastname
firstname
loginname
organisation
position
confmemb clients
num confmemb clients
Definition
*Entitität ConfMemberData
@mailaddress+name+firstname
+loginname+organistion
+position+confmemb clients
+num confmemb clients
*Mailadresse des Konferenz-*
teilnehmers
*Typ: String*
*Nachname*
*Typ: String*
*Vorname*
*Typ: String*
*UNIX-Kennung*
*Typ: String*
*Name der Organisation*
*Typ: String*
*Stellung in der Organisation*
*Typ: String*
*Liste von Referenzen auf
ConfMemberClientCallbacks*
*Typ: Sequence of
ConfMemberClientCallBacks*
*Anzahl der Referenzen*
*Typ: unsigned short*
benutzt von
ConfMember
ConfMemberData
ConfMemberData
ConfMemberData
ConfMemberData
ConfMemberData
ConfMemberData
ConfMemberData
ConfMemberData
Tabelle 7.2: Datenverzeichnis der Konferenzteilnehmerdaten
Entwurf einer CORBA-Erweiterung für Confman
7.5.3
75
Konferenzwerkzeugdaten
Begriff
ConfToolData
toolname
num ports
kill signal
run script
conftool clients
num conftool clients
Definition
*Entität ConfToolData* ConfTool
@toolname+num ports+kill signal
+run script+conftool clients
+num conftool clients
*Name des Konferenz-Tools*
*Typ: String*
*Anzahl benötigter Ports*
*Typ: unsigned short*
*Signal zum Beendigen*
*Typ: String*
*Name des Start-Skriptes*
*Typ: String*
*Liste der
ConfToolClientCallBacks*
*Typ: Array of
ConfToolClientCallBacks*
*Anzahl der Clients*
*Typ: unsigned short*
benutzt von
ConfToolData
ConfToolData
ConfToolData
ConfToolData
ConfToolData
ConfToolData
Tabelle 7.3: Datenverzeichnis der Konferenztooldaten
Das Datenverzeichnis der Konferenzwerkzeuge ist in Tabelle 7.3 dargestellt. Neben dem Namen des Werkzeugs toolname werden die Anzahl
der benötigten Ports num ports, das Signal zum Beenden des Tools
kill signal und ein Script zum Ausführen run script gespeichert. Auch
hier wird eine Liste für Callback-Objekte verwaltet (conftool clients und
num conftool clients).
7.6
Partitionierung der Ereignisse
In der Ereignispartitionierung werden die oben genannten Ereignisse erneut
aufgegriffen und die zu realisierenden Funktionen CORBA-Objekten zugeordnet. Diese werden in den weiteren Schritten näher spezifiziert. Ziel der
Spezifikation ist das Festlegen der Schnittstellen der Objekte. Für die grafische Darstellung der Objekte werden die Diagramme der Object Modeling
Technique4 benutzt.
Dieser Entwurf stützt sich auf den CORBA Naming Service, der das
selbständige Auffinden von Objekten unterstützt, und dem CORBA Persistence Service, der das automatische Sichern von Daten auf externen Spei4
Vergl. [Rum94].
Entwurf einer CORBA-Erweiterung für Confman
76
chermedien realisiert.5
7.6.1
Auffinden von Teilnehmern
Für das Auffinden von Teilnehmern wird auf das Konzept der Dynamic
Notification6 zurückgegriffen. Das vom Benutzer gestartete Anwendungsprogramm wird damit zum User-Started Server“, es stellt ein Callback-Objekt
”
bereit, das für andere Objekte, und somit auch für andere Anwendungsprogramme, ansprechbar ist. Damit kann beispielsweise der Name des Benutzers,
der das Programm gestartet hat, und der Name des Rechners, auf dem es gestartet wurde, ermittelt werden.
ConfmanClient
confman_clients
num_confman_clients
add_confmanclient()
remove_confmanclient()
ConfmanClientCallBack
get_hostname()
get_mailaddress()
new_conference()
remove_conference()
new_confmember()
remove_confmember()
new_conftool()
remove_conftool()
start_conference()
Abbildung 7.4: Objektmodell ConfmanClient
Für die Verwaltung der Referenzen dieser Objekte existiert das NEO-Objekt
ConfmanClient (Siehe Abb. 7.4), das über den Naming Service lokalisiert
wird. Die Callback-Objekte werden nach ihrer Erzeugung bei ConfmanClient angemeldet, der die Referenz in einer Liste speichert. Gleichzeitig wird
ein Zähler geführt, der der Anzahl der Referenzen in dieser Liste entspricht.
Die in ConfmanClient festgehaltenen Referenzen stehen allen Anwendungsprogrammen zur Verfügung, somit kann auf alle Callback-Objekte, und damit
indirekt auf die Anwendungsprogramme, zugegriffen werden.
7.6.2
Verwaltung der Daten
Die Daten der Konferenzen, Konferenzteilnehmer und Konferenzwerkzeuge
werden ebenfalls in NEO-Objekten festgehalten, die als Instanzen der ObjektTypen Conference, ConferenceMember und ConferenceTool erzeugt
werden (Siehe Abb. 7.5).
5
6
Siehe 4.7.
Siehe Abschnitt 5.5.
Entwurf einer CORBA-Erweiterung für Confman
ConferenceFactory
Conference
erzeugt
create_conference()
ConfMemberFactory
set_...()
get_...()
start_now()
stop()
add_conf_client()
rem_conf_client()
join()
leave()
ConferenceClientCallBack
hält Referenzen auf
ConfMember
erzeugt
create_confmember()
ConfToolFactory
set_...()
get_...()
add_confmember_client()
rem_confmember_client()
set_...()
get_...()
add_conftool_client()
rem_conftool_client()
new_...()
stop()
join()
leave()
ConfMemberClientCallBack
hält Referenzen auf
new_...()
ConfTool
erzeugt
create_conftool()
77
ConfToolClientCallBack
hält Referenzen auf
new_...()
Abbildung 7.5: Datenobjekte
Die Instanzen werden unter eindeutigen Namen im Namensraum der NEOWorkgroup in verschiedenen Naming Contexts abgelegt, damit sie später gesucht und zugeordnet werden können. Dafür wird ein Application Context7
Confman im Kontext services angelegt. Unterhalb dieses Kontextes werden die Application Subcontexts ConferenceMembers, ConferenceTools und
Conferences angelegt. Die Instanzen der Objekte werden in den Subkontexten angelegt, dadurch ist die Zuordnung der Namen zu den Objekt-Typen
vorgegeben. Abb. 7.6 zeigt die Kontexte und die Einbindung der ObjektInstanzen in einem typischen Namensraum.
Kontexte können jederzeit nach Objekten durchsucht werden, so daß auch neu
erzeugte Instanzen schnell gefunden werden können. Anwendungsprogramme
können zu den Objekt-Instanzen Callback-Objekte erzeugen, über die eine
mögliche Änderung an den Daten des betreffenden Objektes mitgeteilt werden.
Die Sicherung der Daten der Objekt-Instanzen erfolgt über den CORBAPersistenzdienst.
7
Ein Application Context ist ein Naming Context, der auf anwendungsbezogene Objekte
enthält. Siehe 5.2.
Entwurf einer CORBA-Erweiterung für Confman
78
/ (root)
machine
services
workgroup
admin
services
servers
ConferenceMembers
Instanzenname
Objektreferenz
[email protected]
[email protected]
[email protected]
[email protected]
<reference1>
<reference2>
<reference3>
<reference4>
Confman
Conferences
Instanzenname
vat
vic
wb
...
ConferenceTools
Objektreferenz
<reference1>
<reference2>
<reference3>
...
machines
computer1
computer2
ConferenceServer
Instanzenname
sumatra.rvs.uni-hannover.de
borneo.rvs.uni-hannover.de
oahu.rvs.uni-hannover.de
...
Objektreferenz
<reference1>
<reference2>
<reference3>
...
Abbildung 7.6: Objekt-Instanzen im NEO-Namensraum
7.6.3
Erzeugen und Entfernen von Datenobjekten
Die Instanzen der Objekt-Typen Conference, ConferenceMember und
ConferenceTool werden von Factory-Objekten erzeugt, die unter den Namen ConferenceMemberFactory, ConferenceToolFactory und ConferenceFactory registriert werden (Abb. 7.5). Diese werden im ServiceKontext der NEO-Arbeitsgruppe abgelegt.
Die Factory-Objekte verfügen über eine create-Methode, die ein neues Objekt erzeugt, anschließend alle Instanzen des Objektes ConfmanClientCallBack über das neue Objekt informiert. Daher verfügen die CallBack-Objekte
über die Methoden new conference, new confmember und new conftool.
Das Entfernen von Objekten wird von den Anwendungsprogrammen vorgenommen. Auch hier müssen alle Instanzen des Objektes ConfmanClientCallBack darüber informiert werden. Dies geschieht mit den removeMethoden.
7.6.4
Starten und Beenden einer Konferenz
Das Starten und Beenden einer Konferenz wird vom Konferenz-Objekt selbst
kontrolliert. Es kann über die Methoden start now und stop von anderen
Objekten eingeleitet werden.
Entwurf einer CORBA-Erweiterung für Confman
79
hält Referenzen auf
(ConfmanClient)
(ConfmanClientCallBack)
hostname=borneo.rvs...
mailadress=grimm@..
(ConfmanClientCallBack)
hostname=kauai.rvs...
mailadress=gruen@..
erfragt Referenzen
der ConfmanClientCallBack-Objekte
(ConfmanClientCallBack)
hostname=sumatra.rvs...
mailadress=berg@..
(Conference)
id=832934104
member=boeker@...,
gruen@...
(ConfmanClientCallBack)
hostname=java.rvs...
mailadress=boeker@..
Abbildung 7.7: Instanzendiagramm zum Konferenz-Start
Beim Konferenz-Start nimmt Conference Verbindung zu ConfmanClient
auf, um die Liste der Referenzen der ConfmanClientCallBack-Objekte zu
erhalten (Siehe Instanzendiagramm in Abb. 7.7). Diese enthalten eine Methode start conference, die bei allen Teilnehmern der Konferenz aufgerufen
wird. Die Instanzen des Benutzer-Programms ConfmanNEO erzeugen ein
neues Objekt ConferenceClientCallBack, das Änderungen an den Daten
der Konferenz an die Benutzer weitergibt (Abb. 7.8).
(ConfmanNEO)
beobachtet Conference
(ConferenceClientCallBack)
mymailaddress=
boeker@...
(ConfmanClientCallBack)
ruft start_conference auf
hostname=kauai.rvs...
mailadress=gruen@..
(ConfmanClientCallBack)
ruft start_conference auf
hostname=java.rvs...
mailadress=boeker@..
(Conference)
id=832934104
member=boeker@...,
gruen@...
beobachtet
Conference
(ConferenceClientCallBack)
mymailaddress=
boeker@...
(ConfmanNEO)
Abbildung 7.8: Einladen der Konferenzteilnehmer
Wird eine Konferenz mit stop beendet, so werden die Teilnehmer über eine
Methode stop des ConferenceClientCallBack-Objekts informiert.
Entwurf einer CORBA-Erweiterung für Confman
7.6.5
80
Starten einer zeitgesteuerten Konferenz
Der Objekt-Typ Conference verfügt über eine Methode invoke, mit deren
Hilfe ein Zeitgeber für den Start einer zeitgesteuerten Konferenz gestartet
wird. Die Startzeit wird aus den Konferenz-Daten ermittelt. Nach Ablauf des
Zeitgebers wird die Konferenz über die Methode start now gestartet.
7.6.6
Beitreten und Verlassen einer Konferenz
Das Beitreten und Verlassen eines Teilnehmers in einer Konferenz wird über
die Methoden join und leave registriert. Diese rufen wiederum gleichnamige Methoden in den Callback-Objekten der Teilnehmer auf, die bereits an
der Konferenz teilnehmen. Zusätzlich sind die Methoden refuse und pause
definiert, wenn ein Teilnehmer die Einladung ablehnt oder eine laufende Konferenz unterbricht.
7.7
Objektmodell nach der Object Modeling Technique
In diesem Abschnit werden die oben genannten Objekte zusammengefaßt und
erweitert, dabei werden die Beziehungen untereinander dargestellt. Gleichzeitig wird die Verbindung zur Benutzerschnittstelle des Anwendungsprogrammes hergestellt, dabei werden Objekte herangezogen, die in der Benutzerschnittstelle definiert worden sind. 8 Diese Objekte sind durch einen Stern (*)
gekennzeichnet.
Das Objektmodell der Datenobjekte wird dabei exemplarisch am ConferenceMemberObject vorgestellt, das ConferenceToolObject und das ConferenceObject sind entsprechend aufgebaut.
Datenobjekte
Das Modul ConfMembers umfaßt die Objekte ConfMember und ConfMemberFactory (Siehe Abb. 7.9). Das Factory-Objekt enthält nur eine Methode, die das Anlegen neuer Instanzen des ConfMember-Objektes
ermöglicht. ConfMember ist von CosLifCycle::LifeCycleObject abgeleitet, somit erbt es Methoden zum Löschen, Kopieren und Bewegen. Es enthält
die Methoden zum Setzen und Lesen der Daten nach Tabelle 7.2 sowie die Me8
Vergl. [Fri96].
Entwurf einer CORBA-Erweiterung für Confman
81
CosLifeCycle::
LifeCycleObject
copy()
move()
remove()
Vererbung der Methoden
zur Steuerung der
Lebenszyklen
ConfMemberDDL
ConfMembers
ConfMemberData
mailaddress
lastname
firstname
loginname
organisation
position
confmemb_clients
num_confmemb_clients
ConfMemberData ist
ein Objekt des Moduls
ConfMemberDDL
ConfMember
set_name()
set_firstname()
set_loginname()
set_organisation()
set_position()
dto. get_...()
add_confmemb_client()
remove_confmemb_client()
Aggregation
über
Persiztenzdienst
ConfMemberFactory
ConfMember und
ConfMemberFactory sind
Objekte des Moduls ConfMembers
create_confmember()
create_confmember()
erzeugt Instanzen von
ConfMember
Abbildung 7.9: OMT-Diagramm: ConfMember
thoden add confmemb client und remove confmemb client zum Einfügen
und Löschen von Callback-Objekten.
Die Daten des ConferenceMemberObjects werden in dem Datenobjekt ConfMemberData gespeichert, das Teil des Moduls ConfMemberDDL ist über
den Persistenzdienst eingebunden wird.
In Abb. 7.10 sind weitere Objekte dargestellt, die Hilfsfunktionen für das
Anwengungsprogramm bereitstellen. Mit Hilfe der Klasse QueryRegistration werden die Referenzen auf die Application Subcontexts ermittelt. NEOContexts speichert sie zwischen, um unnötige ORB-Anfragen zu vermeiden.
NameContextList listet die Namen aller Objekte auf, die in einem Naming
Context gespeichert sind.
Das Objekt MemberEntry (*) benutzt NEOContexts, um die Referenz
auf das Application Subcontext ConferenceMembers zu bekommen, anschließend läßt es von NameContextList die Liste mit den Namen aller Objekte
erzeugen. Über die Methode resolve des Naming Context wird aus dem
Namen die Objektereferenz erzeugt. MemberEntry speichert diese in der
Variablen confmember ref.
WatchConfMember ist ein weiteres Hilfsobjekt, das zum Beobachten des
Objektes ConfMember dient. Es wird von MemberEntry (*) erzeugt
und erhält eine Kopie der Referenz auf das ConfMember-Objekt. WatchConfMember erzeugt ein neues Objekt ConfMemberClientCallBack.
Dieses wird über die Methode add confmemb client in die Liste der Callback-
Entwurf einer CORBA-Erweiterung für Confman
82
CosNaming::
NamingContext
liefert Referenzen auf
Kontexte und
Subkontexte
QueryRegistration
attributes
resolve_appcontext()
resolve_appsubcontext()
resolve_or_create_
appsubcontext()
WatchConfMember
connected
confmember_name
confmember_ref
callback_ref
client_id
resolve()
connect()
disconnect()
get_name()
cleanup()
NEOContexts
confmember_context
conference_context
conftool_context
speichert die Referenzen
der Kontexte
referenziert über
MemberEntry::watch
instance()
get_confmember_context()
get_conference_context()
get_conftool_context()
NameContextList
MemberEntry (*)
confmember_ref
watch
count
nameArray
liest die Namen von
Objektinstanzen aus
einem Naming Context
Initialize()
operator[]
Count()
MemberEntry benutzt NEOContexts
und NameContextList zum
Auffinden der Objektinstanzen
ConfMemberFactory
MemberEntry benutzt
ConfMemberFactory zum
Erzeugen neuer Instanzen
create_confmember()
ConfMember
referenziert über
MemberEntry::
confmember_ref
set_name()
set_firstname()
set_loginname()
set_organisation()
set_position()
dto. get_...()
add_confmemb_client()
remove_confmemb_client()
Abbildung 7.10: OMT-Diagramm: Referenzieren des ConfMember-Objektes
written in IDL
ConfMemberData
mailaddress
lastname
firstname
loginname
organisation
position
confmemb_clients
num_confmemb_clients
referenziert über
ConfMemberData::
confmemb_clients[i]
written in C++
ConfMember
set_name()
set_firstname()
set_loginname()
set_organisation()
set_position()
dto. get_...()
add_confmemb_client()
remove_confmemb_client()
referenziert über
WatchConfMember::
confmember_ref
WatchConfMember
connected
confmember_name
confmember_ref
callback_ref
client_id
connect()
disconnect()
get_name()
cleanup()
ConfMemberClientCallBack
get_username()
new_name()
new_firstname()
new_loginname()
new_organisation()
new_position()
remove()
referenziert über
WatchConfMember::
callback_ref
Abbildung 7.11: OMT-Diagramm: ConfMemberClientCallBack
Entwurf einer CORBA-Erweiterung für Confman
83
Objekte eingefügt (Abb. 7.11).
written in IDL
written in C++
ClientCallBack lokalisiert
Adreßbuch und ermittelt
Referenz auf MemberEntry
Adreßbuch hält
Referenzen auf
MemberEntry
ConfMemberClientCallBack
AdressBook (*)
get_username()
new_name()
new_firstname()
new_loginname()
new_organisation()
new_position()
remove()
attributes
MemberEntry (*)
attributes
ClientCallBack
aktualisiert
Attribut in MemberEntry
Abbildung 7.12: OMT-Diagramm: Callback-Funktion
Abb. 7.12 verdeutlicht die Callback-Funktion am Beispiel des geöffneten
Adreßbuches. Wird an dem NEO-Objekt ConfMember eine Änderung an
einem Atrribut vorgenommen, so wird diese Änderung an alle CallbackObjekte über deren new-Methoden weitergegeben. Das Callback-Objekt lokalisiert das Adreßbuch, das ihm die Referenz auf das MemberEntry-Objekt
zur Verfügung stellt. Nach der erfolgten Änderung wird das Adreßbuch aktualisiert.
ConfmanClient
Mit dem Start des Client-Programms ConfmanNEO wird ein CallbackObjekt ConfmanClientCallBack erzeugt. Anschließend ermittelt ConfmanNEO das Server-Objekt ConfmanClient mit Hilfe der ODF find Funktion und fügt das Callback-Objekt mit der Methode add confman client in
die Callback-Liste ein (Abb. 7.13).
Mit Hilfe der Funktionen get num confman clients und get confmanclient callback können Referenzen auf Callback-Objekte anderer Anwendungsprogramme ermittelt werden. Damit wird die Liste aller anwesenden
Konferenzteilnehmer ermittelt.
Entwurf einer CORBA-Erweiterung für Confman
84
written in IDL
ConfmanClientDDL
ConfmanClientData
confman_clients
num_confman_clients
written in C++
ConfmanClients
ConfmanClient
referenziert über
ConfmanNEO::confmanclient_ref
mit ODF_find()
add_confman_client()
remove_confman_client()
get_num_confmanclients()
get_confmanclient_callback()
ConfmanNEO
connected
my_confmember_name
confmanclient_ref
callback_ref
client_id
member_list
conference_list
tool_list
referenziert über
confman_clients[i]
ConfmanClientCallback
get_hostname()
new_confmember()
new_conference()
new_conftool()
dto. remove_...()
start_conference()
remove()
connect()
disconnect()
get_name()
cleanup()
referenziert über
ConfmanNEO::callback_ref
Abbildung 7.13: OMT-Diagramm: ConfmanClient
ConferenceManager
Konferenzen mit mehr als zwei Teilnehmern benötigen einen KonferenzServer, dabei werden die Datenströme durch Multiplexen verteilt. In der
CORBA-Erweiterung werden Konferenz-Server repräsentiert durch Instanzen des Objekt-Typen ConferenceServer (Abb. 7.14). Sie werden auf dem
Rechner am Object Request Broker angemeldet, der als Konferenz-Server dienen soll. Die Instanzen werden im Application Subcontext ConferenceServer
abgelegt (Abb. 7.6).
ConferenceManager
route_conference()
ConferenceServer
get_quality_of_service()
get_subnet()
get_time()
serve_conference()
Abbildung 7.14: Konferenz-Server-Objekte
Der ConferenceManager wird aktiviert, sobald eine Konferenz mehr als
zwei Teilnehmer enthält. Dieser lokalisiert die Konferenz-Server und ermittelt eine Verteilungsstruktur für die Konferenz. Diese wird dem ConferenceObjekt zurückgegeben, das damit das Starten der der Server und der Konferenzwerkzeuge einleiten kann (Abb. 7.15).
Entwurf einer CORBA-Erweiterung für Confman
85
ConferenceManager
ConferenceManager
lokalisiert alle
ConferenceServer
ConferenceServer
ConfmanClient
add_confman_client()
rem_confman_client()
get_num_confmanclients()
get_confmanclient_callback()
get_quality_of_service()
get_subnet()
get_times()
start()
stop()
get_ports()
add_tool()
kill_tool()
route_conference()
Conference
lokalisiert
ConfmanClient
Conference
lokalisiert
ConferenceManager
Conference
set_...()
start_now()
add_conf_client()
rem_conf_client()
join()
leave()
ConfmanClientCallback
get_hostname()
new_confmember()
new_conference()
new_conftool()
dto. remove_...()
start_conference()
remove()
Konferenzteilnehmer
werden über ConfmanClientCallBack eingeladen
ConferenceClientCallBack
new_...()
get_ports()
start_tool()
kill_tool()
stop()
join()
leave()
Abbildung 7.15: Start einer Server-Konferenz
ConfTool
set_num_ports()
set_kill_signal()
set_run_script()
dto. get_...()
add_client()
remove_client()
Entwurf einer CORBA-Erweiterung für Confman
7.8
86
Ermitteln eines Konferenz-Servers
Für die Ermittlung eines geeigneten Servers in einer Server-Konferenz verfügt
jedes Server-Objekt über eine Funktion, mit deren Hilfe die Qualität seines
Dienstes bei vorgegebenen Anforderungen, der Quality of Service (QoS), bestimmt wird. Die Qualität des Dienstes ist dabei abhängig von der Zahl der zu
bedienenden Teilnehmer, der Anzahl der gewählten Multimedia-Tools, sowie
der aktuellen CPU-Last.
float get_quality_of_service (
in short num_members,
in short num_tools
);
// number of members
// number of conference tools
Für die Berechnung des Qualitätswertes wird die aktuelle Prozessorauslastung
über ein Systemaufruf ermittelt. Weiterhin ist die Anzahl der Prozessoren des
Rechners von Bedeutung sowie eine Konstante, die die Charakteristiken des
Rechners beschreibt. Diese lassen sich vom Administrator einstellen.
Die Qualität des Dienstes q läßt sich dann nach der Formel
q=
p
w + m ∗ t ∗ const
berechnen, wobei p der Anzahl der Prozessoren entspricht, w der Prozessorlast
(Workload), m der Teilnehmerzahl und t der Anzahl der Konferenzwerkzeuge. Das Produkt m ∗ t ∗ const entspricht der zu erwartenden Steigerung der
Workload. In der Tabelle 7.4 sind die Ergebnisse eines Rechenbeispiels eines
Servers bei unterschiedlichen Anforderungen aufgeführt.
Konstante
const
0.1
0.1
0.1
0.1
0.1
0.1
0.1
Prozessoren
p
1
1
1
1
1
2
4
Workload
w
0.1
0.3
0.1
0.3
1.0
1.0
2.0
Teilnehmer
m
3
3
4
4
3
3
3
Werkzeuge
t
2
2
2
2
2
2
2
Qualität
q
1.43
1.11
1.11
0.91
0.63
1.25
1.53
Tabelle 7.4: Beispielwerte zur Berechnung des Qualitätswertes
Es läßt sich zeigen, daß die Formel für eine einfache Berechnung ausreichend
ist, die der Bestimmung der Qualität des Serverdienstes genügt. Wenn ein
Entwurf einer CORBA-Erweiterung für Confman
87
Server die Konferenz nicht annehmen kann, wird der Wert 0 zurüchgegeben.9
Die Auswahl des geeigneten Konferenz-Servers übernimmt das Objekt ConferenceManager, das mit den Anforderungen der Konferenz den Server ermittelt, der den besten Qualitätswert liefert. Über die Methode
serve conference wird der Konferenz-Server aktiviert.
7.8.1
Wegefindung bei Konferenzen mit mehreren Servern
Die durch Server-Konferenzen verursachte Netzlast ist proportional zu der
Anzahl der Konferenzteilnehmer. Dies kann insbesondere bei Netzwerkverbindungen mit hoher Auslastung, die eine weitere Strecke zurücklegen, zu
Problemen in der Übertragung der Daten führen.
Bei Konferenzen mit mehr als 3 Teilnehmern in verschiedenen Subnetzen kann
es daher sinnvoll sein, mehrere Konferenz-Server einzusetzen, die die Daten
untereinander vermitteln und sie dann an die Teilnehmer ihres Subnetzes
verteilen. Abb. 7.16 zeigt ein Beispiel für eine solche Datenverteilung.
Teilnehmer 2
Teilnehmer 4
Teilnehmer 6
Teilnehmer 1
Server 1
Server 2
Server 3
Teilnehmer 7
Teilnehmer 3
Teilnehmer 5
Abbildung 7.16: Datenverteilung einer Server-Konferenz mit mehreren Servern
Um einer sinnvolle Verteilung der Daten vornehmen zu können, werden Kennnisse über folgende Punkte gesammelt:
• Subnetze: Über die Rechneradressen der Konferenzteilnehmer und der
Server kann herausgefunden werden, in welchem Subnetz sich die Knoten befinden. Dabei ist zu beachten, welcher Klasse die IP-Adresse angehört und welches Subnettingverfahren Verwendung findet. NetzwerkElemente, die auf Ethernet-Ebene eine Unterteilung in verschiedene
9
Dies ist beispielsweise der Fall, wenn der Server gleichzeitig Arbeitsplatzrechner eines
Konferenzteilnehmers ist.
Entwurf einer CORBA-Erweiterung für Confman
88
Collision-Domains vornehmen, können hierbei nicht berücksichtigt werden, da sie Kenntnisse voraussetzen, die nicht zur Laufzeit erworben
werden können.
• Zeitmessungen: Der Datenaustausch der Multimedia-Tools erfolgt
über das Verschicken von Datagramm-Paketen (UDP). Um eine
möglichst authentische Aussage über die Qualität der Netzverbindung
machen zu können, werden Pakete in gleicher Größe und zeitlicher Folge
zwischen den Netzknoten verschickt und die Zeit bis zur Antwort abgewartet. Durch das Zusammemfassen der Meßergebnisse in einer Matrix
kann ein Optimum bezüglich der zu wählenden Datenverteilungsstruktur gefunden werden.
• Erfahrungswerte: Die oben genannten Messungen sind subjektiv, so
daß sie nicht immer die optimale Verteilung ermitteln. Werden die gefundenen Verteilungsstrukturen über einen längeren Zeitraum festgehalten, so können Aussagen getroffen werden, welche Verbindungen sich
bewährt haben. Diese Erfahrungswerte können hilfreich sein zum Aufbau ähnlicher Strukturen.
Das NEO-Objekt ConferenceManager hat die Aufgabe, nach den oben
genannten Methoden die optimale Struktur zur Verteilung der Datenstöme
zu ermittelen. Es enthält eine Methode route conference, die die verwendeten Multimediatools sowie die Hostadressen der Teilnehmer als Parameter
überreicht bekommt, die an der Konferenz teilnehmen.
Die Konferenz-Server-Objekte verfügen über die Methoden get subnet und
get times, anhand derer das Subnetz, in dem sich der Rechner befindet, und
die Datenübertragungszeiten zu anderen Kommunikationspartnern ermittelt
werden können. Die Theorien hinter den Methoden wird im folgenden näher
betrachtet.
Subnetze
Die IP-Adresse10 eines Rechners setzt sich zusammen aus 4 Bytes. Anhand der
ersten Bits kann erkannt werden, welcher Netzklasse der Rechner angehört.
IP-Adressen sind in 5 Klassen eingeteilt, die durch das erste Byte bestimmt
werden. Adressen der Klasse A beginnen mit einer Null, sie enthalten eine 7
Bit lange Net-ID und eine 24 Bit lange Host-ID. Damit lassen sich 16.777.214
Hosts in diesem Netz adressieren.
Klasse B Netze beginnen mit der Bitfolge 10 und benötigen 14 Bits zur Darstellung der Net-ID und 16 Bits für die Host-ID. Damit können 65534 Rechner
10
IP ist die Abkürzung für Internet Protocol.
Entwurf einer CORBA-Erweiterung für Confman
89
adressiert werden. Ein Netz der Klasse C beginnt mit der Bitfolge 110 und
benutzt 21 Bit zum Adressieren der Net-ID und 8 für die Host-ID, es läßt
maximal 254 Hosts zu. Netze der Klasse D sind Multicast-Adressen, sie sind
hier nicht von Interesse. Klasse E Netze sind noch nicht näher spezifiziert.
In Netzen der Klasse B wird häufig ein Subnetting-Verfahren eingesetzt, das
die 16 Bit, die für die Host-ID vorgesehen waren, in Sub-Net-ID und Host-ID
aufteilt. Dieses kann über die Netmask ermittelt werden. Somit enthält diese
Adresse drei Komponenten: Net-ID, Subnet-ID und Host-ID. 11
Die im folgenden definierte Struktur enthält zwei Variablen zum Aufnehmen
der Net-ID und Subnet-ID. Die Werte werden von der Methode get subnet
des Objektes ConferenceServer ermittelt. Wird kein Subnetting eingesetzt,
erhält subnetid den Wert -1.
struct SubNet {
short netid;
short subnetid;
};
SubNet get_subnet();
Diese Methode wird ebenfalls in die ConfmanClientCallBack-Objekte aufgenommen, somit kann eine Zuordnung von Konferenz-Server und Teilnehmer
in gleichen Subnetzen vorgenommen werden.
Zeitmessungen
Für die Zeitmessungen benötigt der Server die Hostnamen der Rechner aller
Konferenzteilnehmer sowie aller verfügbaren Konferenz-Server. Diese wird der
Funktion get time übergeben, die UDP-Pakete an diese Rechner schickt.
struct TimeToHost{
string hostname;
long
time;
};
void get_time( inout TimeToHostList hosts);
Die Pakete werden bei Eintreffen an den Arbeitsstationen der Konferenzteilnehmer dupliziert und an den Server zurückgeschickt. Dieser mißt die Zeit
11
Detailliertere Informationen können [Gri94] entnommen werden.
Entwurf einer CORBA-Erweiterung für Confman
90
zwischen dem Versenden des Paketes und dem Eintreffen der Rückmeldung.
Die Zeiten werden in der Liste eingetragen, so daß sie dem ConferenceManager zur Verfügung stehen.
Der ConferenceManager trägt alle Zeiten in einer Tabelle nach Tab. 7.5
ein und sucht die Minima in jeder Zeile. Dadurch wird die Zuordnung der
Teilnehmer zu den Servern sowie die günstigste Verbindung zwischen den
Servern ermittelt. Die so gefundene Struktur wird anschließend daraufhin
geprüft, ob alle Konferenzteilnehmer miteinander verbunden sind und ob ein
Konferenz-Server entfallen kann, wenn er nur einen Teilnehmer bedient.
In einem Versuch wurden Zeitmessungen mit UDP-Paketen der Größe 316
Byte vorgenommen, die nach diesem Verfahren verschickt wurden. 12 Dabei dienten die Rechner borneo, (130.75.5.18), cip1-s (130.75.16.100) und
UniCS (130.75.6.1) als mögliche Konfernz-Server, java (130.75.5.2), molokai (130.75.5.49), cip1-2 (130.75.16.2), cip1-29 (130.75.16.29) und s5b002
(130.75.7.2) als Teilnehmer-Rechner. Die Ergebnisse sin in Tabelle 7.5 aufgenommen.
Java
Molokai
Cip1-2
Cip1-29
S5b002
Borneo
Cip1-s
UniCs
Borneo
14,5
6,2
16,3
11,6
10,6
—
12,4
12,6
Cip1-s
15,7
12,0
8,7
9,8
15,4
13,5
—
22,6
UniCs
16,5
33,6
17,9
30,8
18,9
16,4
19,4
—
Tabelle 7.5: Versuch: Zeitmessungen mit UDP-Paketen
Nach Auswertung der Zeiten ergibt sich eine Verteilungsstruktur nach
Abb. 7.17.
7.9
Schnittstellen und Datenbeschreibungen
Auch die Beschreibung der Schnittstellen und Daten der NEO-Objekte wird
hier nur exemplarisch vorgenommen, da sie sich bei den drei Objektservern
ConferenceMemberObjects, ConferenceToolObjects und ConferenceObjects
nur in der Ausführung unterscheiden.
Die Schnittstelle des Moduls ConfMembers wird in einem IDL-File de12
Es handelt sich bei diesem Programm um das Client-Server Beispiel mit UDP“ aus
”
[Gri94], das um Methoden zur Zeitmessung erweitert wurde.
Entwurf einer CORBA-Erweiterung für Confman
91
Java
Cip1-2
Molokai
Borneo
Cip1-s
Cip1-29
S5b002
Abbildung 7.17: Verteilungsstruktur nach Zeitmessungen mit UDP-Paketen
finiert, das den Namen ConfMember.idl erhält. Dort enthalten sind alle Methoden, die zum Setzen und Auslesen der Attribute der Objektinstanz benötigt werden. Es enthält auch die oben genannten Methoden zum
Einfügen und Löschen von Objektereferenzen der Callback-Objekte vom Typ
ConfMemberClientCallBack.
//
//
//
//
//
//
//
//
//
//
This may look like C++ code, but it is really -*- IDL -*Author:
Bernd Boeker <[email protected]>
File:
ConfMember.idl
Mon Dec 11 1995
(c) 1995 Lehrgebiet Rechnernetze und Verteilte Systeme
Universitaet Hannover, Germany
#ifndef _CONFMEMBER_IDL
#define _CONFMEMBER_IDL
#include <Cos/LifeCycle.idl>
#include "ConfMemberClientCallBack.idl"
#include "ConfmanClientCallBack.idl"
module ConfMembers{
exception TooMuchInterest{};
exception UnknownId{};
exception AlreadyExists{};
interface ConfMember : CosLifeCycle::LifeCycleObject {
// methods for setting conference members data
oneway void set_name(in string new_name);
Entwurf einer CORBA-Erweiterung für Confman
oneway
oneway
oneway
oneway
void
void
void
void
92
set_firstname(in string new_firstname);
set_loginname(in string new_loginname);
set_organisation(in string new_organisation);
set_position(in string new_position);
// methods for retrieving conference members data
string get_name();
string get_firstname();
string get_loginname();
string get_organisation();
string get_position();
// add other ConfMemberClient to interested party
unsigned long add_confmember_client(in ConfMemberClientCallBack confmemb_client)
raises(TooMuchInterest);
// remove ConfMemberClient from interest list
void remove_confmember_client(in unsigned long confmember_id)
raises(UnknownId);
};
interface ConfMemberFactory{
// create and name a new ConfMember
ConfMember create_confmember(in string mailaddress)
raises(AlreadyExists);
};
};
#endif // !defined _CONFMEMBER_IDL
Die Daten des Objektes werden in einem DDL-File definiert. Dieses wird
unter dem Namen ConfMember.ddl gespeichert, es enthält die Schnittstellenbeschreibung der Klasse ConfMemberData, die dem Modul ConfMemberDDL zugeordnet ist.
//
//
//
//
//
//
//
//
//
//
This may look like C++ code, but it is really -*- DDL -*Author:
Bernd Boeker <[email protected]>
File:
ConfMember.ddl
Wed Dec 13 1995
(c) 1995 Lehrgebiet Rechnernetze und Verteilte Systeme
Universitaet Hannover, Germany
#ifndef _CONFMEMBER_DDL
#define _CONFMEMBER_DDL
Entwurf einer CORBA-Erweiterung für Confman
93
#include <Cos/Naming.idl>
#include "ConfMemberClientCallBack.idl"
#include "ConfmanClientCallBack.idl"
module ConfMemberDDL {
const short max_clients = 128;
typedef sequence<ConfMemberClientCallBack, max_clients> ConfMemberClientCallBacks;
typedef sequence<ConfmanClientCallBack, max_clients> ConfmanClientCallBacks;
interface ConfMemberData {
// mailadress of conference member, unique
attribute string mailaddress;
// first name
attribute string firstname;
// last name
attribute string lastname;
// login account name
attribute string loginname;
// name of the users organization
attribute string organization;
// the users postion
attribute string position;
// list of users confman client callbacks,
// one for every confman he has started,
// and the number of clients
attribute ConfmanClientCallBacks confman_clients;
attribute unsigned short num_confman_clients;
// list of confmemberclients (addressbooks of various conference
// members)
attribute ConfMemberClientCallBacks confmemb_clients;
attribute unsigned short num_confmemb_clients;
};
};
#endif // !defined _CONFMEMBER_DDL
Das Callback-Objekt wird in der Datei ConfMemberClientCallBack.idl definiert. Es enthält die Methoden, die das vom Benutzer gestartete Anwen-
Entwurf einer CORBA-Erweiterung für Confman
94
dungsprogramm über Änderungen an den Attributen der Objektinstanz informieren.
//
//
//
//
//
//
//
//
//
//
This may look like C++ code, but it is really -*- IDL -*Author:
Bernd Boeker <[email protected]>
File:
ConfMemberClientCallBack.idl
Tue Dec 12 1995
(c) 1995 Lehrgebiet Rechnernetze und Verteilte Systeme
Universitaet Hannover, Germany
#ifndef _CONFMEMBERCLIENTCALLBACK_IDL
#define _CONFMEMBERCLIENTCALLBACK_IDL
interface ConfMemberClientCallBack {
// return the users name
string get_username();
// set
oneway
oneway
oneway
oneway
oneway
the new values of the ConfMember
void new_name(in string name);
void new_firstname(in string firstname);
void new_loginname(in string loginname);
void new_organisation(in string organisation);
void new_position(in string position);
// remove the object
void remove();
};
#endif // !defined _CONFMEMBERCLIENTCALLBACK_IDL
7.10
Design-Änderungen gegenüber Confman
Gegenüber der derzeit distributierten Version von Confman sind einige Änderungen vorgenommen worden, die nicht die CORBA-Erweiterung betreffen.
Ziel dieser Änderungen ist es, eine intuitivere Bedienung zu ermöglichen. Alle
Änderungsentwürfe sind bei der Benutzung des Programms entstanden.
Entwurf einer CORBA-Erweiterung für Confman
7.10.1
95
Toolbutton-Leiste
Alle Knöpfe zum Auswählen der Multimedia-Werkzeuge enthalten nur noch
zwei Zustände. Damit können die Werkzeuge jederzeit in einer laufenden Konferenz hinzugenommen werden, ohne vorher aktiviert zu werden. Daraus ergibt sich die veränderte Situation, daß die Ports für die Tools erst unmittelbar
vor dem Starten ermittelt werden.
Weiter gilt es zu berücksichtigen, ob das zu Starten gewünschte Tool auch bei
allen Kommunikationspartnern vorhanden ist. Auch hier findet die Probe erst
unmittelbar vor dem Start des Werkzeugs statt. Werkzeuge, die bei keinem
weiteren Konferenzpartner definiert sind, werden nicht gestartet.
7.10.2
Quit-Funktionen
Der Quit-Button im Hauptmodul sowie die Quit-Funktion im File-Menü des
Conferencemanagers sind nicht mehr kontextsensitiv, sie führen stets die gleiche Funktion aus und liefern so immer das gleiche Ergebnis. Wird der Conferencemanager bzw. Confman in einer laufenden Konferenz beendet, findet
auch hier eine Rückfrage statt. Ein Bestätigen der Rückfrage führt dann –
anders als beim distributierten Confman – zum Schließen des Fensters.
7.10.3
Adreßeditor
Durch den Wegfall der Hostlisten in den Einträgen des Adreßbuches sind im
Adreßeditor die Felder zum Eintragen der Rechnernamen sowie die Rechnerliste entfernt worden. Damit erhält das Fenster ein verändertes Aussehen.
Kapitel 8
Laufzeitverhalten von ConfmanNEO
Nach dem im vorigen Kapitel beschriebenen Entwurf ist eine Erweiterung
für Confman implementiert worden, deren Laufzeiteigenschaften hier näher
untersucht werden sollen. Die Unterstützung von Server-Konferenzen ist im
Rahmen dieser Arbeit nicht mehr vorgenommen worden, da diese Arbeit nur
eine Technologiestudie darstellt und sich ein sinnvoller Einsatz von ConfmanNEO derzeit nicht abzeichnet.1 Stattdessen wird im nächsten Kapitel eine
Übernahme der Entwicklungsergebnisse auf die in der Distribution befindlichen Version von Confman diskutiert. Alle Messungen sind in einem Netzwerk
vorgenommen worden, das in dieser Zeit auch von anderen Rechnern genutzt
worden ist.2
Die NEO-Server-Objekte sind auf einer SPARCstation 10/20 mit 64 MByte
Speicher installiert, die Daten sowie die Programme werden – abgesehen von
Abschnitt 8.2 – von der lokalen Festplatte geladen. Alle Server- und ClientProgramme wurden mit der Option -O2 übersetzt. Als Betriebssystem stand
Solaris 2.4 bzw. Solaris 2.5 zur Verfügung.
8.1
Aktivierung und Deaktivierung von NEO Objekten
NEO-Objekte werden durch Prozesse repräsentiert. Um die Prozessorlast
nicht unnötig hoch zu halten, werden Prozesse, die längere Zeit nicht angesprochen worden sind, terminiert. Dabei werden die persistenten Daten auf
externen Speichermedien gesichert.
1
Dieses werden die in diesem Kapitel beschriebenen Zeitmessungen zeigen.
Es handelt sich hier um das Netzwerk des Regionalen Rechenzentrums, in dem sich
über 200 Rechner befinden. Durch die Aufteilung in verschiedene Collision-Domains liegt
die Netzauslastung gewöhnlich unter 10 %.
2
96
Laufzeitverhalten von ConfmanNEO
97
Bei Anforderung eines Dienstes wird der Serverprozeß automatisch gestartet
und seine persistenten Daten werden wieder zurückgeladen. Dadurch kann
ein Serverstart mehrere Sekunden Zeit in Anspruch nehmen, abhängig von
der Größe des Server und der persistenten Daten.
Die Serverprozesse der ConfmanNEO-Objekte werden terminiert, nachdem
sie eine Stunde lang nicht in Anspruch genommen worden sind. Aus diesem Grund sind die Messungen einmal bei aktivem und inaktivem Server
durchgeführt worden. Dieser Zeitwert kann beliebig verändert werden, die
automatische Terminierung ist auch abschaltbar. 3
8.2
Programmstart von ConfmanNEO
Während des Programmstarts lokalisiert ConfmanNEO die Naming Contexts,
in denen die Konferenzen, Teilnehmer unf verfügbaren Werkzeuge abgelegt
sind. Anschließend erzeugt es das Callback-Objekt ConfmanClientCallBack,
lokalisiert das NEO-Objekt ConfmanClients und meldet das Callback-Objekt
dort an.
ConfmanNEO benutzt dafür einige NEO-Services, die bei Bedarf gestartet
werden müssen. Die Startzeit der Server ist dabei abhängig von ihrer Installation, in diesem Fall werden alle Server, die Bestandteil vom NEO-System
sind, über NFS geladen. Die Server-Objekte der Confman-Erweiterung sowie
alle dazugehörigen Daten werden in einer Meßreihe von einer lokalen Festplatte geladen, in der zweiten Meßreihe ebenfalls über NFS. In jeder Meßreihe
wird je eine Messung mit noch zu startenden Services (Server inaktiv) sowie
mit bereits gestarteten Services (Server aktiv) vorgenommen.
Alle Messungen wurden auf den Rechnern des Lehrgebietes Rechnernetze und
Verteilte Systeme vorgenommen. Die Arbeitsgruppe wird vom Rechner molokai verwaltet, auf dem Rechner sumatra sind die Confman-Server-Objekte
installiert, als Client-Rechner diente borneo. Es wird davon ausgegangen,
daß der Benutzername bekannt ist, sodaß das Erzeugen einer neuen Instanz
vom Typ ConfMember entfällt.
Server inaktiv
40 s.
Server aktiv
10 s.
Tabelle 8.1: Programmstartzeiten bei lokalem Server
Tabelle 8.1 enthält die Startzeiten von ConfmanNEO bei lokalen ServerObjekten, in Tabelle 8.2 werden Server-Objekte, dynamische Bibliotheken
3
Über eine sinnvolle Einstellung soll zu einem späteren Zeitpunkt diskutiert werden.
Laufzeitverhalten von ConfmanNEO
98
und Datenbanken über NFS geladen. ConfmanNEO wird dabei stets über
NFS gestartet.
Server inaktiv
45 s.
Server aktiv
15 s.
Tabelle 8.2: Programmstartzeiten bei Server über NFS
8.3
Auffinden von Objekt-Instanzen
Eine weitere Meßreihe beschäftigt sich mit der Zeit, die zum Auffinden von
Objekt-Instanzen benötigt wird. Als Beispiel dient hier das Adreßbuch, das
eine unterschiedliche Anzahl von Einträgen enthält.
Tabelle 8.3 enthält die Zeiten, die zum Öffnen eines Adreßbuches mit 8, 32
und 128 Einträgen benötigt wird. Dabei werden die Server-Objekte sowie die
Datenbanken der Server-Objekte lokal geladen.
Einträge
8
32
128
Server inaktiv
15 s.
38 s.
132 s.
Server aktiv
7 s.
31 s.
115 s.
Tabelle 8.3: Zeiten zum Öffnen des Adreßbuches
8.4
Auswirkung der Dynamic Notification
Mit Hilfe der Dynamic Notification werden Änderungen an Adreßbucheinträgen, Konferenzdaten oder Tooldaten an andere Benutzer weitergereicht,
die gerade den gleichen Datensatz betrachten. Diese Meßreihe untersucht die
Zeiten, in der die Datenänderungen an alle Benutzer verteilt worden sind. Als
Beispiel dient des Ändern eines Eintrags in einer Konferenz, das an 0, 8 und
32 weitere Teilnehmer weitergereicht werden soll (Tab. 8.4). In diesem Fall
kann davon ausgegangen werden, daß die Server alle nicht terminiert sind,
da die Bearbeitung eines Datensatzes nur in seltenen Fällen länger als eine
Stunde unterbrochen werden wird.
Teilnehmer
0
8
32
Server inaktiv
—
—
—
Server aktiv
3 s.
4 s.
5 s.
Tabelle 8.4: Zeit für dynamische Benachrichtigung
Laufzeitverhalten von ConfmanNEO
8.5
99
Reaktivierung nach längerer Pause
Die Server-Objekte werden terminiert, wenn sie eine bestimmte Zeit nicht
angesprochen worden sind. So kann es vorkommen, daß nach dem Start von
ConfmanNEO, wenn dieser längere Zeit nicht benutzt wurde, die ServerObjekte neu gestartet werden müssen. Dies kann z. B. durch das Öffnen des
Konferenzmanagers veranlaßt werden.
Die Zeiten, die für die Reaktivierung benötigt werden, sind dabei unterschiedlich und hängen von der Anzahl der Konferenzen und der Anzahl der Teilnehmer in der Konferenz ab. Aus den Erfahrungen in den Erfahrungen, die
in der Entwicklung und der Aufnahme der Meßreihen ergeben haben, spielen
sich die Zeiten zwischen 20 Sekunden und 2 Minuten ab.
8.6
Speicherbedarf
Die Meßergebnisse sind in einem hohen Maß von dem zur Vefügung stehenden Speicher der Test-Rechner abhängig. Dies ist deshalb von besonderer Bedeutung, da mit Solaris NEO entwickelten Programme und Server-Objekte
einen hohen Speicherbedarf haben. ConfmanNEO belegt beispielsweise 14
MB des Speichers der Test-Rechner, dies entspricht ca. 22 % des gesamten,
zur Verfügung stehenden Speichers. Die Server-Objekte belegen ca. 9 MB
Speicherplatz. Confman – in der Version ohne CORBA-Erweiterung – belegt
hingegen nur 6 MB Speicher.
8.7
Weitere Optimierungsmethoden
Die obigen Messungen zeigen, daß trotz des Versuchs, die Wartezeiten
im Laufzeitverhalten von ConfmanNEO zu minimieren, keine befriedigende
Lösung errreicht werden konnte. Bisher sind folgende Optimierungen vorgenommen worden:
• Installation der Server-Objekte auf lokalen Festplatten
• Kompilieren von Client- und Servercode mit der Compileroption -O2
• Asynchroner Methodenaufruf durch Verwenden des oneway-Deklarators
• Trennen von Workgroup-Server und ConfmanNEO-Objektserver
Laufzeitverhalten von ConfmanNEO
100
Es sind noch weitere Optimierungsmethoden denkbar, die in weiteren Versuchsreihen erprobt werden könnten. Dazu gehören:
• Durchführung der Messungen in einem leistungsfähigeren Netzwerk, wie
z. B. ATM
• Einsatz von leistungsfähigeren Rechnern
• Workgroup-Server und Objektserver von Arbeitsstationen lösen und auf
eigenständigen Servern installieren
• Lokale Installation der NEO-Serverdienste
• Lokale Installation des Anwendungsprogrammes und der dynamischen
Bibliotheken
• Deaktivierung der automatischen Terminiereung von Serverprozessen
• Überarbeiten des Programmcodes mit der Zielsetzung, Laufzeiten zu
verkürzen
Durch den Einsatz einer leistungsfähigeren Hardware-Infrastruktur ist eine
Performance-Steigerung zu erwarten, die somit eine Verkürzung der Wartezeiten nach sich zieht.
Die genannten organisatorischen Maßnahmen stellen den Objektservern mehr
Prozessorkapazität zur Verfügung und sorgen für eine Reduzierung der Netzlast durch NFS-Pakete. Auch damit ist eine Verkürzung der Wartezeiten zu
erwarten.
Wie sich weiter in den Messungen gezeigt hat, steigt die benötigte Zeit der
Dynamic Notification nur gering mit der Anzahl der zu benachrichtigen Objekte. Eine längere Programmstartzeit wird vom Benutzer auch eher akzeptiert als Wartezeiten zur Laufzeit. Daher erscheint es sinnvoll, während des
Programmstarts eine Kopie der Daten aller NEO-Objekte anzulegen. Im Falle
der Änderung der Daten wird der kopierte Datensatz mit Hilfe der Dynamic
Notification aktualisiert.
Dadurch sind noch einmal Verkürzungen der Laufzeiten zu erwarten, die allerdings nicht im Rahmen dieser Arbeit getestet werden konnten.
8.8
Vergleich Confman vs. ConfmanNEO
ConfmanNEO ist mit der Zielsetzung entworfen worden, die in Kapitel 2
aufgedeckten Problemstellungen zu lösen, ohne weitere Nachteile entstehen zu
Laufzeitverhalten von ConfmanNEO
101
lassen. Durch die Wartezeiten während des Zugriffs auf NEO-Objekte konnte
dieses Ziel nicht erreicht werden. Um die Unterschiede, die der Benutzer dieses
Systems empfindet, zu verdeutlichen, ist ein Vergleich der Produkte Confman
und ConfmanNEO vorgenommen worden.
Zum Vergleich des Zeitverhaltens beider Produkte sind daher Zeitmessungen
vom Programmstart von Confman, vom Öffnen eines Adreßbuches mit 11
Einträgen und vom Öffnen des Konferenzmanagers vorgenommen worden.
Alle Messungen sind zweimal durchgeführt worden, um festzustellen, ob das
wiederholte Durchführen einer Aktion eine Verkürzung der Wartezeit zufolge
hat. Die Ergebnisse sind in Tabelle 8.8 festgehalten.
Aktion
Programmstart
Adreßbuch
Konferenzman.
1. Messung
5 s.
3 s.
3 s.
Wiederholungsmessung
5 s.
< 2 s.
2 s.
Tabelle 8.5: Wartezeiten bei Confman
8.9
Zusammenfassung der Meßergebnisse
Während der Benutzung von ConfmanNEO entstehen Wartezeiten, die ein
flüssiges Arbeiten mit dem Programm nicht ermöglichen. Diese Wartezeiten
entstehen besonders dann, wenn NEO-Objekte in einem Netzwerk lokalisiert
werden oder auf diese zugegriffen wird. Die oben aufgeführten Messungen
zeigen, daß diese Wartezeiten mit der Anzahl der Zugriffe auf die Objekte
steigen. Einzige Ausnahme ist die Dynamic Notification, die mit der Anzahl
der notwendigen Benachrichtigungen nur geringfügig mehr Zeit in Anspruch
nimmt.
Der Einsatz von Solaris NEO scheint für ein interaktives Programm wie Confman nicht geeignet.
Kapitel 9
Ergebnisse und Ausblick
9.1
Entwicklung verteilter Systeme mit CORBA
Aus der Sicht des Programmierers stellt die CORBA-Infrastruktur eine erhebliche Vereinfachung bei der Entwicklung verteilter Systeme dar. Durch die volle Unterstützung von Objektorientierung und der Beschreibung von Schnittstellen in einer einheitlichen, systemunabhängigen Sprache ist es möglich,
Dienste in Netzwerke zu integrieren und von verschiedenen Systemen zu nutzen, unabhängig von der Implementierung oder dem Betriebssystem.
Besonders angenehm ist die Implementierung deshalb, weil die Netzwerkschnittstellen für den Programmierer transparent sind. Mit Hilfe weniger
Funktionen lassen sich Objekte im Netz finden, die dann auf herkömmliche
Art referenziert werden können.
Das Auffinden der Objekte geschieht automatisch, die Wahl der Server spielt
in der Entwurfsphase der Software keine Rolle. Die Dienste werden mit ihrer
Installation in der CORBA-Infrastruktur angemeldet, sie stehen somit dem
Benutzer zur Verfügung, ohne daß dieser Kenntnis über den Aufenthaltsort“
”
des Dienstes hat. Ein Verschieben von Diensten auf andere Rechner kann zur
Laufzeit vorgenommen werden, dem Benutzer bleibt dieses Vorgehen verborgen.
Somit stellt diese Architektur ein sehr leistungsfähiges System zur Entwicklung verteilter Systeme dar, das auf zukunftsweisende Techniken setzt. Die
Vielzahl der Software-Hersteller – insbesondere der großen – und der Anzahl
der Produkte, die auf CORBA basieren, lassen darauf deuten, daß CORBA
eine ähnliche Verbreitung finden wird wie der Remote Procedure Call.
102
Ergebnisse und Ausblick
9.2
103
Erfahrungen mit Solaris NEO
Solaris NEO und Workshop NEO standen bei der Implementierung des Prototypen von ConfmanNEO in der Version 1.0 zur Verfügung. Die bereits angekündigte Unterstützung der grafischen Benutzerschnittstelle OpenStep ist
in dieser Version nicht enthalten gewesen.
Es hat sich gezeigt, daß Solaris NEO in dieser Version noch nicht ganz ausgereift ist. Schon die Installation ist nicht unproblematisch, so ist z. B. keine
direkte Installation auf einem NFS-File-Server möglich.1 Die Einbindung weiterer Rechner in den NEO-Verbund ist über NFS möglich, dafür existiert eine
Installationsroutine. Nach der Installation der Software werden Datei-Rechte
nicht richtig gesetzt, so daß eine Nachbearbeitung von Hand erforderlich ist.
Weiter hat sich gezeigt, daß bei Absturz eines Rechners die ORB-Server nicht
wieder gestartet werden, da Lock-Files beim Absturz nicht gelöscht werden
und ein erneutes Starten der ORB-Dienste verhindern. 2
Durch die fehlende Unterstützung einer grafischen Benutzerschnittstelle ist
der Programmierer genötigt, auf bekannte Bibliotheken zum X-Window-System zurückzugreifen. Dadurch ist zusätzlicher Programmieraufwand erforderlich, da NEO-Programme in mehreren konkurrierenden Ebenen ablaufen. 3
Die von Solaris NEO erzeugten Fehlermeldungen lassen häufig nicht auf die
Fehlerursache schliessen und stiften somit mehr Verwirrungen als sie Hilfestellung bieten. Weder Benutzer noch Administrator sind mit dem Umgang von
Solaris NEO vertraut, so daß eine Fehlerbehandlung, die Lösungsmöglichkeiten aufzeigt, eine sinnvolle Erweiterung darstellen würde.
Nicht zuletzt hat sich gezeigt, daß das Laufzeitverhalten von NEOAnwendungen nicht unkritisch ist. Wartezeiten während des Lokalisierens und
des Zugriffs auf NEO-Objekte fordern die Geduld des Anwenders, so daß trotz
aller Bemühungen, das Zeitverhalten zu optimieren, ein angenehmes Arbeiten
nicht gewährleistet ist.
1
Dies läßt sich nur dadurch realisieren, wenn die Installation lokal vorgenommen wird,
anschließend das gesamte Verzeichnis /opt/SUNWdoe auf einen File-Server übertragen wird.
2
Dieses kann über einen nachträglichen Patch behoben werden.
3
Siehe Abschnitt 5.6.
Ergebnisse und Ausblick
9.3
104
Weiterentwicklung der Produktionslinie ConfmanNEO
Solaris NEO ist in der derzeitigen Version nur mit der CORBA-Implementierung Orbix von Iona Technologies 4 interoperabel, nicht jedoch mit Object
Request Brokern von anderen Herstellern. Dies ist erst möglich, wenn NEO
die CORBA-Spezifikation 2.0 erfüllt.
Auch die Problematik der zeitintensiven Abfragen auf NEO-Objekte scheint
z. Z. nicht zu lösen zu sein. Hier wird eine leistungsfähigere Hardware
benötigt, die sich allerdings schon mit der Generation der UltraSPARCArchitekturen ankündigt.
Die Produktlinie ConfmanNEO wird daher zunächst nicht weitergeführt, bis
Lösungen für diese Probleme gefunden werden können. Im weiteren wird daher versucht, die im Entwurf gesammelten Ergebnisse, die sich nicht unmittelbar auf CORBA stützen, auf die in Distribution befindliche Version von
Confman zu übertragen.
9.4
Übernahme der Entwicklungsergebnisse zu dem nicht auf
CORBA basierenden Confman
Einige der Entwicklungsergebnisse aus Kapitel 7 sind auch übertragbar auf
nicht CORBA-basierte Systeme, so z. B. die Strategien zur Wegefindung bei
Server-Konferenzen. Dieser Abschnitt soll dazu anregen, die aus der Entwicklung der Confman-Erweiterung gesammelten Ergebnisse in die Produktionslinie Confman zu übernehmen.
Dabei bleibt allerdings zu berücksichtigen, daß ein selbständiges Finden von
Objekten und Servern mit herkömmlichen Netzwerkdiensten nicht möglich
ist. Hier ist weiterhin das Verwalten von Listen mit Rechnernamen erforderlich.
9.4.1
Personenfindung
Zentraler Anmeldeserver
In der CORBA-Erweiterung diente das NEO-Objekt ConfmanClients als
zentrale Anmeldestelle für die verschiedenen Instanzen des Anwendungsprogramms ConfmanNEO. Dadurch war es unter anderem möglich, eine Liste
4
Siehe [Ion96].
Ergebnisse und Ausblick
105
der Benutzer zu erstellen, die z. Z. über Confman erreichbar sind.
Diese Funktionaliät kann durch Einrichten eines zentralen Anmeldeservers
ersetzt werden. Beim Programmstart von Confman hat dann eine Anmeldung
an diesem Server zu erfolgen, bei er Mail-Adresse und Rechnername registriert
werden. Die Verwaltung dieser Liste dadurch regelmäßige Proben des Servers
unterstützt werden.
Da dieser Dienst nicht automatisch innerhalb eines Netzwerkes gefunden werden kann, ist es notwendig, im Anwendungsprogramm den Namen des Rechners einzutragen, der als Anmeldeserver dient.
Die Einrichtung einer zentralen Instanz, die zur Personenfindung herangezogen werden kann, bietet die Vorteile, daß sich die Benutzer nicht Anrufumleitungen kümmern müssen. Es kann jedoch als störend empfunden werden,
wenn die Anwesenheit von jedem beoachtet werden kann. Hier bietet sich eine
Lösung dadurch an, daß die eigene Anwesenheit dem Server mitgeteilt wird,
aber für andere nicht sichtbar ist. Dieses Verstecken“ ist aber auch nicht
”
sicher, es ist in dieser Arbeit nicht weiter bedacht worden.
Einrichten eines Confman-Naming-Services
Die Einrichtung eines zentralen Anmeldeservers führt in einem weltweiten
Netz zu Problemen und erweckt in der Regel Mißtrauen, so daß alternative
Strategien herangezogen werden müssen. Die Pflege und Verwaltung dieser
Dienste sollte auch nicht zentral gesteuert werden, sondern den beteiligten
Domains überlassen werden.
Durch die eindeutige Zuordnung von Mail-Adressen und Domains besteht die
Möglichkeit, Domain-bezogene Server einzurichten. Diese können beispielsweise durch ein vorangestelltes cns. identifiziert werden. Wird z. B. nach
einer Instanz von confman des Benutzers [email protected] gesucht, wird der Rechner mit dem Namen cns.rvs.uni-hannover.de lokalisiert und geprüft, ob es sich um einen Confman-Naming-Server handelt.
Dieser Service kann dabei parallel zu den bestehenden Suchverfahren laufen.
Auch hier sollte den Benutzern freigestellt sein, welche Informationen über
diesen Server verfügbar sind. Dieses bleibt in weiteren Arbeiten zu prüfen.
Ergebnisse und Ausblick
106
Nutzung vorhandener Dienste wie X.500
Für den Aufbau eines hierarchischen Systems zur Verwaltung von personenbezogenen Daten existiert ein Directory Service, der unter dem Namen X.500
standardisiert worden ist. Es bleibt zu prüfen, ob dieser Standard für die
Personenfindung für Confman geeignet ist.
9.4.2
Wegefindung bei Serverkonferenzen
Der Entwurf zur Wegefindung kann auch mit der derzeitigen ConfmanVersion realisiert werden, wenn die Aufgaben des ConferenceManagers vom
Confman-Client des Konferenzleiters übernommen werden. Die KonferenzServer werden – wie bisher – in einer Liste verwaltet, die vom Benutzer gepflegt werden muß. Alternativ können die Konferenz-Server über den oben
genannten Confman-Naming-Service ermittelt werden, dies erlaubt ein flexibleres Lokalisieren der Server.
Die Konferenz-Server werden um die genannten Funktionen get subnet,
get quality of service und get time erweitert, so daß die beschriebenen
Funktionen zur Ermittlung der Verteilungsstruktur in ähnlicher Weise benutzt werden können.
Kapitel 10
Zusammenfassung
Die Common Object Request Broker Architecture stellt ein leistungsfähiges und zukunstorientiertes Rahmenwerk für die Programmierung verteilter,
objektorientierter Systeme dar. Dabei ist die Zielsetzung, die Interoperabilität, Wiederverwendbarkeit und Portabilität von Software-Komponenten zu
erhöhen. Die Schnittstellen zu Objekten werden in einer einheitlichen, systemunabhängigen Sprache beschrieben, sodaß die Objekte von unterschiedlichen Systemen genutzt werden können, unabhängig von deren Implementierung.
Mit der Common Object Request Broker Architecture werden verschiedene
Dienste angeboten, die deutliche Erleichterungen in der Programmierung von
verteilten Systemen bieten. Dazu gehören ein Namensdienst, der das Auffinden von Objekten anhand ihres Names realisiert sowie ein Persistenzdienst,
der automatische Sichern von Objekten auf externen Speichermedien verwirklicht.
Netzwerkschnittstellen bleiben dem Entwickler verborgen, mit Hilfe weniger
Funktionen können Objekte, die auf beliebigen Netzwerkknoten installiert
sind, referenziert werden. Damit unterscheiden sie sich nicht mehr von lokalen
Objekten.
Durch die einheitliche Schnittstelle können Objekte in beliebige Anwendungen integriert werden, damit wird die Interoperabilität zwischen verschiedenen Anwendungen ermöglicht.
Desweiteren wird damit die Administration von Diensten erleichtert, da Objekte zur Laufzeit auf andere Rechner verschoben werden können, ohne damit
Umstellungen für Benutzer zu verursachen.
107
Zusammenfassung
108
Damit übersteigen die Fähigkeiten der Common Object Request Broker Architecture die herkömmlichen Methoden, wie z. B. Remote Procedure Call
und ToolTalk, bei weitem.
Die CORBA-Implementierung Solaris NEO in der vorliegenden Version wies
Probleme im Zeitverhalten auf, so daß sie zur Implementierung der Netzwerkerweiterung für Confman bei der vorhandenen Hardware des Lehrgebietes
Rechnernetze und Verteilte Systeme z. Z. nicht geeignet ist. Die entstehenden
Wartezeiten sind dem Benutzer nicht zumutbar. Es ist jedoch abzusehen, daß
diese Probleme mit den Weiterentwicklungen sowohl in der Hardware als auch
in der Software an Relevanz verlieren.
Die Vielzahl an Entwicklern und die zunehmende Anzahl an Produkten, die
auf CORBA basieren, läßt auf eine wachsende Verbreitung der Architektur
schließen. Durch eine Eindung CORBA-konformer Object Request Broker
wird es sich als Basisdienst für verteilte Systeme etablieren, der die bestehenden Mechanismen ablöst.
Glossar
BOA
Basic Object Adapter
Schnittstelle zwischen ORB und Objektimplementierung
CDE
Common Desktop Environment
Einheitliche Benutzeroberfläche für verschiedene
UNIX-Betriebssysteme basierend auf Motif
COM
Component Object Model
Microsofts Objektmodell
auch: Common Object Model als gemeinsames Objektmodell zwischen Microsofts OLE und Digitals Object Broker
CORBA
Common Object Request Broker Architecture
Spezifikation des Objektmodells der ORB
DCE
Distributed Computing Environment
Rahmenwerk der OSF für verteilte Systeme
DII
Dynamic Invocation Interface
Schnittstelle für den dynamischen Aufruf
von Objekten zur Laufzeit
DOE
Distributed Objects Everywhere/Environment
Entwicklungsname für Solaris NEO
DSI
Dynamic Skeleton Interface
Dynamische Schnittstelle, die für die Kommunikation
zwischen ORB verschiedener Hersteller benötigt wird
109
Glossar
110
(D)SOM
(Distributed) System Object Model
Objektmodell von IBM
ESIOP
Environment Specific Inter-ORB Protocol
Spezielles Kommunikationsprotokoll für ORBs
verschiedener Hersteller
GIOP
General Inter-ORB Protocol
Allgemeines Protokoll zur Kommunikation zwischen
Object Request Brokern verschiedener Hersteller
IDL
Interface Definition Language
Sprache zur Schnittstellenbeschreibung von CORBA-Objekten
IIOP
Internet Inter-ORB Protocol
Spezielles Protokoll zur Kommunikation zwischen ORBs verschiedener Hersteller basierend auf TCP/IP
NFS
Network File System
Dateisystem mit Zugriff auf Dateien auf entfernten Rechnern
basierend auf RPC
OLE
Object Linking and Embedding
Protokoll zur Kommunikation zwischen Anwendungen unter
Microsoft Windows
OMA
Object Management Architecture
Referenzarchitektur für ein verteiltes, objektorientiertes System
OMG
Object Management Group
Konsortium verschiedener Firmen, die an der Spezifikation
von CORBA arbeiten
ONC
Open Network Computing
Ansatz von Sun Microsystems für einen offenen Netzwerkstandard, aus dem RPC entstanden ist
ORB
Object Request Broker
Kernstück von CORBA
Glossar
111
OSF
Open Software Foundation
Vereinigung, die sich für die Verbreitung freier Software
einsetzt
RFI
Request For Information
Ein allgemeiner Aufruf an die Computer Industrie, Informationen
zu einem Themenbereich an die OMG zu schicken
RFP
Request For Proposal
Ein expliziter Aufruf, zu einem bestimmten Themenbereich
Stellung zu beziehen
RPC
Remote Procedure Call
Realisierung des Prozeduraufrufs auf entfernten Rechnern, der
dem Anwender in der Regel verborgen bleibt
UNO
Universal Networked Objects
Ansatz zur Interoperabilität zwischen ORBs verschiedener Hersteller
Literaturverzeichnis
[Beh95]
Behme, Henning, Im Kaffehaus. iX 7/95.
[Ber94]
Berg, Alexander von, CMS - Conference Management System.
Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme,
September 1994.
[BeL95a]
Berners-Lee, T. [u. a.], Hypertext Transfer Protocol - HTTP/1.0.
Internet-Draft draft-ietf-http-v10-spec-05.ps.
[BeL95b]
Berners-Lee, T. und Connolly, D., Hypertext Markup Language
- 2.0. RFC 1866, November 1995.
[Bey93]
Beyer, Torsten, Objektbörse. iX 2/93.
[Bus93]
Busch, Michael, Kommunikation über alles. iX 5/93.
[Con78]
Constantine, Larry L. und Yourdon, Edward, Structured Design.
Englewood Cliffs, NJ USA, 1978.
[DiL94]
Dier, M. und Lautenbacher, S., Groupware: Technologien für die
lernende Organisation. Computerwoche-Verlag, 1994.
[Dig94]
Digital Equipment Corporation, Common Object Model for Object Broker and OLE.
http://www.dec.com/info/Customer-Update/940208002.txt.html
[Emb92]
Embley, David W. [u.a.], Object-oriented Systems Analysis – A
Model-Driven Approach. Yourdon Press, 1992.
[Fri96]
Fricke, Clemens, Entwicklung eines Online-Conferencing-Systems
für nicht-öffenliche Konferenzen in breitbandigen Netzen. Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme, Mai
1996.
112
Literaturverzeichnis
113
[Fro93]
Fromme, M. [u.a.], Einführung in das Software-Engeneering.
Lehrgebiet Rechnernetze und Verteilte Systeme 1993.
[Fro94]
Fromme, Michael, Multimedia Conferencig – Eine Übersicht zu
Programmen und Systemen. Lehrgebiet Rechnernetze und Verteilte Systeme, Juni 1994.
http://www.rvs.uni-hannover.de/reports/conferen.html
[Fro95]
Fromme, Michael, Multimedia-Konferenzen in der Wissenschaft:
Szenarien, Technologie und Werkzeuge. Studienarbeit am Lehrgebiet Rechnernetze und Verteilte Systeme, Juli 1995.
[Gri94]
Grimm, C. [u.a.], Rechnernetze – Eine Einführung. Lehrgebiet
Rechnernetze und Verteilte Systeme, 1994.
[Grü96]
Grüneberg, L. [u.a.], Entwicklung eines Management-Systems für
multimediale Online-Konferenzen. Lehrgebiet Rechnernetze und
Verteilte Systeme, Universität Hannover, Februar 1996.
[Gul88]
Gulbins, J., UNIX: eine Einführung in Begriffe und Kommandos.
Springer, 3. Auflage 1988.
[HP96]
Hewlett-Packard Company, Distributed Smalltalk.
http://hpcc998.external.hp.com:80/sesd/products/dst/main.html
[IBM95]
IBM, Overview of SOM. AIXpert August 1995.
[IBM96]
IBM, Object Request Broker in the Open Blueprint.
http://www.software.hosting.ibm.com/openblue/ID0F1/COVER.HTM
[Ion96]
IONA Technologies, Ltd., The Orbix Home Page at IONA Technologies.
http://www.iona.com/Orbix/index.html
[Jav96]
JavaSoft, Inc., Frequently Asked Questions - Applet Security. Version 1.0.2, 6. Mai 1996.
http://www.javasoft.com/java.sun.com/sfaq
[Ker90]
Kernighan, B. W. und Ritchie, D. M., Programmieren in C. Deutsche Ausgabe von A. T. Schreiner und E. Janich, Hanser, 2. Ausgabe 1990.
[Kil]
Killermann, Udo, Mechanismen des Remote Procedure Call. Studienarbeit am Regionalen Rechenzentrum für Niedersachsen
[Lem95]
Lemay, Laura, Web Publishing with HTML. Sams Publishing,
Indianapolis, 1995.
Literaturverzeichnis
114
[Mic95]
Microsoft Corporation, OLE Programmer’s Reference, Volume 1,
Guide to Programming. Microsoft 1995.
[Mic96]
Microsoft Corporation, Microsoft Component Object Model
(COM).
http://www.microsoft.com/backoffice/reading/bst11200.htm
[MoZ95]
Mowbray, J. T. and Zahavi, R., the Essential CORBA. Wiley,
1995.
[Net96]
Netscape Communications Corporation, Netscape Navigator
Handbook.
http://home.netscape.com/eng/mozilla/2.01/handbook
[OMG92]
Object Management Group, Object Management Architecture
Guide, Revision 2.0. OMG TC Document 92.11.1.
[OMG93]
Object Management Group, The Common Object Request Broker: Architecture and Specification, Revision 1.2. OMG Document
Number 93.12.43.
[OMG94a] Object Management Group, IDL C++ Language Mapping Specification. OMG Document 94.9.14.
[OMG94b] Object Management Group, Object Models. OMG Document
94.10.5.
[OMG95]
Object Management Group, Corba Products Directory.
ftp://ftp.omg.org/pub/corba products directory.ps
[OMG96a] Object Management Group, OMA Executive Overview.
http://ruby.omg.org/omaov.htm
[OMG96b] Object Management Group, What is CORBA?
http://ruby.omg.org/corba.htm
[Par93]
Parchmann, R., Systemprogrammierung für Ingenieure. Vorlesung an der Universität Hannover, Wintersemester 1992/1993 und
Sommersemester 1993.
[Pra93]
Pralle, H., Rechnernetze und verteilte Systeme: Systemarchitektur und Betrieb. Vorlesung an der Universität Hannover, Wintersemester 1992/1993.
[Pra94a]
Pralle, H., Rechnernetze und Verteilte Systeme: Ausgewählte Kapitel der Rechnerarchitektur. Vorlesung an der Universität Hannover, Wintersemester 1993/1994.
[Pra94b]
Pralle, H., Grundzüge der Informatik I. Vorlesung an der Universität Hannover, Wintersemester 1993/1994.
Literaturverzeichnis
115
[RRZN95] Regionales Rechenzentrum für Niedersachsen, HTML-Kurzbeschreibung. Revision A, November 95.
http://www.rrzn.uni-hannover.de/Umdrucke/NET.ALL.8.html
[Rum94]
Rumbaugh, J. [u.a.], Objektorientiertes Modellieren und Entwerfen. Hanser, 1994.
[Sri95a]
Srinivasan, Raj, RPC: Remote Procedure Call Protocol Specification Version 2. RFC 1831, August 1995.
[Sri95b]
Srinivasan, Raj, XDR: External Data Representation Standard.
RFC 1832, August 1995.
[Sta95]
Stal, Michael, Der Zug rollt weiter. iX 5/95.
[Str92]
Stroustroup, Bjarne, Die C++-Programmiersprache. AddisonWesley, 2. Auflage 1992.
[Sun95a]
Sun Microsystems, The Java Language, A White Paper. Mountain
View, 1995.
[Sun95b]
Sun Microsystems, The Java Language Specification. Mountain
View, 1995.
[Sun95c]
Sun Microsystems, The HotJava Browser: A White Paper. Mountain View, 1994/5.
[Sun91a]
SunSoft, Solaris OpenWindows, Introduction to the ToolTalk Service, A White Paper. Mountain View, 1991.
[SunS91b] SunSoft, ToolTalk 1.0 Programmer’s Guide. Mountain View,
1991.
[SunS94]
SunSoft, Inc, [u.a.], Universal Networked Objects, ORB 2.0 RFP
Submission. OMG TC Document 94.9.32, September 1994.
[SunS95d] SunSoft, SunSoft’s NEO Product Family. Mountain View, September 1995.
[SunS95e] SunSoft, Solaris NEO, Operation Environment Product Overview. Mountain View, September 1995
[SunS95f] SunSoft, Workshop NEO, Development Environment Product
Overview. Mountain View, September 1995
[SunS95g] SunSoft, NEO Performance Tips. Mountain View, September
1995.
[SunS95h] SunSoft, Connectivity Between Windows and SunSoft’s Solaris
NEO. Mountain View, September 1995
Literaturverzeichnis
[SunS95i]
116
SunSoft, NEO Tutorial. Mountain View, Oktober 1995.
[SunS95j] SunSoft, NEO Programming Guide. Mountain View, Oktober
1995
[SunS95k] SunSoft, ONC+ Developer’s Guide. Mountain View, November
1995
[SunS96a] SunSoft, Project NEO.
http://www.sun.com/sunsoft/neo/external/index.html
[SunS96b] SunSoft, The Baton: A Mechanism to Use MT-Unsafe Libraries
in an MT Environment.
http://www.sun.com:80/sunsoft/neo/external/tech supp/papers/95.10.19/html/baton.html
[SunS96c] SunSoft, DOE Objects in your GUI: An Alert Window.
http://www.sun.com:80/sunsoft/neo/external/tech supp/papers/95.10.19/html/alert.html
[SunS96d] SunSoft, Sun Announces Product That Connects Java To Business Applications.
http://www.sun.com:80/sunsoft/neo/external/press rels/joe-pr.html
[SunS96e] SunSoft, Joe – Client/Server Applications for the Web.
http://www.sun.com:80/sunsoft/neo/external/prod specs/JOE Overview.html
[SunS96f] SunSoft, Joe: Developing Client/Server Applications for the Web.
Mountain View, März 1996
[Tan92]
Tanenbaum, Andrew S., Computer-Netzwerke. Wolfram’s Fachverlag, 2. Auflage 1992.
[Wie88]
Wiener, Richard S. und Collins, Lewis J., An Introduction to
Object-Oriented Programming and C++. Addison-Wesley, 1988.
[You92]
Yourdon, Edward, Moderne Strukturierte Analyse. 1992.
Index
Adresbuch, 5, 83
ANDF, 62
application embedding, 23
Attribut, 32
GIOP, 40
HotJava, 62
HTML, 61
HTTP, 61
BOA, 36
Bridge, 39
Half-, 40
In Line-, 39
Request Level-, 39
IDL, 28, 30
IDL-Rumpf, 29
IDL-Skelett, 29
IIOP, 40, 66
in-place activation, 22
Interface, 32, 45, 64
Registrierung, 46
Interface Repository, 28
Callback-Objekte, 56
Callback-Referenzen, 55
CDE, 22
CGI, 61
Client-Server-Modell, 1, 10
COM, 23
Common Facilities, 26
Confman, 3, 4
Container, 22
CORBA, 2, 65, 102
Java, 3, 61
Joe, 3
Kommunikation
objektorientierte, 19
prozesorientierte, 18
Konferenz
geschlossene, 7
Konferenz-Server, 84
Kontextdiagramm, 70
Datenmodell, 71
Datenverzeichnis, 72
Deadlock, 58
DII, 34
DSI, 40
Dynamic Notification, 53
MBone-Tools, 5
Modul, 32
Motif, 57
Ereignistabelle, 70
ESIOP, 40, 66
Nachrichten, 17
Nachrichtenkanal, 18
Name Space, 43, 44
Factory Object, 44
117
Index
118
Naming Context, 43
NEO, 3
Object Services, 26, 37
Objekt, 27
Modell
OMG, 27
ToolTalk, 19
Objektimplementierung, 27
OLE, 3, 22
OLE/COM, 23
OMA, 2, 26
OMG, 2, 25
OMT, 80
Operation, 27, 33
ORB, 2, 27, 65
networked, 39
stand-alone, 39
ORB-Schnittstellen, 28
persistente Daten, 46
Prozes, 18
RPC, 11, 23
DCE, 23
ONC, 13, 21
Rumpf
IDL-, 29
Schnittstellen
ORB-, 28
Server-Objekt
Registrieren, 50
Service, 44
Sitzung, 19
Skelett
IDL-, 29
Stub, 13
Subtyp, 27
Terminkalender, 8
ToolTalk, 2, 17
Typ, 27
Typenwerte, 31
Umgebungsmodell, 70
User Program, 44
User-Started-Server, 44, 53
Vererbung, 33
Workgroup, 44
World-Wide-Web, 60

Entwicklung verteilter Systeme mit CORBA

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können