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