Dieser Artikel beschreibt die Architektur von Microsoft Windows SharePoint Services. Sie erhalten Informationen über die Serveraktionen bei Seitenanforderungen von Benutzern und die Reaktion von Windows SharePoint Services. Auch die Funktion von verwaltetem Code im Vergleich zu nicht verwaltetem Code in Windows SharePoint Services und zum Datenbankschema von Windows SharePoint Services wird erläutert. Dieser Artikel enthält auch Links zu englischsprachigen Seiten.

Auf dieser Seite

 Allgemeine Systemübersicht
 Webservertopologie
 Verarbeitung von Anforderungen in IIS und über den ISAPI-Filter
 Webpart-Infrastruktur
 Nicht verwalteter Code in Windows SharePoint Services
 Inhalt der Konfigurationsdatenbank
 Schlussfolgerung

Allgemeine Systemübersicht

Innerhalb einer Microsoft Windows SharePoint Services-Anwendung sind drei Arten von Serverkomponenten aktiv:

• Mindestens ein Front-End-Webserver

• Eine Konfigurationsdatenbank

• Mindestens ein Inhaltsdatenbankserver

Sie können diese drei Komponenten auf einem Computer installieren oder auf mehrere Computer in einer Serverfarm verteilen. Alle Zustandsinformationen werden über die Inhalts- und Konfigurationsdatenbanken im Microsoft SQL Server verwaltet.

Abbildung 1. Allgemeine Übersicht über eine Windows SharePoint Services-Bereitstellung

Webserver
In einer Serverfarm mit Windows SharePoint Services sind Webserver nur statusfreie Klone. Eine Anforderung kann über den Lastenausgleich an jeden beliebigen Webserver weitergeleitet, jede Site kann von jedem Webserver bedient werden. Der Webserver stellt zum Abrufen der Daten eine Verbindung zu einer Back-End-Datenbank her, um die Webseite zu erstellen und an den Client zurückzugeben. Wenn ein Webserver in einer Serverfarm ausfällt, werden die Anforderungen an die anderen Webserver weitergeleitet. Sie können die Kapazität der Bereitstellung erhöhen, indem Sie Webserver hinzufügen. Dokumente und andere Endbenutzerdaten werden nicht auf den Webservern gespeichert. Der gesamte Inhalt der Website sowie die Konfigurationseinstellungen werden auf den Datenbankservern gespeichert.

Inhaltsdatenbankserver
In der Back-End-Inhaltsdatenbank wird der gesamte Inhalt der Site gespeichert. Dazu gehören alle Dokumente oder Dateien der Site in den Dokumentbibliotheken, Listendaten und Eigenschaften der Webparts sowie die Benutzernamen und -rechte. Im Gegensatz zu Webservern sind Inhaltsdatenbankserver nicht identisch. Alle Daten zu einer bestimmten Site werden in einer Inhaltsdatenbank auf genau einem Computer gespeichert. SQL Server bietet eine Failover-Sicherung, die verhindert, dass der Dienst unterbrochen wird, wenn ein Datenbankserver ausfällt.

Konfigurationsdatenbank
Über die Konfigurationsdatenbank erfolgt die vollständige Verwaltung der Bereitstellung, das Umleiten von Anforderungen an die entsprechende Datenbank und das Verwalten des Lastenausgleichs für die Back-End-Datenbanken. Wenn ein Front-End-Webserver eine Anforderung für eine Seite auf einer bestimmten Site empfängt, wird die Konfigurationsdatenbank von diesem überprüft, um die Inhaltsdatenbank mit den Daten der Site zu ermitteln. Sie können die Konfigurationsdatenbank auf einem Computer zusammen mit einem Webserver oder auf einem Remotecomputer mit Microsoft SQL Server ausführen.

 Zum Seitenanfang

Webservertopologie

Die Topologie oder logische Anordnung der Webserver in einer Windows SharePoint Services-Bereitstellung ist vom Kontext abhängig. Wenn Sie Windows SharePoint Services bereitstellen, werden standardmäßig zwei virtuelle Server oder Websites in Microsoft Internet Information Services (IIS) erstellt. Sie erstellen eine Website für einen virtuellen Verwaltungsserver und erweitern die vorhandene IIS-Website an Port 80, um einen virtuellen Benutzer- oder Laufzeitserver zu erstellen.

Abbildung 2. Virtuelle Standardserver für Verwaltung und Benutzer in IIS

Sie können nur einen virtuellen Verwaltungsserver auf einem Computer erstellen, mit dem Sie alle Front-End-Webserver konfigurieren und auf neue virtuelle Server erweitern.

In einer Windows SharePoint Services-Bereitstellung können Sie mehrere virtuelle Server implementieren. Sie können die virtuellen Server auf zwei Arten konfigurieren. Bei der Standardkonfiguration werden die Domänennamen zu virtuellen Servern in IIS aufgelöst. Bei dieser Konfiguration können mehrere virtuelle Server erstellt werden, und zwar ein Domänenname pro Server. Bei der zweiten Konfiguration, dem so genannten skalierbaren Hostheader-Modus, wird die Kapazität des in IIS verwendeten Hostheader-Modus erweitert, der einen einzelnen virtuellen Server als Host für mehrere Domänennamen zulässt, wobei der Hostheader oder der Domänenname für das Auflösen der Sites verwendet wird.

Das Skalierelement für einen virtuellen Benutzerserver ist die Websitesammlung, die sich aus einer Website der obersten Ebene oder Stammwebsite (z. B. http://VServer/[Websites/]WebsiteSammlung) und einer beliebigen Anzahl von Unterwebsites (z. B. http://VServer/[websites/]WebsiteSammlung/Unterwebsite) zusammensetzt. Die Website der obersten Ebene enthält z. B. Webparts und Kataloge von Listenvorlagen und Websitevorlagen und ermöglicht die Verwaltung aller Websites in der Websitesammlung. Ein virtueller Server wird durch die Websitesammlungen partitioniert, die das Teilen eines bestimmten URL-Namespaces in verschiedene Segmente ermöglichen. Dabei hat jede Websitesammlung einen eigenen Namespace (z. B. http://VServer/[Websites/]ErsteWebsiteSammlung, http://VServer/[Websites/]ZweiteWebsiteSammlung usw.). Windows SharePoint Services können einen Lastenausgleich für die Websitesammlungen über mehrere Inhaltsdatenbanken durchführen. Die einzelnen Websites befinden sich aber immer in derselben Datenbank wie ihre übergeordnete Websitesammlung.

IIS erkennt keine Websitesammlungen, die nicht mit IIS-Websites oder virtuellen IIS-Verzeichnissen übereinstimmen.

Hinweis für SharePoint Portal Server 2003 Wenn Sie Microsoft Office SharePoint Portal Server 2003 bereitstellen, ist die Portalwebsite eine Windows SharePoint Services-Websitesammlung mit zusätzlichen Funktionen. Es gibt eine Portalwebsite pro virtuellem Server. Sie können auf dem virtuellen Server aber zusätzliche Windows SharePoint Services-Standardwebsitesammlungen erstellen.

 Zum Seitenanfang

Verarbeitung von Anforderungen in IIS und über den ISAPI-Filter

IIS verarbeitet die grundlegenden HTTP-Anforderungen, Windows SharePoint Services implementiert jedoch den ISAPI-Filter STSFLTR.DLL, der das IIS-Verhalten ändert, damit verwaltete Pfade sowie Inklusionen und Exklusionen verarbeitet werden können. Der ISAPI-Filter leitet Anforderungen entweder an die Windows SharePoint Services-ISAPI-Erweiterung weiter oder er filtert ASPX-Seiten (.aspx) und Webdienst-URLs (.asmx) und leitet diese an den SharePoint-ASP.NET-Handler weiter.

Abbildung 3. HTTP-Anforderungen werden an ASP.NET oder die ISAPI-Erweiterung weitergeleitet

Hinweis für SharePoint Portal Server 2003 Wenn Sie SharePoint Portal Server bereitstellen, werden die Dienst- und Profildatenbanken ebenfalls in SQL Server erstellt, und es wird eine ADO.NET-Schicht unterhalb von ASP.NET implementiert.

Die Funktion von IIS
IIS leitet HTTP-Anforderungen an die entsprechende Anwendung weiter. Dabei wird der Treiber HTTP.SYS für das Warten an dem für eine IIS-Website oder einen virtuellen SharePoint-Server festgelegten Port sowie für das Verarbeiten eingehender IP-Pakete verwendet. Als Standardeinstellung werden Port 80 für HTTP- und Port 443 für HTTPS-Anforderungen verwendet. IIS löst die Anforderungen mithilfe des Domänennamens, des Ports und der IP-Adresse des virtuellen Servers auf, an den die Anforderung gerichtet ist. IIS-Websites bieten in einer Bereitstellung Verwaltungs-, Sicherheits- und Ressourcengrenzen, Windows SharePoint Services führen jedoch zum Verarbeiten von Websiteaktivitäten Code von der Ebene der virtuellen Server abwärts aus.

IIS verarbeitet die gesamte Benutzer-Authentifizierung (Anonyme Authentifizierung, Integrierte Windows-Authentifizierung oder Basis-Authentifizierung) pro virtuellem Server und verwaltet das Aktivieren anonymer Anforderungen. Wenn der anonyme Zugriff in IIS deaktiviert ist, ist er für den gesamten virtuellen Server deaktiviert, so dass anonyme Anforderungen niemals Windows SharePoint Services erreichen. Windows SharePoint Services müssen jedoch für die Annahme von nicht authentifizierten Anforderungen konfiguriert sein. Wenn IIS für das Annehmen anonymer Anforderungen konfiguriert ist, Windows SharePoint Services jedoch nicht, werden die Anforderungen trotzdem abgelehnt.

Windows SharePoint Services verwenden neben IIS für die Benutzer-Authentifizierung die neue Funktion für Anwendungspools von IIS 6 für das Ausführen von virtuellen Servern in unterschiedlichen Anwendungspools. Jeder Anwendungspool verfügt über eigene Prozessor- und Speicher-Ressourcen, um einen isolierten Satz von Arbeitsprozessen bereitzustellen, in dem die Webanwendungen ausgeführt werden. Windows SharePoint Services verwenden Anwendungspools zum Bearbeiten der Ressourcenzuordnung. Dieser Ansatz bietet die folgenden Vorteile:

• Prozessidentität: Wenn Windows SharePoint Services eine Verbindung zu SQL Server herstellen und für die SQL Server-Authentifizierung konfiguriert wurde, verwenden sie dabei eine Identität aus dem Anwendungspool.

• Prozessisolation: Unterschiedliche virtuelle Server lassen sich auf demselben Computer ausführen. Dabei können ihre Datenbanken vollständig voneinander getrennt sein, wenn die Server unter verschiedenen Konten ausgeführt werden, obwohl sie eine gemeinsame Konfigurationsdatenbank verwenden. Anwendungspools bieten eine Sicherheitsgrenze, bei der jeder Anwendungspool eigene Anmeldeinformationen auf dem Server benötigt.

• Anwendungsrecycling: In früheren Versionen von IIS konnten Prozesse über eine lange Zeit ausgeführt werden, so dass Ressourcenverlust ein ernst zu nehmendes Problem für den Server war. In der aktuellen Version von IIS werden Prozesse recycelt, so dass Verluste den Server nicht beeinträchtigen.

Änderungen von Windows SharePoint Services an IIS
Windows SharePoint Services verwenden IIS-Anwendungspools und -Authentifizierung ohne Änderungen. Andere IIS-Dienste wie virtuelle Server oder die Handhabung von Anforderungen werden für die Integration in die Windows SharePoint Services-Architektur allerdings angepasst. Bei einer Installation auf einem einzelnen Computer ersetzen Windows SharePoint Services den IIS-Standardanwendungspool DefaultAppPool durch den eigenen Anwendungspool STSAppPool1, der für den Standardserver für Benutzer verwendet wird, und erstellen für den virtuellen Verwaltungsserver den zusätzlichen Anwendungspool STSAdminAppPool. Bei einer Serverfarm erstellen und benennen die Administratoren die beiden Anwendungspools.

Hinweis für SharePoint Portal Server 2003 Der Name des in SharePoint Portal Server standardmäßig erstellten Anwendungspools für die Verwaltung lautet CentralAdminAppPool.

Im Gegensatz zu SharePoint Team Services von Microsoft speichern Windows SharePoint Services in der IIS-Metabase keine Konfigurationsdaten unterhalb der Ebene der virtuellen Server. Alle Informationen zu Websites und Websitesammlungen werden in der SharePoint-Konfigurationsdatenbank unabhängig von IIS gespeichert, so dass die Verwaltung der Konfiguration der Serverfarm erheblich erleichtert wird.

Verarbeitung von Anforderungen für Pfade über den ISAPI-Filter
Vor der Authentifizierung untersucht der ISAPI-Filter (STSFLTR.DLL) die angeforderte URL, um zu überprüfen, ob die Anforderung einem verwalteten Windows SharePoint Services-Pfad gilt. Dabei wird eine vom Administrator geführte Liste ein- und ausgeschlossener Pfade verwendet. Der ISAPI-Filter leitet die Anforderungen entsprechend der folgenden Logik weiter:

• Kein verwalteter Pfad - Weiterleitung zulassen.

• Verwalteter Pfad und in einem virtuellen Verzeichnis wie _layouts oder _vti_bin - Umschreiben des URLs in _layouts oder _vti_bin im Serverstamm.

• Wenn verwalteter Pfad, aber nicht in _layouts, und Anforderung für eine ASPX- oder ASMX-Datei - Weiterleitung zulassen. In diesem Fall wird die Anforderung von der ASP.NET-ISAPI-Erweiterung und anschließend vom verwalteten Handler von Windows SharePoint Services verarbeitet.

• Wenn kein verwalteter Pfad, aber nicht in _layouts und keine ASPX- oder ASMX-Datei - Umschreiben in die ISAPI-Erweiterung von Windows SharePoint Services.

Anforderungen für die SharePoint-ISAPI-Erweiterung treten bei statischen HTML-Seiten, bei älteren Protokollen wie dem RPC-Protokoll (Remote Procedure Call) der FrontPage-Servererweiterungen, beim neuen DAV-Protokoll sowie bei statischen Seitenabrufen mit GET (z. B. zum Abrufen einer HTM- oder DOC-Datei) auf.

Die wichtigste Funktion verwalteter Pfade ist das Definieren der von Windows SharePoint Services verwalteten URL-Namespaces. Sie definieren jedoch auch die Pfade, die bei der selbstständigen Websiteerstellung verwendet werden. Dadurch können Administratoren steuern, wo Websites erstellt werden dürfen (z. B. durch das Einschränken der Websiteerstellung auf ein bestimmtes Verzeichnis und das Einschließen von einem URL wie http://Server/BenutzerWebsites/).

Pfade werden entweder eingeschlossen oder ausgeschlossen. Exklusionen geben an, dass ein bestimmter URL-Namespace nicht zu einer erweiterten Website gehört. Damit wird verhindert, dass Windows SharePoint Services die Anforderung abfangen. Windows SharePoint Services ignorieren Anforderungen an einen ausgeschlossenen Pfad. Inklusionen geben im Gegensatz dazu an, wie ein URL-Namespace in einer SharePoint-Bereitstellung in verschiedene Websitesammlungen aufgeteilt wird. Es gibt zwei Arten von Inklusionen.

• Ausdrückliche Inklusion bedeutet, dass der Stamm des Servers selbst eine SharePoint-Website ist. Außerdem wird dadurch eine Website angegeben, die von Windows SharePoint Services verwaltet wird.

• Platzhalterinklusion gibt eine vollständige Websitesammlung unterhalb eines bestimmten Verzeichnisses an, das von Windows SharePoint Services verwaltet wird.

Hinweis Wenn Sie eine Aktualisierung auf SharePoint Portal Server 2001 durchführen und die Webspeicher-Dokumentverwaltung einsetzen, verwendet SharePoint Portal Server eine Exklusion, um die URL im Webspeichersystem anzugeben, z. B. unterhalb eines virtuellen Verzeichnispfads des Stamms der Portalwebsite. SharePoint Portal Server implementiert standardmäßig zwei Platzhalterinklusionen, eine für Teams und eine für persönliche Websites. Außerdem verwendet er Partitionierungsschemas (z. B. /teams oder /sites), um Konflikte zwischen Websiteordnern oberster Ebene und Sammlungen von Unterwebsites zu vermeiden.
ASP.NET-Handler und Seitendarstellung
Der ASP.NET-Handler in Windows SharePoint Services fungiert als ein Filter, der den ASP.NET-Modus für das Ausführen einer Seite festlegt. Dies kann der direkte oder der sichere Modus sein.

Seiten im virtuellen Verzeichnis /_layouts, auch als Anwendungsseiten bezeichnet, werden im direkten Modus ausgeführt. Das heißt, dass Windows SharePoint Services diese Seiten nicht abfangen, sondern die normale Ausführung in ASP.NET zulassen. Anwendungsseiten enthalten z. B. systemeigene SharePoint-Seiten für das Erstellen neuer Listen, das Bearbeiten von Ansichten usw. Der Inhalt des Verzeichnisses /_layouts gilt dabei als nicht zur Website gehörig, und die zugehörigen Seiten werden bei Anforderungen direkt von IIS bereitgestellt. Bei benutzerdefinierten ASP.NET-Seiten in diesem Verzeichnis kann beliebiger Code verwendet werden.

ASP.NET-Seiten in einer Website, z. B. die Startseite, Seiten für das Anzeigen von Listen und Elementen und Webpartseiten, werden als Benutzerseiten bezeichnet und im sicheren Modus ausgeführt. Das bedeutet, dass Windows SharePoint Services das Ausführen von Webformular-Steuerelementen auf diesen Seiten nur dann zulassen, wenn der Administrator die Steuerelemente als sicher eingestuft hat. Sie können diese Seiten z. B. über die Benutzeroberfläche oder mit Microsoft Office FrontPage 2003 anpassen, Sie können auf Benutzerseiten jedoch nicht beliebigen Code einfügen, da diese zur Laufzeit im Browser lediglich als Text dargestellt werden. Im Gegensatz zum direkten Modus wird die ASP.NET-Seite im sicheren Modus nicht in eine DLL-Datei kompiliert. Sie können die Liste der sicheren Steuerelemente, die auf den Websites eines bestimmten virtuellen Servers ausgeführt werden dürfen, anpassen, indem Sie die Datei web.config des Servers bearbeiten.

Hinweis Damit eine ASP.NET-Anwendung zusammen mit Windows SharePoint Services auf demselben Server ausgeführt werden kann, ohne dass durch den SharePoint-ISAPI-Filter Konflikte ausgelöst werden, muss die URL der Anwendung ausgeschlossen werden. Außerdem muss der SharePoint-ASP.NET-Handler aus der Datei web.config der Anwendung entfernt werden. Da der Code in der Anwendung über einen ausgeschlossenen URL ausgeführt werden muss, darf er keinen Verweis auf die Windows SharePoint Services-Assembly enthalten. Weitere Informationen finden Sie unter Working with web.config Files im Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).

 Zum Seitenanfang

Webpart-Infrastruktur

Die Webpart-Infrastruktur ermöglicht Windows SharePoint Services die Verarbeitung im sicheren Modus. Dadurch können Sie Webparts anhand der Seiten-URLs, der aktuellen Benutzer-ID oder anderer in der Datenbank gespeicherter Informationen zu einer ASP.NET-Seite hinzufügen.

Abbildung 4. Auffüllen der Zonen einer Webpartseite

Wenn eine Webpartseite im Browser geöffnet wird, verwenden Windows SharePoint Services die Seiten-URL und die Benutzer-ID, um eine Liste der für die Seite angegebenen Webparts von SQL Server zurückzugeben und ein ASP.NET-Seitenobjekt zu erstellen. Anhand dieser Informationen werden die Webpartzonen auf der Seite mit den entsprechenden Webparts aufgefüllt. Die Startseite einer SharePoint-Website enthält z. B. standardmäßig zwei Webpartzonen mit Webparts, die Übersichten über Ankündigungen, Ereignisse und Verknüpfungen enthalten, sowie einen Bildwebpart mit einem Logo. Wenn der Administrator allerdings das Anpassen der Seite zulässt und ein Benutzer die Seite ändert, zeigen Windows SharePoint Services je nach Benutzer unterschiedliche Webparts an.

 Zum Seitenanfang

Nicht verwalteter Code in Windows SharePoint Services

Der größte Teil der in Windows SharePoint Services verwendeten Logik für die Arbeit mit Websites und Listen liegt in nicht verwaltetem Code vor und wird größtenteils über DLL-Dateien aus der früheren Version SharePoint Team Services bereitgestellt. Webparts und andere ASP.NET-Objekte in Windows SharePoint Services sowie die ISAPI-Erweiterung sind nur dünne Schichten über dem nicht verwalteten Code. Webparts und Webdienste bauen auf dem neuen SharePoint-Objektmodell auf, wobei das Objektmodell im Gegenzug als Wrapper fungiert, der die Aufrufe im nicht verwalteten Code durchführt.

Nicht verwalteter Code unterstützt Microsoft Office FrontPage 2003-Servererweiterungen, das DAV-Protokoll, das Erstellen von Ansichten, statische Dokumentabrufe mit GET und alle Datenbankeingaben/-ausgaben. Die wichtigste DLL-Datei owssvr.dll stellt einen Großteil der Logik für die Arbeit mit Listen bereit. Dazu gehört auch die Logik für das Interpretieren der systemeigenen XML-Sprache CAML (Collaborative Application Markup Language), die zum Definieren von Daten und zum Ausgeben von Text verwendet wird.

Jeder Front-End-Webserver enthält Website- und Listendefinitionen im Installationsverzeichnis (Lokales_Laufwerk:\Programme\Gemeinsame Dateien\Microsoft Shared\Webservererweiterungen\60\), die auch die CAML-Schemadateien enthalten. Die Schemadateien legen z. B. fest, wie Instanzen neuer Websites und Listen erstellt und wie Listendaten angezeigt werden. Weitere Informationen über Website- und Listendefinitionen finden Sie unter Introduction to Templates and Definitions.

Hinweis für SharePoint Portal Server 2003 SharePoint Portal Server implementiert zusätzlich den Zugriff mit verwaltetem Code auf seine Datenbanken über ADO.NET.

Erstellen von Ansichten
CAML definiert die Darstellung von Ansichten in einem Webpart. Jeder Listentyp von Windows SharePoint Services verfügt im Verzeichnis \web server extensions\60\TEMPLATE\Sprach_ID\Website_Definition\LISTS über eine eigene Datei mit der Bezeichnung SCHEMA.XML, die die Darstellung von Listen auf HTML-Seiten beim Anzeigen im Browser definiert. In der früheren Version SharePoint Team Services wurden Listenansichten über die Erweiterung von CAML-Zonen im Browser übertragen (gekennzeichnet mit dem Präfix ows). In Windows SharePoint Services wird die CAML-Ansicht stattdessen über einen Webpart übertragen, wie in der folgenden Abbildung dargestellt.

Abbildung 5. Darstellen einer Listenansicht über einen Webpart in Windows SharePoint Services

Die CAML-Datei SCHEMA.XML enthält Definitionen für die Standardlistenansichten und für die Formulare, die für die Arbeit mit den einzelnen Elementen verwendet werden. CAML wird für das Erstellen des für den Clientbrowser erforderlichen HTML- und Skriptcodes genutzt. Dazu gehören z. B. das Skript, Symbolleisten oder Spaltenkopfzeilen in der Ansichtenkopfzeile, Feldnamen oder Feldwerte im Ansichtentext sowie Eigenschaften für die Seitennavigation oder Listen in der Ansichtenfußzeile. CAML dient bei Windows SharePoint Services für die Ausgabe beliebiger in der Webpartansicht erforderlicher Markupsprachen, Skripte oder von Text im Browser, dazu gehören z. B. HTML, XML, WML, ECMAScript (Microsoft JScript oder JavaScript) usw. CAML wird für das Erstellen komplexer Bereiche wie dem Skript für die Listenansicht eines Kalendersteuerelements verwendet.

Hinweis Der DataView-Webpart erstellt XML-Code aus einer SharePoint-Liste oder -Listenansicht und verwendet XSLT (Extensible Stylesheet Language Transformation) für die Darstellung der Benutzeroberfläche der Listenansicht, so dass umfangreiche Anpassungen auf Grundlage von Standards möglich sind. Die Daten werden von Windows SharePoint Services im XML-Format bereitgestellt, und FrontPage implementiert einen zusätzlichen Webpart für die Darstellung einer Ansicht der Daten.

Neben der Datei SCHEMA.XML werden in Windows SharePoint Services die folgenden CAML-Schemadateien verwendet:

1. WEBTEMP.XML Ermöglicht mehrere Websitedefinitionen in einer Bereitstellung. Dazu gehören z. B. die Standarddefinitionen für die Vorlagen von Teamsite und Dokumentarbeitsbereich in Windows SharePoint Services oder für eine der Vorlagen von Besprechungsarbeitsbereichen.

2. ONET.XML Definiert die in neue Seiten einzufügenden Listen und Seiten.

3. FLDTYPES.XML Definiert die SQL-Implementierung aller in Windows SharePoint Services verwendeten Feldtypen und deren HTML-Darstellung.

4. BASE.XML Definiert die Schemas für globale Listen in der Datenbank, z. B. die Tabellen Lists, Docs und UserInfo.

5. DOCICONS.XML Gibt das Symbol für die einzelnen Dateitypen an und ordnet den Dateityp einer Anwendung zu.

Weitere Informationen über Website- und Listendefinitionen finden Sie unter Introduction to Templates and Definitions sowie unter Customizing SharePoint Sites and Portals: Part 1.

Angepasste Seiten
Im sicheren Modus können Benutzer die Website anpassen, ohne dass sie dabei Code auf dem Server platzieren dürfen. Außerdem verbessert dieser Modus die Skalierbarkeit und reduziert die Anzahl der Objekte, die für die Website erstellt werden müssen, sowie die Datenmenge, die in der Datenbank gespeichert werden muss.

In der Vorversion SharePoint Team Services mussten Sie, um tausende verschiedene Websites auf dem Server zu erstellen, auch tausende verschiedene Kopien jeder einzelnen Benutzerseite für jede Liste erstellen, z. B. von der Datei AllItems.htm oder den Elementformularen. In Windows SharePoint Services enthält die CAML-Schemadatei im Installationsverzeichnis die vollständige Seitendefinition, sofern die Benutzerseite nicht geändert wurde. Außerdem wird die Definition auf dem Front-End-Webserver zwischengespeichert. Durch das Zwischenspeichern der Definition müssen Windows SharePoint Services keine Kopien der Benutzerseiten erstellen, wenn Sie eine Website oder Liste anfertigen. Diese Seiten sind virtuelle Seiten, deren Inhalt von den CAML-Schemadateien abgeleitet wird, obwohl sie wie Seiten im Browser angezeigt werden. Durch die Zwischenspeicherung wird die Skalierbarkeit erheblich erhöht, da Seiten, die nicht geändert wurden, für andere Websites wiederverwendet werden können. Da dies die Speicherung von unnötigen Daten reduziert, wird auch die ansonsten hohe Speicherlast für die Verwaltung von Seiten verringert. Die Datenbank wird von Windows SharePoint Services abgefragt, um zu ermitteln, ob die Seite geändert wurde. Wenn dies nicht der Fall ist, enthält die Datenbank nicht den gesamten Inhalt der Datei. Bei der Abfrage wird dann nur der Pfad zu einem Ordner im Installationsverzeichnis zurückgegeben, der die nicht angepasste Seite enthält. Bei Webpartseiten, die nicht angepasst wurden, ruft SQL Server nur die Liste der Webparts ab, die für die Anzeige in den Webpartzonen erforderlich sind.

Wenn die Seite default.aspx für eine Website angefordert wird, prüfen Windows SharePoint Services zunächst, ob die Seitenquelle geändert wurde. Wenn dies der Fall ist, enthält die Spalte Content in der Tabelle Docs nicht mehr den Wert NULL wie bei nicht angepassten Seiten, sondern den Seiteninhalt im Binärformat. Die Definition wird nicht aus dem Installationsverzeichnis abgerufen, sondern aus der Datenbank. Nach dem Anpassen einer Seite kann diese nicht mehr auf die ursprüngliche Seitendefinition zurückgesetzt werden. Entsprechend wird beim Anpassen der Listenansicht einer Seite AllItems.aspx die geänderte Ansicht in der Spalte tp_View der Tabelle WebParts gespeichert. Die Definition der Listenansicht wird dann nicht mehr aus dem Installationsverzeichnis abgerufen.

 Zum Seitenanfang

Inhalt der Konfigurationsdatenbank

Jede Installation von Windows SharePoint Services verfügt über eine Konfigurationsdatenbank, die die Bereitstellung verwaltet. Sie können die Konfigurationseinstellungen in dieser Datenbank nur über den virtuellen Verwaltungsserver ändern. Für virtuelle Benutzerserver sind die Einstellungen schreibgeschützt.

In der Konfigurationsdatenbank werden die folgenden allgemeinen Daten gespeichert:

• Globale Einstellungen Informationen über die Serverfarm, z. B. über die in der Farm enthaltenen Web- oder Datenbankserver.

• Virtuelle Server Informationen über die einzelnen virtuellen Server in der Bereitstellung, z. B. über den für einen bestimmten virtuellen Server zu verwendenden SMTP-Server oder über Standardeinstellungen für Websites.

• Websitezuordnung Informationen darüber, welche Inhaltsdatenbank die Daten für eine bestimmte Website enthält. Wenn Windows SharePoint Services den URL einer Anforderung empfangen, legen die Einstellungen in dieser Datenbank fest, welche Inhaltsdatenbank die Daten für die Website enthält.

Abbildung 6 zeigt die Funktionsweise der Websitezuordnung bei einer Suche in der Inhaltsdatenbank.

Abbildung 6. Suche in der Inhaltsdatenbank basierend auf dem relativen URL zum virtuellen Server

Auf dem Server wird eine Anforderung für http://MeinServer/Websites/MeineWebsite/Lists/AllItems.ASPX veröffentlicht. Der entscheidende Teil der URL - Websites/MeineWebsite - gibt die Websitesammlung in der Anforderung an. Da der Standard für Websites eine Platzhalterinklusion für die auf dem Server erstellten Websitesammlungen bietet, ist Websites/MeineWebsite ein zum virtuellen Server relativer Abschnitt, der die Websitesammlung angibt. Da der wichtige Teil der URL den Computernamen ausschließt, können zwei virtuelle Server mit derselben Adresse oder mit unterschiedlichen Adressen denselben Inhalt zur Verfügung stellen. Die Websitedaten können z. B. für Extranet und Intranet unterschiedlich sein.

Im vorherigen Beispiel gibt die Konfigurationsdatenbank an, dass die Daten für die Website auf dem Datenbankserver ITG_STS_1 in der Datenbank STS_01 enthalten sind. Nachdem diese Informationen von der Konfigurationsdatenbank abgerufen wurden, wird die Datenbank-ID (in Abbildung 6 ist dies "101") auf dem Webserver im Sitzungscookie zwischengespeichert und für das Herstellen einer Verbindung zur richtigen Datenbank in nachfolgenden Anforderungen verwendet. Windows SharePoint Services verwenden ein "optimistisches" Schema für das Zwischenspeichern. Das bedeutet, sie gehen davon aus, dass eine Website seit dem letzten Abrufen durch den Benutzer nicht verschoben wurde. Wenn die zwischengespeicherte URL falsch ist und die Site nicht gefunden werden kann, überprüfen Windows SharePoint Services in der Konfigurationsdatenbank, ob die Website verschoben wurde. Das System wird daraufhin durch einen Korrekturalgorithmus angepasst.

Hinweis für SharePoint Portal Server 2003 Wenn SQL Server installiert ist, fügt SharePoint Portal Server systemeigene Tabellen zur Konfigurationsdatenbank hinzu und verwendet diese Datenbank zum Verfolgen der Aktivitäten auf den Servern in der Farm. Dazu gehören Informationen darüber, wer eine Suche durchführt, die Indizierung und einmalige Anmeldungen. SharePoint Portal Server fügt außerdem Zuordnungen für verschiedene Zugriffsmethoden und das Extranet hinzu, um eine Aggregation über mehrere Speicher durchzuführen.

Schema der Inhaltsdatenbank
Windows SharePoint Services speichern alle Benutzerdaten in der SQL Server-Datenbank. Dieser Ansatz bietet die folgenden Vorteile:

• Speicherung von Listendaten, Dokumenten und Metadaten in normalisierten Tabellen.

• Transaktionsaktualisierung von Dokumenten und Dokumentmetadaten.

• Konsistente Sicherungen von Dokumenten und Dokumentmetadaten.

• Eine programmierbare Speicherschicht

• Deadlockerkennung und -lösung.

Während in der früheren Version SharePoint Team Services eine Datenbank pro Website und eine Tabelle pro Liste implementiert wurde, verwenden Windows SharePoint Services ein festes Datenbankschema und eine feststehende Anzahl von Datenbanken pro Server, um die Skalierbarkeit zu erhöhen. In einer kleinen Datenbanktabelle werden alle Listendaten gespeichert, die Zuordnung von Listenschemas zu physischen Tabellen erfolgt dabei logisch. Außerdem reduzieren gespeicherte Prozeduren die Anzahl der Durchläufe in SQL Server und verknüpfen die Logik für Ein- und Ausgabe enger mit der Datenspeicherung.

Abbildung 7. Kernschema der Inhaltsdatenbank

Die Tabelle Sites enthält die Einstellungen für die einzelnen Websitesammlungen in der Datenbank. Dies sind die Standardeinstellungen für alle Unterwebsites, die in den einzelnen Websitesammlungen erstellt werden. Die Tabelle stellt alle Websites auf oberster Ebene aller Websitesammlungen sowie die Stammwebsite und die eigene Site im Kontext einer Portalwebsite dar. Die Tabelle Webs enthält die Einstellungen für die einzelnen Websites in einer Websitesammlung.

In der Tabelle Docs werden die gesamten Dokumente aller Websites in Websitesammlungen dieser Datenbank gespeichert. Dazu gehören z. B. Dokumente in den Dokumentbibliotheken, Anlagen und Knoten für alle Listen, jedoch auch die Datei default.aspx und Benutzerseiten für jede Liste, sofern diese angepasst wurde. Die Spalte Content der Tabelle Docs enthält den Wert NULL, wenn die Seiten nicht angepasst wurden. Nach dem Erstellen einer Website enthält die Spalte Content den Wert NULL für alle Websiteseiten in der Tabelle, da diese bisher nicht angepasst wurden. Ihre Seitendefinitionen werden von Schemadateien abgerufen, die sich auf dem Front-End-Webserver befinden.

Die Tabelle Lists (die Liste der Listen) enthält eine Zeile für jede Liste aller Websites in der Datenbank. Diese Tabelle enthält Einstellungen für jede Liste, die angeben, welche Listen oder Dokumentbibliotheken in den Websites enthalten sind und welches Schema von den einzelnen Listen instanziiert wird. Die Tabelle UserData enthält alle Listendaten für die von Benutzern auf der Website erstellten Elemente, dabei enthält jede Zeile die Daten für jedes Element.

Die Tabelle Links enthält Verknüpfungen, die bei der Neuberechnung von Verknüpfungen verwendet werden. Dadurch wird die Verwaltung von Verknüpfungen erheblich vereinfacht, da in früheren Versionen für jedes Dokument Schattendateien im Dateisystem erstellt werden mussten, die alle Verknüpfungen vom und zum Dokument enthielten.

Die Tabelle WebParts enthält Informationen über alle Webparts und Listenansichten auf den Websites. Sie ersetzt die Tabelle Views aus früheren Versionen, wie auch Webparts CAML-Ansichten auf Benutzerseiten ersetzen. Die Spalte tp_View enthält den CAML-Code für angepasste Ansichten bzw. NULL, wenn die Ansichten nicht angepasst wurden. Die Informationen zur Anpassung von Webparts werden in der Tabelle Personalization verwaltet.

Hinweis für SharePoint Portal Server 2003 Die Inhaltsdatenbank von SharePoint Portal Server ist umfangreicher als die Windows SharePoint Services-Datenbank, da sie zusätzliche Tabellen und gespeicherte Prozeduren enthält. SharePoint Portal Server verwendet Fremdschlüsselbeziehungen in Tabellen. Dabei wird das Datenbankschema der Windows SharePoint Services nicht geändert, jedoch zwei Datenbanken hinzugefügt. In der Profildatenbank werden persönliche Profile und Definitionen für Besucher gespeichert, mit denen Webparts und Inhalte gesteuert werden können. Die Dienste-Datenbank unterstützt Suchvorgänge und die Indizierung sowie Abonnements und Abonnementergebnisse.

 Zum Seitenanfang

Schlussfolgerung

Die Windows SharePoint Services-Architektur bietet Änderungen, die die Skalierbarkeit und Leistung im Vergleich zur Vorversion SharePoint Team Services verbessern. Windows SharePoint Services werden durch die Integration von .NET Framework zu einer noch umfangreicheren Plattform für die Webentwicklung erweitert. Außerdem bieten umfassende Änderungen am Datenbankschema bessere Möglichkeiten, die Funktionen von SQL Server zu nutzen. Als Ergebnis der Änderungen an der Datenbank von Windows SharePoint Services spielt IIS im Vergleich zu SharePoint Team Services eine geringere Rolle als die SharePoint-Architektur. Das Verständnis dieser Architektur kann Ihnen beim Entwickeln benutzerdefinierter Anwendungen mit der Windows SharePoint Services-Plattform helfen.

 Zum Seitenanfang