Wer dachte, dass die Entwicklung von .NET mit der neuen Windows Server-Version abgeschlossen ist, sieht sich getäuscht. Bereits im kommenden Jahr leitet Microsoft die nächste Phase ein und wird mit dem SQL Server Yukon das erste konsequent auf .NET abgestimmte Server-Produkt veröffentlichen.
Schon lange hat Microsoft die Vision einer einheitlichen Datenhaltung. Egal ob Office-Dokumente, eMails oder das persönliche Videoarchiv, alles sollte auf gleiche Weise gespeichert werden. Damit möchte man einerseits Inkonsistenzen vermeiden und sich andererseits aufwändige und teuere Parallelentwicklung eigentlich funktionsgleicher Softwaremodule sparen. Schon heute wird diese Strategie in den Produkten Exchange und SharePoint Portal Server umgesetzt, die beide auf das Web Storage System (WSS) aufbauen. Hierbei spielt der SQL Server eine zentrale Rolle, dessen Technologie in Windows Longhorn Basis für ein neues Filesystem sein wird. Als inoffizieller Release-Termin steht momentan Ende 2003 im Raum, genaueres erfährt man derzeit leider nicht. Zusammen mit Yukon wird es auch ein neues .NET Framework in der Version 2, sowie ein neues Visual Studio für Yukon geben.
Das Besondere an dem SQL Server Yukon ist die Integration der Common Language Runtime (CLR), die es unter anderem ermöglicht, Serverprozeduren direkt in einer der .NET-Sprachen zu schreiben. Vorbei die Zeiten, in denen man sich auch noch mit T-SQL beschäftigen musste. Die Prozeduren werden dem Server in Form von Assemblies bereitgestellt, der diese direkt in seinem Speicherbereich ausführt. Dabei bleiben die Vorzüge der CLR, beispielsweise kontrollierter Speicherzugriff, erhalten. Aber um es vorweg zu nehmen: T-SQL wird (vorerst) natürlich weiterhin unterstützt.
Der Datenzugriff geschieht dabei über ADO.NET, ein entsprechender Namensraum ist bereits reserviert. Unter System.Data.SqlServer wird ein neues Set an Interfaces bereitgestellt, die direkten Zugriff auf den Abfrageprozessor des SQL Servers erhalten. Demnach sollte einer Programmierung performanter Datenbankanwendungen nichts mehr im Wege stehen. Bereits heute existiert mit System.Data.SqlTypes eine vollständige Sammlung SQL Server-kompatibler Datentypen. So ist es möglich, Variablen vom Typ money oder varchar zu deklarieren, um problemlos und ohne notwendige Konvertierungsschritte Daten auszutauschen.
Eine in C# geschriebene SQL Server-Funktion könnte so aussehen:
using System.Data.SqlServer;
using System.Data.SqlTypes;
public class MeineKlasse
{
public shared SqlInt32 MeineFunktion(SqlInt32 ID)
{
SqlCommand cmd = SqlContext.GetCommand();
cmd.CommandText = SELECT SUM(n) FROM EineTabelle WHERE ID=@ID;
Besonders zu beachten ist der Aufruf SqlContext.GetCommand(), der den direkten Zugriff auf den Abfrageprozessor ermöglicht.
Zudem darf man auf ein neues Sicherheitskonzept gespannt sein, denn mit der Integration von .NET werden auch die .NET-Sicherheitsmechanismen integriert. So wird per Standardeinstellung nur der Zugriff auf die Daten innerhalb des SQL Server-Prozesses erlaubt, nicht aber auf GUI, unmanaged Code oder die Erstellung eines Threads. Die Rechte werden dabei vom SQL Server verwaltet, einen anderen Weg - und damit ein Umgehen der Rechteverwaltung - wird es nicht geben. Zur Laufzeit wird jeder Zugriff auf gesicherte Ressourcen geprüft, sowohl der auszuführende Code selbst als auch der Code des Aufrufers. Um die Administration zu vereinfachen, hat Microsoft drei Standardrechte für eingebundene .NET-Assemblies angedacht:
SAFE: Rechenoperationen und Zugriff auf die Daten sind erlaubt. Ressourcen außerhalb des SQL Servers sowie unmanaged Code sind dagegen unzugänglich. Der Quellcode muss von der Common Language Runtime überprüfbar sein. (Standardeinstellung)
EXTERNAL_ACCESS: Zusätzlich ist das Erstellen von Tabellen, Abfragen und weiteren Objekten erlaubt.
UNRESTRICTED: Das Recht entspricht dem heutigen Recht beim Ausführen einer Stored Procedure, jeder Ressourcenzugriff ist erlaubt. Nur System-Administratoren dürfen unrestricted code ausführen. Dieser Level erlaubt das Ausführen von unmanaged und nicht von der CLR verifizierbarem Quellcode.
Um eigene Assemblies integrieren zu können, wurde T-SQL um einige Befehle erweitert. Mit dem Befehl CREATE ASSEMBLY wird eine Assembly initialisiert:
CREATE ASSEMBLY MeinAssembly FROM `\\Pfad\Ordner\MeinAssembly.dll'
WITH PERMISSION_SET = EXTERNAL_ACCESS
Der Parameter WITH AUTOREGISTER registriert die in der Assembly bereitgestellten Funktionen je nach Deklaration im Quellcode als Stored Procedure, Trigger usw. Assemblies werden in der Datenbank gespeichert und somit bei Backup und Restore berücksichtigt. Mit DROP ASSEMBLY wird eine Assembly analog zu DROP TABLE wieder gelöscht. Dabei werden Abhängigkeiten geprüft, um die Konsistenz der Datenbank zu gewährleisten. Daher ist es nicht möglich, eine Assembly zu löschen, die für einen berechneten Index benötigt wird. Um eine Löschung zu erzwingen, wird jedoch der Parameter FORCE zur Verfügung stehen.
Wurde eine Assembly geladen, so stehen die Methoden innerhalb der Datenbank zur Verfügung. Man kann sie aber auch aus einer T-SQL Funktion aufrufen, was besonders bei der Portierung existierender Anwendungen hilfreich sein wird. Die Funktionsköpfe bleiben erhalten und die Aufrufe werden an die .NET-Funktion weitergeleitet:
CREATE FUNCTION AssemblyFunktion (@a int) RETURNS int
EXTERNAL NAME `MeinAssembly:MeineKlasse.MeineFunktion'
DETERMINISTIC
Am Aufruf dieser T-SQL Funktion ändert sich nichts:
SELECT * FROM EineAndereTabelle WHERE AssemblyFunktion(Parameter1) = 42
Würde man auf die Kapselung verzichten, so müsste der Aufruf wie folgt geschehen:
SELECT * FROM EineAndereTabelle WHERE MeinAssembly:MeineKlasse.MeineFunktion(Parameter1) = 42
Der Parameter DETERMINISTIC besagt, dass die Funktion bei gleichen Eingabewerten das gleiche Ergebnis liefert. Dadurch ist es möglich, diese Funktion für einen berechneten Index zu nutzen.
Auch Stored Procedures und Trigger werden auf gleiche Weise gekapselt:
CREATE PROCEDURE AssemblyProzedur
EXTERNAL NAME `MeinAssembly:MeineKlasse.MeineProzedur'
CREATE TRIGGER MeinTrigger ON EineTabelle
AFTER INSERT, UPDATE
EXTERNAL NAME `MeinAssembly:MeineKlasse.MeineTriggerProzedur'
Eine der größten Innovationen dürfte die Einführung benutzerdefinierter Datentypen basierend auf .NET-Klassen sein. Speichert man Werte dieser Typen, so werden die Objekte vollständig inklusive aller Properties und Methoden serialisiert.
CREATE TYPE MeineKlasse
EXTERNAL NAME `MeinAssembly:MeineKlasse'
Diese Datentypen kann man jetzt bei der Tabellenerstellung verwenden:
CREATE TABLE BeispielTabelle (
id INT PRIMARY KEY,
name char(20),
Variablenname MeineKlasse)
und entsprechend in einem Select-Statement benutzen:
SELECT * FROM BeispielTabelle WHERE Variablenname::MeineFunktion(n) > 0
Mit der Integration des .NET Frameworks wird man in der Lage sein, die gesamte Middle-Tier-Logik innerhalb des Servers zu kapseln, ohne auf die Performance einer kompilierten Anwendung verzichten zu müssen. T-SQL-Befehle werden dagegen mehr oder weniger zur Laufzeit interpretiert. Bei reinen Datenzugriffen ist der Geschwindigkeitsvorteil nicht so hoch zu erwarten, die Ausführungsgeschwindigkeit wird äquivalent zu T-SQL-Code sein. Erst bei komplexen Routinen und Berechnungen wird der Performancevorteil der CLR zur Geltung kommen. Neben der Performance wird auch die Frage der Skalierbarkeit entscheidend für den Erfolg des SQL Server-Nachfolgers sein. Daher soll Yukon bei gleicher Hardware mindestens gleich viele Benutzer mit Daten bedienen können wie der jetzige SQL Server 2000. Microsoft arbeitet an einer erweiterten Speicherverwaltung zwischen dem SQL Server und der CLR. Bei geringen Speicherressourcen soll der SQL Server in der Lage sein, den Garbage Collection Manager anzustoßen, um nicht mehr benötigten Speicher vorzeitig freizugeben. Auf der anderen Seite soll auch die CLR nicht mehr verwendeten Speicher innerhalb des SQL Servers wieder freigeben können.
Aber auch bekannte Features werden mit Yukon fortgeführt. Besonders die XML-Unterstützung wird neben der CLR-Integration eine wesentliche Rolle spielen. Derzeit kann der SQL Server 2000 zwar mit einigen Updates um neue XML-Funktionalitäten erweitert werden, aber die Performance und manche Details lassen häufig zu wünschen übrig. Hier wird Microsoft nachbessern und die XML-Unterstützung direkt ins Herz des neuen SQL Servers integrieren. Performant und reich an Features - so scheint das Motto zu sein.
Zeitnah zum SQL Server Yukon wird es ein neues Visual Studio für Yukon geben. Das Augenmerk liegt in der verbesserten Integration des SQL Servers: IntelliSense und Command Completion inklusive eines Auflistens verfügbarer Tabellen und Spalten stehen auf dem Programm. Man kann zwar schon heute Stored Procedures debuggen, aber mit der Integration der CLR wird man auch hier noch einiges an Funktionen nachlegen können.
Neben der Unterstützung des neuen SQL Servers werden XML Web Services ein weiterer Schwerpunkt sein. Microsoft hat angekündigt, das Verknüpfen mehrerer Dienste innerhalb eines Projekts zu erleichtern. Des Weiteren werden Community-Features in die Visual Studio-Umgebung Einzug erhalten und den Entwickler mit allen Informationen versorgen, die er für seine tägliche Arbeiten braucht. Als letztes bleibt noch zu erwähnen, dass Microsoft auch seine Office-Produkte mit .NET veredeln möchte. Für Visual Studio für Yukon ist eine erste Integration der Office-Programmierung vorgesehen. Obwohl VBA zunächst erhalten bleibt, scheint das Ziel zu sein, alles unter Visual Studio zu vereinheitlichen. - Wer sich als Visual Studio-Programmierer einmal in VBA einarbeiten durfte, wird die Vorzüge bereits jetzt zu schätzen wissen.
Ausblick
Im Großen und Ganzen dürfte klar werden, welche Richtung Microsoft verfolgt, nämlich alles auf .NET anzupassen. Der SQL Server Yukon ist das erste Beispiel der großen Umbaumaßnahme. Obwohl die Vorteile offensichtlich sind, wird es einmal mehr Einarbeitungs- und Portierungsaufwand bedürfen, um am Ball zu bleiben. Es bleibt abzuwarten, ob die IT-Manager und Softwareentwickler in diesem Punkt mit Microsoft Schritt halten können - und letztendlich auch wollen.
