我们正在创建一个n层Silverlight LOB应用程序，并正在考虑使用.NET RIA服务。我们不清楚它与我们当前的WCF服务API相关的位置。我们目前的架构是：
Silverlight的 < - > WCF服务 < - > 商业逻辑 < - > 实体框架模型 < - > 数据库
观看了Nikhils Mix 09的演示后，看起来.NET RIA服务将取代我们的WCF和BusLog部分：
Silverlight的 < - > RIA服务 < - > EF模型 < - > D B
哪个好，期望我们需要公开一个标准的SOAP端点API供其他应用程序使用（Biztalk，Integration等）。 .NET RIA Services是否可以作为SOAP端点公开而无需异步要求？
通过.NET RIA服务实现WCF服务有多容易？你知道这方面有什么好的在线例子吗？
谢谢， 标记
是的 - 在RIA服务的下一个CTP中，我们将非常好地支持定义WCF服务（通过Astoria和最终的vanilla WCF），这些服务在RIA服务中公开您的业务逻辑。因此，您在RIA Services实施方面有两个负责人。
Silverlight <---> RIA服务<---> EF模型<---> DB WCF服务<--->
我说如果主要目标是Silverlight应用程序，这个模型是有意义的，但是如果主要目标是WCF服务，我会挂起你今天拥有的模型。这有帮助吗？
..brad
是的 - 在RIA服务的下一个CTP中，我们将非常好地支持定义WCF服务（通过Astoria和最终的vanilla WCF），这些服务在RIA服务中公开您的业务逻辑。因此，您在RIA Services实施方面有两个负责人。
Silverlight <---> RIA服务<---> EF模型<---> DB WCF服务<--->
我说如果主要目标是Silverlight应用程序，这个模型是有意义的，但是如果主要目标是WCF服务，我会挂起你今天拥有的模型。这有帮助吗？
..brad
我们正在研究完全相同的情况。现在，我们正考虑采用这种模式：
Silverlight < - > RIA服务< - > WCF服务< - >业务逻辑< - >实体框架模型< - >数据库
我们将能够以各种绑定方式托管我们的WCF服务。我们将使用从RIA到WCF的inProc调用来获取Silverlight应用程序。对于WCF服务的外部使用者，我们将使用wsHttp端点托管它们。
因此，在我们的场景中，我们充分利用了两者。 RIA服务成为我们应用程序的一组演示服务的一部分，减轻了Silverlight应用程序编程的负担（即异步）。缺点是我们增加了一个额外的层。
思考？