¿Cómo identificar los servicios de negocio en SOA?

¿Cómo identificar los servicios de negocio en SOA?

Publicado el 18/04/2010| 4 comentarios

En varias entradas de este blog se ha abordado el tema de los principios de SOA, los 5 principios de Gartner, lo que no se debe hacer en SOA, etc. Sin embargo, tal vez todas estas entradas se quedan un poco en el terreno de la teoría. Es por eso que en esta, se intentará aplicar estos principios sobre un ejemplo práctico. Un ejemplo, por supuesto enormemente simplificado, que define la funcionalidad necesaria para una Agencia de Viajes.

La funcionalidad de negocio necesaria sería la siguiente:

 Un paquete de viaje sería todo lo necesario para que un turista pueda llevar a cabo sus vacaciones: billetes de avión, estancia en hotel y coche de alquiler.

 Cada oficina de la agencia ejecuta un programa cliente que necesita esta funcionalidad de la aplicación de reservas de la organización.

 Además de las oficinas de la empresa, también se debe dar servicio a una cadena de hipermercados que vende nuestros viajes con su marca, aunque en este caso no se ofrecen los coches de alquiler.

Con estos sencillos requisitos vamos a ver qué servicios de negocio se identifican. Como primer aproximación podría bastar con un único servicio:

 reservar: un único servicio que da soporte a toda la funcionalidad requerida. Permite reservar el servicio que queramos (avión, hotel, coche…)

 parámetros de entrada: una estructura de información genérica en la que se puede indicar los hoteles requeridos, los viajes de avión, los coches de alquiler. Esta estructura consistirá en una lista de pares de datos del tipo “nombre”, “valor”.

 parámetros de salida: una lista de confirmaciones de todas las reservas que forman el paquete

Si examinamos este servicio siguiendo los principios anteriormente referidos, nos encontramos lo siguiente:

 sentido para el negocio. El servicio “reservar” es demasiado genérico. Al menos debería tener un “apellido”, un sustantivo que definiese algo mejor la funcionalidad que va a proporcionar. De cara al negocio, nuestra empresa “reserva hoteles”, “vende billetes de avión” o “gestiona el alquiler de coches”. El servicio “reservar” es demasiado genérico.

 no es modular. No tiene cohesión interna ya que se dedica a cosas muy dispares. No tiene nada que ver reservar un avión con reservar un coche de alquiler.

Por otra parte, tampoco logra un mínimo acoplamiento con sus clientes, ya que el mensaje de entrada hace referencia a una estructura común para todos los servicios. Esto añade dependencias que no son necesarias. Por ejemplo, un cambio en la forma de reservar el coche de alquiler puede afectar a los clientes que no usan esta funcionalidad pero se ven afectados porque usan el mismo servico

 no tiene el interfaz claramente definido. Al ser una estructura genérica para todas las funcionalidades no es posible indicar el tipo del parámetro de entrada. Por ejemplo, para el billete de avión necesitamos el parámetro “clase” del tipo “turista, business, primera” sin embargo tendremos que mandar un parámetro del tipo “nombre = tipo” y “valor = turista”.

Al no estar el parámetro definido no es posible realizar validaciones automáticas de formato o del valor que puede llevar (en este caso es un tipo enumerado con tres posibles valores). Además no puede se descrito en el fichero WSDL (en el caso de que sea un web services), es decir, no es posible identificar automáticamente el tipo de este campo. En su lugar, será necesario proporcionar información adicional para que el programador del cliente pueda usarlo (lo normal sería enviar un documento word que acompañe al descriptor del servicio). En realidad, el descriptor del servicio, describe más bien poco.

 seguridad: al ser un único servicio no se puede limitar el acceso a diferentes clientes. Por ejemplo, necesitamos que nuestra red de oficinas puede invocar las tres funcionalidades (aviones, hoteles y coches de alquiler) mientras que nuestro socio (el hipermercado) no debería poder invocar al alquiler de coches.

Como sólo tenemos un servicio, no es posible lograr este nivel de autorización con los estándares de seguridad declarativa (por ejemplo en JEE) teniendo que programar una solución ad-hoc para controlar el acceso de manera programática.

 distribuible. Si bien el servicio “reservar” se puede implementar como un servicio web y por lo tanto es distribuible,

...