Question

我们在培训课程中学习的金融风险系统案例的关键功能需求之一是解决方案应该能够分发数据到企业局域网用户的一个子集。显然有很多种不同的方法来解决这个问题，其中最简单的是允许用户通过一个内部的Web应用程序访问数据。既然只有组织内用户的一个子集应该看到数据，任何解决方案对数据都需要某种形式的认证和授权。

鉴于最近围绕Web 2.0和富互联网应用的传言，培训班里有一个组认为允许通过微软Silverlight应用程序访问数据会很不错。他们已经想过构建一个ASP.NET应用程序，但又喜欢Silverlight提供的更多可能性，比如交互式地切割数据。他们这个决定的另一个驱动因素是Silverlight客户端可以“免费”提供，花费的时间“和构建一个ASP.NET应用程序是一样的”。“免费”是一个非常大胆的观点，特别是考虑到他们有效地向软件系统中添加了一个额外的架构层。下面是我画的他们设计的概况，用以说明增加的复杂度。

虽然我不认为Silverlight应用程序不难构建，然而小组没有指出的关键问题是数据从哪来。像往常一样，有一些选项；从直接访问数据数据库，到在中间层暴露一些数据服务。

小组已经考虑了在IIS（Internet Information Services，互联网信息服务）Web服务器上部署一些Windows通信基础（WCF，Windows Communication Foundation）服务，作为数据暴露机制，但这导致了更多的问题。

1.你需要向Silver客户端暴露什么操作？

2.你会使用哪些技术捆绑和协议？

3.你如何确保人们不能插入自己定制的WCF客户端并消费服务？

4.如何部署和测试？

5.其他。

非功能需求

在这个案例学习中，第三个问题很重要。数据只应该被一小部分人访问，我们确实不想暴露一个任何可以访问开发工具的人都能消费的Web服务。

大多数安全意识很强的组织会在自己托管的对外Web服务器和隔离区之间部署防火墙，但我也见过一些软件系统，同样是那些受保护的Web服务器随后去访问正常的企业局域网内部服务器上部署的未受保护的Web服务。假设我的笔记本电脑能连接到企业局域网，通常就没有什么能阻止我打开微软Visual Studio之类的开发工具，定位到服务定义（比如一个WSDL，Web Services Description Language，Web服务描述语言文件），以不正当用途消费Web服务。在这种情况下，必须考虑数据服务的认证和授权，Silverlight客户端也是如此。这需要对安全有全面的考虑。

时间和预算：没有什么是免费的

回到构建Silverlight客户端不会比构建ASP.NET应用程序更花时间的断言，其实这不可能，因为需要开发额外的数据服务来支持Silverlight客户端。在这种情况下，额外的富客户端层带来收益的同时，也要考虑到额外引入的复杂度。所有的架构决策都少不了权衡。更多的可移动部件意味着更多的设计、开发、测试和部署工作。不管厂商的市场炒作会怎么说，从来没有什么是免费的，你需要评估给设计增加额外层的优缺点，特别是如果它们产生了额外的进程间通信。