2009-01-12 9 views
14

Dado un ejemplo de invocación de dos métodos de servicios web desde un bean de sesión, ¿qué pasa 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.Servicios web y retrotracción de transacciones

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

Respuesta

15

Varias técnicas están evolucionando, pero el problema sigue siendo lo suficientemente innovador 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 conciente. 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 el problema es: cómo vincular la transacción EJB (es decir, JTA/XA) ​​con la de 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 - consulte http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/txbridge/BOF-4182.odp

Tenga en cuenta que la técnica de puenteo de protocolo también se puede utilizar a la inversa, para permitir que un EJB que utiliza p. Ej. un backend de base de datos XA, para ser expuesto 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 ver 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 revisarlo si elige este enfoque: http://www.jboss.org/jbosstm/baframework

+0

Afortunadamente utilizamos JBoss, así que estoy inclinado hacia las soluciones que proponemos, en especial el último eslabón. – atas

+0

hola a todos, esta respuesta ahora tiene 5 años y dice "JSR-156 aún no está listo". ¿Hay alguna actualización de esto? ¿Existe ahora un estándar para manejar las transacciones con los servicios web de soap? gracias de antemano – jambriz

6

Se utilizan las especificaciones de WS-C y Web Services-Transaction (WS-T) desarrolladas por Microsoft, BEA Systems e IBM en casos tales como yo sé. Puede comenzar leyendo los artículos Web services transactions y A comparison of Web services transaction protocols proporcionados por IBM para dejarlo en claro.

+1

Ninguno de los enlaces que proporcionó trabajo por más tiempo. No es sorprendente ya que publicó esto hace 8 años :) – Darcy

2

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

Solo echa un vistazo a http://www.atomikos.com/Publications/TryCancelConfirm para un artículo detallado. Las características mencionadas están disponibles en Atomikos ExtremeTransactions ... Ese producto también es compatible con las transacciones clásicas del servicio web de estilo 'ACID'.

HTH

individuo

responsabilidad: yo trabajo para atomikos

Cuestiones relacionadas