En algunas ocasiones, nos proponen la construcción de un servicio con una característica un tanto curiosa, ese servicio sólo lo va a utilizar un cliente. Es decir,  no se va reutilizar.

Según Gartner y sus cinco principios de lo servicios web (ver esta entrada) el simple hecho de no ser un servicio “compartible” o shareable hace que no pueda considerarse como un servicio como tal. Realmente ¿qué sentido tiene?

Imaginemos una aplicación con interfaz de usuario (un frontal o frontend) que necesita un servicio de este tipo, es decir, sólo va a ser consumido por este cliente. Es necesario implementar el servicio (normalmente mediante un web service), desplegarlo, securizarlo, darlo de alta en el Registry o repositorio de servicios que tengamos, etc. etc. Sin duda muchas tareas y mucho trabajo para el beneficio que se va a obtener. Si estamos seguros de que ese servicio no lo va a usar nadie más ¿no sería mejor implementarlo directamente en la aplicación de frontal? es decir, ¿considerarlo como una librería o programa de utilidad en lugar de un servicio?

En mi opinión, no merece la pena considerar esta funcionalidad como un servicio. Y es que en ocasiones caemos en el exceso de considerar que todos son servicios cuando en realidad son los procedimientos, método o rutinas de toda la vida.

Por otra parte, como es conocido, la casuística  que se puede dar en el desarrollo de una aplicación (o aplicaciones) dentro de una empresa es infinita. Si bien deberíamos huir de escenarios en los que claramente se afirma:

“este servicio sólo lo va a usar mi aplicación”

existen otros en los que sí se justifica la creación de un servicio de este tipo.

Sin ir más lejos, un posible ejemplo sería el siguiente. La aplicación necesita cierta funcionalidad que por estar hecha en una tecnología antigua no es posible implementar. En este caso, se necesita insertar un documento en un gestor de contenidos corporativo que no proporciona el API necesario para el lenguaje en la que está construida la aplicación. En este caso estaría justificado la creación del servicio gracias  a que precisamente por ser un servicio, está desacoplado. Es decir, el servicio web sí que podría usar el API de acceso al gestor de contenidos por estar implementado de cero con una tecnología nueva. La aplicación, que sí deberá tener soporte para web services, podría invocar a este nuevo servicio mediante un mensaje SOAP proporcionando de esta manera la funcionalidad que necesita.

Comparte este artículo…

Share

Anuncios