2011-06-15 70 views
3

这可能是在黑暗中拍摄的(我对WCF的内部知识并不了解),但是这里还是...从服务器端结束WCF会话?

我目前正在一个客户端网站上使用遗留应用程序,重新遇到WCF服务的持久性问题。该应用程序使用Microsoft Sync Framework 2.0并通过上述服务进行同步。服务器端的服务实现有很多在各种状态下的自定义代码“一塌糊涂”。

不管怎样,我们看到客户端应用程序的大部分时间,我们正在缩小使用同一台机器上打同样的服务上的应用程序上不同的用户中心模式的错误。它似乎,服务和客户端上的身份验证级别不同步的某种方式。

在文章here中讨论了该错误,我们正在研究从消息层安全性切换到传输层安全性的方法,这将有望解决问题。但是,如果这个问题有意义,我们或许可以用侵略性较小的方式来解决它。

在链接的文章,其中一条建议是要强行终止连接,如果特定的异常被捕获,再试一次,如果再次失败,这是因为这个特殊的理论没有。听起来不错,并且易于实施。但是,我发现自己无法确信连接是否正常终止。

服务操作通过自定义接口,该接口是在服务器侧实现。该接口可以做些什么来结束连接的唯一的事情就是对代理本身,它是一个自定义的方法在服务器上调用EndSession()通话EndSession()

所以......

从WCF服务方法,有没有办法正常和正常终止的方式,客户端会喜欢与客户端的连接?

也就是说,在这个自定义EndSession()有一些最后一步,我可以采取导致服务器完全忘了这方面是开放的?因为它似乎当在同一台机器上的另一个用户试图在应用程序内打服务一样,当它失败的链接文章中的错误的。

这个想法是,在事物的客户端,调用EndSession()的代码后面是将代理对象清零,然后调用工厂方法以在下次需要时提供另一个工厂方法。所以我想如果更多的东西需要在服务器端发生的(并且默认在WCF确实,如果不是这一切的自定义实现代码)终止对端的连接?

就像我说的,在黑暗中拍摄。但是,也许在回答/讨论,在这里我至少可以进一步诊断问题,所以任何的帮助深表感谢。谢谢。

回答

3

不幸的是只有真正的三种方式,其中session可以终止

  1. 客户端关闭代理
  2. 服务的receiveTimeout在客户端之前超过 发送另一个 要求
  3. 的服务引发一个 非故障例外,它将故障 通道,因此终止 会话

如果您不希望涉及的客户端,那么您只有2个和3个客户端都没有问题 - 他们在下次尝试与服务对话时都会遇到异常情况。

你可以使用Duplex messaging并获得服务,通知其需要终止会话的客户端 - 客户端,然后得到一个机会,以更加方便地关闭代理,但是这是一个合作战略

+0

对不起花了一段时间才能得到回到这里,这个项目一直是忙碌的一周。我想我们会稍微考虑一下双工信息(虽然这种遗留代码的状态不适合改变),但我很欣赏这个建议。但是我至少在终端上测试了你的观点,但对于客户来说并没有很好的结局,而且你完全正确:)无论如何,由于团队不完全了解的原因,系统现在大都在工作。我认为我们让客户成功关闭了代理。感谢您的建议! – David 2011-06-18 12:07:23