Das Microsoft-Internet

.NET und was dranhängt

Trends & News | Trend

Mitte Februar ist es so weit: Microsoft wird einen wesentlichen Meilenstein seiner .NET-Strategie erreichen und Werkzeuge für Entwickler in endgültiger Version in Umlauf bringen. Zeit für eine Bestandsaufnahme, was Microsoft mit diesem Schritt bis jetzt erreicht hat, und einen Blick in die Zukunft, was .NET dem Anwender bringt und was das fürs Internet bedeutet.

Aufmacher

Die ‘.NET-Strategie’ ist nur schwer zu fassen, weil sie weit reichende, ehrgeizige Ziele ansteuert: Microsoft will den PC mit den modernen Gadgets wie Mobiltelefon und PDA verheiraten. Informationen, die auf einem Gerät zur Verfügung stehen, etwa Adressbücher und Termindaten, sollen auch auf den anderen einseh- und manipulierbar sein. Das Internet spielt dabei als gemeinsames Kommunikationsmittel die tragende Rolle.

Doch .NET ist mehr: Es besteht aus einem umfangreichen Satz von Werkzeugen zur Softwareentwicklung fürs Internet, für Windows-PCs und für alle erdenklichen anderen Gerätschaften. Außerdem hofft Microsoft auf einen neuen Verkaufsschub für seine Server-Produkte und hat sie vorsorglich schon einmal mit dem .NET-Attribut geschmückt, obwohl das zurzeit mehr verspricht, als tatsächlich drin ist. Auf absehbare Zeit wird sich das Versprechen wohl aber weit gehend erfüllen.

Zu diesen klassischen Produktfeldern gesellt sich mit .NET ein neues Service-Angebot. Unter dem Mantel von .NET will Microsoft einen erneuten Anlauf nehmen, Dienste zu verkaufen: Die ‘.NET myServices’ sollen die Erreichbarkeit heute schon auf einzelnen Websites nutzbarer Kalender und Adressbücher auf das Handy und den PDA ausdehnen und zu einer neuartigen Kommunikationsplattform verschmelzen.

Anwendungsszenarien sollen Geschmack an der neuen Technik wecken: Eine Opernliebhaberin könnte über myServices zum Beispiel Hinweise auf Konzerte in ihrer Nähe beziehen. Auf solche Hinweise hin könnte sie Karten bestellen und auch gleich elektronisch bezahlen. Ihr Kalender würde nicht nur einen geeigneten Termin finden, sondern auch sofort einen entsprechenden Eintrag vornehmen - eine Erinnerung zum rechten Zeitpunkt inklusive.

Spinnt man das Beispiel weiter, so könnte das System sogar Anfahrtszeiten einplanen und dabei auch die aktuelle Verkehrssituation beachten und die terminlich am besten passende Vorstellung sogleich mit dem Kalender eines bevorzugten Begleiters abstimmen. Fällt die Vorstellung aufgrund einer Erkrankung eines Darstellers aus, würden die Termine frei, alle Betroffenen umgehend benachrichtigt und automatisch Ersatztermine abgestimmt.

Bei seinen Erklärungen zur dahinter liegenden Technik von .NET betont Microsoft immer wieder, dass es sich um kein geschlossenes, proprietäres System handelt, sondern dass alles offen sei. .NET benutze Standards wie XML, SOAP und HTTP, als Dienstanbieter könne jeder auftreten, der Zugriff auf die Dienste sei von jeder Plattform aus möglich, heißt es immer wieder aus Redmond - damit hofft Microsoft, auch Kritiker von seiner neuen Technik zu überzeugen.

Im Folgenden gehen wir den essenziellen Fragen zur neuen Technik im Detail nach. Dieser Artikel widmet sich den Grundlagen, einer Erklärung der verwendeten Techniken, der Bedeutung für Anwender, der Frage der Offenheit und endet mit einem Ausblick in die Zukunft. Die folgenden Artikel vergleichen die Technik Microsofts mit der des Mitbewerbs - bis hin zu einem Vergleich von Microsofts .NET-Musterprogrammiersprache C# mit Java und C++.

Die wohl wichtigste Neuerung im Zuge von .NET fürs Internet betrifft so genannte ‘Web-Services’ - sie dürften in nächster Zeit am schnellsten zu Tage treten. Dahinter stecken Mechanismen, die einen einfachen Zugriff auf im Internet verteilt angebotene Dienste erlauben. Das ist mitnichten eine Erfindung Microsofts. Viele Softwarehersteller bieten heute schon Produkte an, die solche Dienste unterstützen. Auch hinsichtlich der dazu verwendeten Standards hat man sich angenähert - HTTP als Transportprotokoll, SOAP und XML zum Aufruf und zum Verpacken der Daten.

Grob könnte man einen Web-Service als eine maschinenlesbare Webseite beschreiben: Ähnlich wie ein Surfer eine Seite im Web ansteuert, um bestimmte Informationen angezeigt zu bekommen, kann ein Programm an einen Web-Service herantreten, um dort Daten abzuzapfen, die es selbst weiterverarbeiten will. Durch die standardisierten Methoden, diesen Dienst anzusprechen, lässt sich das simpel implementieren, wenn grundlegende Bibliotheken dazu bereitstehen.

Hinzu kommt, dass Web-Services über XML-Dokumente in einem spezifizierten Format beschrieben werden (WSDL) und sich somit in zentralen Datenbanken ein Verzeichnis der verfügbaren Dienste aufbauen lässt. Unter anderem betreiben IBM und Microsoft derzeit Server, die ein solches UDDI-Verzeichnis (Universal Description, Discovery and Integration) bereitstellen. Die Beschreibung eines Dienstes per WSDL stellt sicher, dass sich auch bisher unbekannte Web-Services in eine bestehende Anwendung einbauen lassen - letztlich ersetzt sie die umständlichen Mechanismen früherer Standards zum Datenaustausch, etwa bei COM und RPCs.

Allerdings gibt es derzeit keinen Standardweg, wie die Zugriffsrechte für die Inanspruchnahme von Web-Services geregelt sind und ob, wie und wer eventuell eine Abrechnung erledigt. Innerhalb von .NET existiert zwar ein Konzept, wie es mit der Sicherheit beim Aufruf solcher Dienste bestellt ist; eine branchenweit gültige Konvention dürfte allerdings noch auf sich warten lassen, bis Web-Services gängige Verfahren für den Datenaustausch ersetzen.

Fürs Erste dürfte der Nutzen von Web-Services vor allem auf Business-to-Business-Kommunikation (B2B) beschränkt sein. Doch es ist nur eine Frage der Zeit, wann sich auch ein normalsterblicher Anwender dieser Technik bedienen kann - oder womöglich muss. Für sein aktuelles Office-Paket (XP) bietet Microsoft schon einen Zusatz an, mit dem es möglich ist, aus VBA-Applikationen heraus auf die Dienste von Web-Services zuzugreifen. So dürfte es in absehbarer Zeit wohl leichter sein, aktuelle Börsendaten in Excel einzulesen - ganz sicher jedenfalls, sofern sie kostenpflichtig sind.

Deutlich früher dürften Web-Services auch dem Anwender dienen, ohne so offensichtlich zu Tage zu treten - Beispiele lassen sich zuhauf kreieren: Banken könnten für den Online-Zugang Web-Services bereitstellen, die dann die umständlichen Verfahren à la BTX/CEPT ablösen und so eine einheitliche Schnittstelle fürs Internet-Banking schaffen, ob mit oder ohne HBCI. Neue Portale könnten entstehen, etwa für den Preisvergleich, die ihre Daten via Web-Service direkt aus den Datenbanken der Shops beziehen.

Bleibt die Frage, wovon der Anwender bei all der neuen Technik wirklich profitiert. Microsofts Antwort dazu heißt ‘.NET myServices’. Dahinter stecken Dienstleistungen, die Microsoft Endkunden kostenlos anbieten möchte - ein Angebot, das allen, die dem Softwareriesen schon heute aus Prinzip misstrauen, die Fußnägel aufrollen dürfte: Ein Kunde kann seinen Terminplan, Kalender und Adressbuch auf Microsoft-Servern führen.

Darüber hinaus kann er sogar Microsofts Server als verlängerte Festplatte nutzen, um dort seine Dateien, Favoriten und Todo-Listen abzulegen. Ferner kann er dort seine E-Mail aufbewahren lassen. Darüber hinaus will Microsoft Dienste anbieten, mit denen ein Benutzer anmelden kann, wo er sich gerade befindet und wo er darüber hinaus für Handy, PDA und PC seine Vorlieben für Bildschirmschoner, Hintergrundbilder et cetera ablegen kann.

Zentrale Komponente bei den myServices wird der Anmeldedienst Passport sein. Er dient dazu, dass sich Kunden gegenüber den Diensten ausweisen können. Spezielle darauf abgerichtete Dienste sammeln weitere Informationen über den Anwender, etwa zur bevorzugten Zahlungsweise inklusive Kreditkartennummer oder Bankverbindung. Ferner erhalten die Kunden die Möglichkeit, Buch über die in Anspruch genommenen Dienste zu führen.

Bei all dem will Microsoft dafür sorgen, dass ein Benutzer selbst darüber entscheiden kann, wer eventuell noch seine Daten einsehen kann. So wäre es denkbar, dass er einzelnen anderen erlaubt, ihre Kontaktdaten in seinem Adressbuch zu korrigieren, oder dem Babysitter Zugriff auf die wichtigsten Rufnummern gewährt, etwa damit dieser selbst den Kinderarzt oder Pizzabringdienst rufen kann, wenn die Kleinen Hunger haben.

Die Vorteile, die aus einer solch zentralen Datenhaltung resultieren, liegen auf der Hand: Die zahlreichen Daten stehen nicht nur dann zur Verfügung, wenn ein Benutzer an seinem PC sitzt, sondern auch, wenn er mit dem PDA oder Handy unterwegs ist - freilich nur, solange mit diesen Geräten zumindest zeitweise eine Verbindung zum Internet besteht.

Sieht man von den Schmankerln ab, etwa der Möglichkeit, Personen Zugriff auf sie selbst betreffende Einträge in fremden Adressbüchern einzuräumen, so ergibt das Ganze erst richtig Sinn in einer Welt, die auch anderweitig Gebrauch von den myServices macht. Microsoft hat dazu inzwischen allerhand Benutzungsszenarien konstruiert. Dabei spielt ein zentraler Dienst, der bisher unerwähnt geblieben ist, eine wichtige Rolle: das Messaging - also die Möglichkeit, einem an myServices angemeldeten Benutzer Nachrichten zukommen zu lassen.

Diesen Dienst bringt ein modernes Windows XP als Windows Messenger schon mit. Microsoft wollte damit aber weniger den Chat-Trieb der Anwender befriedigen, sondern hat schon mal frühzeitig dafür gesorgt, dass man auch eine Messaging-Plattform in Betrieb hat, die nach eigenen Standards funktioniert. Inzwischen lässt sich dieser Dienst sogar mit dem ersten und einzigen myService, der derzeit tatsächlich im Probebetrieb ist, nutzen: Mittels myAlerts kann man sich zum Beispiel an Geburtstage oder den Muttertag per Nachricht erinnern lassen.

Spinnt man den Faden weiter, könnte jeder myServices-Nutzer anderen Nachrichten zukommen lassen. Dass die nicht unbedingt eine Person verschicken muss, sollte klar sein: Etwa können Online-Auktionshäuser solche Nachrichten versenden, wenn vom Benutzer lang gesuchte Teile zur Versteigerung angeboten werden und wenn er später den Zuschlag erhalten hat. Das Warenwirtschaftssystem eines Kaufhauses könnte zukünftig eine Nachricht schicken, wenn eine bestellte Ware eingetroffen ist. Je nach Aufenthaltsort des Benutzers würden solche Nachrichten auch auf einem mobilen Gerät, etwa dem Mobiltelefon, erscheinen.

Andererseits: Von den Neuerungen wie dem Zugriff mit Handy und PDA sowie der Integration des Messaging abgesehen, kann man das alles schon heute haben. Viele Portal-Betreiber bieten bereits jetzt gleichwertige Dienste an, die man mit jedem x-beliebigen Web-Browser ansteuern kann, etwa Yahoo, Web.de und Microsoft selbst mit MSN. Einige dieser Anbieter liefern sogar Software, um die Kalenderdaten etwa mit dem PDA abzugleichen.

Der entscheidende Unterschied dieser Angebote zu myServices liegt darin, dass sie Insellösungen darstellen, die sich allenfalls über die vom jeweiligen Anbieter vorgegebene Schnittstellen von außen erreichen lassen. Was in der Praxis bereits passiert: So bietet Mercedes-Benz auf seinem Portal einen Kalenderdienst an, der auf den Kalender von daybyday durchgreift. Hierbei handelt es sich allerdings um anbieterspezifische Lösungen und Absprachen.

Standards könnten eine solche Form der Zusammenarbeit wesentlich vereinfachen - und das gleich in zweierlei Hinsicht: Zunächst könnte eine gemeinsame Aufrufsyntax die grundsätzliche Zusammenarbeit erlauben - hier kommen Web-Services ins Spiel. Darüber hinaus könnte eine semantische Festlegung solcher Web-Services dafür sorgen, dass sie beliebig gegeneinander austauschbar wären - bei allen Anbietern solcher Dienste müssten einzelne Funktionen die gleichen Daten ausspucken. Ein Anwender kann sich dann aussuchen, ob er den Kalender von Yahoo oder den von Daimler mit dem Adressbuch von Microsoft oder AOL kombinieren will.

Das Zünglein an der Waage ist dann die Integration dieser Dienste über eine zentrale Instanz. Keine Frage, dass Microsoft die hat: Dem bisher viel geschmähten Anmeldedienst Passport soll diese Aufgabe zukommen. Bisher gilt Passport als Account-Aggregierungs- respektive Single-Signon-Dienst. Meldet sich ein Benutzer während einer Surf-Sitzung dort einmal an, kann er alle angeschlossenen Websites ohne weitere Eingabe seiner Benutzerdaten besuchen. Eine spezielle Funktion namens ‘myWallet’ ermöglicht einem Online-Shop beim Einkaufen sogar, direkt ins Portemonnaie des Benutzers zu langen.

Die Resonanz von Website-Betreibern auf dieses Microsoft-Angebot ist bisher jedoch eher verhalten - mancher bietet es inzwischen aber als Alternative an, zum Beispiel eBay. Microsoft selbst hat sich über seinen Gratis-Maildienst Hotmail und MSN schon eine beachtlich große Benutzerschar mit Passport-Konto geschaffen. Ein Übriges tut der Windows Messenger, Microsofts zum Beispiel in Windows XP integriertes Programm fürs Instant Messaging - nur wer ein Passport-Konto hat, kann diesen Dienst benutzen.

Für die Benutzung der myServices soll Passport ebenso wie für den Messenger in Windows XP zur zwingenden Voraussetzung werden. Unklar ist noch, ob und inwieweit die zentrale Komponente ‘Passport’ für Dritte offen sein wird. Ende September hat Microsoft zwar angekündigt, Passport für Dritte zu öffnen - konkret: aus dem zentralistischen Modell ein föderalistisches zu machen -, doch viel mehr als diese Ankündigung gibt es derzeit nicht. Das einzig Konkrete besteht in der Aussage, langfristig auf Kerberos-Technik zu setzen.

Interessant ist die Rolle, die Microsoft sich selbst in einem solchen föderalistischen Modell zugedacht hat: Nur wer bereit ist, die Privacy-Standards einzuhalten, die sich Microsoft selbst auf die Fahnen geschrieben hat, kommt als an Passport angeschlossene Authenfizierungsstelle in Betracht. Prüft Microsoft selbst die Tauglichkeit eines Anbieters - wie angekündigt -, so ernennt sich Microsoft damit zu einer Art ‘Trust-Center’.

Microsofts Schritt könnte letztlich auch nur eine Reaktion auf Suns Ankündigung gewesen sein, mit der ‘Liberty Alliance’ eine Konkurrenz zu Passport zu schaffen, die unabhängig von einem einzigen Anbieter von vielen Firmen gestützt und betrieben werden soll [#literatur [1]]. Suns Vorschlag haben sich inzwischen ein Dutzend Firmen angeschlossen. Konkrete Entwicklungen gibt es aber weder hier noch bei Microsoft hinsichtlich einer Öffnung. Gerüchteweise war sogar schon davon die Rede, dass sich auch Microsoft Suns Initiative anschließt.

Das Ringen darum, einen Anmeldedienst für das Internet zu definieren, ist verständlich: Wem es gelingt, die Internet-Nutzer mit einer eindeutigen Identität zu versehen, bringt sich in eine außergewöhnliche Position - er sitzt an den Schalthebeln der Macht: kann entscheiden, was zu einer solchen Identität gehört, kann die angeschlossenen Dienste definieren und über die Teilnahme oder den Ausschluss anderer Anbieter befinden.

Passport selbst genießt keinen allzu guten Ruf. Schon vor längerer Zeit hatten Sicherheitsexperten vor möglichen Schwachstellen gewarnt [#literatur [2]]. Letztlich gehen diese auf die Tatsache zurück, dass Passport versucht, durch den Einsatz herkömmlicher Techniken (HTTP-Redirects, Cookies und JavaScript) möglichst kompatibel mit der Mehrzahl der Browser zu sein. Microsoft hat darauf reagiert, allerdings nicht das grundlegende Verfahren geändert, sondern nur einige Schwachstellen geflickt (unter anderem mit einer Erklärung, welche Browser Passport unterstützen).

Passport in der heutigen Form ist übrigens keine reine Windows-Sache. Microsoft stellt entsprechende Entwickler-Kits, mit denen sich eine Website Passport-konform machen lässt, auch für andere Systeme bereit, unter anderem Linux mit Apache. Wer Passport in sein Angebot aufnehmen will, muss sich an Microsofts Privacy-Regeln halten, die unter anderem P3P-Erklärungen voraussetzen (siehe auch c't 4/2002, Seite 186).

Microsoft betont immer wieder die Offenheit der von .NET genutzten und gesetzten Standards - Kritiker bezweifeln das. Microsofts Argumentation ist in vielen Bereichen unvollständig. So führt zwar die Etablierung der Common Language Infrastructure (CLI) und der Sprache C# durch die ECMA als Standard dazu, dass sie öffentlich werden - die ECMA fordert, dass jeder einen dort verabschiedeten Standard implementieren darf, hält sich aber aus Patentfragen weit gehend raus.

So ist derzeit nicht auszuschließen, dass Microsoft Dritte, die bei ECMA offen gelegte Verfahren implementieren, über Patente zu Lizenzzahlungen herankriegt. Die ECMA fordert lediglich, dass dies zu akzeptablen Konditionen zu erfolgen habe. Ob Microsoft Patente dazu hält oder solche beantragt hat, dazu gibt es keine eindeutige Stellungnahme. Sollte womöglich ein Dritter Patente auf in dem Standard beschriebene Dinge halten, könnte das sogar bedeuten, dass die ECMA den Standardstatus aberkennt.

Microsoft hat bei der ECMA zwar als Standard die Sprache C#, nicht aber die vollständige Laufzeitbibliothek des .NET-Framework eingereicht. Dritte können so nicht die vollständige .NET-Umgebung implementieren. Diese Strategie, nur Teile offen zu legen, ist eine bekannte Taktik: Die Windows-Welt ist voll von solchen teiloffenen Dingen - die gesamten für die Datei- und Druckfreigabe im Netzwerk offen liegenden Verfahren genügen heute nicht, um allein damit einen vollständigen Server zu implementieren.

Im Netzwerk-Bereich gibt es eine besondere Technik, für die das gilt: Kerberos. Microsoft nutzt dieses Protokoll bei Windows 2000 zur Authentifizierung im Netz. Kerberos ist eigentlich ein offener Standard, doch Microsoft hat es verstanden, ihn so zu erweitern, dass sich ein Windows-2000-Server nicht durch die Implementierung eines anderen Herstellers ersetzen lässt. Microsoft benutzt Felder, die im Standard für herstellerspezifische Erweiterungen reserviert worden sind. Ohne die Bedeutung der Felder zu kennen, ist eine Alternativimplementierung unmöglich.

Anstatt nun diese Erweiterung offen zu legen, also öffentlich ohne Einschränkungen zugänglich zu machen, behandelt Microsoft sie als Verschlusssache: Nur wer sich verpflichtet, sie nicht nachzubauen, erhält Einblick. Hinzu kommt - so sagen es jedenfalls Kenner -, dass es sich bei den nicht offen gelegten Bestandteilen im Grunde um trivialen Code handelt. Dennoch läuft jeder Gefahr, der ihn nachbaut, von Microsoft verklagt zu werden, schließlich greift in jeder Variante von Reverse Engineering das Digital Millennium Copyright Act (DMCA).

Mit nur quasi offenen Standards operiert Microsoft auch bei den Web-Services: Die Beschreibung von Web-Services etwa (WSDL) ist derzeit noch nicht endgültig, sondern nur als vorläufiger Standard (Draft) erhältlich. Dritte laufen also Gefahr, dass sich ihre Implementierung nicht mit der von Microsoft deckt beziehungsweise der Standard so spät gesetzt wird, dass dadurch erhebliche Marktnachteile entstehen. Microsoft dürfte es hingegen wenig kümmern, wenn sich am Draft bis zur endgültigen Standardisierung noch Änderungen ergeben.

Eine analoge Strategie wird an vielen älteren Vorkommnissen erkennbar: So hat Microsoft die Erweiterungen des zur Internet- oder Firmeneinwahl verwendeten Point-to-Point-Protokolls (PPP) zwar bei der IETF als Draft eingereicht, aber bis heute ist kein Request for Comment (RFC) daraus geworden. Das heißt, es gibt nur die Microsoft-Referenz-Implementierung im DFÜ-Netzwerk. Wer dazu kompatible Clients oder Server entwickeln will, muss Details durch Feldexperimente ergründen, statt sie einer Spezifikation entnehmen zu können.

Weitere Analogien lassen sich bei anderen Protokollen finden. Der Software-Riese versteht es, seine Pfründe zu sichern. Die modernsten Verfahren bleiben Verschlusssache. Insofern ist es zweifelhaft, ob die Gesamtheit der hinter .NET stehenden Konzepte wirklich so offen sein wird, dass eine reibungslose Interoperabilität mit anderen Systemen sichergestellt ist, wie es Microsoft derzeit glauben machen will. Abseits dieser Werbeaussagen betont Microsoft ohnehin, dass Windows die optimale .NET-Plattform ist.

Ernste Zweifel, wie es um die Offenheit wirklich bestellt ist, werfen auch die Verfahren auf, die Microsoft im Rahmen der myServices einführen will. Derzeit sind allenfalls Vorabversionen der nötigen SDKs zu bekommen. Nicht jeder bekommt sie und wenn, so steht in den Release-Notes und den Lizenzverträgen deutlich zu lesen, dass es sich um Work in Progress handelt. Wer selbst Services bereitstellen will, läuft also Gefahr, Schnittstellen zu schaffen, die sich nicht mit den von Microsoft später bereitgestellten Diensten vertragen. Potenzielle Anbieter werden wohl oder übel dem Diktat Redmonds folgen müssen.

Ähnlich wie auch Sun in seinem ‘Java Community Process’ genannten Verfahren versucht, Dritte an der Entwicklung von Java-Standards zu beteiligen, will auch Microsoft so etwas für myServices schaffen. Bei Microdoft heißt das ‘Shared Development Process’ (SDP). Darin will Microsoft Interessierte zusammenbringen und dafür sorgen, dass gemeinschaftliche Standards für Web-Services geschaffen werden. Bei Sun funktioniert das derzeit eher schlecht als recht. Wie es bei Microsoft klappen wird, muss sich noch erweisen.

Anders als beim ersten Anlauf, die Welt mit einem ‘Microsoft-Netzwerk’ zu beglücken, nämlich 1995 mit MSN, haben die Redmonder einiges gelernt: .NET schafft kein Paralleluniversum wie seinerzeit MSN, sondern es nutzt an breiter Front herkömmliche Techniken, um das heutige Internet vorsichtig zu erweitern, etwa beim Anmeldedienst Passport, der in heutigen Browsern vorhandene Mechanismen wie Cookies und Redirects benutzt.

Anders als bei MSN mit seiner proprietären Technik verwendet .NET auch sonst Mechanismen, durch die das Internet in der heutigen Form überhaupt entstehen konnte: Neue Verfahren bringt Microsoft in die gängigen Regulierungszirkel ein, die offene Standards in gemeinsamem Streben schaffen, etwa World Wide Web Consortium (W3C), Internet Engineering Task Force (IETF) und ECMA. Ob Microsoft hierbei wirklich mit offenen Karten spielt, also alle Details offen legt, oder diese Gremien nur ausnutzt, um sich nicht dem Verdacht der Geheimniskrämerei auszusetzen, bleibt im Detail aber ungeklärt.

Weit gehend unklar ist derzeit ebenso, wer außer Microsoft Geld mit .NET verdienen kann: Ende Oktober hatte Microsoft bekannt gegeben, dass Unternehmen, die selbst Dienste unter der Flagge der .NET myServices anbieten wollen, mit bis zu 10 000 US-Dollar zur Kasse gebeten werden - zuzüglich der Gebühren pro Anwendung von 1500 US-Dollar. Die Nutzung der myServices durch Endkunden soll vorerst kostenlos sein - wobei Insider auch hier von Gebühren ab 25 US-Dollar jährlich ausgehen. Klar dürften die Preise dann werden, wenn Microsoft Mitte 2002 erste Dienste in Betrieb nimmt.

Langfristig wird .NET nicht nur aufs Internet abfärben, sondern auch Windows ‘erneuern’. Kommende Windows-Versionen dürften die Laufzeitumgebung für .NET gleich mitbringen und künftige Office-Pakete Gebrauch von der neuen Technik machen. Inwieweit das die schon lange in Aussicht gestellte weitere Zerkleinerung von Anwendungen in Komponenten bringt, bleibt abzuwarten. Vorerst ist die Fehlermeldung von Word, dass die - dann als Web-Service implementierte - Rechtschreibprüfung die Duden-Redaktion nicht zu Rate ziehen kann, weil kein Geld mehr im Wallet ist, nur ein fiktiver Albtraum. (ps)

[1] Home-Page der Liberty Alliance

[2] David P. Korman, Aviel D. Rubin, Risks of the Passport Single Signon Protocol

[3] Microsofts Webseiten zu .NET

[4] W3C-Seiten zu Web-Services

[5] Home-Page der ECMA

[#anfang Seitenanfang]


In vielerlei Hinsicht ist .NET für Microsoft ein revolutionärer Ansatz, der selbst Bill Gates verzückt und zum Vergleich mit dem Übergang von DOS auf Windows hinreißt. Microsoft setzt auf Java-ähnliche Technik: Damit die .NET-Software nicht nur auf Wintel-PCs läuft, hat der Software-Riese eine Art virtuelle Maschine geschaffen, die zukünftig Programme ausführen soll. Dazu gibt es eine Klassenbibliothek, auf deren Dienste diese Programme zugreifen können.

Neu daran ist die Tatsache, dass dieses Konzept ausdrücklich unabhängig von der Programmiersprache ist. Eine Anwendung kann in verschiedenen Sprachen, etwa VisualBasic und C++, verfasst sein. Alle Sprachen greifen nicht nur auf dieselbe Bibliothek zurück, sondern nutzen eine einheitliche OO-Schnittstelle, können also Klassen einander vererben et cetera. Die unmittelbare Zusammenarbeit ist neu und heute allenfalls deutlich umständlicher über externe Standards wie CORBA oder COM zu haben.

Der Kern dieser .NET-Umgebung heißt ‘Common Language Infrastructure’ (CLI), Microsoft konkrete Implementierung in .NET ‘Common Language Runtime’ (CLR). Microsoft hat sich, statt auf Java zurückzugreifen, eine eigene virtuelle Maschine für .NET maßgeschneidert. Grundlage der CLR ist ein gemeinsamer Standard für objektorientierte Programmiersprachen (Common Language Specification, CLS) und für deren Typsystem (Common Type System, CTS). Microsoft hat die CLI bei der ECMA als Standard vorgeschlagen; dort wurde sie Ende Dezember als solcher veröffentlicht.

Ein Programmierwerkzeug für .NET erzeugt normalerweise keinen Code mehr für einen spezifischen Prozessor, etwa x86, sondern Zwischencode in der ‘Intermediate Language’ (MS)IL der CLI. Beim Ausführen oder auf Wunsch schon früher erzeugt ein Just in time Compiler (JIT) daraus Code für den jeweiligen Prozessor. All das besorgt für den Benutzer unbemerkt ein ‘Virtual Execution System’ (VES), das Bestandteil der CLR ist.

Es gibt zahlreiche Unterschiede zum Laufzeitsystem von Java, auch wenn der Ansatz auf den ersten Blick recht ähnlich scheint: Bei Microsoft läuft stets der JIT, bei Java ist das optional. Die Java-VM hat Sun lediglich auf seine Sprache abgestimmt; andere Sprachen, die sie als Grundlage verwenden, sind kaum gebräuchlich. Microsoft hingegen hält besonders auf die Mehrsprachenfähigkeit große Stücke: Soll es damit doch einfach sein, auch alten Cobol-Code in ein neuartiges .NET-Projekt einzubinden.

Auf die Laufzeitumgebung (CLR) setzt eine gemeinsame Klassenbibliothek auf. Sie ersetzt dabei die heute unter Windows gebräuchlichen Bibliotheken vollständig, sei es das Windows-API, die Microsoft Foundation Classes (MFC) oder nur für einzelne Aufgabenbereiche zuständige Bibliotheken, etwa ODBC. Anders als die CLR selbst sind nur Teile der Klassenbibliothek offen gelegt. Die CLI-Spezifikation definiert lediglich die Grundlagen und endet, sobald es um plattformspezifische Dinge, etwa Fenster, geht.

Mit der Einführung von .NET geht auch eine Generalrenovierung der Windows-Programmierschnittstellen einher. Die .NET-Bibliotheken enthalten unter anderem Klassen für WinForms - letztlich die Grundlagen für dialogbasierte Windows-Anwendungen à la VisualBasic und Delphi. Auf lange Sicht könnte Microsoft das klassische Windows-API durch eine OO-Bibliothek ersetzen.

Doch noch ist es nicht so weit: In den .NET-Bibliotheken finden sich zahlreiche Klassen, die dafür sorgen, dass man mit neuen Mitteln auch auf die alten Techniken zurückgreifen kann, um beispielsweise Anwendungen nach dem ‘alten’ Objektmodell DCOM/COM+ in .NET-Anwendungen zu integrieren.

In näherer Zukunft dürfte Microsoft deshalb ein Laufzeitsystem als eigene Welt neben Windows auf den Festplatten der Anwender errichten: Zu dem voluminösen Betriebssystem gesellt sich dann noch die .NET-Laufzeitumgebung. Sie ergänzt den Windows-Einstellungssalat um weitere Optionen, die etwa den Zugriff von nicht vertrauenswürdigem Code auf die Platte et cetera regeln (.NET bringt hier erfreulicherweise allerhand Mechanismen mit, die langfristig für sichere Software sorgen könnten - mehr dazu im Folgeartikel).

".NET im Überblick"

Weitere Artikel zum Thema .NET finden Sie in der c't 4/2002:

Die .NET-Technik S. 92
C# im Vergleich mit C++ und Java S. 98

Kommentare

Anzeige