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

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

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

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

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

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

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

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

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

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

Заметка

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

 

Дополнительные сведения см. в RpcBindingSetOption, RpcServerUseProtseqEpExи [сообщения], ncadg_mq.