COM/DCOM und Software-Architektur

INHALTSVERZEICHNIS

1 Einleitung

2 Architektonische Grundlagen

3 Microsoft’s COM/DCOM
3.1 Überblick
3.2 Weiterführende Technologien in der Anwendung
3.3 COM/DCOM aus architektonischer Sicht
3.4 Technische Spezifikation und Anwendung

4 Bausteine von COM/DCOM

5 Zugriff auf Komponenten und Objekte

6 Fazit

A Abkürzungsverzeichnis

B Abbildungsverzeichnis

C Literatur

D Internetquellen

1 Einleitung

Dieses Kapitel soll kurz die Thematik der vorliegenden Arbeit einführen und die ersten Fragen nach dem warum, was und wie klären. Das Ziel dieser Arbeit ist es, einen Überblick über den Sinn und die grundlegende Idee der Funktionsweise von COM/DCOM zu vermitteln.

Das Gebiet der Informationstechnologie unterliegt einem ständigen Veränderungsprozeß. Laufend werden neue Technologien entwickelt und wenig später sind diese in Form von marktfertigen Produkten erhältlich. Der Markt für Informationstechnologie zeichnet sich durch einen stetigen Konkurrenzkampf aus, in dessen Folge sich die unterschiedlichsten Normen und eine Vielfalt an Standards und Protokollen entwickelten. Aus dieser Vielfalt resultieren unter Umständen inkompatible Softwarekomponenten, die zu großen Kommunikationsschwierigkeiten führen können. In der heutigen Zeit handelt es sich bei allen großen computerbasierten Systemen um solche, die Architekturen verteilter Systeme verwenden.[Som01, Seite 249] Das Ziel, welches die Entwicklung der Komponententechnologie (wie auch COM/DCOM) vorantreibt, ist, ähnlich wie in traditionellen Industriezweigen, häufig wiederverwendbare Softwarekomponenten ingenieurmäßig zu entwerfen und zu erstellen.[Fra99, Seite 1] Aus wirtschaftlicher Sicht folgt eine verlockende Perspektive. Bei vernachlässigbaren Kosten für die Vervielfältigung von Software (Komponenten) kann die Qualität von Software sowie die Entwicklungszeit, bei gleichzeitig geringeren Kosten verbessert werden. Zusätzlich können langwierige Testphasen vermieden werden, da nicht mehr ”großePakete“sonderneinzelne Komponenten auf ihre Funktionalität getestet werden können.

COM/DCOM ist ein von Microsoft entwickelter und implementierter Standard, der in Windows- Betriebssystemen integriert ist und eine komponentenbasierte Entwicklung von Softwaresystemen ermöglichen soll. Wenn man akzeptiert, daß Frameworks eine Form von Architektur darstellen, kann man abstrakt formulieren, daß COM/DCOM-Softwarekomponenten Teile eines Komponentenframeworks sind, das eine Bibliothek von Black- Box- Komponenten zur Verfügung stellt, eine wiederverwendbare Softwarearchitektur definiert, in der die Komponenten geeignet integriert sind und eine Art Verbindung schafft, die es dem Nutzer erlaubt, Komponenten miteinander (auch verteilt) kommunizieren zu lassen. Für die Entwicklung offener und erweiterbarer Softwaresysteme sind komponentenbasierte Modelle wie COM/DCOM der Stand der Entwicklung. Ein Ansatz zur Lösung des Kommunikationsproblems in verteilten Systemen besteht in der Definition eines globalen Standards, der Interoperabilität von Softwarekomponenten garantieren könnte. Einen solchen Standard stellt COM/DCOM dar. Wie diese Arbeit erläutern wird, steckt dahinter die Idee, über sauber definierte Schnittstellen austauschbare Softwareeinheiten zu schaffen.[Gru[00], a.d. Rezension] Eine Grundlage bildet der Binärstandard, der über Schnittstellen eine schnelle Ent wicklung bzw. Weiterentwicklung von Computersystemen ermöglicht. Auf weitere Einzelheiten soll hier nicht eingegangen werden, da die technische Ausgestaltung sehr komplex ist und sich der Blick für das aus der Gesamtsicht ergeben kann.

Um im späteren Verlauf ausreichend erklären zu können, worum es sich bei dem Standard COM/DCOM genau handelt, sollen zuerst die Rahmenbedingungen und die Anforderungen deutlich gemacht werden, mit denen sich Entwickler von großen Computersystemen auseinanderzusetzen haben. Aus den im nächsten Abschnitt aufgezeigten Grundlagen und den Problemen, die die Entwicklung von Computersystemen mit sich bringt, soll der Sprung zu einem Standard der Architektur, wie ihn COM/DCOM darstellt, leichter zu beschreiten sein. Die vorzustellenden Entwurfsregeln sind fundamentale Kernpunkte bei der Erstellung von Computersystemen mittels Komponententechnologien und sollen den Leser besser an die Probleme, die Technologien wie sie COM/DCOM mit sich bringen, heranführen. Im weiteren Verlauf der Arbeit sollen zunächst erste Definitionshilfen gegeben, eine anwendbare komponentenbasierte Technologie (ActiveX) vorgestellt und erste Definitionen der wichtigsten Elemente vorgenommen werden. Aus diesen Erläuterungen wird ein erster graphischer Überblickmöglich. Im [4]. Kapitel wird eine Vertiefung und Spezialisierung der COM/DCOM Elemente, und eine erste Einbindung in modellinterne Gegebenheiten, vorgenommen. Den Leser erwartet nach erhaltenem Basiswissen, das technisch anspruchsvollste Kapitel, das beispielhaft die transparenten internen Abläufe im Modell erläutern soll. Dazu wird ein Zugriff auf eine Funktionalität mittels COM/DCOM beschrieben. Im abschließenden Fazit werden die Vorteile und Nachteile, bzw. die sich daraus ergebenden Möglichkeiten für COM/DCOM (Architekturen), noch einmal zusammengefaßt.

2 Architektonische Grundlagen

Die Verteilbarkeit von hier erst einmal ganz allgemein Bausteinen spielt eine wichtige Rolle, wenn es um die Etablierung eines Standards wie COM/DCOM, der weltweit genutzt werden soll, geht. In diesem Abschnitt soll auf die Architekturen verteilter Softwaresysteme kurz eingegangen und Vorteile, bzw. Nachteile aufgezeigt werden. Grundlegend ist dazu anzumerken, daß es sehr wichtig erscheint, Entwurfsregeln für verteilte Systeme zu erstellen, um eine weitere Verbreitung und Nutzbarkeit gewährleisten zu können. Coulouris[Cou94, Som01, Seite 250] rückt dazu sechs Entwurfsregeln verteilter Systeme in den Mittelpunkt der Betrachtung:

1.) Ressourcenteilung: Verteilte Systeme können gemeinsam Hard- und Softwareressourcen nutzen.
2.) Offenheit: Zusätzliche Ressourcen müssen jederzeit zur Erweiterung eines bestehenden Systems implementiert werden können. (Hard- und Software für verteilte Systeme können unter Umständen sogar von verschiedenen Herstellern stammen.)
3.) Nebenläufigkeit: In einem Netzwerk können gleichzeitig verschiedene Prozesse auf mehreren Computern ablaufen.
4.) Skalierbarkeit: Um evt. ein System an neue Anforderungen anpassen zu können, kann die Kapazität eines Systems durch das Hinzufügen von weiteren Ressourcen erweitert werden.
5.) Fehlertoleranz: Bei diesem Charakteristikum steht die Tolerierbarkeit von Hard- und Softwarefehlern durch Replikation von Informationen auf verschiedenen Rechnern im Mittelpunkt. Ziel ist immer die Systemstabilisierung.
6.) Transparenz: Grundsätzlich soll die verteilte Struktur eines Systems für den Benutzer unsichtbar bleiben. Für ein besseres Handling ist es allerdings oft von Vorteil, einige Kenntnisse über Systemorganisation zu vermitteln.

Eine Herausforderung, die auch für die Entwickler von DCOM bestand, war und ist die Entwicklung von Hard- und Software, die gewünschte Eigenschaften eines Endproduktes realisiert (fachlich) und zugleich auftretende Probleme bei der Erstellung und Anwendung (Kompatibilität, Performance etc.) minimiert. Um dies zu erreichen, gibt es grundsätzlich zwei Möglichkeiten. Die erste Möglichkeit sind Client Server Architekturen, die allerdings bei der Entwicklung von DCOM als solches eher für interne Abläufe Verwendung finden. Die zweite Möglichkeit, auf der letztlich auch DCOM aufbaut, sind Architekturen verteilter Objekte. Diese Objekte liegen ebenfalls auf Servern bereit, um von den Clients angefordert zu werden. Zur Implementierung verteilter Objekte benötigt man eine sogenannte Middleware. Unter Middleware versteht man Softwarelösungen, die eine einheitliche Verteilungsplattform auch für, über Rechnergrenzen hinweg, verteilte Anwendungen zur Verfügung stellen. Aus Sicht des Programmierers sollte es dabei keine Rolle spielen, ob ein bestimmter Dienst auf dem eigenen oder einem anderen Rechner erbracht wird.[la]

Middleware, z.B. in Form eines Object Request Brokers (ORB) soll die Kommunikation zwischen den verteilten Objekten gewährleisten. Der ORB ist z.B. für die Lokalisierung bzw. die Aktivierung von Server-Objekten und die Übermittlung der angeforderten Informationen verantwortlich. Über diese Funktionalität können Anwendungen, die auf verschiedenen Systemen installiert sind, Daten bzw. Objekte austauschen. Der ORB bietet somit eine Basis für Interoperabilität in Netzwerken und ermöglicht die Kooperation von Objekten in verteilten Umgebungen. Wie später noch zu sehen sein wird, ermöglichen standardisierte Schnittstellen eine einfache Portierung der benötigten Anwendungen. Prinzipiell gelten für diese Objekte keine Vorschriften hinsichtlich Programmiersprache, Plattform und Kenntnis von anderen Objekten. Die betreffenden Schnittstellen, über die die Objekte angefordert werden, werden über den sogenannten Remote Procedure Call (RPC) aufgerufen. RPC ermöglicht es, diese Schnittstellen in einem Netz von verteilten Servern aufzurufen, als wären sie auf dem eigenen Computer. RPC kann quasi als Grundlage für DCOM angesehen werden. Die entsprechenden Schnittstellen werden mit einer Interface Definition Language (IDL) beschrieben und über einen Compiler generiert. Zur Zeit existieren zwei ernstzunehmende Standards, die die Architektur verteilter Systeme nutzen. Diese beiden Standards sind CORBA und DCOM.

3 Microsoft’s COM/DCOM

Microsoft‘s COM/DCOM war ursprünglich auf komponentenbasierte Softwareentwicklung in Windows-Umgebungen fokussiert, versteht sich inzwischen aber ebenfalls als Basistechnologie für verteilte Systeme. Weiterentwicklungen, die allerdings nicht Gegenstand dieser Arbeit sind, gehen immer stärkter auf die Verteilbarkeit von Objekten ein.

3.1 Überblick

Die Problematik bei der Entwicklung von computerbasierten verteilten Systemen bestand am Anfang darin, eine Kommunikation zwischen unabhängig voneinander entwickelten Applikationen, z.B. unter Windows, zu ermöglichen. Das Distributed Component Object Model (DCOM) könnte als ein abstraktes Objektmodell, zur Beschreibung von Komponenten und Schnittstellen sowie zur Integration in konkrete Programmiersprachen verstanden werden. Grundlage für das 1996 eingeführte DCOM ist das Component Object Model (COM), welches bei Microsoft als Schlüsseltechnologie zur Entwicklung komponentenbasierter Software gilt.[mi, Seite 9 ff] COM wurde 1995 eingeführt und zählt zu Microsoft‘s Schlüsseltechnologien, wenn es um die Weiterentwicklung seiner Betriebssysteme und Anwendungssoftware geht. COM ist eine Basistechnologie, die beschreibt, wie die Clients, die bestimmte Komponenten benutzen möchten, interagieren. Wenig später wurde COM um die Fähigkeiten verteilter Objekte erweitert. Das daraus entstandene Distributed COM (DCOM) erlaubt es nunmehr, Komponenten auf verschiedenen Rechnern eines Netzwerksystems zu verteilen.

3.2 Weiterführende Technologien in der Anwendung

Dieser Abschnitt soll sich einer komponentenbasierten Technologie, die über das Internet geregelt wird, widmen und eine konkrete Architektur im Zusammenhang mit COM/DCOM vorstellen.

ActiveX

COM/DCOM bietet die Basis für eine populäre Technik von Microsoft, die unter dem Namen ActiveX bekannt ist. ActiveX ist der Markenname für ein Produkt, welches seit 1996 den MS-Sammelbegriff für COM-basierte Internetlösungen bildet und in Konkurrenz zu den weit verbreiteten Java-Applets steht.[li, Seite 12] ActiveX ist eine clientseitige Technik, was bedeutet, daß sie auf dem Rechner eines Client (Users) in dessen Browser oder in einer Erweiterung davon ausgeführt wird.[gi]

[...]