Untersuchung der Möglichkeiten der verteilten Anwendungsentwicklung mit DCOM und Corba

Seminararbeit , 2000 , 27 Seiten

Informatik - Theoretische Informatik

Inhaltsverzeichnis

1 Verteilte Anwendungen
1.1 Das Client/Server Modell
1.2 Middleware

2 Komponentenbasierte verteilte Anwendungen
2.1 Anwendungsgebiete
2.2 Grundlagen
2.2.1 Interfaces
2.2.2 Servertypen und Lebenszeitmanagement

3 DCOM
3.1 Historie
3.2 Von COM zu DCOM
3.3 Interfaces in (D)COM

4 Corba
4.1 Historie
4.2 Abgrenzung zu DCOM
4.3 Die Architektur von Corba

5 Vergleich der Technologien
5.1 Interoperabilität
5.2 Zuverlässigkeit
5.3 Performance
5.4 Zukunftssicherheit
5.5 Zusammenfassung des Vergleichs

6 Ausblick
6.1 DCOM
6.2 Corba

Zusammenfassung

Corba und DCOM sind die fortschrittlichsten Technologien bei der Unterstutzung zur verteilten Anwendungsentwicklung in Unternehmen. Ziel dieser Ausarbeitung soll es sein, die theoretischen Grundlagen einer komponentenbasierten verteilten Umgebung vorzustellen und abschlieBend die beiden Produkte miteinander zu vergleichen.

1 Verteilte Anwendungen

Von verteilten Anwendungen spricht man, sobald eine Reihe von Prozessen über Rechnergrenzen hinaus miteinander kommunizieren. Wie weitverbreitet und als solche auch schwer erkennbar verteilte Anwendungen sind, zeigen folgende Beispiele[ Ö97]

- Netzwerkbetriebsysteme,
- entfernte Datenbankzugriffe,
- RPC’s und
- verteilte Objektsysteme.

So unterschiedlich diese Systeme auch sind, ihnen gemein sind jedoch die Vor- teile, welches das Verteilen von Ressourcen mit sich bringen. Durch den Zu- griff auf zentral verwaltete Daten werden Redundanzen und Inkonsistenzen vermieden. Knappe Ressourcen, wie z.B. Drucker oder Rechenkapazitäten können effizienter genutzt werden. Datenaustausch und Kommunikations- prozesse werden effizienter gestaltet. All diese Modelle nutzen Technologien, welche die Komplexität, die sich aus der Verteilung von Prozessen ergibt zu bewältigen helfen.[Fer99]

1.1 Das Client/Server Modell

Allen hier vorgestellten Verteilungstechniken liegt das Client/Server Modell zugrunde. Hierbei stellt eine Partei ein Service zur Verfügung, welchen eine andere nutzen kann. Fordert nun also ein Client die Serviceleistung vom Ser- ver, so muss er sich über vorher definierte Schnittstellen an diesen wenden. Nach Erbringung des Services liefert der Server das Ergebnis an den Client zurück. Dieses Verhalten kann man über mehrere Schichten fortsetzen. Da- bei nutzt ein Server wiederum den Dienst eines anderen Servers, wird also selbst zum Client. Eine solche Architektur wird auch als n tier architectur model bezeichnet und in Abschnitt 2.1 näher beschrieben. Das Client/Server Modell ist in der Informationstechnik weitverbreitet. Es finden sowohl in der Hardware- als auch der Softwareentwicklung Anwendung.[ Ö97]

1.2 Middleware

Das Client/Server Modell beschreibt, wie aus Sicht des Softwareentwicklers Applikationen über Rechnergrenzen hinaus miteinander kooperieren können. Es sagt nichts darüber, wie die notwendige Kommunikation zwischen Client und Server realisiert wird. Aufrufe über Prozess- oder gar Rechnergrenzen hinaus sind keinesfalls trivial. Es muss berücksichtigt werden, dass es, um die Systemsicherheit zu gewährleisten ist, interprozessuale Kommunikation nur anhand von Kunstgriffen und über Umwege realisiert werden kann. Dies ist nötig, da es keinem Prozess möglich sein sollte, auf den Prozessraum einer anderen Applikation zuzugreifen. Es wird also eine Infrastruktur, die sogenannte middleware¹ benötigt, die den Datenaustausch zwischen Prozes- sen ermöglicht. Sie ist typisch in verteilten Umgebungen und so sind auch DCOM und Corba middleware-Applikationen. Die middleware hat also prin- zipiell die Aufgabe bei der Verteilung von Software zu unterstützen. Diese bleibt für den Nutzer unsichtbar. Der Softwareentwickler jedoch muss, um deren Mechanismen effektiv nutzen zu können ein tiefes Verständnis für de- ren Funktionsweise mitbringen. Im Laufe der Zeit haben sich eine Reihe von Techniken etabliert, welche bei der verteilten Anwendungsentwicklung un- terstützen. Diese reichen vom einfachen Nachrichtenaustausch (message pas- sing) über den Aufruf von entfernten Funktionen (remote procedure calls) bis hin zu verteilten Komponenten (DCOM und Corba). Die Qualität ei- ner middleware hängt von einer Reihe zum Teil miteinander konkurrierender Eigenschaften ab. So geht eine hohe Flexibilität oft zulasten einfacher Be- dienung und überläst viele Aufgaben dem Entwickler. Prinzipiell lassen sich aber folgende Anforderungen an jede middleware stellen.[ Ö97]

Unabhängigkeit vom Transportsystem Der Austausch von Daten soll Unabhängig von darrunterliegenden Technologien ermöglicht werden. Routineaufgaben, wie Verbindungsaufbau oder Synchronisation sollten von ihr übernommen werden.

Heterogenität verbergen Die middleware muss in einem heterogenen Um- feld das Zusammenarbeiten der Applikationen gewährleisten. Dazu gehört auch, dass Betriebssystem- oder Hardwarespezifika auf Client- oder Ser- verseite berücksichtigt werden, um z.B. Datentypen kompatibel zuein- ander zu halten.

Transparenz gewähren Hierbei sollen interne Strukturen für den Betrach- ter, der diese für die Erfüllung seiner Aufgaben nicht zu wissen braucht, unsichtbar bleiben. Dadurch reduziert man Entwicklungsaufwand, stei- gert die Übersicht und erleichtert die Wartung. Unter dem Oberbegriff Verteilungstransparenz werden folgende Transparenzfunktionen zusam- mengefasst:

Ortstransparenz Der Ort eines Dienstes soll dem Anwender verbor- gen bleiben.

Zugriffstransparenz Der Zugriff auf lokale und entfernte Dienste wird gleich behandelt.

Migrationstransparenz Dienste können ohne Auswirkungen auf den Anwender verlagert werden.

Replikaktionstransparenz Dienste können dupliziert werden, wobei die Konsistenz der Daten gesichert bleibt.

Transaktionstransparenz Koordinationsmechanismen für Transak- tionen bleiben unsichtbar.

Fehlertransparenz Soweit möglich, sollen Fehlerbehebungsmaßnah- men vom Anwender unbemerkt vorgenommen werden.

Autonomie Zur Erfüllung eines gemeinsamen Zweckes kooperieren in einem Client/Server-System autonome Einheiten miteinander. Diese Einhei- ten können Unternehmensstrukturen entsprechen und ihnen wird ein gewisses Maß an eigenständiger Entscheidungsfreiheit gewährt. Der Grad der Autonomie wird von der Notwendigkeit auf Eigenkontrolle bestimmt. Hierzu werden die Interessen (globale und lokale) gegenein- ander abgewogen.

Skalierbarkeit Unter Skalierbarkeit versteht man die Anpassungsfähigkeit des Systems an eine sich ständig verändernde Umgebung. Mit der Zeit wechselt die Anzahl der Benutzer, der Rechnerknoten im Netz oder es kommt neue Hard- und Software hinzu. Eine middleware muss sich die- sen permanenten Änderungen anpassen können. Es sollte z.B. möglich sein neue Benutzer in das System zu integrieren, Anwendungen zu ver- lagern, Komponenten zu entfernen oder durch neue zu ersetzen, ohne dass es Einschränkungen im Betrieb des Systems gibt.

2 Komponentenbasierte verteilte Anwendun- gen

Moderne Softwareentwicklung versucht große, komplexe, monolithische Ap- plikationen in einfach zu entwickelnde, leicht verständliche und austauschbare Teile, sogenannte Komponenten² zu zerlegen. Diese können in unterschied- lichen Sprachen entwickelt sein, vorrausgesetzt es liegt eine Umgebung vor, die das Zusammenwirken der Komponenten sicherstellt. Neben den softwa- retechnischen Vorteilen (einfache Wartung, Wiederverwendung etc.) bietet sich hier die Möglichkeit, diese Komponenten in Netzwerken zu verteilen. Bei geschicktem Design der Software arbeiten die einzelnen Komponenten der Applikation weitgehend autonom. Ist dies der Fall, so ist es möglich die Software auseinander zureißen, zu verteilen, ohne das die Funktionstüchtig- keit beeinträchtigt wird. Somit ist prinzipiell jede Applikation welche kom- ponentenbasiert entwickelt wurde auch verteilbar. [Koc99] Die sich hieraus ergebenen Vorteile sind:

Wartbarkeit Von vielen Anwendungen gemeinsam genutzte Funktionalität lässt sich zentral verwalten und somit leicht handhaben. Die Aufteilung der Anwendungen in voneinander unabhängige Komponenten macht den Austausch einzelner Module möglich, ohne die Funktionstüchtig- keit der Gesamtapplikation zu gefährden.

Kapselung Durch die Festschreibung von Schnittstellen wird das Konzept des information hiding realisiert. Das bedeutet, dass dem Entwickler lediglich die offerierten Schnittstellen bekannt sein müssen. Um die zu- grundeliegende Implementation braucht er sich nicht zu kümmern.

Erweiterbarkeit Schnittstellen sind integraler Bestandteil komponenten- basierter Applikationen. Über sie ist es dem Entwickler möglich neue Bausteine an bestehende Implementationen anzubinden.

Flexibilität Durch die modulare Ausrichtung ist es leicht möglich, einzel- ne Komponenten für den jeweiligen Einsatz anzupassen. Problemlose Integration und kurze Entwicklungszyklen sind die Konsequenz.

Nicht bei jeder Komponente ist es sinnvoll diese zu verteilen. Es muss berück- sichtigt werden, dass durch das Zwischenschalten eines Netzwerkes ein over- head aus Kommunikations- und Koordinierungsaufgaben entsteht, der zu Performanceeinbussen führen kann. Man muss sich vor Augen führen, dass das Laufzeitverhalten bei der Verteilung maßgeblich vom Kommunikations- aufwand beeinflusst wird. Eine auf einem anderen Rechner ausgeführte Kom- ponente sollte mit geringem Datenvolumen manipulierbar sein. Der zeitliche

Überhang, der durch das zwischengeschaltete Netzwerk entsteht sollte gegenüber der Zeit, die für die Bearbeitung der Anfrage benötigt wird nicht zu hoch sein.[Tha99]

2.1 Anwendungsgebiete

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: three-tier architecture

Überall dort wo Client/Server basierte Applikationen genutzt werden, sind prinzipiell auch komponentenbasierte verteilte Anwendungen denkbar. Dies trifft in besonderem Maße auf den business layer des in Abbildung 1 dar- gestellten three tier architecture model zu. Dieses Softwarearchitekturmodell beschreibt den Aufbau einer Applikation, welche vielen Clients die Arbeit auf einer gemeinsamen Datenbasis ermöglicht. Es ist ein für betriebswirt- schaftliche Anwendungen gern verwendetes Modell und stellt eine Erweite- rung des Client/Server Modells dar. Die Clients der ersten Schicht sind für die Eingabe der Daten und deren Validierung zuständig. Im business layer werden diese Daten verwendet, um z.B. ein Angebot für einen Kunden zu erstellen. Dafür greift diese Schicht aus Daten aus der Datenbank Schicht zurück. Vorteil dieser Vorgehensweise ist es, dass die sich oftmals ändernden Teile einer solchen Applikation, die Geschäftsregeln nur einmal, zentral vor- liegen. Komponenten, als zustandsorientierte Module sind besonders geeignet prozessgesteuerte Vorgänge abzubilden. Zudem ist diese Schicht ohnehin ei- ner entfernt liegenden Datenbank vorgeschaltet, so dass durch die zusätzlich Schicht kaum Performanceeinbussen zu erwarten sind.[Cha98]

2.2 Grundlagen

Beide hier vorgestellten Technologien weisen bezüglich der zugrundeliegenden Techniken starke Gemeinsamkeiten auf. Deswegen sei an dieser Stelle ein Einblick in die Funktionsweise einer komponentenbasierten Verteilungsumgebung gegeben und nachfolgend dann zu den einzelnen Techniken die notwendigen Ergänzungen geliefert.

Aufgrund der Forderung nach Transparenz sollte für den Entwickler kein Unterschied zwischen einer lokalen - im Prozessraum seiner Applikation aus- geführten - und einer entfernten Komponente bemerkbar sein. Aus diesem Anspruch lassen sich die zentralen Aufgaben einer komponentenverteilen- den middleware ableiten. Zunächst muss dem Client die Möglichkeit gegeben werden sich mit der Komponente vertraut zu werden, ihre veröffentlichten Methoden ihr Interface kennen zulernen. Sobald ein Client nun über das Interface auf eine Komponente zuzugreifen versucht, muss diese lokalisiert und auf dem entfernten Rechner initialisiert werden. Außerdem müssen Me- thodenaufrufe des Clients abgefangen und zum Server durchgeschleust, dort ausgeführt und die Rückgabewerte auf umgekehrten Weg wieder zurückgege- ben werden. Diese Aufgaben werden mit Hilfe der sogenannte Stub/Skeleton- Technologie, welche schon bei RPC’s³ genutzt wird, gelöst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Methodenaufruf in einer Verteilungsumgebung

2.2.1 Interfaces

Wie man in Abbildung 2 sieht, wird an Stelle des Komponentencodes im Client lediglich eine Fassade, der sogenannte stub⁴, implementiert. Er fängt Methodenaufrufe ab und übergibt diese an den die middleware, welche für die Ausführung auf dem entfernten Rechner zuständig ist, weiter. Damit dieser Mechanismus funktionieren kann, muss der Client ein eindeutiges Bild von der Serverkomponente besitzen.

Die interface definition language In der interface definition language werden dafür die öffentliche Methoden der Komponente in einer programier- prachenunabhängigen Form deklariert. Jede Komponente kann dabei beliebig viele unterschiedliche Interfaces definieren. Aus dieser Quelle beziehen so- wohl Server als auch Client ihre Vorstellung von der Komponente. Zusätzlich wird hieraus der Code für den stub generiert, welcher in die Clientapplikation gelinkt wird. Die Serverkomponente erhält gleichfalls kompilierten Code, den skeleton⁵, welcher die Methodenanfrage entgegennimmt und die entsprechen- de Methode im Server aufruft. Es ist dann die Arbeit des Programmierers diese Methoden mit Leben zu füllen.[Ros98]

Eine Interfacedefinition weicht, da sie den Anforderungen einer verteilten Umgebung gerecht werden muss, gegenüber einer normalen Objektdefinition in einigen Punkten ab.

interface a [uuid(0000-0000-0000-0000)]

{

attribute UShort value;

void set_value(in UShort new_value);

void get_value(out UShort output_value);

void add_to_value(inout UShort value_to_be_added); oneway void performthisoperation();

};

Wie man am obigen Beispiel, welches der Spezifikation der IDL von Cor- ba folgt, sieht, werden im Interface lediglich die öffentlichen Methoden des Objekts beschrieben. Zusätzliche bekommen die Argumente einer Funktion einen weiteren Parameter, der angibt in welche Richtung die Argumente beim Methodenaufruf versandt werden. Das hat den Vorteil, das keine unnötige Daten über das Netzwerk versendet werden. Zusätzlich kann man angeben, ob der Client auf die Ausführung der Operation warten soll (synchroner Auf- ruf, Standardeinstellung) oder ob sofort nach Absetzen des Befehls fortgefah- ren werden soll (asynchroner Aufruf). Eine kurze Zusammenstellung zu den Schlüsselwörtern der IDL findet sich in Tabelle 1. Die komplette Spezifikation der Corba IDL findet sich in [Obj], die der DCOM IDL in [Mic].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Schlüsselattribute in IDL

Interfaces werden zusätzlich zu ihrem Bezeichner zur Identifizierung mit einem global eindeutigen Schlüssel (GUID⁶ ) belegt. Dieser wird beim Anle- gen des Interfaces automatisch anhand der Systemzeit und Rechnerspezifika generiert und stellt somit in hohem Maße sicher, dass es weltweit keine zwei unterschiedliche Interfaces mit der selben GUID gibt. Mit Hilfe des Schlüssels wird das Interface und dessen zugehörige Komponente intern verwaltet und referenziert.

Dynamisches Binden Das bisher beschriebene Verfahren des statischen Bindens hat einen entscheidenden Nachteil. Es muss dem Client bereits zur Compilezeit das Interface bekannt sein. Dies ist jedoch nicht immer möglich. Deshalb gibt es zusätzlich die Möglichkeit des dynamischen Bindens. Dadurch wird es möglich wird, während der Laufzeit das Interface anzufordern und ohne expliziten Clientstub auf Serverobjekte zuzugreifen. Es wird dann vom Client jeder Methodenaufruf entsprechende seiner Definition zusammenge- stellt und verschickt. Diese Technik hat jedoch die Nachteile, das gegenüber einem statischen Binden Performanceeinbussen zu erwarten stehen und das keine Typüberprüfung der Argumente stattfindet. Dynamisches Binden wird z.B. benötigt, wenn man Scriptingmöglichkeiten zur Verfügung stellen will.

Die Vorteile der Interfacetechnologie Die Interfacetechnik ermöglicht es Komponenten zu entwickeln und über Prozessgrenzen hinaus auf die- se zuzugreifen. Durch die Trennung von Interface und Implementation er- reicht man Sprachunabhängigkeit und erzielt somit die Fähigkeit in hete- rogenen Umgebungen auf gemeinsame Komponenten zuzugreifen. Weiterhin sind Änderungen an der Implementierung möglich, ohne dass der Client davon beeinträchtigt wird.

2.2.2 Servertypen und Lebenszeitmanagement

Da Komponenten keine eigenständige Programme sind, benötigen sie eine Applikation, in deren Prozessraum sie laufen können. Das bedeutet, dass so- bald ein Client eine Komponente anfordert die zugehörige Serverapplikation gestartet werden muss⁷, um dann in deren Adressraum die Komponente in- stanzieren können. Eine automatisch gestartete Applikation muss sich also auch selber beenden, sobald sie nicht mehr benötigt wird. Damit ist es nötig, neben der Lebenszeit einer Komponente auch die der umschließende Serve- rapplikation zu managen. So muss z.B. auch berücksichtigt werden, dass im Falle eines Netzwerkfehlers oder durch den Absturz des Clients die Verbin- dung zum Server plötzlich abreißen kann, ohne das dieser das bemerkt. In einem solchen Fall ist es Aufgabe der middleware den Server vom Vorfall in Kenntnis zu setzen. Bei dieser Aufgabe unterstützen sowohl Corba als auch DCOM. Abbildung 3 zeigt einige der vielen Varianten wie Clients auf

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Clients greifen auf Komponenten zu

Komponenten zugreifen können. Wie man sehen kann, können mehrere Kom- ponenten in ein und dem selben Server residieren. Mehrere Clients können die gleiche Instanz einer Komponente benutzen oder aber für jeden Client wird eine eigene Instanz erzeugt. Auch hier ergeben sich verschiedenste Probleme des Lebenszeitmanagements, welche meist über Referenzzähler zu lösen sind. Eine vollständige Auflistung von Servertypen findet sich in [Sch97] und in [Tha99, Seite 91ff].

3 DCOM

3.1 Historie

Das distributed component object model (DCOM) ist eine im Jahre 1996 vor- gestellte Technologie aus dem Hause Microsoft. Es wurde erstmals mit NT 4.0 ausgeliefert und ist seit 1997 auch für Windows 95 verfügbar. Es existieren zudem einige Portierungen unter dem Namen EntireX für diverse UnixDerivate (z.B. Sun Solaris, Digital Unix, HP-UX, AIX, Linux, OS/390) von der Software AG. DCOM beruht auf dem component object model (COM) und erweitert dieses um die Möglichkeit der Verteilung.

3.2 Von COM zu DCOM

Die Erweiterungen gegenüber dem COM-Standard sind dabei vergleichswei- se gering. COM bietet einem Prozess die Möglichkeit auf in einem anderen Prozess residierende Komponenten zuzugreifen. Es stellt die Grundlage für viele zur Verknüpfung von Applikationen genutzte Technologien dar. Ziel ist es dabei in beliebigen Programmiersprachen entwickelte Softwarebaustei- ne und Funktionalitäten für andere Applikationen zur Verfügung stellen zu können. Die dazu notwendige Übermittlung der Daten, das Weiterleiten von Funktionsaufrufen übernimmt das COM-Laufzeitsystem. Um eine Kompo- nente im Server lokalisieren zu können setzt COM eine feste Struktur des Binärcodes der Applikation voraus. Das bedeutet, dass COM-Objekte nur mit entsprechenden Compilern erzeugt werden können. Es ist es auch nicht möglich von COM-Objekten abzuleiten, da dies ein genaueres Bild von der verwendeten Komponente voraussetzen würde. Daher ist COM ehr eine ob- jektbasierte denn eine objektorientierte Technologie. Die Abbildung 4 zeigt

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Interprozesskommunikation in COM und DCOM

die Unterschiede zwischen COM und DCOM. Während COM LPC’s⁸ zur Kommunikation verwendet, werden in DCOM diese durch DCE-RPC’s⁹ er- setzt und zusätzlich Sicherheitsmechanismen implementiert. Ansonsten sind beide Technologien absolut identisch, was für Programmierer, welche bereits COM benutzt haben den Umstieg auf DCOM enorm erleichtert.[Koc99]

DCOM alleine stellt nur die Grundfunktionalität zur Verfügung, welche für das Verteilen von Objekten benötigt wird. Microsoft bietet aber mit der Backoffice-Familie¹⁰ ein Reihe von ergänzenden Produkten an, welche den Nutzwert von DCOM steigern sollen. Sie entsprechen in etwa den services von Corba, welche im Abschnitt 4.3 näher besprochen werden. Im Gegensatz zu diesen sind die Backoffice-Produkte jedoch nicht Bestandteil von DCOM, sondern eigenständige Applikationen, welche vor allem in der 2 und 3 Schicht des three tier architecturemodel zum Einsatz kommen.

3.3 Interfaces in (D)COM

Interfaces sorgen dafür, dass Objektrepräsentation und -implementierung voneinander getrennt werden. COM-Interfaces setzen jedoch eine spezielle Strukturierung des Binärcodes einer Komponente voraus. Damit ist diese Trennung teilweise Aufgehoben. Neben diesem Nachteil lassen sich noch einige andere in Bezug auf den Umgang mit Interfaces finden.

Fehlende Strukturierung der Interfaces Ein Nachteil ist, das ein Client nur eine Zusammenstellung von zusammengehörigen Interfaces zu Gesicht bekommt, jedoch keine Aussagen zur Hierarchie eingebetteter Komponen- ten erhält. So veröffentlich z.B. Word eine Komponente namens Applikation. Diese hat u.a. die Eigenschaft ActiveDocument, welches auf eine Document Komponente verweist. In der Interfacedeklaration hingegen erscheinen Ap- plikation und Document auf der selben Ebene, obwohl ein direkter Zugriff auf Document gar nicht möglich ist. Zudem fallen Vererbungsstrukturen die- ser flachen Ordnung zum Opfer. Obwohl Interfacedeklarationen in der IDL Mehrfachvererbung unterstützen, gehen diese Informationen beim Kompilie- ren in die .tlb Datei verloren. Deswegen sieht man in jedem Interface alle veröffentlichen Methoden, nicht jedoch aus welchen Interfaces diese abgelei- tet sind.

Einschränkungen bei der Definition Zudem erlaubt die MIDL lediglich Methodendeklarationen nicht jedoch die Definition von Eigenschaften. Zwar kann mit der Automatisierungstechnik¹¹ dies umgehen, muss aber dafür Performanceeinbußen in kauf nehmen. [Sch98]

Verwaltung der Interfacedefinition Weiterhin gibt es keine zentrale Anlaufstelle, aus welcher sowohl Client als auch Server Interfaceinformatio- nen beziehen können. Mit der MIDL¹² definierte Interfaces werden entweder in die Serverapplikation gelinkt oder aber in einer .tlb gespeichert. Diese kann dann weitergegeben werden und in der jeweiligen Clientapplikation verwen- det werden. Diese Informationen werden sowohl im Client als auch im Server lokal in der Registry gespeichert. Dies bedeutet eine Verdopplung von Daten und damit eine erschwerte Verwaltung. Abhilfe wird hier der active directory service bringen, der zusammen mit NT 5.0 ausgeliefert und als zentrale Da- tenbank für die Nutzerdaten und Serviceinformationen einer Domain dienen wird[Mic96].

4 Corba

4.1 Historie

Im Dezember 1991 stellte die OMG¹³ den Corba Standard vor, welcher die plattformübergreifende Nutzung von verteilten Objekten ermöglichen soll. Corba ist eine Spezifikation, welche die grundlegenden Eigenschaften einer Verteilungsarchitektur beschreibt. Oberstes Ziel ist die Unabhängigkeit von Plattform oder Programmiersprache. Damit wird die Integration von Corba in eine bestehende Systemumgebung möglich, was im Einsatz in Unterneh- men von entscheidenden Vorteil ist. Ab der Version 2.0 des Corba Standards ist auch geregelt, wie das Zusammenspiel mehrer von verschiedener Anbietern entwickelter Corbaimplementierungen zu regeln ist. Somit steht eine große Anzahl von kompatiblen Corba-Produkten, wie z.B. den ObjectBroker von BEA Systems oder den VisiBroker von Inprise zur Verfügung. [Ros98]

4.2 Abgrenzung zu DCOM

Grundsätzlich gleichen sich Corba und DCOM stark. Ein wesentlicher Unter- schied liegt darin, das Corba lediglich eine Spezifikation darstellt, während DCOM als integraler Bestandteil der Windowsbetriebssysteme besonders auf diese zugeschnitten ist. Der sich ergebene Vorteil liegt in der leichteren Por- tierbarkeit von Corba. Zudem wurde Corba speziell auf die Bedürfnisse einer komponentenbasierten Verteilungsplattform hin designt, während DCOM ehr als Erweiterung von COM zu verstehen ist. Microsoft handelt bei DCOM ehr nach dem Prinzip ”Erst implementieren und dann designen”[MET98, Seite 19], während Corba den genau umgekehrten Weg geht. Damit bietet Corba ein breitere Unterstützung bei den im Rahmen der Komponentenentwicklung zu erwartenden Problemen. So ist z.B. bei DCOM der Client zur Angabe eines Serverrechners genötigt, auf dem er die entsprechende Komponente vermu- tet. Corba hingegen übernimmt mit Hilfe eines smart agent das Auffinden des entsprechenden Objekts selber. [Cha98]

4.3 Die Architektur von Corba

Abbildung 5 zeigt den Aufbau eines Corba-ORB¹⁴. Der ORB ist das Ge- genstück zur DCOM-Laufzeitumgebung. Er ist das Herzstück einer jeden Corba Implementation und ist für das Umleiten von Clientanforderungen an einen entsprechenden Server zuständig. Im folgenden werden die einzelnen Bestandteile des ORB näher erläutert. Eine vollständige Beschreibung findet sich in [Obj95]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Corba ORB Architektur

Interface Repository Das Interface Repository ist eine verteilte Laufzeit- Datenbank, die maschinenlesbare Versionen der IDL-definierten Schnitt- stellen, die Metadaten, beinhaltet. Sie ist die zentrale Anlaufstelle zum Auffinden von Informationen zu den Interfaces. Ein API¹⁵ erlaubt, die Metadaten zu lesen, abzuspeichern und zu verändern.

Dynamic Invocation Interface (DII) Mit Hilfe dieses Dienstes wird das dynamische Binden auf der Clientseite realisiert.

Object Implementation Die Object Implementations implementieren die in den IDL-Interfaces spezifizierten Schnittstellenbeschreibungen. Sie können in den unterschiedlichsten Sprachen realisiert werden, die vom ORB unterstützt werden. Hierunter fallen unter anderem C, C++, Del- phi, Java, Smalltalk und Ada.

Object Adapter Der Object Adapter nimmt Dienstanfragen der Clients entgegen und aktiviert die entsprechenden Server-Objekte. Er bildet die Laufzeitumgebung der Server-Objekte, übergibt ihnen die Anfragen und weist ihnen Objektreferenzen zu. Der Object Adapter registriert die von ihm unterstützten Klassen und Objekte im Implementation Repository.

Implementation Repository Das Implementation Repository bildet ei- ne Laufzeitdatenbank, die Informationen über die von einem Server unterstützten Klassen und Objekte enthält. Weitere Informationen, die mit der Implementierung von ORBs zusammenhängen, z.B. Trace- Informationen, Prüfprotokolle, Sicherheit und andere administrative Daten, sind dort ebenfalls zu finden.

Dynamic Skeleton Interface (DSI) Das Dynamic Skeleton Interface ist das Gegenstück zum DII auf der Client-Seite. Es erlaubt eingehen- de Methodenaufrufe von einem Client, für die keine entsprechenden IDL-kompilierten Skeletons existieren, dynamisch zu bearbeiten. Sei- ne Aufgabe besteht darin, ankommende Anfragen von einem Client zu analysieren und das dafür vorgesehene Objekt zu finden und den Methodenaufruf abzusetzen. [Cha98]

Zusätzlich bietet Corba eine Reihe von services, welche den Funktionsumfang des ORB erweitern. Sie unterstützen bei so zentralen Fragen wie der Lebenszeitverwaltung einer Komponente, Sicherheitsüberprüfungen und Synchronisation von Objekten. Die services im einzelnen sind:

Life Cycle Service Regelt das Erzeugen und Vernichten von Objekten.

Persistence Service Ermöglicht das Speichern von Objektzuständen und -referenzen.

Naming Service Dient dem Auffinden von Objekten im Netzwerk über des- sen Namen.

Event Service Ermöglicht dem Server Clients den Eintritt von Ereignissen zu melden.

Concurrency Control Service Dient der Synchronisation von Objekten und verhindert so das Auftreten von deadlocks.

Transaction Service Dient dem zusammenfassen mehrerer zusammengehöri- ger Operationen zu einer Transaktion. Siehe auch Abschnitt 5.2.

Relationship Service Dient der Verwaltung von Beziehungen zwischen Ob- jekten. Wird z.B. ein Objekt gelöscht so werden auch alle eingebetteten Objekte mit entfernt.

Externalization Service Ermöglicht es den Zustand von Objekten in einen Datenstrom zu verwandeln. Dadurch kann ein Objekt über Rechner- grenzen hinaus verschickt werden.

Query Service definiert Operationen auf Gruppen von Objekten mit glei- chen Prädikaten, Attributen oder Properties.

Properties Service Properties werden erst zur Laufzeit dem Objekt zuge- wiesen.

Time Service Synchronisiert die Systemuhren.

Security Service Schützt vor unbefugten Zugriffen.

Weitere Dienste sind der Licensing Service, der Trader Service und der Collection Service. Eine ausführlichere Beschreibung der services findet sich in [Höl99, Seite 11ff], die vollständige Spezifikation in [Obj96].

Ein weitere Sammlung von Diensten wird in den Corba facilities zu- sammengefasst. Hier finden sich komplexe Bausteine, die eine Reihe von Standardfunktionen bereitstellen. Zu den in der Entwicklung befindlichen common facilities gehören zum Beispiel Drucken, E-Mail, Datenaustausch, Frameworks für Business-Objekte und Internationalisierung. Allerdings sind diese nicht Bestandteil der Corbaspezifikation. Näheres hierzu findet sich in [Ede97].

5 Vergleich der Technologien

Auch wenn die Ansätze, die beide Technologien verfolgen sich stark ähneln, so sind doch die Herangehensweisen sehr unterschiedlich. Im anschließenden Kapitel soll versucht werden, einen Vergleich zwischen DCOM und Corba anzustellen, was bei derart komplexen Umgebungen und der Vielzahl denkbarer Verwendungen jedoch ein hehres Unterfangen darstellt.

Nur allein der Umstand, dass Corba als Spezifikation auf viele verschie- dene Umsetzungen bauen kann macht den Vergleich fragwürdig. Dennoch lassen sich bezüglich gewisser Eigenschaften Vor- und Nachteile der einzel- nen Techniken herausarbeiten. Welche Technologie dann im einzelnen der Vorzug gegeben wird, hängt maßgeblich von den Anforderungen an die jewei- lige Aufgabe ab. Die folgende Aufstellung geschieht in Anlehnung an ”Corba vs. DCOM - Solutions for the enterprise” von der META Group Consul- ting[MET98]. Dieses Papier stellt in Bezug auf die verteilte Anwendungs- entwicklung im Geschäftsbereich einer Unternehmung die Anforderungen an eine Verteilungsplattform und die deren Umsetzung in Corba bzw. DCOM gegenüber. Dabei geht man vom Vorhandensein eines zu erweiternden Sy- stems, sowie der Notwendigkeit der ständigen Anpassung der Software an die sich ändernde Infrastruktur im Unternehmen aus.

5.1 Interoperabilität

Aufgabe einer middleware ist, Softwaresysteme miteinander zu verbinden. Um dies in einer heterogenen Umgebung gewähren zu können muss sie in der Lage sein, möglichst unabhängig von zugrundeliegenden Techniken Interaktion zwischen den Systemen zu erlauben. Interoperabilität meint hier also vor allem die Fähigkeit der middleware ein möglichst breites Spektrum verschiedenartiger Umgebungen bedienen zu können.

Aufgrund der breiteren Plattformunterstützung kann Corba hier einen klaren Punktsieg davontragen und auch bezüglich der Unterstützung durch flankierende Module liegt Corba vorn.

Abbildung in dieser Leseprobe nicht enthalten

5.2 Zuverlässigkeit

In einer middleware werden komplexe Vorgänge, die nach außen hin nicht sichtbar werden, ausgeführt. Innerhalb dieser Vorgänge kann es zu Fehlern kommen, die dann weitreichende Folgen haben. Eine middleware muss also selbstständig dafür sorgen, dass in solchen Fällen der Schaden begrenzt wird.

Zudem bietet die offene Architektur Angriffspunkte für Attacken von aussen, so dass zusätzlich Sicherheitsmechanismen benötigt werden.

Um eine middleware vernünftig einsetzen zu können muss sie also eine Reihe von Diensten mitbringen, die diese Aufgaben übernehmen oder aber bei deren Umsetzung unterstützen.

Transaction Unter einer Transaction versteht man eine Operation oder ei- ne Gruppe von Operationen, die bis ins Letzte durchgeführt werden müssen. Dies bedeutet, dass entweder alle an der Transaktion beteiligten Objekte die Transaktion erfolgreich durchführen (ihre eigenen Datensätze aktualisieren), oder alle beteiligten Objekte müssen die Transaktion abbrechen (in den Zu- stand vor Einleitung der Transaktion zurückkehren).[Ros98] Corba offeriert den transaction service, der für diese Aufgabe verantwortlich zeichnet. Mi- crosoft hat mit dem Microsoft Transaction Server (MTS) eine vergleichbare Lösung zu bieten, jedoch präferiert die META Group den Corbaansatz, da der transaction service in die Spezifikation integriert ist.

Messaging Unter Messaging wird das sichere Versenden und Empfangen von Meldungen verstanden. Dabei soll sichergestellt werden, dass eine ein- mal versendetet Nachricht in jedem Falle auch den Empfänger erreicht, auch wenn dieser vorübergehend nicht erreichbar ist. Möglich wird dies, indem Nachrichten durch die middleware zwischengespeichert werden und sobald wieder eine Verbindung zustande gekommen ist versandt werden. Dabei soll- te der Client während dieser Wartezeit nicht blockiert werden(asynchrones Senden). Einige Corba Implementationen bieten Messaging Unterstützung, indem sie zusätzlich eine eigenständige message-oriented middleware (MOM) integrieren. DCOM bietet von Haus aus kein Messaging. Jedoch existiert mit dem Microsoft Message Queue Server (MSMQ) ein Produkt, welches diese Lücke zu schließen verspricht.

Sicherheit Ein zentraler Aspekt, mit dem die Akzeptanz einer middleware steht und fällt ist die Frage nach den Sicherheitsmechanismen der angebo- tenen Lösung. DCOM greift auf das security framework von Windows NT zurück. Über Nutzernamen und Nutzergruppen wird die Authenzität des Clients sichergestellt und entsprechende Zugriffsrechte vergeben. Bei jedem Zugriffsversuch auf eine Komponente wird überprüft, ob der Client zur Be- nutzung autorisiert ist. Dabei kann für jedes Interface einzeln Sicherheits- vorgaben vergeben werden. Damit entfällt die Programmierung von sicher- heitsspezifischem Code auf Client- und Serverseite. Für andere Plattformen benutzt man einen Windows NT kompatiblen security provider, um diesen Sicherheitsmechanismus nutzen zu können.

Neben der Authentifizierung spielt auch die Verschlüsselung der Daten eine Rolle. Insbesondere im Internet gilt es sicherzustellen, das ein Abhören der Verbindung zwischen Client und Server nicht möglich ist. Hier kommen SSL¹⁶ zum Einsatz und andere Authentifizierungsmechanismen(z.B. public key Verfahren oder Zertifikate).

Der Corba security service ist einer der strengsten überhaupt. Er um- fasst Authentifizierung, Zugriffskontrolle und Vertraulichkeit. Er bietet ein 3-stufigem Sicherheitskonzept und berücksichtigt so die unterschiedlichen Sicherheitsanforderungen im Unternehmen. Leider realisieren die meisten Corba-ORB’s den Standard nur unzureichend oder gar nicht. Lediglich Visi- genic kann einen ORB anbieten, der dem höchsten Sicherheitslevel entspricht.

Fehlertoleranz Unter dem Schlagwort Fehlertoleranz verbergen sich eine Reihe von Forderungen, die den Wunsch wiederspiegeln, dass eine middleware in der Lage sein sollte in möglichst breitem Umfang sich selbst zu reparieren. Das heißt, das im Falle eines Ausfalles Alternativserver gesucht, oder Arbeiten zwischengespeichert werden.

Corba bietet im Rahmen seiner Spezifikation keinen solchen Service an. Allerdings liefern einige Hersteller fehlertolerante Systeme mit aus. DCOM implementiert einen einfachen Ping Mechanismus. In regelmäßigen Abständen werden keep alive messages zum Server gesandt. Bleiben diese eine bestimm- te Zeitlang aus, so wird die Verbindung als unterbrochen angenommen und der Referenzzähler um eins verringert. Allerdings ist der Zeitraum, bis ein Client als tot deklariert wird nicht konfigurierbar und es kann nicht festge- stellt werden, ob der Server nicht in einer Endlosschleife hängt. Zudem führt dieses Verfahren zu erhöhter Netzwerklast. Näheres ist hierzu kann man in den White Papers zu DCOM unter [Mic96] erfahren.

Abbildung in dieser Leseprobe nicht enthalten

5.3 Performance

Natürlich muss das Ergebnis einer Performancebewertung einer derart kom- plexen Umgebung, wie es eine middleware darstellt mit entsprechender Vor- sicht genossen werden. Deswegen untersucht die META Group an dieser Stel- le weniger die Reaktionsschnelligkeit der einen oder anderen Installation als vielmehr deren Vermögen, sich an verschiedene Umgebungen und Anforde- rungen anpassen zu können. Dabei ist man auf Aussagen von Nutzern Corbas bzw. DCOMs angewiesen, was der Objektivität nicht gerade zuträglich ist. Außerdem werden der Umfang der Unterstützung bei der Erstellung von mul- tithreading Komponenten und Tuningmöglichkeiten an den Komponenten als Bewertungsfaktoren herangezogen.

Corba bietet laut Spezifikation weder Unterstützung bei der Erstellung von multithreading Anwendungen noch erlaubt es das Tuning von Kompo- nenten. Trotzdem liefern viele Corba Hersteller ihre Software mit entspre- chenden Werkzeugen aus. Ähnlich wie Corba besitzt auch DCOM von Haus aus keine multithreading Fähigkeiten. Da es jedoch integraler Bestandteil der Windowsbetriebssyteme ist, kann man problemlos auf deren Mechanismen zurückgreifen.

Abbildung in dieser Leseprobe nicht enthalten

5.4 Zukunftssicherheit

In Anbetracht der Tatsache, dass trotz eines sich ständig ändernden Unter- nehmensumfeldes Applikationen oftmals über mehrere Jahrzehnte weiterbe- stehen ist es besonders wichtig, auf eine middleware Technologie zurückgrei- fen zu können, die Wiederverwendung und die Eingliederung von Software- bausteinen auch auf lange Sicht ermöglicht. Deswegen ist es für Unternehmen wichtig auf eine Technologie zu bauen, deren Fortbestand auch auf lange Sicht gesichert ist.

Ausgereiftheit In Anbetracht der Tatsache, dass viele der oben genannte services (messaging, transaction) weder bei Corba noch bei DCOM vollständig vorliegen zeigt, welch starker Entwicklungsbedarf noch bei beiden Technologien herrscht. Trotzdem sind auf beiden Seiten starke Bemühungen vorhanden diese Lücken schließen zu wollen.

Zudem zeigt der Zuspruch, den gerade Corba erfährt, dass auch an- spruchsvolle Unternehmen, wie z.B. in der Telekommunikationsbranche oder die Luftschifffahrt auf diese Technologie bauen. Microsoft bemüht sich mit dem MSMQ, MTS und active directory den Anschluss wiederherzustellen. Allerdings besteht hier ganz klar die Einschränkung, dass diese Produkte nur in einer reinen Windows NT Umgebung laufen.

Herstellerunterstützung Für jedes Unternehmen ist es wichtig, auf Produkte zu setzen, von denen man annehmen kann, dass man auch noch in vielen Jahren Support für sie erhält.

Corba als eine Spezifikation, die von mehr als 700 Firmen getragen wird hat hierbei beste Aussichten auch auf lange Sicht zu bestehen. Die Stan- dardisierungsbemühungen der OMG sorgen zudem für Kompatibilität der einzelnen Installationen. Zudem sind mit IBM, BEA, oder Orbix namhafte Softwarehersteller an Corba beteiligt, so dass hier für die nächsten Generatio- nen der Fortbestand gesichert sein dürfte. Allerdings hat Corba aufgrund der großen Anzahl an Entscheidungsträgern den Nachteil, dass es sich langsamer entwickelt, als z.B. das größtenteils von nur einer Firma getragene DCOM.

DCOM wiederum hat bezüglich der Plattformunabhängigkeit und der technischen Ausgereiftheit einige Einschränkungen. Da es aber eine Schlüsseltechnologie im Bereich der Backoffice-Familie Microsoft darstellt, ist zu erwarten, dass Microsoft versuchen wird diese Technologie und damit Windows NT am Servermarkt durchzudrücken.

Skalierbarkeit Um in einem sich wechselnden Umfeld bestehen zu können, muss eine middleware die Fähigkeit besitzen, mit wachsenden Anforderungen zurechtzukommen. So sollte im Falle einer steigenden Anzahl von Komponenten nicht zu Performanceeinbrüchen aufgrund der schwierigeren Verwaltung kommen. Zudem muss es Eingriffsmöglichkeiten für den Administrators geben, um Engpässe beseitigen zu können.

Beide Technologien unterstützen hier nur unzureichend. So bietet Corba keinen entsprechenden service, der die gewünschten Funktionen zur Verfügung stellt und auch DCOM hat nichts vergleichbares vorzuweisen. Bei Corba kann man aber aufgrund guter Erfahrungen mit Großprojekten davon ausgehen, dass es nicht so schnell an seine Grenzen stößt.

Abbildung in dieser Leseprobe nicht enthalten

5.5 Zusammenfassung des Vergleichs

Vom technologischen Standpunkt aus betrachtet zeigen sich keine wesentli- chen Unterschiede zwischen DCOM und Corba. Sieht man von der Plattfor- munabhängigkeit einmal ab, so sind beide nahezu gleichwertig. In einer reinen Windows NT Umgebung ist DCOM sicherlich die bessere Wahl, da es sich nahtlos in eine bestehende Umgebung einpasst und zudem ohne Extralizenz genutzt werden kann. Natürlich ist man mit dieser Wahl auf diese Platt- form festgelegt. Dieser Nachteil besteht bei der Wahl von Corba nicht. Ziel der OMG war es schon immer Plattformunabhängigkeit und die bestmögli- che Integration in bestehende Umgebungen zu gewähren. Zudem sind flan- kierende services mit Bestandteil der Corba Spezifikation. Dies sichert die Interoperabilität, Flexibilität und erhöht die Stabilität der Corba Implemen- tation. Allerdings ist die OMG aufgrund ihrer Größe oftmals langsam in ihren Entscheidungen und so werden Corba Implementationen oftmals mit nicht standardisierten Erweiterungen ausgeliefert. [Owe98]

6 Ausblick

6.1 DCOM

Microsoft hat inzwischen die Weiterentwicklung von DCOM der Active Group¹⁷ überlassen. In Zukunft werden unter dem Schlagwort COM+, der Weiter- entwicklung von COM, immer mehr Technologien zusammengefasst werden. Auf der Verteilungsseite sind hier Dinge wie ein publish and subscribe service, welcher es Servern erlaubt, an mehrere Clients Ereignisbotschaften zu sen- den, vorgesehen. Zudem werden queued components COM+ um messaging¹⁸ Fähigkeiten erweitern. Das dynamic load balancing verteilt automatisch Cli- entanfragen an mehrer Server und der MTS wird integraler Bestandteil von COM+ werden. Diese Bemühungen zeigen klar, dass Microsoft eine Alterna- tive zu dem offen Standard Corba setzen will ohne allerdings Plattformun- abhängigkeit gewähren zu wollen. [Cle]

6.2 Corba

Seit August 1999 ist die Corba Version 3.0 verabschiedet. Sie befindet sich noch im Status pre-production und wird Mitte 2000 mit dem Aufkommen der ersten Umsetzungen in den Status available wechseln. Ziel der neuen Spezifikation ist es, eine einfachere Handhabung zu etablieren, sowie neuen Anforderungen gerecht zu werden. Es wird versucht das Internet besser integrieren zu können. Dazu wird es Unterstützung für firewalls, sowie einen überarbeiteten nameservice geben. Zudem gibt es Bestrebungen die bestehenden services zu erweitern oder zu verbessern.[Sie99]

Es bleibt noch festzuhalten, dass sowohl DCOM als auch Corba einen klaren Fokus auf Internettechnologien legen. Corba zeigt viele Bestrebungen, seinen Standard in dieser Richtung zu erweitern. Besondere Hoffnung setzt man auf die Unterstützung aus der Java Gemeinde, da sich diese Sprache aufgrund ihrer Plattformunabhängigkeit besonders für die Zusammenarbeit mit Corba eignet. Microsoft hingegen setzt mit seiner ActiveX Technologie auf einen eigenen Standard.

In Zukunft werden wohl beide Technologien ihren Platz auf dem Markt finden. Ein klares Statement für oder wider die eine oder andere Technologie zu geben ist nicht möglich. Jeder sollte selbst entscheiden, welchen middle- ware er seinen Zuspruch gibt. Es gibt auch Bestrebungen Corba und DCOM zu kombinieren, um die Vorteiler beider Technologien nutzen zu können.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Literatur

[Cha98] Tin-Ho Chan. Seminarvortrag: Corba, IDL, Java-ORB. FH München, 1998.

http://www.informatik.fh-muenchen.de/ schieder/seminar-java- ss98/corba/ausarbeitung/index.html.

[Cle] James Cleverley. Com+ Watch. Wrox.

http://www.comdeveloper.com.

[Def] Webopedia, online Enzyklopädie.

http://webopedia.internet.com/TERM/m/middleware.html.

[Ede97] Falk Edelmann. Ablaufszenarien für Client-Server Anwendungen mit CORBA 2.0. Technische Universität Chemnitz, 7 1997.

http://archiv.tu-chemnitz.de/pub/1997/0042/top.html.

[Fer99] Ao. Univ. Prof. Dr. Abis Ferscha. Entwicklung verteilter Software. Universität Wien Institut für Angewandte Informatik, 1999.

http://www.ani.univie.ac.at/ ferscha/lehre/SS99.

[Höl99] Thomas Höller. Entwurf und Realisierung eines CORBA/SNMP Gateways. Technische Universität München, 6 1999.

http://www.nm.informatik.uni- muenchen.de/common/Literatur/MNMPub/Diplomarbeiten/hoel96/HTML- Version/main.html.

[Koc99] Carsten Kocherscheidt. Ausarbeitung: Verteilte Objekte - DCOM. Ruhr Universität Bochum, 1999.

http://www.etdv.ruhr-uni-bochum.de/dv/lehre/seminar/dcom.

[MET98] META Group consulting. CORBA vs. DCOM: Solutions for the Enterprise, 3 1998.

http://www.sun.com/swdevelopment/whitepapers/CORBA-vs- DCOM.pdf.

[Mic] Microsoft. DCOM Homepage.

www.microsoft.com/com.

[Mic96] Microsoft. White Paper: DCOM Architecture, 1996.

http://www.microsoft.com/com.

[ Ö97] Özer,Rezic, Sahin, Schneider. Ausarbeitung: Offene Verteilte Systeme. TU-Berlin, 7 1997.

http://www.de.freebsd.org/ wosch/lv/ovs/ausarbeitung/.

[Obj] Object Managment Group OMG. Homepage.

http://www.omg.org.

[Obj95] Object Managment Group OMG. CORBA 2.0/Interoperability - Universal Networked Objects, 3 1995. OMG TC Document 95.3.xx.

[Obj96] Object Managment Group OMG. CORBAservices: Common Object Services Specification, 3 1996.

[Owe98] Owen Tallman, J. Bradford Kain. COM versus CORBA A Decision Framework. Quoininc, 9-12 1998.

http://www.quoininc.com/quoininc/COM CORBA.html.

[Ros98] Jeremy Rosenberger. CORBA in 14 Tagen. Markt u. Technik, 1998. online Version unter

http://www.datanetworks.ch/ steger/pages/dom/corba/inhalt.htm.

[Sch97] Martin Schwarz. Moment, ich verbinde ... - COM, SOM und CORBA - oder die Suche nach dem Software-Esperanto. c’t Magazin, 3:256, 1997.

[Sch98] Arne Schäpers. Kurze Leine - Lokale COM-Server und -Clients. c’t Magazin, 3:174, 1998.

[Sie99] Jon Siegel. What’s Coming in CORBA 3. Object Managment Group OMG, 1999.

http://www.omg.org/news/pr98/compnent.html.

[Tha99] Thuan L. Thai. Learning DCOM. O’Reilly, 4 1999.

[...]

---

¹ Definition middleware aus [Def]: ”The term middleware is used to describe separate products that serve as the glue between two applications. It is, therefore, distinct from import and export features that may be built into one of the applications. Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them.” Alternativ finden sich auch die Bezeichnungen Verteilungsplattform oder distribution environment in der Literatur

² der hier verwendete Komponentenbegriff bezieht sich auf Objekte, wie sie in mo- dernen objektorientierten Programmiersprachen verwendet werden. Komponenten sind selbstständige Softwarebausteine, welche auch aus einer Reihe von eingebeteten Objek- ten bestehen können.

³ RPC: remote procedure call

⁴ stub, engl.: Stumpf, Stummel

⁵ skeleton, engl: Gerippe, Gestell

⁶ GUID: global unique identifier

⁷ die sogenannte remote activation

⁸ LPC: lightweight procedure call

⁹ DCE-RPC: Eine RPC Implementation der distributed computing environment

¹⁰ Backoffice-Familie: Eine Reihe von Windows NT Server-Programmen wie z.B. der SQL-Server oder der Internet Information Server (ein Webserver)

¹¹ Automatisierung: Synonym für dynamisches Binden s.a. 2.2.1

¹² MIDL: microsoft iterface definition language

¹³ OMG: object management group, Konsortium aus über 700 Firmen

¹⁴ ORB: object request broker

¹⁵ API: Application Programing Interface

¹⁶ SSL: security socket layer

¹⁷ Active Group setzt sich aus den Firmen Microsoft, Adobe, DEC, HP, SAP u.a. zusam- men

¹⁸ s.a. Abschnitt 5.2

• Hochschule: Technische Universität Ilmenau
• Autor: Martin Strecker (Autor:in)
• Erscheinungsjahr: 2000
• Seiten: 27
• Katalognummer: V96615
• ISBN (eBook): 9783638092913
• Sprache: Deutsch
• Schlagworte: Untersuchung, Möglichkeiten, Anwendungsentwicklung, DCOM, Corba