以前我们有桌面应用程序，但考虑到客户端不希望访问服务器（物理或远程）这一事实，我们将它们变成 Windows 服务，将在（理论上）24 小时内运行7.
现在我们需要为该服务提供一个远程用户界面，以保留旧功能和旧界面。
为此，我们已经考虑过使用 WCF 开发几个 SOA 服务。我们将有一个服务用于配置，另一个服务用于例如网络信息、统计等，以便所有服务的总和提供与旧接口相同的功能，但分为不同的功能区域。
我在 SOA 方面没有太多经验，所以这种设计是否正确？ SOA 是否适合远程 UI？应该只有一个服务还是应该有逻辑组？
注意：我们有几个应用程序可以访问服务的某些部分信息，这就是我们进行这种逻辑划分的原因。
编辑：是否值得对谁可以连接以及早期可以访问的对象实施任何安全措施？我看到它带有一个很大的 YAGNI 警告，但也许我错了。
我对如何实现远程 UI、现有框架、最佳方法、使用 SOA 的优缺点等各种建议感兴趣
【问题讨论】：
标签： .net wcf architecture soa
当您说“远程 UI”时，我认为您实际上的意思是您有一些操作在远程服务器上执行，但通过 API 远程调用。
远程 UI 意味着用户界面正在服务机器上运行，并且用户正在通过投影的 UI 与服务进行交互，例如类似于终端服务。
在 SOA api 中公开服务所做的工作可能是您想要采取的最佳途径。然后，您可以在 Winforms、Silverlight、ASP.Net 或将来的任何其他工具中实现 UI。 SOA 对很多人来说是很多东西，但我喜欢把它看作是系统中的边界点，每一方都不知道对方的实施细节。
确定服务的粒度并不总是显而易见的，但如果您尝试考虑您为服务的消费者提供的功能，而不仅仅是您目前负责实现的 UI 应用程序。这些东西当然不是一成不变的，你可以随着事情的进展进行重构。单个应用程序可以使用多个服务，因此在这方面没有问题。
在我工作的地方，我们通常先实现功能，然后再回答安全问题。您的安全要求当然是具体的，但您需要考虑诸如被访问数据的敏感性或用户可以通过服务调用的功能等因素。如果该服务在您的网络内部使用或通过 Internet 公开，以及用户可能会尝试恶意行为的可能性。例如，商业用户不太可能下载 Visual Studio 的副本并创建自己的 WCF 客户端以造成破坏，但一切皆有可能。
【讨论】：
听起来您走在正确的轨道上。您的问题与我的问题基本相同，我的设计方式与您描述的大致相同 - Windows 服务托管三个 WCF 服务（迄今为止）和一个前端应用程序供用户用于与本地或远程 WCF 服务。
如果您描述的逻辑分区确实彼此独立，那么让每个分区成为自己的 WCF 服务模块就很有意义。但是，如果有一些重叠（例如，配置服务需要以某种方式与网络信息服务交互），那么我将在 WCF 合同级别强加逻辑划分，不一定作为完全独立的 WCF 模块。它会使 Windows 服务内部的处理变得更容易一些。
如果您没有 Juval Lowy 的书 Programming WCF Services，我强烈建议您购买一本。它是伟大的 WCF 参考书。您还可以访问他的网站IDesign.net，获取大量免费提供的 WCF 代码示例。
【讨论】：
我的意见是对于前端用户界面，基于 SOAP 的 Web 服务可能会很重，并且当负载增加时性能可能会成为一个问题，而不是基于用户 REST 的服务用于前端，而基于 SOAP 的服务用于您的业务逻辑和编排，以便您实现具有良好性能的高度可扩展的应用程序。
我认为 WCF 支持 SOAP 和 REST 服务，REST 服务是轻量级且技术中立的，因为它们基于纯 HTTP。
【讨论】：