Servicios web para portlets remotos en C # / .NET & # 8212; Opciones?

Question

Recientemente tuve mi mente expandida por un nuevo concepto: Servicios web para portlets remotos , o WSRP. Lo supe durante una presentación en un portal web basado en Java que estamos considerando comprar en el trabajo; somos una tienda .NET y WSRP sería el medio por el cual ampliaríamos este portal.

Aunque no puedo controlar la decisión final sobre si compramos o no el producto, puedo proporcionar información sobre lo difícil que sería crear portlets compatibles con WSRP. Desafortunadamente, mis consultas recientes sobre el tema han resultado casi nulas.

Entonces, les pregunto a ustedes, la comunidad SO, lo siguiente: ¿qué bibliotecas o marcos existen para construir portlets compatibles con WSRP en C # /. NET? ¿Cuáles son algunos de los pros y los contras de usar WSRP en general?

Debido a que no hay una respuesta correcta aquí, haré de esto una publicación wiki comunitaria.

Hasta ahora, solo he encontrado lo siguiente:

• WSRP Kit de herramientas para Sharepoint de Microsoft (pero que requiere Sharepoint).
• WSRP Portal y WSRP .NET Framework Por NetUnity.

Dado que WSRP está por encima de SOAP, este parece ser un candidato perfecto para un enlace y canal WCF, y sin embargo, no veo nada sobre el tema, en ningún lado.

Answer 1

Si lee detenidamente la especificación WSRP, encontrará que es una versión remota de la especificación de portlet Java (si lo deletreo bien). Eso significa que es útil para integrar portlets de Java. Cualquier otra cosa tendrá que parecerse a un portlet de Java, que no es muy genérico.

Answer 2

WSRP es muy contrario. En este momento, el mundo ha visto que el acoplamiento estrecho entre el modelo de datos y el modelo de presentación es subóptimo. El éxito de los servicios RSS, REST, MVC y web en general lo demuestra. A pesar de WS en el nombre, WSRP se opone a los principios básicos de los servicios web. La especificación WSRP ignora los buenos consejos para mantener separados los datos y la presentación, y los combina estrechamente.

WSRP promete integración, a nivel de UI. Este parece ser el problema incorrecto para resolver.

Me desconcierta que esta cosa haya vivido tanto tiempo.
El problema que intenta resolver a menudo no es el problema que debe ser resuelto.

Answer 3

Creo que su popularidad / adopción se puede inferir por el hecho de que la última versión de NetUnit fue "Esta última versión agrega soporte para Visual Studio 2005 y .NET 2.0".

Answer 4

Tendría que estar de acuerdo con Cheeso. La integración de la IU con los datos solo sirve a los consumidores de portlets y agrega una capa grande, innecesaria y arriesgada a los productores de portlets. Nuestra tienda .NET ha sido recientemente obligada a considerar WSRP y he encontrado una falta de soporte y experiencia. El mejor enfoque centrado en MS que he visto discutido es aquí . Pero no he encontrado ninguna implementación / soporte específico de WCF. Cualquier ventaja es muy apreciada!

Answer 5

WSRP es esencialmente un estándar de servicio web de portal a portlet. ¿Cuáles son los datos primarios intercambiados entre el portal y el portlet? Es marcado y en gran parte porque la mayoría de los portales usan una interfaz de usuario web. Toda esta idea de que no son datos puros versus IU es un punto discutible. Está destinado a ser un servicio web para el descubrimiento de portlets, metadatos, marcado, interacciones, almacenamiento en caché, comunicación de portlet a portlet, etc. Eso es lo que hace un portal, incluso si no es WSRP. Sin embargo, WSRP es un estándar abierto y multiplataforma.

¿Qué es un portal que solo integra portlets de sus propios productos y / o plataforma? ¿Tiene PeopleSoft HR basado en Java y le gustaría proporcionar acceso a sus portlets desde SharePoint a sus empleados? Buena suerte. ¿Por qué no puede ser este un escenario alcanzable para la mayoría del software empresarial? Y sí, me doy cuenta de que es una integración relacionada con la interfaz de usuario. Esa es una de las razones principales por las que estoy usando un portal. No es como si esperara que PeopleSoft se integre con SharePoint en el "puro" nivel de datos y, de alguna manera, un elemento web Beneficios para empleados aparece mágicamente en SharePoint listo para usar. Sin embargo, eso es lo que espero si la integración de portlet a portlet se basa en WSRP.

WSRP, aunque no es perfecto, es una solución superior en mi opinión. Además de la fácil integración del portlet dentro de un portal, separa el portal de la aplicación. No se implementan binarios en el servidor del portal ni se ejecutan en el mismo servidor. Esto tiene sentido. Nunca ejecute aplicaciones en el mismo servidor que el servidor del portal: tampoco se actualizará. Llegué a la conclusión de que es una locura poner los binarios de la aplicación en el mismo servidor que el servidor del portal. " Implemente esta aplicación en el servidor del portal y haga que afecte la seguridad, la estabilidad, el rendimiento y todo lo demás, y me gustaría crear tantas dependencias como sea posible y eliminar todo el servidor cada vez que actualice la aplicación " ;. Es una pesadilla de dependencia. Es mejor obtener un par de consultores de proveedores de portal para que se den de la mano al actualizar y tengan a alguien a quien culpar.

¿Necesita equilibrar la carga de una plataforma de portal completa cuando solo se alcanza un número selecto de portlets? A los proveedores del portal les gustaría que lo creyeras. Muchas veces, el portal no hace más que esperar a que los portlets terminen de procesarse. Con WSRP, tiene la flexibilidad de cargar portlets de equilibrio independientemente de la plataforma del portal. Siempre se descompone en unos pocos portlets que son los más afectados. ¿Por qué no cargar el equilibrio solo esos portlets? Entonces, en lugar de equilibrar innecesariamente la carga del portal en 80 CPU, podría cargar esos pocos portlets en 10 CPU. WSRP también es absolutamente perfecto para la computación en la nube.

WSRP es un estándar de portal a portlet. Si desea escribir un portlet que funcione en múltiples portales y potencialmente en diferentes plataformas, WSRP lo es. Si está contemplando remotamente la integración de portlets de terceros, WSRP lo es. Es el único estándar. Sin embargo, también tiene algunos beneficios significativos sobre otras interfaces locales de portal a portlet patentadas y también debe considerarse para esos beneficios.