微软的远程处理框架.NET Remoting(1)

微软的.NET Remoting提供了一种允许对象通过应用程序域与另一对象进行交互的框架。本文将通过两个具体的代码例子介绍它的特性，通过.NET Remoting，两个应用间的通信将变得非常简单，使用上也相当灵活。
  
  
  　　最近几年来，在计算机世界中，关于“向外扩展”（scale-out）与“向上扩展”（scale-up）的讨论不断，并且有向scale-out转化的趋势。在以前，当计算机跟不上应用对性能的要求时，人们将会购买一台更好更昂贵的机器，这就是scale-up，而scale-out则是通过在网络中加入更多的机器来解决这个问题，这样就无需更换整个系统。通过将计算的负担分配在多个系统中，整个系统就有了更高的可用性。
  
  　　如果将这个scale-out的意念更推进一步，我们可能会发现：为什么要将诸如信用卡验证和运送跟踪的处理放在我们的系统呢？如果能够调用售卖者的应用来直接得到这些服务，岂不可以做得更为简单吗？如果能做到这一点，我们就可以扩展自己程序的功能，而无需再加入额外的硬件。值得注意的是，这样做将会另ISV（独立软件开发商）的角色由一个软件提供者，转变为一个服务提供者。
  
  　　这个想法很好，但是目前的技术要实现它的话，存在着不少的问题。DCOM在跨防火墙工作时会有问题。DCOM是建立在私有协议上的，而CORBA存在有多种不同接口的问题。如果将DCOM和CORBA放在一起工作呢，就更麻烦了。
  
  　　为了实现这个scale-out的想法，我们需要一个组件技术，它可以跨越多种类型的网络和多种协议无缝地工作。远程.NET就可以做到这一点。
  
  　　这个无缝的交互是通过使用XML和SOAP来实现的。不过，它并没有认定SOAP进行组件交互的唯一方法，它也并没有认定HTTP或者TCP/IP是用来连接这些服务的网络协议。这样可令远程架构更加灵活，并且可适应协议和网络的变化。
  
  　　.NET架构是使用channel对象将应用连接在一起的。.NET架构提出了两种channel，它们是：
  
  　　System.Runtime.Remoting.Channels.TCP
  　　System.Runtime.Remoting.Channels.HTTP
  
  　　TCP channel和现有的DCOM非常类似，可提供很高的性能，在机器都处在一个内部网络时，可选用TCP channel，而HTTP channel使用HTTP协议，可让应用在Internet上交互。由于它使用的是HTTP协议，它可以很容易地做到负载均衡，并且能通过防火墙。