以前我们有桌面应用程序，但考虑到客户端不希望访问服务器（物理或远程）这一事实，我们将它们变成了将在（理论上）24/7 运行的Windows 服务。
现在我们需要为该服务提供一个远程用户界面，以保留旧功能和旧界面。
为此，我们已经考虑过使用 WCF 开发几个 SOA 服务。我们将有一个服务用于配置，另一个服务用于例如网络信息、统计等，以便所有服务的总和提供与旧接口相同的功能，但分为不同的功能区域。
我在 SOA 方面没有太多经验，所以这种设计是否正确？SOA 是否适合远程 UI？应该只有一项服务还是应该有逻辑组？
注意：我们有几个应用程序可以访问服务的某些部分信息，这就是我们进行逻辑划分的原因。
编辑：对谁可以连接以及早期可以访问的内容实施任何安全措施是否值得？我有点看到它带有一个很大的 YAGNI 警告，但也许我错了。
我对有关如何实现远程 UI、现有框架、最佳方法、使用 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。