Comunicar de forma asincrónica con servicios web XML

Artículo
10/07/2008

En la comunicación de forma asincrónica con un servicio web se siguen los dos modelos de diseño de invocación de métodos asincrónicos especificados por .NET Framework. Sin embargo, antes de llegar a esos detalles, es importante tener en cuenta que no tiene que escribirse específicamente un servicio web para administrar solicitudes asincrónicas que se van a llamar de forma asincrónica.

Wsdl.exe y el modelo de diseño asincrónico de .NET Framework

Cuando la herramienta Lenguaje de descripción de servicios web (Wsdl.exe) genera una clase de proxy cliente para tener acceso a un servicio web especificado, proporciona dos mecanismos a la clase de proxy para comunicarse de forma asincrónica con cada método de servicio web. El primer mecanismo es el modelo Begin/End. El segundo mecanismo es el modelo de programación asincrónico orientado a eventos disponible en la versión 2.0 de .NET Framework. Para obtener una breve descripción del uso de los modelos con servicios web, consulte las secciones siguientes. Para obtener detalles completos sobre los dos modelos, consulte Asynchronous Programming Design Patterns.

El modelo de invocación Begin/End

Wsdl.exe crea automáticamente tres métodos para cada operación (un método de servicio web en ASP.NET) publicada en el servicio web. Un método es para el acceso sincrónico; los otros dos son para el acceso asincrónico. Esto es cierto aun cuando sólo se trate de una implementación sincrónica del método de servicio web. En la tabla siguiente se describen los tres métodos.

Nombre de método en clase de proxy	Descripción
<NameOfWebServiceMethod>	Envía sincrónicamente un mensaje para el método de servicio web denominado <NameOfWebServiceMethod>.
Begin<NameOfWebServiceMethod>	Comienza la comunicación asincrónica del mensaje con un método de servicio web denominado <NameOfWebServiceMethod>. El cliente indica al método Begin que inicie el procesamiento de la llamada del servicio, pero que vuelva inmediatamente. El valor devuelto no es el tipo de datos especificado por el método de servicio web, sino un tipo que implementa la interfaz IAsyncResult.
End<NameOfWebServiceMethod>	Finaliza una comunicación asincrónica del mensaje con un método de servicio web denominado <NameOfWebServiceMethod>, devolviendo un valor que es el resultado de la llamada del método de servicio web.

Los métodos Begin y End siguen la nomenclatura del modelo de diseño asincrónico de .NET Framework. El modelo de diseño indica que existen dos métodos asincrónicos con nombre para cada método sincrónico.

Para ver un ejemplo, considere una clase de servicio web PrimeFactorizer que tiene un método de servicio web que busca los factores primos, con la firma siguiente:

public long[] Factorize(long factorizableNum)

Este tipo de método podría tardar en procesarse un tiempo relativamente largo, dependiendo de la entrada. Por tanto, es un buen ejemplo de cuándo debe hacer que su cliente de servicios web llame al método de servicio web de forma asincrónica.

Si Wsdl.exe usó este servicio web como entrada para generar el proxy de cliente, codifique (usando la cadena de consulta ?wsdl para un servicio web ASP.NET), generaría los métodos con las firmas siguientes:

public long[] Factorize(long factorizableNum)
public System.IAsyncResult BeginFactorize(long factorizableNum, System.AsyncCallback callback, object asyncState)
public long[] EndFactorize(System.IAsyncResult asyncResult)

Implementar un cliente de servicios web que realiza una llamada al método asincrónico mediante el modelo Begin/End

¿Cómo sabe un cliente cuándo llamar al método End ? Hay dos técnicas para implementar un cliente con el fin de determinar esto, como se define en .NET Framework:

la técnica de espera: usa uno de los métodos de la clase WaitHandle para hacer que un cliente espere a que el método finalice.
la técnica de devolución de llamada: pasa una función de devolución de llamada al método Begin, al que se llama más tarde para recuperar los resultados cuando el método ha terminado de procesarse.

Nota: independientemente de las dos técnicas con las que un cliente decida comunicarse de forma asincrónica con un servicio web, los mensajes SOAP enviados y recibidos son idénticos a los mensajes SOAP generados a través del método de proxy sincrónico. Es decir, todavía existe sólo una solicitud y respuesta SOAP enviada y recibida por la red. La clase de proxy lo consigue administrando la respuesta SOAP mediante un subproceso diferente al que usó el cliente para llamar al método Begin. Por consiguiente, el cliente puede continuar realizando otro trabajo en su subproceso, mientras que la clase de proxy administra la recepción y procesa la respuesta SOAP.

Técnica de espera con el modelo Begin/End

La clase WaitHandle implementa métodos que permiten esperar que se señalen los objetos de sincronización: WaitOne, WaitAnyy WaitAll. La señal de un objeto de sincronización es una indicación de que los subprocesos esperarán hasta el recurso especificado pueda tener acceso al recurso. El cliente de servicios web tiene acceso a un objeto WaitHandle a través de la propiedad AsyncWaitHandle del objeto IAsyncResult devuelta por el método Begin.

Para obtener un ejemplo de esta técnica, consulte Cómo: Implementar un cliente de servicio web asincrónico con la técnica de espera.

Técnica de devolución de llamada con el modelo Begin/End

Con la técnica de devolución de llamada, una función de devolución de llamada implementa el delegado AsyncCallback, que exige la firma:

public void MethodName(IAsyncResult ar)

Para obtener un ejemplo de esta técnica, consulte Cómo: Implementar un cliente de servicio web asincrónico con la técnica de devolución de llamada.

Si la devolución de llamada requiere un contexto de sincronizado/afinidad del subproceso, se envía a través de la infraestructura de distribuidor de contextos. Es decir, la devolución de llamada podría ejecutar de forma asincrónica con respecto a su llamador para tales contextos. Ésa precisamente es la semántica del calificador unidireccional en firmas de método. Eso significa que cualquier función de llamada al método podría ejecutarse de forma sincrónica o asincrónica con respecto al llamador remoto, y el llamador no podría hacer ninguna suposición sobre la realización de este tipo de llamada cuando el control de ejecución vuelva a él.

La llamada al método End antes de que la operación asincrónica haya finalizado bloqueará el llamador. El comportamiento de llamarlo una segunda vez con el mismo IAsyncResult devuelto por el método Begin es imprevisible.

Clientes de servicios web asincrónicos con el modelo asincrónico orientado a eventos

Multithreaded Programming with the Event-based Asynchronous Pattern introduce un nuevo modelo de programación asincrónica que usa eventos para administrar las devoluciones de llamadas, lo que facilita la generación de aplicaciones multiproceso sin tener que implementar complejo código multiproceso. Para obtener información general del nuevo modelo asincrónico orientado a eventos, consulte Event-based Asynchronous Pattern Overview. Para obtener detalles sobre las implementaciones de cliente con el nuevo modelo, consulte How to: Implement a Client of the Event-based Asynchronous Pattern.

Para ver cómo se genera un servicio web con el modelo orientado a eventos, consulte Cómo: Implementar un cliente de servicios web asincrónico orientado a eventos con ASP.NET 2.0.

Consulte también

Compartir a través de

Comunicar de forma asincrónica con servicios web XML

Wsdl.exe y el modelo de diseño asincrónico de .NET Framework

El modelo de invocación Begin/End

Implementar un cliente de servicios web que realiza una llamada al método asincrónico mediante el modelo Begin/End

Técnica de espera con el modelo Begin/End

Técnica de devolución de llamada con el modelo Begin/End

Clientes de servicios web asincrónicos con el modelo asincrónico orientado a eventos

Consulte también

Tareas

Conceptos

Otros recursos

Recursos adicionales