Marshaller的角色由Formmatter Sink完成，在Remoting中默认提供了两种Fommatter：一个实现了消息对象与二进制流的相互转换，另一个实现了消息对象与Soap数据包的相互转换，而支持Soap格式则说明Remoting具有实现Web Service技术的可能。
Client Request Handle与Server Request Handel都是.NET中实现网络底层通讯的对象，如HttpWebRequest、HttpServerSocketHandler等。在Remoting中我们并不直接接触这些对象，而是通过Channel对它们进行管理。在框架中默认提供了三种Channel：HttpChannel、TcpChannel与IpcChannel。但是在上面这副图中，我们并没有看到Channel对象，那么Channel又是如何影响网络底层的通讯协议的呢?
其实在上面这幅图中，真正能对通讯时所采用的网络协议产生影响的元素是Transport Sink，对应不同的协议Remoting框架中提供了三种共计六个Transport Sink：HttpClientTransportSink、HttpServerTransportSink与TcpClientTransportSink、TcpServerTransportSink以及IpcClientTransportSink、IpcServerTransportSink，它们分别放置在客户端与服务器端。既然Transport Sink才是通讯协议的决定元素，那么Channel肯定与它有着某种联系，让我们先暂时搁置此话题，留待后面进一步介绍。
观察上面这副图，我们可以发现其中包含了一系列的Sink，而所谓的Sink就是一个信息接收器，它接受一系列的输入信息，为了达到某种目的对这些信息做一些处理，然后将处理后信息再次输出到另一个Sink中，这样一个个的Sink串联起来就构成了一个Pipeline(管道)。
Pipeline模式在分布式框架中经常可以看到，应用该模式可以使框架具有良好的灵活性。当我们需要构建一个系统用于处理并转换一串输入数据时，如果通过一个大的组件按部就班的来实现此功能，那么一旦需求发生变化，比如其中的两个处理步骤需要调换次序，或者需要加入或减去某些处理，系统将很难适应，甚至需要重写。而Pipeline模式则将一个个的处理模块相互分离，各自独立，然后按照需要将它们串联起来即可，此时前者的输出就会作为后者的输入。此时，每个处理模块都可以获得最大限度的复用。
当需求发生变化时，我们只需重新组织各个处理模块的链接顺序，或者删除或加入新的处理模块即可。在这些处理模块(Sink)中最重要的两类是Formatter Sink与Transport Sink，也就是图1中的红色部分，当我们需要通过网络访问远程对象时，首先要将消息转化为可在网络上传播的数据流，然后需要通过特定的网络协议完成数据流的发送与接收，这正是这两类Sink所负责的功能。虽然它们本身也可以被自定义的Sink所替换，不过Remoting中提供的现有实现已经可以满足绝大多数的应用。
