Portales Java y Portlets
jsr286 (1)
La única ventaja que conozco de antemano 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 usamos aquí que funcionan de esta manera, y algunas organizaciones encuentran valor en el enfoque del portal.
Sin embargo, como señala correctamente, esto impone algunas limitaciones frustrantes al autor de la aplicación. También hemos encontrado que el valor de los portales es algo dudoso cuando se coloca junto a un sistema de inicio de sesión único que ahorra al usuario la molestia de iniciar sesión en múltiples aplicaciones, pero que aún permite a cada aplicación los beneficios completos del entorno del navegador.
FWIW, si decide distribuir su trabajo como una colección de portlets, existen sistemas de portal que son de código libre / abierto que podría proporcionar a las personas que aún no tienen un contenedor de portlets:
http://java-source.net/open-source/portals
Espero que todo eso ayude un poco.
El mundo de Java tiene un estándar JSR-286 sobre cómo los portales y los portlets deberían interactuar: componentes de software que comparten una página web unificada.
Parece que hay una serie de implementaciones de portal. ¿Pero hay un "mercado" en vivo de portlets intercambiables que se ejecutarán en ellos? Por lo que puedo encontrar buscando en la web, parece muy desequilibrado: todos los portales y no los portlets. Es como si hubiera docenas de teléfonos con 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 montón de portlets que quiera agregar al portal?
Me sorprende que la mayoría de las empresas ya tengan una página similar a un portal basada en su elección de ERP o producto CRM en el que se ejecuta su negocio, o tal vez incluso solo en la página "Hoy" de MS Outlook. Entonces, si envío un nuevo producto destinado a 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 existente 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 manera de hospedar portlets de host? (Estoy adivinando: también no es genial).
Finalmente, JSR-286 parece bastante mudo sobre HTML + JavaScript, es decir, cómo los portales y los portlets interactúan dentro del navegador. Se trata de cosas del lado del servidor basadas en Java, que definen una manera de cooperar en el uso de las direcciones 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.
Esta publicación del blog (y los comentarios que aparecen debajo de ella) han proporcionado mucha información para reflexionar y parecen confirmar mis sospechas:
La experiencia práctica profesional junto con la investigación anterior me llevó a la conclusión de que la arquitectura del portal carece de suficientes ventajas técnicas y características distintivas para garantizar un aumento en la aceptación. En la práctica, pocas aplicaciones pueden limitarse a la funcionalidad aislada y dispar de los portlets, y renunciar a este grado de control arquitectónico no es realista en el software de nivel empresarial ... la ventana de oportunidades de la arquitectura del portal para convertirse en una tecnología general no solo se ha cerrado, Pero cerrado hace bastante tiempo.
Entonces, para resumir esto como una pregunta más coherente: ¿qué valor real obtendría al basarme en JSR-286 en este momento?