Question

我正在考虑一个项目，我将被要求使用各种所谓的“异步”模式，或“双工”模式，或SOAP webservice的“回调”模式。在这种模式下，服务的调用者在SOAP头中提供一个“回复”地址，而服务，而不是在HTTP响应中返回调用的输出，创建一个单独的HTTP连接到这个“回复” “向其发送并发布响应消息。这通常使用CompositeDuplexBinding在WCF中实现，如下所示：

<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消息语义或改变协议实现。这种交互正是在WS-Addressing中实现ReplyTo标头时的预期。

你会怎么做？也许Workflow Foundation能够做到这一点吗？

Answer 1

在这种情况下，请勿使用WCF中定义的HTTP双工通信。它根本不起作用，因为它依赖于其他一些先决条件 - 会话，服务器上的服务实例等等。这都会增加很多超时问题。

您需要的是基于服务公开单向服务和客户端暴露单向服务这一事实的双向通信（服务可以是双向的，以支持某种类型的传递通知）。您将在第一个请求中传递客户端的地址以及一些相关ID，以区分从同一客户端传递的多个请求。您将在请求完成后调用客户端服务。是的，你必须自己管理所有的东西。

如果您处于Intranet环境中并且您的客户端将基于Windows，您甚至可以考虑将传输协议更改为MSMQ，因为它内置了对所有这些要求的支持。

修改

我检查了您更新的问题，您将通信模式称为Soap Messaging。我从来没有用过WCF，但应该可以。您需要在通信的两端公开服务 - 您可以构建您的服务以完全遵循所需的合同。当您的服务收到呼叫时，您可以使用OperationContext.Current.IncommingMessageHeaders来访问WS-Addressing信息。您可以存储此信息，并在以后需要时使用它们。问题是这些信息不包含您需要的信息。你必须先在客户端填写它们。通常可以使用OperationContextScope并填充OperationContext.Current.OutgoingMessageHeaders来实现。我担心的是WCF可以“聪明”并覆盖对传出WS-Addressing信息的更改。我可能会在周末自己尝试一下。

Answer 2

事实证明，Windows Workflow Foundation（v4）确实促进了这种消息交换。

因为WF允许你解耦请求和响应，并且基本上做你想要的任何事情，包括坚持工作流程，闲置它，然后去外面割草，你可以“免费”获得这个功能。可以在以下网址找到相关信息：

Durable Duplex (MSDN)

Workflow 4 Services and duplex communications

WCF双工通道，解除请求和响应

2 个答案: