pieces-of-the-puzzle-592798_640

Cuando pensamos en los servicios candidatos en un proyecto, es bastante común agrupar en un sólo servicios varias capacidades (capabilities) en uno de estos servicios candidatos. Esto en los servicios de tipo Web Services, se traduce en que un sólo servicio tiene varias operaciones.

La lógica nos lleva a pensar en que si hacemos un servicio que gestiona la entidad “cliente” por poner un ejemplo, en que este servicio tendría la capacidad de “dar de alta cliente”, “modificar cliente” y “consultar cliente”. Es decir, toda la lógica de negocio necesaria para trabajar con esta entidad de negocio.

Sin embargo, debemos tener en cuenta que estos servicios, cuando se implementan, dejan de estar en el “mundo de las ideas” y es necesario que se aterricen sobre un middleware y un hardware, es decir, el “mundo real”.

Después de tener un poco de experiencia con la arquitectura y diseño de algunos servicios creo que se tendría que seguir una práctica que parece poca cosa en un principio, pero si no lo pensamos antes de desarrollar los servicios, casi seguro que ya no no podremos aplicarla con el problema que ello puede suponer.

Creo que sería una buena práctica separar la implementación de los servicios de consulta de los de escritura. Lo digo por varios motivos, me explico:

  • El acceso a base de datos lo podemos optimizar mediante un configuración distinta de los datasources (acceso desde los servidores de aplicaciones a la base de datos).
  • Puede haber escenarios en los que no, pero lo normal es que las operaciones de lectura se invoquen más veces que las de escritura. Esto nos podría tomar decisiones de diseño diferentes para los dos casos que nos ayuden a mejorar el funcionamiento de los servicios.
  • Optimización de la transaccionalidad. Como medida de mejora del rendimiento podemos hacer fácilmente que las operaciones de lectura no tengan transaccionalidad distribuida mientras que los de escritura sí la tengan.
  • Podemos cachear los servicios de consulta de varias maneras, incluso a nivel de servidor web (en el mensaje SOAP).
  • Podemos gestionar mejor los permisos de acceso, es muy común que un rol sólo tenga permiso de lectura mientras que otro rol tenga los de lectura y escritura.

Por convención, los nombres de los Web Services deberían contener un verbo y un sustantivo que lo definan con detalle. Por ejemplo, “Comprar Artículo”. Si separamos las operaciones de lectura respecto a las de escritura, podríamos tener un servicio de “consultar cliente” y otro de “gestionar cliente” donde agruparíamos las operaciones de escritura.

En conclusión, creo que puede ser una buena práctica separar las operaciones de lectura de las de escritura en la definición de los servicios. Si se hace en esta etapa nos saldrá prácticamente “gratis”. Cualquier cambio en este sentido una vez que estén implementados, nos será prácticamente imposiblece hacerlo.

Creo que este es un caso paradigmático de “pequeña” decisiones que podemos tomar en una etapa temprana que pueden reportarnos grandes beneficios posteriormente. El modelo de gestión de la seguridad y de la identididad  puede ser otro, pero sin duda, hay muchos aspectos a los que debemos echarle “una pensada”.