Compartir a través de


Desarrollo de aplicaciones RPC-Message Queuing

Es necesario muy poco esfuerzo para aprovechar el transporte MSMQ en la aplicación RPC. Para la mensajería sincrónica, solo necesita especificar el transporte de cola de mensajes (ncadg_mq) como secuencia de protocolo. El protocolo ncadg_mq admite todas las características de datagrama estándar, excepto las llamadas de difusión. Además, tenga en cuenta que actualmente el transporte de la cola de mensajes no admite puntos de conexión dinámicos.

Al aplicar el atributo [message] a las declaraciones de procedimiento remoto en el archivo IDL, se implementa automáticamente la cola de mensajes en modo asincrónico para esas llamadas. Esto permite que las aplicaciones cliente y servidor controlen muchas de las propiedades asociadas a mensajes y colas de mensajes, entre las que se incluyen:

  • Calidad de servicio
  • Confirmación de recibo
  • Registro en el diario
  • Prioridad de llamada
  • Persistencia de la cola de procesos del servidor

La calidad del servicio es el esfuerzo que realizará el transporte para entregar la llamada al proceso del servidor. Una entrega rápida se pondrá en cola en la memoria, por lo que es bastante rápida, pero la llamada se perderá si un equipo o conexión de red deja de funcionar en el momento incorrecto. Una entrega recuperable se publicará en un archivo de disco hasta que se entregue, por lo que la llamada no se perderá, incluso en caso de bloqueo del equipo. Esto proporciona una entrega garantizada, pero a un costo en el rendimiento, ya que cada llamada se escribe en el disco.

También puede indicar al transporte de MSMQ que espere a que se confirme que la llamada alcanzó la cola de destino (servidor) antes de devolverla. Al elegir esta opción, el cliente se bloquea hasta que el servidor confirme la llamada; de lo contrario, el control vuelve al cliente inmediatamente después de realizar la llamada.

Mediante el registro en diario, las llamadas se pueden registrar en el disco. Si el registro en diario está activado, cada llamada se registra en el disco, ya que se transmite al próximo salto en su camino al proceso del servidor.

La prioridad de llamada se puede usar junto con el atributo de función RPC [message] para permitir que las llamadas con mayor prioridad tengan prioridad sobre las llamadas con menor prioridad, incluso si las llamadas de alta prioridad llegan más adelante. La prioridad de llamada también funcionará de forma limitada con RPC sincrónica, pero las llamadas RPC sincrónicas no se pueden apilar de la misma manera que las llamadas asincrónicas.

El proceso de cliente controla todas las propiedades anteriores mediante una llamada a RpcBindingSetOption. Una vez establecida, estas propiedades permanecen en vigor hasta que se cambian en otra llamada a RpcBindingSetOption.

El proceso del servidor RPC puede controlar la duración de su cola de recepción. De forma predeterminada, la cola se elimina cuando se cierra el proceso del servidor. Sin embargo, el proceso de servidor puede usar RpcServerUseProtseqEpEx al configurar su punto de conexión para indicar al transporte que permita que la cola continúe existiendo y aceptar solicitudes de llamada incluso cuando el proceso del servidor no se esté ejecutando. En este caso, las llamadas se ponen en cola y se ejecutan más adelante, cuando el proceso del servidor vuelve a estar en línea.

Nota

Si usa llamadas asincrónicas [message] en una interfaz, debe registrar la interfaz llamando a RpcServerRegisterIf o RpcServerRegisterIfEx antes de llamar a RpcServerUseProtseqEpEx(ncadg_mq). Una vez que active la secuencia de protocolos, las llamadas que ya esperan en la cola del servidor comenzarán a leerse fuera de la cola. Si no se ha registrado la interfaz RPC correspondiente, se producirá un error en las llamadas. Esta situación puede ocurrir si tiene un punto de conexión permanente para las llamadas a procedimientos remotos, el servidor se ha cerrado y los clientes han seguido enviando llamadas al servidor. Estas llamadas se apilan en la cola, esperando que se lean una vez que el servidor vuelva a estar en línea.

 

Para obtener más información, vea RpcBindingSetOption, RpcServerUseProtseqEpEx y [message], ncadg_mq.