transactionmanagementtype transaction container cmt bean java web-services transactions ejb rollback

java - container - ejb transactions



Servicios web y retrotracción de transacciones (3)

Dado un ejemplo de invocación de dos métodos de servicios web desde un bean de sesión, ¿qué ocurre si se lanza una excepción entre las llamadas a dos métodos? En el caso de no llamar a los servicios web, la transacción se revertirá y no se dañará. Sin embargo, el servicio web no se revertirá. Por supuesto, incluso con un único servicio web, hay un problema. Si bien esta es una pregunta genérica, estoy interesado en las soluciones que tienen que ver con los beans de sesión de EJB.

Una respuesta fácil y personalizada sería agregar un "método de reversión" especial al servicio web para cada método de "funcionalidad real". Lo que estoy pidiendo es una forma estandarizada para hacerlo.

En realidad, generalmente no solo necesitas un método de reversión personalizado, sino también un método de compromiso personalizado. De lo contrario, tendrá problemas como los que se encuentran en el estándar WS-BA.

Simplemente consulte http://www.atomikos.com/Publications/TryCancelConfirm para obtener un artículo detallado. Las características mencionadas están disponibles en Atomikos ExtremeTransactions ... Ese producto también admite transacciones clásicas de servicios web de estilo ''ACID''.

HTH

Chico

Descargo de responsabilidad: trabajo para Atomikos

Varias técnicas están evolucionando, pero el problema todavía es lo suficientemente avanzado como para que el proceso de estandarización aún no nos haya proporcionado una solución totalmente portátil.

La primera opción, puede hacer que la transacción de servicios web sea consciente. Esto, por supuesto, asume que usted tiene el control sobre ellos, aunque escribir un proxy de transacción consciente para servicios no transaccionales también es una opción en algunos casos.

Los protocolos WS-AT y WS-BA son los principales estándares para servicios web transaccionales. Lamentablemente, especifican solo el protocolo, no las vinculaciones de idioma. En otras palabras, no hay una API estándar en el nivel del lenguaje de programación. Para Java, lo más cercano es JSR-156, pero aún no está listo.

Entonces surge el problema: cómo vincular la transacción EJB (es decir, JTA / XA) ​​con la WS. Dado que los modelos utilizados por los protocolos WS-AT y XA están estrechamente relacionados, esto se puede lograr mediante un puente de protocolo. Varios servidores de aplicaciones proporcionan algo solo estas líneas. JBoss presentó el suyo en JavaOne - ver http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/txbridge/BOF-4182.odp

Tenga en cuenta que la técnica de puente de protocolo también se puede usar a la inversa, para permitir que un EJB que utiliza, por ejemplo, un backend de base de datos XA, se exponga como un servicio web transaccional.

Sin embargo, el modelo de bloqueo utilizado por las transacciones de compromiso en dos fases solo es realmente adecuado para transacciones de corta duración en el mismo dominio de control. Si sus servicios se ejecutan en el mismo centro de datos de la compañía, probablemente se saldrá con la suya. Para una distribución más amplia, ya sea geográfica o administrativa, es probable que desee consultar WS-BA, un protocolo de transacciones de servicios web específicamente diseñado para dicho uso.

WS-BA utiliza un modelo basado en compensación que es más difícil de programar. Se basa esencialmente en la técnica que mencione: el efecto de los métodos de servicio se deshace llamando a un método de compensación. Puede ser complicado hacerlo bien, pero un interno de JBoss hizo un marco de anotación bastante agradable que le permite definir métodos de compensación con un mínimo esfuerzo y hacer que se accionen automáticamente. No está estandarizado, pero vale la pena consultarlo si elige este enfoque: http://www.jboss.org/jbosstm/baframework