Hoy mismo me llegaba un comentario al blog de un lector que plantea una cuestión muy importante, y tal vez, como él mismo decía  quizás se pase siempre por alto cuando hablamos de SOA.

La cuestión era sobre el papel de la capa de presentación en SOA. Normalmente únicamente se habla de la capa de servicios, del bus ESB, las lógicas de negocio, etc. etc. pero ¿qué pasa con la capa de presentación? ¿cómo hay que considerar el interfaz de usuario en una arquitectura SOA?

Con una arquitectura no SOA, una aplicación típica, por ejemplo de gestión de clientes, estará formada por un solo desarrollo, un solo desplegable en el servidor, en el que tendremos las pantallas, la lógica de negocio y el acceso a datos. Por supuesto, si está bien diseñado estos tres aspectos estarán separados en tres capas lógicas.

Sin embargo, esta separación lógica no es suficiente. Toda la aplicación sigue siendo una única “pelota”, un todo o nada. ¿por qué esto no es válido desde el punto de vista de SOA? analicémosla bajo dos puntos de vista básicos que consagra SOA: la multicanalidad y la reutilización.

Multicanalidad

Nuestra aplicación estará hecha en un tecnología determinada. Por ejemplo, una aplicación web en .NET o en Java destinada a ser ejecutadas en una oficina de la compañía por un empleado.

Sin embargo, nuestra empresa quiere abrir una canal en internet y quiere que el cliente directamente pueda modificar sus propios datos, por ejemplo, su domicilio. Pues bien, aunque la tecnología pudiera ser válida para publicarla directamente en internet, al final al cabo es una aplicación web, nos encontraremos con un problema.

La funcionalidad de la aplicación no es válida para el canal de internet para un usuario final. ¿por qué? pues porque tendrá demasiada funcionalidad y la usabilidad de la misma no valdrá para otro canal que para el que fue diseñada. No olvidemos que se trata de una aplicación de negocio para nuestra red de oficinas.

Tendríamos que hacer un cambio tan profundo en la usabilidad y en la funcionalidad, básicamente recortando la aplicación que no nos quedaría más remedio que volver a implementarla. ¿y qué pasa con la lógica de negocio? al fin y al cambio la lógica de “cambiar domicilio” tendría que valer para el nuevo canal. Sí tendría que valer, pero no es posible separar esto de la “pelota” que tenemos por aplicación. ¿por qué? porque no está orientada a servicios.

Reutilización

Y en este ejemplo, hipotético pero perfectamente real, se tiene en cuenta el canal de internet (con la misma tecnología que la empleada para el canal de oficina). Pensemos lo que sería por ejemplo, hacer una aplicación nativa para el móvil, seguramente con otro lenguaje y framework.

No podremos reaprovechar nada de la aplicación, cero.

Principios de SOA aplicados a la capa de presentación

La capa de presentación se define como 100% consumidora de servicios (ver esta entrada), y para su diseño debemos de tener en cuenta estos principios (pocos pero muy importantes):

  1. Aplicaciones de negocio multicanal.
    Ya hemos hablado de esto más arriba, pero en resumen, si tenemos nuestra lógica de negocio mezclada con la lógica de presentación nuestra aplicación o será multicanal ni reutilizable (no será SOA).
    Hay que tener en cuenta que una aplicación de negocio debe ser capaz de empezar la gestión por un canal, continuar por otro y finalizar por un tercero. Por ejemplo, empezar con una pantalla en una aplicación internet para solicitar un pedido a una tienda, continuar respondiendo con un SMS, y finalizar mediante una llamada telefónica.
    Si la lógica de negocio está en el canal en lugar de en servicios, tendremos un problema.
  2. Flujos de navegación, no procesos de negocio.
    En las pantallas hay que poner únicamente la lógica de interacción con el usuario, nada más. Los procesos de negocio, la secuencia de tareas de negocio que hay que ejecutar para dar una funcionalidad de negocio debe estar en la capa de integración (en el servidor de procesos).
  3. Sin estado, sin conversación
    En una interacción con el usuario, por ejemplo “la modificación del domicilio” se ejecuta en un flujo de pantallas. Durante este flujo se va recopilando y mostrando información al usuario, pero una vez que se acaba el flujo, esta información desaparece. Es decir, se destruye la memoria de sesión.
    Por supuesto la lógica de negocio (servicios) invocada desde la pantalla habrá persistido esta información en la base de datos si es necesario.
  4. Las operaciones de acceso son independientes entre sí
    Si queremos desacoplar la lógica de la aplicación, debemos hacer los flujos independientes entre sí, es decir “sin estado”. Esto se traduce en la práctica que para que un flujo empiece no es necesario que se haya ejecutado un flujo anteriormente.

Conclusión

Si los servicios de negocio son el “cerebro” de la compañía, sin duda, la lógica de presentación son sus ojos y oídos. Sin embargo, no debemos mezclar las cosas y mantenerla claramente separados.

Por un lado, el cerebro, como un conjunto de servicios de negocio multicanal y reutilizables, combinables para formar otros servicios de más alto valor añadido.

Por otro lado, las lógicas de presentación, que deben de adaptarse al canal y al dispositivo. Y pueden ser muchos y muy variados, aplicación web para el canal de internet, aplicación de escritorio para el canal de oficina, aplicación móvil nativa, vía SMS, B2B, etc. etc.

Comparte esta entrada:
Share

Anuncios