¿Qué es el Service Application Proxy?

Esta pregunta me la hice hace un buen tiempo, y aunque la respuesta estándar era medianamente convincente, no conseguí estar 100% convencido. Mas que nada por que algunos clientes habían hecho Aplicaciones de Servicio personalizadas. Cuando me vi con este problema estaba convencido que algo debía de haber en internet que mostrara el cómo y encontré éstos artículos de Andrew Connell:

Chapter 11: Building Customer Service Applications for the Right Situations
(Real World SharePoint 2010)
https://msdn.microsoft.com/en-us/library/gg193964.aspx 

Creating Custom SharePoint 2010 Service Applications and Consumers
https://msdn.microsoft.com/en-us/library/gg543112.aspx

Ambos están basados en el mismo código fuente, aunque explicados desde ángulos distintos. El asunto es que más de uno se ha lanzado a la aventura y han tenido mas de un problema con ello. Pero a partir de aquí fue cuando empecé a investigar a fondo el Service Application Proxy.

Lo primero que debéis saber, es que las Aplicaciones de Servicio están basadas en WCF (Windows Communication Foundation), si queréis entender a fondo su funcionamiento, debéis primero conocer las bases de WCF. En lo que se refiere a nuestro tema, lo importante es que WCF es una plataforma que de alguna forma abstrae el protocolo de transporte de mensajes entre el consumidor y el servicio, y unos de los protocolos que abstrae son los propios servicios web de WCF. Así, puedes tener mas de una forma de comunicación entre el servicio y el artefacto que lo consume.

El Service Application Proxy, básicamente es un enlace entre el servicio y el consumidor. Pero en esta comunicación hay mas elementos que participan y para que se entienda mejor, echar un vistazo a este diagrama de secuencia:

 

Así, tenemos

• Consumidor: Es el cliente final de nuestro servicio. En nuestro caso es un web part.
• Cliente y Proxy: Son los artefactos que se encargan de abstraer la comunicación entre el consumidor y el servicio.
• Topology: Es un servicio nativo de SharePoint, se encarga de encontrar el punto de comunicación entre el servicio y el proxy, además se encarga de hacer las veces de balanceador, si el servicio estuviera levantado en más de un servidor.
• Servicio Web: En el caso concreto del ejemplo en cuestión, es la capa que publica las funciones del servicio.
• Instancia de Servicio: Es el servicio propiamente dicho, que tiene la inteligencia de negocio y que puede ser levantado en más de un servidor a la vez si queremos balancear. Puede ser un servicio de Windows, pero no necesariamente.

El proxy, en nuestro caso es quien se encarga de abstraer el protocolo de comunicación entre el consumidor y el servicio. En el caso del código de Connell, es a través de servicios web. Sólo basta con ver que clase es la que hereda el Proxy en cuestión:

 

El problema es que la palabra proxy, para un desarrollador, significa el artefacto que está en el cliente, que construye los mensajes para comunicarse con el servicio en el servidor. Las Aplicaciones de Servicio tienen una arquitectura distinta, que puede incluso usar dos proxies, uno para el servicio y otro para el cliente. Y en mi opinión esto último es lo que genera confusión cuando se habla del dichoso proxy.

Lo cierto es que para un perfil de sistemas, la palabra proxy no genera tanta confusión, pero si alguien quiere lanzarse a desarrollar una aplicación de servicio personalizada, seguro que cae en la categoría de desarrollador.

Para comprender a fondo como funciona toda esta arquitectura, os recomiendo encarecidamente que leáis este artículo:

https://msdn.microsoft.com/en-us/library/ee536537.aspx

Mi consejo final: Si estáis pensando en desarrollar una aplicación de servicio personalizada, aseguraros de comprender a fondo el artículo anterior. De lo contrario os veréis metidos en un berenjenal de proporciones astronómicas.