Cuando una aplicación o servicio quiere usar otro servicio o producto de terceros, y por terceros me refiero a cualquier software que no esté desarrollado por nuestra compañía, lo habitual en Arquitectura es poner una capa de abstracción entre el cliente y el que proporciona este servicio o funcionalidad. Mediante esta capa intermedia nos estamos independizando de un fabricante en concreto o incluso de una tecnología.

Ejemplos hay cientos:

  • Uno muy habitual sería en el caso en que realizamos una operación contra la base de datos. Una base de datos de un fabricante concreto.
  • Otro caso menos frecuente podría ser el caso de que nuestra empresa contrata con un broker proveedor de envío de SMS. Lo normal es que es broker nos proporcione un API propietario, puede ser un web service, al que debemos adaptarnos  para poder enviar el SMS. Evidentemente nuestra empresa puede cambiar de proveedor con el tiempo, por ejemplo, porque ha encontrado otro que le da mejores condiciones económicas o más fiabilidad en el servicio.

Desde el punto de vista del diseño técnico de la aplicación lo primero que debemos de tratar es de independizarnos lo más posible del API que vamos a utilizar. Si hay algo cierto en informática, es que las cosas cambian. Nada permanece igual con el tiempo. Cosas que nos parecen poco cambiantes, como sería el API de un producto de referencia en su categoría, como un gestor documental, puede cambiar sin “previo aviso” de una versión para otra. Al cambiar el API, el interfaz público del software que estamos usando, cosa que nos habían jurado que no iba a pasar nunca, tendremos que asumir un coste en la adaptación de nuestro servicio o aplicación.

Como comentaba, la práctica habitual en el diseño de las aplicaciones consiste en crear una capa intermedia entre el cliente y el proveedor de la funcionalidad en cuestión. Una capa de abstracción que rompa el fuerte acoplamiento para que posibles cambios (tanto en las propias versiones del producto o una sustitución por otro producto) no afecten o afecten lo mínimo posible a nuestros desarrollos.

Adicionalmente obtendremos otra serie de beneficios si aprovechamos la existencia de esta capa:

  1. Reducción de la complejidad. En ocasiones un API de un proveedor tiene muchos parámetros que es posible que no necesitemos. En lugar de “enfrentar” al programador con esta complejidad se puede implementar un interfaz sencillo en la capa de abstracción y que sea ésta la que se encargue de lidiar con el proveedor.
  2. Posibilidad de elección de una implementación del servicio en tiempo de ejecución. La capa intermedia o capa de abstracción normalmente se implementa mediante un patrón de diseño del tipo abstract factory. Mediante este patrón se pueden tener varias implementaciones y con arreglo a un criterio, que puede ser calculado en tiempo de ejecución, elegir una u otra. Por ejemplo, en el caso del broker de SMS, en un hipotético caso podríamos tener dos brokers con diferentes precios por mensaje según la hora del envío. Para el cliente, esto sería transparente ya que sería la factoría la que usaría una instancia de un proveedor u otro, eligiendo entre ellos automáticamente en función de la hora.

¿dónde esta el límite?

Llevado este enfoque al límite tendríamos una aplicación o servicio en el que todas las operaciones que podríamos llamar de entrada/salida, o de relaciones “con el exterior” se harían a través de una capa de abstracción. Me refiero con esto no sólo para acceder a la base de datos, el envío de SMS, de email, etc. sino también, por que no, para leer o escribir un fichero del sistema de archivos. Con esto conseguiríamos una aplicación totalmente independizada de su “entorno de ejecución”. Aunque parezca una exageración, esta proliferación de capas puede estar muy justificada.

En nuestro caso, por ejemplo, en un servicio implementado con EJB (Enterprise Java Beans o los objetos que implementan la lógica de negocio según JEE) necesita escribir ficheros en disco. Pues bien, según la especificación no es posible hacer esto. Sin embargo, existe una zona gris de indeterminación respecto al seguimiento que de esta norma hacen los servidores de aplicaciones. Así pues, por el momento, se permite este acceso a disco desde el EJB, pero por aquello de cubrirse las espaldas, se ha implementado una capa de abstracción para esta funcionalidad. Así pues, por el momento se escribe a disco, pero llegado el momento, sería muy fácil para la arquiectura realizar otra implementación que escribiese en base de datos en lugar del sistema de archivos. La aplicación cliente no sufriría ningún cambio ya que este sería totalmente transparente.

Conclusión

Teniendo en cuenta la experiencia vivida, siempre que sea posible, es muy recomendable interponer una capa de abstracción entre nuestras aplicaciones y el software de terceros, operaciones de entrada/salida, etc.

Comparte esta entrada…

Share

Anuncios