Verteilte Objekte

Internet und Intranet
2.3.6 Möglichkeiten und Grenzen aktueller Technologien
In der Diskussion um verteilte Objekte müssen die vorhandenen Technologien für eine Standortbestimmung
angesprochen werden, auch wenn diese nicht direkt zu einer klassischen verteilten
Middleware gezählt werden, wie sie im folgenden Kapitel 3 vorgestellt wird.
Die Entwicklung von Klient/Server Systemen auf Basis von Sockets ist ein sehr aufwendiger
Vorgang. Eine Unterstützung für objektorientierte Programmierung wird nicht geboten und der
Entwickler wird voll in die Protokollimplementierung auf den niederen Schichten des TCP/IP
einbezogen. Dies hat zur Folge, daß komplexe, auf Sockets implementierte VS automatisch
proprietär sind [ORF97].
Die Kombination aus HTTP/CGI oder HTTP/ISAPI, die prinzipiell auf Sockets basiert, ist
umständlich, zustandslos und sehr langsam. Vor allem die Zustandslosigkeit läßt dieses Modell
für große verteilte Anwendung ungeeignet erscheinen. Nichtsdestotrotz ist dieses Modell die am
häufigsten verwendete Plattform für 3-Tier-Systeme im Internet [ORF97]. Zusammenfassend
kann über diese beiden Modelle gesagt werden, daß sie nicht zuletzt auch aufgrund ihrer mangelhaften
Performanz nur für einen „Passiv Dataview“ in einer klassischen Terminal/Server
Konfiguration geeignet sind. Daten können lediglich von einem Anbieter angefordert, empfangen
und dann offline dargestellt werden. Auch wird die notwendige Sicherheit auf Transportebene nur
über „zusätzliche“ Protokolle wie SSL und SHTTP erreicht, die sich zum heutigen Zeitpunkt
noch nicht als Standard gefestigt haben.
RMI kann dagegen schon als Middleware für verteilte Objekte aufgefaßt werden. Es unterstützt
eine Schnittstellenbeschreibungssprache durch seine Implementierung in JAVA, hat eine verteilte
Garbage Collection und eine gute Performanz. RMI kann als „Objekt-BUS“ auf Basis von JAVA
bezeichnet werden, der folgende positiven Eigenschaften einführt:
• Code kann mit Daten übertragen werden.
• Durch die Implementierungssprache JAVA wird sowohl ein Sicherheitskonzept für Code, als
auch eine Schnittstellenbeschreibungssprache eingeführt.
• Objekte können „By-Value“ übergeben werden, was unter CORBA und COM nicht möglich
ist (vgl. entsprechende Kapitel 3.2.1 und 3.2.3).
Vermißt werden allerdings persistente Namensgebung und Objektreferenzen, Sicherheit auf
Transportebene und die Transaktionsunterstützung. Vor allem ist RMI aber proprietär, hat somit
auch kein sprachneutrales Übertragungsprotokoll und ist in der Implementierung auf JAVA
fixiert. Weiter ist es neu, nicht etabliert und selbst nicht standardisiert.
Als Basis für eine Plattform für verteilte Objekte in einem Unternehmen, sind die vorgestellten
Technologien damit unzulänglich.
2.4 Sicherheit
2.4.1 Sicherheit in verteilten Systemen
Vor dem Aufkommen verteilter Systeme waren Daten und Programme auf einem System
konzentriert. Dieses konnte leicht gegen verschiedenste Gefahren geschützt werden, indem die
unmittelbare Umgebung gesichert wurde. VS lassen sich dagegen nicht derartig schützen. Vergleicht
man jedes Teilsystem innerhalb eines VS mit einer Insel, muß sowohl die Insel selbst, also
auch die Kommunikation zwischen den Inseln gesichert werden. Weiter müssen sich die Inseln
gegenseitig vertrauen, um miteinander kommunizieren zu können.
Bevor man sich aber Gedanken über die Sicherung eines VS macht, muß man sich die Frage nach
dem Sinn und Aufwand der Sicherung stellen. Die Industrie ist dabei die Vorteile von VS, wie
Kostenreduktion, Distribution von Angriffspunkten, Kommunikation etc. zu erkennen und damit
diese Systeme auch einzuführen. Damit ist die Sicherheit von VS weniger eine technische, als eine
20