Para todos aquellos que estamos mas alla del speech marketinero de que la “integracion de web services” es algo simple y feliz, quiero plantear la discusión sobre: Qué es lo que pasa con las trasacciones en este contexto?
Si bien muchas veces, adoptar el uso de Web Services es la opción mas viable a la hora de integrar los tan diversos componentes de negocios. Tenemos que tener noción de una gran falencia en esta tecnología, las transacciones.
Parecería ser que muchos acostumbrados al mundo de los EJB, familiarizados con conceptos como: CMT (Container Managed Transactions) o User Transactions, que olvidan la importancia de las transacciones a la hora de migrar funcionalidad a Web Services.
Ahora bien…volvamos un poco a las bases:
Caracteristicas de una Transacción
- Atomicidad (Atomicity): Todos los participantes de la transaccion deben “confimar” o “cancelar”.
- Cosistencia (Consistency): Se obtiene un resultado consistente.
- Aislamiento (Isolation): No hay percepción de cambios hasta que todos los participantes hayan “confirmado” o “cancelado”.
- Durabilidad (Durability): Los cambios producidos por la transacción deben ser persistidos.
Viendo la definición nos damos cuenta que las operaciones entre WS distan mucho en su naturaleza de ser transacciones “per se”.
Caso Práctico
De que estoy hablando? Bueno, supongamos estos casos:
“Se dispone de un sistema de stock, un online-store y un sistema de pagos-online, los tres implementados con web services. El online-store actua como integrador entre el sistemas de pagos-online y el sistema de stock.
Caso 1: Si se ingresa un pedido, y el online-store realiza una baja de item en el sistema de stock y luego intenta realizar el pago-online el cual falla. Hay una inconsistencia en el sistema de Stock (falla el aislamiento y consistencia).
Caso 2: Si se ingresa un pedido, y el online-store realiza el pago pero resulta que no hay stock (falla la consistencia y aislamiento) ”
Si bien es debatible que es lo que falla en cada una las actividades del ejemplo, la realidad es que no se llega el resultado esperado. Para salvar estos inconvenientes la solución más común, es implementar lo que se denominan “Transacciones de Compensación“, lo cual basicamente es desarrollar rutinas para el manejo de errores que busquen deshacer los cambios realizados a partir de nuevas transacciones. Con lo cual no hace falta tener 2 dedos de frente para notar que algo no cierra en este enfoque.
Ejemplo:
“Caso 1: Se genera una transacción de compensación que vuelva el stock al valor correcto.
Caso 2: Se genera una transacción de acreditación de dinero para compensar el debito anterior.”
Conclusión: las transacciones de compensación, son soluciones de negocio a problemas de infraestructura tecnologíca.
Entonces…
El debate que busco plantear es sobre las WSTx:
- WS-Coordination
- WS-AtomicTransaction
- WS-BusinessActivity
Las cuales son un set de especificaciones para anotaciones XML, que permitan el uso de protocolos estandar, abiertos y seguros para transacciones a travez de la Web.
A grandes terminos los escenarios al cual estan enfocados son:
- Transacciones atomicas individuales que representa bloques logicos para transacciones complejas entre pares.
- Interacciones de soluciones Web que resultan actividades de negocio (intercambio de bienes, informacion, servicios, etc)
En resumen, el uso de WSTx puede llegar a ser la solución al manejo de transacciones en Web Services, asi como tambien ser uno de los tantos estandar que quedan en la nada debido a su complejida o falta de integración entre implementaciones.
La realidad es que su uso y aceptacion en el mercado, lo definiran. Por lo pronto voy a empezar a trabajar en algunos ejemplos para ver sus pros y contras.
Slds.
