如果 IsOneWay = true，则不会调用 WCF 服务代码
我通过消息总线扩展 WCF 传输，请求-答复模式对我来说效果很好。当我实现输入输出模式时，我遇到了一个问题。情况是：
1、我创建了InputChannel和OutputChannel并让TransportBindingElement返回它们。
2、我创建了一个合约接口，它有两个方法。其中一个属性为 IsOneWay = true，假设它是 Method1；另一个不是名为 Method2 的方法。
3，如果我调用Method1，我可以看到它给了我一个RequestChannel和ReplyChannel，而不是InputChannel和OutputChannel。并且回复通道可以接收WCF消息并返回RequestContext。但服务代码没有被调用。
4、如果我在 Method1 上设置 IsOneWay = false，效果很好。
4、如果我调用方法2，效果很好。
5，我创建了另一个服务合约，它只有一个 IsOneWay = true 的方法。如果我调用此方法，WCF 会为我提供 InputChannel 和 OutputChannel，并且它运行良好（执行服务代码）。
所以我的问题是： 1，如果我有一个具有 IsOneWay = true 方法和 IsOneWay = false 方法的服务，WCF 将为我提供请求-回复通道，对吗？
2、如何处理服务调用，该服务调用的方法为 IsOneWay = true，但在同一服务契约中还有 IsOneWay = false 方法？
顺便说一句，我注意到对于 IsOneWay = true 方法的请求消息，MessageID 为 NULL。我为请求消息设置了一个新的 ID，但不幸的是，服务代码仍然没有被调用。
I'm extend the WCF transport over a message bus, the request-reply mode works well to me. When I'm implementing the input-output mode I met a problem. The situation is:
1, I created the InputChannel and OutputChannel and let the TransportBindingElement return them.
2, I created a contract interface, which has two methods. One has the attribute said IsOneWay = true, let's say it's Method1; the other was not which named Method2.
3, If I invoked Method1, I can see that it gave me a RequestChannel and ReplyChannel instead of InputChannel and OutputChannel. And the reply channel can receive the WCF message and return the RequestContext back. But the service code was not invoked.
4, If I set IsOneWay = false on Method1, it works well.
4, If I invoked Method2, it works well.
5, I created another service contract which have only one method with IsOneWay = true. If I invoked this method WCF gave me InputChannel and OutputChannel, and it works well (service code executed).
So my question is:
1, If I have a service with IsOneWay = true methods and IsOneWay = false methods, the WCF will give me request-reply channel, is that correct?
2, How can I handle the service invoke, which the method was IsOneWay = true, but also has IsOneWay = false methods in the same service contract?
BTW, I noticed that for the request messages to the IsOneWay = true method, the MessageID was NULL. I set a new ID to the request message but no luck, the service code still wasn't invoked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我终于找到了原因和解决方案。
WCF 将根据整个服务契约选择最佳通道形状，而不是您调用的服务操作。因此，如果我有一个 IsOneWay = true 和 IsOneWay = false 方法混合的服务契约，WCF 将使用请求-答复模式，因为它可以覆盖所有可能的调用。
接下来，当WCF使用请求-回复模式来处理单向消息时，回复消息将为空。这意味着在 RequestContext.Reply 方法中，来自参数的传入消息为 null。所以我们不能像正常的请求-回复模式一样处理它（在该模式下回复消息不应该为空）。现在我们需要向底层传输发送一条空白消息，以使服务器端进程继续进行。
在客户端，在 RequestChannel.Request 方法中，我们还应该处理在本例中从 RequestContext.Reply 发送的空白消息。只要返回 null 就可以了。
Well I finally got the reason and the solution.
The WCF will chose the best channel shape based on the whole service contract, instead of which service operation you invoked. So if I have a service contract with IsOneWay = true and IsOneWay = false methods mixed, WCF will use request-reply mode since it can cover all possible invokes.
Next, when WCF using the request-reply mode to handle the one way message, the reply message will be null. Which means in the RequestContext.Reply method the incoming message from the parameter is null. So we cannot handle it as in the normal request-reply mode (in that mode the reply message shouldn't be null). Now we need to send a blank message to the underlying transportation, to make the server side process continue.
And on the client side, in RequestChannel.Request method we should also handle the blank message we sent from the RequestContext.Reply in this case. Just return null should be OK.
在我看来，您已经有了一种可行的解决方案 - 将单向操作与请求响应操作分离到不同的服务契约中。
操作之间通信模式的差异表明，无论技术上是否可行，您都不应该在同一服务中一起公开这些操作。
更新
从您的评论来看，您似乎正在尝试实现某种转发服务？如果是这样，您读过这篇文章吗？
https://dzone.com/articles/single-wcf-generic-endpoint-上
You kind of have, in my opinion, a solution which works already - decouple your one way operations from your request-response operations into different service contracts.
The difference in communication patterns between your operations suggests that regardless of whether it is technically possible or not, you should not expose these operations together in the same service.
UPDATE
It sounds from your comment like you are trying to implement sime kind of forwarding service? If so have you read this?
https://dzone.com/articles/single-wcf-generic-endpoint-on