Soporte de transacción atómica de servicios web (WS-AT) en el servidor de aplicaciones

El soporte de transacción atómica de servicios web (WS-AT) del servidor de aplicaciones proporciona un servicio de transacciones de calidad para los entornos de servicios web. Las aplicaciones de servicios web distribuidas, así como los recursos que utilizan, pueden tomar parte en las transacciones globales distribuidas.

Los protocolos de servicios web proporcionan modos estándares de definir las aplicaciones de servicios web, permitiendo que las aplicaciones funcionen independientemente del producto, plataforma o lenguaje de programación utilizados. El soporte WS-AT es una implementación de las especificaciones siguientes en el servidor de aplicaciones. Estas especificaciones definen un conjunto de servicios web que permiten a las aplicaciones participar en transacciones globales que se distribuyen en el entorno heterogéneo de los servicios web.

El soporte WS-AT es soporte para un protocolo de interoperatividad que no presenta interfaces de programación nuevas para el soporte de transacciones. El uso de aplicaciones empresariales estándar de la interfaz JTA (Java™ Transaction API) UserTransaction proporciona la demarcación de transacciones globales. Si un componente de aplicación que se ejecuta en una transacción global realiza una solicitud de servicios web, se propaga un WS-AT CoordinationContext de forma implícita al servicio web de destino, pero sólo si se han establecido los descriptores de despliegue de aplicaciones apropiados, tal como se describe en el tema que trata sobre la configuración de atributos de despliegue de transacciones.

Si el servidor de aplicaciones es el sistema que alberga el punto final de destino de una solicitud de servicios web que contiene un WST-AT CoordinationContext, el servidor de aplicaciones establece de forma automática una transacción JTA subordinada en el entorno de tiempo de ejecución de destino que pasa a ser el contexto transaccional con el que se ejecuta la aplicación de servicios web de destino.

En la siguiente figura se muestra un contexto de transacción compartido entre dos servidores de aplicaciones para una solicitud de servicios web que contiene un WS-AT CoordinationContext.

Figura 1. Contexto de transacción compartido entre dos servidores de aplicaciones
La transacción atómica incluye el cliente de servicio web y sus recursos XA en el servidor de aplicaciones 1 y la aplicación de servicio web y sus recursos XA en el servidor de aplicaciones 2.
[z/OS]transition: Ya no necesita crear nuevas cadenas de transporte de contenedor web para utilizar el soporte de WS-AT. El servidor de aplicaciones ya está configurado para habilitar WS-AT y no es necesaria una configuración adicional.

Puede configurar las políticas para el protocolo WS-AtomicTransaction. Puede configurar si un cliente propaga mientras que un servidor recibe un contexto WS-AT. Para asegurarse de que un cliente siempre envía un contexto WS-AtomicTransaction al realizar una solicitud saliente de servicio, debe asociar un conjunto de políticas con el cliente, donde el conjunto de políticas debe incluir el tipo de política WS-Transaction, y este tipo de política debe tener un valor WS-AtomicTransaction de Obligatorio. Si sabe que el cliente siempre invoca puntos finales remotos que incluyan el atributo de tipo de política ATAssertion de WS-AtomicTransaction, también puede configurar el cliente para que aplique la configuración WS-Policy del proveedor para que el cliente adopte automáticamente la política obligatoria del proveedor.

Para asegurarse de que las solicitudes recibidas por un proveedor de servicios web incluyan un contexto WS-AtomicTransaction, debe asociar un conjunto de políticas con el proveedor, donde el conjunto de políticas debe incluir el tipo de política WS-Transaction, y este tipo de política debe tener un valor WS-AtomicTransaction de Obligatorio.

Para asegurarse de que un cliente o proveedor nunca utiliza un contexto WS-AtomicTransaction, debe asociar un conjunto de políticas con el cliente o proveedor, donde el conjunto de políticas incluya el tipo de política WS-Transaction, y este tipo de política debe tener un valor WS-AtomicTransaction de Nunca. Puede utilizar esta configuración para entornos en los que no desea que las solicitudes de servicios web creen un acoplamiento fuerte entre un cliente y un proveedor, por ejemplo cuando hay solicitudes entre empresas.

Si no hay ningún conjunto de políticas asociado con un cliente o proveedor, o bien si el tipo de política WS-Transaction no se incluye en el conjunto de políticas, se utiliza el comportamiento predeterminado de WS-Transaction.

Restricciones del soporte WS-AT

En esta versión del servidor de aplicaciones, los contextos WS-AT no se pueden iniciar desde un proceso de cliente no recuperable.

[z/OS]Las solicitudes de trabajo de la misma transacción WS-AT que se envían a un clúster de servidores no tienen garantizada su asignación al mismo miembro del clúster cada vez. En estos casos, el trabajo de una transacción puede estar gestionado por varios miembros del clúster. Si el trabajo transaccional de varios miembros del clúster necesita el mismo recurso transaccional, se puede producir un punto muerto.

El diseño de la aplicación

WS-AT es un protocolo de transacciones de compromiso de dos fases y está indicado únicamente para transacciones de corta duración.

Una transacción atómica coordina gestores de recursos que aíslan actualizaciones de transacciones manteniendo bloqueos de transacciones en los recursos. Por tanto, generalmente no se recomienda distribuir transacciones WS-AT en dominios de empresa. Las transacciones entre empresas requieren normalmente una semántica menos estricta que las de compromiso de dos fases y, en estos casos, puede ser más adecuado utilizar una transacción de empresa de compensación, por ejemplo como parte de un proceso BPEL (Business Process Execution Language) o utilizando WS-BA (Web Services Business Activity).

WS-AT es más adecuado para distribuir el contexto de transacción entre los servicios web desplegados dentro de una sola empresa. Los únicos que transportan el contexto de transacción son los patrones de intercambio de mensajes de solicitud-respuesta, porque el originador (la aplicación o el contenedor) de una transacción tiene que estar seguro de que hayan finalizado todas las tareas empresariales que se ejecutan en esa transacción antes de solicitar la finalización de una transacción. Los servicios web invocados por una solicitud en un único sentido nunca se ejecutan en la transacción del cliente solicitante.

El efecto de las anomalías de servicio en las transacciones WS-AT es similar al efecto de las excepciones de aplicaciones EJB (Enterprise JavaBeans) en las transacciones, como se describe en la especificación EJB. Si un servicio que se ejecuta bajo la transacción WS-AT de solicitante devuelve un error, el servidor de aplicaciones no marca automáticamente la transacción como de sólo retrotracción. El manejador de excepciones del solicitante decide si la transacción puede continuar y elige si se marca la transacción como de sólo retrotracción. Si el solicitante se ejecuta en el servidor de aplicaciones, pueden utilizarse las API JTA o EJB estándar para marcar la transacción como de sólo retrotracción. El componente de servicio que genera el error podría marcar por sí mismo la transacción como de sólo retrotracción antes de devolver el error. Si la implementación del componente de servicio encuentra una excepción del sistema, habitualmente permite que su contenedor maneje la excepción. Los contenedores del servidor de aplicaciones marcan automáticamente cualquier contexto de transacción recibido como de sólo retrotracción cuando manejan una excepción del sistema generada por una implementación de servicio.

Desarrollo de aplicaciones

No se necesitan tareas de desarrollo específicas para que las aplicaciones de servicios web puedan aprovechar WS-AT.

De las aplicaciones JAX-RPC, hay algunos descriptores de despliegue de aplicaciones que deben establecerse correctamente, tal como se describe en el tema sobre cómo configurar atributos de despliegue de transacción. El tiempo de ejecución JAX-RPC da soporte a WS-AT 1.0.

Para las aplicaciones JAX-WS, habilite el soporte WS-AT creando un conjunto de políticas, añada el tipo de política WS-Transaction al conjunto de políticas, configure, si lo desea, el tipo de política y adjunte el conjunto de políticas a la aplicación o el cliente que participará en la comunicación WS-AT. El tiempo de ejecución JAX-WS soporta WS-AT 1.0, WS-AT 1.1, WS-AT 1.2 y la aserción WS-Policy para WS-AT.

Si la ejecución de JAX-WS recibe una solicitud entrante, se da soporte a los niveles de especificación WS-Transaction 1.0, WS-Transaction 1.1 y WS-Transaction 1.2. Si se envía una solicitud JAX-WS saliente, sólo se puede utilizar un nivel de especificación. Si hay disponibles confirmaciones WS-Policy de WS-Transaction, ya sea del WSDL (Web Services Description Language) del servicio web de destino o del tipo de política WS-Transaction del cliente, se utiliza el nivel de especificación que se puede aplicar en el cliente y en el servicio web de destino. Por ejemplo, si el entorno de alojamiento del servicio web de destino sólo soporta WS-Transaction 1.0, se utiliza WS-AT 1.0. Si ambos niveles de especificación están disponibles o si no hay disponibles aserciones WS-Policy de WS-Transaction, se utiliza el nivel de especificación WS-Transaction predeterminado que se establece en los valores del servicio de transacciones.

El comportamiento predeterminado si no hay un conjunto de políticas efectivas o si el tipo de política WS-Transaction no se incluye en el conjunto de políticas efectivas, es el siguiente:
  • Para un cliente, si este no considera la política del proveedor, no envía ningún contexto WS-AT o WS-BA (Web Services Business Activity). Este comportamiento es equivalente a un valor de política WS-Transaction de Nunca.
  • Para un cliente, si este considera la política del proveedor, envía contexto WS-AT o WS-BA si la política del proveedor incluye confirmaciones WS-AT o WS-BA. Este comportamiento es equivalente a un valor de política WS-Transaction de Soporta.
  • Para un servidor, el servidor no recibe ningún contexto WS-AT o WS-BA. Este comportamiento es equivalente a un valor de configuración de políticas WS-Transaction de Nunca.

Los desarrolladores de aplicaciones no tienen que registrar explícitamente los participantes de WS-AT. El tiempo de ejecución del servidor de aplicaciones se hace responsable del registro de los participantes de WS-AT, de la misma forma que el registro de XAResources en la transacción JTA a la que la transacción WS-AT está federada. En el momento de completarse la transacción, todos los participantes de XAResources WS-AT se coordinan de forma atómica por el servicio de transacciones del servidor de aplicaciones.

Si una transacción JTA está activa en la hebra cuando se efectúa la solicitud de una aplicación de servicios web, la transacción se propaga en la solicitud de servicios web y se establece en el entorno de destino. Este proceso es parecido al de la distribución de contexto de transacción sobre IIOP, como se describe en la especificación de EJB. Cualquier tarea de transacciones realizada en el entorno de destino pasa a formar parte de la misma transacción global.

Aserciones de política WS-Transaction

Si configura las políticas del protocolo WS-Transaction para un protocolo, esta configuración afecta a las confirmaciones incluidas en cualquier WSDL generado para el servicio web con el que está asociado el tipo de política. La aserción WS-Policy que se utiliza para describir los requisitos transaccionales de un cliente o proveedor que utilice WS-AtomicTransaction es ATAssertion. Si el tipo de política WS-Transaction tiene un valor WS-AtomicTransaction de Obligatorio o Soporte, se incluye una aserción de política en el WSDL.

El servidor de aplicaciones también puede analizar, entender y aplicar estas confirmaciones del WSDL que analiza.

En el ejemplo siguiente se muestra WSDL donde la aserción ATAssertion de WS-AtomicTransaction indica que debe invocarse un punto final con el contexto WS-AT incluido en el mensaje de solicitud, y que el contexto esté en formato WS-Transaction 1.0 o 1.1. Hay dos espacios de nombres y dos confirmaciones; uno para cada nivel de especificación WS-Transaction, mediante el operador WS-Policy ExactlyOne para mostrar que el cliente debe elegir qué nivel de especificación desea utilizar.

<wsdl:definitions targetNamespace="bank.example.com"
     xmlns:tns="bank.example.com"
     xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
     xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
     xmlns:wsat11="http://docs.oasis-open.org/ws-tx/wsat/2006/06"
     xmlns:wsat10="http://schemas.xmlsoap.org/ws/2004/10/wsat"
     xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
     oasis-200401-wss-wssecurity-utility-1.0.xsd">
     <wsp:Policy wsu:Id="ATPolicy">
         <wsp:ExactlyOne>
             <wsat11:ATAssertion />
             <wsat10:ATAssertion />
             <!-- omitted assertions -->
         </wsp:ExactlyOne />
     </wsp:Policy>
     <!-- omitted elements -->
     <wsdl:binding name="BankBinding" type="tns:BankPortType">
          <!-- omitted elements -->
          <wsdl:operation name="TransferFunds">
               <wsp:PolicyReference URI="#ATPolicy" wsdl:required="true"/>
               <!-- omitted elements -->
          </wsdl:operation>
     </wsdl:binding>
</wsdl:definitions>

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjta_wstran
File name: cjta_wstran.html