imagen: rastreator.com

Con respecto al diseño y construcción de servicios SOA para aplicaciones de Seguros, siempre me he hecho una pregunta ¿los servicios para este sector son iguales que los otros o hay alguna particularidad que debemos tener en cuenta?Después de darle alguna vuelta, creo que podemos hablar de una idiosincrasia definida de los servicios de negocio del sector de Seguros. Y la mejor manera de definirla sería por comparación con sus “primos”, los servicios del sector de la Banca:

  1. los servicios de seguros procesan un gran número de datos mientras que los bancarios tratan relativamente pocos datos
  2. los servicios bancarios se ejecutan un gran número de veces mientras que los de seguros se ejecutan relativamente pocas veces.

Esto se puede ver de manera intuitiva si comparamos, por ejemplo, un pago con una tarjeta de crédito en un centro comercial a realizar un presupuesto (o cotización) de un seguro para un coche.
En una tarde de sábado por ejemplo, la cantidad de pagos en los comercios, a través de los datáfonos, que se dan en unos pocos minutos puede llegar a miles. Sin embargo para invocar a estos servicios se necesitan relativamente pocos datos, quizás varios códigos relativos a la tarjeta, el importe, el comercio, etc. etc.
Por otra parte, si entramos en la página web de una aseguradora a realizar un presupuesto para el seguro, y nos animamos al ver que sólo nos preguntan por el dni y la fecha de nacimiento, contemplaremos atónitos como pantalla tras pantalla se nos pregunta decenas y decenas de datos. Aunque sea por pura intuición podemos asumir entonces que este tipo de servicios se ejecutan relativamente pocas veces si lo comparamos con los pagos con tarjeta.

Teniendo esto en cuenta, voy a referirme a lo que entiendo son las características más especificas de los servicios de Seguros.

Tipo de operaciones

Lo que más abunda sin duda es el clásico mantenimiento de una entidad (al final se traduce en una tabla en una base de datos), lo que se conoce como CRUD (Create, Replace, Upadate y replace) o lo que es lo mismo, el típico alta, baja y modificación de un registro de base de datos.
Por supuesto, nunca o casi nunca es tan sencillo como ejecutar únicamente unas cuantas sentencias SQL. Existe lógica de negocio a aplicar, como por ejemplo el cálculo del precio de la póliza.
Además, aparte de las puras operaciones CRUD, una gran parte de la lógica de una aplicación de seguros se dedicará a hacer validaciones. Me refiero a que antes de “consolidar” los datos en la base de datos, se suelen hacer validaciones tales como que “el conductor tiene más de 18 años” o “te hago un descuento de 10% si tienes otros tres productos contratados”.

Datos en sesión

Para recoger los datos en muchas pantallas es necesario guardar estos datos temporales en algún sitio. Un sitio habitual es la sesión de la aplicación web. La memoria es uno de los recursos más preciosos que tiene un servidor de aplicaciones así que no se puede abusar de este tipo de almacenamiento ya que se multiplica por el número de usuarios que tienen abierta una sesión en ese momento.
Además lo normal es que el entorno de producción tenga un mecanismo de alta disponibilidad en el que se agrupan varios nodos (servidores) en un conjunto de ellos gestionados de manera centralizada (un clúster). Para prever el caso de que uno de estos nodos se caiga, la información de la sesión se replica de un nodo a otro a intervalos regulares. En un principio estos datos almacenaban en la base de datos, sin embargo, actualmente se usa la memoria para este tipo de datos con una velocidad cientos de veces superior, sin embargo, visto en conjunto es un trabajo de CPU y red considerable.Por lo tanto, el uso de la sesión debe ser el menor posible.

Documentación asociada

Es necesario una gestión documental bien definida y con suficiente potencia para poder guardar de manera eficiente millones de documentos durante años. Por ejemplo, en algunas ocasiones, en los juicios es necesario aportar documentación asociada a un siniestro después de más de 20, 25 o más años.

Nunca se borra nada

En una aplicación de Seguros nunca se borra nada. Como mucho se marcará un registro con un borrado lógico pero nunca se da de baja realmente.
La razón es que siempre se necesita saber el estado de una entidad de negocio (por ejemplo Poliza o Cliente) para una fecha dada. Es decir, responder a preguntas del tipo ¿qué cobertura tenía una poliza hace cinco años? o ¿cual era el domicilio del cliente en esa fecha?
Podemos entender una de estas entidades como algo formado por “sedimentación”. Es decir, sobre una primera información, se van añadiendo sucesivos añadidos que se van “apilando” como un estrato tras otro de información (es lo que se conoce por ejemplo un “suplemento” a una póliza). Realmente la entidad “poliza” es un marco o una “caja” donde se van guardando uno tras otro esos suplementos. Hay que tener en cuenta que una poliza puede estar viva durante decenas de años.

Después de plantear las características especificas y necesidades de los servicios SOA de seguros, el siguiente paso será proponer una posible implementación en una futura entrada en este blog. Nos vemos.

Si te ha parecido interesante, comparte esta entrada:Share

Anuncios