Die bisherige Entwicklungsarchitektur von Microsoft heißt Windows Distributed Internetwork Application (DNA) . Diese empfiehlt eine Schichtenarchitektur mit Middleware und Komponenten. Die Vorteile von .NET gegenüber DNA liegen unter anderem in der Vereinheitlichung der bisherigen Programmiermodelle. So musste man sich vor .NET für ein Programmiermodell entscheiden und mit dessen Einschränkungen und Nachteilen leben.
Um .NET zu verstehen und dessen Einführung beziehungsweise Migration zu planen, hat Microsoft das Projekt "Microsoft .NET Developer Tools readiness kit" gestartet. Deutschland übernimmt dabei erstmals im Microsoft-Konzern eine weltweite Führungsrolle bei der Erstellung von Workshop-Material. Innerhalb des Projekts gibt es 32 Module, von denen drei das Thema Migration aus je einer anderen Perspektive abdecken. Sie tragen die Bezeichnung:
- "From DNA to .NET Porting",
- "From DNA to .NET Knowledge Path",
- "From DNA to .NET Design Path".
Bei DNA-to-.NET-Porting geht es um die klassische Portierung, bei der die Codierung einer vorhandenen Anwendung so lange angepasst wird, bis diese in der neuen Umgebung fehlerfrei läuft. Dieses Themengebiet ist sehr umfangreich und deckt viele Technologien ab. Portierung von Visual Basic 6.0 zu Visual Basic.NET und die Anwendung des Visual Basic.NET Upgrade Wizard sind nur der Anfang. Ein weiteres Beispiel ist die Migration von J++-Anwendungen. Hierfür gibt es das "Jump to .NET Paket - Java User Migration Path". Hierin enthalten sind verschiedene Technologien und Services, Interoperabilitäts-Unterstützung, Programmierungs-Tools sowie ein Java-zu-C#- Konverter.
Der DNA-to-.Net-Knowledge-Path berücksichtigt, dass Programmierwissen nicht nur aus Syntax-Kenntnissen besteht. Noch wertvoller ist das Know-how, wie man zum Beispiel eine bestimmte Aufgabe durch Aufrufe der Laufzeitfunktionen löst. Das zentrale Thema dieses Moduls ist deshalb das "Know-how-Mapping". Das .NET-Framework bietet zahlreiche neue Klassen mit neuen Namen. Deshalb beantwortet das Modul gezielt Fragen, zum Beispiel welche Funktion eine Datei erstellt und welche eine Internet-Verbindung. Meistens ist eine 1:1-Zuordnung möglich, während in Ausnahmefällen eine Umschreibung der Codierung notwendig ist.
Das dritte Modul (DNA to .NET Design Path) ist rein strategisch und beschäftigt sich mit Design-Aspekten. Dieses Thema repräsentiert den Kern der Diskussion. Anwender, die zur Zeit noch nicht in .NET einsteigen können, erhalten damit Design-Empfehlungen, um eventuell später anfallende Portierungskosten zu minimieren. Das Motto dahinter: "Design for .NET and build with DNA". So können vor allem Entwicklungsprojekte, die noch in den Startlöchern stecken, die Weichen für einen Übergang zu .NET stellen.
Untersuchungen bei Microsoft haben gezeigt, dass zum Beispiel Active Server Pages (ASP) zu ASP.NET einen optimalen Portierungspfad darstellen. Dabei wird die Codierung in der Regel bis zu zehnmal reduziert, die Performance durch den Wegfall der Interpretation um einen Faktor verbessert und die Stabilität erheblich erhöht.
In kleinen Paketen planenDie generelle Empfehlung ist, das Migrationsprojekt in kleinen überschaubaren Paketen zu planen und nicht gleichzeitig an allen Ecken des Systems umzubauen. Die optimale Strukturierung strebt die Lauffähigkeit des Systems nach jedem abgeschlossenen Schritt an. Die Vorteile bestehen nicht nur in der frühzeitigen Nutzung, sondern auch in der Risikominimierung und Qualitätskontrolle.
Zur Verdeutlichung sei hier ein fiktives ASP-Projekt in der Design-Phase herangzogen. Es wurde beschlossen, Windows-DNA-Technologien zu verwenden und die Anwendung später auf .NET zu portieren. Vor diesem Hintergrund werden folgende Techniken eingesetzt: ASP (Active Server Pages mit Visual Basic), COM+-Komponenten (Komponententechnologie mit Visual Basic), MSXML (Microsoft XML) sowie ADO (Active Data Objects).
Hinzu kommen mehrere Design-Empfehlungen, die nicht nur die Migration auf .NET erleichtern, sondern auch die Anwendung verbessern:
- Die Anwendung sollte mindestens aus drei Schichten bestehen: Präsentation, Geschäftslogik und Daten. Eine Façade kapselt die Geschäftslogik-Schicht und ist das einzig Sichtbare auf der Präsentationsebene.
- Client-seitiges Scripting ist zu vermeiden, da es unter anderem zur Browser-Abhängigkeit führt.
- Sinnvoll ist eine maximale Trennung zwischen Präsentation und Logik innerhalb der ASP. Scripting in ASP ist zugegebenermaßen unvermeidbar, es muss jedoch auf ein Minimum reduziert werden. Die Codierung sollte mehrheitlich in Komponenten untergebracht werden. Scripting wird als "Klebstoff" zwischen den Komponenten verwendet, und das Prinzip lautet: Klebstoff dünn auftragen.
- Rollendefinition, denn jede Komponente sollte eine klare Aufgabe erfüllen.
- Globale sollten in Funktionen und Klassen verkapselt sein.
- Statt Scripting XML/XSLT einsetzen, da man sich damit auf der sicheren Seite befindet und für die Zukunft bestens ausgestattet ist.
Eine spätere Migration der DNA-Anwendung auf .NET kann dann zum Beispiel folgende Schritte beinhalten:
ASP als PortierungspfadZunächst wird der ASP Script Code in Objekt-Klassen übertragen (ASP zu ASP.NET). Dabei wird die Codierung vom Layout getrennt, was eine erhebliche Verbesserung und mehr Übersichtlichkeit mit sich bringt. Die Codierungsqualität steigt deutlich, gleichzeitig genießt der Anwender eine bessere Performance. Die Middleware der COM+-Komponenten können ohne weiteres von der Präsentationsschicht angesprochen und müssen noch nicht migriert werden. Nach diesem Schritt ist die Anwendung wieder lauffähig.
Die Migration der COM+-Komponenten auf .NET ist relativ problemlos, da sich Visual-Basic-Komponenten in der Regel fast ohne Änderung portieren lassen. Voraussetzung hierfür ist die Beachtung von Richtlinien der Komponentenprogrammierung. Neben einer besseren Codierung steigt auch die Performance. Die ersten beiden Schritte haben auch Einfluss auf eine Qualitätskontrolle.
Der dritte Schritt ersetzt die Aufrufe auf MSXML durch Aufrufe auf .NET-XML-Klassen. Das .NET-Framework bietet dazu eine neue Gruppe von XML-APIs, die auf Industriestandards basieren wie DOM, XPath, XSD und XSLT. Diese Phase stellt vor allem eine Investition in offene Standards dar. Die Anwendung kann anschließend eingesetzt werden.
Alle COM-Aufrufe entfernenIm vierten Schritt wird ADO durch ADO.NET ersetzt. Genau wie ADO ist ADO.NET eine API (Application Programming Interface), doch im Gegensatz zu ADO ist es auf einem verbindungslosen Modell aufgebaut. ADO.NET ist vor allem für den Einsatz im Internet optimiert, wo die Verbindungslosigkeit (disconnected) eine Selbstverständlichkeit ist. Datensätze werden in XML zwischen Client und Server transportiert. Nach einer kurzen Verbindung kann der Client mit einer XML-Kopie der Daten arbeiten, während der Server andere Clients bedient. Nach diesem Schritt sind alle COM-Aufrufe entfernt.
Technisch gesehen ist die Migration nach dem vierten Schritt abgeschlossen. Es gibt trotzdem die Möglichkeit, neue .NET-Technologien in Anspruch zu nehmen, die Verbesserungen in der Anwendung erzielen. Gute Beispiele sind Web-Controls, Validatoren (validators) oder Caching. (Eine kostenlose ".NET-readiness-kit"-CD lässt sich via E-Mail mit "NETRK" in der Betreffzeile unter bijanj@microsoft.com beziehen.)
*Bijan Javidi ist Principle Consultant der Microsoft Consulting Services in München (bijanj@microsoft.com).
Abb: .NET vereinheitlicht Windows-Programmierungsmodelle
Quelle: Microsoft