WCF дуплексный канал, разъединение запроса и ответа

Question

Я рассматриваю проект, в котором мне потребуется использовать то, что по-разному называется «асинхронным» режимом, или «дуплексным» режимом, или режимом «обратного вызова» веб-службы SOAP. В этом режиме вызывающая служба предоставляет в заголовке SOAP адрес «reply-to», и служба вместо возврата результата вызова в HTTP-ответе создает отдельное HTTP-соединение с этим «reply-to». "адрес и отправляет ответное сообщение на него. Обычно это достигается в WCF с помощью CompositeDuplexBinding, например:

<binding name="async_http_text">
    <compositeDuplex clientBaseAddress="http://192.168.10.123:1234/async" />
    <oneWay />
    <textMessageEncoding messageVersion="Soap12WSAddressing10" />
    <httpTransport useDefaultWebProxy="false" />
</binding>

В результате получается не одно, а два HTTP-соединения на вызов: одно от клиента к службе, а затем одно от службы обратно к клиенту. С точки зрения реализации сервиса, ничего не меняется, у вас есть метод, который реализует метод интерфейса, и вы принимаете запрос и возвращаете ответ. Фантастика, это то, что мне нужно, почти.

В моей ситуации запрос и ответ могут быть разделены чем-либо от минут до дней. Мне нужен способ отделить запрос и ответ и «сохранить» состояние (сообщение, URI ответа и т. Д.), Пока у меня не будет достаточно информации, чтобы ответить позже (или даже никогда, при определенных обстоятельствах).

Меня не очень радует то, что мои методы по сути "приостанавливаются" на несколько дней одновременно с необходимыми глупыми значениями тайм-аута (если они даже приняты как действительные), но я не знаю, как чтобы собрать такую ​​систему вместе.

Для полной ясности я реализую набор стандартов, предоставляемых органом по стандартизации, поэтому у меня нет гибкости для изменения семантики сообщений SOAP или для реализации протоколов. Такое взаимодействие является именно тем, что было задумано, когда заголовок ReplyTo был реализован в WS-Addressing.

Как бы вы это сделали? Возможно, Workflow Foundation обеспечивает такие возможности?

Answer 1

Оказывается, Windows Workflow Foundation (v4) действительно облегчает такой обмен сообщениями.

Поскольку WF позволяет вам отделить запрос и ответ и делать в основном все, что вы хотите в середине, включаяСохраняйте рабочий процесс, бездействуйте, выходите на улицу и подстригайте траву, вы получаете эту возможность «бесплатно».Информацию можно найти по следующим URL:

Durable Duplex (MSDN)

Рабочий процесс 4 Услуги и двусторонняя связь

Answer 2

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

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

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

Edit:

Я проверил ваш обновленный вопрос, и вы назвали бы ваш шаблон общения как Soap Messaging. Я никогда не делал это с WCF, но это должно быть возможно. Вам нужно предоставлять сервис по обе стороны коммуникации - вы можете построить свой сервис, чтобы точно следовать необходимым контрактам. Когда ваша служба получает вызов, вы можете использовать OperationContext.Current.IncommingMessageHeaders для доступа к информации WS-Addressing. Вы можете хранить эту информацию и использовать ее позже, если она вам понадобится. Проблема в том, что эта информация не будет содержать то, что вам нужно. Вы должны сначала заполнить их на клиенте. Обычно это возможно при использовании OperationContextScope и заполнении OperationContext.Current.OutgoingMessageHeaders. Я боюсь, что WCF может быть «умным» и отвергать ваши изменения в исходящей информации WS-Addressing. Я, наверное, попробую сам в выходные.