Den Absichtserklärungen der Redmonder ist zu entnehmen, dass Entwickler mit Hilfe von .NET die Möglichkeit erhalten, eine neue Generation von Internet-basierten Anwendungen und Services zu erstellen. Dem derzeitigen Modell von Clients, die auf Daten, Dienste und Web-Seiten zugreifen, stellt die Gates-Truppe ein weitgehend dezentrales Modell gegenüber, das verteilte Web-Services miteinander vernetzen soll. In Firmenaussagen wird dabei das heutige Internet als Mainframe-Modell apostrophiert, in dem der Browser als dummes Read-only-Terminal fungiert. Demgegenüber soll das .NET-Zeitalter einen universelleren Zugang zu Informationen erlauben, indem das Programmieren, Editieren und das Bereitstellen von Daten vereinfacht wird.
Noch verstecken sich aber viele Details hinter einem Marketing-Schleier. Auch ein Herunterbeten der .NET-Features allein dürfte kaum jemandem verständlich machen, wie und in welchen Umgebungen sich Microsofts Zukunftstechnik einsetzen lässt. So viel ist derzeit klar: Wer Windows auf Desktops einsetzt, wird wenig Nutzen von .NET haben. Im Server-Bereich dürfte es dagegen einige Veränderungen mit sich bringen. Wer allerdings mit dem Entwurf, der Entwicklung und der Implementierung von Unternehmens-Software oder Web-Anwendungen beschäftigt ist, sollte sich bewusst sein, dass .NET den Charakter von Windows merklich verändern wird. Designmodelle und Entwicklungstechniken, die seit NT 3.51 galten, werden schon bald obsolet sein.
Framework vereinfacht bisherige COM-Technik
Im Gegensatz zur schwammig definierten "Windows DNA" (Distributed Internet Architecture) ist .NET ein einfach und klar strukturiertes Softwareprodukt. Es handelt sich dabei um ein Anwendungs-Framework, und als solches stellt es den Programmen System- und Netzwerkdienste zur Verfügung.
Die .NET-Dienste reichen von der Darstellung grafischer Benutzeroberflächen bis hin zur Kommunikation mit anderen Servern und Anwendungen. Das Framework ersetzt dabei das Component Object Model (COM) durch ein weitaus einfacheres Objektmodell, das konsistent über viele Programmiersprachen hinweg implementiert wurde. Dadurch wird das Verteilen von Daten zwischen Anwendungen und über das Internet einfacher und transparenter. .NET soll auch die Skalierbarkeit und Stabilität von Anwendungen verbessern. Die aufgeführten Vorteile lassen sich bereits anhand der Vor-Betaversion nachvollziehen. Erhältlich ist das ".NET Framework SDK Preview" unter http://msdn.microsoft.com/net.
Um zu verstehen, auf welche Weise .NET die Unternehmens-IT verändern kann, muss man zunächst einen Blick darauf werfen, wie sich das Framework in die bestehenden und geplanten Windows-Architekturen einfügt.
.NET hat bisher vor allem deshalb einige Verunsicherung ausgelöst, weil einerseits IT-Fachleute eine Inkompatibilität mit bestehenden Systemen und Anwendungen befürchteten und andererseits Entwickler einen Bruch mit existierenden Technologien vermuteten. Demgegenüber verspricht Microsoft die nahtlose Integration in bestehende Windows-Umgebungen.
Bevor .NET in einer der kommenden Windows-Versionen - möglicherweise dem Windows-2000-Nachfolger "Whistler" - integriert sein wird, kann es auf Wunsch unter Windows 2000 nachinstalliert werden.
Microsoft hat wegen seiner vorschnellen Ankündigung und der teils widersprüchlichen Aussagen um .NET die Gerüchteküche kräftig angeheizt. Eine der kolportierten Vermutungen war, dass COM und COM+ beerdigt werden sollten. Tatsächlich aber migrieren die Redmonder die COM+-Middletier-Services inklusive Messaging und Transactions nach .NET. COM+-basierte Anwendungen bleiben also kompatibel. Die gravierendste Änderung, die .NET für Windows-basierte Unternehmensarchitekturen bringt, ist die Kapselung von Enterprise-Services. Hatte man sich zu Beginn von Projekten bisher auf die Auswahl einer bestimmten Programmiersprache wie Visual C++ oder Java konzentriert, so können Entwickler ihre Planung zukünftig sprachunabhängig an den mit .NET angebotenen Enterprise-Services ausrichten.
Ebenfalls aus der Luft gegriffen sind Gerüchte, wonach .NET auf COM aufbaut oder ein Java-artiger Wrapper für COM sein soll. COM-Dienste wie Objektdaten-Repräsentation oder Remote Execution sind im .NET-Framework unabhängig und besser implementiert. Es dürfte aber einige Zeit vergehen, bis alle Windows-Bestandteile, insbesondere Multimedia-relevante COM-Dienste wie Direct X nach .NET migriert sein werden. Aus diesem Grund werden viele .NET-Anwendungen Aufrufe an COM-Schnittstellen enthalten, obwohl .NET von COM keinen Gebrauch macht.
Anwender, die den Einsatz von .NET planen, müssen ihre Clients unter Umständen aktualisieren, sobald sie entsprechende .NET-Anwendungen auf Servern installieren. Die Hardwareanforderungen sollten sich nicht erhöhen, es dürfte ausreichen, die Runtime-Software auf die verschiedenen Windows-Clients zu verteilen. Als Messlatte gilt derzeit: Ein PC mit MS-Office kommt auch mit der .NET-Runtime zurecht. Nicht alle .NET-Anwendungen erfordern allerdings Installationen am Client. Die Programmierumgebung ASP+, eine Weiterentwicklung der Active Server Pages (ASP), lässt Web-Anwendungen in Form von Script- und neuerdings auch Bytecode direkt auf dem Server ablaufen. Clients benötigen für solche Anwendungen lediglich einen Browser. Je nachdem, welche Art von Anwendungen eingesetzt werden, könnte .NET Veränderungen an der Netzwerkinfrastruktur voraussetzen. Da das Framework HTTP als Daten- und Anwendungsprotokoll benutzt, dürften PCs, die auf eingehende HTTP-Verbindungen von .NET-Servern warten, von Netzwerk-Analyzern als Web-Server identifiziert werden.
VB-Script-Interpreter wird verschwinden
Microsoft warnt derzeit noch davor, die Pre-Betaversion auf Produktionsmaschinen einzusetzen. Wenn die Software fertig ist, werden sich aber die einzig gravierenden Eingriffe in das System aller Voraussicht nach auf die Visual-Basic-(VB-) und Jscript-Interpreter beschränken. .NET verändert die Scripting-Umgebung von Windows grundlegend, der VB-Script-Interpreter wird verschwinden. Jeglicher Visual-Basic- und VB-Script-Code wird zukünftig in Echtzeit in die Intermediate Language (IL) von .NET kompiliert und anschließend in der .NET-Laufzeitumgebung ausgeführt. Der Jscript-Interpreter wird ersetzt durch einen Jscript/ECMA-(European Computer Manufacturer´s Association Script-) Compiler, der in Microsofts neuer Programmiersprache C# (sprich: See sharp) geschrieben wurde.
Bei der Migration auf .NET müssen manche Anwender mit einer erhöhten Anforderung an Arbeitsspeicher und Prozessorleistung rechnen. Am stärksten dürfte es Dienste und Anwendungen treffen, die bisher in C++ geschrieben wurden. Das .NET-Framework unterstützt auch C++ und lässt dem Entwickler die Wahl, nativen Code oder IL-Code zu generieren. Im letzteren Fall steigt durch den Overhead der virtuellen Maschine die Hardwareanforderung drastisch an. Eher positiv dürfte sich der Umstieg von Visual Basic oder Java auf .NET auswirken. Hier ist sogar mit einem Leistungszuwachs zu rechnen.
Für Unternehmen ist es derzeit noch zu früh, mit der systematischen Planung und Schulungen für .NET zu beginnen. Unternehmensinterne Applikationsentwickler können allerdings .NET bereits jetzt in ihre Planungen für solche Programme mit einbeziehen, bei denen in etwa einem Jahr mit dem Coding begonnen wird.
Interessanterweise erweitert .NET keinesfalls die Sammlung der Enterprise-Services unter Windows 2000. Diese umfassen eine umfangreiche Middleware aus Transaktions-, Messaging- und Datenbank-Services, blieben wegen COM+ und einiger veralteter Entwicklungs-Tools bisher aber weitgehend unbeachtet. COM+ präsentiert sich Entwicklern mit einer verwirrenden Programmierschnittstelle, die sich in Abhängigkeit von der verwendeten Sprache und dem Entwicklungs-Tool jeweils verändert. .NET stellt sich hingegen als einheitliche, durchgängige Service-Schnittstelle dar, vergleichbar mit Java, aber mit dem Vorteil, dass Entwickler nicht an eine einzige Sprache gebunden sind.
Die zeitweilig geäußerte Vermutung, Microsoft werde .NET auch auf Nicht-Windows-Plattformen ausweiten, fand bisher keine Bestätigung. Für Projekte in heterogenen Umgebungen ist die Technik deshalb nach dem derzeitigen Stand nicht geeignet. Anwendungen jedoch, die für .NET geschrieben werden und auf Windows-Spezifika wie COM+, direkten Zugriff auf DLLs und andere proprietäre Microsoft-Standards verzichten, sollten irgendwann auch außerhalb von Windows laufen können. Für die Migration von bestehenden Anwendungen gibt es keinen zwingenden Grund, jedoch dürfte es sich in vielen Fällen lohnen, da mit höherer Sicherheit, Skalierbarkeit und besserer Wartbarkeit zu rechnen ist. Eine .NET-Anwendung ist auf höheren Systemebenen angesiedelt und birgt daher geringere Gefahren für das darunter liegende Betriebssystem.
IT-Verantwortliche sollten bei der Bewertung von .NET gesunde Skepsis walten lassen. Allem Anschein nach handelt es sich bei .NET für die Gates-Company um einen ähnlich bedeutenden Schritt wie einst die Einführung von NT. Es liegt nun an den Redmondern, die Entwicklung und Implementierung industrieweiter Standards voranzutreiben, um dem Produkt die versprochene Stabilität und Reife angedeihen zu lassen. Es lohnt sich in jedem Fall, die weitere Entwicklung von .NET mit der gleichen Aufmerksamkeit zu verfolgen wie Java 2 Enterprise Edition (J2EE) und den Linux-Markt. Alle drei Bereiche dürften in den nächsten Jahren zu den dominierenden Themen in der Unternehmens-IT gehören.
*Tom Yager leitet das Testcenter der CW-Schwesterpublikation "Infoworld" und besitzt langjährige Erfahrung in der Unix- und Windows-Entwicklung.
Das Ende des nativen Codes?
Ein Großteil der derzeitigen Entwicklungswerkzeuge für Windows kompiliert Programme in den nativen Code des jeweiligen Prozessors - Befehle werden dabei direkt auf der Hardware abgearbeitet. Im Gegensatz zu diesen herkömmlichen Kompilaten, die als Exe-Dateien (Executables) vorliegen, werden Java-Programme beispielsweise in den hardwareunabhängigen Bytecode übersetzt, der auf verschiedensten Hardwareplattformen mit Hilfe einer Java Virtual Machine zur Laufzeit in Maschinencode übersetzt und ausgeführt wird. Gar nicht kompiliert werden Programmscripts im Plaintext-Format, wie etwa Visual-Basic- oder Perl-Scripts. Sie werden von einem Interpreter zur Laufzeit übersetzt und abgearbeitet.
Der gravierende Nachteil aller interpretierten Sprachen ist, dass dieser Zwischenschritt die Programme deutlich verlangsamt. So galt dies lange Zeit als Handicap von Visual Basic - die Interpretation durch die zusätzlich benötigte Runtime-Bibliothek wirkte hier lange Zeit als Bremsklotz, bis eine schnellere Mischlösung angeboten wurde. .NET versucht einen Mittelweg zwischen nativem und interpretiertem Code. So erzeugen alle .NET-Compiler, ob für C#, Visual Basic oder die verschiedenen anderen Sprachen, einen Intermediate-Language-(IL-)Bytecode. Statt jedes Byte vor der Abarbeitung zu interpretieren, konvertiert ein Just-in-time-Compiler größere Blöcke der IL in Maschinencode, der dann direkt auf der Hardware läuft. IL kombiniert so die Vorteile von kleineren interpretierten Executables mit denen der Hardwareunabhängigkeit und erreicht dabei eine relativ hohe Arbeitsgeschwindigkeit. Microsoft gibt an, dass manche IL-Programme nur um zehn Prozent langsamer seien als native Programme. Durch die IL weitet .NET die versprochenen Verbesserungen hinsichtlich Sicherheit und Skalierbarkeit auf fast alle Programmiersprachen aus. Visual C++ wird eine der wenigen Sprachen sein, die weiterhin die Möglichkeit für nativen Code bieten.
.NET managt Programme
Programme, die für .NET geschrieben werden, werden als "Managed Applications" bezeichnet. Die Intermediate Language (IL) wird über die Common Language Runtime (CLR) ausgeführt. Die CLR weist Speicher zu und gibt ihn frei, ermittelt und lädt externe .NET-Objekte, wickelt die Kommunikation mit entfernten Anwendungen ab und erstellt prozessorunabhängige Datentypen.
Durch das Speicher-Management und die Kontrolle über Systemzugriffe macht CLR Anwendungen sicherer. Eine gemanagte Anwendung kann weder auf Speicherbereiche zugreifen, die ihr nicht zugewiesen sind, noch Objekte manipulieren, die bereits freigegeben wurden. Damit ist eine breite Palette von Softwarefehlern ausgeschlossen, die andere Programme oder das Betriebssystem zum Absturz bringen können. Durch das Definieren eines Satzes von prozessor- und sprachunabhängigen Datentypen befreit die CLR Programmierer von mühsamen und fehleranfälligen Datenumwandlungen.
Das Objektmodell von .NET ist völlig transparent. Programmierer definieren Objekte, indem sie lediglich die Methoden der jeweiligen Programmiersprache anwenden. Die CLR registriert diese Objekte automatisch und publiziert sie zur Benutzung für andere lokale oder verteilte Anwendungen.