¿Cuál es la alternativa a una estrategia de portal empresarial en el espacio Java?

Desilusión con el espacio del portal

Veo una cantidad inquietante de grandes clientes empresariales que se han desilusionado con su experiencia empresarial en el Portal, especialmente aquellos en el espacio de WebSphere Portal Server (WPS). Se han invertido millones, sin embargo, la promesa de contenido personalizado con agregación y herramientas de colaboración integradas nunca se ha cumplido. El cambio a WPS 7.x es un gran movimiento de extracción y reemplazo, y los clientes se preguntan si deberían mudarse a otro lugar por completo.

Software de portal: una opción horrible, pero ¿cuál es la alternativa?

Hay muchos enemigos del Portal, y a veces una solución de portal es realmente exagerada, pero cuando se habla de grandes corporaciones multinacionales, ¿cómo recomendaría que diseñen una solución global sin un servidor de portal?

No siempre es tan divertido trabajar con los portales como Tomcat o JBoss AS, pero cuando se trata de integrar múltiples aplicaciones, administrar contenido, actualizar aplicaciones individuales que se implementan como archivos de guerra individuales, administrar la seguridad hasta el nivel de portlet, probar cierto cantidad de personalización para los usuarios y ayuda con la abrumadora tarea de administrar las miles de páginas que las empresas a gran escala tienen como parte de sus sitios web internos y externos, ¿existe una tecnología mejor?

Obteniendo información y comentarios de la comunidad

He estado tratando de obtener la mayor cantidad de información posible. Escribí un pequeño artículo sobre TSS sobre el tema:

¿Qué otras alternativas al portal existen en el mercado?

También estoy resucitando un hilo en CodeRanch para ver si puedo obtener alguna idea de ese guapo equipo.

Hilo actualizado que pide una alternativa a una estrategia de software de portal. Circa 2012

También estoy buscando información de los twitterati (@potemcam).

No se trata tanto de una publicación cruzada como de un intento de reunir realmente una visión aguda de la comunidad. Si puedo obtener algunas respuestas y experiencias sólidas, me gustaría agregarlas en un artículo de asesoramiento en TSS.

¿Cuál es la alternativa correcta a un portal empresarial en el espacio Java?

Por cierto, también haré enlaces cruzados a esta pregunta desde otros sitios para que las personas con las mismas preguntas puedan ir y venir y ver qué dice la comunidad sobre este tema.

Primero, debe tener en cuenta qué problemas Portal fue diseñado para resolver. ¿Es, como sugiere Wikipedia, reunir información de diversas fuentes de manera unificada? Si es así, ¿de qué otras maneras tenemos que hacer esto ahora?

Bueno, primero, ¿cómo se reúne información de diversas fuentes? La respuesta obvia es llamar a una variedad de servicios (web). Esto presenta problemas de contratos y latencia de red, bla, bla, bla, pero estas son cosas mal resueltas por el portal, así que es su decisión. ¿Y si los servicios son RESTful? ¿Eso facilita la gestión de contratos? Posiblemente.

Entonces, ¿cómo se unifica la información? Uno de los problemas que resolvió Portal fue cómo llevar estos elementos dispares a una página y hacer que se carguen de forma independiente. AJAX ha crecido desde entonces, y el mismo efecto puede manejarse potencialmente usando llamadas XMLHttpRequest a los diversos servicios (RESTful?) Para obtener sus datos, y luego usando un conjunto compartido de hojas de estilo.

esto funcionara? Puede y lo hace. ¿Es más manejable que los servidores de portal JSR286? Probablemente. ¿Todavía hay un montón de problemas que superar? Seguro. Pero es una alternativa viable.

Recientemente he estado profundamente involucrado en la escena del servidor del portal Java. Fue elegido como una alternativa económica a SharePoint, ya que pudimos encontrar un proveedor de portal con características comparables. Fuimos con eXo Platform y aunque se anuncia sobre todo para las características sociales, es totalmente compatible como un servidor de portal JSR286.

Un portal de Java puede ser increíblemente poderoso, pero naturalmente tiene el costo de parecer excesivamente diseñado e innecesariamente complejo. La respuesta general del cliente que hemos recibido ha sido que la configuración básica y la sobrecarga de un servidor pueden ser demasiado. Todavía tengo que encontrar una plataforma o alternativa de portal que pueda ofrecer un conjunto detallado de funciones, pero que siga siendo aceptablemente escaso para un conjunto de requisitos operativos. Años de hinchazón de características entre plataformas de portal competidoras han afectado seriamente al mercado.

El crecimiento en el mundo del portal Java ha sido extremadamente lento. Encontrará interfaces anticuadas, UX arcaico, y cada acción dejará un mal sabor de boca. Hay pocos innovadores aquí, eXo Platform es uno de los pocos que encontramos haciendo un esfuerzo concertado para la modernización.

Dado todo eso, aún puede crear un producto razonable en el mundo JSR268 con una medida de éxito. Pudimos hacer esto aprovechando los servicios JAX-RS para cada portlet, básicamente características y funcionalidad del portlet de selección de cereza. Todo el acceso a la base de datos se ejecuta desde el servidor web, servicios RESTful separados para operaciones CRUD optimizadas. Se necesita una diligencia imponente con un exceso de esfuerzo que no muchos están dispuestos a cometer.

También puede ir completamente a cero y construir un 'portal' con servlets y JAX-RS. Esto se puede hacer mucho más rápidamente que el desarrollo de portal estándar. Sin embargo, se quedará corto cuando se trata de admitir el conjunto completo de características de configuración que se encuentran en un portal web estándar.

Simplemente, hay un ciclo serio de atrapamiento de conjuntos de características excesivas que sofocan la innovación que no parece estar cambiando pronto. Es poco probable que ocurran avances que cambien el juego porque los grandes bateadores no ven la meta evolución. Pero su única opción alternativa es reinventar solo las características que desee.

No estoy de acuerdo con Matthew , ninguno de los problemas con los portales empresariales es causado directamente por la tecnología. El problema es casi siempre una falta de enfoque y dirección claros.

¿Cuál es el problema que estás tratando de resolver? Intenta concretarlo con algunos detalles. Probablemente pueda adivinar que mover la información de las bandejas de entrada del correo electrónico a alguna solución de contenido de búsqueda será bastante alta. Al igual que encontrar información que vive en unidades de red compartidas. Entonces, probablemente haya una pregunta sobre el flujo de trabajo.

Más allá de eso, comienza a ponerse un poco nebuloso y ahí es donde fallan las soluciones. Si alguien intenta venderle un portal con una demostración que muestra a un equipo no relacionado que busca información sobre su problema y encuentra que otro equipo ya ha resuelto que el problema no es reconocer cómo trabaja la gente.

No quiero que esto se convierta en un largo gofre, así que haré una pregunta. ¿Su solución de portal le permite compartir información con sus pares tan fácilmente como su cliente de correo electrónico? Específicamente, mi aplicación se bloqueó y quiero enviarle una captura de pantalla. Puedo pegar eso directamente en mi correo electrónico, eso no funcionará con soluciones basadas en la web. ¿Se integra con Office? ¿Quién va a obtener toda la información existente en el portal?

Concéntrese en las personas, sus interacciones y sus necesidades y olvide primero lo técnico. Segundo, modere las expectativas y deseos de la gente con una dosis de realidad.