应用像Visual Studio.NET（VS.NET）这样的高级开发环境的一个好处就是能够对应用和网络服务快速的发展和部署。开发应该保持干净的并且使用有文献证明的模式为你的用户和顾客保证一种可靠的生产环境。
对待某些开发技术的常用方法就是认识了解它们，这是因为有些东西能够用VS.NET实现，但这并不意味着这些都是必须实现的。这样的一个例子就是嵌套网络服务。
在这篇文章中，我们来看看嵌套网络服务的一些基本原理，并总结一下执行它们的时候会得到什么结果。
什么是嵌套服务？
嵌套网络服务就是调用了其他网络服务的网络服务。我们用到“嵌套”是因为次级的网络服务是在父类网络服务中调用的。如果一个父类网络服务引用了多个外部网络服务，这样就会出现一个树节点层次模型，其中那个父亲就是位于这棵树最顶端的父节点。
用VS.NET为了使这个模型更形象化，建立两个简单的ASP.NET应用程序，并对每个程序添加一个网络服务。然后我们规定父类应用程序为WS1，而那个嵌套在其中的程序为WS2。
虽然这个例子中的两个应用程序是以一台计算机作为主机的，但是我们要认为它们是在完全不同的公司中执行处理的相互独立的两部分，这两个公司是物理上分开的，只通过互联网交流通信，记住这一点是很重要的。
结论
在一个嵌套网络服务中，最少有三部分组成：客户，WS1，WS2。其中一些可能发生的问题是：
● 认证――在我们给出的例子中这三部分角色都有他们自己的验证方式。WS1应该能够对用户顾客进行验证，但是WS2将于用户顾客基本上毫无关系，所以也不能确认用户的可信性。
● 状态――对话/应用状态能否在所有情况下使用这个问题我们不用管，但是我们确定的是服务器的状态是不能转移的。也就是说，WS2不能利用WS1的服务器状态并取代其作用。
● 网络方法属性――网络方法的某些特性将可能导致它们之间的冲突。例如，为高速缓存的周期时间，缓冲区的响应以及处理执行设值的话，将会导致父类和子类网络方法之间的冲突
● 封装――方法标志，类名，或者某些商业逻辑可能需要返回给用户，以便他们正确的交互作用。一个公司如果不希望将这些处理展示给他的用户（WS1）范围以外的对象的话，那么他们就不需要对WS2进行管理。
● 自定义类――当类出现在方法标志中的时候，用户就可以看到这些类（如果它们是连续的话）。这样就通过嵌套式网络服务对用户化商业逻辑建立了依赖关系，这并不合我们的需要。
考虑一下多重嵌套网络服务的可能性。在WS2中再轮流调用其他网络服务，然后这个服务有调用其他的服务，如此循环下去是完全可能的。不用多久，这个调用链就难以控制管理了，这是就需要将他们分成一个个小部分，而这样很可能导致失败。
正确的设计
虽然应用嵌套网络服务会有所不利之处，但是在某些场合下这种方法还是有用的――提供了一种弥补潜在问题的设计模式。如果一个公司关在多个域中管理不同的应用程序，问题并不大，因为设计小组清楚地知道每个服务的特殊要求。
同样的，如果两个公司有着密切的联系，他们各自的特殊要求能够通过多重服务得到满足，那么失败的几率也会减少，这种情况下用嵌套方式也是可行的。
你也可以在设计你的网络服务器的时候拒绝用户自定义类，只提供使用到.NET框架中的对象的方法标志，保证你的客户能够对临时类有所了解。
