Neu bei SharePoint 2010: das Client Object Model

Bereits bei früheren SharePoint-Versionen gab es ein umfangreiches Objektmodell, das zum Beispiel den Zugriff auf eiine Site oder einzelne Listen ermöglichte. Es handelte sich aber um ein rein serverbasiertes Modell. Client-Anwendungen mussten ein wenig umständlich über eine Webservice-API auf die Funktionalität des SharePoint-Servers und seine Daten zugreifen. Da Web-Anwendungen zunehmend mit clientseitigen Technologien wie Ajax oder Silverlight "aufgebohrt" werden, die dem Benutzer das Gefühl einer Rich-Client-Anwendung vermitteln sollen, führte Microsoft in SharePoint 2010 das Client Object Model (Client OM) ein. Wie es die Bezeichnung vermuten lässt, handelt es sich um ein Objektmodell, das ein lokaler Client benutzen kann, um via JavaScript oder .NET-Managed Code in einer Silverlight-App auf SharePoint-Funktionen und -Daten zugreifen können. Bemerkenswert ist, dass Microsoft das Client OM innerhalb der SharePoint-2010-Benutzeroberfläche selber intensiv nutzt. Bei der Benutzerführung wird dies an vielen Stellen durch eine deutlich reduzierte Anzahl an Page Refreshes angenehm spürbar.

Das Client-OM in drei Ausprägungen

Das Client Object Model gibt es in drei unterschiedlichen Ausprägungen für .NET (zum Beispiel WPF, WinForms oder Office-Add-Ins), für Silverlight und für JavaScript (verwendbar auf SharePoint-Seiten, im Dialog Framework und in Web Parts). Alle drei Varianten arbeiten nach demselben Muster und unterscheiden sich nur marginal. Die Microsoft-Entwickler haben darauf geachtet, dass die Konzepte und Namespaces des Client OM so weit als möglich demjenigen des vielen Entwicklern bereits vertrauten serverseitigen Objektmodells entsprechen. Erfahrene SharePoint-Entwickler werden sich daher im Client OM schnell heimisch fühlen. Trotz dieser Ähnlichkeiten gibt es aber auch wesentliche Unterschiede. So ist der Funktionsumfang im Vergleich zum serverseitigen Objektmodell deutlich abgespeckt. Immerhin stellt das Client OM Klassen zum Durchführen der wichtigsten Aufgaben innerhalb einer Site Collection bereit. Dazu gehört etwa der Lese- und Schreibzugriff auf Objekteigenschaften und List-Items, das Erstellen von Sites und Listen oder das Manipulieren von WebParts und Menü-Items. Nicht unterstützt werden Funktionen, die außerhalb des Scopes einer Site Collection liegen. Auch auf die vielen Administrations-Funktionen des Server-Objektmodells hat man via Client-API keinen Zugriff.

Abb. 1 illustriert wie das Client OM im Hintergrund funktioniert. Für die Kommunikation mit SharePoint-Server steht ein WCF-Service (unter /_vti_bin/client.svc) bereit. Die über das ClientContext-Objekt gebündelten Abfragen werden zunächst intern in CAML umgewandelt und als XML-String an den Service übermittelt. Die angeforderten Daten werden als JSON-Paket zurückgeliefert, auf dem Client ausgewertet und an Objekte der Anwendung übergeben.

Abb. 1: Ein WCF-Service wickelt die Kommunikation zwischen Client und Server ab. Die Resultate im JSON-Format werden vom Client OM selbständig ausgewertet