SharePoint 2013: Apps, Apps überall!

… und jetzt auch für SharePoint 2013. Ich wurde unlängst von einem Kunden gefragt, warum es nun SharePoint Apps gibt, wo es doch ohnehin schon die server- und clientseitigen Möglichkeiten gibt, SharePoint „anzuprogrammieren“.

Also die Antwort darauf aus Microsoft Sicht ist durch aus nachvollziehbar und auch sinnvoll. Viele Entwickler und Systemadministration werden dem beipflichten, denn die technischen Gründe dafür sind absolut vertretbar. Bevor ich aber die Frage beantworte, blicken wir doch mal kurz in die Vergangenheit.

Mit SharePoint 2010 war es möglich Managed Code für SharePoint Farmen in Form von Full-trust Lösungen oder sogenannte Sandboxed-Solutions, die in einer eingeschränkten Umgebung laufen sollen, zu programmieren. Sandboxed-Solutions waren gedacht als die Lösung für Office 365, d.h. die Lösung die uns Entwicklern es ermöglicht SharePoint Lösungen für Office 365 zu programmieren.

Wer das jemals versucht hat, weiß, dass das eher eine sub-optimale Möglichkeit ist und war. Denn Sandboxed Solutions unterliegen gewaltigen Einschränkungen. Näher möchte ich darauf nicht eingehen. Aus Entwicklersicht kann ich aber behaupten, dass ich sehr glücklich bin, dass es dazu eine Alternative gibt.

Ja genau, Apps für SharePoint sind eine Alternative, nein eigentlich sogar die einzige Möglichkeit tatsächlich uneingeschränkt SharePoint 2013 Lösungen für Office 365 zu programmieren. Natürlich nicht nur für Office 365 sondern auch on-premise.

Und warum ist das so?

Es handelt sich dabei um einen kompletten Architekturwechsel im Vergleich zu den bestehenden Möglichkeiten SharePoint zu programmieren. Apps müssen Office 365 und on-premise Farmen gleichermaßen unterstützen. Damit dies möglich ist, darf kein server-seitiger Code in einer SharePoint Umgebung laufen, d.h. es werden keine Assemblies mehr in der Farm verteilt. Das funktioniert aber nur, wenn es möglich ist SharePoint komplett über WebService anzuprogrammieren. Dies ist nun möglich, weil SharePoint 2013 mit OData und REST Services Standards anbietet.

Zudem darf man bei so einem Architekturwechsel nicht die Sicherheit vergessen. Apps haben, ähnlich wie Benutzer eine eigene Identität. Dadurch ist es möglich Apps unabhängig von Benutzern zu berechtigen. Auch hier setzt Microsoft jetzt auf Standards wie OAuth.

Das Verteilen von Apps erfolgt für Office 365 über den sogenannten Office Store. Dadurch bekommen Unternehmen bzw. Entwickler die Möglichkeit neue Geschäftsmodelle bzw. Vertriebswege zu nutzen, um ihre Lösungen an Unternehmen zu bringen. Für on-premise Farmen besteht die Möglichkeit, einen eigenen App Catalog zu pflegen, wo Administratoren Apps zur Verfügung stellen, die dann von berechtigten Benutzern in den Websites oder Website-Sammlungen hinzugefügt werden können.

Aufgrund der Tatsache, dass bei der App Entwicklung kein server-seitiger Code mehr programmiert werden kann, was den .NET Entwicklern wohl nicht so gefällt, ist es eben nicht mehr möglich, dass server-seitiger Code im w3wp-Prozess läuft und somit eventuell für Probleme sorgt.

Dies ist wohl ein Hauptgrund für die Existenz der SharePoint Apps, denn individueller Code, der in einer SharePoint Farm on-premise läuft, sind immer wieder Risiken für Performance, Stabilität, Skalierbarkeit und Upgrades auf neue SharePoint Versionen.

Wenn man es genau betrachtet sind Custom Solutions auch ein Problem für Microsoft, denn Full-trust Code hat sehr oft Upgrades auf neue Versionen von SharePoint verhindert oder zumindest hinausgezögert. Kunden lassen sich Zeit damit, zuerst die bestehenden Full-trust Lösungen portiert werden. Dadurch werden weniger Lizenzen von neuen SharePoint Versionen verkauft, weil Kunden nicht Upgraden dürfen oder können. Aufgrund der zusätzlichen Einschränkungen mit Sandboxed Solutions konnte auch die Cloud-Strategie von Microsoft nicht so recht anlaufen.

Mit Apps für SharePoint wird versucht all diese Probleme zu lösen.

Dadurch ist es jetzt zusätzlich möglich, die Funktionalitäten und Logik nicht nur in SharePoint sondern auch in Fremdsystemen, die nichts mit .NET zu tun haben, auszulagern. Das bedeutet, es wird niemand daran gehindert, die Lösungen in beispielsweise PHP oder JAVA zu implementieren. Sofern die Standards wie OAuth und ODATA berücksichtigt werden, können diese Lösungen per App Architektur in den SharePoint geholt werden.

Was bedeutet der Architekturwechsel für uns .NET und SharePoint Entwickler?

Um es einfach auszudrücken, es wird Zeit, dass wir uns mit JavaScript, HTML5 und CSS3 anfangen zu beschäftigen, außerdem mit ODATA und OAuth. Zudem wird das clientseitige Objektmodell von SharePoint mehr und mehr zu der API der Wahl. Damit aber jetzt nicht Panik aufkommt, es ist weiterhin möglich das serverseitige Objektmodell wie bisher zu nutzen, da SharePoint 2013 dies wie gewohnt unterstützt. Man sollte sich aber bei neuen Lösungen überlegen, ob man nicht bereits das App Model verwenden kann.

Ausblick

Im nächsten Blogbeitrag zum Thema Apps für SharePoint werde ich darauf eingehen, welche Hosting Möglichkeiten von Apps existieren, außerdem werde ich ein paar Beispiel zeigen, wie Apps entwickelt werden können.  Ich werde NAPA zeigen, die App mit der man kleine Apps entwickeln kann. Es folgt somit eine Serie von Blogbeiträgen, die sich ausschließlich mit Apps für SharePoint beschäftig.

Dem interessierten und ungeduldigen Leser empfehle ich für’s Erste folgenden Link :

http://msdn.microsoft.com/en-US/office/dn448478