1 Komponenten-Software

Transkript

1 1 Komponenten-Software 6 Von der objektorientierten Programmierung zur Komponenten- Software 10 Die Entwicklung von COM+ 14 Von COM zu COM+ 18 Just-In-Time-Aktivierung 20 Objekt-Pooling 20 Lastenausgleich 21 In-Memory-Datenbank 21 Warteschlangenkomponenten 21 Transaktionen 23 Rollenbasierte Sicherheit 24 Ereignisse Seitdem es Personal Computer gibt, besteht eines der wichtigsten Ziele der Industrie darin, immer leistungsfähigere Hardware für die CPU-hungrige Software zu entwickeln. Im Lauf der Zeit haben Unternehmen wie Intel ihre Prozessoren von 8 über 16 auf 32 Bit erweitert und die Taktgeschwindigkeit von 4,77 auf über 550 Megahertz (MHz) erhöht. Zur Zeit werden 64-Bit-Prozessoren mit einer noch höheren Taktgeschwindigkeit entwickelt. Die Entwicklungskosten eines neuen Prozessors sind allerdings so immens, dass sich nur die größten Unternehmen solche Ausgaben leisten können. Und eines Tages werden die hohen Entwicklungskosten vielleicht in keinem gesunden Verhältnis mehr zu den möglichen Verbesserungen stehen. Abgesehen von den besseren CPUs wurden viele Wege vorgeschlagen, um die allgemeine Verarbeitungsgeschwindigkeit zu verbessern. Bei diesen Initiativen stand das Konzept der Parallelverarbeitung an erster Stelle. Parallelverarbeitung besagt, dass in einer idealen Umgebung eine CPU x Arbeitsschritte in einem bestimmten Zeitraum erledigen kann und damit 10 CPUs im gleichen Zeitraum 10x Arbeitsschritte. Parallelverarbeitung kann auf zwei verschiedene Weisen implementiert werden: symmetrische Parallelverarbeitung oder kurz SMP (Symmetric MultiProcessing) und verteilte Datenverarbeitung. Verteilte Datenverarbeitung wird im X nächsten Abschnitt detailliert erläutert. SMP ist ein Design, in dem einige (oder einige hundert) CPUs in einem einzigen Computer arbeiten. SMP setzt voraus, dass das Betriebssystem des Hosts Multithreading unterstützt. Auf diese Weise können verschiedene Threads konkurrierend auf verschiedenen CPUs laufen. Die Implementierung von SMP erfordert besondere Software-Unterstützung. Windows 3

2 NT war beispielsweise eines der ersten Betriebssysteme für Personal Computer, das SMP unterstützte. Aktuelle Versionen von Windows 2000 können flexibel bis zu 16 Prozessoren unterstützen. Für unsere Zwecke definieren wir die verteilte Datenverarbeitung als ein System, in dem Computer miteinander verbunden sind, um CPU-Kapazitäten gemeinsam zu nutzen, und das sich den Anwendern wie ein einziger Computer darstellt. Diese Definition ist sehr vage, wenn exakt beschrieben werden soll, wie die Computer miteinander verbunden sind. Wenn Sie beispielsweise ein Dokument auf dem Farbdrucker ausdrucken möchten, der im Flur außerhalb Ihres Büros steht, könnten Sie die Datei auf eine Diskette kopieren, zu dem Computer gehen, an dem der Farbdrucker angeschlossen ist, die Diskette einlegen und das Dokument ausdrucken. Ist das ein Beispiel für verteilte Datenverarbeitung? Theoretisch gesehen ist es irrelevant, wie Computer genau miteinander verbunden sind. Es geht eher um den Datendurchsatz, den die Verkabelung bietet. Ein verteiltes System, in dem Computer durch Ethernet-Kabel mit einer Übertragungsleistung von 100 Megabits pro Sekunde in einem lokalen Netzwerk (LAN Locale Area Network) miteinander verbunden sind, bietet eine ganz andere Leistung als ein System, in dem Computer über ein 56-Kbps-Modem verbundenen sind. Bevor wir damit fortfahren, diese Definition zu erweitern, untersuchen wir zunächst ein realistisches, wenn auch hypothetisches, verteiltes System. Eine große Bank hat Niederlassungen in der ganzen Welt. Die Bank besaß ein großrechnerbasiertes Datenverarbeitungszentrum in ihrer Zentrale, und alle Niederlassungen waren mit Terminals ausgestattet, die mit dem Großrechner verbunden waren. (So weit haben wir ein Beispiel für ein zentralisiertes System, wobei alle Kontenund Kundeninformationen an einem einzigen Ort gespeichert werden.) Die Bank entschied, den Großrechner durch ein verteiltes System zu ersetzen. Jede Niederlassung besitzt nun einen Mastercomputer, der lokale Kontendaten speichert und lokale Transaktionen bearbeitet. Jeder dieser Computer ist über ein Global Area Network (GAN) mit allen anderen Computern der Niederlassungen verbunden. Wenn Transaktionen ausgeführt werden können, ungeachtet dessen, wo sich der Kunde befindet oder wo die Kontodaten des Kunden gespeichert werden, und wenn die Anwender keinen Unterschied zwischen dem neuen System und dem alten Großrechnersystem feststellen können, haben wir ein Beispiel für ein erfolgreiches verteiltes System. Was könnte der Auslöser dafür sein, dass die Bank das zentralisierte Großrechnersystem durch ein verteiltes System ersetzt? Die Betriebskosten sind der Hauptfaktor, der industrieweit eine Tendenz zugunsten verteilter Systeme auslöste. Für ein Unternehmen kann es ökonomischer sein, hunderte oder auch tausende von PCs zu kaufen und zu verwalten als einen einzigen Großrechner. Doch die Kosten allein sind nicht die Antwort. Ein gut entworfenes verteiltes System kann zu gleichen Kosten auch eine bessere Leistung bieten. Ein weiterer Faktor, der die Entscheidung der Bank, das zentralisierte System aufzugeben, beeinflusst haben könnte, ist die Erkenntnis, dass die Verarbeitungskapazität eines verteilten Systems die jedes Großrechners übertreffen kann. Die aktuellen Technologien erlauben ein Netzwerk aus 5000 Intel Pentium-basierten PCs, wobei jeder etwa 200 Millionen Anweisungen in der Sekunde (MIPS) ausführen kann, wodurch sich eine Gesamtleistung von MIPS ergibt. Sollte eine einzelne CPU eine solche Leistung erbringen, müsste sie alle Sekunden eine Anweisung ausführen. Auch wenn wir annehmen, dass sich Elektrizität mit Lichtgeschwindigkeit ( Kilometer pro Sekunde) ausbreiten würde, kann in Sekunden nur eine Distanz von 0,3 Millimetern zurückgelegt werden. Eine solch leistungsfähige CPU in einem Würfel von 0,3 Millimeter Seitenlänge zu bauen, wäre eine Meisterleistung des modernen Ingenieurwesens. Die Hitzeentwicklung dieser CPU wäre jedoch so immens, dass sie sofort zerbersten würde. 4 Kapitel 1

3 Zuverlässigkeit ist sowohl ein wichtiges Anliegen als auch ein Ziel jedes verteilten Systems. Ein gut entworfenes verteiltes System kann eine weit höhere Zuverlässigkeit als ein vergleichbares zentralisiertes System bieten. Wenn wir etwa davon ausgehen, dass ein bestimmtes zentralisiertes System eine Ausfallhäufigkeit von nur 2 Prozent besitzt, können die Anwender erwarten, dass dieses System 2 Prozent der Zeit heruntergefahren ist, und während dieser Ausfallzeiten kommt die gesamte Arbeit zum Erliegen. In einem verteilten System können wir davon ausgehen, dass jeder Knoten eine Ausfallhäufigkeit von 5 Prozent besitzt. (Die unterschiedlichen Ausfallhäufigkeiten sind auf die Tatsache zurückzuführen, dass die meisten Großrechner in besonders gekühlten, staubfreien Räumlichkeiten untergebracht sind und rund um die Uhr von geschultem Personal betreut werden, während PCs oft in Schränke eingeschlossen und dann vergessen werden.) Wenn zu jedem Zeitpunkt 5 Prozent der Rechner ausfallen, ergibt sich daraus eine Verringerung der Gesamtsystemleistung um 5 Prozent, nicht aber der Ausfall des gesamten Systems. Für kritische Anwendungen, wie etwa die Steuerung von Nuklearanlagen oder von Navigationssystemen von Raumschiffen, wo Zuverlässigkeit und Redundanz von großer Bedeutung sind, kann ein verteiltes System eine besonders hohe Zuverlässigkeit bieten. In der folgenden Formel steht P für die Wahrscheinlichkeit des Auftretens zweier voneinander unabhängiger Ereignisse A und B: P(A B) PA PB Die folgende Formel beschreibt den allgemeinen Fall: P c,n = c n 10-2n Pc,n ist die Wahrscheinlichkeit, dass alle Ereignisse gleichzeitig fehlschlagen, wenn es n voneinander abhängige Ereignisse gibt und jedes Ereignis eine Fehlerwahrscheinlichkeit von c Prozent besitzt. Auch bei einer Ausfallhäufigkeit von 5 Prozent je Knoten können die Anwender eines Systems mit 100 Knoten einen Systemausfall nur mit einer Wahrscheinlichkeit von Prozent erwarten. Dieser Fall ist also sehr extrem, da es unwahrscheinlich ist, dass alle 100 Computer gleichzeitig ausfallen. Wir verwenden die oben gezeigte Logik, um das Risiko des gleichzeitigen Ausfalls mehrerer Computer zu berechnen. Abbildung 1.1 zeigt die Wahrscheinlichkeit des gleichzeitigen Ausfalls von einem bis fünf Computern in einem System mit zehn Computern Ausfallrisiko Anzahl der Ausfälle Abbildung 1.1: Das Risiko des gleichzeitigen Ausfalls aller Rechner in einem System mit zehn Knoten Komponenten-Software 5

4 Verteilte Systeme müssen während der Ausbau- und Wartungsarbeiten nicht abgeschaltet werden. Mehrere Server können gleichzeitig abgeschaltet oder hinzugefügt werden, ohne die Anwender oder die Unternehmensabläufe zu stören. Zudem ist eine vernüftige und logischere Kapazitätsplanung möglich, da es nicht notwendig ist, zusätzliche Verarbeitungskapazitäten im Voraus zu kaufen. In den vergangenen Jahren wurde viel über die Migration von unternehmensweiten Systemen für das Two-Tier-Paradigma, das auch als Client-/Server-Modell bezeichnet wird, zu einer Three- Tier-Architektur geredet. Die zunehmende Popularität des Internet sowie das Aufkommen der Java-Programmiersprache und des Netzwerk-Computers haben das Interesse der Anwender an der Three-Tier-Systemarchitektur geweckt. Wir werden später in X diesem Kapitel einen Blick auf die Three-Tier-Lösung werfen und untersuchen, wie sich COM+ in diese Architektur eingliedert. Von der objektorientierten Programmierung zur Komponenten-Software Der Prozess der Software-Entwicklung hat sich über die Jahre hinweg nicht sonderlich geändert. Die meisten Software-Entwicklungen zeichnen sich durch Kosten- und Terminüberschreitungen aus, und die Ergebnisse sind oft fehlerbehaftet und nicht zu warten. Im Lauf der Jahre wurden eine Reihe verschiedener Paradigmen und Methodiken, von der Erstellung von Flussdiagrammen bis zur Objektorientierung, angeboten und gelegentlich über kürzere oder längere Zeiträume hinweg als Allheilmittel für die Probleme der Software-Entwicklung angesehen. Im Rückblick hat keine dieser angeblichen Lösungen die Erwartungen erfüllt, und für den Erfolg kleiner Gruppen, die jeweils zusammen an einem Projekt arbeiteten, konnte kein zuverlässiger Ersatz gefunden werden. Das soll nicht heißen, dass Flussdiagramme nicht nützlich oder objektorientierte Entwürfe fehlerhaft sind, sondern einfach nur, dass sie die Software-Entwicklung nicht auf eine Formel oder ein Rezept reduzieren, das Erfolg garantiert. Vielleicht sind diese Paradigmen überbewertet worden oder die Anwender der Methodiken haben zu viel erwartet. Zum heutigen Zeitpunkt hat man realisiert, dass die Software-Entwicklung von Natur aus schwierig und mit Problemen beladen ist, für die keine Patentlösungen existieren. Objektorientierte Programmierung Objektorientierte Programmierung ist eines der aktuelleren Paradigmen, das von der Software- Industrie schon relativ lange wohlwollend akzeptiert wird. Diese Akzeptanz drückt sich in der Popularität der objektorientierten Programmiersprachen aus, wie Ada, Smalltalk, Java und C++. Jede dieser Sprachen trägt die objektorientierte Fahne unterschiedlich hoch, abhängig von den ursprünglichen Fachgebieten der Designer, dem Problem, das sie lösen wollten, und den Beschränkungen, mit denen sie zu kämpfen hatten. C++ etwa nimmt einen pragmatischen Blickwinkel gegenüber der objektorientierten Programmierung ein, wobei die Ursache hierfür im Wesentlichen in dessen Wurzeln in C sowie den strengen Kompatibilitätserfordernissen dieser Sprache liegt. Visual Basic ist zwar nicht vollständig objektorientiert, doch objektorientierte Ideen haben das Design durchdrungen, und diese Sprache entwickelt sich immer mehr zu einer vollständig objektorientierten Sprache. Kurz gesagt, statt Programme zu entwickeln, die auf eine prozedurale und organisierte Weise die Logik eines Computers imitieren, liegt das Ziel der objektorientierten Programmiertechniken in der Vereinfachung der Programmierung und der Erhöhung der Effizienz, indem die Software- 6 Kapitel 1

5 Entwicklung die Denkweise von Menschen nachahmt. Objektorientierte Programmiermethoden erkennen, dass Software häufig versucht, Dinge (Objekte), mit denen wir jeden Tag arbeiten, in ein Modell zu fassen oder zu»virtualisieren«. Statt diese Objekte auf eine prozedurale Menge an Schritten zu reduzieren, die für die Ausführung einer Aufgabe nötig sind, erlauben objektorientierte Programmiersprachen dem Entwickler, die Existenz von Objekten schon im Quelltext besser auszudrücken. Es ist zu wünschen, dass dies zu aussagekräftigerem Quelltext führt, der einfacher zu entwickeln und kostengünstiger zu warten ist. Bei den meisten objektorientierten Programmiersprachen muss zwischen den Konzepten eines Objekts und einer Klasse unterschieden werden. Bei einer Klasse handelt es sich um eine Vorlage, die ihre Elemente definiert. Ein Objekt dagegen ist eine Instanz einer Klasse und kann etwas ausführen. Dieses Verhältnis wird im folgenden Beispiel vielleicht besser erläutert. Vergleichen Sie eine Plätzchenform mit einem Plätzchen. Eine Plätzchenform entspricht einer Vorlage (Klasse), die viele Attribute eines Plätzchens definiert, etwa Form und Größe. Ein Plätzchen dagegen entspricht einem Objekt, da es auf der Basis einer Plätzchenform entsteht. (Allerdings erfüllen Plätzchen keine andere Aufgabe, abgesehen von der, gut zu schmecken.) Das objektorientierte Paradigma umfasst drei Hauptkonzepte, die von einer objektorientierten Programmiersprache unterstützt werden müssen: b Kapselung: Das Verbergen der Implementierungsdetails eines Objekts. b Vererbung: Die Fähigkeit, bestehende Objekte bei der Erstellung neuer, stärker spezialisierter Objekte wiederzuverwenden. b Polymorphie: Die Fähigkeit des Codes, abhängig vom verwendeten Objekt unterschiedliche Verhaltensweisen zu zeigen. Gemeinsame Verwendung und Wiederverwendung von Code Objektorientierte Programmierung ist vor allem deswegen so populär geworden, weil sie den Entwicklern verspricht, dass sie in ganz unterschiedlichen Projekten den gleichen Code gemeinsam verwenden können. Wie schon angemerkt, werden gleiche Algorithmen und ähnlicher Code immer wieder neu entwickelt, wodurch unglaublich viel Zeit, Mühe und Geld verschwendet wird. Die gemeinsame Verwendung und Wiederverwendung von Code wird als größter Vorteil eines gut implementierten objektorientierten Designs angesehen. Tatsächlich ist der Prozentsatz des Codes, der wirklich gemeinsam genutzt wird, noch ziemlich gering. Bis vor kurzem besaßen sogar Anwendungen in Programmpaketen wie Microsoft Office jeweils eigenen Code für die Implementierung von Standardeigenschaften wie Symbolleisten, Statusleisten und Rechtschreibprüfungen. Viele dieser standardisierten Steuerelemente der grafischen Benutzeroberfläche oder GUI (Graphical User Interface) wurden in aktuelle Versionen von Windows integriert und können von allen Anwendungen gemeinsam genutzt werden. Wenn Sie darüber nachdenken, ist ein Betriebssystem ein gutes (wenn auch nicht besonders flexibles) Beispiel für die Wiederverwendung von Code. Die Wiederverwendung von Code scheint zu den Dingen zu gehören, von denen jeder erwartete, dass sie sich spontan ergeben würden. Dies hat sich als Wunschdenken erwiesen, da die Wiederverwendung von Code gut geplant und die Auswirkungen sorgfältig durchdacht werden müssen. Wenn Sie Code schreiben und ihn dann an Freunde weitergeben, ist das Wiederverwendung von Code? Wie steht es mit Codebibliotheken, die Programmierer in ihre Anwendungen einbinden? Dies sind Beispiele für die Wiederverwendung von Code, doch jedes hat seine Probleme. Wenn Sie Ihren Code an Ihre Freunde weitergeben und diese einiges daran nicht mögen, können sie den Quelltext ändern. Ein solches Herumbasteln ist nicht mit der Idee der Wiederverwendung Komponenten-Software 7

6 von Code vereinbar. Änderungen am Quelltext eines anderen vorzunehmen, lässt sich mit dem Umstoßen einer Figur in einem Porzellanladen vergleichen: der unglückselige Einkaufsbummler wird zum stolzen Besitzer. Wenn irgend etwas nicht korrekt arbeitet, nachdem jemand Ihren Code geändert hat, sind Sie nicht gezwungen, den Code weiterhin zu unterstützen. Falls Sie Ihren Code später aktualisieren und eine neue Version veröffentlichen, müssen Ihre Freunde außerdem erneut den Code durchforsten und die eigenen Änderungen nochmals eintragen. Der Code ist danach offenkundig nicht wiederverwendbar. Wenn Sie eine Klassenbibliothek kaufen und deren Arbeitsweise nicht mögen, haben Sie Pech gehabt, außer Sie kaufen auch den Quelltext und ändern ihn, aber damit haben wir wieder das oben erwähnte Problem. Um die Wiederverwendung von Code besser zu verstehen, ist eine solidere Definition vonnöten: Wahre Wiederverwendung von Code ist die Fähigkeit, möglichst allgemein gehaltenen Code in Ihrer Software einzusetzen, um damit ein größeres Ganzes zu schaffen, trotzdem aber in der Lage zu sein, Arbeitsweise und Zweck des Codes anzupassen. Ein weiteres Problem der meisten Typen von Codewiederverwendung besteht darin, dass normalerweise die ursprünglichen Software-Entwickler sowie die Person, die den Code wiederverwenden möchte, in der gleichen Programmiersprache arbeiten müssen. Wenn eine Klassenbibliothek beispielsweise in C++ geschrieben ist, ist es fast unmöglich, diesen Code in einer Anwendung einzusetzen, die nicht in C++ geschrieben ist. Aus dem gleichen Grund kann eine Java-Klasse nur in einem Java-Programm verwendet werden. Obwohl die Wiederverwendung von Code erleichtert wird, wenn Sie mit einer objektorientierten Programmiersprache statt mit einer anderen Sprache arbeiten, gibt es auch hier Einschränkungen. Wie können wir die gemeinsame Verwendung und die Wiederverwendung von Code, die allgemein als erstrebenswert angesehen wird, in der praktischen Programmierung einsetzen? Die objektorientierte Programmierung wird schon lange als Problemlösung angepriesen. Dieses Versprechen muss sie nun erfüllen. Komponenten-Software Die Aufteilung eines Projekts in seine logischen Komponenten ist die Essenz von objektorientierter Analyse und objektorientiertem Design. Dies ist auch die Basis für Componentware, also aus einzelnen Teilen zusammengesetzter Software. Eine Komponente ist ein wieder verwendbares Stück Software in binärer Form (im Gegensatz zu Quelltext), das mit relativ geringem Aufwand in andere Komponenten von anderen Herstellern aufgenommen werden kann. Es ist wichtig zu realisieren, dass es sich bei COM nicht um einen vorgeschriebenen Weg handelt, wie eine Anwendung zu strukturieren ist. COM ist vielmehr eine Spezifikation, welche die Programmierung, die Verwendung und die unabhängige Entwicklung binärer Objekte ermöglicht. Diese Objekte sind unabhängig von der Anwendung, die sie verwendet, und von den Programmiersprachen, in denen die Objekte selbst geschrieben sind. Software-Komponenten können in verschiedene Kategorien unterteilt werden. Dazu gehören visuelle Komponenten, wie Schaltflächen oder Listenfelder, oder funktionale Komponenten, die Ausdrucke oder Rechtschreibprüfungen ermöglichen. Eine komponentenbasierte Architektur könnte beispielsweise dazu führen, dass die Rechtschreibprüfung eines Herstellers in verschiedenen Textverarbeitungsprogrammen anderer Hersteller eingesetzt wird. Diese Fähigkeit kann dem Verbraucher viele Vorteile bieten. Sie lieben vielleicht die Textverarbeitung der Firma A, verabscheuen aber die Rechtschreibprüfung, die mit diesem Produkt ausgeliefert wird. Sie kaufen also eine Rechtschreibprüfung, mit der Sie gerne arbeiten, von der Firma B, die sich auf die Entwicklung solcher Programme spezialisiert hat. Diese Fähigkeit erlaubt es den Software-Entwicklern, sich auf ihre besonderen Stärken zu konzentrieren. 8 Kapitel 1

7 Eine gute Analogie bietet die Automobilindustrie. Viele Autohersteller kaufen einzelne Autoteile, wie Motoren und Getriebe, von verschiedenen Subunternehmen und bauen ihre Autos aus diesen Komponenten zusammen. Der springende Punkt ist hier, dass die Teile so verwendet werden können, wie sie sind; sie müssen nicht neu übersetzt werden, der Quelltext muss nicht vorliegen, und Sie sind nicht auf eine Programmiersprache beschränkt. Der Terminus für diesen Prozess lautet binäre Wiederverwendung, da er auf binären Schnittstellen statt auf einer Wiederverwendung auf Quelltextebene basiert. Während sich die Software-Komponenten an die vereinbarte Schnittstelle halten müssen, ist ihre interne Implementierung vollkommen autonom. Aus diesem Grund können die Komponenten sowohl mit prozeduralen als auch mit objektorientierten Sprachen erstellt werden. Eines der Hauptziele des komponentenbasierten Programmiermodells ist die Förderung der Interoperabilität. Interoperabilität ist eines jener Schlagwörter im EDV-Bereich, das für jeden eine andere Bedeutung hat. Bezogen auf Komponenten-Software ist Interoperabilität die Fähigkeit der Zusammenarbeit von Komponenten. Wenn Sie ein Projekt untersuchen und Bereiche entdecken, in denen die Software auf eine unnatürliche Art zusammengepresst scheint, sollten Sie die Applikation in Komponenten aufteilen. Wir werden hier das Beispiel der Steuerelemente verwenden. In der guten alten Zeit der Windows-basierten Programmierung schrieben Sie Elemente für Ihre Anwendung, wenn Sie sie benötigten. Wenn in Ihrem Programm eine Symbolleiste fehlte, haben Sie den Code dafür einfach in Ihre Anwendung aufgenommen. Diesem Beispiel sind zwei Probleme eigen: Zunächst ist es nicht Ihr Ziel, eine Symbolleiste zu erstellen, sondern eine großartige Anwendung, die eine Symbolleiste besitzt. Außerdem würde vielleicht jemand in Ihrem Unternehmen diese Symbolleiste, an der Sie viele kostbare Stunden gearbeitet haben, gerne in einem anderen Projekt einsetzen. Wie soll das möglich sein, wenn der Symbolleistencode über Ihr gesamtes Programm verstreut ist und auf Nachrichten wie WM_CREATE, WM_PAINT und WM_LBUTTONDOWN reagiert? Eine komponentenbasierte Lösung dieses Problems würde darin bestehen, die Symbolleiste als eine separate Komponente zu programmieren. Daraus ergibt sich jedoch ein weiteres Problem. Wie sollen die Symbolleistenkomponente und unsere Anwendung zusammenarbeiten? Es ist also ein Problem der Interoperabilität. Das Komponenten-Software-Paradigma verlangt, dass alle Komponenten eine Schnittstelle definieren, die die Funktionalität der Komponenten offen legt. Solange die Komponente die Schnittstelle implementiert und die Client-Applikation über die Schnittstelle auf die Komponente zugreift, ist die Interoperabilität gegeben. Im Symbolleistenbeispiel können sich die Anwendungsprogrammierer nun auf die Software konzentrieren und die Symbolleistenkomponente einfach von einem anderen Entwickler kaufen, der sich auf Symbolleisten spezialisiert hat. Dadurch wird Zeit für Entwicklung, Test und Wartung gespart. In der Software-Welt gibt es kein besseres Beispiel für die Auswirkung von Komponenten als das der ActiveX-Steuerelemente. Ein ActiveX-Steuerelement ist eine COM+-Komponente, die gewöhnlich auf einem Formular angeordnet wird. Dort kann es mit den Anwendern interagieren. Der Anwender hat gewöhnlich den Eindruck, das ActiveX-Steuerelement und das Formular seien eine einzelne Applikation. Dies ist auch dann der Fall, wenn die beiden Software-Teile unabhängig voneinander und vielleicht in unterschiedlichen Programmiersprachen entwickelt wurden. Das Steuerelement und das Formular arbeiten über Schnittstellen zusammen. Das Formular fragt das Steuerelement ab, um zu erfahren, welche Schnittstellen es unterstützt. Das Steuerelement führt die gleiche Abfrage für das Formular aus. Sie können die objektorientierten Programmierkonzepte in Verbindung mit einer komponentenbasierten Lösung verwenden, um flexible und leistungsfähige Objekte zu erstellen, die problemlos von anderen Entwicklern wiederverwendet werden können. Komponenten-Software 9

8 Ein wichtiges Prinzip der objektorientierten Programmierung, das bereits erwähnt wurde, ist die Kapselung. Die Kapselung verbirgt die Implementierung eines Objekts vor den Benutzern des Objekts. Die Benutzer eines Objekts haben nur auf die Schnittstelle des Objekts Zugriff. Entwickler, die fertige Objekte in ihren Projekten einsetzen, sind nur am»vertrag«interessiert, also dem zugesagten Verhalten, das vom Objekt unterstützt wird. Die Komponenten-Software formalisiert die Idee eines Vertrags zwischen einem Objekt und einem Client. Jedes Objekt zeigt an, wozu es fähig ist, indem es verschiedene Schnittstellen implementiert. Die einzige Möglichkeit, auf die Dienste eines Objekts zuzugreifen, besteht darin, dessen Schnittstelle zu verwenden. Ein solcher Vertrag ist die Basis für Interoperabilität. Schnittstellen Eine Schnittstelle ist tatsächlich etwas sehr Einfaches, nämlich eine definierte Menge von Funktionen, die unter einem Namen zusammengefasst sind. Vorerst wollen wir mit dieser vereinfachten Schnittstellendefinition arbeiten. Beispielsweise ist die Win32 API eine Schnittstelle zur Funktionalität des Betriebssystems Windows. Mit Komponenten-Software kann nicht nur ein Betriebssystem eine Schnittstelle zur Verfügung stellen, sondern auch die von Entwicklern erstellten Software-Komponenten. Eine Schnittstelle ist ein streng typisierter Vertrag zwischen einer Software-Komponente und einem Client. Sie ist ein Ausdruck für das erwartete Verhalten und die erwarteten Verantwortlichkeiten und gibt Programmierern und Designern ein konkretes Gebilde an die Hand, das in Bezug auf die Komponente zum Einsatz kommt. Zwei Objekte, die dieselbe Schnittstelle implementieren, sind polymorph. Obwohl es keine strikte Anforderung des Modells ist, sollten Schnittstellen so in Faktoren zerlegt werden, dass sie in vielerlei Kontexten wiederverwendet werden können. Die Entwicklung von COM+ Wie die meisten Microsoft-Technologien ist auch COM+ nicht über Nacht von einem koffeinabhängigen Entwickler erfunden worden. COM+ ist statt dessen eine Verschmelzung unterschiedlicher Pfade der technologischen Entwicklung (siehe Abbildung 1.2). Damit Sie die Grundlagen von COM+ besser verstehen, müssen Sie sich zunächst mit den Technologien befassen, aus denen sich COM+ entwickelt hat. Von OLE zu COM+ Microsofts Betriebssystem MS-DOS ist für einen nach heutigen Standards sehr leistungsschwachen Computer entwickelt worden und ließ nur die Ausführung einer einzigen Anwendung zu einem Zeitpunkt zu. Als Intel leistungsfähigere Prozessoren wie den und den entwisdf 10 Kapitel 1

9 Clipboard 1987 Distributed computing 80'er Jahre OLE 1992 OSF DCE RPC für Windows 1992 COM 1995 Distributed COM 1996 Microsoft Distributed Transaction Coordinator 1996 Microsoft Transaction Server 1997 Microsoft Message Queue Server 1997 COM Abbildung 1.2: Die Entwicklung von COM+ ckelte, begann Microsoft, die grenzenlosen Möglichkeiten der gleichzeitigen Ausführung von Anwendungen ins Auge zu fassen. Nach der Einführung der kooperativen Multitasking-Umgebung Microsoft Windows stellte Microsoft fest, dass die Anwender Daten zwischen den verschiedenen Anwendungen austauschen wollten. Die Zwischenablage und DDE (Dynamic Data Exchange) gehörten zu den ersten Interprozess-Kommunikationsmöglichkeiten von Windows. Bei DDE handelte es sich um einen Dienst zum Austausch von Daten und Befehlen, der von Entwicklern verwendet wurde, um eine Möglichkeit zum Datenaustausch in ihre Anwendungen einzubauen. Allerdings war DDE ein sehr komplexes Protokoll, und daher ist es außer in Microsoft Excel nur in sehr wenigen Anwendungen erfolgreich implementiert worden. Die Zwischenablage bot den Anwendern die einfachen und leicht verständlichen Operationen Ausschneiden, Kopieren und Einfügen. Die Zwischenablage konnte zur Erstellung von Verbunddokumenten eingesetzt werden. Der Begriff Verbunddokument beschreibt ein Dokument, das verschiedene Typen von Inhalten umfasst. Das Textverarbeitungsdokument eines Anwenders kann etwa Text, Bitmaps, Diagramme und Audiodateien enthalten. Stellen Sie sich vor, Sie hät- Komponenten-Software 11

10 ten im Jahr 1992 den Jahresbericht Ihres Unternehmens mit einer der ersten Versionen von Microsoft Word für Windows erstellen wollen. Zunächst hätten Sie wahrscheinlich den Text verfasst, der das Unternehmen und dessen Entwicklung im vergangenen Jahr beschreibt. Dann hätten Sie Excel geladen, um ein Arbeitsblatt mit Zahlen über die Ergebnisse Ihres Unternehmens zu erstellen. Zuletzt hätten Sie einige Zellen im Arbeitsblatt markiert, in die Zwischenablage kopiert und dann in Ihr Word-Dokument eingefügt. Ohne Zwischenablage wäre es nötig gewesen, das Word-Dokument und das Excel-Arbeitsblatt separat auszudrucken und beide mit Hilfe von Schere und Kleber auszuschneiden und zusammenzufügen. Die Tatsache, dass der Zwischenablagedienst sowohl für die Entwickler einfach zu implementieren als auch für die Anwender einfach zu steuern war, führte dazu, dass er in den meisten Anwendungen erfolgreich eingesetzt wurde. Auch in den heutigen Windows-Anwendungen erfreut sich der Dienst ungebrochener Beliebtheit. Allerdings wurden auch die Unzulänglichkeiten der Zwischenablage schnell augenfällig. Das grundlegende Problem der Zwischenablage als Werkzeug für die Erstellung von Verbundokumenten bestand darin, dass es dem Datenübertragungsmechanismus vollkommen an Intelligenz mangelte. Wenn Sie beispielsweise nach der Erstellung des Jahresberichts Ihres Unternehmens festgestellt hätten, dass einige Zahlen im Excel-Arbeitsblatt aktualisiert werden müssen, hätten Sie die aktualisierten Zahlen erneut markieren, kopieren und in Ihr Word-Dokument einfügen müssen. Das ursprüngliche Konzept von OLE (Object Linking and Embedding) resultierte aus dem Bemühen der Anwendungsabteilung von Microsoft, dieses Problem zu beheben. OLE wurde erstmals im Jahr 1992 mit Microsoft Windows 3.1 ausgeliefert. Mit OLE 1 verfolgte man das Ziel, einen verbesserten Mechanismus für die Arbeit mit Verbunddokumenten anzubieten. So konnten diese intelligenten Verbunddokumente die Daten des Excel-Arbeitsblattes in das Word-Dokument einbetten oder sie damit verknüpfen. Wann immer verknüpfte Zahlen im Arbeitsblatt aktualisiert wurden, fanden die neuen Daten automatisch ihren Weg in das Word-Dokument. Außerdem war es möglich, die verknüpften oder eingebetteten Zahlen in Excel zu öffnen und zu bearbeiten, indem der Anwender in Word darauf doppelklickte. Diese Fähigkeit war ein Segen für die Anwender, wenn auch nur wenige verstanden, wie es funktionierte. Tatsächlich wurde DDE intern von der ersten OLE-Version als Interprozess-Kommunikationsprotokoll verwendet. OLE umfasste einige hochinteressante Ideen, vor allem aber, dass Objekte für Verbunddokumente, die von verschiedenen Anwendungen unterstützt wurden, zur Erstellung einer Art von»superdokument«zusammenarbeiten konnten. Die OLE-Entwickler verfeinerten ihre Ideen und weiteten sie aus, bis sich irgendwann ihr Blickwinkel änderte und sie begannen, diese Verbunddokumentobjekte als Software-Komponenten zu betrachten kleine, unabhängige Software-Objekte, die in eine Anwendung eingefügt werden konnten und so deren Funktionalität erweiterten. Mit dem Erscheinen von OLE 2 im Jahr 1993 wurden die Verknüpfungs- und Einbettungsfähigkeiten von OLE weiter verfeinert und die Einrichtungen zum Verknüpfen und Einbetten durch die direkte oder In-Place-Aktivierung erweitert. Direkte Aktivierung, gelegentlich auch visuelle oder direkte Bearbeitung genannt, erlaubt einer Anwendung, das Erscheinungsbild einer anderen Anwendung anzunehmen. Es ermöglicht damit dem Anwender, alle Daten in einem Verbunddokument zu bearbeiten, ohne den Kontext eines einzigen Fensters zu verlassen. Damals und noch lange danach realisierte kaum ein Entwickler, dass die Architektur von OLE 2 auf der revolutionären Idee der komponentenbasierten Software aufbaute. Langfristig gesehen, stellte sich diese Tatsache als der bei weitem wichtigste Beitrag von OLE 2 heraus. Im Lauf der Jahre ist OLE in den Hintergrund getreten und COM in den Blickpunkt gerückt. Dem Design der meisten Software-Projekte liegt immer noch der Gedanke zu Grunde, ein Ungetüm zu produzieren, das alle Funktionen umfasst, die sich ein Anwender je wünschen könnte. An diesem Software-Entwicklungsmodell ist problematisch, dass Anwendungen mit zunehmender 12 Kapitel 1

11 Größe auch zerbrechlicher werden. Es ist schwierig, eine Anwendung zu verstehen, die Codezeilen umfasst, doch bei Anwendungen mit Zeilen ist es unmöglich. Auch eine kleine Änderung in einer Anwendung dieser Größenordnung erfordert extensive Tests des gesamten Systems. Oft kann eine harmlos erscheinende Änderung in einem Bereich in vielen anderen Bereichen Schaden anrichten. COM fungiert als»kleber«zwischen den Komponenten, so dass Software-Objekte, die nicht zueinander in Beziehung stehen, untereinander eine Verbindung herstellen und sinnvoll zusammenarbeiten können. Diese Komponenten können dann in vielen Umgebungen sowohl auf der Client- als auch auf der Server-Seite wieder verwendet werden. Eine bestimmte Geschäftskomponente kann beispielsweise von einer Arbeitsplatzanwendung als auch von einer Web-Anwendung, die auf dem Microsoft Internet Information Server (IIS) läuft, eingesetzt werden. COM lässt Sie Objekte in bestimmte Komponenten gruppieren, so dass Ihre Applikation aus ersetzbaren Teilen besteht, die eine bestimmte Funktionalität zur Verfügung stellen. Die Erstellung eines Systems, das auf zusammenarbeitenden Komponenten basiert, heißt nicht, dass dem Anwender auf dem Desktop kein Symbol mehr zur Verfügung steht, mit dem er die Anwendung starten kann. Lassen Sie uns als Beispiel die Architektur des Microsoft Internet Explorer näher betrachten. Die Shell ist ein einfacher ActiveX-Dokument-Host, und die eigentliche Interpretation und Bildschirmdarstellung des HTML-Codes wird von einer ActiveX-Dokumentkomponente ausgeführt, die geladen wird, sobald der Anwender zu einer Website wechselt. Wenn diese Website ein ActiveX-Steuerelement enthält, wird das Steuerelement heruntergeladen und installiert. Diese COM-basierte Architektur bewirkt, dass sich jeder Teil der Shell auf eine bestimmte Aufgabe konzentriert. Verschiedene Teams, die mit unterschiedlichen Programmiersprachen arbeiten, können Komponenten entwickeln, und solange sich jeder an die Regeln von COM hält, passt alles nahtlos zusammen. Damit die Gründe für die Entstehung von COM deutlicher werden, sehen wir uns zunächst einige der Herausforderungen der Software-Industrie an, die Microsoft zur Entwicklung von COM veranlassten. Wie jeder weiß, hat die fortwährende Evolution der Computerhardware und -software den Arbeitsplätzen der Anwender und den Netzwerken eine stetig ansteigende Zahl von ausgeklügelten Anwendungen beschert. Diese komplexe Software brachte sowohl für die Entwickler als auch für die Anwender eine entsprechende Menge an Problemen mit sich, wie es in der COM-Spezifikation beschrieben wird: b Moderne Software-Anwendungen sind groß und komplex. Ihre Entwicklung ist langwierig; sie sind schwierig und teuer zu warten, und Erweiterungen durch zusätzliche Funktionalität sind riskant. b Anwendungen werden noch immer als monolithische Einheiten entwickelt. Sie werden mit im vorhinein festgelegten, statischen Eigenschaften ausgeliefert, und Eigenschaften können weder hinzugefügt noch entfernt, unabhängig aktualisiert oder durch Alternativen ersetzt werden. b Anwendungen lassen sich kaum integrieren; weder die Daten noch die Funktionalität eines Programms stehen anderen Programmen zur Verfügung. b Programmiermodelle reflektieren die Herkunft des Dienstleisters; sie variieren sehr stark, abhängig davon, ob der Dienst von jemandem bereitgestellt wird, der sich im gleichen Adressraum, in einem anderen Adressraum auf dem gleichen Rechner, auf einem anderen Rechner im Netzwerk oder im Betriebssystem befindet. Wird COM alle diese Probleme lösen können? Wie die Natur der hier beschriebenen Problemstellungen nahelegt, kann keine Software allein diese Probleme lösen. Doch Sie werden in den nächsten Abschnitten sehen, dass Software, die auf der Basis einer COM-Architektur erstellt Komponenten-Software 13

12 wird, diesen Herausforderungen eher gewachsen ist. COM+ wiederum hat sich aus einer Kombination des klassischen COM und des Microsoft Transaction Server (MTS) entwickelt, wie später in X diesem Kapitel beschrieben wird 1. Seit seiner Einführung verkörpert COM+ den Höhepunkt einer langen Evolution von Ideen, die mit OLE begannen. RPC und COM+ Die Anfänge von COM+ gehen bis in die 80er Jahre zurück. In diesen Zeiten war es ein echter Fortschritt, wenn man einfach einige Computer über ein lokales Netzwerk miteinander verband. Damit der Personal Computer tatsächlich an die Macht kommen konnte, musste ein verteiltes Unterstützungssystem analog zu dem eines zentralisierten Betriebssystems geschaffen werden. Allerdings führte dieser Ansatz erst dann zum Erfolg, als die großen Unternehmen bei der Entwicklung neuer Standards zusammenarbeiteten. In der Welt der Großrechner waren Standards kein Thema. Software wurde für eine bestimmte Hardware geschrieben und von den IBM-Computern erwartete niemand, dass sie mit Computern anderer Firmen kommunizieren konnten. In den späten 80ern unternahmen verschiedene Gruppen der Industrie Versuche, sich mit anderen Unternehmen auf Standards zu einigen und diese dann als verbindlich zu erklären. Eine dieser Gruppen, die Open Software Foundation (OSF), wurde zu einem industrieweiten Konsortium mit dem Auftrag, Standards für viele Bereiche zu definieren. Die Mitglieder der OSF beschäftigten sich mit verteilter Datenverarbeitung. Aus diesen Bemühungen heraus stammen die Spezifikationen für Distributed Computing Environments (DCE). Es war das allgemeine Ziel von DCE, eine Umgebung für die Erstellung verteilter Systeme bereitzustellen. Zu diesem Zweck begann DCE mit der Sammlung umfassender integrierter Werkzeuge und Dienste, welche die Erstellung verteilter Anwendungen unterstützten, analog zur Unterstützung des Betriebssystems in einer zentralisierten Umgebung. Ein Ergebnis von Distributed Computing Environment (DCE) war eine Spezifikation der Kommunikation zwischen Computern. Diese Spezifikation, bekannt unter der Bezeichnung Remote Procedure Calls (RPC oder Fernprozeduraufrufe), erlaubt die Kommunikation zwischen Anwendungen, die auf verschiedenen Computern ausgeführt wurden. COM+ verwendet RPCs für die Kommunikation zwischen den Computern. Von COM zu COM+ COM+ umfasst gegenwärtig zwei Funktionsbereiche: eine grundlegende Programmierarchitektur (die zuerst von der ursprünglichen COM-Spezifikation definiert wurde) zum Erstellen von Software-Komponenten sowie eine integrierte Sammlung von Komponentendiensten mit einer entsprechenden Laufzeitumgebung zum Erstellen von hochentwickelten Software-Komponenten. Komponenten, die innerhalb dieser Umgebung arbeiten, werden als konfigurierte Komponenten bezeichnet. Sie befolgen die Standardregeln von COM. Sie können das COM+-Programmiermodell ohne die Komponentendienste und das Laufzeitmodell nutzen. COM+ offenbart jedoch erst dann seine geballte Leistung, wenn diese beiden Bestandteile zusammen eingesetzt werden. Die COM+-Programmierarchitektur stellt ein Modell zum Erstellen von Komponenten-Software zur Verfügung. Für die meisten Entwickler ist dieses Modell jedoch unzureichend. In einem typi- 1 Mit der Veröffentlichung von Windows NT 4.0 im Jahr 1996 erhielt COM die Funktionalität zum Ausführen von Komponenten, die sich auf entfernten, über ein Netzwerk miteinander verbundenen Computern befanden. Diese Technologie wurde zunächst Distributed COM genannt und ist nun ein wesentlicher Bestandteil von COM+. 14 Kapitel 1

13 schen Unternehmen erstellen Entwickler gewöhnlich Geschäftskomponenten, die als ein Teil einer größeren Applikation arbeiten. Sie verwenden dazu häufig eine Client-/Server- oder Three- Tier-Lösung. Entwickler erstellen sogar einfache Komponenten mit einem enormen Aufwand. Selbst wenn die Ziele einer Geschäftskomponente relativ bescheiden sind, müssen die Entwickler eine robuste und sichere Umgebung für die Komponente schaffen. Wenn viele Clients gleichzeitig auf die Komponente zugreifen möchten, müssen die Entwickler sicherstellen, dass ausschließlich Clients mit einer entsprechenden Berechtigung bestimmte privilegierte Operationen auf der Komponente ausführen können. Die Skalierbarkeit ist ein weiterer Aspekt, der berücksichtigt werden muss, wenn eine große Anzahl unterschiedlicher Clients versucht, auf eine Komponente zuzugreifen. Große Systeme sollten Client-Fehler während komplexer Operationen, in die ein Datenbankserver involviert ist, generell erwarten. Der Client könnte beispielsweise Daten lokal speichern und anschließend eine Datenaktualisierung auf dem Datenbankserver vornehmen, die auf einigen lokalen Informationen basiert. Wenn der Client während dieser Operation einen Fehler verursacht, können Sie sich der Integrität der Datenbank nicht mehr sicher sein, sofern Sie kein Transaktionsprotokoll implementiert haben. Wenn die interne Datenstruktur der Komponente schließlich beschädigt wird, muss dies ermittelt werden, bevor die Integriät der Datenbank selbst gefährdet ist. An diesem Beispiel erkennen Sie, dass ein wesentliches Problem des Grundmodells für die Komponenten-Software darin besteht, dass Entwickler eigenständig sehr viel Funktionalität implementieren müssen. Dabei handelt es sich um Funktionalität, die wenig mit den eigentlichen Zielen der Applikation zu tun hat. Microsoft hat realisiert, dass das Schreiben robuster server-seitiger Systeme intensive Arbeit erfordert. Themen wie Threading, Konkurrenz, Sicherheit und Administration, Stabilität und dergleichen sind für jedes verteilte System entscheidend. Das Entwickeln von Software, die diese Features nahtlos integriert, erfordert einen enormen Aufwand. Dieser Aufwand steht in keinem Verhältnis zu der Verarbeitung, die von dem System zum aktuellen Zeitpunkt durchgeführt wird. Microsoft SQL Server ist zum Beispiel ein Datenbankserver, der all diese Features verwendet und gleichzeitig SQL-Abfragen bearbeitet. Microsoft hat diese Erkentnis genutzt, um den Microsoft Transaction Server (MTS) zu entwickeln. Der MTS ist die erste auf Windows basierende Implementierung einer Laufzeitumgebung, welche die genannten Dienste für Software-Komponenten anbietet. Die Laufzeitumgebung und die Komponentendienste, die von COM+ zur Verfügung gestellt werden, wurden aus Ideen entwickelt, die vom MTS stammen. COM+ stellt eine robuste Laufzeitumgebung zur Verfügung, welche die meisten Probleme berücksichtigt, mit denen Entwickler von server-seitigen Systemen konfrontiert werden. COM+ ermöglicht die einfache Entwicklung von prozessinternen COM+- Komponenten, die die eigentliche geschäftsbezogene Funktionalität enthalten. Wenngleich alle prozessinternen COM+-Komponenten in der COM+-Laufzeitumgebung ausgeführt werden können, sind sie hierfür nicht speziell entwickelt worden. Ausführbare Komponenten können zum Beispiel nicht alle Dienste nutzen, die von COM+ angeboten werden. Die fundamentale Architektur von COM+ verursacht nur wenig Rechenaufwand. Microsoft hat jedoch erkannt, dass viele Entwickler angepasster Unternehmensapplikationen von einem Standardsatz verschiedener Applikationsdienste profitieren könnten. Entwickler werden während des Erstellens von Geschäftsapplikationen beispielsweise häufig mit immer wiederkehrenden Problemen konfrontiert, wie zum Beispiel der Sicherheit, Stabilität, Konkurrenz und Skalierbarkeit. COM+ zwingt Entwickler nicht dazu, für jede Applikation eigene Lösungen dieser Probleme zu erarbeiten. Stattdessen bietet es integrierte Dienste für Komponenten zur Laufzeit an. Doch nicht alle Komponenten benötigen diese Dienste. Programmierer, die Applikationen mit einem Komponenten-Software 15

14 sehr hohen Performance-Anspruch entwickeln, verzichten wegen des Rechenaufwands zur Laufzeit darauf. In vielen Standardapplikationen sind die Dienste jedoch sowohl für den Entwickler als auch für die Stabilität des gesamten Projekts äußerst wertvoll. Windows-DNA: ein Three-Tier-Zugang Viele neue Unternehmens-Informationssysteme werden für den Einsatz unter Windows 2000 entwickelt. Um Entwicklern die Vorzüge der Windows 2000-Applikationsdienste nahe zu bringen, hat Microsoft den Begriff Windows-DNA geprägt. Dies ist die Abkürzung für Distributed inter- Net Applications Architecture. Windows DNA ist das Applikationsentwicklungsmodell für die Windows-Plattform. Es bietet eine Three-Tier-Architektur an, die auf COM+ basiert, wie in Abbildung 1.3 dargestellt. Da Windows DNA umfassende und integrierte Dienste für die Windows- Plattform anbietet, sind die Entwickler von der Bürde befreit, die erforderliche Infrastruktur für verteilte Applikationen selbst zu erzeugen oder zusammenzustellen. Sie können sich somit darauf konzentrieren, die benötigten Geschäftslösungen zu liefern. Das Ziel dieser Three-Tier- Lösung besteht darin, die Geschäftslogik vom Client-/Server-System zu trennen, indem sie auf eine mittlere Stufe verlagert wird, die unter Windows 2000 läuft. Die sich daraus ergebende Three-Tier-Architektur besteht aus einer Präsentationsschicht, den Geschäftslogik-Komponenten und der Schicht mit den Datendiensten. Hilfsmittel Schlanker Client Datenbanken Alte Systeme Client Firewall Externe Applikationen Präsentation Geschäftslogik Daten Systemdienste Abbildung 1.3: Die Windows-DNA-Architektur Präsentation Die Client-Seite eines Client-/Server-Systems umfasst gewöhnlich die Funktionalität der Benutzeroberfläche und der Geschäftslogik, die das System steuert. Lediglich die Datenbank befindet sich auf der Server-Seite. Dieses Design führt zu client-seitig ausgelasteten Applikationen, die an ein bestimmtes Betriebssystem gebunden sind und nur schwierig eingesetzt und unterstützt werden können. In einer Three-Tier-Architektur wird der Client weniger stark belastet. In der Regel verwaltet der Client hier lediglich die Benutzeroberfläche. Solch ein "schlanker" Client kann 16 Kapitel 1

15 zum Beispiel aus Formularen, die mit Visual Basic entworfen wurden, oder lediglich aus HTML- Seiten bestehen, die für die Darstellung in einem Web-Browser wie zum Beispiel dem Internet Explorer entwickelt wurden. Das Entwickeln von client-seitigen Applikationen, die ausschließlich aus HTML-Seiten bestehen, ist für viele Unternehmen auf Grund der Plattformunabhängigkeit und der einfachen Verteilung sehr verlockend. Die Entwickler von Applikationen, die eine Benutzeroberfläche benötigen, die wegen ihrer Komplexität nicht mit HTML erstellt werden kann, können Dynamic HTML oder Skriptcode verwenden (Der Internet Explorer unterstützt sowohl VBScript als auch JScript). Eine weitere Möglichkeit besteht darin, ActiveX-Steuerelemente oder Java-Applets in Webseiten einzusetzen. Java-Applets sind wie HTML plattformunabhängig, und sowohl Java-Applets als auch ActiveX-Steuerelemente ermöglichen eine automatische Verteilung. Applikationen, die eine noch stabilere Präsentationsschicht benötigen, können mit Programmiersprachen wie beispielsweise Visual Basic, Java und C++ erstellt werden. Applikationen, die mit Visual Basic, Java oder C++ erzeugt wurden, führen in der Regel direkte Methodenaufrufe an die Geschäftskomponenten in der COM+-Umgebung durch, während Client-Programme, die in HTML programmiert wurden, das Hypertext Transfer Protokoll (HTTP) zur Kommunikation mit dem Webserver nutzen. Geschäftslogik Während die Client-/Server-Architektur darauf fixiert ist, die Client-seitigen und die Server-seitigen Komponenten auf unterschiedlichen Computern einzusetzen, können die Geschäftslogikkomponenten eines Three-Tier-Designs zu weitaus flexibleren Lösungen führen. Die Geschäftslogik einer Applikation kann beispielsweise als eine prozessinterne COM+-Komponente implementiert werden, die im Prozess der Client-Applikation auf der Client-Seite oder im Prozess eines Web-Servers auf der Server-Seite ausgeführt wird. Alternativ hierzu kann die Geschäftslogikkomponente in einer COM+-Umgebung auf einer dritten Maschine, die sowohl vom Client als auch vom Datenbankserver getrennt ist, ausgeführt werden. Daten Die Datenschicht eines Windows-DNA-Modells besteht aus SQL-Servern wie zum Beispiel Microsoft SQL Server, Oracle, Sybase, DB2 oder jedem anderen Datenbankserver, der OLE DB oder Open Database Connectivity (ODBC) unterstützt. COM+-Komponenten, die auf der mittleren Stufe ausgeführt werden, verwenden gewöhnlich ActiveX-Datenobjekte (ADO, die COM+-Komponente, die einen Wrapper für OLE DB zur Verfügung stellt), um eine Verbindung zur Datenbank herzustellen und diese abzufragen. OLE DB ermöglicht den Datenzugriff auf eine Vielzahl unterschiedlicher Datenbankserver, einschließlich älterer Systeme. Komponentendienste Microsoft war der Meinung, dass Entwickler zu viel Zeit mit dem Schreiben von Verwaltungscode verbrachten 30 Prozent der Zeit wurde für die Entwicklung von COM+-Komponenten aufgebracht. COM+-Komponentendienste stellen eine Standardimplementierung von Diensten zur Verfügung, die von Komponentenentwicklern häufig benötigt werden. Programmierer können sich jetzt somit auf die Geschäftslogik konzentrieren. Dies soll die ursprünglichen COM+- Ideen einem breiteren Publikum zugänglich machen und ist wichtig, wenn COM+ die Komponenten-Objekttechnologie für Windows-Dienste der Zukunft werden soll. Abbildung 1.4 zeigt die Evolution der Dienste von COM bis COM+. Komponenten-Software 17

16 COM+ Lastenausgleich In-Memory-Datenbank Objekt-Pooling Warteschlangenkomponenten Ereignismodell Bessere Administration Microsoft Transaction Server Transaktionsdienste Ressourcen-Pooling Rollenbasierte Sicherheit Administration Just-In-Time-Aktivierung Distributed COM Remote-Architektur Verteilte Komponentendienste COM Schnittstellenbasierte Programmierung Grundlegende Komponentenmodule Abbildung 1.4: Die Evolution der Komponentendienste von COM bis COM+. Just-In-Time-Aktivierung Wenngleich COM+ bestimmte Anforderungen an Ihre Komponenten stellt, bietet es sehr viel Funktionalität. Ein wichtiges Feature von COM+ ist die Fähigkeit, Komponenten der mittleren Stufe zu skalieren, so dass diese hunderte oder sogar tausende Clients gleichzeitig unterstützen können. Ein Client, der ein COM+-Objekt in einer COM+-Umgebung instanzieren möchte, erhält einen Verweis auf ein Kontextobjekt, das von COM+ implementiert wurde. Dabei handelt es sich nicht um einen Verweis auf das Komponentenobjekt (wie in Abbildung 1.5 dargestellt). Erst wenn der Client später eine Methode der Komponente aufruft, instanziert COM+ das eigentliche Objekt. Diese Technik, die als Just-In-Time-Aktivierung bezeichnet wird, weist Client-Programmen eine Referenz auf Objekte zu, die möglicherweise nicht sofort verwendet werden. Der hierfür erforderliche Rechenaufwand ist nur sehr gering. Wenn Sie komplexe Geschäftslogik-Komponenten implementieren, kann eine Komponente auf andere Komponenten zugreifen. Diese Komponenten können ebenfalls andere Komponenten aufrufen. Das korrekte Steuern dieser Kettenreaktion ist keine einfache Aufgabe. In COM+ enthält das vom System erstellte Kontextobjekt, das jedes Benutzerobjekt verbirgt, Informationen zur Verwaltung dieser komplexen Beziehungen. 18 Kapitel 1

17 Client IObjectContext ICustom Transaction ID Object-Creator ID Das Objekt Deaktivierung Client IObjectContext ICustom Transaction ID Object-Creator ID Das Objekt Aktivierung Client IObjectContext ICustom Transaction ID Object-Creator ID Das Objekt Abbildung 1.5: Eine Client-Applikation, die eine konfigurierte COM+-Komponente verwendet, die wiederum transparent aktiviert und deaktiviert wird. COM+ erweitert außerdem das COM-Modell, um eine frühe Deaktivierung eines Objekts zu ermöglichen. COM+ kann eine Komponente sogar dann deaktivieren, wenn Client-Programme über einen zulässigen Verweis auf diese Komponente verfügen. Dazu gibt COM+ alle Verweise auf das Objekt frei. Dies führt wiederum dazu, dass korrekt erstellte COM+-Komponenten zerstört werden, wenn ihr interner Verweiszähler den Wert 0 erreicht. Wenn der Client bestimmte Dienste von einem Objekt anfordert, das von COM+ deaktiviert wurde, wird das Objekt transparent reaktiviert. Für einen Client-Prozess kann somit der Eindruck entstehen, von der Erstellung bis zur Freigabe mit einem einzigen Objekt zu arbeiten. Stattdessen verwendet er möglicherweise unbemerkt viele verschiedene Instanzen derselben Klasse. Diese Vorgehensweise gewährleistet, dass die COM-Vorgaben nicht verletzt werden. Die Just-In-Time-Aktivierung ist ein leistungsfähiges Ressourcen-Sharing-Konzept, da sie COM+ erlaubt, die Ressourcen des Servers sehr viel gerechter auf die aktiven Komponenten zu verteilen. Stellen Sie sich zum Beispiel vor, dass ein Client-Prozess zehn Prozent seiner Zeit mit dem Anfordern unterschiedlicher Dienste von einem bestimmten Objekt verbringt. Mit der automatisierten Deaktivierung von COM+-Objekten ist das Objekt lediglich ein Zehntel der Zeit instanziert, die es gewöhnlich als Instanz seiner Klasse verbringen würde. Dies lässt eine Server-Maschine weitaus skalierbarer werden, da nicht alle Objekte während der gesamten Zeit, in der die Clients ausgeführt werden, aktiv sind. Komponenten-Software 19

18 Objekt-Pooling Um die Gesamtskalierbarkeit einer verteilten Applikation zu erweitern, unterstützt COM+ das Objekt-Pooling. Wenn ein Client ein Objekt freigibt, das Objekt-Pooling unterstützt, recycled COM+ das Objekt für die spätere Verwendung durch denselben oder einen anderen Client. Das Objekt wird somit nicht zerstört. Wenn ein Client später versucht, auf denselben Objekttyp zuzugreifen, entnimmt COM+ das gewünschte Objekt aus dem Pool, sofern es dort vorhanden ist. COM+ instanziert automatisch ein neues Objekt, wenn der Pool mit den wieder aufbereiteten Objekten leer ist. Objekte, die das Pooling unterstützen, müssen ihren Status wiederherstellen, so dass dieser dem Status eines neu erstellten Objekts entspricht. Sie sollten entscheiden, ob Sie das Recyclen eines Objekts unterstützen möchten. Wiegen Sie dazu den Aufwand des Erstellens neuer Objekte gegen das Speichern der Ressourcen dieser Objekte im Objekt-Pool ab. Ein Objekt, dessen Erstellung viel Zeit erfordert, das aber über nur wenige Ressourcen verfügt, ist ein guter Kandidat für das Recycling. Stellen Sie sich zum Beispiel ein Objekt vor, das eine komplexe Speicherstruktur entwickelt, wenn es erstellt wird. Wenn dieser Objekttyp das Pooling unterstützt, kann es seine Struktur einfach reinitialisieren, nachdem es deaktiviert wurde. Auf diese Weise wird die Performance zur Laufzeit verbessert, da die Struktur nicht mit jeder Aktivierung erneut generiert werden muss. Für andere Objekte bietet das Recycling nicht in jedem Fall Vorteile. Ein Objekt, das beispielsweise nur sehr aufwendig zu erstellen ist und viele Statusinformationen für jeden Client speichert, sollte nicht dem Recycling zugeführt werden, da es nicht von anderen Clients wieder verwendet werden kann. Lastenausgleich Eine verteilte COM+-Applikation kann potentiell tausende von Clients bedienen. In diesem Szenario können die Just-In-Time-Aktivierung und das Objekt-Pooling jedoch nicht immer die erforderliche Applikationsskalierbarkeit zur Verfügung stellen. Die Arbeitsauslastung des Clients sollte deshalb auf mehrere Server eines Netzwerkes verteilt werden. In COM+ ist der Lastenausgleich auf der Komponentenebene implementiert. Dies bedeutet, dass eine Client-Applikation, die eine spezifische Komponente anfordert, zunächst einen Lastenausgleichs-Router kontaktieren muss. Der Router enthält Informationen über Maschinen, die der verteilten Applikation zugeordnet sind. Er verteilt außerdem die Arbeitsauslastung auf diese Server. Nachdem das gewünschte Objekt auf einem der Server im Zuordnungsbereich instanziert wurde, erhält der Client eine Referenz, die direkt auf die entsprechende Komponente des Servers verweist. Alle künftigen Anfragen des Clients werden dann direkt an die Komponente weitergeleitet. Es wurden bereits eine Vielzahl unterschiedlicher Lastenausgleichsalgorythmen entworfen. COM+ verwendet einen einfachen Antwortzeitalgorythmus zur Analyse, um die Arbeitslast der Server auszugleichen. (In Zukunft wird COM+ vielleicht die Installation anderer Algorythmen zulassen.) Der Lastenausgleich ist auch in einem Fehlerszenario sehr wichtig. Wenn ein Client einen Verweis auf die Komponente eines Server besitzt, dessen System ausfällt, leitet COM+ die Client-Anfragen zu einem anderen Server des Zuordnungsbereichs der Applikation weiter. Dieses ausfallübergreifende Verhalten hilft dabei, Client-Dienste ununterbrochen bereitzustellen, wodurch die Stabilität des gesamten Systems erhöht wird. Da der Lastenausgleichs-Router eine geringe kritische Fehlerquelle sein kann, verfügen Sie über die Möglichkeit, den Windows 2000-Zuordnungsdienst zu verwenden, um einen oder mehrere Sicherungsrouter für den Fall eines Fehlers einzurichten. 20 Kapitel 1

19 In-Memory-Datenbank Die In-Memory-Datenbank (IMDB) ist ein weiterer leistungsfähiger COM+-Dienst. IMDB ist ein flüchtiger, transaktionaler Datenbank-Cache, der die Performance verteilter Applikationen erhöht. Als OLE DB-Provider implementiert, stellt IMDB einen äußerst schnellen Zugriff auf die Daten der lokalen Maschine zur Verfügung. Client-Applikationen verwenden Datenzugriffskomponenten wie zum Beispiel ADO, um indizierte tabellarische Daten zu erstellen und darauf zuzugreifen. Diese im Cache befindlichen Datenbanken können von der COM+-Applikation dynamisch erstellt oder von einem Datenträger geladen werden. Warteschlangenkomponenten Warteschlangenkomponenten sind ein Schlüsselfeature von COM+, das auf der Microsoft Message Queue Server-Infrastruktur (MSMQ) basiert, die in Windows 2000 enthalten ist. Ein Client, der diese Komponenten verwendet, kann auf einfache Weise Methodenaufrufe auf einer COM+- Komponente ausführen. Dies ist auch dann möglich, wenn keine Verbindung zur Komponente besteht. Das MSMQ-System zeichnet die Methodenaufrufe auf und ordnet sie einer Warteschlange zu. Die Aufrufe werden "abgespielt", sobald die erforderliche Komponente wieder zur Verfügung steht. Abbildung 1.6 zeigt, wie MSMQ verwendet wird, um Daten zwischen dem Client und der Komponente zu transferieren. Client Proxy (Rekorder) MSMQ Warteschlange (Versenden) Server Stub (Player) Warteschlange (Emfpangen) Komponente Abbildung 1.6: Eine Client-Applikation, die über MSMQ auf ein Objekt zugreift Transaktionen Mit COM+ können Sie Komponenten erstellen, die automatisch an einer verteilten Transaktion teilnehmen. Wenngleich die Transaktionsverarbeitung eine der wichtigeren Funktionen von COM+ ist, nimmt es zur Transaktionsverwaltung die Unterstützung des Microsoft Distributed Transaction Coordinator (MS DTC) in Anspruch. Ursprünglich hat Microsoft die OLE-Transaktionen entworfen, ein objektorientiertes, auf COM basierendes Zwei-Phasen-Commit-Protokoll, und dies in MS DTC implementiert. MS DTC ist ein Transaktions-Manager, der ursprünglich zum Lieferumfang von Microsoft SQL Server gehörte. (Die OLE-Transaktionen-Spezifikation defi- Komponenten-Software 21

20 niert vier wesentliche Schnittstellen: ITransaction, ITransactionDispenser, ITransactionOptions und ITransactionOutcomeEvents.) Microsoft hat die über MS DTC verfügbaren Dienste allerdings nicht allein für die Verwendung mit Microsoft SQL Server entworfen. MS DTC ist nun ein in Windows 2000 integrierter Dienst, dessen Funktionalität vielen unterschiedlichen Anwendungen zur Verfügung steht, die Transaktionsverwaltungsdienste benötigen. Neben der OLE-Transaktionsspezifikation unterstützt COM+ auch den Standard X/Open DTP XA. XA ist ein Zwei-Phasen-Commit-Protokoll, das von der X/Open DTP-Gruppe definiert wurde. Um COM+ die Zusammenarbeit mit dem XA-Ressourcen-Managern zu ermöglichen, beinhaltet das COM+-Software Development Kit (SDK) eine spezielle Komponente. Diese Komponente übersetzt OLE-Transaktionen in den XA-Standard, so dass es für den XA-Ressourcen-Manager sehr einfach ist, Ressourcenverteiler zur Verfügung zu stellen, die OLE-Transaktionen von COM+ akzeptieren und diese Transaktionen dann unter Verwendung von XA ausführen. Eine Transaktion wird typischerweise initiiert, wenn eine Anwendung eine kritische Operation ausführen soll. Die Applikation initiiert die Transaktion, indem sie einen Transaktions-Manager wie zum Beispiel den MS DTC benachrichtigt. Die Anwendung nimmt dann zur Ausführung der gewünschten Aufgabe die Dienste verschiedener Ressourcen-Manager in Anspruch. Unter einem Ressourcen-Manager wird ein beliebiger Dienst verstanden, der die OLE Transaktionsspezifikation unterstützt, wie beispielsweise der Microsoft SQL Server. Ressourcen-Manager arbeiten mit MS DTC zusammen. Wenn die Client-Applikation verschiedene Ressourcenverteiler aufruft, übergibt sie ebenfalls Informationen, die die aktuelle Transaktion identifizieren (Ressourcenverteiler werden auch als Ressourcen-Dispenser bezeichnet. Sie gleichen den Ressourcen-Managern, sind aber nicht genauso robust.) In der Regel wird die Transaktionsverarbeitung vor allem für Datenbankzugriffe angewendet, da die Integrität der dort gespeicherten Daten höchste Priorität hat. Die Transaktionsverarbeitung ist allerdings nicht auf Datenbankverwaltungssysteme (DBMS) beschränkt. COM+ bietet beispielsweise auch zwei Ressourcenverteiler an: den ODBC Driver Manager und den Shared Property Manager. Der ODBC Driver Manager ist ein Ressourcenverteiler, der einen Pool mit Datenbankverbindungen für COM+-Komponenten verwaltet. Sie können ebenfalls einen zusätzlichen Ressourcenverteiler mit Hilfe des COM+-SDKs entwickeln. Ein Ressourcen-Manager, der Arbeiten im Auftrag der Client-Anwendung ausführen soll, registriert sich selbst beim Transaktions-Manager. Der Transaktions-Manager überwacht den Ressourcen-Manager im weiteren Verlauf der Transaktion. In der Terminologie der Transaktionsverarbeitung endet eine Transaktion, wenn die Client-Anwendung die Transaktion über eine Commit- Operation abschließt oder wenn die Transaktion abgebrochen wurde. Im Fall eines Abbruchs benachrichtigt der Transaktions-Manager alle an der Transaktion beteiligten Ressourcen-Manager darüber, dass sämtliche Operationen, die im Rahmen dieser Transaktion ausgeführt wurden, durch eine Rollback-Operation rückgängig gemacht werden müssen. Man kann eine Rollback- Operation mit einer riesigen Undo-Operation vergleichen. Falls in der Client-Anwendung ein nicht behebbarer Fehler auftritt, bevor die Transaktion abgeschlossen oder abgebrochen wurde, bricht MS DTC die Transaktion automatisch ab. Wenn die Client-Anwendung zu verstehen gibt, dass die Transaktion abgeschlossen werden kann, führt der MS DTC ein Zwei-Phasen-Commit-Protokoll aus, das sicherstellt, dass die in der Transaktion definierten Operationen korrekt durchgeführt werden. (Das Zwei-Phasen-Commit- Protokoll gewährleistet, dass Transaktionen für mehr als einen Server entweder auf allen Servern oder auf keinem Server abgeschlossen werden.) Das Zwei-Phasen-Commit-Protokoll ergibt sich aus der Koordination zwischen dem MS DTC und den unterstützten Ressourcen-Managern. Zuerst fragt der MS DTC alle an der Transaktion beteiligten Ressourcen-Manager, ob sie mit der 22 Kapitel 1