【问题标题】:.NET Service Host Calling Its Own Service.NET 服务主机调用自己的服务
【发布时间】:2011-08-04 10:58:34
【问题描述】:

我有多个 WCF 服务自托管在 Windows 服务中。其中一项 WCF 服务需要调用托管在同一 Windows 服务中的另一项 WCF 服务。这可能需要在同一台机器上运行,或者在另一台机器上安装的同一个 Windows 服务上运行。我是否需要应用程序添加对自身的引用,或者是否有更简单的方法来调用它自己的服务之一。我知道如何通过更改端点地址来完成不同的机器位,但我不太清楚是否应该添加对自身的引用。即我是否需要使用与单独客户端相同的代码。

【问题讨论】:

    标签: c# .net wcf


    【解决方案1】:

    这里的概念称为“位置透明度”。也就是说,调用存在于同一进程或另一台机器上的 (WCF) 服务没有(技术)差异。

    通常,这被认为是一件好事,因为您可以在部署之后/期间更改服务的位置,具体取决于您的需要(稳定性或单个服务的资源消耗)。

    您可以通过配置命名管道绑定来优化您在同一台机器上运行的事实——这是否真的产生任何明显的差异当然取决于您的服务操作运行多长时间,执行它们的实际任务(参见@ 987654321@ 了解更多/关于选择合适绑定的好信息)。

    最后,如果它真的很重要,你可以创建你的own binding,这可能会利用这两个服务在同一个进程中生活的事实 - 很可能不是一项微不足道的任务。

    不过,无论如何,您都希望确保实际的服务实现不依赖于所使用的传输或绑定,因此要保持位置透明性。

    【讨论】:

    • 谢谢。最初添加对自身的引用的概念看起来很奇怪,但这样说是有道理的。
    【解决方案2】:

    如果您想访问 WCF 服务,无论它是否在进程内托管,为其生成代理都是一个好主意,也是一种访问它的简单方法。

    不过,您可以使用ChannelFactory 自己为服务创建Channel。但是如果可以的话,为什么不为其生成一个代理呢?

    【讨论】:

      【解决方案3】:

      您可以使用 new 关键字创建服务的新实例(针对服务的具体实现 - 当然不是接口)。我一直这样做,而且效果很好。 此外,项目不能添加对自身的引用,否则会导致时空连续体破裂;)

      【讨论】:

      • 这当然会绕过 WCF 的所有交易、安全等基础设施。如果这对于 OP 的情况是可以接受的,我不知道,但总的来说,我认为这是一个“坏事”想法”。
      • 鉴于提出问题的背景,我没有假设 OP 正在开发高级应用程序(没有冒犯 OP),因此提出了一些可以帮助他而不是混淆的东西他的。此外,调用在同一进程中的事实表明安全性在这里不是问题。请记住,每个问题都存在“万物之母”的解决方案......它们并不总是适用:)
      猜你喜欢
      • 2018-08-18
      • 1970-01-01
      • 1970-01-01
      • 2010-10-19
      • 2017-03-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多