Remoting & Version

1、客戶端版本高於服務器端

        1．1 VO(Value Object變化)

        以前版本（服務器端）：

        新版本（本地端口）：

        測試内容1：是否可以使用以前Value Object的方法。

        結果正常獲得結果。

        測試内容2：是否可以使用新的Value Object的方法。

        結果為返回Null，但是不會抛出任何異常。

       

        1．2新增加一個方法

        以前版本：

        新版版本：

        測試内容1：是否可以使用以前的遠端方法。      無異常抛出      成功申請一張ECTest的29號單。

        測試内容2：是否可以使用新增加的遠端方法。      和預期一樣抛出異常結束。

 

2、服務器端高於客戶端版本

        新版本：（服務器端）

        舊版本（客戶端）：

        顯然這種情況下不可能使用到新增加的功能（因爲根本無法通過編譯-_-||）

        2、1新的VO(value object)新增加一個方法后，調用以前的方法把VO作爲結果返回，並且調用其以前的數據。

        結果失敗，並且抛出異常。

        2、2服務器端增加了新的方法（沒有實際功能，只是爲了測試使用）而客戶端使用較低的版本調用以前舊有方法執行某些操作。

        結果正常，成功完成所有的操作。

 

3、    結論和初步的分析

        上面的測試毫無疑問是一個非常粗略的過程，實際上這個測試本身基於這樣一個假設：新版本承認以前版本提供的所有方法，他的修改只是改變實現，以及增加新的功能。不過我相信這個假設是具有一定的合理性的，因爲非常顯然，如果新版本本身已經不支持某一個方法，那麽必然會導致基於較舊版本的客戶端程序失敗。如果我們希望總體的IT系統可以做到SOA，那麽違反上述假設的變化應該是絕對不會發生才行。

        但是如果我們，仔細分析上面的測試的情況，會發現一些相當有趣的問題。作爲.NET Remoting Framework的基礎的兩種對象：MBV和MBR對於修改有著完全不同的行爲模式。

        從表象上來看（以是否抛出異常為標準），對於MBV來説，他可以容忍新的客戶端程序跑在舊的服務上（見1、1的測試），如果客戶端程序是基於較舊的版本開發，那麽不會有任何的問題。不過這個特性也帶來了一個暗藏的陷阱，如果客戶端基於較新的版本開發，那麽和不匹配的服務提供者合作，並不會報告任何異常，這樣就可能使得問題以一種非常奇怪的方式反映出來（甚至是在另外一個第三方的系統中-_-||）。

        對於MBR來説，情況比較正常了。他可以讓較舊的客戶端的程序跑在新的服務上，如果沒有調用新增加的功能，那麽反過來的情況也是允許的。總的來說，只要服務器上有描述和客戶端相同的方法，那麽版本就不是一個問題。

        如果我們深究一步，應該說這樣的現象和這兩種對象的工作方式密切相關。對於MBV的調用，代理会通過Formatter来完成对象拷贝。而对于MBR对象，代理则把所有的东西通过反射来进行。

        由此我们可以知道MBV对象的修改，将是一个非常重大的版本变化，因为它将导致所有的旧有系统工作失灵（假设旧有系统没有及时更新的情况下）。相反，对于MBR对象的修改就没有如此的惊天动地了，只要保证服务器的版本足够高，那么就不会有任何问题。

        尽管从版本的通用性角度来说，MBV对象处于一个相当不利的局面中。但是，基于性能的考虑，MBV依然是一个具有相当诱惑力的选择，毕竟除了第一次创建，这个对象可以提供和本地对象完全没有任何区别的性能。

        从对比的角度来说，使用Remoting技术在版本上造成的问题，相当轻微。毕竟和以前的COM、COM+相比，更新一个程序集是一件非常简单的事情，只要拷贝一个新的文件放在那里就可以了。如果使用一些简单配置文件，指导一下.NET平台的Loader，甚至更新完全可以做到透明进行。相对于Web Service而言，MBR对象也提供了完全相同的能力。如果考慮到，大多數人在使用Web Service時，通過的都是IDE自動生成的Class，並且包含在主程序集中，那麽Remoting的方式可能更加容易更新一些。