Compartir a través de

Realización y procesamiento de llamadas asincrónicas

  • Artículo

Los objetos COM pueden admitir llamadas asincrónicas. Cuando un cliente realiza una llamada asincrónica, el control vuelve al cliente inmediatamente. Mientras el servidor procesa la llamada, el cliente es libre de realizar otro trabajo. Cuando el cliente ya no puede continuar sin los resultados de la llamada, puede obtener los resultados de la llamada en ese momento.

Por ejemplo, una solicitud de un conjunto de registros grande o complejo puede llevar mucho tiempo. Un cliente puede solicitar el conjunto de registros mediante una llamada asincrónica y, a continuación, realizar otro trabajo. Cuando el conjunto de registros está disponible, el cliente puede obtenerlo rápidamente sin bloquearlo.

Los clientes no realizan llamadas asincrónicas directamente en el objeto de servidor. En su lugar, obtienen un objeto de llamada que implementa una versión asincrónica de una interfaz sincrónica en el objeto de servidor. La interfaz asincrónica del objeto de llamada tiene un nombre del formulario AsyncInterfaceName. Por ejemplo, si un objeto de servidor implementa una interfaz sincrónica denominada IMyInterface, habrá un objeto de llamada que implemente una interfaz asincrónica denominada AsyncIMyInterface.

Nota

La compatibilidad asincrónica no está disponible para IDispatch o para interfaces que heredan IDispatch.

 

Los objetos de servidor que admiten llamadas asincrónicas implementan la interfaz ICallFactory . Esta interfaz expone un único método, CreateCall, que crea una instancia de un objeto de llamada especificado. Los clientes pueden consultar ICallFactory para determinar si un objeto admite llamadas asincrónicas.

Para cada método en una interfaz sincrónica, la interfaz asincrónica correspondiente implementa dos métodos. Estos métodos asocian los prefijos Begin_ y Finish_ al nombre del método sincrónico. Por ejemplo, si una interfaz denominada ISimpleStream tiene un método Read, la interfaz AsyncISimpleStream tendrá un Begin_Read y un método Finish_Read. Para iniciar una llamada asincrónica, el cliente llama al método Begin_.

Al implementar un objeto de servidor, no es necesario proporcionar un objeto de llamada para cada interfaz que implemente el objeto. Si el objeto de servidor implementa la interfaz ICallFactory y usa serializaciones estándar, un cliente serializado siempre puede obtener un objeto de llamada de proxy, incluso si no hay ningún objeto de llamada en el lado servidor. Este proxy serializará el método Begin_ como una llamada sincrónica, el servidor procesará la llamada de forma sincrónica y el cliente puede obtener los parámetros out llamando al método Finish_.

Por el contrario, si un cliente realiza una llamada sincrónica serialada en una interfaz para la que hay un objeto de llamada en el lado servidor, el servidor siempre procesará la llamada de forma asincrónica. Este comportamiento no será evidente para el cliente, ya que el cliente recibirá los mismos parámetros de salida y el mismo valor devuelto que habría recibido del método sincrónico.

En cualquier caso, la interacción entre el cliente y el servidor se serializa como si la llamada fuera sincrónica: la salida de los servidores proxy sincrónicos y asincrónicos es indistinguible, como es la salida de los códigos auxiliares correspondientes. Este comportamiento simplifica considerablemente el modelo de programación tanto de clientes como de servidores. Si un objeto de servidor implementa ICallFactory, un cliente serializado no tiene que intentar crear un objeto de llamada que pueda no estar disponible para el cliente, siempre hay disponible un objeto de llamada.

Cuando el cliente y el servidor están en el mismo apartamento, el objeto de servidor procesará la llamada que realice el cliente. Si un objeto de llamada no está disponible, el cliente debe obtener explícitamente la interfaz sincrónica y realizar una llamada sincrónica.

Para obtener más información, vea los temas siguientes: