Was CIOs über .NET wissen sollten

Ersatz für COM, Grundlage aller neuen Microsoft-Produkte und Java-Killer – als all dies ist .NET bereits angepriesen worden, aber selbst Microsoft schwankt immer noch, wie das .NET-Konzept am besten zu vermarkten sei.

Virtual Machine-Technologie
Nachdem erst im letzten Jahr das Server-Betriebssystem der nächsten Generation in Windows .NET Server 2003 umbenannt wurde, machte Microsoft vor kurzem eine völlige Kehrtwende und änderte den Namen in Windows Server 2003. Die Funktionalität des neuen Server-Betriebssystems hat sich dabei nicht geändert – es wird immer noch die erste Server-Version des Windows-Boliden sein, die das .NET-Framework im Betriebssystem integriert hat.

Also ist Windows Server 2003 nun „.NET connected“. Diese neue Markenbezeichnung gibt an, ob ein Produkt andere .NET-Produkte von Microsoft oder von Drittanbietern verwendet oder mit diesen zusammenarbeitet. Aber damit CIOs endlich den wirklichen Wert von .NET von reinen Marketingsprüchen unterscheiden können, bedarf es mehr als etwas Markenkosmetik.

Das erste Schlüsselkonzept, das CIOs verstehen müssen, ist, dass die gesamte Plattform um einen zentralen Kernel angeordnet ist, der alle Zugriffe auf die Systemressourcen kontrolliert. Um die Relevanz dieser Struktur zu begreifen, muss man sich einmal die bisherige Windows-Architektur anschauen. Windows gibt Entwicklern eine Reihe von Services an die Hand sowie die APIs (Application Programming Interfaces), um darauf zugreifen zu können. Jedes Mal, wenn Entwickler direkt auf Systemressourcen wie Speicher, Ports oder Hardware zugreifen müssen oder wollen, können sie Windows „umgehen“. Wenn sie diese Ressourcen hinterher nicht wieder korrekt freigeben, wird die daraus resultierende Inkonsistenz zwischen der Windows-Umgebung und der zugrunde liegenden Hardware-Umgebung jedoch fast unausweichlich zu einem Crash, Speicherleck oder zu anderen das System destabilisierenden Ereignissen führen.

Dazu kommt: Auch wenn die Windows API recht konsistent ist, bringen die APIs für andere Services, die auf Windows aufsetzen (Datenzugriff, Message Queuing, HTTP-Zugang, Netzwerkprogrammierung, Sicherheit) alle ihre eigenen Unzulänglichkeiten mit sich und verlangen entsprechenden Lernaufwand.

Die .NET Platform ersetzt diese Ansammlung von Systemschnittstellen und Zugangspunkten durch einen einzigen zentralen Kernel, der verantwortlich ist für alle Zugriffe auf Hardware und Systemressourcen. Anwendungen, die mit dem .NET Framework entwickelt wurden, sind von daher stabiler, denn der Kernel kann Anwendungen davor bewahren, sich gegenseitig ins Gehege zu kommen. Die Schnittstellen zum Kernel werden als kohäsive, leicht zu verstehende und zu erweiternde hierarchische Sammlung von Klassen präsentiert. Diese Klassen stellen nicht nur die Schnittstelle zur Hardware und zu den Systemressourcen auf dem zugrunde liegenden System für den Entwickler dar, sondern enthalten auch Standardprotokolle der Industrie wie SOAP, WSDL, HTTP, SMTP, HTML und andere, die es Entwicklern ermöglichen, die .NET Platform zum Schreiben von Code unter Verwendung der Standard-Klassen zu benutzen, und dem Framework erlauben, die notwendigen Übersetzungen durchzuführen.

Da das .NET Framework Hardware und Systemressourcen als konsistente, Prozessor- und Betriebssystem-unabhängige Architektur präsentiert, können Microsoft (und andere Firmen) Versionen des .NET Frameworks auch auf anderen Betriebssystemen als auf Windows implementieren.

Microsoft hat Versionen des .NET Framework für x86-Rechner veröffentlicht, die unter Versionen von Windows ab Windows 98 Second Edition und für Windows-Powered Pocket PCs mit MIPS-, ARM-, SH3- und Intel PA-Architekturen laufen. Es gibt sogar für Studienzwecke eine Version des .NET Frameworks für BSD-Unix.