我目前正在处理的项目包括一个服务器，它从客户端接收 C# 脚本（部分代码），将其包装以创建一个完整的类，对其进行编译，然后将其加载到单独的 AppDomain 中以供执行。
任务（当前正在运行的脚本）可以在执行的任何时候向用户发送反馈，如用户在脚本中定义的那样。并且可能该任务可能会等待用户的响应（目前假设它只是在发送反馈之后）。并且用户可能在任何时候决定终止一个任务。
服务器实现为托管 WCF 服务库的 Windows 服务。
由于我不想使客户端过于复杂以使其直接与动态创建的 AppDomain 进行通信，因此我在进行一些研究后考虑的（部分）解决方案是托管具有命名管道绑定的第二个 WCF 服务，以使动态 AppDomain 将其用作它们与面向 WCF 服务的客户端之间的中继。
我的问题是，现在我想不出一种让两个 WCF 服务交互的干净方法。
我的想法是：
- 让他们保持对彼此的直接引用：通常这两个服务都是单例的，这应该不难做到。但是，如果其中一个失败并且需要重新启动，那将是一个痛苦的维护。（我还是 WCF 的新手，所以我不知道这有多普遍，但这仍然是一个需要考虑的问题。我认为。）
- 引入某种“消息队列”（或两个，每个方向一个），其属性可以设置和订阅。因此，当一个服务设置一个属性时，将在第二个服务中触发一个事件。但这对我来说有点奇怪，即使我真的想不出任何明确的问题。
我真的可以在我想要完成的事情上使用一些专家意见，无论是对我的想法或新想法的意见。即使这涉及重新思考架构。这个项目仍处于足够早的阶段，可以承受一些返工，当然，只要有足够的理由这样做。
由于我付出了很多努力（阅读：2 分钟的绘画时间）来准备一个快速（阅读：无用）的系统架构，因此我将在此处链接它，因为我没有发布图像的声誉： 链接到图式
编辑：
由于赞成票，我现在享有声誉：
仍然在重读我的问题之后，我觉得也许我一直从一个过于狭隘的角度看待这个问题，将服务视为比普通课程更特别的东西。我越想越觉得观察者模式可能是最好的方法。