Mit DNA hat Microsoft ein Konzept für eine mehrschichtige Anwendungsarchitektur vorgelegt, die den Aufbau flexibler, wiederverwendbarer Softwarekomponenten vereinheitlichen soll. Das Ziel dieser Aktivitäten ist klar: Zum einen müssen im Zusammenhang mit E-Business eine große Anzahl von Entwicklungsprojekten möglichst effizient bewältigt werden, was ohne die mehrfach nutzbaren Komponenten kaum möglich erscheint. Zum anderen möchte sich natürlich Microsoft im Bereich der Anwendungsentwicklung stärker als bisher positionieren und, über den Einsatz der eigenen Werkzeuge hinaus, den Markt für Softwareentwicklung in seinem Sinne beeinflussen.
Und dabei hat Microsoft bereits einiges erreicht: Mit dem Standard COM+ als Nachfolger von COM/DCOM steht heute eine leistungsfähige Technologie für die Entwicklung von Softwarekomponenten für die Windows-Welt zur Verfügung. In Windows NT war der Microsoft Transaction Server (MTS) noch ein separates Produkt, das auf COM/DCOM aufbaute. Unter Windows 2000 wurden COM und MTS zu COM+ zusammengeführt. COM+ ist abwärtskompatibel, für COM geschriebene Objekte können also auch unter COM+ ausgeführt werden, allerdings können sie die spezifischen Leistungen des MTS nicht nutzen. Um in die COM+-Runtime-Umgebung geladen werden zu können, müssen COM+-Objekte als Dynamic Link Libraries vorliegen.
Voraussetzung für den Einsatz von Softwarekomponenten ist die saubere Abgrenzung der Schichten, wie sie schon seit einigen Jahren State-of the Art ist. Wer sich bei der Entwicklung seiner Anwendungen in der Vergangenheit an dieses Konzept gehalten hat, wird es daher beim Einstieg in die DNA-Welt leichter haben. Die Abtrennung der Präsentationsschicht erlaubt die Verwendung unterschiedlicher Client-Umgebungen, sie hat vor allem in letzter Zeit durch die Browser-Clients eine große Bedeutung erlangt. Auf der anderen Seite erlaubt eine von der Anwendungslogik unabhängige Datenbankschicht eine größere Flexibilität und Skalierbarkeit der gesamten Lösung. Zwischen Präsentationsschicht und Datenhaltung liegt der eigentliche Kern einer Anwendung, die Business-Logik, sie wird von den nicht-visuellen Objekten vertreten.
Das Grundproblem aller Komponenten-Technologie ist die Kommunikation der einzelnen Komponenten miteinander beziehungsweise mit der Datenbank einerseits und mit visuellen Objekten der Präsentationsschicht wie etwa Buttons, Eingabefeldern oder Auswahlboxen andererseits. Diese Kommunikation muss reibungslos auch über Sprachgrenzen hinweg funktionieren, damit die Komponenten universell verwendbar sind. Ist diese Bedingung erfüllt, lassen sich mit einer Anwendung beliebig komplexe Aufgaben lösen, weil der Entwickler in der Lage ist, die jeweils optimalen Komponenten aus unterschiedlichen Welten zu kombinieren.
Unter COM verläuft die Kommunikation der Objekte vereinfacht etwa nach folgendem Schema:
1. Die Anwendung nimmt auf Grund eines Ereignisses - zum Beispiel dem Mausklick auf einen Button - die Verbindung zu einem COM-Objekt auf. Im Fall des Centura Team Developers wird mit der Anweisung "create" eine Instanz des Objektes gestartet.
2. Windows stellt eine persistente Verbindung zum Objekt her.
3. Die Anwendung ruft entsprechend der gewünschten Aktion eine Methode des Objektes auf. Welche Methoden verfügbar sind, lässt sich in CTD über den Activex-Explorer feststellen.
4. Das Objekt führt die Methode aus, beispielsweise einen "search"-Befehl in der Datenbank.
5. Das Objekt gibt das Ergebnis zurück.
6. Die Anwendung gibt das Objekt wieder frei, in CTD mit der Anweisung "release".
Dieser Ablauf bedingt eine sorgfältige Programmierweise. Wer es sich beim Entwickeln einfach macht und beispielsweise die COM-Objekte generell bei Programmstart anmeldet und erst am Ende wieder freigibt, wird Speicherprobleme bekommen, sobald immer mehr Anwender seinem Beispiel folgen. Die Anwendung ist dann nicht skalierbar.
Unter anderem gegen solche Probleme wurde der Microsoft Transaction Manager (MTS) geschaffen. Beim MTS handelt es sich, vereinfacht ausgedrückt, um eine Art Objekt-Manager für COM-Objekte. Er erleichtert den Umgang mit den COM-Objekten, indem er den Entwickler von seiner Verwaltung entlastet. Dazu legt er eine logische Schicht zwischen Anwendung und COM-Objekt an. Für die jeweiligen Anwendungen ist dies transparent, für sie ist es gleich, ob sie mit COM- oder COM+-Objekten sprechen. Der MTS kennt zum Beispiel die von einer Anwendung benötigten COM-Objekte, er startet eine Objektinstanz aber erst im Moment des Methodenaufrufs (Schritt 3), also erst, wenn das Objekt wirklich benötigt wird, und er gibt den Speicher sofort nach der Rückgabe des Ergebnisses (5) wieder frei.
Anders als bei COM besteht also nicht eine persistente, sondern nur eine punktuelle Verbindung zwischen Anwendung und Objekt. Auf Basis seiner Informationen über die COM+-Objekte kann der MTS bei erfolgtem Aufruf auch eine effektive Lastverteilung vornehmen, indem er es dem gerade verfügbaren schnellsten Prozessor zuweist. Auf die gleiche Weise lassen sich in die COM+-Objekte Commit- oder Rollback-Funktionen von MTS einbetten.
Diese Transaktionen können im Falle von Störungen bis zum endgültigen Commit komplett zurückgefahren werden, auch wenn innerhalb dieser MTS-Transaktionen mehrere eigenständige Datenbanktransaktionen enthalten sind. Um MTS-Transaktionen zu verwenden, müssen alle Datenbanktransaktionen über OLE DB ausgeführt werden.
Darüber hinaus erlaubt der MTS ein Monitoring der COM-Objekte: Der Entwickler kann den MTS durch spezielle Methodenaufrufe anweisen, bestimmte Ereignisse, beispielsweise Fehlerzustände, zentral zu protokollieren. Ebenso können rollenbasierte Sicherheitsfunktionen über den MTS bis auf Objektebene weitergereicht werden; der MTS kann dann beispielsweise den Zugriff auf ein einzelnes COM+-Objekt sperren.
Mit dem MTS lässt sich eine weitaus bessere Skalierbarkeit von Anwendungen erreichen. Dazu gehört aber auch, dass der MTS selber skaliert werden kann: der CSA (Component Service Administrator), der logischerweise außerhalb des MTS angesiedelt ist, regelt die Verteilung von Objekten auf verschiedene Transaktions-Server.
*Martin Teetz ist Business Development Manager bei Centura Software in München.
Abb: Com+ erleichtert die Erstellung von Komponenten: Entwickler müssen lediglich Metadaten und Methoden bereitstellen. Registrierung und Speicher-Management werden vom System erledigt. Quelle: Microsoft