Architektur des externen BLOB-Speichers

Letzte Änderung: Donnerstag, 8. Oktober 2009

Gilt für: SharePoint Foundation 2010

Vor der Einführung des Speicheranbieters für externe Binary Large Objects (BLOB) (EBS-Anbieter), wurde der mit einer SharePoint-Datei verbundene Binärdatenstrom durch die Semantik des BLOB-Speichers an die Microsoft SQL Server-Inhaltsdatenbank geleitet, die mit den strukturierten Daten der Website gemeinsam genutzt wurde. In diesem Szenario erkannte ein Parser auf dem Save-Pfad beim Aufruf eines Save-Befehls für die SharePoint-Datei den Save-Befehl und stufte ein Paket Metadaten aus dem Dateistrom herauf. Die Metadaten wurden dann zusammen mit dem zu der Datei gehörigen BLOB in der SQL Server-Inhaltsdatenbank gespeichert.

Nach dem Installieren, Konfigurieren und Aktivieren des EBS-Anbieters ändert sich die Semantik jedoch grundlegend (siehe Abbildung 1). Jetzt leitet statt der Webanwendung der Speicherzugriffsstapel auf der mittleren Schicht BLOB-Datenströme weiter, verwendet den EBS-Anbieter zum Speichern von BLOB-Daten im externen BLOB-Speicher und gibt dann Metadaten zurück, anhand derer er das BLOB bei Bedarf abrufen kann. Beachten Sie, dass das SharePoint Foundation-Objektmodell von der Semantik des EBS-Anbieters sowie von einem externen BLOB-Speicher vollständig isoliert ist. Durch diese Trennung wird sichergestellt, dass vorhandene Anwendungen und Dienste Speicherimplementierungen nicht "sehen" können. Nur der Speicherzugriffsstapel "sieht", dass ein externer BLOB-Speicher vorhanden ist, und erkennt dessen Semantik.

Abbildung 1. Architektur des externen BLOB-Speichers

Der EBS-Anbieter ist Ihre benutzerdefinierte Implementierung der Anbieterschnittstelle, des nicht verwalteten ISPExternalBinaryProvider, und ist als COM-Komponente in den Speicherzugriffsstapel integriert.

Die Anbieterschnittstelle stellt Ihnen zwei Methoden bereit: StoreBinary und RetrieveBinary. Der Speicherzugriffsstapel erkennt den Save- und den Open-Befehl und ruft, wenn die Befehle BLOB-Dateien zugeordnet werden, die StoreBinary- bzw. die RetrieveBinary-Methode auf.

Speichern der BLOB-Pipeline: Verwenden des "Save"-Befehls

BLOB-Daten können durch Reaktion auf den Save-Befehl im externen Datenspeicher gespeichert werden. Abbildung 2 zeigt eine funktionale Darstellung dessen, wie ein Save-Befehl von der Front-End-Webanwendung vom Speicherzugriffsstapel zum EBS-Anbieter geleitet und extern gespeichert wird. Zum Schluss wird ein Datensatz für den Speicherort als Metadaten in der Inhaltsdatenbank beibehalten.

Abbildung 2. BLOB-Speicherung mithilfe des Save-Befehls

Wenn in der Front-End-Webanwendung ein Save-Befehl aufgerufen wird, ermöglicht die Logik der mittleren Anwendungsschicht eine Validierung der Geschäftslogik. Diese umfasst Antivirusprüfungen, Eigenschaftenheraufstufung, Rechteverwaltung und andere der Verarbeitung vorgeschaltete Aufgaben. Anschließend erkennt der Speicherzugriffsstapel, dass der Save-Befehl für eine BLOB-Datei gilt. Die Anbieterschnittstelle übergibt die Anforderung an den EBS-Anbieter, und dieser speichert den Binärstrom im externen BLOB-Speicher.

Der EBS-Anbieter gibt die BLOB-ID (BlobId) an die Schnittstelle zurück, und die Schnittstelle übergibt die ID an den Speicherzugriffsstapel. Der Zugriffsstapel behält dann die ID und die BLOB-Metadaten in der Inhaltsdatenbank bei.

Der EBS-Anbieter gibt einen eindeutigen Bezeichner ([Out] ppbBinaryId) für die BLOB-Datei zurück, der im externen BLOB-Speicher platziert wird.

Abrufen der BLOB-Pipeline: Verwenden des "Open"-Befehls

Das Abrufen von BLOB-Daten aus dem externen BLOB-Speicher ist die Umkehrung des Save-Vorgangs. Erkennt der EBS-Anbieter einen Open-Befehl für eine Datei, der ein BLOB zugeordnet ist, ruft er Methoden in der Anbieterschnittstelle auf, um die Datei aus dem externen BLOB-Speicher abzurufen. Abbildung 3 ist eine funktionale Darstellung dessen, wie der Speicherzugriffsstapel mithilfe eines Open-Befehls aus der Front-End-Webanwendung die BLOB-ID aus der Inhaltsdatenbank abruft und dann mithilfe der ID den Binärstrom aus dem externen BLOB-Speicher abruft.

Abbildung 3. Abrufen des BLOB-Speichers mithilfe des Open-Befehls

Der Speicherzugriffsstapel ruft Metadaten und die BlobId durch Senden einer Transact-SQL-Abfrage an die Inhaltsdatenbank ab. Anschließend übergibt er den Rückgabewert (BlobId) an den EBS-Anbieter, damit er die richtige Binärdatei durch Verwenden der RetrieveBinary-Methode für die ISPExternalBinaryProvider-Schnittstelle aus dem externen BLOB-Speicher abrufen kann. Die Methode gibt eine ILockBytes-Schnittstelle an den Speicherzugriffsstapel zurück.

Wie bei der StoreBinary-Methode ist der EBS-Anbieter für die Protokollierung von Abrufereignissen verantwortlich. Unerwartete HRESULT-Rückgaben werden in Windows SharePoint Server protokolliert, abgesehen davon verhält sich die Anwendung so, als ob Rückgaben entweder S_OK oder E_FAIL sind.

Fehler im EBS-Anbieter werden vom Speicherzugriffsstapel bekannten Fehlercodes zugeordnet.

Siehe auch

Konzepte

Externer Speicher für BLOBs (Binary Large Objects) in SharePoint Foundation