Développement d’applications de mise en file d’attente RPC-Message

Très peu d’efforts sont nécessaires pour tirer parti du transport MSMQ dans votre application RPC. Pour la messagerie synchrone, vous devez uniquement spécifier le transport de file d’attente de messages (ncadg_mq) comme séquence de protocole. Le protocole ncadg_mq prend en charge toutes les fonctionnalités de datagramme standard, à l’exception des appels de diffusion. Notez également que le transport de file d’attente de messages ne prend pas en charge les points de terminaison dynamiques.

En appliquant l’attribut [message] aux déclarations de procédure distante dans le fichier IDL, vous implémentez automatiquement la mise en file d’attente de message en mode asynchrone pour ces appels. Cela permet aux applications clientes et serveurs de contrôler de nombreuses propriétés associées aux messages et aux files d’attente de messages, notamment :

  • Qualité de service
  • Accusé de réception
  • Journalisation
  • Priorité de l’appel
  • Persistance de la file d’attente des processus serveur

La qualité de service est l’effort que le transport fera pour remettre l’appel au processus serveur. Une remise express sera mise en file d’attente en mémoire, elle est donc assez rapide, mais l’appel sera perdu si une connexion ordinateur ou réseau tombe en panne au mauvais moment. Une remise récupérable est publiée dans un fichier disque jusqu’à ce qu’il soit remis, de sorte que l’appel ne sera pas perdu, même en cas de plantage de l’ordinateur. Cela garantit la livraison, mais à un coût de performances, car chaque appel est écrit sur le disque.

Vous pouvez également indiquer au transport MSMQ d’attendre l’accusé de réception que l’appel a atteint la file d’attente de destination (serveur) avant de retourner. Le choix de cette option bloque le client jusqu’à ce que le serveur accepte l’appel. Sinon, le contrôle revient au client immédiatement après avoir effectué l’appel.

À l’aide de la journalisation, les appels peuvent être consignés sur le disque. Si la journalisation est activée, chaque appel est journalisé sur le disque, car il est transmis au tronçon suivant sur son chemin vers le processus serveur.

La priorité d’appel peut être utilisée conjointement avec l’attribut de fonction RPC [message] pour permettre aux appels avec une priorité plus élevée d’être prioritaires sur les appels avec une priorité inférieure, même si les appels à priorité élevée arrivent plus tard. La priorité des appels fonctionne également de manière limitée avec rpc synchrone, mais les appels RPC synchrones ne peuvent pas s’empiler de la même manière que les appels asynchrones.

Le processus client contrôle toutes les propriétés ci-dessus en appelant RpcBindingSetOption. Une fois définies, ces propriétés restent en vigueur jusqu’à ce qu’elles soient modifiées dans un autre appel à RpcBindingSetOption.

Le processus du serveur RPC peut contrôler la durée de vie de sa file d’attente de réception. Par défaut, la file d’attente est supprimée lorsque le processus serveur se termine. Toutefois, le processus serveur peut utiliser RpcServerUseProtseqEpEx lors de la configuration de son point de terminaison pour indiquer au transport de permettre à la file d’attente de continuer à exister et d’accepter les demandes d’appel même lorsque le processus serveur n’est pas en cours d’exécution. Dans ce cas, les appels sont mis en file d’attente et exécutés ultérieurement, lorsque le processus serveur revient en ligne.

Notes

Si vous utilisez des appels [message] asynchrones dans une interface, vous devez inscrire l’interface en appelant RpcServerRegisterIf ou RpcServerRegisterIfEx avant d’appeler RpcServerUseProtseqEpEx(ncadg_mq). Une fois que vous avez activé la séquence de protocole, tous les appels qui attendent déjà dans la file d’attente pour le serveur commencent à être lus hors de la file d’attente. Si l’interface RPC correspondante n’a pas été inscrite, les appels échouent. Cette situation peut se produire si vous avez configuré un point de terminaison permanent pour vos appels de procédure à distance, si le serveur a été arrêté et si les clients ont continué à envoyer des appels au serveur. Ces appels seront empilés dans la file d’attente, en attendant d’être lus une fois que le serveur sera de retour en ligne.

 

Pour plus d’informations, consultez RpcBindingSetOption, RpcServerUseProtseqEpEx et [message], ncadg_mq.