相同的Windows服务的主机

Question

我目前工作的项目上的两个WCF服务库之间的通信包括接收来自客户端的C＃脚本（部分代码）的服务器，把它包装打造一个完整的类，编译然后加载它到一个单独的AppDomain中执行。

任务（正在运行脚本）可以在任何时间点发送反馈给用户的是执行，如用户脚本定义。可能这个任务可能会等待用户的响应（目前假设它在发送反馈后才立即响应）。用户可能随时决定杀死一项任务。

服务器实现为承载WCF服务库的Windows服务。

由于我不想让客户端过度复杂化以使其直接与动态创建的AppDomains进行通信，因此我在一些研究中考虑的（部分）解决方案是使用命名管道绑定托管第二个WCF服务以使动态AppDomain使用它作为它们和面向WCF服务的客户端之间的中继。

我的问题是，现在我不能想到一个干净的办法有两个WCF服务交互。

我的想法是：

1. 让他们保持直接引用对方： 看到，因为正常情况下，服务的都是单身它不应该是很难做到的。 但是，如果其中一个失败并需要重新启动，那将会很痛苦。 （我还是新来的WCF，所以我不知道如何常见的是，但它仍然是一个需要考虑的问题，我想。）
2. 介绍一些不大不小的“消息队列”的（或两个，每个方向），可以设置和订阅属性。因此，当一个服务设置一个属性时，第二个事件将被触发。但这对我来说有点不好意思，即使我不能真正想到任何明确的问题。

我真的可以使用一些专家意见来表达我想要完成的事情，无论是对我的想法或新想法的意见。即使这涉及重新考虑架构。只要有足够的理由去做这个项目，这个项目还处于足够早的阶段，可以进行一些返工。

既然我已经把很多的努力（读：油漆2分钟），以备快速（读：没用的）系统的架构，我会因为我没有名声张贴在此处链接图片： Link to schema

---

编辑：

正如我现在有声誉多亏了给予好评：

仍然在重读我的问题之后，我觉得也许我一直在从狭隘的角度看待这个问题，把服务看作比普通的类更特殊的东西。我越想越多，我觉得观察者模式可能是最好的方法。

Answer 1

只是为了记录在案，并避免留下我的（傻）无法解决的问题，我已经意识到我被试图找到特定于WCF服务的解决方案过于狭隘地看这个。 最后，我最终使用了观察者模式的变体（基于IObservable<T>Interface）。