reutilización

Cuando ya de por sí es complicado diseñar una solución end-to-end que comprenda desde la app móvil hasta el backend empresarial, queremos ir más allá y hacer que esta solución completa sea reutilizable en diferentes compañías e incluso en diferentes países.

Naturalmente esto no es nada fácil y, por decirlo así, el número de variantes, combinaciones y permutaciones de elementos a tener en cuenta se dispara.
Afortunadamente, a nuestro favor, tenemos una de las principales características de SOA (y uno de sus 8 principios básicos): el desacoplamiento.

Por supuesto, vamos a tener que contar con los principios que hacen referencia a los contratos de servicios, con la autonomía… pero gracias al desacoplamiento, el consumidor del servicio no tendrá ni idea de dónde se ejecuta el servicio, ni siquiera sabrá cómo está hecho (abstracción) el servicio por dentro ni sobre qué sistema operativo, servidor de aplicaciones o gestor de base de datos en el que se basa.

A nuestro favor, para poder hacer esto realidad, tenemos otro aliado no menos importante: en una arquitectura de servicios típica tenemos varias capas o niveles de servicios.

Si vemos la foto general de la solución y representamos al usuario de la aplicación a la izquierda y los backends a la derecha, tendremos muy probablemente cuatro grandes “capas” o “dominios”:

  1. Lógica de negocio implementada con el lenguaje correspondiente (Java, stored producdures, COBOL, etc). Estas son las operaciones más básicas desde el punto de vista de la arquitectura y ejecutan acciones concretas como “dar de alta un cliente”, “calcular presupuesto”, etc. etc.
    Si tenemos suerte, el propio backend será capaz de exponerse su lógica por si mismo como servicios SOAP o REST. Si no es así, me temo que tendremos que hacer una implementación de los mismos que envuelva la lógica de negocio y la exponga como un servicio.
  2. Servicios de integración donde se suelen encontrar los servicios compuestos que usan otros servicios (internos o externos). Si disponemos de un bus de integración en esta capa estarán típicamente los servicios desplegados sobre el mismo.
  3. Servicios de canal este tipo de servicios son los encargados de adaptar los servicios de negocio al canal específico al que se quieren dirigir. Típicamente adapta un servicio de negocio, de backend o compuesto, que es genérico y que puede caracterizarse por tener decenas o incluso cientos de campos de entrada/salida a unos más ligeros y especializados según el canal del que se trate. Por ejemplo, se adapta para dar servicio a una aplicación web de cliente final, donde se simplifica para un escenario concreto.
    Por ejemplo, el servicio de backend de contratar producto es de un grano muy grueso, muy reutilizable, por el resto de aplicaciones internas de la empresa (destinados a empleados) mientras que el ofrecido por internet es de más grano fino (especializado para un fin concreto).
  4. Aplicaciones de frontal que es realmente lo que usario ve de toda la solución. Aparte de los consabidos cambios de internacionalización como los literales y las imágenes, no tiene por qué verse afectado el interfaz al pasar la aplicación de un país a otro.
    Pero esto quizás es más probable en una aplicación para el usuario final. Al final todos usamos prácticamente la misma app de Gmail, por poner un ejemplo, sea cual sea el país donde vivamos.
    Sin embargo, en una aplicación comercial destinada a los empleados a buen seguro que tendremos que enfrentarnos a muchas diferencias… simplemente para adaptarse a los requisitos legales o de impuestos, por poner un ejemplo.
    Estos cambios pueden implicar que “aparezcan” o “desaparezcan” determinados campos de la pantalla según el país, o incluso que desaparezcan o se incluyan páginas o pantallas enteras porque en un país es necesario recoger ciertos datos o realizar cierto trámite que no es necesario en otros.

En el mejor de los escenarios, bastante improbable en la práctica, entre todas las capas tendremos unos contratos de servicios que no cambiarían sea cua sea la compañia o país en el que instalemos la solución.

Pero como digo, nos podemos olvidar de esta situación idílica, ya que a poco que cambie mínimamente una regulación legislativa o una regla de negocio el contrato será diferente.

La solución a aplicar será diferente si los cambios a realizar en el contrato son compatibles hacia atrás o no. Si son incompatibles estos cambios se van a retransmitir de la misma manera que las ondas de agua cuando arrojamos una piedra en un estanque.

Sería fácil decir que hay que diseñar los servicios pensando en que sean agnósticos y que puedan “asumir” los posibles cambios que puedan venir en el futuro, sería tanto como decir que tenemos aptitudes prácticamente adivinatorias… pero me temo que es lo que hay, aquí no hay magia, y únicamente la experencia (la propia o la ajena) nos ayudará en esto.

Al final, la conclusión parece clara, ¿Podríamos hacer una solución reutilizable a este nivel sin SOA?… sería casi imposible.

¿Las recomendaciones? Yo diría que ver cada capa como un compartimento lo más estanco posible de manera que los cambios que haya que hacer en su interior no se propaguen hacia fuera (manteniendo los contratos) y tratar en lo posible que cuando haya un cambio que sí afecte al exterior se propague lo mínimo posible.

Anuncios