offline-525700_640

Estamos ya acostumbrados a pensar en servicios como una encapsulación de lógica de negocio. Además para que SOA tenga sentido, y sea rentable desde el punto de vista económico, estos servicios deben ser reutilizables en la teoría y en la práctica, siendo uno de los primeros indicadores del éxito de una adopción de SOA precisamente el porcentaje de reutilización de estos servicios.

Reutilización y conectividad

Obviamente para que ello suceda, tiene que ser posible que los que quieran consumir servicios puedan invocarlos. Y como un cliente debe desconocer la localización física del servicio al que llama, porque según los principios de SOA estos deben estar desacoplados, normalmente la invocación se hace a través de la Red.

Además del desacoplamiento, por un principio básico de la programación, un cierto código que hace una tarea concreta debería idealmente debe estar en un solo sitio para no dificultar el mantenimiento del mismo.

¿Pero que pasa si el cliente de estos servicios no tiene conexión?¿ Se nos viene abajo todo el montaje?

¿Qué pasa si no hay conexión?

Pensemos en una aplicación móvil de negocio, una de las que una empresa puede proporcionar a sus empleados para movilizar un proceso de negocio (business to employee). Puede ser bastante normal que tengamos que trabajar en zonas con mala o directamente sin cobertura y por lo tanto, en el que no se puede invocar a los servicios del backend de la empresa.

Evidentemente existen procesos que se ejecutan en un dispositivo móvil que pueden “esperar” a que tengamos conexión para continuar… pero ¿Qué pasa con los que no pueden esperar?

Nos encontramos con la paradoja que nuestra arquitectura SOA y nuestros servicios de negocio desplegados en servidores de los que nos sabemos su localización física, seguramente accedidos a través de un bus o otros servicios compuestos no pueden ser invocados desde el dispositivo.

¿qué opción nos queda en este caso?

Si la lógica de negocio tiene que ser ejecutada si o sí, incluso cuando no hay conexión, es de perogrullo que hay que trasladar esta lógica al propio dispositivo.

Pero no podemos mover esta lógica desde los backend de negocio al móvil… más bien, la cosa consistiría en coger una porción de la lógica del backend (la más pequeña posible) e implementarla en la aplicación móvil. Y digo no mover si no copiar… es decir, que vamos a tener una lógica de negocio en dos sitios (al menos), en el dispositivo y en el backend. Además tendremos seguramente un semáforo que nos indica que si hay conexión debemos llamar al backend mientras que si no la hay, como plan de “contingencia”, hay que ejecutar la lógica en modo local.

Como casi todo lo que tiene que ver con la arquitectura y desarrollo de aplicaciones móviles, la cosa se complica aún más, ya que no sólo tendremos seguramente una plataforma móvil como iOS y Android. Lo normal es que tengamos al menos estas dos, quizás también la de windows phone… y quizás, en el caso más problemático, es posible que tengamos diferentes apps para móviles que para tablets.

Así pues, lo que venía siendo un caso claro de invocación desde un cliente a un servicio SOA del backend, nos podemos encontrar con que tenemos la lógica de negocio replicada en varios sitios y además con diferentes tecnologías y lenguajes de programación.

Por supuesto, hay opciones intermedias como son las aplicaciones híbridas en las que podremos desarrollar la lógica de negocio en javascript para todas las plataformas pero también podemos tener el caso de desarrollo nativos y por lo tanto tendríamos estas lógicas en Objective-C para iOs, Java para Android y c# para windows phone. 

¿existe solución?

En un mundo ideal, quizás tendríamos algo parecido a lo de los applets en Java (¿alguien se acuerda de ellos?). Es decir, sería un componente compilado y ejecutándose en el servidor (en este caso un fichero .jar) pero que tendríamos la posibilidad de “empaquetarlo” en algo parecido al applet. De alguna manera, se desarrollaría una sola vez y esta librería de código sería capaz de ejecutarse en un servidor de aplicaciones en el servidor y también ser descargado al dispositivo para ejecutarse en local. 

Este tipo de tecnología, así tal cual, no creo que exista.. .aunque puede haber que se le parezca y que cambie la forma de desarrollar. Me refiero al nuevo lenguaje “universal” que no es otro que nuestro viejo conocido javascript. Ya es el lenguaje de referencia en las aplicaciones web que se ejecutan en el navegador, también lo es en plataformas móviles de construcción en modo híbrido y también, poco a poco, va conquistando el servidor con servidores del tipo node.js. De esta manera, al menos en teoría, un mismo código podría ejecutarse tanto en el servidor como en los dispositivos móviles.

Claro que esta posible solución, sólo valdría para los nuevos desarrollos de lógicas de negocio. No olvidemos que la gran parte de los backends actuales están escritos en lenguajes como COBOL o PL/SQL y no es posible hacer esto.

En definitiva, el estado offline en SOA es otro de los problemas con los que tenemos que lidiar… y no son pocos lo que hay ya 😉