Im Zentrum der Veranstaltung standen Microsofts neues Entwicklungs-Tool Visual Studio (VS) .NET und die .NET My Services, eine Serie von Basis-Internet-Diensten, die bisher unter dem Codenamen Hailstorm firmiert hatten. Für .NET My Services wurden nun konkretere Zeitpläne genannt. Auf der Konferenz händigte man den Entwicklern eine erste Preview-Version des Software Development Kits (SDK) sowie einen 500-Seiten-Wälzer mit den Spezifikationen aus. Im ersten Quartal 2002 soll ein weiteres SDK folgen, im zweiten Quartal wird mit ersten Datacenter-Tests bei Drittanbietern gerechnet. Nach einem weiteren SDK-Update sollen ab Ende 2002 die Dienste allgemein verfügbar sein. Bei den Lizenzgebühren sind verschiedene Modelle geplant. Ab 1000 Dollar pro Jahr und 250 Dollar pro Anwendung sind Entwickler dabei. Größere Unternehmen sollen 10000 Dollar pro Jahr sowie 1500 Dollar pro Anwendung zahlen müssen.
Größten Wert legen die Redmonder auf einen störungsfreien, zuverlässigen Betrieb: Während der Testphase wird die Zahl der Teilnehmer unter Berücksichtigung der Server- und Netzkapazitäten streng überwacht und begrenzt.
Noch herrscht auch unter Entwicklern einige Unklarheit über die konkrete Verwendung und den Nutzen der Services. Zum einen liegt das daran, dass sich die technische Umsetzung noch in einer frühen Phase befindet. Zum anderen dürfte es noch viele Fragen zum Geschäftsmodell geben. So viel ist klar: .NET My Services wie .NET Alert, .NET Calendar oder .NET Inbox stellen so etwas wie Standard-Schnittstellen dar, die sich jeder Entwickler zunutze machen kann. Statt wie bisher lokal liegen manche Programm-Schnittstellen nun im Internet - und setzen somit eine gehostete und mit Transaktionskosten verbundene Infrastruktur voraus.
Es gibt aber einen wesentlichen Unterschied zu den bisher weitgehend gescheiterten Modellen von Software-als-Service. Application-Service-Providing (ASP) stellte den Endanwender im Wesentlichen vor die Frage, ob er eine Software als Paket kauft oder bei einem ASP mietet. Beim Web-Service-Modell sind es in erster Linie Entwickler, die sich für die Integration eines Service als Basis- oder Zusatzfunktionalität für eine lokale oder im Web befindliche Anwendung entscheiden.
Der Anreiz für den Anwender liegt darin, in bestimmten Bereichen wie Calendaring oder E-Mail nun eine zentrale, Server-basierte Datenhaltung nutzen zu können. Dadurch könnte in Zukunft viel Synchronisierungsaufwand zwischen verschiedenen Clients wie PC, PDA und Notebook entfallen. Eines der ersten Anwendungsbeispiele hat Groove Networks auf der PDC vorgeführt. Der Spezialist für Peer-to-Peer-Groupware setzt die Betaversion von .NET Alert ein, um Kalendereinträge innerhalb von Arbeitsgruppen in Echtzeit auf externe Clients wie etwa den Outlook-Kalender eines Pocket PCs zu übertragen. Am Pocket-PC-Client musste Groove lediglich ein kleines Visual-Basic-Programm implementieren.
Entscheidend an den .NET My Services ist der anwenderzentrierte Ansatz. Jeder Zugriff über das Simple Object Access Protocol (Soap) erfordert die Authentifizierung des Users und der Anwendung. Überraschend kündigte Microsoft in diesem Zusammenhang übrigens an, den hauseigenen Passport-Dienst nicht mehr als alleinige Authentifizierungsinstanz zwingend zu verlangen. Stattdessen soll ein föderiertes Authentifizierungssystem auch andere Dienste wie etwa die von Sun oder AOL geplanten unterstützen.
Visual Studio .NET fast fertig
Einen wichtigen Schritt hat Microsoft bei seinem neuen Entwicklungs-Tool Visual Studio .NET gemacht. Offenbar kann das Unternehmen seinen Zeitplan für die Fertigstellung einhalten, auf der PDC wurde bereits der Release Candidate vorgestellt. Noch in diesem Jahr soll das fertige Tools erscheinen. Für die ungewöhnliche Termintreue gibt es handfeste Gründe. Denn Visual Studio .NET ist der Dreh- und Angelpunkt in der gesamten Web-Service-Strategie.
Eine besondere Herausforderung für Microsoft dürfte auch die Entwicklung einer neuen Client-Strategie gewesen sein, die den unvermeidlichen Einzug offener Standards glaubwürdig unterstützt und gleichzeitig die Vormachtstellung der Windows-Plattform aufrechterhält. Dieser zweigleisige Ansatz zieht sich nun mehr oder weniger deutlich erkennbar durch alle Technologiebereiche und wird von VS .NET in vielfältiger Weise unterstützt.
Spotlight: Microsoft definiert .NET: "Microsoft .NET My Services .NET Services service serves as directory for all .NET My Services services" (Zitat eines PDC-Redners)
Um zu verstehen, welche Fragen die Gates-Company mit .NET zu beantworten versucht, muss man zunächst die Defizite der existierenden Windows-Architektur betrachten. Microsoft-Anwendungen waren bisher immer auf die Ausführung am lokalen PC ausgelegt (Computerwoche online berichtete). Dieses Modell geriet mit dem Aufkommen des Internet und der weit reichenden Vernetzung von Computern zunehmend in Misskredit. Neben der proprietären Plattform erwiesen sich vor allem die systemimmanenten Sicherheitsprobleme als Hindernis für Entwickler, die seriöse Internet-basierte Anwendungen schreiben wollten.
Renaissance der Windows-Anwendungen?
Mit .NET reagiert die Gates-Truppe auf diese Probleme und versucht vor allem, die verschmähten Client-Anwendungen wieder attraktiv zu machen. Im Zentrum steht dabei die Einführung des Frameworks "Windows Forms". Es handelt sich hierbei um Klassen aus dem .NET-Framework. Diese ermöglichen die Programmierung von klassischen Windows-Client-Anwendungen und nutzen dabei alle Vorteile der .NET-Laufzeitumgebung CLR (Common Language Runtime) wie Sprachunabhängigkeit und die Codeausführung in der geschützten Sandbox. Zudem verspricht Microsoft Kostenersparnisse durch ein einheitliches Programmiermodell und eine vereinfachte Softwareverteilung. Die formularbasierte Entwicklung ist für Visual-Basic-Kenner nicht neu: Das Aussehen einer Anwendung mit ihren Fenstern, Menüs, Eingabefeldern und Knöpfen ist dabei unmittelbar mit dem Schreiben des Programmcodes verknüpft. C++-Programmierer bedienten sich bisher einer völlig anderen, umständlicheren Arbeitsweise unter
Rückgriff auf die Windows-APIs oder die Microsoft Foundation Classes (MFC).
Was bisher nur mit Java vernünftig möglich war, das Ausführen von Client-Programmen über das Internet, kann jetzt dank der abgesicherten Laufzeitumgebung bedenkenlos auch mit Windows-Programmen realisiert werden. Die Zugriffe auf das lokale System regeln Anwender oder Administratoren durch die Angabe von Sicherheitszonen. Hieraus resultieren einschneidende Auswirkungen auch auf die Verteilung von Software in Unternehmen sowie die Stabilität und Administrierbarkeit von Anwendungen. Softwareverteilung bedeutet im Rahmen des .NET-Szenarios nicht mehr zwingend, auf jedem Client eine Installationsroutine vorzunehmen. Gerade in diesem Bereich machte sich Windows bisher als Kostenfaktor bemerkbar, denn für die Verteilung und das Verwalten von Client-Anwendungen sind ausgeklügelte Strategien und kostspielige Deployment- und Management-Tools notwendig.
Einfache Softwareverteilung
Mit .NET-Anwendungen dürfte ein bisheriges Horrorszenario - die Ausführung einer Exe-Datei über einen Hyperlink - seinen Schrecken verlieren und könnte zum Standard werden. Ebenso einfach lässt sich eine zentral gespeicherte Anwendung im gesamten Unternehmen ohne Installation bereitstellen - am Desktop reicht eine Verknüpfung auf ein Netzwerk-Share. Komplexere Anwendungen können mit Hilfe von Auto-Update-Funktionen lokal gespeichert und ausgeführt werden. Versagt ein Software-Update seinen Dienst oder taucht ein Bug auf, reicht die Modifikation einer zentralen Config-Datei mit einem Zeiger auf das alte Programmverzeichnis, um den alten Zustand wiederherzustellen.
COM- und .NET-Komponenten lassen sich gemeinsam verwenden, ohne dass man in solchen Fällen auf alte Mechanismen wie die Registrierung in der Registry zurückgreifen müsste. So will Microsoft einen reibungslosen Übergang zwischen den beiden Technologien gewährleisten.
Plattformunabhängigkeit
Windows-Forms-Anwendungen sind darüber hinaus Web-Service-fähig - schließlich soll Windows nach dem Willen von Microsoft auch in der kommenden Web-Service-Epoche das bevorzugte Client-System sein. Interessant ist hierbei die Tatsache, dass die Steuer- und Designelemente der Windows Forms auch in Browser-basierte Anwendungen integriert werden können. Der Übergang von einer komplett Browser-basierten zu einer reinrassigen Windows-Anwendung verschwimmt somit zunehmend. Auch beim Thema Plattformunabhängigkeit will sich die Gates-Company keine Blöße geben. Mit neuen Erweiterungen wie den "Smart Device Extensions" können beliebige Clients wie etwas PDAs adressiert werden.
Ein weiteres Argument, das .NET-Anwendungen Vorschub leisten könnte, sind die mangelhaften Gestaltungsmöglichkeiten von HTML für Desktop-Anwendungsoberflächen. Obwohl derartige Anwendungen in den letzten Jahren unter der Losung "Plattformunabhängigkeit" eine weite Verbreitung gefunden haben, lassen sie in Sachen Bedienkomfort meist zu wünschen übrig. Windows-Anwendungen haben nicht zuletzt wegen ihres einheitlichen Look and Feel und stringenter Bedienkonzepte ihre Popularität erlangt. Mit den Windows Forms werden sie nun Web-Service-fähig und erhalten noch weitere neue funktionale und multimediale Features.
Auch wenn Web-Services alte Plattformschranken weitgehend beseitigen, so werden in der Softwareindustrie wohl kaum alle Karten neu gemischt. Microsoft steht im neuen Spiel wieder an vorderster Front. Zwar herrschen über das Geschäftsmodell von .NET My Services noch Unklarheiten, aber wenn kein Wunder geschieht, werden die Redmonder als Erste ein Basis-Set an grundlegenden Diensten anbieten, die dann Standards setzen. Auch den Windows-Client bereitet man in allen Belangen auf das Web-Service-Zeitalter vor. Mehr Sicherheit und vereinfachte, kostengünstigere Softwareverteilung sollen den Desktop als sichere Einnahmequelle aufrechterhalten. Nicht zu vergessen ist der integrierte Entwicklungsansatz, der es Programmierern einfach macht, Anwendungen unter Nutzung aller Schnittstellen von den alten Win32 bis zu .NET zu schreiben.