Разработка приложений для RPC-Message очередей

Чтобы воспользоваться преимуществами транспорта MSMQ в приложении RPC, требуется очень мало усилий. Для синхронного обмена сообщениями необходимо указать только транспорт очереди сообщений (ncadg_mq) в качестве последовательности протокола. Протокол ncadg_mq поддерживает все стандартные функции датаграмм, кроме трансляции вызовов. Кроме того, обратите внимание, что в настоящее время транспорт очереди сообщений не поддерживает динамические конечные точки.

Применив атрибут [message] к объявлениям удаленных процедур в IDL-файле, вы автоматически реализуете очередь сообщений в асинхронном режиме для этих вызовов. Это позволяет клиентским и серверным приложениям управлять многими свойствами, связанными с сообщениями и очередями сообщений, в том числе:

• Качество обслуживания
• Подтверждение получения
• Ведение журнала
• Приоритет вызова
• Сохраняемость очереди серверных процессов

Качество обслуживания — это усилия, которые транспорт будет делать для доставки вызова серверного процесса. Экспресс-доставка будет помещена в очередь в памяти, поэтому она выполняется довольно быстро, но вызов будет потерян, если компьютер или сетевое подключение не работает в неправильное время. Восстанавливаемая доставка будет отправляться в файл диска до тех пор, пока она не будет доставлена, поэтому вызов не будет потерян даже при сбое компьютера. Это обеспечивает гарантированную доставку, но с высокой производительностью, так как каждый вызов записывается на диск.

Вы также можете указать транспорту MSMQ ожидать подтверждения того, что вызов достиг целевой (серверной) очереди, прежде чем вернуться. При выборе этого параметра клиент блокируется до тех пор, пока сервер не подтвердит вызов, в противном случае управление возвращается клиенту сразу после выполнения вызова.

С помощью ведения журнала вызовы можно регистрировать на диске. Если ведение журнала включено, каждый вызов регистрируется на диске по мере передачи на следующий прыжок на пути к процессу сервера.

Приоритет вызова можно использовать в сочетании с атрибутом функции RPC [message], чтобы разрешить вызовы с более высоким приоритетом иметь приоритет над вызовами с более низким приоритетом, даже если вызовы с высоким приоритетом поступают позже. Приоритет вызова также будет работать в ограниченном режиме с синхронным RPC, но синхронные вызовы RPC не могут стекаться так же, как асинхронные вызовы.

Клиентский процесс управляет всеми указанными выше свойствами, вызывая RpcBindingSetOption. После установки эти свойства остаются в силе, пока они не будут изменены в другом вызове RpcBindingSetOption.

Процесс RPC-сервера может управлять временем существования очереди получения. По умолчанию очередь удаляется при выходе серверного процесса. Однако серверный процесс может использовать RpcServerUseProtseqEpEx при настройке своей конечной точки, чтобы сообщить транспорту, что очередь должна продолжать существовать и принимать запросы на вызовы, даже если серверный процесс не запущен. В этом случае вызовы помещаются в очередь и выполняются позже, когда серверный процесс возвращается в режим "в сети".

Примечание

При использовании асинхронных вызовов [message] в интерфейсе необходимо зарегистрировать интерфейс, вызвав RpcServerRegisterIf или RpcServerRegisterIfEx перед вызовом RpcServerUseProtseqEpEx(ncadg_mq). После включения последовательности протоколов все вызовы, уже ожидающие в очереди для сервера, начнут считываться из очереди. Если соответствующий интерфейс RPC не зарегистрирован, вызовы завершатся ошибкой. Такая ситуация может произойти, если настроена постоянная конечная точка для удаленных вызовов процедур, сервер завершен, а клиенты продолжают отправлять вызовы на сервер. Эти вызовы будут помещены в очередь, ожидая их чтения после того, как сервер вернется в режим "в сети".

 

Дополнительные сведения см. в разделах RpcBindingSetOption, RpcServerUseProtseqEpEx и [message], ncadg_mq.