Dokument_38.pdf (5583 KB) - OPUS - Hochschule Konstanz

Verteilte Systeme mit der Konstanzer Komponentensprache CompJava
Hans Albrecht Schmid und Marco Pfeifer
Prof. Dr.
Hans Albrecht Schmid
war nach seinem
Studium an der Universität
Stuttgart, am Institut National
Polytechnique de Grenoble und nach
seiner Promotion mit einem Doktorandenstipendium
der Studienstiftung des
deutschen Volkes als Assistent an der
Universität Karlsruhe, als Gastprofessor
an der University of Toronto und als Forschungsgruppenleiter
an der Universität
Stuttgart tätig. Darauf war er zehn Jahre
im IBM Entwicklungslabor Böblingen
in verschiedenen leitenden technischen
und Management-Positionen tätig,
bevor er als Professor an die HTWG
Konstanz kam. Seine Forschungsschwerpunkte
sind fortgeschrittene Softwaretechnologien
in technischen und
kommerziellen Anwendungsgebieten. Er
hat eine größere Anzahl von Forschungsprojekten,
darunter ein DFG-Projekt,
durchgeführt und eine beträchtliche
Anzahl international anerkannter
Veröffentlichungen auf diesen Gebieten
publiziert.
Dipl.-Inf. (FH)
Marco Pfeifer
Software-Engineering-
Studium an der HTWG
Konstanz. Seit Oktober 2005 Projektmitarbeiter
der Hochschule Konstanz.
Mit der Komponentensprache CompJava
lassen sich verteilte Systeme von Komponenten
wesentlich einfacher erstellen als
das bei kommerzieller Middleware der Fall
ist. Außerdem ist die Komposition von lokalen
Komponenten sehr viel effi zienter als
bei kommerzieller Middleware, so dass große,
skalierbare Systeme durch Komposition
von Komponenten erstellt werden können.
Ausgangspunkt
Die Keimzelle von verteilten Systemen bildeten
Anfang der 70er-Jahre Programme,
die auf zwei über eine Telekommunikationsleitung
miteinander verbundenen
Computern abliefen und mittels eines
Protokolls kommunizierten. Die Erstellung
und Wartung solcher Systeme war
extrem zeitaufwändig, weil sich der Entwickler
– und damit ist selbstverständlich
auch die Entwicklerin gemeint – dabei
mit vielen, eigentlich einfachen, aber doch
sehr fehleranfälligen Details beschäftigen
musste (selbst wenn er sich auf ein schon
vorhandenes Protokoll wie LSV2 aus dem
Fertigungsbereich oder TCP aus dem Internet
abstützen konnte). Das führte zu sehr
großen Softwareentwicklungskosten im
Vergleich zu den Kosten der Entwicklung
lokaler Systeme.
Ein weiteres Problem war dabei, dass hinter
einer derartigen Art von Rechnerkommunikation
eine ganz andere Denkweise steckt
als bei der lokalen Programmierung. Bei
dieser ruft man Prozeduren, auch Funktionen
genannt, auf oder Dienste und Methoden,
die von Komponenten bzw. Objekten
zur Verfügung gestellt werden. Deshalb
wurden Anfang der 80er-Jahre entfernte
Prozeduraufrufe in Form des RPC (Remote
Procedure Call) eingeführt. Damit konnte
die Zusammenarbeit von zwei „entfernten“
Programmen (d.h. Modulen auf entfernten
Rechnern) in ähnlicher Weise wie die von
zwei lokalen Modulen durchgeführt werden
und all die einfachen, aber fehleranfäl-
ligen Details der Kommunikationsabwicklung
der RPC-Systemsoftware überlassen
werden.
Verteilte Objekte
Die Objektorientierung gewann seit Anfang
der 90er-Jahre eine immer größere Bedeutung,
ähnlich wie die Arbeit mit verteilten
Dateisystemen, Drucksystemen oder,
allgemeiner, Client-Server-Systemen. Somit
kam die Idee von „verteilten Objekten“ auf,
dass man nämlich Objekte auf verschiedene
Rechner eines Rechnernetzes verteilen
kann und die Methoden eines entfernten
Objektes auf ähnliche oder möglichst gleiche
Art und Weise wie die eines lokalen Objekts
aufrufen kann. Die Zielsetzung [Black
et al. 1987] war dabei folgende:
1. Die Programmierung mit „verteilten
Objekten“, also Erstellung, Deklaration,
Kreation und Aufruf von Methoden, sollte
möglichst auf gleiche Art und Weise wie
bei einem lokalen Objekt durchgeführt
werden.
2. Man sollte die Zuordnung („Allokation“)
von verteilten Objekten auf die Knoten
eines Rechnernetzwerks ändern können,
ohne dass eine Umprogrammierung
erforderlich wird. In anderen Worten, die
Software für die verteilten Objekte sollte
unabhängig von der späteren Allokation
der Objekte entwickelt werden, was man
Allokations-Unabhängigkeit nennt.
3. Der lokale Aufruf der Methode eines
verteilten Objektes, das auf dem gleichen
Rechnerknoten allokiert ist, sollte die gleiche
Effi zienz haben wie der lokale Aufruf
der Methode eines nicht-verteilten Objektes.
Middleware
Obwohl es in der Forschung erfolgreiche
Ansätze gab, verteilte Objekte direkt mit
einer Programmiersprache zur Verfügung
zu stellen [Black et al. 1987], setzten sich
in der Praxis Middleware-Systeme wie z.B.
CORBA, Java RMI, DCOM und DotNet zur
Verteilung von Objekten und später von
Komponenten durch. Leider gelang es diesen
nun schon klassischen Middlewaresystemen
nur teilweise, die oben angeführten
Ziele zu erreichen.
Zum Beispiel ist bei Java RMI die Programmierung
von verteilten Objekten im Prinzip
gleich wie die von lokalen Objekten.
Aber im Detail gibt es doch Unterschiede,
so dass die Programmierung von verteilten
Objekten um einiges komplexer ist und einige
Einarbeitung erforderlich macht. Auch
kann man den Quellcode für ein lokales
Objekt oder einen lokalen Methodenaufruf
nicht einfach übernehmen und evtl. an
ein oder zwei Stellen abändern, um daraus
ein verteiltes Objekt oder einen entfernten
Methodenaufruf zu machen, sondern man
muss mehr oder weniger mechanisch im
ganzen Quellcode kleine Details ändern.
Bei den anderen Middlewaresystemen wie
z.B. CORBA, DCOM und DotNet sind die Unterschiede
noch viel größer und es ist noch
viel mehr Einarbeitung erforderlich. Somit
ist Ziel 1 nur teilweise erfüllt.
Die Middlewaresysteme stellen für entfernte
Objekte oder Komponenten entfernte
Schnittstellen zum Methodenaufruf
zur Verfügung, die sich von den lokalen
Schnittstellen unterscheiden, wie Abbildung
1 zeigt. Man kann über eine entfernte
Schnittstelle auch einen „kollozierten“
Aufruf durchführen, wenn Aufrufer und
aufgerufenes Objekt auf dem gleichen
Rechnerknoten allokiert sind, so dass Ziel 2
erfüllt ist.
Aber leider sind die Kosten eines kollozierten
Aufrufs über eine entfernte Schnittstelle
fast so groß wie die bei einem entfernten
Aufruf und somit wesentlich schlechter als
die beim lokalen Aufruf über eine lokale
Schnittstelle, wie Tabelle 1 zeigt. Ein kollozierter
Aufruf über eine entfernte Schnittstelle
verursacht also große Zusatzkosten,
auf „neudeutsch“ Overhead genannt, so
dass Ziel 3 nicht erfüllt ist.
HTWG Forum
Technik Informatik
50 51
Aufrufkosten in ns
1.000.000
100.000
10.000
1.000
100
10
1
lokaler Aufruf kollozierter
Aufruf
Abb. 1: Klassische Realisierung von verteilten
Objekten/Komponenten mit Middleware
entfernter
Aufruf
Tabelle 1: Kosten für lokalen, kollozierten und
entfernten Aufruf der Methode int increment(int i)
auf einem 3 GHz Pentium IV mit Windows XP
Dieser Overhead ist in vielen Fällen nicht
tragbar, weil er die Effi zienz des Gesamtsystems,
d.h. die Antwortzeit oder den
maximalen Durchsatz, zu stark verschlechtert.
Deshalb gab es bei der zweiten Version
des Enterprise JavaBeans Standard
(EJB 2.0) großen Druck der Anwender, eine
Lösung für dieses „collocated invocation
overhead“-Problem zu fi nden [SUN 2001
b]. Daraufhin wurden sehr spät, in der letzten
vorgeschlagenen Fassung der zweiten
Version des Standards (proposed fi nal
draft 2 of the EJB 2.0 specifi cations as of
4/24/2001) [SUN 2001 a] lokale Schnittstellen
zusätzlich zu den entfernten Schnittstellen
für EJB-Komponenten eingeführt.
Mit den lokalen Schnittstellen erfüllen EJB-
Komponenten die Ziele 1 und 3, aber nicht
mehr das Ziel 2 (vergleiche [Schmid 2002]).
Verteilung von Komponenten mit
CompJava
Unser Ziel für die Verteilung von Komponenten
mit CompJava [Schmid, Pfeifer,
Schneider 2005] war, alle drei oben genannten
Ziele zu erreichen. Ein verteiltes
System von Komponenten wird durch die
Komposition einer Komponente aus möglicherweise
entfernt allokierten Subkomponenten
erstellt, die wiederum aus Subkomponenten
bestehen können, usw.
Bei der Erstellung eines verteilten Systems
von Komponenten mit CompJava ändert
sich nichts gegenüber der im letzten Jahr
skizzierten Vorgehensweise bei der Erstellung
eines lokalen Systems [Schmid,
Maucher, Pfeifer, Schneider, Ederleh, Hager
2005], außer dass zwei neue Schlüsselworte
hinzukommen.
Ein verteilter Komponententyp, genauer
gesagt, ein verteilbarer Komponententyp,
wird durch das Schlüsselwort „remotable“
gekennzeichnet. Auf Komponenten eines
verteilbaren Komponententyps kann man
von entfernten Rechnerknoten aus zugreifen.
Die Defi nition eines verteilbaren Komponententyps
erfolgt genau gleich wie die
eines lokalen Komponententyps, nur dass
für die Port-Schnittstellen eine zusätzliche
Restriktion gilt, damit überhaupt ein
entfernter Zugriff auf die Schnittstellen
möglich ist: die Java Interfaces dürfen keine
Operationen mit Parametern und Resultaten
mit (lokaler) Referenzsemantik
defi nieren, sondern mit Kopiersemantik;
das heißt, referenzierte Objekte müssen
serialisierbar sein. Abbildung 2 zeigt den
verteilten Komponententyp KundenTyp.
remotable component type KundenTyp {
port verwaltung provides Kundendaten;
}
Abb. 2: Verteilbarer Komponententyp KundenTyp
Eine verteilte Komponente wird durch das
Schlüsselwort „distributed“ gekennzeichnet.
Die Subkomponenten einer verteilten
Komponente, welche einen verteilbaren