WCF双工通道，将请求和响应解耦
我正在考虑一个项目，其中需要使用 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 能够实现这种事情？
I'm contemplating a project where I'll be required to make use of what is variously called the "asynchronous" mode, or the "duplex" mode, or the "callback" mode of SOAP webservice. In this mode, the caller of the service provides in the SOAP header a "reply-to" address, and the service, instead of returning the output of the call in the HTTP response, creates a separate HTTP connection to this "reply-to" address and posts the response message to it. This is normally achieved in WCF using a CompositeDuplexBinding, like so:
<binding name="async_http_text">
<compositeDuplex clientBaseAddress="http://192.168.10.123:1234/async" />
<oneWay />
<textMessageEncoding messageVersion="Soap12WSAddressing10" />
<httpTransport useDefaultWebProxy="false" />
</binding>
This results in not one, but two HTTP connections per call: one from the client to the service, and then one from the service back to the client. From the point of view of the service implementation, nothing changes, you have a method that implements the interface method, and you take in the request and return the response. Fantastic, this is what I need, almost.
In my situation, the request and response can be separated by anything from minutes to days. I need a way to decouple the request and the response, and "store" the state (message, response URI, whatever) until I have enough information to respond at a later time (or even never, under certain circumstances).
I'm not terribly excited about having my methods essentially "paused" for up to days at a time, along with the required silly timeout values (if they're even accepted as valid), but I don't know how to go about putting a system like this together.
In order to be completely clear, I'm implementing a set of standards provided by a standards body, so I do not have flexibility to change SOAP message semantics or alter protocol implementations. This sort of interaction is exactly what was intended when the ReplyTo header was implemented in WS-Addressing.
How would you do it? Perhaps Workflow Foundation enables this sort of thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下，请勿使用 WCF 中定义的 HTTP 双工通信。它根本不起作用，因为它依赖于其他一些先决条件 - 会话、服务器上的服务实例等。这一切都增加了很多超时问题。
您需要的是基于以下事实的双向通信：服务公开单向服务，客户端也公开单向服务（服务可以是双向的以支持某种传递通知）。您将在第一个请求中传递客户端的地址以及一些相关 ID，以区分从同一客户端传递的多个请求。请求完成后，您将致电客户服务。是的，你必须自己管理所有的事情。
如果您处于 Intranet 环境中并且您的客户端基于 Windows，您甚至可以考虑将传输协议更改为 MSMQ，因为它内置了对所有这些要求的支持。
编辑：
我检查了您更新的问题，您将您的通信模式称为 Soap Messaging。我从来没有用 WCF 这样做过，但应该是可能的。您需要在通信双方公开服务 - 您可以构建您的服务以完全遵循所需的合同。当您的服务收到调用时，您可以使用
OperationContext.Current.IncommingMessageHeaders来访问 WS-Addressing 信息。您可以存储此信息并在以后需要时使用它们。问题是这些信息不会包含您需要的内容。您必须先在客户端上填写它们。这通常可以通过使用OperationContextScope并填充OperationContext.Current.OutgoingMessageHeaders来实现。我担心的是 WCF 可能会“聪明”并覆盖您对传出 WS-Addressing 信息的更改。我可能会在周末亲自尝试一下。In such case don't use HTTP duplex communication as defined in WCF. It will simply not work because it is dependent on some other prerequisities - session, service instance living on the server, etc. It all adds a lot of problems with timeouts.
What you need is bi-directional communication based on fact that service exposes one way service and client exposes one way service as well (services can be two-way to support some kind of delivery notification). You will pass client's address in the first request as well as some correlation Id to differ multiple requests passed from the same client. You will call client service when the request is completed. Yes, you will have to manage all the stuff by yourselves.
If you are in intranet environment and your clients will be Windows based you can even think about changing your transport protocol to MSMQ because it has built-in support for all these requirements.
Edit:
I checked your updated question and you would call your communication pattern as Soap Messaging. I have never did it with WCF but it should be possible. You need to expose service on both sides of the communication - you can build your service to exactly follow needed contracts. When your service receives call you can use
OperationContext.Current.IncommingMessageHeadersto access WS-Addressing information. You can store this information and use them later if you need them. The problem is that these information will not contain what you need. You have to fill them first on the client. This is generally possible by usingOperationContextScopeand fillingOperationContext.Current.OutgoingMessageHeaders. What I'm affraid is that WCF can be "to clever" and override your changes to outgoing WS-Addressing information. I will probably try it myself during weekend.事实证明，Windows Workflow Foundation (v4) 确实促进了这种消息交换。
因为 WF 允许您解耦请求和响应，并且基本上可以在中间做任何您想做的事情，包括保留工作流程、闲置它以及出去割草，所以您可以“免费”获得此功能。可以在以下 URL 中找到信息：
耐用双面打印 (MSDN)
工作流 4 服务和双工通信
It turns out the Windows Workflow Foundation (v4) does indeed facilitate this sort of message exchange.
Because WF allows you to decouple the request and response, and do basically whatever you want in the middle, including persist the workflow, idle it, and go outside and cut the grass, you get this capability "for free". Information can be found at these URLs:
Durable Duplex (MSDN)
Workflow 4 Services and duplex communications