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:

1. Transacciones atomicas individuales que representa bloques logicos para transacciones complejas entre pares.
2. 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.

Para hacerla corta y no andar con teoria, hacer lo siguiente:

1. Abrir Terminal 
   Macintosh HD -> Applications -> Utilities -> Terminal
2. Correr los scripts de mantenimiento:

$ sudo periodic daily weekly monthly  

Que es lo que acabamos de hacer?

Mac OS X viene con scripts de mantenimiento, cuya funcionalidad esta discriminada por la necesidad de ser ejecutados en un determinado periodo de tiempo. Es decir:

• daily: Realiza limpieza de logs. Remueve los archivos log viejos, “scratch” y “junk”, realiza backs-ups de la NetInfo DB, etc.
   
• weekly: Rebuilds de las bases locate y whatis. Rotacion de logs:
  ftp.log
  lookupd.log
  lpr.log
  mail.log
  netinfo.log
  ipfw.log
  secure.log

• monthly:  Reporta por uso de cuentas. Rotacion de logs:
  wtmp.install.log
  cu.modem.log

Si queremos ver cuando se ejecutaron por ultima vez estos logs:

$ ls -l /var/log/*out

Para cambiar los valores por defecto de cada cuanto se corren estas acciones podemos modificar dentro /System/Library/LaunchDaemons los siguientes archivos para cada script:

• daily -> com.apple.periodic-daily.plist
• weekly -> com.apple.periodic-weekly.plist
• monthly -> com.apple.periodic-monthly.plist