远程调用技术代码追踪(RO第三方控件).docx

最近阅读了 SocketConn 的源码和 WebService 的源码，把追踪的过程写了下来，方便大家学习。毕竟这需要精力，时间和毅力。感谢煮茶待英雄博志区和三层数据库讨论区兄弟们 的支持，特别是 julian 兄弟，不是他，我可能没耐心继续下去。如果有时间，大家可以继续完善。从 socket 和 Websevice 的底层实现细节，我们发现 BORLAND 的工程师们的构思和实现的过程。我觉得这对我们的学习应该是非常重要的。学会思考。学会读源码，学会分析。 希望和我交往的朋友可通过 QQ 或 Email 联系我。 Wu_yanan2003@ 另见： 《远程调用技术代码追踪(webservice) 》 《远程调用技术代码追踪(Socket) 》 《远程调用技术代码追踪(ASTA) 》 《远程调用技术代码追踪(RemObjects) 》 远程调用技术内幕 在前面我已经分析了 socket 和 webservice 的代码追踪。现在总结一下：三层架构的运作模型： BizSnap与.NET Remoting 的 Server 端运作模式 当 Client 将 Request 送达 Server 端后，会经过一个 Message Dispatcher机制，这个机制大多是几个重要的组件合作完成，主要在于解出Request 中对于所要求对象的描述，以及欲呼叫的方法等信息，有了这些信息后Dispatcher 就可以找到对应的对象与方法，接着就开始了呼叫动作，由于 Request 是 SOAP 讯息格式，并不能直接用来呼叫对象的方法，因此得先将SOAP 讯息转化为Stack(堆栈)，完成这个转换动作后就到了这种处理模 式中的核心概念了，也就是建立起目的对象并呼叫对应的方法，这个动作非常依赖前面的 Message To Stack程序，因为这个程序会将SOAP 讯息转化为Stack，有了 Stack 之后Push Stack and Call Method 动作才能正确的执行，那么如何呼叫目的方法呢?很简单， 只要利用该语言所提供的RTTI 信息(.NET 中则是 MetaData)，就可取得该方法的内存地址，接着只须以低阶的ASM 或 IL 所提供的 CALL 指令即可呼叫该方法，由于已将SOAP 讯息转为Stack，因此传入参数就不是问题了。在呼叫结束后，Stack 中已经有了传回的参数，接着只须将Stack 转回 SOAP 讯息传回给Client 端就可以了。 BizSnap、.NET Remoting 的 Client 端运作模式 不管是 BizSnap 或是.NET Remoting，当 Client 端欲呼叫 Web Services时都会经过一个Proxy Object，于 BizSnap中这个对象就是 THTTPRIO，.NET Remoting中这个对象就是RealProxy，由于这个对象属于静态的，因此在使用之前必需将其转型回目的对象的型别，当 Client 端下达转型动作后整个魔法就开始运行了，首先Proxy Object 会利用 RTTI 或是 MetaData 信息取得欲转型的类别信息，并依照这些信息建立起一个兼容于该类别的对象(Transparent Proxy Object)，接着将这个对象中的所有方法地址替换为Stub Method， Stub Method 做的事情很单纯，只是将Stack 转为 SOAP Message 后送出，当Server 端响应后再将 SOAP Message转换为 Stack 后返回，这样整个 Client 端呼叫动作就完成了， 下次再呼叫时只需由Cache 中取出这个已建立好的Transparent Proxy Object，就可以直接进行呼叫，这可以避免因反复以RTTI 或是 MetaData 建立 Transparent Proxy Object而失去效率。 BizSnap、.NET Remoting 的处理模式属于较低阶的方法，这种方法的坏处大于好处， 好处是设计者可以完全不了解其内部运作，以传统方式来撰写程序，坏处是过度依赖编 译器及平台，增加日后移植到其它语言或平台上的难度，另外使用动态产生对象类别的低阶技术很容易引发效率及内存管理的问题。 NET Web Services 与 Java NET Web Services 与 Java 的处理模式与.NET Remoting、BizSnap 大同小异，其间最大的不同之处在于这种模式利用了其语言的特性，采动态呼叫的方式来执行呼叫的动作， 而非如先前所提的模式在Stack 与 Message 之间进行转换，这种模式简单的在Client 端与 Server 端之间插入一个预先编译好的Proxy Object，这个Objec