Должен ли я использовать дуплексный сервис WCF или обычный сервис WCF?

Question

В настоящее время я разрабатываю C # Windows Form Application, который я намерен разрешить взаимодействовать с сервером. Сервер получит публикацию из мобильного приложения, которое я разработал, и всякий раз, когда публикуется сообщение, мое приложение Windows Form должно быть уведомлено и уведомить меня.

например. Мое мобильное приложение отправляет сообщение на мой сервер. Как только мой сервер получит сообщение, мое приложение Windows Form должно отобразить новое уведомление, показывающее содержание полученного сообщения, и соответствующим образом обновит интерфейс пользователя.

В этом типе сценария лучше использовать дуплексную службу WCF или обычную службу WCF?

Если дуплекс, объясните, почему мне нужно использовать дуплекс? Спасибо!

Answer 1

Дуплексный сервис - это сервис, в котором создаются два канала.

• Первый канал - это канал обычного клиента -> сервера, использующий ваш контракт на обслуживание. Это то, что вы найдете в каждой службе WCF, и как ваш клиент может отправить запрос в службу, и он может ответить.
• Второй канал - это сервер -> клиентский канал, использующий другой контракт на обслуживание, который вы определили. Этот второй канал позволяет серверу отправлять сообщения клиенту без запроса клиента.

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

Answer 2

Исходя из предположения, что ваше приложение Windows и ваш сервер являются одним и тем же доменом, я бы посоветовал вам использовать шаблон публикации / подписки для этого типа взаимодействия. Вы можете использовать что-то вроде образца IDesign , который доступен на их веб-сайте. По сути, ваше приложение Windows подписывается на события, которые генерируются вашим мобильным приложением, отправляющим сообщение на ваш сервер. Затем ваш издатель отправит событие в ваше приложение Windows.

Для этого ваше соединение с сервером / издателем должно быть всегда открыто. Это лучше всего достигается с помощью tcpBinding, поскольку он является двунаправленным и позволяет устанавливать большие тайм-ауты (фактически бесконечность).

Если вы не можете использовать TCP, ваша работа стала немного сложнее. Использование дуплексного канала является немного проблематичным, потому что вы также должны контролировать канал, потому что ни одна из сторон не уведомит другую, если канал закроется. Вы узнаете, только когда попробуете его использовать. Конечно, это может происходить и с TCP-соединением, но оно немного стабильнее, чем при использовании http.

Другой альтернативой является использование привязки MSMQ. Это гарантирует доставку вашего сообщения, потому что вы взаимодействуете через MSMQ, а не через канал связи, такой как http или tcp. В этом случае вам даже не понадобится инфраструктура pub / sub, вы можете просто иметь службу, которая отправляет ваши мобильные сообщения в очередь, которую отслеживает ваше приложение Windows. Преимущество использования фреймворка заключается в том, что несколько приложений могут прослушивать одно и то же событие.

НТН.