SharePoint 2010 Services à la Carte

Die neue Service Architektur, die das das in MOSS 2007 verwendete Shared-Service-Provider-Modell (SSP) ablösen soll, gehört zu den grundlegendsten Neuerungen in SharePoint 2010. Es handelt es sich um ein in punkto Architektur komplett neu konzipiertes Service-Modell, über das Web-Anwendungen innerhalb einer SharePoint-Farm und teilweise sogar farmübergreifend mit typischen Middle-tier-Diensten wie Search, Usage Tracking oder Single-Sign-On versorgt werden können. Das neue Konzept ist nicht nur für SharePoint-Architekten und -Administratoren von fundamentaler Bedeutung, sondern auch für Entwickler interessant, die SharePoint nun mit eigenen Service-Anwendungen erweitern können. Höhere Flexibilität und Skalierbarkeit Anders als beim Shared-Service-Provider-Konzept in SharePoint 2007, bei dem man eine Gruppe von Diensten noch als Ganzes einer SharePoint-Anwendung (Web Application) zuordnen musste, können Application Services den Web-Anwendungen nun einzeln zugewiesen werden. Das neue modulare Konzept bringt damit gleich eine ganze Reihe von Vorteilen mit sich. So lassen sich für eine einzelne SharePoint Web Anwendung (Web Applications) nur diejenigen Dienste aktivieren, die auch tatsächlich benötigt werden. Die Performance eines Servers oder Server Farm lässt sich dadurch optimieren. Ausserdem kann die Last auf unterschiedliche Anwendungsserver verteilt werden, was letztlich zu höherer Skalierbarkeit führt. Dank der neuen Architektur lassen sich Dienste und deren Daten auch besser isolieren. Service-Anwendungen – die übrigens innerhalb derselben Farm auch mehrfach instanziert werden können – lassen sich dabei in komplett voneinander abgeschotteten Applikationspools und mit eigenen Datenbanken betreiben. Diese strikte Trennung von Services ermöglichen insbesondere einen besseren Betrieb in Multi-Tenant-Szenarios, wo mehrere Kunden auf derselben Farm gehostet werden. Das neue Servicemodell wird denn auch im 2010er Release von SharePoint Online, das Mitte dieses Jahres im Rahmen von Office 365 verfügbar wird, eine zentrale Rolle spielen. Ein weiterer Vorteil ist, dass ein Teil der Services auch Farm-übergreifend zur Verfügung gestellt werden können. Das ermöglicht es Unternehmen Dienste zu zentralisieren. Ein typischer Kandidat hierfür wäre beispielsweise der User Profile Service, der für die Bereitstellung der Benutzerprofile zuständig ist. Diese könnten dann unternehmensweit von Web-Anwendungen in unterschiedlichen Serverfarmen konsumiert werden. Zahlreiche Out-of-the-Box-Dienste Natürlich nutzt Microsoft das neue Service-Konzept in SharePoint 2010 auch selber sehr intensiv. Neu ist, dass die Service-Architektur bereits in der SharePoint Foundation, der "kleinsten" SharePoint-Variante, zur Verfügung steht. Das SSP-Modell gab es in SharePoint 2007 erst ab MOSS 2007. Dabei wurden die aus dem SSP-Modell bekannten Dienste wie Suche, die Business Connectivity Services (für die Anbindung von externen Daten), die Excel Services  oder User Profile auf das Servicemodell umgestellt. Es sind aber auch einige neue Dienste wie etwa die Managed Metadata Services (zentrale Verwaltung von Metadaten und Taxonomien), Web Analytics, die Office Web Applications oder die Visio Services hinzugekommen. Eine Tabelle zu den verschiedenen SharePoint 2010 Services und in welcher SharePoint Edition sie zu finden sind, gibt es unter [1]). Eigene Services entwickeln Für SharePoint-Entwickler interessant ist, dass die neue Service Architektur nicht nur Microsoft vorbehalten sind, sondern mit Hilfe des Service Application Frameworks auch eigene Service-Anwendungen entwickelt werden können. Diese lassen sich in die Service Infrastruktur einklinken und stehen dann mit den oben genannten Features und Vorteilen zur Verfügung. Die Entwicklung eigener Service Applikation ist allerdings keine triviale Angelegenheit. Es müssen eine ganze Reihe an Komponenten implementiert werden, um die Vorgaben des Frameworks in Bezug auf Funktionalität und Architektur zu erfüllen (siehe Diagramm 1).  So werden verschiedene Back-End- (Application Server) und Front-End-Komponenten (Web Front-End Server) benötigt. Ausserdem muss Code für das Deployment, das Einrichten einer allfällig benötigten Service-Datenbank, das Administrationsinterface und die entsprechenden Service Consumers (Web Parts, SharePoint-Seiten, PowerShell CmdLets, weitere Services etc.), welche die Service-Anwendung schliesslich nutzen, erstellt werden. Die Links unter [2], [3] liefern detaillierte Anleitungen dazu, wie Service Anwendungen umgesetzt werden müssen. Eine weitere Hilfe bietet das Visual Studio 2010 Add-on CKSDev 1.2 [4], das eine Item-Vorlage für einfache Service-Applications enthält. Wann ist eine Service Anwendung sinnvoll? Natürlich ist die Service-Application-Architektur nicht für jede Art von Anwendung geeignet. Bevor man sich für die Umsetzung eigener Service-Applikationen entscheidet, sollte man auf jeden Fall sorgfältig prüfen, ob die Anforderungen auch tatsächlich die Vorteile des Service Frameworks (Modularität, Skalierbarkeit etc.) nötig machen und der damit verbundene Entwicklungsaufwand gerechtfertigt ist. Sinn machen können Service Anwendungen etwa dann, wenn Funktionen und Daten über mehrere Site Collections, Web-Anwendungen oder Farmen hinweg zur Verfügung gestellt werden sollen. Weitere mögliche Anwendungsfälle wäre etwa das Aggregieren von Daten (wie etwa bei Search), das Durchführen von spezialisierten Berechnungen oder das Auslagern von rechenintensiven Prozessen. Urs Bertschy ist Inhaber der auf Web- und SharePoint-Consulting/-Development spezialisierten Bertschy Informatik AG. Unter http://www.bertschy.ch/blog unterhält er einen Technologieblog, der sich vor allem SharePoint- aber auch anderen IT-Themen widmet. Links [1] http://technet.microsoft.com/en-us/library/cc560988.aspx [2] http://msdn.microsoft.com/en-us/library/gg543112.aspx [3] http://msdn.microsoft.com/en-us/library/ee536537.aspx [4] http://www.bertschy.ch/2011/02/cksdev-1-2-bringt-weitere-hilfen-fur-sharepoint-2010-entwickler Peter Monadjemi