Una vez al año no hace daño.
Cuando se trabaja en un entorno en el que conviven varias aplicaciones es natural que tarde o temprano se comuniquen entre ellas o incluso que desde un principio estén diseñadas para ello. El objetivo es conseguir un sistema modular en el que se duplique la mínima cantidad posible de información y de esfuerzo de los desarrolladores y mantenedores de las aplicaciones.
Esta comunicación puede hacerse a muchos niveles y de muchas formas pero lo ideal es que las dependencias sean lo mas flexibles posibles y no haya acoplamientos rígidos, que el sistema sea distribuido y que use protocolos estándar no propietarios.
En los últimos tiempos hay una arquitectura en alza que parece puede cumplir esos objetivos en mayor medida que otras alternativas mas aparatosas: hablamos de REST, claro esta. Sin embargo cuando hablamos de aplicaciones con interfaces gráficas surge la aspiración de extender esa reutilización hasta la misma interfaz y no quedarse solo a nivel del API. Así a bote pronto se me ocurren pocas alternativas para reusar dinamicamente, en tiempo de ejecución, interfaces graficas complejas de diferentes aplicaciones web: portlets tal vez. Si conoceis alguna no dudeis en apuntarla, si es posible con sus ventajas e inconvenientes.
En mi caso inspirandome en el flujo de una autenticación vía http del tipo oauth opté por lo que me pareció una solución directa y sencilla (demasiado tal vez), al menos a simple vista: hacer una llamada estándar http de una aplicación a otra con el objetivo de presentar el html servido por la segunda. Este html no es embebido ni transformado: simplemente la pagina servida por la otra aplicación se carga en el navegador. En la llamada la aplicación "cliente" o llamadora incluiría en los parámetros la url (que puede ser de la misma aplicación cliente) y parámetros de vuelta. La aplicación servidora los utilizara en determinados puntos para que el usuario pueda volver a la aplicación original o a la url siguiente en el flujo de la operación, añadiendo mas información en los parámetros si es necesario.
Por ejemplo tenemos el típico caso en el que una aplicación tiene que elegir un recurso o recursos de otra para completar una operación. Una llamada al API teniendo su identificador es muy sencilla pero para conseguirlo de una forma cómoda pueden hacer falta varias pantallas de filtro y navegar entre varios recursos y pantallas. Es lógico querer reutilizar toda ese flujo y la interfaz y que la aplicación cliente no dependa de si cambia la lógica tanto de negocio como de la presentación. La llamada tendría este esquema:
http://server/aplicacion-tramitacion/expediente/201001?select=informe.inicial&ciudadano.id=dni&client.urlback=/aplicacion-atencion-ciudadana/peticion/&client.urlback.params=usuario=x
Para ello la aplicación servidora debe estar preparada para gestionar esas peticiones externas, modificando ligeramente su propia interfáz para añadir los puntos donde el usuario puede volver a la aplicación originál (o a cualquier otra), bien seleccionando uno o varios recursos o cancelando la selección. El usuario navega entre el filtro, los listados y los detalles de los recursos hasta encontrar el deseado y volver usando "client.urlback"
http://server/aplicacion-atencion-ciudadana/peticion/3?informe.inicial=12&usuario=x
Este es justamente el caso en el que efectivamente lo he usado. Sin embargo no estoy totalmente seguro de los posibles inconvenientes de esta solución, sobre todo a la hora de generalizarla a otros casos diferentes y como puede escalar en función de la complejidad de las llamadas. Tampoco tengo una referencia de posibles alternativas con las que comparar y evaluar los pros y los contras. Por ejemplo el número de parámetros de las llamadas puede hacerse inmanejable y en cualquier caso no es muy elegante, al menos superficialmente (aunque siempre pueden usarse llamadas de tipo POST para ocultarlos)
