hand-427517_640

No voy a insistir en el hecho de que los patrones de diseño aplicados al software me parece realmente una de las mejoras cosas que se ha inventando. Patrones que se pueden aplicar tanto al diseño “interno” de un programa como a la forma de exponer esta funcionalidad al exterior. Y con eso me refiero a la exposición como servicio de este software.

Existen muchos patrones de diseño aplicados en SOA. Podemos ver en primer lugar los que se recogen en la página “oficial” de Thomas Erl. Claro que cada uno puede crear y aplicar los patrones que se le ocurran, o más bien, que “descubra” a partir de sus propios diseños e implementaciones. Por supuesto, no hay un catálogo cerrado de patrones. Lo importante es aplicarlos bien, los que se publican en la comunidad, y con el tiempo, identificar los nuevos patrones y publicarlos para que el resto los use.

Si hablamos en concreto sobre los patrones SOA, aparece una exhaustiva lista en la página de SOA Patterns. Y es tan exhaustiva que al principio asusta un poco, pero esto es debido a que son, creo, de muy bajo nivel de detalle. Y es que al poco que  repasas un poco la lista, te das cuenta que de manera intencionada o más o menos intuitiva.

Lo primero que tengo que decir, es que la página no brilla por su claridad de exposición precisamente. Así las cosas creo que se puede resumir perfectamente.

Foundational Service Patterns

Habla de capacidades y contexto agnósticos de un servicio, que simplemente se refiere a la capacidad de un servicio para que pueda ser reutilizado en varios sitios en las aplicaciones de la empresa.

En un caso sencillo, este sería el caso de un servicio que por ejemplo, nos permite conocer el nombre y apellidos de un cliente a partir de su documento de identidad. Está claro que este servicio se puede utilizar en múltiples procesos y otros servicios: facturación, envío de email, etc. etc.

Para que esto sea posible, la lógica dentro de este servicio tiene que estar encapsulada y no depender de nada externo al propio servicio.

Patrones sobre el inventario de servicios

Básicamente lo que viene a decir que es preferible diseñar los servicios para evitar el cambio de protocolo y el cambio del modelo de datos. Es decir, que no haga falta cambiar esto cada vez que un servicio llama a otro, simplemente porque es un trabajo ímprobo mapear los campos de un servicio y otro en tiempo de construcción y también pasa factura en tiempo de ejecución ya que es necesario realizar miles o millones de transformaciones que podrían ser evitables.

También se recoge el hecho de que es necesario un inventario accesible desde toda la empresa para que se puedan reutilizar en los nuevos servicios compuestos que vayan surgiendo.

Por supuesto, uno de los objetivos también es el evitar los servicio duplicados o repetidos. Es decir, que para hacer una cosa concreta sólo haya un servicio y no dos tres, o n veces, como suele ocurrir en las empresas.

Transformación

Nos encontramos aquí con cosas que pueden resultar obvias, aunque entiendo la necesidad de dejar por escrito, nunca se sabe… En una arquitectura SOA es necesario la transformación del formato, del modelo de datos y de los protocolos.

Aunque hay que procurar que los nuevos servicios esta necesidad sea la mínima posible, evidentemente vamos a tener que acceder a antiguos programas y aplicaciones legacy en la que es imprescindible hacer estas transformaciones.

REST

Me parece curioso el apartado específico para servicios REST. Como en otras ocasiones se recogen aquí aspectos básicos como son el “linkado” desde una entidad de negocio a otra (es decir, los enlaces que propugna HATEOAS).

Habla también que los servicios deben ser “ligeros”, aunque no se explica mucho más, para optimizar el intercambio de datos y el proceso que se tiene que hacer en la parte cliente.

Si tenemos en cuenta que los servicios REST muchas veces tienen en el lado cliente a consumidores con pocos recursos como son las páginas web (que ejecutan javascript) y que además también tenemos en muchos casos aplicaciones móviles, es obvio que tenemos que minimizar el trasiego de datos (para no gastar la cuota de datos móvil y que también todas estas transformaciones al final se traducen en un mayor consumo de batería).

Patrones de mensajería

En este apartado se recoge los patrones, en ocasiones yo diría más bien que características, que nos encontramos en una implementación de servicios:

  • Colas asíncronas de mensajes
  • Mensajes orientados a eventos
  • Envío fiable, es decir, garantizar que el mensaje va a llegar a su destinatario aunque este esté caído, no haya red, etc. etc.
  • Callback, o como el destino puede devolver la llamada al cliente
  • Enrutado de mensajes
  • Intermediario de mensajes para su transformación, logs, gestión de errores, etc.

Conclusión

En definitiva, es una página que hay que visitar. Aunque como digo, echo en falta una mayor claridad en la explicación. De fondo, encuentro que esos patrones son de muy bajo nivel. En algunas ocasiones, ni siquiera diría que son patrones. Más bien diría que son características que deben de cumplir los mensajes.

Como conclusión final, diría que si queremos diseñar servicios SOA, de las primeras cosas que deberíamos hacer es informarnos sobre los patrones que ya alguien ha identificado. Y luego sopesar, para nuestro caso particular, si aplica tal o cual patrón o necesitamos aplicar una nueva solución específica.

 

Anuncios