选择正确的.net技术[翻译]

原文出自：
《Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting》
Part II Chapter 10 Choosing the Right .NET Technology

    在这本书中，我一直强调一个原则，那就是每一个.NET技术都有一个理想的应用环境。为了构建一个成功的分布式应用程序，你不但要理解如何使用这些技术，而且要知道何时使用这些技术。

内部和外部系统
    内部系统是一个相对私有的软件，它管理着每日任务的某些部分，这些任务是商业运营中所必需完成的。它可以包括Bug跟踪功能、开发部门使用的项目管理软件，或者是客户销售跟踪和投资管理应用程序。在其中任何一个案例中，我们有两个选择：
    基于.NET Remoting技术的解决方案可以提供最快的通讯速度。当然，内部系统通常并不会停留在这种方式上。如果该系统是成功的，你通常需要一种桥，用以向其他系统提供功能（接口）。由于这个原因，如果你需要开放一些功能给第三方软件，基于XML Web服务的解决方案提供一种简单的整合途径。XML Web服务还提供一些ASP.NET服务，例如缓存一个验证，这样可以提高运行效率或者简化编码。无论基于两种技术中的哪一种，客户端通常使用 Windows Form创建，它提供了一个十分灵活的用户界面，允许你创建不同的应用类型，例如一个长期运行的系统托盘程序。

    提供给外部系统（例如电子商务商店）的功能可以依赖于ASP.NET或XML Web Service作为支撑。最关键的考虑是你是否需要使用离线架构，这种架构通过消息队列或者相似技术来实现客户请求的分配。如果你期望在高峰时间，有一个相对集中的大吞吐量，并且客户不需要即时的回应的话，这种离线架构使服务器的处理能力达到最大。

混合的内部/外部系统
    一些系统把XML Web服务和.NET Remoting结合起来，它们把.NET Remoting用于内部客户，而把XML Web服务作为与第三方软件或平台通讯的接口。这个方式是否成功，取决于能否保证XML Web服务和远程组件使用相同的服务提供者(Service Provider)组件来完成一个类似于体重物的过程，例如访问数据库。尽管XML Web服务和远程组件相互独立运行，它们仍然共享相同版本的服务提供者组件，如图10-6所示。

                                         图10-6


注：技术上讲，创建一个具有XML Web服务和远程对象共同性质的组建对象是可能的。你只要从MarshalByRefObject 派生一个类，从而允许提供.NET Remoting支持，并且添加<WebMethod>特性，创建一个.asmx文件来暴露Web方法。然而，这种方法是绝对不建议使用的。你仍然应该把组件独立开来。XML Web服务和.Net Remoting在处理问题上的微小差异，例如序列化，会为未来的开发增加麻烦。因此，我们应该把共享的功能放入独立的组件中。

通用的后端(The Common Back-End)
    混合系统的弱点在于，对于大数据量加载效率很低。例如，XML Web服务和Remoting对象之间连接无法被池化；另外，由于我们处理的是两个重复的对象实现，负载平衡会变得十分复杂。
    解决这个问题的一个方案是通过.NET Remoting 创建一个通用的后端处理组件，如图10-7所示。这个附加的层将导致附加的跨进程通讯，因此它会降低一小部分性能。然而，从长远来看这种结构更具有可伸缩性。

                                        图10-7


部分离线系统(Partially Disconnected System)
    部分离线系统包含一些无法保持长期连接的客户端，因此无法总是与服务器端组件交互。例如，你可以创建一个用于记录经常出差的员工的开销的程序，当计算机重新连接到网络时，这些费用报表会被输入中央数据库。另一个离线系统的例子是一种分配给第三方的工具。比如说，你可以能会为一些已授权的商人提供销售订单工具。然而，你不能够假设这些商人在使用程序时能够一直连接在Internet上，你也不能假设他们能够连接到他们的内部网上。
    在离线系统中，有不止一种方法可以用于通讯。一种方法是使用消息队列（如图10-8所示），在这个例子中，当连接恢复时，系统会自动发送消息，这种方法是有用的，它允许你使用与实时连接系统(Connected System)的客户端相同的设计来完成离线系统的客户端。无论在实时连接系统还是在离线系统中，一旦操作完成消息就会发出，唯一的差别在于Windows分发消息的方式。
    图10-8

在其他一些案例中，你可能会因为特殊的需求需要开发一个定制的解决方案。你可以创建一个应用程序，该程序不断查询连接是否可用或者等待用户手动告诉程序是否有一个连接可用。这种方法同email程序的工作方式一样。如果你在离线状态下发送一个email信息，然后退出程序，重新连接，在你重新加载程序之前信息是不会被发出的。
    一个最终的方法是创建一个专门的Windows服务，负责发送信息到中央服务的任务。这个服务将一直在计算机上允许，检查连接是否可用，如果可用，它会把存储在客户端的信息发送出去。这个方法概念上与消息队列类似。然而，你无法保证所有的客户端上安装了消息队列软件，并且被正确配置，这是非常常见的。

从COM升级
    在当今世界，分布式系统通常都需要从一个已存在的COM架构演化而来，.NET使这个工作变得相对简单。从COM到.NET的迁移是主要的工作，但是必须遵循一条准则，那就是采用分阶段的方式以保证系统能够正常工作。对于大多数机构来说，这意味着在一个COM和.NET组件混合的系统上花费大量的时间。
    当你升级一个传统的多层应用程序时，最好是从跟踪记录客户端应用程序开始，因为用.NET客户端与一个COM组件通讯要比用一个基于COM的客户端与. NET组件通讯简单得多。整合的第一阶段应该是使用ASP.NET或Windows Form重写表示层，如图10-9，你可以用.NET内建的COM交互支持来访问中间层的COM对象。
    图10-9
   
    由于客户端直接与COM层通讯，升级业务组件变得十分困难。另外，如果组件位于另外一台计算机上，你必须使用分布式COM(DCOM)来作远程通讯。下一个阶段则要把COM交互层放到服务器上，如图10-10所示。你可以通过使用XML服务或通过.NET Remoting开放出来的组件创建另一个.NET层，客户端直接和该层的.NET组件连接，该组件负责获得请求并从下层的COM组件中获得结果。
    图10-10
   
    最后一个阶段是使用.NET组件重建业务层，如图10-11所示。在最好的情况下，你应该可以一个一个部署你的这些组件，在客户端的代码不需要任何改动的情况下，你只需要更新.NET的XML Web服务层或者远程组件。
图10-11