1

我正在考虑一个项目，在该项目中我将被要求使用各种称为“异步”模式、“双工”模式或 SOAP Web 服务的“回调”模式。在这种模式下，服务的调用者在 SOAP 标头中提供一个“回复”地址，并且服务不会在 HTTP 响应中返回调用的输出，而是创建一个到该“回复”的单独 HTTP 连接" 地址并向其发布响应消息。这通常在 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 消息语义或更改协议实现。这种交互正是在 WS-Addressing 中实现ReplyTo 标头时的意图。

你会怎么做？也许 Workflow Foundation 支持这种事情？

4

2 回答 2

1

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

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

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

编辑：

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

于 2011-02-04T08:47:41.437 回答
1

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

因为 WF 允许您将请求和响应解耦，并且基本上可以在中间做任何您想做的事情，包括持久化工作流、将其闲置以及到外面去割草，所以您“免费”地获得了这种能力。可以在这些 URL 中找到信息：

耐用双工 (MSDN)

工作流 4 服务和双工通信

于 2011-02-04T20:38:08.153 回答