.NET Remoting
.NET Remoting提供了一个功能强大、高效的处理远程对象的方法，从结构上而言，.NET Remote对象非常适合通过网络访问资源，而又无需处理由基于SOAP的WebServices所带来的难题。.NET Remoting使用起来比Java的RMI简单，但要比创建Web Service难度大一些。
什么是Remoting，简而言之，我们可以将其看作是一种分布式处理方式。从微软的产品角度来看，可以说Remoting就是DCOM的一种升级，它改
善了很多功能，并极好的融合到.Net平台下。Microsoft? .NET Remoting
提供了一种允许对象通过应用程序域与另一对象进行交互的框架。这也正是我们使用Remoting的原因。为什么呢？在Windows操作系统中，是将应用
程序分离为单独的进程。这个进程形成了应用程序代码和数据周围的一道边界。如果不采用进程间通信（RPC）机制，则在一个进程中执行的代码就不能访问另一
进程。这是一种操作系统对应用程序的保护机制。然而在某些情况下，我们需要跨过应用程序域，与另外的应用程序域进行通信，即穿越边界。
在Remoting中是通过通道（channel）来实现两个应用程序域之间对象的通信的。首先，客户端通过Remoting，访问通道以获得服务端
对象，再通过代理解析为客户端对象。这就提供一种可能性，即以服务的方式来发布服务器对象。远程对象代码可以运行在服务器上（如服务器激活的对象和客户端
激活的对象），然后客户端再通过Remoting连接服务器，获得该服务对象并通过序列化在客户端运行。
在Remoting中，对于要传递的对象，设计者除了需要了解通道的类型和端口号之外，无需再了解数据包的格式。但必须注意的是，客户端在获取服务器
端对象时，并不是获得实际的服务端对象，而是获得它的引用。这既保证了客户端和服务器端有关对象的松散耦合，同时也优化了通信的性能。
Remoting的两种通道
Remoting的通道主要有两种：Tcp和Http。在.Net中，System.Runtime.Remoting.Channel中定义了
IChannel接口。IChannel接口包括了TcpChannel通道类型和Http通道类型。它们分别对应Remoting通道的这两种类型。
TcpChannel类型放在名字空间System.Runtime.Remoting.Channel.Tcp中。Tcp通道提供了基于
Socket
的传输工具，使用Tcp协议来跨越Remoting边界传输序列化的消息流。TcpChannel类型默认使用二进制格式序列化消息对象，因此它具有更高
的传输性能。HttpChannel类型放在名字空间System.Runtime.Remoting.Channel.Http中。它提供了一种使用
Http协议，使其能在Internet上穿越防火墙传输序列化消息流。默认情况下，HttpChannel类型使用Soap格式序列化消息对象，因此它
具有更好的互操作性。通常在局域网内，我们更多地使用TcpChannel；如果要穿越防火墙，则使用HttpChannel。
远程对象的激活方式
在访问远程类型的一个对象实例之前，必须通过一个名为Activation的进程创建它并进行初始化。这种客户端通过通道来创建远程对象，称为对象的激活。在Remoting中，远程对象的激活分为两大类：服务器端激活和客户端激活。
服务器端激活，又叫做WellKnow方式，很多又翻译为知名对象。为什么称为知名对象激活模式呢？是因为服务器应用程序在激活对象实例之前会在一个
众所周知的统一资源标识符(URI)上来发布这个类型。然后该服务器进程会为此类型配置一个WellKnown对象，并根据指定的端口或地址来发布对
象。. Net Remoting把服务器端激活又分为SingleTon模式和SingleCall模式两种。
SingleTon模式：此为有状态模式。如果设置为SingleTon激活方式，则Remoting将为所有客户端建立同一个对象实例。当对象处于
活动状态时，
SingleTon实例会处理所有后来的客户端访问请求，而不管它们是同一个客户端，还是其他客户端。SingleTon实例将在方法调用中一直维持其状
态。举例来说，如果一个远程对象有一个累加方法（i=0；++i），被多个客户端（例如两个）调用。如果设置为SingleTon方式，则第一个客户获得
值为1，第二个客户获得值为2，因为他们获得的对象实例是相同的。如果熟悉Asp.Net的状态管理，我们可以认为它是一种Application状态。
SingleCall模式：SingleCall是一种无状态模式。一旦设置为SingleCall模式，则当客户端调用远程对象的方法时，
Remoting会为每一个客户端建立一个远程对象实例，至于对象实例的销毁则是由GC自动管理的。同上一个例子而言，则访问远程对象的两个客户获得的都
是1。我们仍然可以借鉴Asp.Net的状态管理，认为它是一种Session状态。
客户端激活。与WellKnown模式不同，
Remoting在激活每个对象实例的时候，会给每个客户端激活的类型指派一个URI。客户端激活模式一旦获得客户端的请求，将为每一个客户端都建立一个
实例引用。SingleCall模式和客户端激活模式是有区别的：首先，对象实例创建的时间不一样。客户端激活方式是客户一旦发出调用的请求，就实例化；
而SingleCall则是要等到调用对象方法时再创建。其次，SingleCall模式激活的对象是无状态的，对象生命期的管理是由GC管理的，而客户
端激活的对象则有状态，其生命周期可自定义。其三，两种激活模式在服务器端和客户端实现的方法不一样。尤其是在客户端，SingleCall模式是由
GetObject()来激活，它调用对象默认的构造函数。而客户端激活模式，则通过CreateInstance()来激活，它可以传递参数，所以可以
调用自定义的构造函数来创建实例。
远程对象的定义
前面讲到，客户端在获取服务器端对象时，并不是获得实际的服务端对象，而是获得它的引用。因此在Remoting中，对于远程对象有一些必须的定义规范要遵循。
由于Remoting传递的对象是以引用的方式，因此所传递的远程对象类必须继承MarshalByRefObject。MSDN对
MarshalByRefObject的说明是：MarshalByRefObject
是那些通过使用代理交换消息来跨越应用程序域边界进行通信的对象的基类。不是从 MarshalByRefObject
继承的对象会以隐式方式按值封送。当远程应用程序引用一个按值封送的对象时，将跨越远程处理边界传递该对象的副本。因为您希望使用代理方法而不是副本方法
进行通信，因此需要继承MarshallByRefObject。
在Remoting中能够传递的远程对象可以是各种类型，包括复杂的DataSet对象，只要它能够被序列化。远程对象也可以包含事件，但服务器端对于事件的处理比较特殊，我将在本系列之三中介绍。
服务器端
根据第一部分所述，根据激活模式的不同，通道类型的不同服务器端的实现方式也有所不同。大体上说，服务器端应分为三步：
1、注册通道
要跨越应用程序域进行通信，必须实现通道。如前所述，Remoting提供了IChannel接口，分别包含TcpChannel和
HttpChannel两种类型的通道。这两种类型除了性能和序列化数据的格式不同外，实现的方式完全一致，因此下面我们就以TcpChannel为例。
注册TcpChannel，首先要在项目中添加引用“System.Runtime.Remoting”，然后using名字空间：
System.Runtime.Remoting.Channel.Tcp。在实例化通道对象时，将端口号作为参数传递。然后再调用静态方法
RegisterChannel()来注册该通道对象即可。
2、注册远程对象
注册了通道后，要能激活远程对象，必须在通道中注册该对象。根据激活模式的不同，注册对象的方法也不同。
对于WellKnown对象，可以通过静态方法
RemotingConfiguration.RegisterWellKnownServiceType()来实现，注册对象的方法基本上和
SingleTon模式相同，只需要将枚举参数WellKnownObjectMode改为SingleCall就可以了。
3、注销通道
如果要关闭Remoting的服务，则需要注销通道，也可以关闭对通道的监听。在Remoting中当我们注册通道的时候，就自动开启了通道的监听。
而如果关闭了对通道的监听，则该通道就无法接受客户端的请求，但通道仍然存在，如果你想再一次注册该通道，会抛出异常。
如果你刚开是学 看几个例子就行了
remoting webservice 涉及到设计模式
现在很多公司都要求使用 remoting webservice来实现 面向服务架构(SOA)
解决方案让您更轻松地应对变更.无论您的流程多么复杂或缓慢,SOA都能够帮助简化它们,帮助组织实现快速变革,进而实现业务影响力.
一、Remoting的优缺点？
优点：
1、能让我们进行分布式开发
2、Tcp通道的Remoting速度非常快
3、虽然是远程的，但是非常接近于本地调用对象
4、可以做到保持对象的状态
5、没有应用程序限制，可以是控制台，winform，iis，windows服务承载远程对象
缺点：
1、非标准的应用因此有平台限制
2、脱离iis的话需要有自己的安全机制
二、Remoting和Web服务的区别？
ASP.NET Web 服务基础结构通过将 SOAP 消息映射到方法调用，为 Web 服务提供了简单的
API。通过提供一种非常简单的编程模型（基于将 SOAP 消息交换映射到方法调用），它实现了此机制。ASP.NET Web
服务的客户端不需要了解用于创建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客户端。唯一的要求是：双方都要认可正在创建和使用
的 SOAP 消息的格式，该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合约定义来定义的。
. NET Remoting 为分布式对象提供了一个基础结构。它使用既灵活又可扩展的管线向远程进程提供 .NET
的完全对象语义。ASP.NET Web 服务基于消息传递提供非常简单的编程模型，而 .NET Remoting
提供较为复杂的功能，包括支持通过值或引用传递对象、回调，以及多对象激活和生命周期管理策略等。要使用 .NET
Remoting，客户端需要了解所有这些详细信息，简而言之，需要使用 .NET 建立客户端。.NET Remoting 管线还支持 SOAP
消息，但必须注意这并没有改变其对客户端的要求。如果 Remoting 端点提供 .NET 专用的对象语义，不管是否通过
SOAP，客户端必须理解它们。
三、最简单的Remoting的例子
项目DEMO截图：
1、远程对象：
建立类库项目：RemoteObject
using System;
namespace RemoteObject
{
public class MyObject:MarshalByRefObject
{
public int Add(int a,int b)
{
return a+b;
}
}
}
2、服务端
建立控制台项目：RemoteServer
using System;
using System.Runtime.Remoting;
namespace RemoteServer
{
class MyServer
{
[STAThread]
static void Main(string[] args)
{
RemotingConfiguration.Configure("RemoteServer.exe.config");
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<system.runtime.remoting>
<application name="RemoteServer">
<service>
<wellknown type="RemoteObject.MyObject,RemoteObject" objectUri="RemoteObject.MyObject"
mode="Singleton" />
</service>
<channels>
<channel ref="tcp" port="9999"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
3、客户端：
建立控制台项目：RemoteClient
using System;
namespace RemoteClient
{
class MyClient
{
[STAThread]
static void Main(string[] args)
{
RemoteObject.MyObject app =
(RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings["ServiceURL"]);
Console.WriteLine(app.Add(1,2));
Console.ReadLine();
}
}
}
建立配置文件：app.config
<configuration>
<appSettings>
<add key="ServiceURL" value="tcp://localhost:9999/RemoteObject.MyObject"/>
</appSettings>
</configuration>
4、测试
在最后编译的时候会发现编译报错：
1、找不到app.Add()
2、找不到RemoteObject
这是因为客户端RemoteClient没有添加RemoteObject的引用，编译器并不知道远程对象存在哪些成员所以报错，添加引用以后
vs.net会在客户端也保存一个dll，可能大家会问这样如果对远程对象的修改是不是会很麻烦？其实不麻烦，对项目编译一次vs.net会重新复制
dll。
然后直接运行客户端会出现“目标主机拒绝”的异常，也说明了通道没有打开
运行服务端再运行客户端出现“找不到程序集RemoteObject”！回头想想可以发现我们并在服务端对RemoteObject添加引用，编译的时候
通过是因为这个时候并没有用到远程对象，大家可能不理解运行服务端的时候也通过？这是因为没有这个时候还没有激活远程对象。理所当然，对服务端要添加引用
远程对象，毕竟我们的对象是要靠远程承载的。
现在再先后运行服务端程序和客户端程序，客户端程序显示3，测试成功。
四、结束语
我们通过一个简单的例子实现了最简单的remoting，对其实质没有做任何介绍，我想通过例子入门才是最简单的。
本文转自：http://www.cnblogs.com/Leo_wl/archive/2010/05/06/1729264.html
每个人在他生活中都经历过不幸和痛苦。有些人在苦难中只想到自己，他就悲观消极发出绝望的哀号；有些人在苦难中还想到别人，想到集体，想到祖先和子孙，想到祖国和全人类，他就得到乐观和自信。 ——洗星海
