One world Einführung

Stellt man SharePoint 2007 und SharePoint 2010 einander gegenüber, dann wird man viele Dinge finden, die sich nicht grundlegend verändert haben. Allerdings gibt es einen sehr interessanten, grundlegenden Wandel der klar zu Tage tritt: SharePoint 2010 ist viel serviceorientierter geworden. Viele SharePoint Features sind neu als Services implementiert. Mit dabei sind zentrale Funktionen wie die Profilverwaltung oder die Suche. Dies ist aber noch nicht alles! SharePoint 2010 bietet auch ein sehr flexibles Framework um unsere Custom Services in eine SharePoint Farm nahtlos zu integrieren. Dabei muss es sich bei einem Service nicht zwingend um einen ‚echten’ Webservice oder WCF Service handeln. Vielmehr kann SharePoint 2010 auch zentrale Funktionen, die auf allen Frontend Servern verfügbar sein sollen als Service behandeln. Durch das Service Application Framework (SAF) können wir diese entsprechend einbinden.

In diesem Artikel wollen wir nicht die Möglichkeiten und Features diskutieren, die das SAF zur Verfügung stellt. Vielmehr wollen wir eine ‚top down’ Übersicht darüber geben, wie das SAF und SharePoint 2010 unser Denken über die Integration von SharePoint Applikationen in einer Enterprise Umgebung verändern können.

Um dabei nicht zu theoretisch zu werden, wollen wir an einem Beispiel aufzeigen, wie Daten von einem Hybris Server (Produktinformationssystem) durch einen Service gelesen- und in SharePoint WebPart angezeigt werden können. Dabei soll das WebPart nicht direkt die Hybris Rest Services aufrufen, sondern wir wollen einen generischeren Hybris Connector als SharePoint Application Service anbieten. In unserem Beispiel soll dieser Service ein ‚echter’ wcf-Service sein, der im IIS gehosted wird. Dabei erfolgt das Deployment des Service über eine SharePoint Solution und die Konfiguration wird in der SharePoint Central Administration vorgenommen. Weiter bindet SharePoint unseren custom Service in die Farmtopologie ein und kann den Zugriff auf den Service sowie Loadbalancing und Disasterrecovery für unseren Service mit anbieten.

Das Beispiel

2941-BeispielHConnector.jpg
  1. Ein Hybris Server wird als Datensenke benützt. Er stellt Rest-Services für den externen Zugriff bereit. Au der Hybris Seite sind keinerlei Änderungen nötig.
  2. Der Hybris Connector Service kann auf einem oder mehreren Servern in der Farm betrieben werden. Er wird über SharePoint Deployment Mechanismen verteilt und in der Central Administration konfiguriert. Der Service ruft die Rest Services von Hybris auf und erhält Daten im xml Format. Der Service parsed diesen xml-Stream und befüllt einfache .Net Datenobjekte, die über wcf an den Client zurückgegeben werden.
  3. Der Client kann über eine ServiceApplicationProxy Instanz auf den Service zugreifen. Dieser wird als Teil des Connector Service implementiert und von der SharePoint Farm zur Verfügung gestellt wird.

Schlussfolgerung

Was sind die Vorteile des hier vorgestellten Ansatzes? Warum wollen wir die Hybris Rest Services nicht direkt im Code behind des WebParts aufrufen? Die Antwort ist: Bessere Wiederverwendbarkeit, bessere Skalierbarkeit und bessere Isolation des Service Codes.
Wir wollen uns vorstellen, dass der Kunde sehr glücklich war, über das WebPart, das im Intranet direkt Produktdaten aus Hybris anzeigen kann. Weiter hat er sich dazu entschlossen, auch sein Internet neu zu lancieren. Unter anderem möchte er dabei einen Produkt-Teaser haben, der die Produktinformationen aus Hybris anzieht. Gut gemacht! Wir können ihm für dieses Feature einen sehr interessanten Preis offerieren, weil unser Hybris-Connector Service wiederverwendet werden kann. Nach dem Relaunch des Internet stellt sich nun heraus, dass die neue Website des Kunden zur beliebtesten Website des Jahres avanciert. Um die zunehmende Last abzufangen stellt der Kunde einige zusätzliche Frontend Server in seine Farm. Wie wird dabei unser Service skalieren? Der SharePoint Administrator erstellt auf den neuen Servern einfach zusätzliche Service Instanzen und SharePoint übernimmt automatisch das load balancing für den Service.
Natürlich ist die Implementierung des Hybris-Connector Codes in einem Application Service etwas aufwendiger als wenn man Hybris direkt vom WebPart aus aufrufen würde. Allerdings können wir leicht einsehen, dass der Zusatzaufwand sich in vielen Fällen leicht rechtfertigen lässt.
Zu guter Letzt wollen wir noch auf einen weiteren Aspekt der Service orientated Architecture (SOA) eingehen: In einem Unternehmen wird man niemals gewillt oder dazu in der Lage sein, den gesamten custom code als einen monolithischen Block in einem Aufwasch neu zu implementieren. Die Risiken und die Kosten sowie die internen Vorbehalte gegenüber einem solchen Unterfangen wären einfach zu gross. Gelingt es aber, einzelnen Anforderungen durch Services nach und nach abzudecken, dann können wir die notwendigen Modernisierungen und Veränderungen viel besser portionieren und schrittweise umsetzen.

Ausblick

Dieser Artikel soll der erste der Serie ‚One world’ sein. Wir wollen an dieser Stelle mehre blog posts anbieten, die sich alle mit den Themen Services, Service Architektur und dem SAF befassen. Ein spannendes Gebiet, das zudem einen grossen Einfluss darauf haben kann, wie wir für SharePoint 2010 zukünftig Applikationen entwickeln können.