Modelo de apps en detalle (I): Introducción

Hola a todos,

En un reciente proyecto me he visto involucrado en mucho detalle en el modelo de apps de SharePoint 2013 en entornos corporativos, con aplicaciones de alta confianza (high-trust) y autenticación federada con Claims. Mi idea en esta serie de artículos en el blog es compartir estos conocimientos ya que creo que existe poca información de primera mano sobre la utilización real del modelo de apps, fuera de las apps de demostración.

En este primer post voy a recordar la evolución del modelo de programación de SharePoint.

Antes de SharePoint 2010

Para un programador "veterano" en SharePoint, la programación en SharePoint siempre implica poner el código NET en el servidor de SharePoint. Desde que SharePoint abrazó el modelo de programación NET en la versión 2003, siempre ha sido así. El código de nuestras soluciones SharePoint se pone en la carpeta BIN de la aplicación web de SharePoint o bien en la GAC del servidor.

Los beneficios de este enfoque son el acceso a toda la potencia del modelo de objetos de SharePoint de servidor (Server Object Model) y de NET. Sin embargo, nos exponemos a que nuestro código ralentize el servidor (ya que se ejecuta en el mismo proceso que el código propio de SharePoint) y a que tengamos que preparar bien las actualizaciones de SharePoint. Solo hay que recordar las migraciones de una versión de SharePoint a otra y la caza y captura de código a medida para actualizarlo al nuevo modelo.

La raíz del problema es que SharePoint "puro" sin código a medida tiene un rendimiento muy bueno y que SharePoint con código a medida que no esté bien optimizado (y la verdad es que la mayoría del código a medida en SharePoint que circula por ahí no lo está) puede castigar el rendimiento de tal manera que no sea usable. En esencia: no hay nada que nos impida "frenar" a SharePoint con nuestro código lento. (como ejercicio podéis poner una webpart en SharePoint que haga un Thread.Sleep(5000) y SharePoint se volverá 5 segundos más lento).

SharePoint 2010: CSOM y Sandboxed

Para solventar de alguna manera este acoplamiento fuerte entre SharePoint y nuestro código, en SharePoint 2010 aparecen dos componentes arquitectónicos nuevos.

En primer lugar, tenemos un modelo de objetos de cliente (Client-side Object Model, CSOM) disponible en NET, Silverlight y JavaScript. De esta manera podemos crear código que se ejecute fuera de SharePoint. El modelo de objetos de cliente no es tan potente como el modelo de objetos de servidor, pero es usable en muchos escenarios comunes.

En segundo lugar, aparece el concepto de código sandboxed. Por primera vez, el código a medida se puede ejecutar en un proceso separado de SharePoint y por tanto sometido a restricciones de tiempo de CPU y memoria. De esta manera podemos mantener estable el entorno propio de SharePoint y protegerlo de cierta manera de nuestro código potencialmente acaparador de recursos.

Las aplicaciones sandboxed prometían lo mejor de los dos mundos: acceso al modelo de objetos de servidor y a la vez un control sobre el uso de recursos del código que lo utiliza.

SharePoint 2013: Cloud-based Apps (CBA)

¡Y llegó SharePoint 2013! De buenas a primeras, se cargó de un plumazo "deprecador" el modelo sandbox que tanto prometía. Para sustituirlo, optó por desterrar el código a medida fuera del servidor de SharePoint en el nuevo modelo de apps (cloud-based applications, CBA).

Por tanto, el modelo de desarrollo preferente en SharePoint 2013 es tener todo el código fuera de SharePoint (en apps) y puesto en otro proceso que potencialmente esté en otra máquina así como utilizar el modelo de objetos de cliente (ya introducido en SharePoint 2010) para interactuar con los datos en SharePoint. De esta manera se cumple el objetivo importante de no que el código a medida lento no haga lento a SharePoint, pero a costa de tener que utilizar una API de cliente incompleta y que no está a la par del modelo de objetos de servidor.

Para que el código a medida de las apps pueda llamar a SharePoint sin tener en cuenta el usuario concreto, se adaptó el estándar OAuth para crear las credenciales de las apps. En SharePoint 2013 una app tiene una identidad propia y permisos propios. En tiempo de ejecución, se combinan los permisos de la app y los permisos del usuario que utiliza la app para determinar los permisos efectivos.

Cuando apareció el modelo de las apps, había 3 "sabores" de las mismas: SharePoint-hosted, auto-hosted y provider-hosted. En junio de 2014 desapareció la opción auto-hosted. Las apps SharePoint-hosted sólo pueden contener código JavaScript así que para las aplicaciones corporativas son más bien inútiles. Esto nos deja con el modelo provider-hosted como el único realmente utilizado para hacer una app de cierta relevancia en SharePoint 2013.

Resumen

En este post hemos revisado la evolución de los modelos de desarrollo a medida de SharePoint, hasta el modelo de apps de SharePoint 2013. En el post siguiente abordaré el modelo de las apps en detalle para explicar las piezas que lo componen e ir introduciendo el concepto de low-trust y high-trust apps. ¡Hasta pronto!