Softwaretrends/Microsoft definiert Windows-Frontends neu

.NET: Klassische Server und smarte Clients

13.06.2003
Die .NET-Strategie von Microsoft hat in den letzten drei Jahren seit Bekanntgabe einige Überarbeitungen erfahren. Für viele überraschend wurde etwa dem neuen Windows-Server das .NET-Kürzel genommen. An den Grundzügen der Web-Service-orientierten Architektur halten die Redmonder jedoch fest - mit neuen Schwerpunkten auf der Client-Seite. Von Wolfgang Miedl*

.NET war bei Bekanntgabe Mitte 2000 zunächst eine Technologieplattform mit zwei wesentlichen Ausprägungen: Einerseits ermöglichte sie das Entwickeln und Bereitstellen von XML-Web-Services, andererseits stellte sie eine neue Alternative dar zu dem allgegenwärtigen, aber in die Jahre gekommenen Windows-Programmiermodell COM (Component Object Model). Während es in der ersten Phase vor allem darum ging, Entwickler für die neue Architektur zu gewinnen, wurden eilends auch einige Produkte mit dem Kürzel .NET versehen. Betroffene Anwendungen wie der Biztalk Server verfügten zwar über gewisse XML-Fähigkeiten, in der Öffentlichkeit wurde die .NET-Etikettierung jedoch vielfach als irreführend kritisiert.

Mit dem neu erschienenen Windows 2003 Server hat Microsoft nun eine überraschende Kehrtwende vollzogen: Beim strategisch wichtigsten Server-Produkt hat die Gates-Company in der letzten Entwicklungsphase das .NET-Suffix fallen lassen. Dabei handelt es sich aber keinesfalls um einen Strategie-, sondern um einen Kommunikationswechsel, wie John Rymer, Analyst bei der Giga Information Group, feststellt. Einerseits gab es verunsicherte Kunden, die die .NET Server für reine Web-Services-Plattformen hielten, erläutert Rymer. Andererseits kursierte in vielen Unternehmen die Annahme, dass .NET eine "Alles-oder-nichts"-Lösung sei, die eine völlig neue Infrastruktur erfordere.

Tatsächlich ist Windows Server 2003 in weiten Teilen eine überarbeitete Version des Windows 2000 Server, der zum überwiegenden Teil auf den traditionellen Win-32-Programmier-Schnittstellen basiert. Neu ist die standardmäßige Integration des aktuellen .NET-Frameworks 1.1. Damit ist die Grundlage geschaffen für die Ausführung von .NET-Programmen, die in Form des so genannten Managed Code vorliegen. Im Gegensatz dazu werden "alte" Win-32-Anwendungen als Unmanaged Code bezeichnet. Der Vorteil von Managed Code liegt unter anderem in der kontrollierten, auf einem Berechtigungskonzept aufbauenden Ausführung.

Common Language Runtime als Kontrollinstanz

Realisiert wurde dieses Konzept durch die der Java Virtual Machine ähnliche Laufzeitumgebung Common Language Runtime (CLR). Ganz anders arbeiten bisherige, native Windows-Programme: Sie laufen unkontrolliert auf jeder PC-Plattform ab und öffnen damit Viren und anderen Schädlingen Tür und Tor. Ein .NET-Programm wird bei der Ausführung zwar mittels eines Just-in-Time-(JIT-)Compilers ebenfalls in den Maschinencode des Rechners übersetzt. Durch die zwischengeschobene Laufzeitumgebung CLR können dabei aber alle Zugriffe auf Dateisystem, Netzwerk oder Hardware überwacht und je nach Berechtigungskonzept auch unterbunden werden. Falls etwa eine in einer Web-Seite integrierte Exe-Datei im Browser aufgerufen wird, könnte dieses Programm zwar beispielsweise eine Animation und Musik abspielen, nicht jedoch Dateien oder die Registrierdatenbank auslesen beziehungsweise manipulieren.

Noch ist kommerzielle .NET-Software dünn gesät. Das liegt zunächst daran, dass die Entwicklergemeinde sich erst mit den neuen Programmierwerkzeugen vertraut machen muss. Hier geht es vor allem um die Programmiersprache C# sowie ein aufgrund der Anforderungen des .NET-Frameworks stark modifiziertes Visual Basic .NET. Hinzu kommt, dass das Starten eines .NET-Programms zunächst die Installation des kostenlos verfügbaren .NET-Frameworks voraussetzt. Unproblematisch ist dieser Umstand für Unternehmen. Hier werden die in Windows fehlenden, für .NET benötigten Komponenten in der Regel im Rahmen von IT-Projekten auf Server und Clients verteilt.

Betrachtet man die Verbreitung von Managed-Anwendungen, so gibt es derzeit noch eine klare Trennlinie zwischen Betriebssystem und Server-Produkten einerseits und den darauf gehosteten Anwendungen. Microsoft setzt auch bei seinen unter dem .NET-Logo vermarkteten Servern nach wie vor auf die Unmanaged-Technik. In diesem Szenario dienen etwa Internet Information Services (IIS) und SQL-Datenbank-Server als Unmanaged-Application-Server-Plattform, die die Common Language Runtime und ASP .NET (Active Server Pages) bereitstellen. Darauf aufsetzend soll die Geschäftslogik nach Empfehlung von Microsoft als Managed-.NET-Anwendung ablaufen.

Bis die gesamte Microsoft-Produktpalette auf Managed Code umgestellt ist, wird noch etwas Zeit vergehen. Bei künftigen Produkten wie dem SQL-Server-Nachfolger (Codename Yukon), der nächsten Biztalk-Version (Jupiter) oder Office 12 ist aber mit einer weit reichenden Umstellung auf das .NET-Framework zu rechnen. Laut Andreas Siebe, leitender Technologieberater bei Microsoft Deutschland, steht der Umstieg auf das .NET-Framework definitiv auf der Tagesordnung. Tatsache sei aber auch, dass das .NET Framework immer noch über die Enterprise Services auf native Dienste des Win-32-Systems zugreife.

Auch Microsoft mit einem Application Server

Neu ist für Microsoft die Einführung des Begriffs "Application Server". Damit reagiert das Unternehmen offenbar auf die Erwartungshaltung im Markt, die durch die Java/J2EE-Application-Server geprägt wurde. Windows erfüllte bereits bisher mit seinen integrierten Server-Diensten alle Voraussetzungen dafür, man verzichtete aber auf eine Vermarktung unter dieser Bezeichnung. Mit dem Windows Server 2003 wurde nun jedoch eine neue Management-Konsole namens "Application Server" eingeführt. Darin präsentiert sich die Verwaltung des .NET-Frameworks, der Internet Information Services sowie der Komponentendienste. Interessant ist die zahlenmäßige Bedeutung des Windows Application Servers. Giga hat die Nutzungsarten untersucht und geht davon aus, dass 2002 zwischen 15 und 25 Prozent der Windows-Server als Application Server eingesetzt wurden, der Rest in den klassischen Segmenten Datei- und Druckdienste, Exchange sowie SQL Server.

Nach Fat und Thin Client nun der Smart Client

Eine große Bedeutung misst Microsoft im Rahmen der derzeitigen .NET-Aktivitäten dem Client-Thema zu. Erst vor kurzem wurde hierzu der Begriff "Smart Client" eingeführt, um Windows auf Endgeräten neu zu definieren. Es handelt sich dabei keineswegs um ein neues Produkt, sondern um die Umsetzung des .NET-Anwendungsmodells für Clients - vom Smartphone bis zum PC. Charakteristisch dafür ist, dass es sich um Managed-Code-Software handelt, die je nach Endgerät auf dem .NET Framework oder dem .NET Compact Framework läuft. Grundlage dafür sind die "Windows Forms" - die neuen Klassenbibliotheken für Programme auf der grafischen Windows-Benutzeroberfläche. Microsoft adressiert damit ein Kernproblem bisheriger Windows-Anwendungen im Internet-Zeitalter: COM-Anwendungen können aufgrund der genannten Sicherheitsrisiken weder als im Browser integrierte Elemente (Active X) noch als herkömmliche Windows-Anwendung über das Web angeboten oder verteilt werden. Vor allem große Firmen mussten bisher für PC-Clients aufwändige und kostspielige Verteilungs- und Management-Software einsetzen.

Als Alternative wurden in den letzten Jahren vielfach Browser-basierende Anwendungen entwickelt. Sie ermöglichen eine einfache, zentralisierte Bereitstellung und Verwaltung. Ein weiterer großer Vorteil ist die Zugriffsmöglichkeit von jedem Ort und jeder Plattform aus - auch über einen Thin Client. Als gravierender Nachteil solcher Lösungen hat sich jedoch die bescheidene Bedienbarkeit (Usability) gegenüber GUI-Anwendungen (GUI = Graphical User Interface) erwiesen, die ihre Ursache in den prinzipiellen Beschränkungen von HTML hat. Überdies erfordern Web-Anwendungen eine ständige Verbindung ins Internet.

Windows-Forms-Software für .NET verfügt über dieselben äußerlichen Merkmale wie Win-32-Anwendungen - also Fenster und eine Vielzahl an grafischen Steuer- und Interaktionselementen. Allerdings lässt sie sich im sicheren Kontext ausführen und automatisch über das Web verteilen, ohne dass eine lokale Installation notwendig ist. Zudem bieten sie sich als Frontend für Web-Services an. Aufgrund neuer technischer Konzepte sind DLL-Konflikte ausgeschlossen und Registry-Einträge überflüssig. Mit neuen Datenbank-Schnittstellen ist auch die Entwicklung von Anwendungen möglich, die mit unterbrochener Netzanbindung zurechtkommen.

Für Entwickler ergeben sich aber noch andere Vorteile. So lassen sich bei Verwendung integrierter Programmierumgebungen wie Visual Studio .NET sowohl Windows-Forms-Anwendungen als auch deren Derivate mit Browser-Oberfläche (Web Forms in ASP.NET) erstellen, wie Sigurd Helling, Practice Director .NET bei der Avanade Deutschland GmbH in Kronberg, betont. Dies sei zum Beispiel für große Unternehmen wie Banken oder Versicherungen von Vorteil, wo es vom Thin Client bis zum Tablet PC eine Reihe von Zielplattformen gibt. Die Geschäftslogik wird in solchen Umgebungen idealerweise als XML-Web-Service bereitgestellt. Darauf greifen dann unterschiedliche Fachanwendungen zu, die je nach Anforderungen der Abteilungen an das User Interface auf Web- oder Windows-Forms-Basis entwickelt werden. Dabei bietet .NET mit den Self-Deploying-Windows-Forms als Smart Client eine attraktive Variante an. Diese Flexibilität gebe in der Praxis durchaus Sinn, so Helling: Während in vielen Szenarien ein Browser-Interface ausreiche, erfordern beispielsweise Call-Center-Anwendungen ein hohes Maß an Ergonomie, die mit HTML nicht in vergleichbarer Form umsetzbar sei.

Deutlich entschärft hat sich nach Einschätzung vieler Experten die Konkurrenzfrage zwischen .NET und Java/J2EE. Dies liegt nach Ansicht von Walter Seemayer, der als Direktor der Developer Group bei Microsoft für die .NET-Aktivitäten verantwortlich zeichnet, vor allem an der neuen Offenheit der Systeme durch den Einsatz von Web-Service-Schnittstellen. Während sich in den vergangenen Jahren der Expertenstreit vielfach um die Frage "Entweder J2EE oder .NET" gedreht hat, setzen mittlerweile sehr viele Unternehmen auf beide Plattformen. Motiv für eine solche zweigleisige Strategie sei der Wunsch nach Wahlmöglichkeit. Viele Firmen wollen nicht an eine Plattform oder einen Hersteller gebunden sein. Zudem sei in jedem größeren Unternehmen Know-how für beide Plattformen vorhanden, das somit genutzt werden könne.

Auch die Hersteller von Entwicklungs-Tools stellen sich längst auf die Koexistenz beider Plattformen ein. Die Beherrschbarkeit solcher Mischumgebungen sei jedenfalls kein Problem mehr, wie Wolfgang Bertol, Leiter Marketing bei Rational Software/IBM Software Group, meint: "Wir bieten integrierte Entwicklungsumgebungen an, die sowohl J2EE als auch .NET unterstützen. Damit ist die Frage nach der Zielplattform der Entwickler für uns weitgehend irrelevant."

Die Entwicklung eigener, gehosteter Web-Services - eines der großen Projekte der ersten .NET-Phase - hat Microsoft mittlerweile weitgehend eingestellt.

Der derzeitige Fokus von .NET liegt klar auf dem Unternehmenssektor. Web-Services werden - nicht zuletzt aus Sicherheitsgründen - bisher überwiegend intern eingesetzt. Auch .NET-Anwendungen auf Managed-Code-Basis haben vorwiegend in Projekten Sinn, die eine Verfügbarkeit des .NET Frameworks auf allen Maschinen sicherstellen können. Die weitere Ausbreitung hängt nicht zuletzt von Microsofts Aktivitäten selbst ab. (ue)

*Wolfgang Miedl ist freier Fachjournalist in Erding.

Angeklickt

Mit .NET hat Microsoft nicht nur eine neue Basis für zukünftige Windows-Anwendungen, sondern auch die Möglichkeit für die universelle Verbindung von Prozessen und Geräten mittels Web-Services geschaffen. Derzeit steht die schnelle Entwicklung von Server-gestützten Geschäftsanwendungen im Vordergrund, doch mit dem Konzept "Smart Client" soll die klassische Microsoft-Domäne Windows-PC eine Renaissance auf anderem Fundament erleben - mobile und neue Endgerätegattungen eingeschlossen. Bis Microsoft alle Produkte in jeder Hinsicht auf .NET umgestellt haben wird, dürfte allerdings noch einige Zeit vergehen.

Abb.1: Integration via Web-Services

Microsoft integriert Systeme über die in .NET unterstützte Technik für Web-Services. Damit ist auch eine Brücke zur Java-Welt geschlagen. Quelle: Microsoft

Abb: Schrittweiser Übergang

Managed-Anwendungen für .NET werden durch die Common Language Runtime (CLR) völlig von Hardware und Betriebssystem-Kern abgeschottet. Die derzeit noch üblichen nativen Win-32-Anwendungen (unmanaged) können ihrerseits eine Runtime hosten, die eine kontrollierte Codeausführung ermöglicht. Quelle: Microsoft