pebble

He pasado muchas horas intentando convencer a la gente de que los servicios que exponen la lógica de negocio de los backends deben ser agnósticos respecto a la presentación (espero haber convencido a alguno). Es decir, no puedes hacer ninguna suposición de cómo o quien van a consumir estos servicios.

Lo normal en las aplicaciones tradicionales es que la lógica de negocio de una aplicación fuese consumida directamente por la pantalla de la propia aplicación. Incluso, en las arquitecturas cliente/servidor había lógica de negocio que estaba físicamente al lado de las pantallas.

Con SOA ya sabemos que esto no es así, que los servicios no contienen lógica de presentación y que no deben saber nada del cliente que les invoca. Les debe dar igual si es la pantalla de “tu” aplicación, de otra aplicación, si es otro servicio o incluso si es otra empresa la que lo invoca.

Y el caso más gráfico de todo esto, lo podemos ver ahora con los famosos smartwatch (como el Samsung Gear o el Pebble). Donde el consumidor del servicio no es ya una web, ni siguiera una App móvil, es un reloj, ni más de menos.

¿Qué vamos hacer ahora con esos “servicios” cuya salida está pensada para una pantalla o aplicación en particular?

En esta entrada hablaba precisamente de cómo afectaban los principios de SOA a la arquitectura de una aplicación. Respecto al backend específicamente, teníamos esto:

  • Independiente del canal o frontal.
  • No tiene lógica de presentación.
  • No tiene idioma.
  • Sin estado.
  • Sin procesos de negocio.
  • Interfaz explícita.

Pues eso… tengamos la mente abierta y miremos al presente y al futuro de las aplicaciones. Hemos pasado de aplicaciones de escritorio a aplicaciones web, luego apps móviles, ahora a los relojes… ya estamos en los termostatos, neveras, lavadoras, pulseras, colgantes, coches… no cometamos el error de pensar en cómo se va a presentar la información que proporciona nuestro servicio para diseñarlo.

Anuncios