2011-02-28 45 views
2

我无法将故障通道的概念映射回某些绑定的手动实现。我认为这个WCF功能很烦人,我想知道是否有任何方法来禁用它。WCF通道故障状态有帮助吗?

以TCP为例。大多数TCP通信都是断开的。那么为什么一个连接会对通道造成故障并破坏所有以下连接?

并命名管道?

也许我错了。所以请解释它为什么是一个功能,而不是一个错误。

回答

7

FaultedCommunicationObject状态机的状态之一,该状态机被烘焙成许多WCF抽象的实现。它基本上意味着该对象的“游戏结束”,所以你不会找到任何方法来禁用它。

这当然不是一个错误:所有这些文物底层的CommunicationObject状态机是一个有意识的设计选择。虽然可能有兴趣争论WCF架构师做出的设计决定,但如果您想使用WCF,最终您只需要接受事情的发展并继续前进。

您应该将通道看作不仅仅是所使用传输的适配器:它是一个更高层次的抽象,它在通信堆栈中封装了许多不同的层(传输,编码,安全性,会话管理,交易流,双工等)。

即使查看特定绑定的详细信息,您也会发现堆栈中很少的元素具有容错能力,您可以在先前的通信尝试失败后安全地重用它们(例如,可能是HTTP协议)。即使你提到的那些(TCP,命名管道)也不像你所建议的那样容错。

我认为CommunicationObject状态机或类似的东西,或多或少是必不可少的,以便在比其所有组成层/元素的细节更高的层次上进行通道抽象。它使简单的规则:如果它是Faulted,扔掉它,并创建一个新的。是的,在这种情况下可能会出现一些情况,如果您错过了可以通过保留一些可以安全地重用的资源来实现的优化,但这是您花费更少的费用来处理通信的简单抽象。

11

我认为它是JuvalLöwy's(WCF架构师之一)WCF总体理念的产物。引用他的书编程WCF服务

这[异常系统和使用它的正常方式]是.NET的一个根本缺陷作为一个平台。 [这里] [在抛出异常之后],发生了一些完全出乎意料和可怕的事情。客户怎么可能假装呢?该对象可能会被绝望地破坏,但客户端仍在继续使用它。

的想法是,你毕竟,与对象上哪个传输信道使用的是对方沟通,如果对象抛出一个异常,它可能无法使用了。这是一个有趣的观点,但我不确定我是否完全同意(因为如你所说,在实践中可能会很烦人)。

+5

+1作为Juval喜欢说的那样:*您服务炸毁了 - 所有在那里的血液和身体部位;你仍然想尝试再次调用它?* - 不能得到比这更多的图形:-) – 2011-02-28 18:13:41

0

这是WCF的作用:

Proxy a = new Proxy(); 
a.SomeOp() -> threw exception 
a.SomeOtherOp() -> faulted 

这里SomeOp“失败,而不是 'A',所以为什么SomeOtherOp要失败?

这是有道理的,如果

Proxy a = new Proxy(); -> threw exception 
a.SomeOp() -> faulted