Portales y portlets de Java

Question

El mundo de Java tiene un JSR-286 standard sobre cómo deben funcionar los portales y portlets: componentes de software que comparten una página web unificada.

Parece haber una cantidad de implementaciones de portal. ¿Pero hay un "mercado" en vivo de portlets intercambiables que correrán en ellos? Según lo que puedo encontrar buscando en la web, parece muy desequilibrado: todos los portales y ningún portlet. Es como si hubiera docenas de teléfonos Android y ninguna aplicación.

Si un producto se basara en JSR-286 (o alguna implementación del mismo), ¿cuál es la probabilidad de que un cliente corporativo tenga un grupo de portlets que podría querer agregar al portal?

Me parece que la mayoría de las empresas ya tienen una página tipo portal basada en su elección de ERP o producto CRM en el que se ejecutan sus negocios, o tal vez solo en la página "Hoy" de MS Outlook. Entonces, si envío un nuevo producto para clientes corporativos, y lo convierto en un portal (en lugar de un conjunto de portlets), ¿cuál es la probabilidad de que mis clientes abandonen su portal IBM/SAP/Oracle y utilicen mi portal como su nueva página de inicio? ? (Supongo que no es genial). ¿Y si lo hago un conjunto de portlets compatibles con JSR-286, mis clientes van a tener una forma de alojar portlets de host? (Supongo que tampoco es genial).

Por último, JSR-286 parece bastante mudo sobre HTML + JavaScript, es decir, cómo los portales y portlets interactuarían dentro del navegador. Todo se trata de cosas del lado del servidor basadas en Java, que definen una forma de cooperar en el uso de las URL para que cada actualización de página completa se pueda enrutar al portlet correcto. No parece reconocer el enfoque moderno y rico de AJAX. Menciona AJAX solo de pasada.

This blog post (and the comments under it) han proporcionado una gran cantidad de elementos de reflexión y parecen confirmar mis sospechas:

manos a la experiencia profesional a lo largo de con la investigación anterior me llevaron a la conclusión de que la arquitectura portal de carece de suficiente ventajas técnicas y características distintivas para garantizar un aumento en la aceptación. En la práctica, algunas aplicaciones pueden limitar a sí mismos a la aislada y funcionalidad dispar de portlets, y renunciando a este grado de control arquitectónico es poco realista en el software de nivel empresarial ... ventana de la arquitectura del portal de oportunidades para convertirse en una tecnología convencional no solo ha cerrado , pero cerró hace bastante tiempo .

Por lo tanto, para resumir esto como una pregunta más coherente: ¿qué valor real obtendría al construir en JSR-286 en este momento?

Answer 1

La única ventaja que conozco de improviso es que cuando los proveedores de software empresarial tienen "integración de portal" en su lista de verificación de características, generalmente significa que han escrito portlets de acuerdo con los estándares JSR-168 o JSR-286. SAP, Banner y Magnolia son algunos de los sistemas que utilizamos aquí que funcionan de esta manera, y algunas organizaciones encuentran valor en el enfoque del portal.

Sin embargo, como usted señala correctamente, esto impone algunas limitaciones frustrantes en el autor de la aplicación.También descubrimos que el valor de los portales es algo dudoso cuando se coloca junto a un sistema de inicio de sesión único que le ahorra al usuario la molestia de iniciar sesión en varias aplicaciones, pero que aún permite que cada aplicación obtenga todos los beneficios del entorno del navegador.

Fwiw, si decide distribuir su trabajo como una colección de módulos de función, hay sistemas de portales existentes que son de código libre/abierto que podría proporcionar para la gente que no tuviera ya un contenedor de portlets:

http://java-source.net/open-source/portals

Espero que todo eso ayude un poco.