\chapter {Realisierung von Informationssystemen mit verteilten Objekten}

\label{kom-verteilteObj}



In diesem Kapitel sollen drei verschiedene, kommerziell relevante 

Ans"atze zur Realisierung von

Informations\-sys\-temen mit verteilten Objekten vorgestellt werden. 

Dabei gehen

alle Ans"atze von verschiedenen Ausgangspunkten aus und verfolgen

unterschiedliche Strate\-gien. CORBA will eine m"oglichst umfassende und

allgemeine 

Vermittlung von Diensten in Netzen zur Verf"ugung stellen. Das DCE stellt eine

Reihe von Softwarekomponenten bereit, um die Erstellung verteilter

Anwendungsprogramme auf heterogenen Rechnernetzen zu erleichtern.

OLE ist ein Ansatz,

der bisher auf Betriebssystemebene implementiert ist und dokumentenzentriertes

Arbeiten erm"oglicht. Jedes System wird mit Tycoon verglichen.



\section {CORBA: Unabh"angige Objektverteilungen}



Die Common Object Request Broker Architecture (CORBA) ist die Antwort der

Object 

Management Group (OMG) auf die Frage nach der Zusammenarbeit einer st"andig

wachsenden Anzahl von 

Hardware- und Softwarekomponenten. Kurz zusammengefa"st soll CORBA

die Kommunikation zwischen Applikationen, bei denen es keine Rolle

spielt, wo sie stehen oder wer sie erstellt hat, erlauben. Dazu hat die OMG 

1991 CORBA

1.1 

als Standard definiert. In dieser Version wurden eine Interface Definition 

Laguage (IDL) und

Application Programming Interfaces (API) definiert, die eine Zusammenarbeit

von Objekten innerhalb einer speziellen Implementierung eines Object Request

Broker (ORB) erm"oglichen. Mit der Version 2.0 wurde die Zusammenarbeit

verschiedener ORB-Implementierungen hinzugenommen.



Mit dem ORB werden Client-Server-Beziehungen zwischen Objekten etabliert. Mit

Hilfe des ORB kann ein Klient transparent eine Methode eines anderen Objektes

aktivieren, die entweder auf dem gleichen Rechner oder irgendwo im Netzwerk

liegen kann. Der ORB f"angt die Nachricht ab und ist f"ur die Suche des

Objektes, das die geforderten Dienste erf"ullt, f"ur die "Ubertragung der

Parameter, den Aufruf der Methode und die R"uckgabe der Ergebnisse zust"andig.

Dabei braucht der Klient nichts "uber den Ort des Objektes, seine

Programmiersprache, sein Betriebssystem oder andere Systemaspekte, die nicht

Teil der Schnittstelle sind, zu wissen. Damit bewirkt der ORB die

Zusammenarbeit 

von Applikationen auf verschiedenen Rechnern in heterogenen, verteilten

Umgebungen und verbindet verschiedene Objektsysteme nahtlos.



In bisherigen Client-Server-Applikationen haben die Entwickler eigene Ans"atze

f"ur die Kommunikation zwischen den Komponenten benutzt. Dabei hingen die

Protokolldefinitionen von der benutzten Programmiersprache, dem Netzwerk und vielen

anderen Faktoren ab. Dieser Enwurfsproze"s wird mit dem ORB einfacher. Das

"Ubertragungsprotokoll zwischen den Schnittstellen der Applikationen wird mit 

nur einer Sprache, der IDL, beschrieben. Wenn die Entwickler den ORB benutzen,

sind sie flexibler. Sie k"onnen die f"ur die Anwendung am besten geeignete

Programmiersprache und das beste Betriebssystem ausw"ahlen. Au"serdem k"onnen

mit dem ORB bestehende Komponenten benutzt werden. Mit Wrapper-Funktionen kann

von der IDL zu bestehenden Schnittstellen "ubersetzt werden.

\cite{omg-kurz}



\subsection{Das Objektmodell von CORBA}



Drei wichtige Eigenschaften von CORBA-Objekten sind Kapselung, Vererbung

und Polymorphismus. Kapselung ist die

wichtigste Eigenschaft, weil sie die flexible Zusammenarbeit beliebiger

Softwarekomponenten unterst"utzt und Orts\-transparenz schafft. Au"serdem 

k"onnen bestehende, gekapselte Applikationen mittels Wrapper-Funktionen mit

einer 

IDL-Schnittstelle versehen werden und stehen f"ur beliebige Klienten zur

Verf"ugung. Im Gegensatz dazu unterst"utzen die beiden anderen Eigenschaften

die Zusammenarbeit von CORBA mit objektorientierten Sprachen und Werkzeugen.

Viele Analyse- und Entwurfswerkzeuge benutzen die Eigenschaften automatisch. 

Deshalb sind die Eigenschaften

in die IDL integriert. Sie sind f"ur brauchbare

Softwarekomponenten aber optional.





\subsection{IDL-Schnittstellen}



Die Schnittstellen, "uber die die CORBA-Objekte nach au"sen sichtbar werden,

sind in der IDL definiert. Die Schnittstellen enthalten die Operationen, die

die 

Objekte durchf"uhren k"onnen, die ben"otigten Eingabeparameter, die

Ausgabeparameter, die zur"uckgegeben werden, und au"serdem die Ausnahmen, die

bei der Behandlung auftreten k"onnen. Alle Klienten k"onnen nur "uber die

Schnittstelle auf die Objekte zugreifen, Zugriffe auf die Implementierung von

Objekten sind nicht m"oglich.



Die IDL ist "ahnlich wie die Programmiersprache C typisiert. Als zus"atzlicher

Basistyp existiert ein Typ {\em any}, mit dem alle Werte "ubergeben werden

k"onnen. Konstruierte Typen d"urfen nicht rekursiv benutzt werden. Daf"ur gibt

es Folgen-Typen, die bei der "Ubersetzung eine maximale L"ange bekommen, diese

aber nicht ausnutzen m"ussen \cite{corba-spec}.



In der CORBA-Architektur sind die Implementierungen von den Schnittstellen

getrennt. F"ur einen Klienten stellt die Schnittstelle ein Versprechen dar. 

Wenn

ein Objekt mit einer geeigneten Nachricht aufgerufen wird, kommt auch eine

Antwort zur"uck. F"ur den Programmierer ist die Schnittstelle eine

Verpflichtung. Er mu"s in einer geeigneten Programmiersprache alle Operationen

der Schnittstelle bereitstellen. Den Vertrag aufzustellen (die Schnittstelle

in IDL definieren) und ihn einzuhalten (in einer Programmiersprache wie C++

oder 

Smalltalk) sind zwei verschiedene Schritte, in denen eine

CORBA-Applikation erstellt wird.



\begin{figure}

\centerline{\epsfbox{bilder/corbareq.eps}}

\caption{Der Weg einer Anfrage vom Klienten zur Objektimplementierung}

\label{corbareq}

\end{figure}



Die Anfrage eines Klienten an einen Server nimmt den Weg, der aus der

Abbildung \ref{corbareq} zu ersehen ist. Auf der Klientenseite wird der Aufruf

durch 

den IDL-Stub an den ORB weitergereicht. Auf der Serverseite wird die Anfrage

vom 

IDL-Skeleton aufgenommen und an die Implementierung "ubergeben.



Um ein CORBA-Objekt zu erstellen, mu"s man die folgenden Schritte durchf"uhren:



\begin{enumerate}



\item Es mu"s eine genaue Spezifikation des Objektes erstellt werden.



\item Eine Schnittstelle wird mit der IDL definiert. Sie mu"s alle Operationen,

 die

Eingabeparameter, die R"uckgabewerte und die Ausnahmen enthalten.



\item Es ist eine geeignete Implementierungssprache f"ur das Objekt

auszuw"ahlen. 

Dabei

sollten zwei Aspekte ber"ucksichtigt werden: Verf"ugbarkeit und Eignung. Die

Schnittstelle mu"s dann auf entsprechende Konstrukte in der Programmiersprache

abgebildet werden. Diese Abbildungen sind f"ur die Programmiersprachen C, C++

und Small\-talk

von der OMG vorgegeben. Der IDL-"Ubersetzer erzeugt Funktionsaufrufe aus den

IDL-Operationen. Der Programmierer mu"s die Funktionsr"umpfe bereitstellen.



\item Die Verbindung von der Schnittstelle zum ORB liegt in der Hand des

ORB-Herstellers. Sie wird jedoch mit dem IDL-"Ubersetzer erzeugt, so da"s sich

der Programmierer nicht darum k"ummern mu"s. Es m"ussen lediglich ORB und

IDL-"Ubersetzer vom gleichen Hersteller kommen. Jedoch werden alle ORBs

verschiedener Hersteller "uber die gleiche Schnittstelle angesprochen, so da"s

der Programmcode sp"ater leicht portiert werden kann.



\end{enumerate}



Wenn das Serverobjekt und der Klient in der gleichen Programmiersprache

erstellt 

wurden und "uber den gleichen ORB verbunden werden (dieser Spezialfall mu"s

nicht immer erf"ullt werden), kann aus der Schnittstellendefinition auch der

Stub f"ur den Klienten erzeugt werden. Er enth"alt Funktionsdeklarationen. Die

Funktionsaufrufe m"ussen jetzt vom Programmierer erstellt werden. Sie passen

direkt auf die Deklarationen im Server. Jedoch k"onnen die Verbindungen auch

dynamisch erstellt werden.



\subsection{Der Object Request Broker}



Bisher sind gew"ohnliche Client-Server-Verbindungen mittels entfernter

Prozeduraufrufe vorgestellt worden. Das Ziel ist jedoch, mit

ORB-zu-ORB-Verbindungen jedes Objekt mit jedem zu verbinden. Dazu m"ussen zwei

Probleme gel"ost werden: die Lokalisierung von Objekten und die "Ubersetzung in

fremde ORB-Implementierungen.



Die Lokalisierung wird durch Objektreferenzen unterst"utzt. Sie spiegeln jedoch 

mehr als die reine Netzwerkadresse wider. Sie sollen g"ultig bleiben, wenn ein

Objekt im Netz migriert. Dabei wird die Abbildung von der Referenz auf die

Netzwerkadresse der Implementierung des ORB "uberlassen. Jede

ORB-Implementierung mu"s jedoch alle Ob\-jekt\-re\-fe\-ren\-zen entschl"usseln k"onnen.



Mit Hilfe der IDL wird das zweite Problem angegangen: Mit der IDL kann nicht

nur 

das Skeleton und der Stub f"ur die Kommunikation mit den Objekten erzeugt

werden, sondern der ORB speichert zus"atzlich die Schnittstellen aller Objekte

in einem Interface Repository (IR). Diese Datenbank wird f"ur die

Zusammenarbeit der ORBs

ben"otigt. Wenn die Typen und die Reihenfolge der Argumente einer Nachricht

bekannt sind, k"onnen die ORBs Daten untereinander austauschen. Au"serdem

k"onnen mit Hilfe dieser Datenbank Schnittstellen auf Fehler untersucht oder

alle Schnittstellen angezeigt werden.



Das Dynamic Invocation Interface (DII) sorgt f"ur eine dynamische Verwaltung

der 

Objekte und ist ein Teil des ORB. Damit k"onnen die Klienten auch neue Objekte

benutzen, die sp"ater als der Klient erstellt wurden. Das DII stellt sich nach

au"sen wie eine ORB-Schnittstelle dar, die auch in der IDL erstellt ist. Das

DII enth"alt Routinen, mit denen der ORB und der Klient zusammenarbeiten

k"onnen.

Sie haben dabei die M"oglichkeit, Objektschnittstellen aus dem IR zu benutzen, 

um alle Objekte anzusprechen. 



Die Kommunikation zwischen ORBs bleibt f"ur den Benutzer transparent. Falls der

lokale ORB das aufgerufene Objekt nicht findet, gibt er den Aufruf an einen

entfernten ORB weiter, um ihn dort an das gesuchte Objekt zuzustellen. Um

diese Transparenz zu gew"ahrleisten, m"ussen alle ORBs zwei Datenbanken

verwalten: das IR mit den Schnittstellen und ein Implementation Repository, das

Informationen "uber die verf"ugbaren Objekt\-implementierungen enth"alt.

Au"serdem 

m"ussen die Kommunikationsprotokolle der ORBs untereinander synchronisiert

werden. Diese Probleme werden aber vor dem Benutzer und dem

Applikationsprogrammierer verborgen. Mit der Version 2.0 ist die Kommunikation

zwischen ORBs gesichert.



Um gekaufte Software integrieren zu k"onnen, wird sie in Zukunft mit einer

IDL-Schnittstelle im Quellcode ausgeliefert, mit der auch Klienten eigene

Schnittstellen erzeugen k"onnen. Bei der "Ubersetzung des Quellcodes in der IDL

werden sowohl ein Stub f"ur den Klienten als auch ein Skeleton f"ur der Server

erzeugt. Nach der "Ubersetzung wird das Skeleton einfach gel"oscht, weil der

gekaufte Server ja ein passendes Skeleton mitbringt.



\begin{figure}

\centerline{\epsfbox{bilder/orb.eps}}

\caption{Der ORB mit Klient und Serverobjekt}

\label{orbueber}

\end{figure}



Insgesamt hat der ORB die Struktur und die Schnittstellen, die in der Abbildung

\ref{orbueber} dargestellt sind. Klient und Implementierung k"onnen auf den ORB

"uber eine Schnittstelle zugreifen. Der Objektadapter vermittelt zwischen dem

ORB und der Objektimplemetierung.



\subsection{Die Object Management Architecture}



\label{OMA}



\begin{figure}

\centerline{\epsfbox{bilder/oma.eps}}

\caption{Die Object Management Architecture der OMG}

\label{oma}

\end{figure}



Die Object Management Architecture (OMA) aus Abbildung \ref{oma} bildet das

Ger"ust, das als Grundlage alle Applikationen im System zusammenh"alt. Die

Transport- und "Uber\-tra\-gungs\-kom\-po\-nente ORB wird durch verschiedene

Standarddienste unterst"utzt, die von allen Applikationen genutzt werden

k"onnen. Die Common Object services, die unterhalb des ORB liegen,

standardisieren 

Grunddienste, die von fast allen Objekten gebraucht werden. Mit den

Common Facilities werden den Applikationen Dienste der Mittelschicht angeboten.



Diese Dienste sind alle von der OMG spezifiziert, m"ussen jedoch nicht von

jedem 

Hersteller mit dem ORB zusammen angeboten werden. 



Bisher sind elf verschiedene Common Object services spezifiziert. Sie bieten

alle eine 

systemnahe Unterst"utzung von objektorientierten Applikationen und ihren

Komponenten. Die elf Dienste sind einzeln kurz beschrieben:



\begin{itemize}



\item Lifecycle Service: Erzeugen, L"oschen Verschieben und Kopieren von

Objekten.



\item Relationship Service: Erzeugung und Verfolgung von dynamischen

Verbindungen zwischen Komponenten, die nichts voneinander wissen.



\item  Naming Service: Abbildung von Objektnamen auf Objektreferenzen.



\item  Persistence Service: Speicherung von Objekten auf verschiedenen

Medien.



\item  Externalisation Service: Datenaustausch von Komponenten "uber

Bytestr"ome.



\item  Event Service: Komponenten werden "uber bestimmte Ereignisse

informiert.



\item  Query Service: Anfragen von Objekten an Datenbanken.



\item  Properties Service: Komponenten werden mit benannten Werten verbunden.



\item  Transaction Service: Zwei-Phasen-Commit-Protokoll f"ur Transaktionen.



\item  Concurrency Service:   Zusammen mit dem Object Transaction Service wird

der 

Zugriff auf Business Accounting Systems unterst"utzt.



\item  Licensing Service: Alle einzelnen Aufrufe der Komponenten werden gez"ahlt,

 um eine gerechte Abrechnung zu erm"oglichen.



\end{itemize}



F"unf weitere Dienste sind noch nicht endg"ultig spezifiert:

Trader Service, Security Service, Secure Time Service, Object Collection

Service und Object Startup Service \cite{DisObjSurvG}.



Die Common Facilities liegen in einer Schichtenarchitektur des CORBA-Systems

zwischen den Common Object services und der Applikationsschicht. Mit Hilfe

dieser 

Komponenten k"onnen die Applikationen weiter vom Systemkern entfernt bleiben

und 

schneller entwickelt werden. 

Die Bestandteile der Common Facilities werden in zwei Abschnitte unterteilt.

Die 

horizontalen Komponenten sollen in allen Branchen benutzt werden. Es gibt vier

Kategorien: user interface, information management, systems management und task

management. Die vertikalen Komponenten sollen dagegen branchenspezifisch

eingesetzt werden. Hierbei sollen zum Beispiel Komponenten f"ur Banken oder 

das Gesundheitswesen

erstellt werden.



Die Spezifikationen der Common Facilities sind noch

nicht abgeschlossen. \cite{sig96}



\subsection{Vergleich von CORBA und Tycoon}

\label{tycoon-corba-vergleich}



Bei der Konzeption und Realisierung des Tycoon-Systems und des CORBA-Systems

wurden unterschiedliche Ans"atze gew"ahlt. Jedoch soll hier verglichen werden, welche Beitr"age

beide Systeme zu einem verteilten System leisten. F"ur einen Vergleich beider

Systeme sollen die folgenden Kriterien benutzt werden.



In \cite{LKK93} werden f"unf Anforderungen an ein verteiltes System

gestellt:



\begin{description}



\item[Kommunikationsmechanismen:] Die Kommunikationsdienste sollen leicht

zu handhaben sein und von den Eigenschaften des zugrundeliegenden

Transportprotokolls m"oglichst weit abstrahieren.



\item[Behandlung der Heterogenit"at:] Die beteiligten Rechner des verteilten

Systems stammen in der Regel von unterschiedlichen Herstellern und benutzen

verschiedene Betriebssysteme und verschiedenartige Datenformate.



\item[Zus"atzliche Systemdienste:] Neben Kommunikationsdiensten sind

Systemdienste zur Unterst"utzung der verteilten Anwendung w"unschenswert.



\item[Einbettung von Diensten in Programmiersprachen:] Verteilte Anwendungen

werden meist in h"oheren Programmiersprachen entwickelt. Daher ist es

w"unschenswert, die Kommunikationsdienste und die zus"atzlichen Systemdienste

direkt in die jeweilige Sprache einzubetten.



\item[Entwicklungsunterst"utzung:] Neben den Diensten sollen auch Methoden und

Werkzeuge zur Entwicklung verteilter Anwendungen vorhanden sein. Beispiele

hierf"ur sind spezielle Entwurfssprachen und -editoren oder Testwerkzeuge.

\end{description}



Anhand dieser Kriterien sollen CORBA und Tycoon verglichen werden.



W"ahrend CORBA von Anfang als System f"ur verteilte Objekte entworfen und

entwickelt wurde, wurde die Verteilung bei Tycoon erst nach der Entwicklung

eines lokalen persistenten Objektsystems realisiert. Bei der Integration wurde

aber die Orthogonalit"at beibehalten, so da"s alle Objekte unabh"angig von ihrem

Typ mobil wurden. Entfernte Dienste k"onnen mit dem Remote Procedure Call genutzt

werden, und Objekte k"onnen an andere Systeme verschickt werden. Diesem

komfortablen Kommunikationsmechanismus steht bei CORBA der Object Request Broker

gegen"uber, der ebenfalls eine f"ur den Benutzer transparente Ausf"uhrung

entfernter Objektmethoden zul"a"st. Der Dienst ist in Tycoon im System

eingebaut, wobei mit CORBA eine weitere Softwarekomponente benutzt wird, die

unter anderem zus"atzliche Wartung ben"otigt.



Beide Systeme unterst"utzen heterogene Umgebungen. CORBA wird von mehreren

Herstellern angeboten, die unterschiedliche Plattformen unterst"utzen. "Uber die

IDL wird von Systeminterna wie dem Betriebssystem abstrahiert. Tycoon

ist platt\-form\-un\-ab\-h"ang\-ig und damit in heterogenen Umgebungen einsetzbar.



CORBA unterst"utzt eine Vielzahl zus"atzlicher Systemdienste als Common Object

services. Diese Dienste gibt es bei Tycoon noch nicht. Jedoch wird der Benutzer

durch die Adressierungstransparenz entlastet.



Tycoon besitzt mit {\sc Tl} eine eingebaute, m"achtige Programmiersprache, mit

der auch die Kommunikationsdienste benutzt werden k"onnen. CORBA hat

keine eigene Programmiersprache, jedoch k"onnen mit der IDL Programme

verschiedener Sprachen die Kommunikationsdienste nutzen.



Mit Blick auf die Entwicklungsunterst"utzung hat CORBA im Vergleich mit Tycoon 

den Vorteil der Objektorientierung und aller Erweiterungen, die aus diesem 

Ansatz entstehen. 

In der Programmiersprache {\sc Tl} kann lediglich ein objektorientierter

Programmierstil benutzt werden, in dem Funktionen in Tupel gekapselt werden und

von der M"oglichkeit der Subtypisierung Gebrauch gemacht wird. Jedoch kennt

{\sc Tl} keine Vererbung. Au"serdem m"ussen die Funktionsnamen in {\sc Tl} 

aus Prinzip eindeutig 

vergeben werden, w"ahrend die Objekte in CORBA ihre 

Methoden "uberladen k"onnen. Bei CORBA wird der Programmierer durch die

Generierung der Schnittstellen entlastet \cite{ElHe96}. 



Etwa gleichauf liegen beide Systeme bei der Integration bestehender

Systeme, um sie verteilt einsetzen zu k"onnen. Die in Tycoon eingebundenen

Applikationen k"onnen  netzweit benutzt werden, nachdem sie exportiert wurden.

Tycoon-Anwendungen, die in {\sc Tl} entwickelt sind, brauchen keine besondere

Schnittstellendefinition mittels einer von der Programmiersprache unabh"angigen

IDL. Hier k"onnen entfernte Dienste direkt benutzt

werden. 



Au"serdem bietet

Tycoon mit dem Prinzip der mobilen Threads, das auf den gleichen

Kommunikationsmachanismen wie der RPC basiert, 

eine Basis f"ur mobile Agenten

und Workflow-Umgebungen, die CORBA noch nicht hat. Innerhalb der OMG

finden aber Diskussionen statt, wie Agenten in die Architektur aufgenommen werden

k"onnen.



Tabelle \ref{corba-tycoon} zeigt einen "Uberblick "uber den direkten Vergleich anhand der oben

genannten Kriterien.



\begin{table}[bt]

\begin{center}

\begin{tabular}{|l|c|c|}

\hline

Kriterium & Tycoon & CORBA\\

\hline

\hline

Kommunikations- & & \\

mechanismen & \rb{eingebaut, abstrakt} & \rb{besondere Middleware n"otig}\\

\hline

Behandlung von &  & \\

He\-te\-ro\-ge\-ni\-t"at & \rb{plattformunabh"angig} & \rb{verschiedene Hersteller} \\

\hline

zus"atzliche  &  & \\

Systemdienste & \rb{Addressierungstransparenz} & \rb{zahlreiche Dienste}\\

\hline

Einbettung in Pro- & & IDL f"ur

verschiedene\\

grammiersprachen & \rb{direkt in {\sc Tl}} & Programmiersprachen\\

\hline

Entwicklungs- &  & \\

unter\-st"utzung & \rb{wie {\sc Tl}-Programmierung} & \rb{Generierung der

Schnittstellen} \\ 

\hline

\end{tabular}

\end{center}



\caption{Vergleich von CORBA und Tycoon}

\label{corba-tycoon}

\end{table}





\section{DCE: Umgebung f"ur verteilte Systeme}



Das Distributed Computing Environment (DCE) der Open Software Foundation (OSF)

stellt eine Umgebung f"ur verteilte Systeme zur Verf"ugung. Es unterst"utzt

den Programmierer verteilter Systeme mit Diensten f"ur

die Kommunikation zwischen Anwendungen. F"ur den Benutzer ist die Verteilung

des 

Systems transparent.



Eine DCE-Umgebung wird grunds"atzlich in sogenannte Cells unterteilt. Jede Cell

besteht aus einer Menge von Rechnerknoten und stellt eine organisatorische

Einheit dar.



\begin{figure}[t]

\centerline{\epsfbox{bilder/dce-arch.eps}}

\caption{Die Gesamtarchitektur des OSF-DCE}

\label{DCE-Arch}

\end{figure}



Die Abbildung \ref{DCE-Arch} gibt einen "Uberblick "uber die Dienste, die im

DCE 

zur Verf"ugung stehen. Die Basisdienste werden direkt von den Anwendungen

angesprochen. Ihre Schnittstellen sind f"ur den Programmierer wichtig. Die

weitergehenden Dienste sind f"ur die Anwendungsentwicklung nicht interessant,

weil sie nur indirekt genutzt werden.



Alle Dienste beruhen auf Betriebssystem- und Transportdiensten. Der unterste

Dienst in der DCE-Umgebung ist der Thread-Service. Er realisiert eine portable

Implementierung von leichtgewichtigen Prozessen (Threads). Sie k"onnen sich

einen Adressraum teilen und gemeinsam auf globale Daten zugreifen. Damit

k"onnen 

nebenl"aufige, quasi-parallele Aktivit"aten innerhalb eines Adre"sraums

flexibel 

programmiert werden. Ein Klient, der entfernte Funktionen aufruft, wird nicht

blockiert, bis das Ergebnis eintrifft, ein Server kann nebenl"aufig auf

Anfragen 

warten.



Der Remote Procedure Call (RPC) ist der Basiskommunikationsmechanismus im DCE.

Er realisiert synchrone Fernaufrufe von Prozeduren im Rahmen des Client-Server

Modells. Dabei k"onnen sich Klient und Server auch auf dem gleichen

Rechnerknoten befinden. Der Aufruf der entfernten Prozedur geschieht f"ur den

Programmierer zum gro"sen Teil transparent, d. h. unterschiedliche Formate

werden automatisch konvertiert. Au"serdem k"onnen beliebige Parameterstrukturen

"ubergeben werden. Mittels Attributen kann der Programmierer festlegen, ob der

Aufruf einmal, mehrmals oder ohne Fehlerr"uckmeldung ausgef"uhrt werden soll. 

Dabei k"onnen mit dem RPC ein oder mehrere Server angesprochen werden. Es ist

auch m"oglich, im Fehlerfall mehrere Versuche durchzuf"uhren.

Es

k"onnen ebenfalls alle passenden Server angesprochen werden. Dabei wird der

erste 

R"uckgabewert akzeptiert. Die Schnittstellen f"ur den RPC werden mit einer

Interface Definition Language (IDL), die an C angelehnt ist, spezifiziert.



Der Directory Service hat die zentrale Aufgabe, logische Namen auf

Netzwerkadressen abzubilden. Mit diesem zentralen Directory Service sind alle

Namen schnell zug"anglich und k"onnen leicht konsistent gehalten werden. Der

Directory Service wird in zwei Komponenten unterteilt: Cell Directory Service (CDS) und

Global 

Directory Service (GDS). Dabei ist der CDS f"ur die

Verwaltung der Namen innerhalb einer Cell verantwortlich. Der GDS stellt das

Bindeglied zwischen verschiedenen CDS dar.



Mit dem Security Service wird der Zugriff unberechtigter Benutzer oder

Programme 

auf Daten, Dienste und Nachrichten innerhalb einer DCE-Umgebung verhindert.

Dieser Dienst wird prim"ar mit dem RPC eingesetzt. Grunds"atzlich ist alle

"ubertragene Information verschl"usselt. Jede Instanz kann Zugriffsrechte an

andere Instanzen vergeben. Au"serdem m"ussen sich die Benutzer bei

der Anmeldung mit einem Pa"swort authentifizieren. Die Authentifikation kann in

verschiedenen Granularit"aten durchgef"uhrt werden. Der Benutzer mu"s sich 

entweder zu Beginn einer

Sitzung, bei jedem Aufruf eines Dienstes oder bei jedem "Ubertragungspaket

authentifizieren. In weiteren Stufen wird der Schutz vor Modifikation von

Nachrichten 

garantiert oder es findet eine vollst"andige Verschl"usselung statt.



Der Distributed Time Service (DTS) dient zur Synchronisation der Systemuhren

aller Rechner eines verteilten Systems. Dazu mu"s jede Cell mindestens einen

Time 

Server enthalten. Die anderen Rechner der Cell befragen den Server in

bestimmten 

Zeitabst"anden nach seiner Systemzeit. Au"serdem bietet der DTS auch eine

Programmierschnittstelle an. Damit kann die Systemzeit abgefragt werden und

verschiedene Uhrzeiten k"onnen verglichen werden.



Das Distributed File System (DFS) verwaltet Dateien systemweit. Damit k"onnen

Anwender entfernte Dateien so ansprechen, als ob sie auf dem eigenen Rechner

liegen w"urden. Das DFS hat folgende Eigenschaften:



\begin{description}

\item [Lokationstransparenz:] Der Ort, an dem eine Datei abgelegt ist, ist f"ur

den Anwender vollkommen transparent.



\item [Replikation:] Dateien k"onnen auf mehreren Rechnern in Kopien zum Lesen

gehalten werden, um ihre Verf"ugbarkeit zu erh"ohen.



\item [Caching:] Mit einem lokalen Cache wird der Zugriff auf Dateien so effizient

wie m"oglich gestaltet.



\item [Recovery:] Durch Protokollierung der Zugriffe auf die Dateien wird eine

Wiederherstellung nach einem Rechnerausfall erm"oglicht.



\end{description}



Mit dem Diskless Support Service (DSS) k"onnen Rechner ohne Hintergrundspeicher

in das DCE integriert werden. Dazu mu"s auf jedem plattenlosen Rechner ein

Diskless Client zur Verf"ugung stehen, der mit entsprechenden Servern mit

externer Dateiverwaltung kommunziert und so die Funktionalit"at des

Hintergrundspeichers ersetzt. Auf Serverseite m"ussen daf"ur Boot Server,

Swap Server und Configuration Server zur Verf"ugung stehen.



Die PC Integration erm"oglicht es, Personal Computer mit den Betriebssystemen

MS/DOS, OS/2 und Unix in der DCE-Umgebung einzusetzen. Jedoch k"onnen diese

Rechner wegen ihrer begrenzten Betriebsmittel nur als Clients eingesetzt

werden. 



F"ur den Anwendungsentwickler ist prim"ar der RPC als Kommunikationsmechanismus

von Bedeutung. Er stellt sich als eine geschlossene Bibliothek von C-Funktionen

dar.

\cite{Schi93}



\subsection{Vergleich vom DCE und CORBA}



In der Diplomarbeit von Martin Schoel \cite{scho96} werden das DCE und CORBA

verglichen. Dort kommt er zu folgenden Ergebnissen: Der Hauptunterschied

zwischen CORBA und DCE ist der objektoriente Ansatz von CORBA gegen"uber dem

herk"ommlichen modularen DCE-Ansatz. CORBA bietet so eine bessere Unterst"utzung

bestehender Systeme als das DCE. Jedoch hat das DCE einen Zeitvorsprung gegen"uber

CORBA, so da"s robustere Implementierungen verf"ugbar sind. Auch bieten einige

Teilsysteme wie der Thread Service oder Security Service im DCE eine bessere

Basis f"ur verteilte Systeme als sie CORBA momentan bieten kann. F"ur das DCE

spricht auch, da"s 

Implementierungen, die f"ur das DCE entwickelt wurden, leichter auf neue

Plattformen portiert werden k"onnen, wenn dort das DCE schon verf"ugbar ist. 

Wegen einer

ungenauen Spezifikation des Basic Object Adapter (BOA) bei CORBA ist die Portierung auf

einen neuen ORB nur eingeschr"ankt m"oglich. Nach \cite{Schi93} bietet CORBA

insgesamt ein

h"oheres Abstraktionsniveau zur Interaktion verteilter Objekte als das DCE.



\subsection{Vergleich vom DCE und Tycoon}



F"ur diesen Vergleich werden die gleichen Kriterien wie beim Vergleich von 

CORBA und Tycoon im Abschnitt \ref{tycoon-corba-vergleich} benutzt.



Die Kommunikationsmechanismen werden im DCE durch die Integration der

Anwendungen in die verteilte Umgebung eingef"ugt. Damit sind sie f"ur den

Anwendungsentwickler leicht nutzbar.



Heterogene Systeme werden im DCE unterst"utzt, indem die Umgebung f"ur

zahlreiche Betriebssysteme angeboten wird. Au"serdem k"onnen PCs "uber eine eigene

Komponente integriert werden.



Das DCE bietet zum Beispiel mit dem Time Service und dem Diskless Support

Service mehr zus"atzliche Systemdienste als das Tycoon-System.



Die verteilte Umgebung des DCE stellt sich f"ur den Programmierer als Sammlung von

Funktionen der Programmiersprache C dar, die von ihm bei Bedarf aufgerufen

werden k"onnen. 



Der Entwickler wird bei seiner Arbeit im DCE durch einige Werkzeuge wie ein Editor zur

Definition und Bearbeitung von Zugriffskontrollisten oder ein Kontrollprogramm

zur Verwaltung der Cell Directory Services unterst"utzt.



Die Vergleichsergebnisse werden in Tabelle \ref{dce-tycoon} noch einmal

zusammengefa"st.



\begin{table}[bt]

\begin{center}

\begin{tabular}{|l|c|c|}

\hline

Kriterium & Tycoon & DCE\\

\hline

\hline

Kommunikations- &  & \\

mechanismen & \rb{eingebaut, abstrakt} & \rb{Umgebung f"ur Verteilung} \\

\hline

Behandlung von &  & \\

He\-te\-ro\-ge\-ni\-t"at & \rb{plattformunabh"angig} & \rb{zahlreiche

Betriebssysteme} \\

\hline

zus"atzliche  &  &\\

Systemdienste &\rb{Addressierungstransparenz} &  \rb{viele Dienste}\\

\hline

Einbettung in Pro- &  & \\

grammiersprachen & \rb{direkt in {\sc Tl}} & \rb{Schnittstellen in C} \\

\hline

Entwicklungs- &  & Editoren und\\

unter\-st"utzung &\rb{wie {\sc Tl}-Programmierung} & Verwaltungsprogramme\\

\hline

\end{tabular}

\end{center}



\caption{Vergleich vom DCE und Tycoon}

\label{dce-tycoon}

\end{table}



\section {OLE: Dokumentenzentriertes Arbeiten}



Object Linking and Embedding (OLE) erm"oglicht es Anwendungen, 

Datenbl"ocke anderer Programme in eigene Dokumente

einzubinden, ohne sich um deren Format zu k"ummern. Dazu werden immer eine

Client- und eine Server-Anwendungen ben"otigt: die Client-Anwendung empf"angt

die Daten, die die

Server-Anwendung liefert. Die Verwaltung der Daten geschieht nach der

"Ubergabe arbeitsteilig. Der Client behandelt den Datenblock als gesichtsloses

Objekt, das er an einer bestimmten Stelle in das Dokument einf"ugt. Die Bearbeitung

und eventuell auch die Darstellung der Daten "ubernimmt weiterhin der Server.

Ein Dokument einer Client-Anwendung, das OLE-Objekte enth"alt, wird Compound

Document genannt.



Wie aus dem Namen OLE hervorgeht, kann ein Dokument auf zwei verschiedene Arten

zusammengesetzt werden. Beim Verkn"upfen (Linking) wird das Objekt von der

Server-Anwendung in eine Datei abgelegt und diese Datei als verkn"upftes Objekt

"uber die Zwischenablage

des Systems in das Dokument der Client-Anwendung eingef"ugt. Die

Client-Anwendung speichert dann alle Angaben, um das Objekt sp"ater

wiederzufinden. So kann ein Objekt in verschiedene Dokumente eingef"ugt werden,

und wenn es ge"andert wird, erscheint es auch im zusammengesetzten Dokument

jederzeit im aktuellen Zustand. Wenn ein Objekt in ein Dokument eingebettet

wird, wird die Server-Anwendung aus der Client-Anwendung heraus gestartet, das

Objekt erstellt und beim Beenden der Server-Anwendung werden die Daten im

Format 

der Server-Anwendung im Dokument der Client-Anwendung gespeichert. \cite{Lau93}



Diese Grundlage, eine verbesserte Importm"oglichkeit f"ur Dateien verschiedener

Formate, war aber nur der Anfang der OLE-Entwicklung. Der Hersteller

Microsoft hat, auf diesem Konzept aufbauend, eine Umgebung f"ur verteilte

Objekte geschaffen, die als Basis f"ur die kommenden

Betriebssysteme genutzt werden soll. Innerhalb von Windows 95 ist OLE 

von gro"ser Bedeutung. Ziel ist es, flexible Komponenten im System

zusammenarbeiten zu lassen. Zum Beispiel wird die Textverarbeitung, die

dem Benutzer

unz"ahlige M"oglichkeiten bietet, in einzelne Komponenten wie

Editor, 

Rechtschreibpr"ufung, Trennhilfe, Formeleditor, etc. zerlegt. Diese Komponenten

werden im OLE-System als Objekte bezeichnet.



OLE basiert wie CORBA auf einem Object Request Broker, der hier Component

Objekt 

Model (COM) genannt wird. Jedoch unterst"utzt COM bis jetzt nur einen einzelnen

Rechner, die Objektverteilung innerhalb eines Netzwerkes ist noch nicht

m"oglich, aber f"ur zuk"unftige Versionen angek"undigt. 



\begin{figure}[bt]

\centerline{\epsfbox{bilder/oleobje.eps}}

\caption{Ein OLE-Objekt mit Methoden und Interfaces}

\label{oleobjekt}

\end{figure}



Nach \cite{MeyOber94} ist {\em Interface} der wichtigste Begriff des Component

Object Model. Interfaces sind die Bestandteile eines Objektes, "uber die es von

au"sen angesprochen, verwendet und eingebunden wird. Ein Interface ist die

Zusammenfassung einer Reihe von "ahnlichen Methoden eines Objektes zu einer

Einheit (siehe Abbildung \ref{oleobjekt}).



Innerhalb des COM wird ein

Verhandlungsprotokoll verwaltet, mit dem Klienten zur Laufzeit Referenzen auf

Schnittstellen erhalten k"onnen. F"ur die Beschreibung der Schnittstellen 

exisitiert auch bei OLE

eine spezielle Sprache. Au"serdem k"onnen die Objekte mit einer Object

Description Language (ODL) in eine Bibliothek eingetragen werden, die dem

Interface Repository von CORBA entspricht. Die Methoden der Objekte k"onnen,

wie 

bei CORBA, sowohl statisch wie auch dynamisch angesprochen werden.



Eine OLE-Komponente wird von einer Klasse definiert. In ihr sind eine oder

mehrere 

Schnittstellen implementiert. Au"serdem erh"alt die Klasse eine Class Factory,

mit der eine Instanz 

dieser Klasse erzeugt wird. Jedoch ist eine OLE-Komponente keine alleinstehende

Einheit, sie ist lediglich eine Sammlung von Schnittstellen. F"ur jede

geforderte Funktionalit"at mu"s eine Schnittstelle bereitstehen.



F"unf wesentliche Technologien werden in OLE benutzt, um die gesamte Funktionaliti"at

zu 

bilden. OLE mu"s Komponenten organisieren, um sie auf dem Bildschirm

darstellen zu k"onnen. Dazu werden Regeln

definiert, nach denen sich beteiligte Komponenten am Bildschirmaufbau

beteiligen.

Andere Regeln bestimmen, wie sie Daten innerhalb einer Datei abspeichern. OLE 

bietet die

Schnittstellen, mit denen Komponenten Daten mit anderen Komponenten

austauschen k"onnen. Au"serdem k"onnen Komponenten ihre Aktionen  "uber

automatische Befehlsketten (Scripte) steuern. Die daf"ur n"otigen Technologien

sind in der Abbildung \ref{ole} dargestellt und werden im folgenden einzeln

beschrieben.



\begin{figure}[bt]

\centerline{\epsfbox{bilder/ole.eps}}

\caption{Die wesentlichen Technologien von OLE}

\label{ole}

\end{figure}



Das {\em Component Object Model} spezifiziert die Schnittstellen zwischen den

Kompo\-nen\-ten\-ob\-jek\-ten innerhalb einer Applikation oder zwischen verschiedenen

Applikationen. Wie bei CORBA wird dabei die Implementierung von der

Schnittstelle getrennt. Mittels Appli\-ca\-tion Programming Interfaces (APIs) wird

es

den Objekten erm"oglicht, Objektschnittstellen dynamisch zu finden und sie

anzusprechen. Dazu m"ussen die Daten der Schnittstelle mit einer IDL zur

Verf"ugung gestellt werden. Jedoch kann das COM nur Objekte auf einem Rechner

suchen. Mehrfachvererbung ist im COM nicht m"oglich, statt dessen k"onnen

mehr\-ere Schnittstellen bereitgestellt werden. Diese Schnittstellen k"onnen in

anderen Komponenten aggregiert werden. Damit kapseln diese Komponenten die

Dienste der aggregierten Komponenten. Um ein Objekt nutzen zu k"onnen, mu"s

der 

Client einen einheitlichen Klassenidentifikator  absenden. Der Service

Control Manager (SCM) des COM sucht in einer Registrierdatenbank

nach dem Server und benachrichtigt ihn, damit er eine Instanz seiner Komponente 

zur Verf"ugung stellt.



Mit den Automatisierungs- und Scripting-Diensten ({\em Automation}) k"onnen

Serverkomponenten von

Automatisierungsklienten kontrolliert werden. Diese Klienten werden

typischerweise mit einer Scripting-Sprache programmiert. Diese Technik basiert

auf der M"oglichkeit, Schnittstellen dynamisch anzusprechen. Mit dieser Technik

k"onnen  m"achtige Applikationen weiter spezialisiert werden. Zum Beispiel kann

man eine Tabellenkalkulation zu einer Immo\-bi\-lien\-verwaltung machen.



F"ur den Datenaustausch ({\em Uniform Data Transfer}) zwischen verschiedenen

Komponenten exisitieren

verschiedene M"oglichkeiten, um m"oglichst viele Situationen und verschiedene

Medien 

abzudecken. Daten k"onnen "uber eine Zwischenablage, durch Ziehen und

Verschieben, 

"uber Verbindungen oder zusammengesetzte Dokumente ausgetauscht werden. Der

Datenaustausch kann innerhalb eines Dokuments, mit einem anderen Dokument oder

mit einer anderen Applikation stattfinden. OLE stellt verschiedene

M"oglichkeiten f"ur den Datenaustausch "uber eine Schnittstelle zur

Verf"ugung.



Das OLE Structured Storage System bietet ein Dateisystem innerhalb einer Datei.

Die aktuelle Implementierung dieser Architektur wird {\em Compound Files} genannt.

Diese Compound Files teilen eine physikalische Datei in mehrere Verzeichnisse 

und

Rohdaten auf. Mit dieser Struktur k"onnen die Inhalte eines Dokumentes

organisiert werden. Die beteiligten Komponenten k"onnen ihren Teil in den

Compound Files selbst kontrollieren. Klienten k"onnen "uber mehrere 

Schnittstellen

mit persistenten Objekten kommunizieren. Diese bilden den "Ubergang zu

regul"aren Dateien. OLE bietet einen Dienst f"ur persistente Namen, der

Monikers 

genannt wird. Ein Moniker ist ein Name, der an persistente Daten

gebunden werden kann. Sie k"onnen die assoziierten Daten "uber verschiedene

Algorithmen suchen, die bei der Klassenerstellung angegeben werden. So k"onnen

die Moniker als Zeiger f"ur entfernte Dateien dienen oder SQL-Anfragen

beinhalten, die die assoziierten Daten aus einer Datenbank ermitteln. Mit Hilfe

diese Indirektion k"onnen eingebundene Daten ihren Platz im System transparent

f"ur die umgebende Datei "andern.



Der Compound Document Service  aus dem {\em Compound Document Management} von

OLE bietet Dienste f"ur das

dokumentenzentrierte Arbeiten. Dazu werden Schnittstellen zwischen den

Containeranwendungen (in "alteren Versionen wurden sie Clients genannt) 

und den Serverkomponenten, die sie steuern, definiert. 

Mit diesen

Schnittstellen wird ein Protokoll geliefert, das beim Zugriff auf Daten einer

Anwendung den Server aktiviert und die

Daten am Platz "andern l"a"st. Jede Serverkomponente kontrolliert die

Darstellung und Speicherung seiner Daten im zusammengesetzten Dokument. Mit der

Container/Server-Beziehung k"onnen Daten verschiedener Formate wie Bilder oder

Ton in einem Dokument integriert werden.



\subsection{Vergleich von OLE und CORBA}



In \cite{DisObjSurvG} liefert ein Vergleich von OLE und CORBA das folgende 

Ergebnis:



Der Hauptunterschied zwischen CORBA und OLE besteht darin, da"s CORBA den 

klassischen

objektorientierten Ansatz verfolgt und auf seine Komponenten ausdehnt. Jede

Komponente unterst"utzt Mehrfachvererbung, Kapselung und Polymorphismus. Die

Komponenten geh"oren zu Klassen, die zur Laufzeit instanziiert werden k"onnen.

Die OLE-Komponenten hingegen sind keine klassischen Objekte. Sie k"onnen nicht 

durch

Vererbung erweitert werden, sondern nur durch Kapselung andere Objekte quasi

als 

eigene Methoden benutzen. Insgesamt ist eine OLE-Komponente eine Black Box,

die, 

nachdem sie gekauft und installiert wurde, nicht erweiterbar ist.



Zusammenarbeit zwischen OLE-Komponenten wird nur auf der bin"aren Ebene und nur

auf einem Rechner

unterst"utzt. OLE ist noch kein verteiltes System. 

Im Gegensatz dazu k"onnen CORBA-Komponenten "uber die Sprachen C,

C++, Smalltalk und COBOL aneinander gebunden und verteilt werden. CORBA 

ist OLE auch auf dem

Gebiet der System Services "uberlegen. CORBA bietet mehr Dienste als OLE

an. Zusammengesetzte Dokumente werden von OLE besser unterst"utzt als von

CORBA.



\subsection{Vergleich von OLE und Tycoon}



Bei OLE steht die Wiederverwendung von Daten im Vordergrund, um dem Benutzer

dokumentenzentriertes Arbeiten zu erm"oglichen. Aus dieser Motivation heraus ist

ein Ansatz f"ur verteilte Objekte gewachsen, um die Zusammenarbeit von

Applikationen zu erm"oglichen. Im Tycoon-System spielte die flexible

Wiederverwendung von

Daten bisher keine Rolle, deshalb findet man hier kein entsprechendes

Gegenst"uck. Es ist immer die Aufgabe des Anwendungsentwicklers, bei der

Wiederverwendung vorhandener Programme die Datenstrukturen entsprechend

anzupassen. Dabei wird er durch die

M"oglichkeit der Subtypisierung in {\sc Tl} unterst"utzt.

Generell ist die Wiederverwendung von Daten und Komponenten in

kooperativen Informationssystemen aber ein wichtiges Mittel, um die Zusammenarbeit zu

erleichtern. Deshalb wird sp"ater nochmals darauf eingegangen.

