% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Objektkommunikation


\chapter{Verteilte Anwendungen im WWW}
\label{Kap. objektcom}
Das WWW bietet aufgrund seiner offenen, plattformunabh"angigen Standards f"ur den Informationsaustausch und der vielfach vorhandenen kostenlosen Software f"ur Client und Server eine gute Basis f"ur die Integration bestehender und neuer Anwendungen unter einer Benutzerschnittstelle. Verteilte Anwendungen k"onnen das WWW nutzen, um die Portierung von Clientsoftware auf verschiedene Betriebssystemplattformen zu vermeiden.

Verteilte Anwendungen bestehen aus mindestens zwei Komponenten, die miteinander kommunizieren. So ist das WWW eine verteilte Anwendung, bei der der {\brow} f"ur die Darstellung der vom Server per HTTP "ubertragenen HTML Dokumente verantwortlich ist. Der Server ist f"ur Lokalisierung, Retrieval, Berechnung, Layout --- z.B. bei Datenbankzugriffen mit Hilfe von CGI Skripten ({\VKA}~\ref{Kap. wwwgrla}) --- und Sendung der angeforderten Information zust"andig. Da heute im WWW viele Arbeitsplatzcomputer "uber eigene Rechenkapazit"aten verf"ugen, ist diese Verteilung des Rechenaufwandes suboptimal, weil die Ressourcen des Client bei der Berechnung der Daten ungenutzt bleiben. 

Die Nutzung der Kombination von HTML Formularen, dem HTT Protokoll und CGI Applikationen f"ur verteilte Anwendungen im WWW hat den Nachteil, da"s keinerlei Information "uber die Datentypen einer Anfrage "ubertragbar sind. Stattdessen besteht diese aus Zeichenketten, die das CGI Programm interpretieren und mit Semantik besetzen mu"s. Es kann also keine typsichere Parameter"ubergabe zugesichert werden, da weder Client noch Server "uberpr"ufen k"onnen, ob die "ubergebenen Parameter der Schnittstellendefinition entsprechen. Die in Abschnitt~\ref{objektcomTech} vorgestellten Technologien f"ur verteilte Anwendungen erm"oglichen die typsichere "Ubergabe von Parametern in der Kommunikation zwischen Client und Server.

Voraussetzung f"ur eine bessere Verteilung des Rechenaufwandes sowie der eventuellen Reduzierung der Netzwerkzugriffe durch lokal durchgef"uhrte Berechnungen ist die Ausf"uhrung von Programmcode auf dem Rechner des Benutzers. Die in Abschnitt~\ref{aktKomp} vorgestellten Technologien erlauben die Einbettung von Programmcode in HTML Seiten, der auf dem Benutzerrechner ausgef"uhrt wird. Hierbei sind zwei Varianten der Programmexekution zu unterscheiden:

\begin{description}
\item [Lokale Ausf"uhrung:] Nach dem Laden des Programmcodes vom Server erfolgt dessen Ausf"uhrung auf dem Clientrechner, ohne da"s eine direkte Kommunikation zwischen dem geladenen Clientcode und einem auf einem anderen Rechner laufenden Programm stattfindet. Ein Beispiel hierf"ur ist ein {\java} Applet, das eine Animation auf dem Clientrechner ausf"uhrt, oder ein {\javas} Programm, das die Korrektheit von Benutzereingaben in einem HTML Formular "uberpr"uft. 
\item [Verteilte Ausf"uhrung:] Ein "uber das WWW geladenes Clientprogramm kommuniziert mit einem oder mehreren Serverprogrammen auf einem entfernten Rechner. Dies ist z.B. der Fall bei einem {\java} Applet, das eine Verbindung mit einer Datenbank auf einem Server aufbaut und Operationen auf der Datenbank ausf"uhrt.
\end{description}

Die lokale Ausf"uhrung kommt in F"allen in Betracht, in denen das Programmobjekt mobil ist. Dies ist z.B. bei Datenbanken und gro"sen Programmobjekten nicht der Fall und auch nicht gew"unscht, da dadurch dem Benutzer evtl. die gesamte Informationsbasis eines Unternehmens zur Verf"ugung gestellt w"urde. Andererseits ist bei der Aufteilung gro"ser Programme in mehrere kleine Komponenten die "Ubernahme von Teilfunktionalit"at durch den Client, wie z.B. der grafischen Aufbereitung der Datens"atze einer Datenbankabfrage erstrebenswert. Dies hat bei wiederholter Nutzung des Codes durch den Client eine Entlastung von Server und Netzwerk sowie eine bessere Ausnutzung der Clientressourcen zur Folge.

Die Kommunikation in verteilten Anwendungen erfordert oft das Management individueller Kommunikationszust"ande, die sich aus sequentiell aufeinanderfolgenden Vorg"angen ergeben. Ein klassisches Beispiel daf"ur ist ein Buchungsvorgang f"ur eine Urlaubsreise, der sowohl eine Flugbuchung, eine Hotel-- sowie eine Mietwagenreservierung umfa"st \cite{KrL96}. Diese drei voneinander getrennten Vorg"ange stehen in einem unmittelbaren zeitlichen und "ortlichen Zusammenhang und erfordern eine zusammenh"angende transaktionale Behandlung, da, falls einer der genannten Vorg"ange nicht durchf"uhrbar ist, die evtl. schon erfolgten Buchungen automatisch zur"uckgenommen werden m"ussen. Da HTTP ein verbindungsloses Protokoll ist, werden verschiedene Zust"ande der Kommunikation zwischen Client und Server nicht unterst"utzt, vielmehr wird jede Anfrage eines Client unabh"angig von der vorhergehenden behandelt. Andere verteilte Anwendungen wie z.B. Telekonferenzanwendungen und Mehrbenutzerspiele erfordern inh"arent einen hohen Grad an Benutzerinteraktion und einen verbindungsorientierten Kommunikationsmechanismus zwischen den beteiligten Programmobjekten. 

Komponentenmodelle wie z.B. {\com} erlauben die einfache Komposition von Softwarekomponenten verschiedener Hersteller zu kompletten Applikationen. Der Vorteil der Komponentenmodelle liegt in dem hohen Abstraktionsgrad des vorhandenen Codes. Komponenten f"ur Benutzerschnittstellen, Applikationsalgorithmen und Datenverwaltung k"onnen vom Anwender mit Hilfe von Skriptsprachen und grafischen Editoren zu vollst"andigen Applikationen zusammengesetzt werden \cite{Bo95}. Komponentenmodelle ben"otigen f"ur die Interaktion zwischen Komponenten auf dem gleichen Rechner, genau wie f"ur Zugriffe auf im Netzwerk verteilte Komponenten einen Kommunikationsmechanismus.

Bessere Ressourcennutzung in verteilten Anwendungen, Typisierung von Parametern in der Kommunikation zwischen Client und Server, immobile Objekte, das Management von Kommunikationszust"anden und die Unterst"utzung von Komponentenmodellen sind Gr"unde f"ur die Notwendigkeit zus"atzlicher Mechanismen zur Kommunikation verteilter Objekte im WWW. Diese Mechanismen erlauben die Nutzung bereits vorhandener und eventuell sehr umfangreicher Programme und Daten auf entfernten Rechnern "uber das WWW, dessen grundlegende Kommunikationstechnologie (CGI und HTTP, {\VKA}~\ref{Kap. wwwgrla}) f"ur die Bereitstellung statischer Informationen und einfacher formulargesteuerter Anwendungen geeignet ist. 

Nach einer Einf"uhrung in Terminologie und Konzepte verteilter Anwendungen ({\VAS}~\ref{objektcomKonz}) werden in Abschnitt~\ref{objektcomAnf} Anforderungen an Kommunikationsmechanismen f"ur verteilte Objekte erarbeitet. Darauf aufbauend werden im folgenden drei kommerziell relevante Ans"atze zur Kommunikation von verteilten Objekten im WWW vorgestellt. Die {\em Common Object Request Broker Architecture} ({\corba}) erlaubt die plattform-- und sprach\-un\-ab\-h"angige Kommunikation zwischen beliebig im Netzwerk verteilten Applikationen ({\VAS}~\ref{corba}). Die {\em Remote Method Invocation} ({\rmi}) ist eine Klassenbibliothek der Programmiersprache {\java} ({\VAS}~\ref{code}) und erm"oglicht das Referenzieren von {\java} Objekten und den Aufruf ihrer Methoden "uber ein Netzwerk ({\VAS}~\ref{rmi}). Das {\em Distributed Component Object Model} ({\dcom}), das bisher auf die {\msw} Plattform beschr"ankt ist (Stand Juli 1997), unterst"utzt die Kommunikation zwischen Bi\-n"ar\-code\-kom\-ponenten auf verteilten Rechnern ({\VAS}~\ref{dcom}). 


\section{Terminologie und Konzepte}
\label{objektcomKonz}
In verteilten Anwendungen versteht man unter einem {\em Server} einen Proze"s, der auf Kommunikationsanforderungen eines anderen Prozesses -- des {\em Clients} -- wartet und auf diese reagiert \cite{Ma96}. Es spielt dabei keine Rolle, ob Client und Server auf dem gleichen oder verschiedenen Rechnern laufen. 

Damit Client und Server miteinander kommunizieren k"onnen, stellt der Server eine Schnittstelle mit Operationen zur Verf"ugung, die der Client transparent in seinen Programmtext einbetten und aufrufen kann. 
Die Implementation der Schnittstelle wird durch den Server bereitgestellt ({\VAB}~\ref{csKonzept}). 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/objektcom/csKonzept.eps}
\end{center}
\caption{Kommunikation zwischen verteilten Anwendungen}
\label{csKonzept}
\end{figure}

Der Client ruft die auf dem Server implementierten Operationen mit Hilfe eines {\em Stub} auf. Ein Stub nimmt Funktionsaufrufe des Client entgegen, konvertiert diese inklusive aller "ubergebenen Parameter in eine zur Netzwerk"ubertragung geeignete serielle Repr"asentation ({\em marshalling}) und leitet sie f"ur den Client transparent "uber einen Kommunikationsmechanismus an den Server weiter. Auf der Serverseite rekonstruiert der {\em Skeleton} den Funktionsaufruf und die Parameter aus der seriellen Repr"asentation ({\em unmarshalling}) und leitet die entsprechenden Funktionsaufrufe an die Funktionsimplementation weiter. Der Server f"uhrt die Funktion aus und "ubergibt das Ergebnis an den Skeleton. Der Skeleton "ubernimmt das {\em marshalling} des Ergebnisses und leitet dieses "uber einen Kommunikationsmechanismus an den Client weiter, dessen Stub das {\em unmarshalling} des Ergebnisses und die Ergebnis"ubergabe an den Client vollzieht.
 
Stub und Skeleton werden aus einer gesondert zur Implementation zu definierenden Schnittstellenbeschreibung mit Hilfe eines speziellen Compilers generiert. Wird die Schnittstelle z.B. durch das Hinzuf"ugen neuer Operationen oder Signaturmodifikationen ge"andert, ist f"ur die Nutzung der neuen Funktionalit"at ein neuer Generierungsvorgang erforderlich.

Ziel dieses mehrschichtigen Kommunikationsmodells ist die Abstraktion von den Kommunikationsvorg"angen zwischen Client und Server. Der Client erh"alt "uber ein Stellvertreterobjekt ({\em Proxy}) die Illusion, direkt mit dem Server zu kommunizieren. Der Proxy verf"ugt "uber die gleichen Schnittstellen wie die Implementation des Serverobjektes. Diese werden vom Client angesprochen und der Proxy leitet die Anfragen des Clientobjektes mit Hilfe des Stub "uber das Netzwerk an die Implementation des Objektes weiter. F"ur den Client entsteht so der Eindruck, er w"urde mit einem lokalen Objekt kommunizieren. Der Applikationsprogrammierer mu"s sich nicht um Details der Kommunikation wie z.B. Datenformate und Protokolle k"ummern, sondern kann entfernte Dienste transparent nutzen.

Der Vorgang des Aufrufens von auf entfernten Rechnern vorhandenen Operationen wird als {\em entfernter Methoden-} oder {\em Prozeduraufruf} bezeichnet.

\subsection*{ORB versus RPC}
\label{orbVersusRPC}
Man unterscheidet zwei Arten des entfernten Methodenaufrufes.  Ein {\em Object Request Broker} (ORB) unterst"utzt das klassische Objektmodell, indem Methodenaufrufe an eine spezifische Instanz einer Objektklasse weitergeleitet werden, die "uber ihre privaten Daten in Form von Attributen verf"ugt. Ein {\em Remote Procedure Call} (RPC) greift hingegen auf eine Funktion zu, die nicht "uber spezifische Instanzdaten verf"ugt. Beim RPC werden die zu bearbeitenden Daten in der Regel in Form von Parametern "ubergeben bzw. referenziert, w"ahrend beim ORB Ansatz spezifische Instanzen von Objekten mit einem individuellen Zustand angesprochen werden.

Desweiteren bieten ORBs das Konzept des Polymorphismus, d. h. unterschiedliche Objektklassen verhalten sich bei Aufruf der gleichen Methode unterschiedlich. Abbildung~\ref{orbVerRpc} (nach \cite{OH97}) verdeutlicht die Unterschiede zwischen den beiden Konzepten.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=3,5cm
\epsffile{Bilder/objektcom/orbVerRpc.eps}
\end{center}
\caption{ORB versus RPC }
\label{orbVerRpc}
\end{figure}


\section{Anforderungen an Kommunikationsmechanismen f"ur verteilte Objekte im WWW}
\label{objektcomAnf}
Auf Basis von \cite{Ri97} und \cite{Sch97} werden im folgenden Anforderungen an Kommunikationsmechanismen f"ur verteilte Objekte im WWW aufgestellt:

\begin{description}

\item[Behandlung der Heterogenit"at von Plattformen:] Die an einem verteilten System beteiligten Rechner stammen in der Regel von verschiedenen Herstellern und benutzen unterschiedliche Betriebssysteme und Datenformate. Damit Objekte auf unterschiedlichen Plattformen miteinander kommunizieren k"onnen, mu"s ein einheitliches Datenaustauschformat definiert werden. 

\item[Behandlung der Heterogenit"at von Programmiersprachen:] Damit Systeme, die in unterschiedlichen Programmiersprachen implementiert wurden, miteinander kommunizieren k"on\-nen, m"ussen Schnittstellendefinition und Implementierung voneinander getrennt werden. Ein Kommunikationsmechanismus kann dann anhand der Schnittstellenbeschreibungen Methodenaufrufe an die Implementierung weiterleiten.

\item[Integration mit bestehender WWW Infrastruktur:] Es mu"s m"oglich sein, Objekte "ahnlich wie HTML Seiten "uber das WWW zu verteilen, mit den verteilten Objekten die F"ahigkeiten der {\brow} zu erweitern sowie eine Interaktion zwischen einer HTML Seite und einem integrierten Objekt herzustellen.

\item[Lokale Sicherheit des Client im WWW:] Ein WWW Client mu"s sich auf die sichere Ausf"uhrung eines unbekannten "uber das WWW geladenen Programms verlassen k"onnen. So sollte es f"ur einen Client m"oglich sein, sein System vor unerw"unschten Zugriffen auf seine lokale Festplatte zu sch"utzen, das Starten von anderen Anwendungen zu verhindern und den Aufbau beliebiger Netzwerkverbindungen zu entfernten Rechnern zu verbieten. 

\item[Entwicklungsunterst"utzung:] Neben leicht handhabbaren Kommunikationsdiensten sind Systemdienste wie z.B. Transaktionsmanagement, Lizensierung von Aufrufen verteilter Objekte, Speicherung von Objekten, etc. w"unschenswert. Au"serdem werden Werkzeuge ben"otigt, die die einfache Integration von verteilten Objekten in HTML Seiten erm"oglichen sowie Generatoren f"ur Stubs und Skeletons aus Schnittstellenbeschreibungen. 

\item[Dynamisches Finden und Aufrufen von Objekten:] Softwarekomponenten m"us\-sen sich dynamisch zur Laufzeit zu einem Gesamtsystem zusammenf"ugen lassen und Methodenaufrufe sollten zur Laufzeit aus Schnittstellenbeschreibungen generierbar sein, um die Austauschbarkeit von Objekten zu gew"ahrleisten, da zum "Ubersetzungszeitpunkt von Client und Server nicht immer bekannt ist, welche Schnittstellendefinitionen zur Kommunikation verwendet werden. Handelt es sich bei dem Server z.B. um einen Interpreter, der zur Laufzeit neue Objektbeschreibungen verarbeitet und so neue Objektschnittstellen bereitstellt, mu"s es m"oglich sein, diese neuen Objekte von einem entfernten Rechner aufzurufen. Clients k"onnen z.B. Vermittlungsdienste\footnote{Der {\corba} {\em Trader Service} erlaubt Objekten ihre Dienste "offentlich bekannt zu machen und f"ur Auftr"age anzubieten. Der Dienst ist vergleichbar mit einem Branchentelefonbuch wie z.B. den "`Gelben Seiten"'.} benutzen, um Objekte in einem Netzwerk zu finden. Da den Clients nach dem Finden eines Objektes zur Benutzung desselben in der Regel kein Stub zur Verf"ugung steht, mu"s es Mechanismen geben, die den Client mit Metainformationen (z.B. Methodennamen, ben"otigte Parameter und deren Typen) "uber das Objekt versorgen und es ihm erlauben das Objekt dynamisch aufzurufen. Dieses Vorgehen ist insbesondere im WWW im Rahmen einer wirtschaftlichen Nutzung von verteilten Objekten w"unschenswert, z.B. zur Nutzung der preiswertesten Druck- oder Konvertierungsdienste, die evtl. zum Erstellungszeitpunkt des Client noch gar nicht existierten.

\end{description}

Eine weitere --- insbesondere im WWW wichtige --- Anforderung ist die Kommunikation "uber die Grenzen von {\em Firewalls}. Eine Firewall entscheidet anhand einer festgelegten Sicherheitsstrategie, welche Anfragen von au"sen in ein an das Internet angeschlossenes Firmennetz gelangen und welche Pakete das Firmennetz in umgekehrter Richtung verlassen d"urfen. Um die Kommunikation zwischen verteilten Objekten auch "uber die Grenzen von Firewalls hinweg zu erm"oglichen, gibt es zwei Ans"atze. Der erste Ansatz basiert auf einem Proxy Mechanismus, bei dem auf dem Firewall-Rechner eine Stellvertreteranwendung f"ur den eigentlichen Objektserver eingerichtet wird. Dieser Proxy entscheidet anhand einer Zugangskontrolliste, ob eine Anfrage an das auf dem internen Server vorhandene Objekt gestattet oder abgelehnt wird. Der zweite Ansatz bettet Anfragen an einen Objektserver in HTTP Anfragen ein. Dies wird als {\em Tunneling} bezeichnet. Da auf einer Firewall in der Regel ein HTTP Proxy vorhanden ist, erspart man sich so die Installation und Pflege eines zus"atzlichen Proxy. Allerdings erfordert das {\em Tunneling} sowohl auf der Client- als auch auf der Serverseite den Einsatz von Kodierern bzw. Dekodierern, die die jeweiligen Kommunikationsprotokollaufrufe in HTTP Aufrufe ver- bzw. entpacken. Die im Abschnitt~\ref{objektcomTech} betrachteten Technologien unterst"utzen neben dem Proxy Mechanismus das {\em Tunneling} von Anfragen an einen Objektserver in HTTP Anfragen, daher wird diese Anforderung nicht im Einzelnen n"aher betrachtet.

Die o.g. Anforderungen bilden die Grundlage f"ur die Bewertung der im Folgenden vorgestellten Technologien in Abschnitt~\ref{objektcomVergl}.

\section{Technologien}
\label{objektcomTech}
{\java} ist u.a. aufgrund seiner Plattformunabh"angigkeit, des Sicherheitskonzeptes, der Codemobilit"at und der Unterst"utzung grafischer Benutzerschnittstellen eine geeignete und weitverbreitete Technologie zur Verteilung von Programmobjekten "uber das WWW ({\VAS}~\ref{code}). Mit Schnittstellen zu Datenbanken ({\em Java Database Connectivity}, {\jdbc}), der Anbindung an {\corba} Systeme und entfernten Methodenaufrufen ({\rmi}) stehen Kommunikationsmechanismen zur Realisierung verteilter Anwendungen zur Verf"ugung. Die jeweils verwendeten Schnittstellen und Protokolle zur Daten"ubertragung sind in Abbildung~\ref{javaKommu} dargestellt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/objektcom/javaKommu.eps}
\end{center}
\caption{Kommunikationsmechanismen in {\java} Anwendungen}
\label{javaKommu}
\end{figure}

W"ahrend {\jdbc}\footnote{{\jdbc} wird in dieser Arbeit nicht n"aher betrachtet, da hier allgemeine Kommunikationsmechanismen von Interesse sind, die nicht an einen bestimmten Typ von Server gebunden sind. Interessierte Leser finden weitere Informationen in \cite{JaAPI,Ha96,OH97}.} auf die Kommunikation zwischen SQL Datenbanken und {\java} Anwendungen beschr"ankt ist und {\rmi} ({\VAS}~\ref{rmi}) die Kommunikation zwischen beliebigen {\java} Anwendungen "ubernehmen kann, bietet die {\corba} ({\VAS}~\ref{corba}) Anbindung durch ihre Sprachunabh"angigkeit und Verf"ugbarkeit auf diversen Plattformen den weitreichendsten Ansatz. Im Gegensatz zu den {\java} Ans"atzen, die auf plattformunabh"angigem Bytecode basieren, stellt das {\em Distributed Component Object Model} (DCOM, {\VAS}~\ref{dcom}) einen sprachunabh"angigen Kommunikationsmechanismus f"ur verteilte Bin"arcodeobjekte zur Verf"ugung.

\subsection{{\corba}}
\label{corba}
Die {\em Common Request Broker Architecure} ({\corba}) ist ein Standard der {\em Object Management Group} ({\omg}) zur Kommunikation zwischen heterogenen Softwarekomponenten. Diese Komponenten k"onnen sich auf verschiedenen Rechnern befinden, in verschiedenen Programmiersprachen und auf unterschiedlichen Betriebssystemen implementiert sein. Die Spezifikation von {\corba} \cite{corba} definiert neben einem grundlegenden Objektmodell, eine Schnittstellenbeschreibungssprache (IDL), in der die Schnittstelle zwischen Client und Server definiert wird ({\VAS}~\ref{objektcomKonz}), die verschiedenen Bestandteile eines {\em Object Request Broker} (ORB) inklusive der jeweiligen Anwendungsprogrammierschnittstellen (API), Protokolle f"ur die Interoperabilit"at zwischen verschiedenen Implementationen unterschiedlicher Hersteller von ORBs sowie Abbildungen der IDL auf einige Programmiersprachen (u. a. {\cc}, {\cpp} und {\st}). An einer standardisierten Abbildung der IDL auf die Programmiersprache {\java} wird noch gearbeitet (Stand Juli 1997). Einige Hersteller von ORBs bieten jedoch bereits IDL Compiler f"ur {\java} an. 

\subsubsection*{Die Bestandteile eines ORB}
Ein {\em Object Request Broker} (ORB) ist der Vermittler von Methodenaufrufen zwischen entfernten Objekten. Er ist f"ur die Suche des Objektes, das die erforderlichen Dienste erf"ullt, f"ur die Weitergabe der Parameter, den Aufruf der Methoden und die R"uckgabe von Ergebnissen zust"andig \cite{corba}. In Abbildung~\ref{orb} (aus \cite{OH97}) sind die Bestandteile eines ORB dargestellt:
\begin {description}
\item[Client IDL Stub:] Ein Client IDL Stub entsteht aus der "Ubersetzung einer in IDL abgefa"sten Schnittstellenbeschreibung in die jeweilige Zielprogrammiersprache (z.B. {\cc}, {\cpp}, {\st}, {\java}, etc.). Der dabei entstehende Stub definiert, in welcher Weise ein Client in der Schnittstelle definierte Dienste einer Objektimplementation in der von ihm gew"ahlten Programmiersprache aufruft. Der Stub ist ein lokales Stellvertreterobjekt f"ur das (evtl. entfernte) Serverobjekt und "ubernimmt die Serialisierung und Deserialisierung von Parametern. Der Client IDL Stub wird zum "Ubersetzungszeitpunkt des Clientprogramms eingebunden.
\item[Dynamic Invocation Interface (DII):] Mit Hilfe des DII ist es f"ur den Client m"oglich, Objekte zu benutzen, die erst nach der "Ubersetzung des Clients erstellt werden. {\corba} definiert Standardprogrammierschnittstellen, die das Retrieval von Serverschnittstellen, die Generierung von Parametern und den dynamischen Aufruf eines entfernten Objektes erlauben.
\item[Interface Repository:] Im Interface Repository werden IDL Definitionen wie in einer Datenbank persistent abgelegt. So k"onnen Clients zur Laufzeit f"ur beliebige Objekte Informationen "uber den Aufbau der zugeh"origen Schnittstellen einholen, unabh"angig davon, ob diese bei der Entwicklung des Clientprogramms bereits bekannt waren. 
\item[ORB Interface:] Das ORB Interface stellt lokale Dienste des ORB zur Verf"ugung wie z.B. die Konvertierung einer Objektreferenz in eine Zeichenkette und umgekehrt, diese Operation kann f"ur die persistente Speicherung von Objektreferenzen n"utzlich sein.
\item[Server IDL Skeleton:] Der Server IDL Skeleton stellt statische Schnittstellen zu einem von einem Server exportierten Dienst bereit. Ein Skeleton wird wie ein Stub mit Hilfe eines IDL Compilers erzeugt. 
\item[Dynamic Skeleton Interface (DSI):] Das DSI erlaubt als Pendant zum DII die Bereitstellung von Objektimplementationen f"ur Schnittstellen, die zur "Ubersetzungszeit des Servers noch unbekannt sind. Dies ist z.B. der Fall, wenn es sich bei dem Server um einen Interpreter handelt, der w"ahrend seiner Laufzeit Programme einliest und so erst von neuen Objektklassen, deren Schnittstellen und Implementationen erf"ahrt.
\item[Object Adapter (OA):] Der OA "ubernimmt die Vermittlung zwischen ORB und Ob\-jekt\-im\-ple\-mentation, er generiert und interpretiert Objektreferenzen, gibt Methodenaufrufe weiter, aktiviert und deaktiviert Objekte. Er registriert au"serdem die von ihm unterst"utzten Klassen und ihre Instanzen im Implementation Repository.
\item[Implementation Repository:] Im Implementation Repository werden die von einem Server unterst"utzten Klassen sowie deren Instanzen abgelegt. Es erm"oglicht dem ORB die Lokalisierung und Aktivierung von Objekten.
\end {description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/objektcom/orb.eps}
\end{center}
\caption{Die Bestandteile eines {\em Object Request Broker} (ORB) }
\label{orb}
\end{figure}

{\corba} definiert eine Architektur und eine Reihe von Anwendungsprogrammierschnittstellen, die ein ORB bereitstellen mu"s. Die Implementation der Architektur und der APIs ist herstellerspezifisch. ORBs verschiedener Hersteller k"onnen nicht ohne zus"atzliche Vereinbarungen miteinander kommunizieren. Um Objekte "uber die Grenzen eines ORBs hinaus nutzen zu k"onnen, sind Protokolle f"ur die Kommunikation zwischen den ORBs verschiedener Hersteller erforderlich.

\subsubsection*{Interoperabilit"at zwischen verschiedenen ORBs}
Im Zusammenhang mit dem WWW ist das {\em Internet inter-ORB Protocol} (IIOP) von besonderem Interesse. IIOP ist eine konkrete Realisierung des abstrakten {\em General Inter-ORB Protocol} (GIOP), das eine standardisierte Transfersyntax und eine Menge von Nachrichtenformaten f"ur die Kommunikation zwischen ORBs spezifiziert. Genau wie die {\corba} IDL nicht benutzt werden kann, um komplette Anwendungen zu programmieren und eine Abbildung auf eine konkrete Programmiersprache erfordert, erfordert das GIOP eine Abbildung auf ein konkretes Transportprotokoll. Das IIOP spezifiziert, wie GIOP Nachrichten "uber TCP/IP Verbindungen ausgetauscht werden.

\subsubsection*{Objektdienste}
\label{corbaOma}
Die {\corba} Spezifikation ist Basis der {\em Object Management Architecture} (OMA), die ebenfalls von der {\omg} entwickelt wird. In dieser Architektur werden zus"atzlich zu der Transport- und "Uber\-tra\-gungs\-kom\-po\-nente ORB unter anderem standardisierte Objektdienste zur Ver\-f"u\-gung gestellt, die "uber in IDL spezifizierte Schnittstellen verf"ugen. Es gibt u.a. Dienste, die die Speicherung von Objekten auf verschiedenen Medien unterst"utzen, die Abrechnungsmechanismen f"ur die Nutzung verteilter Objekte anbieten, f"ur das Transaktionsmanagement, etc. \cite{Os97}.

\subsubsection*{WWW Integration}
\label{corbaWWW}
Die Integration von {\corba} Anwendungen und dem WWW kann mit Hilfe der Programmiersprache {\java} erfolgen. {\java} kann dynamisch Code von einem Server aus dem Netzwerk laden. So ist es nicht n"otig, Komponenten einer {\corba} Anwendung vor der Ausf"uhrung lokal zu installieren, da {\java} neben der Anwendung selbst auch den Client IDL Stub sowie den ORB\footnote{{\net} integriert in seine kommende Version des {\nav} einen ORB, so da"s dieser bei Verwendung des gleichen ORB zur Erstellung der {\corba} Clientanwendung nicht mehr vom WWW Server geladen werden mu"s.}  "uber das WWW dynamisch zum Client "ubertragen kann ({\VAB}~\ref{corbaOrblet}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/objektcom/corbaWWW.eps}
\end{center}
\caption{Integration von {\corba} und WWW}
\label{corbaOrblet}
\end{figure}

Nachdem Applet, Client IDL Stub und evtl. der ORB zum Client "ubertragen wurden, steht neben dem klassischen Zugang zu externen Anwendungen "uber HTTP und CGI mit dem IIOP ein weiteres speziell f"ur verteilte Anwendungen entworfenes Protokoll f"ur {\java} Applets zur Verf"ugung. Die Kommunikation von einem {\corba} Server zu bereits vorhandenen Systemen ({\em legacy systems}) wie z.B. Datenbanken oder Transaktionsmonitoren "ubernimmt wiederum der ORB bzw. IIOP.

{\corba} und IIOP f"ugen sich aufgrund ihrer offenen Standardisierung in die offenen Standards des WWW ein, w"ahrend die im Folgenden betrachteten Ans"atze {\rmi} und {\dcom} den Entwickler verteilter Anwendungen in plattform- oder programmiersprachenabh"angige Abh"angigkeiten f"uhren k"onnen, deren Verhinderung von vornherein das erkl"arte Ziel von WWW und {\corba} war.


\subsection{{\java} {\rmi}}
\label{rmi}
Die Version 1.1 des {\java} API enth"alt mit der {\em Remote Method Invocation} ({\rmi}) Klassenbibliothek die F"ahigkeit, {\java} Objekte auf entfernten Rechnern zu referenzieren und deren Methoden aufzurufen. Es handelt sich bei RMI um einen Mechanismus, der die Semantik von entfernten Prozeduraufrufen ({\em Remote Procedure Call}, RPC) auf  Objektaufrufe in verteilten Objektsystemen abbildet \cite{RMI}.

Eine in einem {\java} {\em Interface} definierte Schnittstelle beschreibt die Methoden eines entfernten Objektes, die von einem Client aufgerufen werden d"urfen. Diese Schnittstelle wird in einer oder mehreren Klassen implementiert. Nach der "Ubersetzung dieser Klassen mit einem speziellen {\rmi} Compiler steht dem Client ein Stellvertreterobjekt ({\em Stub}) zur Verf"ugung, das das entfernte Objekt auf dem Clientrechner lokal abbildet und alle Methodenaufrufe an die Objektimplementation auf dem Server weiterleitet. Neben dem Stub wird aus der Serverimplementation ein {\em Skeleton} generiert, das die Methodenaufrufe des Client auf dem Server an die Objektimplementation weiterleitet und Berechnungsergebnisse an den Client zur"uckgibt. Stub und Skeleton tauschen hierbei Objekte mit Hilfe der {\em Object Serialization Specification} (OSS) aus, die das Serialisieren von {\java} Objekten erm"oglicht \cite{He97}. Neben dem Austausch von Objekten zwischen Client und Server k"onnen auch Objektreferenzen als Parameter in Methodenaufrufen "ubergeben werden.

Das Auffinden einer Objektimplementation "ubernimmt ein nicht persistenter Namensdienst: die {\em Registry}. Dabei handelt es sich um eine Laufzeitdatenbank, die nach ihrem Start mit den Namen und Adressen von Objekten gef"ullt wird. Wird der Registry-Proze"s beendet, gehen s"amtliche darin vorhandenen Eintr"age verloren. Dieser Dienst erlaubt die Registrierung und das Retrieval von Serverobjekten anhand von Namen, z.B. erfolgt die Registrierung eines Objektes "'this"' unter dem Namen "'my object"' folgenderma"sen:

\begin{xple}
java.rmi.Naming.rebind("'my object"', this);
\end{xple}
 
Der Client benutzt ein URL Schema, um auf dieses Objekt zuzugreifen:

\begin{xple}
ObjRMI myObject = (ObjRMI) java.rmi.Naming.lookup("'rmi://www.foo.bar/my object"');
\end{xple}

Die Registry ist als ein {\rmi} Serverobjekt auf dem gleichen Rechner aktiv, wie die Objekte, die es verwaltet ({\VAB}~\ref{rmiStruktur}, (1)). Es verf"ugt nicht "uber Beschreibungen der verwalteten Objekte, sondern gibt lediglich dem Client anhand einer URL eine Referenz auf den Skeleton (3) der Implementation, der enfernte Methodenaufrufe erm"oglicht. Der Client ruft dann "uber seinen Stub (2) die entfernten Objekte auf. Mehrere Registry Objekte k"onnen parallel auf einem Rechner aktiv sein. Die {\rmi} Klassenbibliothek enth"alt weitere Klassen, die es dem Client und dem Server erm"oglichen, eine Referenz auf Registry Objekte zu erhalten.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/objektcom/rmiStruktur.eps}
\end{center}
\caption{Entfernte Methodenaufrufe in {\java}}
\label{rmiStruktur}
\end{figure}

Die Beseitigung nicht mehr referenzierter Objekte durch Freigabe des von ihnen belegten Speicherplatzes (engl. {\em Garbage Collection}) wird bei entfernten wie lokalen Objekten automatisch und f"ur den Programmierer transparent durchgef"uhrt. In verteilten Sytemen stellt sich immer die Frage, wann ein Serverobjekt entfernt werden darf. {\rmi} benutzt zur Beantwortung dieser Frage einen Z"ahler, der die aktiven Referenzen in Form von Client/Server Verbindungen in TCP/IP Sitzungen "uberwacht. Solange eine Referenz zu einem entfernten Objekt besteht, kann dieses nicht entfernt werden. 

\subsubsection*{WWW Integration}
\label{rmiWWW} 
Im WWW erlaubt {\rmi} die Kommunikation von {\java} Applets und entfernten {\java} Serverprogrammen. Die Integration des {\rmi} in das {\em {\java} Development Kit} (JDK) ab der Version 1.1 wird das zus"atzliche Laden der {\rmi} Funktionalit"at bei der Benutzung von Applets "uberfl"ussig machen, sobald das JDK 1.1 von den verbreiteten {\brow}n unterst"utzt wird ({\VAB}~\ref{rmiJavaWWW}). 
 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/objektcom/rmiWWW.eps}
\end{center}
\caption{Integration von {\java} {\rmi} und WWW}
\label{rmiJavaWWW}
\end{figure}

{\rmi} erfordert auf der Serverseite die Kapselung von bereits vorhandenen Anwendungen ({\em legacy systems}) in {\java} Code. Im Gegensatz dazu erlaubt {\corba} die Kommunikation verteilter Objekte unabh"angig von der verwendeten Programmiersprache.

\subsection{{\dcom}}
\label{dcom}
Komponententechnologie ist insbesondere auf {\msw} Betriebssystemen in Form von {\em OCX Controls} weit verbreitet und erlaubt dort die Wiederverwendung bin"aren Codes in integrierten Entwicklungsumgebungen wie z.B. {\ms} {\vb} und Anwendungsprogrammen wie z.B. {\ms} {\word}. {\ax} ist der Nachfolger der OCX Technologie und erlaubt die Verteilung von Softwarekomponenten "uber das WWW ({\VAS}~\ref{code}). {\ax} basiert auf dem {\em Distributed Component Object Model} ({\dcom}).

{\dcom} ist die Antwort der Firma {\ms} auf die Frage nach einem Mechanismus f"ur die Vermittlung von Funktionsaufrufen zwischen verteilten bin"aren Objekten.  {\dcom} ist eine Erweiterung des {\em Component Object Model} ({\com}) \cite{MS97}. {\com} definiert, wie bin"are Softwarekomponenten und ihre Klienten miteinander auf einem einzelnen Rechner kommunizieren k"onnen. {\dcom} erweitert {\com} um die M"oglichkeit zur Kommunikation zwischen Komponenten auf verschiedenen Rechnern und basiert auf dem Konzept entfernter Prozeduraufrufe ({\VAS}~\ref{objektcomKonz}). {\dcom} definiert eine eigene Objektterminologie, die sich grundlegend von klassischen Objektmodellen unterscheidet, wie sie von {\corba} und {\rmi} verwendet werden. 

\subsubsection*{{\dcom} Objekte}
Wie in {\corba} und {\rmi} werden Objektschnittstellen von ihrer Implementation getrennt. Dies geschieht mit einer Schnittstellenbeschreibungssprache (IDL), die nicht zur {\corba} IDL kompatibel ist. Ein {\dcom} Objekt --- auch als {\ax} bezeichnet --- ist eine plattformabh"angige Softwarekomponente, die eine oder mehrere {\dcom} Schnittstellen unterst"utzt. Eine {\dcom} {\em Schnittstelle} ist eine Sammlung von Methoden. Um auf eine solche Schnittstelle zuzugreifen, benutzen Clients Zeiger auf ein Feld von Funktionszeigern. Dieses Feld wird als virtuelle Tabelle ({\em vtable}) bezeichnet. Die in der virtuellen Tabelle enthaltenen Zeiger referenzieren die Implementation der jeweiligen Methoden ({\VAB}~\ref{dcomObj}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/objektcom/dcomObj.eps}
\end{center}
\caption{Struktur eines {\dcom} Objektes}
\label{dcomObj}
\end{figure}

{\dcom} Schnittstellen sind Kontrakte zwischen Client und Server, sie kapseln ein Objekt und bieten Clients die M"oglichkeit, "uber einen auf der Tabelle von Zeigern basierenden API auf das Objekt zuzugreifen. Jede Schnittstelle wird zur Laufzeit "uber einen global eindeutigen Schnittstellenbezeichner (IID) in Form einer 128-Bit Zahl referenziert, die mit Hilfe einer Funktion des {\dcom} API erzeugt wird. Diese Funktion benutzt das aktuelle Datum, die aktuelle Zeit, die ID der Netzwerkkarte und einen Hochfrequenzz"ahler zur Erzeugung einer global eindeutigen 128-Bit Zahl.

Ein {\dcom} Objekt ist eine Laufzeitinstanz seiner Klasse. Eine {\dcom} Klasse implementiert eine oder mehrere Schnittstellen und wird ebenfalls durch eine 128-Bit Zahl ({\em CLSID}) global eindeutig identifiziert. In {\dcom} sind Objekte nicht von ihren Klassen zu unterscheiden, da ein Client mit einem Objekt nur "uber dessen IIDs interagiert. Es ist f"ur einen Client nicht m"oglich, eine spezifische Instanz eines {\dcom} Objektes zu referenzieren, da {\dcom} keine eindeutigen Objektreferenzen unterst"utzt. Ein {\dcom} Objekt ist kein Objekt im klassischen {\oo}en Sinn, das "uber einen bestimmten internen Zustand verf"ugt, sondern eine Sammlung von semantisch zusammengeh"origen Funktionen.

\subsubsection*{{\dcom} Server}
Ein {\dcom} Server liegt entweder in Form einer dynamisch bindbaren Bibliothek ({\em Dynamic Link Library}, DLL) oder einer ausf"uhrbaren Datei vor und enth"alt eine oder mehrere {\dcom} Klassen, die jeweils durch ihre CLSID bezeichnet sind. Server werden in der Systemregistrierung ({\em Registry}) der {\msw} Betriebssysteme mit ihrer CLSID und dem Pfad des Programmes eingetragen, das diesen Server implementiert. Bei der Anfrage eines Client sucht {\dcom} nach der CLSID des Servers in der Systemregistrierung und ruft das entsprechende Programm auf. Der Server ist dann f"ur die Erzeugung eines Objektes der gew"unschten Klasse verantwortlich. Es werden drei Arten von {\dcom} Servern unterschieden:

\begin{description}
\item[Integrierte Proze"s Server] werden im gleichen Proze"sraum wie ihre Clients ausgef"uhrt. Clients k"onnen ohne intermedi"are Systemkomponenten auf andere Komponenten im gleichen Proze"s zugreifen. Unter den Betriebssystemen {\msw} und {\mswnt} werden diese Komponenten als DLLs direkt in den Proze"s des Client integriert.
\item[Lokale Server] werden auf dem gleichen Rechner in einem von ihren Clients separaten Proze"sraum ausgef"uhrt. Die Kommunikation zwischen Komponenten in unterschiedlichen Prozessen auf dem gleichen Rechner und Betriebssystem erfolgt "uber den sogenannten {\em Lightweight Remote Procedure Call} (LRPC) Mechanismus. Lokale Proze"s Server werden durch ihre eigene (.EXE) Datei gestartet.
\item[Entfernte Server] werden in einem separaten Proze"s auf einer entfernten Maschine und evtl. einem anderen Betriebssystem ausgef"uhrt als ihr Client. Clients benutzen einen {\dce}\footnote{{\em Distributed Computing Environment} \cite{dce}} "ahnlichen RPC Mechanismus, um mit entfernten Servern zu kommunizieren. Entfernte Server liegen wie Lokale Server in einer eigenen ausf"uhrbaren Datei vor. 

 
\end{description}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6cm
\epsffile{Bilder/objektcom/dcomServer.eps}
\end{center}
\caption{Verschiedene {\dcom} Server}
\label{dcomServer}
\end{figure}

In Abbildung~\ref{dcomServer} (aus \cite{OH97}) sind die verschiedenen Kommunikationsm"oglichkeiten f"ur {\dcom} Objekte dargestellt. Die schwarzen Punkte, die jeweils mit den Serverobjekten verbunden sind, stellen dabei deren {\dcom} Schnittstellen dar. Der Client sieht bei jeder der o. g. Serverarten nur eine Schnittstellenreferenz, es ist f"ur ihn nicht ersichtlich, wo sich ein bestimmtes Objekt befindet. Proxy Objekte auf der Client Seite und Stubs auf der Server Seite sind mit den {\corba} Client IDL Stubs bzw. den Server IDL Skeletons vergleichbar: sie erlauben statische Aufrufe von --- evtl. entfernten --- {\dcom} Objekten.  

\subsubsection*{Dynamische Aufrufe von {\dcom} Objekten}
Neben statischen Aufrufen von Objekten "uber Proxy und Stub Objekte ist es m"oglich, Methodenaufrufe dynamisch zur Laufzeit zu erzeugen und auszuf"uhren. Diese Techniken bilden die Grundlage f"ur die {\ole}\footnote{{\em Object Linking and Embedding} \cite{Br96}} Automation, die es Clients mit Hilfe von Skriptsprachen erlaubt, dynamisch Methoden aufzurufen, die die Inhalte von Objekten manipulieren. {\ole} Automation erlaubt es einem Programm --- dem {\ole} {\em Automation Controller} --- ein anderes Programm --- den {\ole} {\em Automation Server} --- zu steuern \cite{La95}. Ein {\ole} {\em Automation Server} stellt in einer Laufzeitdatenbank ({\em Type Library}), die mit dem {\corba} Interface Repository vergleichbar ist, Beschreibungen seiner Schnittstellen, Methoden und Eigenschaften\footnote{Eigenschaften sind mit Attributen im klassischen Objektmodell vergleichbar.} zur Verf"ugung ({\VAB}~\ref{dcomDyn}). 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/objektcom/dcomDyn.eps}
\end{center}
\caption{{\ole} Automation Clients und ihre Server}
\label{dcomDyn}
\end{figure}


Aus der Beschreibung der Serverobjekte --- abgefa"st in der  {\dcom} {\em Object Definition Language} (ODL), einer Untermenge der {\dcom} IDL --- werden die entsprechenden Metadaten erzeugt und in einer Type Library abgelegt (1). Ein Client eines Automation Server wird als {\em Automation Controller} bezeichnet. Er kann die Namen von unterst"utzten Methoden und Eigenschaften eines Servers mit Hilfe der Type Library bestimmen (2) und nachfolgend Server Objekte erzeugen, deren Methoden aufrufen sowie deren Eigenschaften setzen und abrufen (3). 

\subsubsection*{WWW Integration}
\label{dcomWWW} 
Ein {\ax} ist ein {\dcom} Objekt \cite{OH97}. {\ax} Komponenten sind sowohl beim WWW Client als auch beim WWW Server einsetzbar, sofern sie f"ur die jeweils vorhandene Plattform "ubersetzt wurden. Dies hat den Vorteil des gegen"uber {\java} Applets/Servlets schnelleren Laufzeitverhaltens, birgt aber auch die Gefahr der mi"sbr"auchlichen Nutzung, da {\ax} Programme uneingeschr"ankten Systemzugang haben. Sie d"urfen u. a. externe Anwendungen starten und k"onnen diese per Skriptsprache fernsteuern. In  \cite{DP97} wird gezeigt, wie eine per WWW zu einem Client\-rech\-ner "ubertragene {\ax} Komponente automatisch "Uberweisungsauftr"age im Namen des Benutzers ausf"uhrt.

{\ax} Komponenten k"onnen "ahnlich wie {\java} Applets in HTML Seiten eingebunden und so "uber das Internet verteilt werden. Auf der Serverseite k"onnen {\ax} Komponenten neben ihrem Einsatz als herk"ommliche {\dcom} Server auch als Dienstleister f"ur einen {\em Active Server} genutzt werden \cite{Cl97}. Ein Active Server ist in der Lage, in HTML Seiten enthaltene Skripte auszuf"uhren. Diese erweiterten HTML Seiten werden als {\em Active Server Pages} bezeichnet \cite{Be97}. In den {\em Active Server Pages} kann neben {\vbs} sowohl {\jscript} als auch {\javas} als Skriptsprache benutzt werden. Diese Skripte k"onnen Instanzen von {\ax} Server Komponenten (auch als {\ole} Automation Server bezeichnet, s. o.) erzeugen und diese mit einer bestimmten Aufgabe wie z.B. einer Datenbankanfrage betrauen. "Uber die Active Server Pages lassen sich also HTML Seiten mit bereits bestehenden Anwendungen verbinden. Die Ausgabe einer Active Server Page ist reines HTML. Die sich durch Active Server Pages ergebenden M"oglichkeiten sind mit den F"ahigkeiten von CGI Anwendungen vergleichbar, mit dem Unterschied, da"s der Serverproze"s selbst die Auswertung von Parametern "ubernimmt und, falls eine betroffene {\ax} Server Komponente als DLL vorliegt, er die komplette Berechnung einer Anfrage "ubernehmen kann, ohne einen externen Proze"s starten zu m"ussen. 

Die "Ubertragung von {\ax} Komponenten zum Client via HTTP und deren Kommunikation via DCOM mit einem entfernten DCOM Server ist in Abbildung~\ref{dcomWeb} dargestellt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{Bilder/objektcom/dcomWWW.eps}
\end{center}
\caption{Integration von {\dcom} und WWW }
\label{dcomWeb}
\end{figure}


\section{Vergleich der Technologien}
\label{objektcomVergl}
Auf Basis der Anforderungen aus Abschnitt~\ref{objektcomAnf} werden im Folgenden die oben vorgestellten Technologien gegen"ubergestellt.

\begin{description}

\item[Behandlung der Heterogenit"at von Plattformen:]  {\corba} konforme ORBs werden von verschiedenen Herstellern f"ur unterschiedliche Plattformen und Betriebssysteme angeboten. "Uber das IIOP k"onnen ORBs verschiedener Hersteller miteinander kommunizieren. {\rmi} steht auf allen Plattformen zur Verf"ugung, f"ur die ein {\java} Interpreter und die {\rmi} Bibliotheken existieren. {\dcom} unterst"utzt derzeit nur die Betriebssysteme {\winf} und {\winnt}, eine Beta Version f"ur {\unix} ist von der {\sag} verf"ugbar. 

\item[Behandlung der Heterogenit"at von Programmiersprachen:] 
Mit Hilfe von Schnittstellenbeschreibungen in einer speziellen Schnittstellenbeschreibungssprache (IDL) trennen {\corba} und {\dcom} Schnittstellen von Objekten von deren Implementierung. Ein IDL Compiler erzeugt aus den Beschreibungen Stubs und Skeletons in Programmiersprachen, f"ur die "Ubersetzungsvorschriften ({\em language mappings}) bestehen. {\rmi} ist ausschlie"slich f"ur die Interaktion zwischen {\java} Softwarekomponenten entwickelt worden, daher werden Schnittstellen als {\java} {\em Interfaces} definiert.

\item[Integration mit bestehender WWW Infrastruktur:]  {\rmi} und {\corba} sind im WWW mit Hilfe von {\java} Applets verteilbar, die von allen namhaften {\brow}n unterst"utzt werden. {\java} Applets k"onnen nicht direkt mit einer HTML Seite interagieren, sondern erhalten in einem {\brow} Fenster einen rechteckigen Bereich zugeteilt, den sie dann selbst verwalten. Die Interaktion mit der umgebenden HTML Seite kann "uber {\javas} erfolgen ({\VAS}~\ref{code}). {\dcom} Objekte sind als {\ax} Bin"arcodeobjekte derzeit ausschlie"slich im {\ms} {\ie} und im {\net} {\nav} auf der 32-Bit {\msw} Plattform verwendbar. Die Verbindung zu HTML Seiten wird ebenfalls "uber Skriptsprachen hergestellt.

\item[Lokale Sicherheit des Client im WWW:] W"ahrend {\corba} und {\rmi} Anwendungen im WWW von dem Sicherheitskonzept der in der Programmiersprache {\java} verfa"sten Applets profitieren, unterliegen {\ax} Objekte keinerlei Sicherheitsbeschr"ankungen und k"onnen beliebige Festplattenzugriffe durchf"uhren, andere Anwendungen starten und beliebige Netzwerkverbindungen aufbauen. 

\item[Entwicklungsunterst"utzung:] Alle drei betrachteten Technologien erzeugen werkzeuggest"utzt Stubs und Skeletons. Die Entwicklungsunterst"utzung von {\corba} ORBs h"angt von der jeweiligen Herstellerimplementation ab. In der Regel stehen Generatoren f"ur Stubs und Skeletons und einige zus"atzliche Systemdienste zur Verf"ugung. {\java} bietet mit seinen Klassenbibliotheken eine stetig wachsende Anzahl von zus"atzlichen Diensten f"ur {\rmi} Anwendungen. Interessant zu bemerken ist, da"s der Transaktionsdienst von {\java} (JTS) auf dem {\em Object Transaction Service} der {\omg} basiert \cite{Cu97}. {\dcom} verf"ugt nicht wie {\corba} in der {\em Object Management Architecture} "uber eine begleitende Definition von Systemdiensten. 

\item[Dynamisches Finden und Aufrufen von Objekten:] 
{\corba} und {\dcom} unterst"utzen das dynamische Finden und Aufrufen von Objekten mit Hilfe von Laufzeitdatenbanken, die Metadaten "uber verf"ugbare Objekte enthalten. Ein Client kann so passende Objekte finden, sich "uber deren Methoden und die zum Aufruf notwendigen Parameter informieren und dynamisch eine Anfrage an das Objekt stellen. {\rmi} bietet hier lediglich die M"oglichkeit des dynamischen Ladens von Stubs.

\end{description}



Die drei betrachteten Technologien spielen ihre Vorz"uge jeweils in bestimmten Anwendungsf"allen aus. So bietet {\java} {\rmi} die nahezu nahtlos integrierte Verwendung von entfernten {\java} Objekten. Der Entwickler mu"s keine spezielle IDL Syntax lernen, er kann serialisierbare {\java} Objekte als Parameter von entfernten Methodenaufrufen verwenden, er nutzt die automatische Speicherbereinigung von nicht referenzierten entfernten Objekten, etc. Wenn es aber darum geht, Objekte anderer Programmiersprachen einzubinden, f"uhrt {\rmi} schnell zur Abh"angigkeit von der Programmiersprache {\java}, da f"ur ein entferntes Objekt in einer anderen Programmiersprache ein {\java} Objekt programmiert werden mu"s, das dessen Funktionalit"at kapselt. Der Entwickler macht sich also von einer Programmiersprache --- in diesem Falle von {\java} --- abh"angig, um ihren Kommunikationsmechanismus zu nutzen \cite{Cu97}.  

{\corba} bietet eine umfassende Integrationstechnologie f"ur die Erstellung von objektorientierten, verteilten Anwendungen in einem heterogenen Netzwerk. Die Vorteile dieses offenen Standards erkauft sich der Entwickler mit dem Aufwand des Erlernens einer speziellen Schnittstellenbeschreibungssprache. Desweiteren ist die "Ubertragung von Parametern in entfernten Methodenaufrufen auf Objektreferenzen und Standarddatentypen wie z.B. Integer, Strings, Arrays, etc. beschr"ankt. An einer Erweiterung der {\corba} Spezifikation zur "Ubergabe von Objekten als Parameter wird gearbeitet. 

{\com} hat mit den auf den {\msw} Plattformen weit verbreiteten {\ole}/OCX Kontrollelementen einen offenen Markt f"ur plattformabh"angige Softwarekomponententechnologie geschaffen. Diese Komponenten k"onnen unabh"angig von Hersteller und verwendeter Programmiersprache auf einem Rechner miteinander kooperieren. {\dcom} soll die Kooperation auf im Netzwerk verteilte Komponenten ausdehnen. Da jedoch Portierungen von {\dcom} auf andere Plattformen erst in Beta Versionen vorhanden sind, ist der Markt de facto auf die {\intel}/{\win} Plattform beschr"ankt. Zudem erfordert die Verteilung von {\ax} Komponenten im WWW auf heterogene Plattformen entweder eine jeweils plattformspezifische Version der Komponente oder einen {\brow}, der 32-Bit {\win} Code ausf"uhren kann. Die beschr"ankten Sicherheitsmechanismen von {\ax} Komponenten im Vergleich zu {\java} Applets bilden im WWW bei der Ausf"uhrung unbekannten Codes ein hohes Sicherheitsrisiko f"ur den Anwender. 



