Microsoft hätte die Internet Information Services (IIS) 6.0 gut und gerne auch IIS 10.0 oder IIS 2003 nennen können, so gravierend sind die Änderungen im Vergleich zu den Vorversionen. Die gesamte technische Basis für die IIS wurde neu entwickelt. Das wirft zwei Fragen auf: Warum haben die Redmonder diesen Schritt getan? Und welche Konsequenzen haben solche fundamentale Änderungen für vorhandene Web-basierende Anwendungen?
Die erste Frage ist angesichts der Historie von Sicherheits- und Stabilitätsproblemen bei den IIS leicht zu beantworten. Die Architektur des Webservers war schlicht nicht optimal. Die grundlegende Technologie wurde seit der Einführung praktisch unverändert beibehalten. Spätestens mit der Version 3.0, als die Active Server Pages eingeführt wurden, ist Microsoft aber an die Grenzen gestossen: Der erste Release der Active Server Pages hat beim IIS 3.0 zu einigen Stabilitätsproblemen geführt.
Microsoft hat zwar in den Folgeversionen manche Optimierungen vorgenommen. Doch offensichtlich hat man in Redmond irgendwann erkannt, dass das Kurieren von Symptomen die IIS nur zu einer guten, aber nicht zu einer überragenden Lösung machen kann. Ohne grundlegende Eingriffe in die Server-Architektur geht es nicht.
Fundamentale Änderungen bringen den Nachteil mit sich, dass zwar die Basis besser wird, aber die meisten Anwendungen umgestellt werden müssen. Das haben bereits die Hersteller von Drucker- und Grafiktreibern in der Evolutionsgeschichte von Windows NT 3.1 zum Windows Server 2003 leidvoll erfahren. Diese Treiber wurden mal im Kernel-Mode, mal im User-Mode ausgeführt. Bei jedem Wechsel des Modus mussten die Anbieter ihre Treiber deutlich überarbeiten. Microsoft hat den Schritt zwar dadurch erleichtert, dass umfassende Grundfunktionen heute über im Betriebssystem integrierte Basistreiber bereitgestellt werden. Ein Aufwand bleibt dennoch.
Während eine solche Migration bei einer kleinen Zahl von Druckerherstellern noch funktioniert, wäre ein Aufstand der Anwender unvermeidlich, wenn diese alle ihre Web-basierenden, auf den IIS aufsetzenden Anwendungen plötzlich neu entwickeln müssten.
Dem zu erwartenden Aufstand hat Microsoft vorgebaut. Die bestehenden Anwendungen lassen sich ebenso nutzen wie Neuentwicklungen. Auch für vorhandene Web-Applikationen bringt die neue Architektur signifikante Vorteile in bezug auf Sicherheit und Stabilität. Das spricht für die gute Arbeit, die Microsoft in der Definition von Schnittstellen leistet. Die Anwendungen merken nicht, dass sie auf einer neuen Basis ablaufen. Microsoft hat dafür einen einfachen Trick angewandt: Die Ausführungsumgebung für die Applikationen steht nun oberhalb der neuen Basisarchitektur mehrfach zur Verfügung.
Um zu verstehen, was Microsoft bei den IIS besser gemacht hat, muss man sich das frühere Konzept anschauen. Bei den IIS zur Version 5.1 gibt es einen zentralen Prozess inetinfo.exe. Dieser läuft im User-Mode und unterstützt sowohl HTTP- als auch FTP-Dienste. Dieser Prozess ist auch für alle Erweiterungen verantwortlich, also beispielsweise für das IPP (Internet Print Protocol), für WebDAV und andere Dienste. Diese sind als ISAPI-Erweiterungen in Form von DLLs realisiert, die in den Prozess geladen werden. Der Prozess wird damit mehr und mehr aufgebläht. Jeder Fehler in einer Erweiterung kann ihn zum Absturz bringen. Zudem führen auch Angriffe auf die IIS mit einer solch zentralisierten Konzeption dazu, dass sehr schnell alle auf einem Server laufenden Anwendungen betroffen sind.
In der neuen Architektur nutzt Microsoft nun einen kleinen HTTP-Stack, der im Kernel-Mode läuft. Dieser macht nichts anderes, als die HTTP-Anforderungen aufzunehmen und an Warteschlangen weiterzuleiten. Diese Queues wiederum versorgen Anwendungspools mit den Anforderungen, wobei in einem Pool eine oder mehrere Anwendungen laufen können. Warteschlangen und Anwendungspools werden ebenso wie eine Komponente mit dem umständlichen Namen WWW Service Administration and Monitoring im User-Mode ausgeführt, also wie jedes andere Programm unter Windows auch.
Wichtig ist, dass sowohl die unter anderem für die Statusüberwachung zuständige WWW Service Administration and Monitoring-Komponente als auch der HTTP-Stack nicht durch zusätzliche Komponenten erweitert werden. Solche Add-ons können also künftig auch keine Fehler verursachen. Fehler von Anwendungen dagegen betreffen nur die einzelnen Anwendungspools und werden automatisch von WWW Service Administration and Monitoring behoben. Ebenso kann der HTTP-Stack automatisch neu gestartet werden, wenn es dort zu einem schwerwiegenden Fehler kommt. Die Anwendungen merken davon nichts, weil sie ja nur auf die Queues zugreifen. Nicht zuletzt ist auch die Kommunikation zwischen HTTP-Stack und Warteschlangen viel effizienter als im bisherigen monolithischen Modell. Microsoft hat mit dieser Neuentwicklung der IIS-Basis einen guten Job gemacht - und alles spricht dafür, dass sich das in höherer Stabilität und Sicherheit auszahlen wird.
Die Änderungen der IIS beschränken sich keineswegs auf die neue Architektur. Anwendungsentwickler etwa werden es schätzen, dass sie nun nicht mehr nur ASP, sondern auch ASP .Net nutzen und damit Web-basierende Anwendungen mit dem neuen .Net-Framework erstellen können, das wesentlich effizienter als der bisherige Ansatz ist. Die Koexistenz von ASP und ASP .Net ist möglich, auch wenn man ASP-Anwendungen nicht einfach zu ASP .Net migrieren kann. Neu ist auch ein integrierter UDDI-Server. Bei diesem irritiert aber, dass er nicht auf dem Active Directory, sondern auf der MSDE (Microsoft SQL Server Desktop Engine) basiert.
Der normale Anwender wird wie der Administrator von all dem wenig bemerken. Vielleicht liegt ja genau darin die Stärke des Windows Server 2003 - dass er in vielen Bereichen verbessert wurde, ohne dass man das Gefühl hat, schon wieder mit einem völlig neuen, komplexen Betriebssystem konfrontiert zu sein.
