Windows 8, HTML5 und die Folgen für .NET?

Seite 2: Architektursicht

Inhaltsverzeichnis

Damit dürfte klar sein, dass sich die Architektur zukünftiger Desktop-Anwendungen zunehmend an jene von Web- und mobilen Applikationen annähern wird: Das Frontend würde plattform- und geräteunabhängig in HTML5 und JavaScript geschrieben, das Backend per HTTP, REST und XML oder JSON auf Basis von AJAX und WebSockets angebunden.

Sicherlich bedingt eine derartige Architektur die Existenz eines Servers, der in der Lage ist, mit diesen Kommunikationstechniken umzugehen. Dass ein solcher Server auf der Microsoft-Plattform der IIS (Internet Information Services) darstellt, ist naheliegend. Allerdings verfügt er über einen gravierenden Nachteil: Eine IIS-Version ist an die des dem Server zugrunde liegenden Betriebssystems gekoppelt. Eine Aktualisierung des Webservers erfordert daher stets eine Aktualisierung von Windows – ein insbesondere für die Desktop-Entwicklung wenig ansprechendes Szenario.

Allerdings stellt Microsoft seit einigen Wochen Abhilfe bereit, und zwar in Form von IIS Express: Die Version 7.5 ist auf allen Versionen von Windows seit XP lauffähig und darüber hinaus nicht einmal als Dienst zu installieren. Das bedeutet zugleich, dass künftig jede Anwendung die von ihr benötigte Version von IIS Express enthalten kann, ohne dass sich verschiedene Versionen des Webservers in die Quere kämen. Derzeit stellt Microsoft IIS Express zwar primär als Werkzeug für Entwickler zur Verfügung, jedoch ist durchaus denkbar, dass sich die Ausrichtung noch ändern wird.

Auch die Entwicklung der vierten Version von SQL Server CE erscheint dadurch in einem anderen Licht, denn schließlich wäre er durchaus als moderner und zukunftsträchtiger Nachfolger von Access geeignet.

Das Szenario aus einer HTML5- und JavaScript-gestützten UI, IIS Express als Backend und dem SQL Server CE als Datenspeicher weist jedoch noch einen weiteren eklatanten Vorteil auf: Um aus einer Desktop- eine Web- oder gar eine mobile Anwendung zu machen, ist zukünftig nicht mehr erforderlich, als die UI gegebenenfalls an eine andere Bildschirmauflösung anzupassen und den Server nicht lokal auszuführen, sondern in das Web zu verlagern – Windows Azure lässt grüßen.

Der wesentliche Unterschied zwischen der neuen und der heutigen Welt besteht für Desktop-Entwickler darin, dass das Frontend zukünftig ausschließlich lose mit dem Anwendungsserver gekoppelt wird und dass dementsprechend eine Nachrichten- statt einer Stack-Kommunikation erfolgt – einschließlich aller Vor- und Nachteile. Das bedeutet nicht, dass jeder Entwickler gut beraten ist, sich mit einem Kommunikationsframework wie Windows Communication Foundation (WCF) auseinanderzusetzen, denn das ist gar nicht erforderlich: Die Fähigkeit, HTTP-Anfragen senden und empfangen zu können, genügt völlig.

Am ehesten gewöhnungsbedürftig ist für Desktop-Entwickler vermutlich die Statuslosigkeit des HTTP-Protokolls und die daraus resultierende Statuslosigkeit des Backends, was allerdings für jegliche Services und darauf aufbauende serviceorientierte Architekturen (SOA) seit Jahren gilt. Wer sich als Entwickler bislang erfolgreich um dieses Thema winden konnte, wird sich zukünftig eingehend damit auseinandersetzen müssen.

Doch es gibt eine gute Nachricht: Die verwendeten Techniken sind nicht nur seit Jahren erprobt, sondern auch nicht sonderlich kompliziert. Zudem wird diese Art der Entwicklung automatisch zu einer besseren Architektur von Anwendungen beitragen. Eine SQL-Anweisung direkt in das Frontend einzubetten wird zukünftig schlichtweg nicht mehr möglich sein.

Als gravierendes Argument gegen Webanwendungen wird häufig die – vermeintlich – mangelnde Geschwindigkeit angeführt. Roundtrips zum Server kosten schließlich Zeit, so die gängige Argumentation. Das lässt sich nicht pauschal entkräften, denn zu behaupten, ein Zugriff über das Netzwerk wäre ebenso schnell wie ein lokaler, wäre schlichtweg falsch.

Dennoch besteht Abhilfe: Da sich außer mit einer schnelleren Verbindung der eigentliche Zugriff nicht beschleunigen lässt, besteht das Kunststück darin, die Menge der zu übertragenden Daten zu minimieren und Server sowie Webbrowser gleichermaßen zu entlasten. Das gelingt hervorragend, wenn man nicht, wie im klassischen Web, ganze Webseiten überträgt, sondern ausschließlich kleine Datenpakete.

Hierfür stehen unterschiedliche Techniken bereit: von AJAX bis zu WebSockets. Frameworks wie Socket.io vereinfachen die Entwicklung solcher Anwendungen, indem sie verschiedene Kommunikationstechniken unter einer API auf transparente Art zusammenfassen. Socket.io könnte man daher durchaus aus Microsoft-Sicht als "WCF des Web" bezeichnen.