paypal credit card

Según la muy exigente normativa DSI PSS (Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago), para que una empresa pueda almacenar o incluso únicamente procesar tarjetas de crédito, incluso sin guardarla en ningún momento, tiene que cumplir una serie de requisitos bastante difíciles de implementar.

Una de las más importantes, y la que más consecuencias tiene es que todos los sistemas que estén en la misma red que el que procesa la petición de la tarjeta tienen que cumplir con la misma normativa. Es decir, si en la misma red que la aplicación de pago con tarjeta, tenemos otras 100 aplicaciones (con sus correspondientes middleware y base datos).

Es fácil de imaginar que es lo que pasaría en la informática de una empresa si una aplicación de negocio, digamos que tradicional, tiene que integrar los pagos con tarjeta. Como esta aplicación seguramente estaría muy acoplada con el resto de aplicaciones de la empresa, no encontraríamos con la clásica bola de espagueti con decenas o cientos de llamadas entre ellas que nos daría como resultado que toda las aplicaciones de la empresa deben cumplir con la normativa que comentan al principio. Fácilmente, esto podría representar un proyecto de muchos meses, años siendo realistas, con un coste difícil de justificar (si no imposible) ante negocio.

¿Donde nos puede ayudar SOA con esto?. La respuesta es bastante inmediata: siguiendo los principios de desacoplamiento e independencia de la localización física del servicio podemos reducir la complejidad y coste de forma muy, pero que muy, significativa.

Desacoplamiento:

Mediante este principio, como ya sabemos, las aplicaciones o más bien los servicios están muy débilmente acoplados con los otros servicios que forman la solución de negocio. El único acoplamiento que existe es el contrato entre los mismos.

Independencia de la localización física del servicio:

Un servicio debe ser independiente de la localización física donde se ejecute. Por eso, el consumidor de ese servicio no debe saber dónde está el servicio a la hora de invocarlo. Es por eso que existe la figura del registro de servicios, un índice al que el consumidor acude para localizar el endpoint (dirección física del servicio) donde tiene que invocar.

Sumando estas dos cosas, podemos integrar fácilmente la funcionalidad de pago con tarjeta, con arreglo a esta exigente normativa con el mínimo esfuerzo y coste posible.

Por un lado, si es necesario, el servicio de pago con tarjet, se puede desplegar (él sólo incluso) en una red diferente a el resto de servicios de la empresa.

Por otro lado, los clientes sólo tienen que invocar al servicio de pago (y ni siquiera sabrán donde está)

pagar con tarjeta

Conclusión

Como vemos, si tenemos en cuenta mínimamente los principios sobre los que se asienta SOA, la solución aquí expuesta es poco más que una obviedad. Sin embargo, como he dicho en post anteriores, en la mayoría de las veces, para el éxito de SOA, debemos tener en cuenta dos puntos relativamente sencillos:

  1. Con los principios más sencillos, aplicándolos con criterio, tenemos la solución a muchos de los problemas que se nos pueden plantear (ver la regla del 20%).
  2. La mayor dificultad que tiene SOA es la de convencer a la gente. Me temo que indicar esta solución por parte del arquitecto SOA es bastante más sencillo que lograr que esto se implemente en la realidad (y no me estoy refiriendo a problemas técnicos).