Microsoft ist zum Glück nicht der einzige Spieler auf dem Markt, aber doch wohl der zur Zeit größte. Und so kann es niemanden kalt lassen, auch nicht den größten Microsoft-Hasser, welche Visionen unseren Billy-Boy umtreiben. In den letzten 3 Jahren hat Microsoft im Stillen seine Vision .net auf die Sicht der nächsten 10 Jahre entwickelt. Das Konzept regelt durchgängig alle Bereiche der Architektur neu mit starker Ausrichting auf die Entwicklung von Webservices.
Jetzt lief durch Deutschland die .net-Roadshow und auch ich habe sie besucht. Zu einem lächerlich niedrigen Preis von DM 129,- bekam man einen ganzen Tag Vorträge, eine Beta-Version von Visual Studio .net und reichlich Speis und Trank.
Vor fünf Jahren erst hat das Web die Welt umgekrempelt. Alle Menschen sind miteinander vernetzt und werden schon bald ständig mit dem Web verbunden sein. Ebenso werden die Anbieter im Web alle miteinander vernetzt sein und Dienste im Web nutzen, sogenannte WebServices. Deshalb ist auch Microsoft gezwungen, seine Welt Web-fähig zu machen. Informationen müssen ausgetauscht, Dienste müssen aufgerufen werden können und jedem muss es möglich sein, seine Dienste anzubieten.
Der Austausch von Daten wird auf der Grundlage von XML (eXtensible Markup Language) geschehen. Jeder kann auf dem Web Webservices anbieten. Microsoft selbst bietet WebServices an und kassiert dafür. In der UDDI-Initiative (Universal Description, Discovery and Integration) haben sich bisher 130 Partner zusammengeschlossen von American Express über IBM, SAP und Sun bis zu Verisign, die über eine standardisierte Beschreibung von WebServices diesen Markt aufbauen wollen.
Microsoft wird verschiedene Server-Produkte anbieten. Für Datenbanken den SQL-Server 2000, für Kommunikation Exchange 2000, für die Datendefinition mit XML den BizTalk-Server 2000 und den Commerce-Server 2000 für eCommerce.
Natürlich bietet Microsoft die Entwicklungsumgebung an, um solche Webservices entwickeln zu können. Die gesamte .net-Welt wird deshalb auf einer völlig neuen Software-Architektur aufsetzen.
Aus den Sprachen wurde alles außer Syntax und Semantik der Kontrollstrukturen, Klassen- und Variablen-Deklarationen herausgeworfen und in eine eigene "Common Language Runtime" gesteckt, die für alle Programmiersprachen gleich ist. Diese Runtime enthält die Datentypen, alle Systemfunktionen, Exception-Behandlung, Datenbankzugriff und das User-Interface. Also Ade VB-Controls, MFC und ATL.
Alle .net-Programmiersprachen werden auf einer gemeinsamen Basis aufsetzen. Microsoft selbst bietet C# und VB.net an. Microsoft hat diverse andere Compiler-Hersteller für das Aufsetzen auf das Common Language System von .net gewinnen können wie z.B. Niklaus Wirth mit Oberon, Bertrand Meyer mit der Sprache Eiffel und Smalltalk - meiner Meinung nach eher eine Liste der Verlierer. Visual C++ wird nicht mehr zu dieser Welt gehören, weil es sich nicht in das vorgegebene Schema pressen lässt - ein Grund für C#. Java kann nicht Teil dieser Welt werden, weil es keine reine Programmiersprache ist, sondern auch seine eigene Laufzeitumgebung mitbringt.
C# (Gesprochen C-Sharp, also Scharfes C) fügt sich in die .net-Welt ein, indem man auf einfache Weise Komponenten erstellen kann. C# bietet etwas mehr Flexibilität (z.B. Operator-Overloading) und mehr Funktionalität bei etwas umständlicherer Programmierung als VB.net. Die Syntax erinnert sehr an Java und damit auch an C++. Einige C++-Konstrukte gibt es nicht wie z.B. Mehrfachvererbung und Templates. Man braucht kaum noch Pointer und es gibt eine automatische Speicherverwaltung. Wie bei Java entfällt die Trennung zwischen Headern und Code. Von Java unterscheidet es sich darin, dass es nach wie vor keine "Sandbox" gibt.
VB.net wird nicht kompatibel zu VB6 sein. Es gibt zwar einen Konverter, aber der funktioniert noch nicht richtig und wird voraussichtlich nie jedes Programm umsetzen können. Geändert haben sich die Datentypen (z.B.: Variant entfällt), die Exception-Behandlung (kein On Error ... mehr) und viele andere Details. Dazu gekommen sind jetzt Konstruktoren und Destruktoren, Namespaces und Inheritance sowohl auf Funktionsebene als auch für ganze Interfaces.
Ein interessantes Konzept sind die "Delegates", eine Art Callback-Mechanismus. Einer Funktion einer Event-Klasse können meherere Funktionen anderer Klassen zugewiesen werden. Die zugewiesenen Funktionen werden aufgerufen, wenn die Funktion der Event-Klasse aufgerufen wird.
Alle Sprachen werden in die IL (Intemediate Language) übersetzt und erst beim Programmstart in echten Maschinencode übersetzt. Natürlich kann man Module auch vorkompilieren, wenn man es unbedingt will.
Die IL ist eine logisch recht hoch stehende Sprache, die auch Namespaces und Klassen kennt. Ein nettes Feature ist, dass Klassen, die in einer Sprache definiert sind von Klassen in einer anderen Sprache abgeleitet werden können.
Angst davor quasi den Quellcode auszuliefern? Microsoft liefert eine leicht zu knackende mit Passwort versehene Version. Die Lösung bei "kritischen" Algorithmen? Der Vortragende empfiehlt: "Verwenden Sie dafür doch einfach Visual C++". Da scheint es also keine Lösung in .net zu geben.
Aus Java bekannt ist das Feature "Reflection", also dass zur Laufzeit die Datentypen abgefragt und sogar neue Datentypen erzeugt werden können.
Module werden zu Assemblies zusammengefasst. Ein Assembly enthält diverse Informationen zu Namensgebung, Versionierung und exportierte Typen. Um Viren das Leben schwer zu machen, wird das Assembly vom Entwickler verschlüsselt und kann mit dem mitgelieferten "Public Key" entschlüsselt werden. Eine Checksum des Public-Key wird im Verzeichnis mit abgespeichert.
Auch die Versionsprüfung läuft auf der Ebene der Assemblies ab. Es wird das Prinzip einer viestufiegen Versionsnummer verfolgt. Stelle 1 und 2 machen zwei Asssemblies inkompatibel. Bei Stelle 3 ist die Kompatibilität zweifelhaft, aber die Runtime versucht es zu laden. Stufe 4 ist nur eine Build-Nummer für QFE (Quick Fix Engineering), also einfache Fehlerkorekturen.
Der Zugriff erfolgt über ADO.net. Vom Namen ADO sollte man sich nicht täuschen lassen, es handelt sich um ein teilweise ähnliches API mit einem radikal neuen Konzept dahinter.
Alle benötigten Daten werden grundsätzlich in einen Dataset geladen, einer Art Cache und dort verarbeitet. Es sind somit immer "Disconnected Recordsets". Es gibt kein "pessimistisches Locking" mehr und keine Cursor! Der traditionelle relationale Join ist abgeschafft, sondern die Daten werden prozedural hierarchisch aufgebaut. Auf die Daten gibt es zwei gleichberechtigte Sichten: Den hierarchischen Baum und das XML-Dokument.
Die Begrenzung des Konzepts besteht einerseits darin, dass alle Daten in das RAM geladen werden und dieser natürlich nur eine begrenzte Größe hat. Für GUI-Anwendungen ist das kein Problem, denn kein Benutzer will eine Million Datensätze anzeigen lassen. An die Abschaffung des Lockings muss mancher sich erst gewöhnen, ist in modernen Zugriffskonzepten aber schon allgemein im Gebrauch. Bei "optimistischem Locking" bekommt der Benutzer erst einen auf die Finger, wenn er einen geänderten Datensatz speichern will, aber seit seinem Lesen bereits ein anderer geschrieben hat. Das hat den Vorteil, dass der Datensatz nicht stundenlang gelockt ist und deshalb von keinem anderen Programm mehr aktualisiert werden kann.
Die Daten im Cache können temporär verändert werden z.B. mit zusätzlichen Datenfeldern.
Eine Lücke im neuen Konzept ist noch, dass Schema-Daten nicht geändert werden können, also keine Tabellen oder Felder zur Datenbank hinzugefügt oder gelöscht werden können.
In den Ausnahmefällen, in denen die Möglichkeiten von ADO.net nicht ausreichend sind, kann weiterhin auf ADO 2.6 zurückgegriffen werden.
ASP gibt es nicht mehr. Stattdessen gibt es ein neues Konzept namens ASP.net. Man kann mit .net-Sprachen WebForms entwickeln, die wesentlich performanter sind, weil sie kompiliert werden.
Webforms können serverseitige WebControls enthalten. Im Browser ist es ein reines Form-Element, aber auf dem Server wird Funktionalität hinzugefügt, wie z.B. dass Feldinhalte nach dem Submit erhalten bleiben. Es gibt auch ein DataGrid Control, das wie in VB funktioniert. Es wird automatisch mit Daten gefüllt und in der HTML-Seite wird es als Table abgebildet. HTML und Programmcode werden getrennt gespeichert, ein Prinzip, dass man "CodeBehind" nennt.
HTTP ist stateless, das heisst zwischen zwei Formularen können keine Daten ausgetauscht werden. Da es für viele Anwendungen häufig aber doch nötig ist, muss man hintenherum doch wieder Daten aufbewahren. Dies geschah bisher häufig mit Cookies, die unbeliebt sind, weil Daten auf dem Rechner des Benutzers gespeichert werden. Darum führt man Sessions ein. Sessions werden über eine Session-Id verwaltet, die im HTML-Code in einem Hidden Feld gespeichert ist. Es sind keine Cookies notwendig. Alle Statusinformationen können auf einem externen Server gespeichert werden und sind somit unabhängig vom Web-Server verfügbar.
Mit dem http-Handler kann man das System anpassen, z.B. Dokumente umwandeln von XML in HTML.
An COM+ wird sich nichts ändern, es wird einfach in das .net-Konzept übernommen. COM+-Anwendungen müssen sich künftig von ServicedComponent ableiten. Das .net-Remoting wird DCOM ersetzen
COM+-Anwendungen können als WebServices verwendet werden.
© Mario Boller-Olfert 2001-2002 - E-Mail:Kontaktformular - 123-Byte - Homepage