建构分布式系统: .NET Remoting 篇
What＇s .NET Remoting
随着网际网路的普及化，企业对于软件的需求也趋向复杂化与多样化，为了满足
这些企业的需求，分布式系统也应运而生，分布式系统指的是将软件组件化，放置于
不同的Server 中，前端应用程序再经由网路來使用这些组件。由于分布式系统具备经由
网际网路來使用软件组件的能力，因此能够符合中大型企业对于整合海内外分公司管理
系统的需求，另一方面由于软件已组件化，相对的其重用性与延展性也会大幅提升。
.NET Remoting 就是这類型的分布式技术，原本Microsoft 设计.NET Remoting 的初衷是
希望她能取代DCOM 的地位，但事情并没有这么顺利，基于Security 及对象生命周期
管理等机制的相異性，目前的.NET Remoting 仍然无法完全取代DCOM 的地位。
虽說如此，.NET Remoting 丰富的特色依然吸引了不少设计者的注目，其中最主要的
特色莫过于其高度的延展性，不同于DCOM 的封闭式架构，.NET Remoting 中的绝大
部份组件都是可延伸的，设计者可自行撰写这些组件來延伸.NET Remoting 的能力，
这点对于日渐复杂的分布式系统是相当有用的。
Web Services VS Remoting
在.NET 中，Web Services 的光芒几乎完全盖过了Remoting，原因不外乎是
Web Services 所代表的是一个规格，一个系统整合的契机。利用Web Services 技术，
设计者可以轻易的整合不同的语言及平台，这点在以往是很难达到的，另一个
重点是Web Services 代表着一个宣示，宣示新网路服务时代的來臨，为网际网路
开启另一个商机。那么既然Web Services 有着这么多的好处，那么为何还要提出
Remoting 呢??答案很简单，Web Services 虽然拥有许多优点，但同时也存在着许多
的缺点。Web Services 为了达到高度兼容性的目的，使用了SOAP/XML 來做为沟通
的讯息标准，而SOAP/XML 是使用纯文字模式來呈现，这代表着讯息必须要花费
较多的时间來传输，因此程序的效率自然也会减低。另一方面是规格的问题，由于
SOAP 规格目前依然在持续演进中，许多重要的课题如Stateful Object、Call Back、
Security 等规格都还未完全定案，当然架构于SOAP 之上的Web Services 应用范围也
受到了限制。反观Remoting 则没有这些问题，由于这是由Microsoft 所独立提出并
实作的架构，因此自然没有规格上的束缚，Microsoft 可以视设计者或自身的需求來
加入新功能。在效率上，Remoting 除了提供了与Web Services 一样的SOAP 讯息格式
之外，另外还提供了Binary(二进制)讯息格式，与纯文字的SOAP 讯息格式相比，
Binary 的讯息量明显小了许多，因此应用程序可以获得更高的效率。Remoting 的另一个
主要特色则是其高度的延展性，Remoting 是一个完全开放性的架构，允许设计者为其
添加特殊的功能，例如设计者可以自行撰写Transport Channel 对象來提供不同的传输
接口(例如SMTP、Windows Message)，也可以撰写Message Formatter 來使用不同的讯息
格式(例如编码过的Binary/SOAP Message Formatter)，设计者甚至可以撰写Proxy 对象來
參与Remoting 核心的运作。那么看起來Remoting 似乎比Web Services 好啰??当然不是，
这兩种技术所满足的层面是不同的，Remoting 是针对企业内部的应用，这類系统通常
只挶限在企业内部，例如将一些商业对象撰写为Remoting Object，放置于总公司的Server
中，总公司/分公司的UI 系统再利用Remoting 技术來存取这些商业对象。Web Services
则可以满足企业对外的需求，例如Amazon 提供了搜寻书籍的Web Services 供其它网站
使用，或是信用卡中心提供信用卡确认的Web Services 供电子商务使用(这有安全性
问题，目前相信还没人敢如此做⋯)。那么该如何选择兩者呢??这点要视系统的需求
而定，笔者在后面列出了Web Services 与Remoting 的特色，讀者可以參考表1 來选择
系统所需要的技术。
(表1)
ASP.NET Web Services Remoting
高兼容性，可整合不同语言与平台。低兼容性，只能在.NET 语言与.NET 平台上使用。
使用SOAP/XML 讯息标准，网路流
量较大。
可选用Binary 讯息标准，网路流量较小，设计者可
自行延伸，支持共存模式(Multi-Message Formatter)。
不支援Call back，Stateful Object。 支援Call back，Stateful Object。
目前只支持HTTP 传输接口，理論
上可使用其它接口。
支持TCP、HTTP 传输接口，设计者可自行延伸，
支持共存(Multi-Transport Channel)模式。
架构较无延展性。 高延展性，设计者可自定Transport Channel、Message
Formatter、Proxy。
PS:表中所列出的是一些笔者认为会影响设计者选择的特色，因此主观性较强烈。
.NET Remoting 的架构
(图1)
图1 是.NET Remoting 的大致架构，以Client 端來說，当程序要求取得一个Remoting Object
时，实际上所取得的是一个Proxy 对象，这个对象存在于Client 端的计算机上，拥有
Remoting Object 的所有方法与属性，Client 端对这个对象的操作都会被重导至位于Server
端的Remoting Object 上。图中的Formatter 部份是讯息格式对象，.NET 中提供了
SOAP 与Binary 兩种讯息格式对象，Client 端对Proxy 对象的操作最终会被转换为
讯息后经由Transport 传至Server 端，Server 端再由讯息转换回操作反应到Remoting Object
上，这个讯息转换的动作就是藉由Formatter 对象的帮助來完成的，Formatter 对象在
这些动作中是扮演讯息讀取与写入者的角色，例如程序需要传递一个对象时，只须呼叫
Formatter. Serialize 将对象转为讯息，反之则呼叫Formatter.Deserialize 由讯息转回对象。
Formatter 是可以共存的，这代表着设计者可以撰写出一个同时支持SOAP、Binary 兩种
讯息的Remoting Server，日后的章节对Formatter 会有更详细的讨論。Transport 部份
代表着传输层，.NET 提供了HTTP 与TCP 兩个Transport Channel，与Formatter 相同，
传输层是可以共存的，这也就是說设计者可以撰写一个同时支持HTTP、TCP 兩种
传输协议的Remoting Server。Dispatcher 部份则是Remoting 的核心对象群之一，这些
对象负责建立Remoting Object 的实体与生命周期管理，在Dispatcher 的一連串动作中，
设计者可以藉由Message Sink (日后会讨論到，现在请将她视为一种事件，供设计者
针对一些动作做出反应)來參与这些动作，Dispatcher 的动作相当复杂，其中更牵扯到
了许多与CLR、JIT 互动的技巧，日后笔者会再详述这部份。经由上面的讨論，我们
可以說.NET Remoting 是一个完全开放性的架构，设计者可以藉由撰写不同的对象來
改变或延伸这个架构。
兩种Remoting Object，SAO 与CAO
.NET Remoting 允许设计者撰写兩种類型的Remoting Object，一种是较常見的
SAO (Server Activate Object)，另一种则是CAO (Client Activate Object)，这兩者最大的
区别在于SAO 是无狀态的(Stateless)，Server 端不会为某一个呼叫者保存狀态，简单
的說就是Client 端无法得知前次呼叫与这次呼叫的对象是否是同一个，亦或是兩次
呼叫期间对象的狀态是否被其它的呼叫者所改变。CAO 则是具狀态的(Stateful)，
Client 端所取得的CAO 对象是依存于Client 端的，前次呼叫与这次呼叫永远是同一个
对象(生命周期会影响这个结果)，兩次呼叫间也不可能有另一个Client 端改变对象的
狀态，因为不同Client 端会有不同的CAO 对象实体。
.NET Remoting 下的程序架构
在.NET Remoting 下，设计者可以选择不同的程序架构，这些架构各自有其优缺点与
适合使用的地方，这一节中将介绍笔者常用的兩种。
Share Interface
简单的說就是由Remoting Object 提鍊出一个接口(Interface)，并将其写在一个
DLL(Assembly)中，再由位于Server 程序中的Remoting Object 实作这个接口，这种架构
的好处是可以完全隐藏Remoting Object 的实作面，Client 端只需要有内含Interface 定义
的DLL 就可以取用Remoting Object。坏处是这种方式无法直接作用于CAO(因为你无法
建立一个Interface)，需要藉助Soapsuds 产生Wrapper Classs 或是实作Design Patterns 中的
Factory Method 來完__ 9__成。Share Interface 是多
