Microsoft.NET und ASP.NET -
eine kleine Vorschau (II)

Nachdem wir zu unserem Artikel über Microsoft.NET in der Januar/Februar-Ausgabe von QUERDENKER eine Reihe von Anfragen erhielten haben wir uns entschlossen eine Fortsetzung in dieser Ausgabe zu bringen. Möge der Artikel ein wenig Licht in die .NET Strategie von MS bringen. Aber lesen Sie selbst:

Natürlich ist die Bezeichnung .NET zuallererst einmal eine griffige Formulierung aus der MS-Marketingabteilung, die zukünftig fast alles aus dem Hause Microsoft mit dem entsprechenden .NET-Logo verzieren wird. Zumindest all jene Produkte, wie z.B. der BizTalk Server, die auf der Windows 2000-DNA aufsetzen.

Die interessantesten Eigenschaften von .NET liegen in der Entwicklungsplattform, den verwendeten Sprachen und Protokollen. Größtes Ziel von .NET ist es, die Entwicklung interaktiver Web-Anwendungen zu erleichtern, basierend auf einer total neuen Architektur. Wir möchten uns dies heute ein wenig genauer ansehen, obwohl man hier nur mit einer gewissen Wahrscheinlichkeit rechnen kann - aufgrund der vorliegenden Beta-Versionen von .NET Framework und Visual Studio.NET. Mit Änderungen ist daher zu rechnen.

.NET ist eine völlig neue Plattform und eine Technologie, die ein Paket an neuen Produkten vorstellt, deren Kompatibilität mit vorhandener Technologie nicht immer garantiert werden wird. NET bietet Support für 27 Programmiersprachen an, die sich einen Pool von Klassen teilen, die wiederum Grundfunktionen bereitstellen. NET-Anwendungen laufen nicht mehr in einem nativen Maschinencode. Man hat Intels x86-Code zugunsten einer Zwischensprache, die MSIL (Microsoft Intermediate Language) genannt wird, verworfen. Diese IL läuft in einer virtuellen Maschine, der Common Language Runtime (CLR).

Zusätzlich macht .NET intensiven Gebrauch von XML und das Hauptgewicht liegt auf dem SOAP-Protokoll. Mittels SOAP (Simple Object Access Protocol), will Microsoft eine Technik der Programmierung etablieren, die nicht auf dem Bau von Modulen, einzelnen Bestandteilen aufsetzt, sondern auf der Wiederverwendung von Dienstleistungen basiert. SOAP und Web Services sind die Basisbestandteile der NET-Plattform.

Derzeit muss man sich keine Sorgen um die Zukunft jetziger DNA-Applikationen machen. Erstens wird die Final-Version von .NET wahrscheinlich frühestens 2002 zur Verfügung stehen und zweitens hat Microsoft zugesichert, dass auch bestehende Applikationen unter dem .NET Framework laufen, ohne ihnen allerdings die .NET Funktionalitäten zur Verfügung zu stellen.

Dennoch - auch wenn Microsoft beruhigt - die Änderungen greifen tief in die Architektur des Systems und beeinflussen fast jeden Bestandteil in der Microsoft DNA-Architektur.
Der IIS hat sein wirkungsvolles aber instabiles multi-threaded Modell zugunsten eines Multiprozessmodells fallengelassen, welches an den Apache-Server angelehnt ist. Die ASP-Technologie wird zu ASP.NET, wo interpretierte Skripte ersetzt werden durch Code, der beim ersten Aufruf kompiliert wird - ähnlich dem Modell der Java Server Pages. Win32 APIs wie ATL und MFC werden durch ein zusammenhängendes Set von Basis Framework-Klassen ersetzt. VB.NET sichert nicht mehr die zukünftige Kompatibilität von VB6, da diese Sprache eine Menge an Beigaben erhält um mit der Common Language Specification übereinzustimmen.

COM+ 2.0 ist ein total neues Komponentenmodell, das nichts von COM/DCOM/COM+ übernimmt. COM+ 2.0 verwendet auch nicht mehr die Windows Registry, um die lokalen oder die Remote-Elemente zu registrieren. Dies bedeutet: Installieren einer Komponente ist einfach nur wieder das Kopieren von Dateien in Verzeichnisse - back to the roots!
Die neue Programmiersprache, C# (C Sharp gesprochen), eine Mischung zwischen C++ und Java, wird eingeführt. Diese moderne objektorientierte Sprache wurde von Anders Hejlsberg, Architekt einer größeren Anzahl von Sprachen und Tools bei Borland, einschließlich des berühmten Delphi, erstellt. Das neue Programmiermodell, basierend auf SOAP und den Web-Services, verändert grundlegend die Art und Weise, in der Anwendungen entworfen werden, und öffnet ein neues Modell der Softwareanwendung: Onlineanwendung durch Web-Services.

Diese Änderungen bewegen sich in Richtung einer loseren Koppelung zwischen dem Betriebssystem und den oberen Schichten, die der Anwendung Serverdienstleistungen anbieten. Wir betrachten diese Änderungen ausführlicher weiter unten, um Ihnen einen Einblick in die Transformationen zu geben, die stattfinden. Positiv zu vermerken ist, dass die NET-Plattform weitgehend auf den Standards von W3C, dem IETF und der ECMA aufsetzt.

Microsoft hat durch die geschickte Verquickung von Betriebssystem und dem Internet Explorer eine Dominanz im Internet entwickelt, die sich für Netscape und viele Andere verheerend auswirkte. Mit .NET will man diese Dominanz offenbar ausbauen: .NET offeriert eine endlose Anzahl von interoperablen Web-Services, die zusammen ein globales Service-Austauschnetz bilden. Diese Web-Services basieren auf dem einfachen Nachrichtenzugriffsprotoktoll (SOAP) und XML. SOAP wurde zuerst beim IETF durch DevelopMentor, Microsoft und Userland Software eingereicht. Heute sind nahezu alle Riesen in der Branche, einschließlich IBM, groß in SOAP miteingebunden.

Gerüchte sprechen davon, dass das .NET Framework SDK kostenlos verteilt werden wird, während nur Visual Studio.NET kostenpflichtig sein wird. Doch auch die Konkurrenz schläft nicht und dies ist auch gut so: Die entsprechende Java-Umgebung wurde soeben mit dem Sun Open Environment (Sun ONE) vorgestellt. Auch hier soll eine Entwicklerumgebung mit webbasierenden Services zur Verfügung gestellt werden. Auch diese Plattform ist nicht vor 2002 verfügbar.

Die .NET Architektur

.NET ist ein Set allgemeiner Services, die von einer Reihe von Zielsprachen verwendet werden können. Diese Services werden in Form von Intermediate Code (Zwischencode) durchgeführt, die von der zugrundeliegenden Architektur unabhängig sind. Auch hier zeigen sich wiederum Analogien zu Java - offenbar Microsofts Vorlage. Das Primärziel von .NET ist es, Entwickler mit den Mitteln zu versehen, um leicht interaktive Anwendungen erstellen zu können, die schlußendlich jeder verwendeten Plattform standhält, seien es ein PC, ein PDA oder ein Handy etc.

.NET wird Multi-Sprachen tauglich. Mit der .NET-Plattform liefert Microsoft einige Sprachen und die dazugehörigen Compiler aus, wie etwa C++, JScript, VB.NET (alias VB 7) und C#. Dritthersteller, die mit MS kooperieren, entwickeln aktuell Compiler für weitere Sprachen, wie zum Beispiel COBOL, Eiffel, CAML, LISP, Python und Smalltalk. Rational, Hersteller des berühmten UML-Tools Rose, wird einen Java-Compiler für .NET entwickeln.

.NET Anwendungen laufen unabhängig von der Hardware. Alle diese Sprachen werden über einen binären Zwischencode kompiliert, der von der Hardware und von Betriebssystemen unabhängig ist. Diese Sprache ist IL (Intermediate Language). MSIL wird dann in der Common Language Runtime (CLR) ausgeführt, die im Allgemeinen die gleiche Rolle wie die JVM auf der Java-Plattform erfüllt. MSIL wird dann in Maschinencode durch JIT-Compiler (Just In Time) übersetzt.

.NET Anwendungen sind portabel. Die kompilierten Intermediate-Code-Anwendungen liegen als Portable Executables (PEs) vor. Dadurch ist es möglich, dass Microsoft Komplett- oder Teilimplementierungen der NET-Plattform über eine Reihe von Hardware- und Software-Architekturen anbieten kann: Intel-PCs mit Windows 9x, Windows NT4, Windows 2000 oder XP-64 Bit Windowsversionen, Mikrocontroller basierende PDAs mit PocketPC (z.B. WindowsCE) und natürlich auch auf anderen Betriebssystemen.

.NET Sprachen müssen der CLS entsprechen. Programmiersprachen gibt es zuhauf. Traditionsgemäß sind neue Sprachen erstellt worden, um auf neue Notwendigkeiten, etwa Berechnungen in der Forschung oder dem Erfüllen von Sicherheitsstandards oder Stabilität zu reagieren. Das Resultat ist, dass vorhandene Sprachen heterogen sind: Einige sind prozedural, andere objektorientiert, einige authorisieren den Gebrauch von wahlweise freigestellten Parametern oder einer variablen Anzahl von Parametern, andere wiederum nicht etc.

Der kleinste gemeinsame Nenner ist hierbei eben spezifisch die Common Language Specification, kurz CLS. Um eine neue Sprache dem .NET Framework hinzuzufügen bedeutet also die Konstruktionsrichtlinien und Möglichkeiten der CLS zu beachten und von hier ausgehend einen Compiler zu bauen, der diese Sprache in Intermediate Language umwandelt.

Diese Restriktionen der CLS ergeben dann aber auch bedeutende Einschränkungen. So ist der Sprung von VB 6 auf Visual Basic .NET (intern VB 7) geradezu ein Sprung auf eine neue Programmiersprache. Da ist nur wenig mehr als die Syntax gleich geblieben. Die Tatsache, daß alle NET-Sprachen in der Form eines Zwischencodes auch kompiliert werden, heißt auch, daß eine codierte Berechnungsfunktion, die in einer Sprache geschrieben wurde, dann auch in einer anderen Sprache berechnet und ausgeführt werden kann. Oder: Eine Java-Klasse kann in VB vererbt werden.

Wenn man heute ein COM+ Objekt erstellen möchte hat man die Wahl zwischen VB6 und Visual C++. Mit VB 6 hat man nicht Zugriff auf alle Möglichkeiten. Für bestimmte Anforderungen wird man daher auf Visual C++ zurückgreifen. Im .NET Framework bieten alle Sprachen die gleichen Möglichkeiten an. Sie werden in ihrer Kreativität nicht mehr durch Implementierungbegrenzungen eingeschränkt.

Wie ist das möglich?

.NET ist Multisprachentauglich, obwohl ja im Grunde nur eine einzige Sprache unterstützt wird, nämlich die Intermediate Language. Und doch liegt die Wahl der geeigneten Sprache bei ihnen ...

Um also beliebige Sprachen im .NET Framework verwenden zu können müssen diese einen kleinsten, gemeinsamen Nenner haben. Gleiche Eigenschaften, die mit den Anforderungen von .NET übereinstimmen. Dies bedeutet aber auch, daß die .NET-Version von beispielsweise COBOL so viele neue Konzepte und Erweiterungen beeinhalten muss, daß sie praktisch nichts mehr gemeinsam hat mit der ursprünglichen Version von COBOL. Dies betrifft natürlich auch alle anderen in .NET angebotenen Sprachen. Bei 27 mit .NET angebotenen Sprachen gibt es natürlich auch 27 verschiedene Syntax-Versionen.

Das symptomatischste Beispiel betrifft Java. Es ist eine der unterstützten .NET-Sprachen. Rational arbeitet aktuell an einem derartigen Compiler, der Java auf MSIL transportiert. Aber was ist das für ein Java? Es ist ein Java, das unter MSIL-Code läuft und nicht unter Byte-Code. Dieses Java profitiert nicht von den traditionellen APIs, die durch die JEE-Plattform, wie JMS, RMI, JDBC oder JSP angeboten werden. Dies ist ein Java, in dem EJBs durch .NET's verteiltes Objektmodell ersetzt werden. Sie sagen Java, aber ist das überhaupt noch Java? Was ist mit der Syntax von Java? Nein, unserer Auffassung nach ist es nicht mehr Java! Möglicherweise ist Java im Zusammenhang mit Microsoft sowieso eine eigene Geschichte und daher die Ausnahme beim .NET Modell?

Java-Experten sehen im .NET "Java" halt nur einen weiteren Versuch seitens Microsoft die Zukunft von Java zu untergraben. Die Beziehungen zwischen Sun und Microsoft sind auch nach dem eigenartigen Vergleich vor wenigen Wochen getrübt. Es steht auch außer Frage, dass Microsoft "ihre" Variante von "Java" in .NET einbauen würde. Aus unserer Perspektive ist der Support von Java im .NET total unbrauchbar, wenn man beabsichtigt, einen gewissen Grad an Kompatibilität zu den JEE-Plattformen von Sun einzuhalten. So denken wir auch, dass auch im .NET Modell wiederum von Microsoft der Versuch unternommen wird, proprietäre Wege zu gehen und dabei möglichst viele Entwickler zu gewinnen, um dann wieder einen Quasi-Standard vorzuweisen, der mit allem anderen inkompatibel ist, aber eben erfolgreich etabliert am Markt. Auch das Gerücht .NET sei auch auf Unix-System verwendbar halten wir eben nur für ein Gerücht, welches aus bestimmten Marketinggründen bewußt von Microsoft ausgestreut wurde.

Ein hierarchischer Katalog von Klassen versorgt alle Dienste und API´s, die die Applikation benötigt. Aufgrund der eingebauten Prüfungsroutine des Reflection API wird wie in der Javadoc eine ausführliche Dokumentation hergestellt.

Common Language Runtime

Wie bereits erwähnt ist die CLR eine virtuelle Maschine wie die JVM bei Java. Dieser Laufzeitumgebung obliegt das Handling der entsprechenden Betriebsmittel (Speicherallokierung und Garbage Collection) und stellt die notwendige Abstraktion zwischen der Applikation und dem zugrundeliegenden Betriebssystem sicher.

Um eine stabile Plattform zu erreichen, die den Anforderungen verteilter Anwendungen im E-Business genügt, überwacht die Runtime auch den Ablauf des Programmes. Im .NET Dialekt spricht man von "managed code" für Anwendungen, die unter Aufsicht der CLR laufen und von "unmanaged code" bei Applikationen, die außerhalb der CLR laufen.
Die Runtime sucht dabei nach den traditionellen Programmierfehlern, die uns seit Jahren das Leben schwer machen: Zugriff auf nicht allokierte Speicherbereiche, Zugriff auf Array-Elemente außerhalb der Begrenzungen, Zugriff auf überschriebene Speicherbereiche etc.

Diese Überwachung der Ausführung des "managed" Codes kostet allerdings Performance. Wir rechnen mit einer ca. zehnprozentigen Leistungseinbusse. Dies allerdings auf Grundlage der vorliegenden Beta-Versionen und so glauben wir auch gleichzeitig, dass dies unseriös ist. Es ist zu erwarten, dass in weiteren Versionen der Performanceeinbruch sicherlich geringer sein wird. Und so sollte sich jeder die Frage stellen, ob ihm eine höhere Sicherheit und Zuverlässigkeit eine relativ geringe Leistungseinbusse wert ist? Wir glauben schon! Noch dazu könnten die Performanceverschlechterungen durch höhere Prozessorleistungen sicherlich aufgefangen werden.

ASP.NET

Die neue Version von ASP für die Entwicklung dynamischer Web-Seiten ist eine komplette Neubearbeitung, basierend auf den Services der CLR. Alle Sprachen, die in .NET angeboten werden, können auch in ASP.NET-Seiten verwendet werden. Man ist also nicht mehr ursächlich am VBScript und JScript gebunden. Die neuen ASP.NET Seiten tragen auch unterschiedliche Extensions: "aspx" bei einfachen ASP.NET-Seiten, "asmx" bei den Web-Services und "aspc" bei Pagelets, die eine Ansammlung von mehrfach verwendbarem ASP.NET-Seiten beeinhalten.

Alte asp-Seiten brauchen im .NET Framework nicht umgeschrieben werden. .NET kann alte asp- und neue aspx-Seiten nebeneinander ablaufen lassen. Einzig, die alten ASP-Seiten laufen über die asp.dll und profitieren nicht von den neuen CLR-Funktionalitäten.
Die neuen aspx-Seiten werden jetzt nicht mehr interpretiert, sondern beim ersten Aufruf zu MSIL-Code compiliert. Wieder vergleichbar mit den Java Server Pages in der JEE-Welt. Das logische Resultat sollte eine Leistungsverbesserung sein, ungefähr in dem Ausmass wie beim Upgrade von VB4 auf das kompilierte VB5 - verspricht Microsoft.

Diese tiefgreifenden Änderungen erfordern neben den Auswirkungen auf die Art der Codierung der ASP-Seiten auch einen Lernprozess betreffend der Einführung neuer Konzepte in VB.NET.

Änderungen finden auf drei Stufen statt:

Änderungen in der API
Änderungen an der Site-Struktur
Änderungen zwischen VBScript und VB.NET

ASP.NET unterstützt nur eine Sprache pro Seite. In der DNA konnte eine alte Asp-Seite wechselnde Abschnitte von JScript und von VBScript enthalten. In ASP.NET wird dies unmöglich sein, da eine Seite eben zu einem MSIL-Code kompiliert wird. In ASP.NET müssen Funktionen in HTML-Script-Tags eingebettet werden. Zur besseren Übersicht und Lesbarkeit des Codes ist es auch nicht mehr erlaubt, die Funktion durch HTML-Tags zu unterbrechen, sondern es ist umgekehrt, die Funktion enthält die HTML-Tags.

Bisher galt:

    <%
    Function Willkommen() 
    %>
    <b><i>
    <% 
    Response.Write "Hallo! Willkommen bei Active Server Pages" 
    %>
    </i></b>
    <% 
    End Function 
    %> 
    

In ASP.NET sollte es so aussehen:

    <Script Language="VB" runat=server>
    Function Willkommen() 
    Response.Write ("<b><i>") 
    Response.Write ("Hallo! Willkommen bei ASP.NET") 
    Response.Write ("</i></b>") 
    End Function 
    </Script>   
    

Die Klammern um den Funktionsaufruf Parameter sind jetzt vorgeschrieben. Andere Kompatibilitätsprobleme kommen von der Tatsache, dass alle ASP.NET-Arrays nullbasierend sind, während in Asp 3.0, einige auf 1 basieren, andere wiederum auf 0 basieren.

In VB.NET werden defaultmäß die Parameter durch Werte (ByVal) geführt; aktuell in VBScript werden sie durch Referenzierung (ByRef) geführt. Letztlich unterstützt VB.NET auch nicht mehr die voreingestellten Werte bzw. die Schlüsselwörter "Set" und "Let". Obwohl dies nicht unbedingt kritische Änderungen sind, so kosten sie doch Zeit, da vorhandener Code umgeschrieben werden muss, wenn Sie von den neuen Eigenschaften der CLR und des kompilierten Codes profitieren möchten. Microsoft beabsichtigt allerdings Tools zur Verfügung zu stellen, die die Migration erleichtern sollen.

In ASP.NET können alte COM-Komponenten verwendet werden. Diese werden allerdings gekapselt und laufen außerhalb der Laufzeitumgebung des CLR. Dies wirkt sich naturgemäß negativ auf die Performance aus, was ebenfalls den Wunsch laut werden läßt alte COM-Komponenten in COM+ 2.0 umzuschreiben.

Der größte Pluspunkt von ASP.NET sind wahrscheinlich die Server Controls, die ihnen bei der Programmierung ein mächtiges Werkzeug in die Hand geben. Mit diesen Server Controls profitieren ihre ASP.NET-Seiten von sicht- und unsichtbaren Komponenten, die hochentwickelte Services liefern: Baummenüs, Listboxen, Kalender und so weiter. Diese Komponenten analysieren den Web Client, der sie aufruft und generieren eine kompatible Darstellung. Typischerweise verwendet man etwa bei Formularfeldern clientseitiges Skripting, etwa in Javascript, um die Einträge zu prüfen. Jetzt kann man darauf verzichten und eine serverseitige Prüfung durchführen und damit auch das Handikap umgehen, dass beispielsweise am Browser selber Javascript deaktiviert ist und eine Formularprüfung damit auch nicht funktionieren würde.

Fazit

Wir gehen davon aus, dass das endgültige Release der Final Version nicht vor Ende 2001, eher später erhältlich sein wird. Zur Zeit kann man auch davon ausgehen, dass .NET Anwendungen mit der vorhandenen Windows 2000 DNA-Architektur problemlos kooperieren werden. Sicherlich arbeitet Microsoft an einer noch besseren Partnerschaft von .NET mit dem kommenden Betriebssystem Windows XP und sicherlich werden auch Migrationstools erhältlich sein.

Allerdings sollte man sich auch bewußt sein, dass Migrationstools niemals 100% aller notwendigen Änderungen durchführen können. Infolgedessen wird es ratsam sein, genügend Zeit und Betriebsmittel dieser Migration zu widmen. Außerdem macht eine Umwandlung von ASP/VBScript-Anwendungen in ASP.NET/VB.NET-Anwendungen nicht automatisch eine .NET Anwendung daraus. Es aller Wahrscheinlichkeit nach notwendig, die Anwendungsarchitektur zu ändern, um von den neuen Möglichkeiten völlig zu profitieren, die von .NET angeboten werden.

Wir werden in folgenden Ausgaben von QUERDENKER sicherlich weitere Artikel über .NET bringen und so versuchen mehr Licht in die Angelegenheit zu bringen. Gerne würden wir auch weiterhin ihre Meinung hierzu erfahren. Senden Sie uns einfach ein Mail!

see-programming

querdenker