| |
eine universelle, objektorientierte Middleware definiert. Die Entwicklung bzw. Weiterent-
wicklung des CORBA-Standards wird seit 1990 von der OMG (Object Management Group)
bestimmt. Der Laufzeitkern der CORBA-Architektur wird durch die ORB-Komponente (Ob-
ject Request Broker) und das Protokoll GIOP/IIOP (General Inter-ORB Protocol/Internet
Inter-ORB Protocol) gebildet - beides ist im CORBA-Standard spezifiziert. Hersteller von
CORBA-Implementierungen werden deshalb meist ORB-Hersteller genannt.
Eine der aktuellsten Formen von Middleware ist jüngeren Ursprungs. TCP/IP [Ste92] als
Netzwerkprotokoll, HTTP (Hyper Text Transfer Protocol) [BLa96, Fa99] als Anwendungs-
protokoll und HTML (Hyper Text Markup Language) [W3Cb] als Sprache zur Beschreibung
der Präsentation von Daten sind nun seit geraumer Zeit die Säulen des erfolgreichen World
Wide Web, hinzugekommen ist XML (Extensible Markup Language) [W3Cd] als erweiterbare
und anpassbare Dokumentbeschreibungssprache. Die Idee, XML als Austauschformat zwi-
schen verschiedenartigen Anwendungen zu benutzen, ist noch relativ jung. Seit 1999 gibt
es eine Spezifikation, welche definiert, wie ein RPC-Ruf (Remote Procedure Call) - eine der
wichtigsten Kommunikationsformen in verteilten Systemen - mit HTTP und XML realisiert
werden kann. Dieser Standard nennt sich passenderweise XML-RPC [Win99].
Die XML-RPC Spezifikation ist kurz und einfach, dafür sind die Produkte, welche XML-
RPC implementieren, auch entsprechend in ihrer Funktionalität beschränkt. Die Grundidee
allerdings, RPC-Rufe mit XML und einem HTTP-Dienst auszuführen, ist begeistert aufge-
nommen worden, zum Ersten, weil bereits eine umfassende Infrastruktur von HTTP-Diensten
in Form der Webserver-Rechner überall in der Welt besteht, somit auch der administrative
Mehraufwand gering ist, zum Zweiten, weil sich auf diese Weise ein großer Teil der in den
vergangenen Jahren entwickelten Webserver-Programmlogik (CGI/Common Gateway Inter-
face [NCS] Skripte etc.) komplett oder teilweise wiederverwenden lässt und zum Dritten, weil
sich mit dieser Architektur mögliche Komplikationen mit Firewall-Software leichter vermeiden
lassen, welche häufig so eingerichtet ist, dass Zugrife auf den Webserver-Port 80 erlaubt, alle
anderen Verbindungsaufbauten aber abgelehnt werden.
Eine Eigenschaft bei universeller Middleware wie durch den CORBA-Standard definiert ist
die hohe Komplexität, die zwangsläufig zu entstehen scheint, wenn man eine Vielzahl von
Technologien und Anwendungsbereichen unterstützen will. Eine Eigenschaft von kompakten
Technologien wie XML-RPC ist die beschränkte Menge an angebotener Funktionalität. Im
Rahmen dieser Studienarbeit werde ich versuchen, die Entwicklung einer verteilten Applikati-
on, einmal mit CORBA, einmal mit XML-RPC zu bewerten. Gegenstände der Untersuchung
sind die Theorie der Aufgabenrealisierung, die praktische Entwicklung von Anwendungen
sowie die Qualität (Leistungsfähigkeit, Efektivität, Stabilität) des Ergebnisses. Weil der
kleinste gemeinsame Nenner dieser beiden Technologien in der Umsetzung von Rufen ent-
fernter Prozeduren über Betriebssystem- und Programmiersprachengrenzen hinweg besteht,
bleibt der Anteil der CORBA-Spezifikation, der untersucht wird, auch größtenteils auf die
grundlegenden Mechanismen beschränkt.
Ich hofe, mit dieser Arbeit einige Vor- und Nachteile eines umfassenden Standards (COR-
BA) gegenüber der Verwendung eines Minimalstandards (XML-RPC) erschließen zu können.
Technologien wie XML-RPC werden nunmehr seit einigen Monaten als Web Services bezeich-
net, eine Bezeichnung, die nach [Cer02] für jede Software zutrefend ist, die über das Internet
verfügbar ist und ein standardisiertes XML Protokoll verwendet - die Art der Standardisierung
ist dabei allerdings nicht vorgeschrieben.
6
|  |
|
| |
|
|
