En la entrada anterior, resumí los principios sobre los que se asienta la arquitectura orientada a servicios. Estos son los principios teóricos sobre los que se asienta una arquitectura SOA.  Sin embargo, ¿que repercusión tienen en la práctica estos nueve puntos? ¿en qué se traducen en un arquitectura T.I?

Una arquitectura SOA está formada generalmente por varias capas:

  1. Cliente: es el lenguaje de marcado (por ejemplo XHTML, los APIs JavaScript, CSS, etc.) que se ejecutan en el navegador
  2. Frontend : es la capa que se encarga de recibir las peticiones del usuario, invocar a la lógica de negocio y devolver los resultados al mismo. Controla la navegación de pantallas, apertura y cierre de la sesión web, etc.
  3. Integración: es la cala encargada de exponer los servicios al frontend(por ejemplo mediante web services). Crea servicios compuestos resultado de integrar llamadas a varios servicios de negocio. Contiene “mediaciones”, que transforman datos y enrutan la petición hacia el backend correspondiente y procesos de negocio de larga duración (implementados generalmente con BPEL)
  4. Backend: es donde reside la lógica de negocio propiamente dicha. En la empresa puede haber varios backends con tecnologías heterógeneas que la capa anterior se encarga de integrar y dar un interfaz homogéneo hacia el fronted
  5. Base de datos: donde se persiste la información de negocio (Oracle, db2, SQL Server, etc)

Teniendo en cuenta los principios de SOA y la distribución en capas que he citado antes:

¿como afectan estos específicamente a la capa de frontend?

  • Las aplicaciones de negocio son multicanal o multi-frontend. Los dispositivos desde los que un usuario puede acceder a la aplicación son muchos y variados. Aparte de habitual navegador desde un ordenador de escritorio, nuestro canal pueden ser un navegador móvil, una aplicación tipo iPhone o Android, SMS, etc.
    Por lo tanto, desde el punto de vista del diseño de una aplicación hay que tener esto en cuenta y por ejemplo, no se puede tener un controlador de flujo o navegación en el core. Es el frontend, cada uno es distinto, el que tiene que tomar las decisiones sobre a qué pantalla navegar, como se presenta el interfaz al usuario, etc.
  • En el frontend existen flujos de navegación, esto es, una serie de pantallas con una navegación definida. No hay sin embargo, procesos de negocio (esto es parte de la capa de integración).
  • El ámbito de la información es el flujo de navegación. Quiero esto decir que hay que tener en cuenta que la información que se presenta y/o se recopila del usuario en las pantallas tiene una vida muy corta, la de la sesión del mismo. Si por ejemplo, el usuario cierra su navegador o está un periodo de tiempo sin interactuar con la aplicacion, esta información se perderá. No se puede tener en el frontend información que se necesita que dure dos días, por ejemplo.
  • El frontend no tiene lógica de negocio. Ésa reside en la capa SOA y sobre todo en la capa Core. No se puede poner lógica de negocio aquí ya que es posible que el cliente que use la aplicación no tenga ni frontend, como en el caso del B2B. Para la lógica de negocio, el frontend se limita únicamente a invocar a la capa de integración
  • Los flujos son independientes entre sí. No existe el concepto de un flujo que llama a otros flujos, coreografiando los servicios de negocio, porque esto sería un proceso de negocio e iría en la capa SOA.
    En un proceso de negocio, los flujos se corresponden los tareas humanas. Esto es cuando en la ejecución de un proceso, se ejecutan las tareas automáticas y se encuentra con una tarea humana (por ejemplo, “aprobar vacaciones”). Esto se traduce en que se crea una lista de tareas o to-do list que se le presenta al usuario encargado de aprobar esas vacaciones. Cuando el usuario pulsa sobre esta tarea, se lanzará un flujo de navegación para que el usuario pueda completar esta tarea.
  • El frontal no gestiona la transaccionalidad. Como consecuencia de todo lo anterior (no tiene lógica de negocio). Normalmente la transaccionalidad la maneja la capa de integración (transacción distribuida entre diferentes backends) o directamente en el propio backend.

¿como afecta al Backend?

  • Independiente del canal o frontal. Simplemente el backend no tiene que saber quién le llama (referido a la frontal o tipo de presentación o interfaz de usuario). Evidentemente se puede tener una parametrización distinta dependiendo del canal de entrada (por ejemplo ofrecer descuentos por internet que no se ofrecen en la oficina) pero esto serían más bien reglas de negocio.
  • No tiene lógica de presentación. Como el backend no sabe quien le llama, no caben conceptos tales como devolver texto formateado con HTML ni nada parecido. El backend tiene que devolver datos “puros” sin contaminar por la presentación.
  • No tiene idioma. Como no sabe nada de presentación, el backend no tiene que guardar información traducida a los idiomas de los posibles usuarios. Simplemente porque es posible que no haya un usuario. ¿que pasaría si el consumidor del servicio es otro servicio? ¿qué idioma tendría entonces?. La gestión del idioma debe hacerla el frontal.
  • Sin estado. Siguiendo el principio de SOA de no tener servicios con estado, pero también por razones de rendimiento, el backend no tiene estado
  • Sin procesos de negocio. Los procesos de negocio se gestionan en la capa de integración. Por lo tanto, el backend se simplifica y no tiene necesidad de gestionarlo.
  • Interfaz explícita. Debido a otro de los principios de SOA, la interfaz del servicio debe estar correctamente definida, tipada y conocida. Por ejemplo puede ser un WSDL en el caso de que el backed provea de servicios web, una COPY de una transacción CICS, un interfaz Java para el caso de exponerlo como un EJB, etc.

Conclusión

Una arquitectura SOA no se limita únicamente a identificar servicios y hacerlos disponibles al cliente. Es toda una filosofía que afecta, y mucho, al resto de capas que forman parte de la arquitectura. Podemos decir que tanto en el frontend como el backend, adelgazan y se simplifican, cediendo parte de los cometidos que tenían tradicionalmente asignados (como parte de lógica de negocio en el frontend o el proceso de negocio en el backend) a la capa de integración, verdadero corazón y centro neurálgico de la arquitectura.

Comparte este artículo…

Anuncios