Ejemplo de Identificación de Servicios Funcionales

Ejemplo de Identificación de Servicios Funcionales en una aplicación de Seguros

Un ejemplo muy simplificado, que define la funcionalidad necesaria para realizar una consulta de Póliza, una consulta de Siniestros y una consulta de Recibos.

Funcionalidad requerida para la aplicación de seguros

• Habrá pólizas, habrá siniestros y habrá recibos.
• Habrá identificadores y datos diferentes para la póliza, para el siniestro y para el recibo.
• Tendremos nuestra red de oficinas y una entidad financiera como socio. Esta entidad financiera utilizará la Consulta de Póliza y Consulta de Recibo como ayuda en la toma de decisiones de cara a los créditos que conceden.

Primera aproximación para la aplicación de seguros

Como primera aproximación podría bastar con un único servicio:

• Consultar. Un único servicio que da soporte a toda la funcionalidad requerida. Permite consultar pólizas, siniestros y recibos.
  • Parámetros de entrada: Qué se desea consultar y el Identificador de lo que se desea consultar,
  • Parámetros de salida: Conjunto de datos que dependerá de lo que se ha decidido consultar.

Análisis de la primera aproximación para la aplicación de seguros

Si examinamos este servicio siguiendo los principios de identificación de servicios SOA, encontraremos lo siguiente:

• Sentido para el negocio: El servicio “consultar” es demasiado genérico, pero sí puede tener sentido para el negocio. Realmente en este caso, debería haber tres servicios:
  • Consultar Póliza.
  • Consultar Siniestro.
  • Consultar Recibo.
• No es modular. La funcionalidad de consultar una póliza puede ser semejante a consultar un recibo, pero los datos son distintos.

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 consulta de póliza puede afectar a los clientes que no usan esta funcionalidad pero que usan el mismo servicio.

• No tiene el interfaz claramente definido. En el caso que se ha planteado, el parámetro de entrada es común, pero podríamos plantear otros tipos de consultas en los que como parámetro de entrada tuviéramos datos específicos dependiendo de la póliza, con lo que en ese caso, el interfaz debería ser específico.
• Seguridad. Al ser un único servicio no se puede limitar el acceso a diferentes clientes. Por ejemplo, necesitamos que nuestra red de oficinas pueda invocar las tres funcionalidades (consulta de Póliza, Siniestro, Recibo), mientras que nuestro socio (entidad financiera) no debería poder invocar a la consulta de Siniestro.

Cómo solo tenemos un servicio, no es posible lograr este nivel de autorización con los estándares de seguridad declarativa, teniendo que programar una solución ad-hoc para controlar el acceso de manera programática.

• Distribuible. Si bien el servicio “consultar” se puede implementar como un servicio web y por lo tanto es distribuible, no tiene toda la flexibilidad que nos podría aportar otro tipo de implementación. Es posible, por ejemplo, que la consulta de pólizas sea mucho mayor que la consulta de siniestros. Si en lugar de un solo servicio fuesen tres, se podría desplegar el servicio más demandado en una máquina más potente o en un mayor número de máquinas que el resto de servicios, logrando una mayor eficiencia y calidad de servicio de nuestra infraestructura.
• No es intercambiable. Al tener un solo servicio con un contrato poco definido nos impactaría mucho un posible cambio. Por ejemplo, en un hipotético caso, nuestra compañía compra un software estándar para la gestión de pólizas. Con una verdadera orientación a servicio, en el que las tres funcionalidades no estuviesen en el mismo servicio, sería sencillo cambiar el servicio de consultar póliza por este paquete comercial. Sin embargo, con esta implementación es muy difícil teniendo un impacto importante en el resto de funcionalidades que proporciona la empresa, estando expuestos a errores y pérdida de servicio. En realidad, un cambio en el servicio de consultar siniestro no tendría que afectar a la Entidad Financiera ya que no usa este servicio, pero no es así.
• No es compartible. Imaginémonos que nuestra organización llega a un acuerdo económico con otra empresa para proporcionarle pólizas. Esta nueva empresa tendrá que implementar la invocación a nuestro único servicio, teniendo que lidiar con parámetros (los de consultar siniestro y consultar recibo) que en realidad no le interesa para nada. Tal vez, en este caso, habría que decirle: tienes que mandarme 50 parámetros pero 40 tienen que venir vacios ya que no te hacen falta.

Aproximación definitiva para la aplicación de seguros

Teniendo en cuenta el análisis anterior y el sentido común, los servicios de negocio que se deberían implementar en la empresa del ejemplo, son:

• ConsultarPoliza: Un servicio que da soporte a la funcionalidad requerida para la consulta de pólizas.
• ConsultarSiniestro: Un servicio que da soporte a la funcionalidad requerida para la consulta de siniestros.
• ConsultarRecibo: Un servicio que da soporte a la funcionalidad requerida para la consulta de recibos.

Análisis de la aproximación definitiva de la aplicación de seguros

A diferencia respecto de la aproximación de un solo servicio, con el planteamiento de tres servicios:

• Sí tiene sentido para el negocio.
• Es modular, tiene cohesión (cada servicio se dedica a una cosa) y expone al consumidor únicamente la información que necesita (bajo acoplamiento).
• Cada uno de los servicios tiene el interfaz (el contrato con el cliente) claramente definido.
• Se puede securizar de manera independiente. Por seguridad declarativa se puede impedir el acceso desde la entidad financiera a la consulta de pólizas de auto.
• Es distribuible. Cada servicio se puede desplegar en una máquina diferente.
• Se puede sustituir un servicio por otra implementación sin afectar al resto.
• Lo puede invocar cualquier aplicación dentro o fuera de la organización.
• Se puede fácilmente construir (componer) un nuevo servicio más complejo a partir de los servicios anteriores.