Gestärktes Paar
Der Internet Information Server ist von jeher Bestandteil des Windows Server. Im Vergleich zum Vorgänger haben die Redmonder in der Version 7.0 eine Reihe grundlegender Änderungen vorgenommen. Neuerungen im ASP.Net-Umfeld fallen dagegen bescheidener aus.
- Dr. Holger Schwichtenberg
- Christian Segor
Zusammen mit dem Windows Server 2008 liefert Microsoft einen generalüberholten Webserver aus – den IIS 7.0 [1]. Dem Administrator fällt als Erstes die nunmehr weitgehend modularisierte Architektur auf. Wer die IIS-Serverrolle mit dem Win2k8-Manager installiert, hat die Auswahl aus gut 40 unterschiedlichen „Role Services“ (s. Abb. 1) und wird, anders als im Screenshot dargestellt, natürlich nur die Komponenten auswählen, die er für den Betrieb tatsächlich benötigt.
Diese Einschränkung auf das wirklich Wichtige erhöht die Stabilität des IIS7, reduziert die Komplexität, eliminiert eventuell unerwünschte Wechselwirkungen mit nicht benötigten Modulen und verringert den administrativen Patch-Aufwand. Zudem fördert ein solchermaßen verschlankter IIS die Sicherheit. Weniger Komponenten bedeuten weniger Code, in dem sich Sicherheitslecks verbergen können.
Diese Modularität schlägt sich auch in der Processing Pipeline des IIS7 nieder. Während IIS6 über eine „monolithische“ Pipeline verfügte, die man bestenfalls per ISAPI erweitern konnte, ist die Pipeline in der neuen Version deutlich schlanker geworden. Eine Anfrage durchläuft nur noch die wirklich benötigten Stationen, die der Administrator bei der Installation in Form von Role Services ausgewählt hat. Ähnliches gilt für die Integration von ASP.Net. In der Vorgängerversion als ISAPI-Filter implementiert, ist ASP.Net im IIS7 direkt in die Pipeline integriert. Der Entwickler kann auf diesem Weg mittels ASP.Net-APIs den Funktionsumfang des IIS erweitern und an jeder Stelle in die Pipeline eingreifen.
Auch Programmierer, die ihre Webanwendungen lieber mit PHP oder Ähnlichem entwickeln, finden mit IIS7 eine geeignete Plattform. Microsoft bietet eine Implementierung der FastCGI-Schnittstelle. FastCGI [a] ist eine schon etwas betagte Weiterentwicklung des noch betagteren CGI-Standards, der dazu dient, auf einem Webserver Anwendungen zu starten und deren Ausgabe an den Client zurückzuschicken. Sie verringert die ursprünglichen Performance-Probleme von CGI; die „Fast-Version“ ist laut Microsoft bis zu 25-mal schneller; übrigens gibt es sie auch für den IIS6 [b].
Im Bereich der Systemadministration hat sich einiges getan. Vor allem wurde die berüchtigte Konfigurationsdatenbank Metabase abgeschafft. An ihre Stelle treten die vom .Net-Framework bekannten XML-basierten config-Dateien, also nicht mehr solche voller kryptischer Code-Zahlen, sondern „human readable“. Den Speicherort der Dateien kann der Administrator frei definieren (auch UNC-Pfade sind möglich), sodass sich eine verteilte Konfigurationstopologie aufbauen lässt. Darüber hinaus kann man die Datei von Server zu Server kopieren, um auf diese Art eine einheitliche Konfiguration zu erreichen.
Die grafische Administrationsoberfläche ist kaum wiederzuerkennen: kein Verirren mehr in labyrinthischen, reiterüberfrachteten Konfigurationsdialogen, sondern eine klar strukturierte Verwaltungskonsole. Eine Remote-Administrationskonsole für XP und Vista steht im IIS Download Center ebenfalls zur Verfügung. Darüber hinaus existieren für die IIS-Verwaltung ein Kommandozeilen-Tool namens AppCmd, eine API und eine WMI-Schnittstelle.
Ajax in ASP.Net 3.5 eingebunden
Zwar ist ASP.Net 3.5 eine Erweiterung zur 3.0-Version, was sich an einer zusätzlichen Assembly (System.Web.Extensions.dll) zeigt, der IIS7 kennt aber kein „ASP.Net 3.5“. Dort muss man auch nach der Installation von ASP.Net 3.5 weiterhin „ASP.Net 2.0.50727“ für eine Website auswählen.
Das 3.0-Framework, das im November 2006 erschienen ist, enthielt keine Neuerungen für Webentwickler, wenn man von der Möglichkeit absieht, mit „Windows Presentation Foundation“ (WPF) entwickelte Anwendungen im Internet Explorer betreiben zu können. Diese „Web Browser Applications“ (WBAs) erfordern jedoch auf dem Client das Framework 3.0, und somit waren sie auf den Explorer von Microsoft angewiesen. „Echte“ .Net-Webanwendungen mit ASP.Net hingegen erfordern das Framework nur auf dem Webserver. Der Client erhält nur „browserunabhängige“ Standards wie (X)HTML, DHTML/DOM, CSS und Javascript.
Bereits mit der Ajax-Extension, die nun Bestandteil der 3.5-Version sind, hat Microsoft die Grundlagen fĂĽr mehr clientseitige Programmierung gelegt. Die Erweiterung besteht aus einer Sammlung umfangreicher Javascript-Bibliotheken sowie neuen Steuerelementen fĂĽr ASP.Net. Im Zentrum steht dabei das ScriptManager-Steuerelement, das die fĂĽr die jeweilige Seite notwendigen Javascript-Skripte einbindet beziehungsweise dynamisch erzeugt.
Zwei Verfahren konkurrieren hier miteinander: die partielle Seitenerzeugung und die Skript-Dienste. Bei der partiellen Seitenerzeugung definiert der Entwickler durch UpdatePanel-Steuerelemente eine oder mehrere Regionen, die der Server bei einem Rückruf auswechseln soll. Die Darstellung für die einzelnen Seitenregionen erzeugt weiterhin der Webserver. Durch Trigger (z. B. eine Schaltfläche, einen Hyperlink, ein Auswahlfeld oder einen Timer) definiert der Entwickler, unter welchen Bedingungen sich welche Regionen aktualisieren sollen. Das Verfahren ist einfach ohne eine einzige Zeile selbstentwickelten Javascript-Codes umsetzbar, der Benutzer hat das typische Ajax-Erlebnis einer flackerfreien Anwendung. Dieses Verfahren reduziert die Belastung des Webservers und den Netzverkehr aber leider kaum.
Bei den Skript-Diensten erstellt der Entwickler innerhalb der Seite eine spezielle Server-Methode oder einen Webservice, die aus dem Browser heraus ĂĽber Javascript ansprechbar sind. Dabei generiert der ScriptManager einen passenden Javascript-Proxy fĂĽr den serverseitigen .Net-Code. Um Serialisierung und Deserialisierung via JSON oder XML muss sich der Entwickler nicht kĂĽmmern.
Neu ist, dass man mit WCF erstellte Dienste (.svc-Dateien) direkt aus Javascript aufrufen kann. Da Script-Dienste in der Regel nur Daten senden, obliegt die Darstellung dem Javascript im Browser. Das Verfahren entlastet Webserver und Netzwerk, belastet aber den Entwickler. Immerhin bietet die neue IDE rudimentäre Intellisense und einen guten Debugger für Javascript.
Darüber hinaus enthält ASP.Net 3.5 noch drei nennenswerte Neuerungen: die ListView-, DataPager- und LinqDataSource-Steuerelemente. ListView dient der Darstellung einer Datenmenge in einem beliebigen Layout. Im Gegensatz zu den anderen datengebundenen Steuerelementen besitzt ListView einen Assistenten, der die XML-Vorlagen für verschiedene Gestaltungsalternativen automatisch erstellt.
Weniger spektakulär sind die DataPager-Klasse, die Paging-Funktionen für datengebundene Steuerelemente bereitstellt, und LinqDataSource, die es ermöglicht, LINQ-to-SQL-Datenkontext als Datenquelle auf einer ASP.Net-Webseite zu verwenden. Darüber hinaus hat Microsoft im Wesentlichen in ASP.Net 3.5 Funktionen integriert, die es vorher als Add-on gab. Mehr ist erst Mitte des Jahres mit den 3.5-Extensions [c] zu erwarten.
Dr. Holger Schwichtenberg
unterstützt mit seiner Firma www.IT-Visions.de Unternehmen beim Einsatz von .Net-Technologien, hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher.
Christian Segor
ist Technologie-Berater bei der GlĂĽck & Kanja Consulting AG in Stuttgart.
Literatur
[1] Mitch Tulloch et al.; Introducing Windows Server 2008; Microsoft Press 2007
In der Printausgabe finden Sie auĂźerdem Artikel zum neuen Betriebssystem (Windows Server 2008), Visual Studio 2008 sowie dem DBMS SQL Server.
| ASP.Net-Geschichte | ||||
| ASP.Net-Version | .Net-Version | CLR-Version | Visual-Studio-Version | erschienen |
| 1.0 | 1.0 | 1.0 | 2002 | Januar 2002 |
| 1.1 | 1.1 | 1.1 | 2003 | April 2003 |
| 2.0 | 2.0 | 2.0 | 2005 | Oktober 2005 |
| 2.0 + Ajax Extensions | 2.0 / 3.0 | 2.0 | 2005 mit Erweiterung oder 2008 | Januar 2007 |
| 3.5 | 3.5 | 2.0 | 2008 | November 2007 |
| 3.5 + Extensions | 3.5 | 2.0 | 2008 | geplant fĂĽr Mitte 2008 |
(wm)
