Seguimos con la segunda parte del artículo (ver primera parte).

Pero… ¿qué es un servicio?

Actualmente todo el mundo maneja el concepto de servicio, aunque tal vez cada uno de nosotros tenga su propia idea de su significado. Por ello sería conveniente encontrar una definición sencilla, fácilmente entendible por personas no técnicas y que no tenga ambigüedad. Aunque lamentablemente, no es tan fácil conseguir esto.

La definición más sencilla podría ser: “programa que hace algo útil para el negocio”. Esto es, responde a una necesidad de negocio y tiene sentido para él. Un servicio podría ser “reservar billete de avión” para una agencia de viajes o “realizar transferencia” para un banco. Es por tanto, la implementación de una funcionalidad bien definida y que tiene la característica de que puede ser combinado con otros servicios para formar uno más complejo y de más valor añadido. Por ejemplo, en la misma agencia de viajes podríamos tener el servicio “reservar escapada fin de semana”, este servicio a su vez podría usar el servicio de “reservar billete de avión” y el de “reservar hotel”. Con la combinación de estos dos servicios ya existentes hemos creado uno nuevo, de más valor añadido y sin ni siquiera programarlo. Esta reutilización y combinación de servicios (o composición) es la esencia de un nuevo paradigma de diseño de aplicaciones, la Arquitectura Orientada a Servicios (SOA) que veremos más adelante.

La consultora Gartner ha definido lo que se conocen como los cinco principios de un servicio, principios que tiene que cumplir para ser considerado como tal. De manera breve son los siguientes:

  1. Modular: el servicio tiene que tener un cometido y solo uno. Es decir, si reserva billetes de avión no puede también realizar la nómina de los empleados. Este servicio además debe tener la mínima dependencia del resto posible. Cuanto menos dependencia (acoplamiento) tenga, más fácil será de cambiar sin afectar a nada más.
  2. Distribuible. El servicio, como programa informático que es, debe ejecutarse en un ordenador con un software adecuado (por ejemplo el sistema operativo). Si es distribuible, éste puede ejecutarse en cualquier máquina de manera transparente para el que lo usa. Esto da una tremenda flexibilidad para la gestión de los recursos técnicos de la T.I.
  3. Claramente definido. Debe tener explícitamente definido su “contrato”, esto es, sus parámetros de entrada y de salida. Como todo contrato debe mantenerse en el tiempo.
  4. Intercambiable. Esto quiere decir que un futuro, se puede cambiar el servicio por otro. Quizás compremos en el futuro un paquete comercial de reserva de aviones y queramos sustituir nuestro antiguo servicio. Pues bien, esto debe hacerse de la misma manera que se cambia la rueda de un coche, se quita una y se pone otra.
  5. Compartible. El servicio debe poder usarse por todo tipo de aplicaciones e incluso por otras organizaciones o clientes.

Ya sé lo que es un servicio… pero ¿qué es SOA?

Una vez que tenemos una noción de lo que es un servicio, nos encontramos que SOA, al igual que éste, tiene muchas definiciones (cada uno tiene la suya). Para centrarnos, entre todas estas definiciones existentes, quizás nos podríamos quedar con estas tres:

  1. Principio de diseño de software que “define la utilización de servicios para dar soporte a los requisitos de negocio” (Wikipedia)
  2. Diseño de aplicaciones basadas en servicios que encapsulan piezas de software de negocio usadas en la web para coordinar procesos de negocio de empresa (Mary E. Shacklett)
  3. Forma de diseñar aplicaciones que consiste en juntar servicios según tus necesidades. El objetivo no es programar nuevos servicios si no “componer” nuevos servicios basándose en otros más básicos ya programados (dicSOAnario del blog “Pensando en T.I.”)

Una vez aclarado qué es SOA, nos queda la pregunta más importante que se debe hacer la organización:

¿Qué beneficio saco yo de SOA? ¿Cuál es mi retorno de inversión?.

Las respuestas serían las siguientes:

  1. SOA promete un ahorro de costes en el desarrollo de aplicaciones de negocio. ¿Cómo? Pues basándose en la reutilización de servicios ya existentes para implementar nuevos servicios de negocio de más alto nivel y mayor valor añadido
  2. SOA promete mayor flexibilidad y menor time to market. Si el modelo SOA está maduro en la organización, llega un momento en que prácticamente no se desarrolla nada nuevo, ya que se crean nuevos servicios a partir de otros ya existentes. En lugar de programar aplicaciones, se componen aplicaciones.

Evidentemente lograr estos dos objetivos no es tarea fácil. Si no se hace bien, la adopción de SOA en una organización puede convertirse en un proyecto fallido que incremente los costes y tiempos en lugar de disminuirlos

Continuará…

Comparte esta entrada…

Share

Anuncios