我觀MIDAS

我觀MIDAS

剛看到DFW的達人王兄的《對Borland 和 N-TIER的牢騷》，發現今天的BLOG有內容可寫了:P

非常同意現在的系分、高手都很熱衷於趕時髦，或曰“浮躁”。我也見過非常非常之多人是在為了三層而三層，把簡單的問題複雜化，把沒必要做成三層的應用特地改成三層，結果得不償失，事倍功半。

但對王兄後面的一些技術性分析，我覺得還是有值得商榷之處。

首先，李維所說的：DCOM 的連線速度較SOCKET CONNECTION 慢， 但是串連完成後， 傳輸資料較SOCKET CONNECTION 要快。我覺得基本正確。要注意一點：這裡的Socket並非指Socket通訊，而是指Borland的SocketConnection。

問題在於王兄把DCOMConnection和DCOM混為一譚了。DCOM應用是一種相當於是遠端Automation應用，它是通過ORPC協議來傳輸IDispatch介面實現的。所謂的DCOMConnection便是基於DCOM的ORPC協議來傳輸MIDAS的IAppServer介面（它也是派生自IDispatch介面），而MIDAS（不止是MIDAS，DNA也一樣）並沒有限制DCOM串連（即ORPC）的服務端必須是DCOM應用，後來的MTS、COM+無一不是基於此，即便是現在.net的remoting也是基於此，它是在成熟的標準RPC基礎上，結合了Windows的安全機制發展的起來，最關鍵一點，它的底層協議也是TCP/IP（ORPC用了UDP和TCP兩個協議）。王兄所謂的淘汰之說，應該是指DCOM應用，而不是指DCOM串連吧。

不可否認，MS設計ORPC協議是完全基於Windows的域使用者安全機制，這決定了它有很多的限制，特別是因為用了動態連接埠，所以基本上是無法穿過Firewall（不表示不能，只要開啟Firewall的全部連接埠即可，但這樣的話Firewall就形同虛設了），但也還有其它辦法可以解決，典型的就是MS提供的基於IIS的CIS（COM Internet Services）技術，此外便是Borland的SocketConnection和WebConnection。

從本質上說這些穿過Firewall的技術都是所謂的Tunnel技術。即通過一對代理把ORPC的請求和響應轉為通過別的協議傳輸。其中CIS和WebConnection的本質都是用HTTP協議作為中間協議，而SocketConnection則是用TCP協議。如下：

DCOM Client ==[遠程介面調用/ORPC]==> Server（DCOM/MTS/COM+）

DCOM Client ==[本地介面調用]=> Client Agent(SocketConnection/WebConnection etc.) ==[中間協議：TCP/HTTP]=>Server Agent(ScktSrvr/HttpSrvr etc.)==[本地介面調用]=>Server（DCOM/MTS/COM+）

上面一個是標準的DCOM串連，下面則是Tunnel串連，因為Tunnel多了很多中間步驟，所以資料轉送效能一定比較差。但為什麼連線速度反而比DCOM快呢？因為ORPC有安全性約束，在串連時需要身分識別驗證，而用了Tunnel後，兩邊都是本地介面調用，不用安全身分識別驗證，所以連線速度比較快。但這樣的話就需要自己處理安全問題，如SocketConnection提供了Interceptor技術，而WebConnection則需要藉助於SSL。不過據我所知，絕大多數做這兩種應用的人都沒有考慮過這個問題（據說有人用代理獵手在網上搜211的連接埠號碼，居然找出一堆的地址，汗啊）。

正好前不久給一朋友幫忙，他為了安全考慮，需要改造WebConnection，所以對它的實現機制剛好還是比較熟的（不然MIDAS有幾年沒有用了，快忘記著差不多了）。王兄說WebConnection會導致效率大幅下降，這我同意，因為在WebConnection中需要對COM請求的資料進行Marshall並編碼為HTTP協議所需要的文字格式設定，到了httpsrvr中又要把HTTP的文本轉成本地COM調用。相對來說，SocketConnection的位元據效率肯定比HTTP的文本要高，更何況相比WebConnection用的HTTP這樣的應用程式層協議來說，SocketConnection用的底層的TCP協議，效能上也要好。但如果用了SocketConnection就必須要在防火牆上專門開一個連接埠供其使用，對於一些只能訪問Web的防火牆，就無能為力了。

至於基於XML和HTTP的SOAP/WebService，我也同意王兄的看法。基本上它的大多數優點，WebConnection都有（只是通用性和標準性不如SOAP），而且WebConnection用的BASE64編碼無論在時間效率和空間效率上都遠高於XML編碼。個人認為，如果不是必須要與異構系統互聯，SOAP/WebService還是應該避免的。

但王兄認為HTTP效率低下就完全不可取我不敢苟同。在一些情況下，用犧牲效率來換取高度的靈活性還是值得的，至於王兄所說的查詢出數M的資料，對於現在的網路來說，問題並不是很大，就算資料量再大也可以通過減少每次傳輸的記錄數來解決，畢竟使用用戶端的使用者一次能看的資料也是有限的。

拋開WEB防火牆的苛刻要求，SocketConnection不論是在效能上還是在靈活性上應該說都是比較好的選擇。但遺憾的是，Borland提供的SocketServer並不具有工業應用的能力，具體的王兄已經分析得很細了，我就不再贅述。但王兄因此否定SocketConnection我覺得不太妥當。

畢竟對於Borland來說ScktSrvr是一個隨DELPHI/BCB免費提供的小程式，不可能對它要求太高，拿Tuxedo來比是不公平的，Tuxedo可是BEA的主要賺錢產品之一，單一個Tuxedo就比DELPHI要貴了，沒有理由要求DELPHI免費配一個跟Tuxedo相當的產品。而Borland提供了ScktSrvr的源碼意義也正是在於：如果你需要很高的效能要求，完全可以自己參照著源碼用完成連接埠之類的更好的方法去修改它。

當然，就目前的情況來說，MIDAS並不能算是一個非常好的多層解決方案，不可能指望用一種多層技術去處理所有的多層應用情況（即所謂手裡有一把鎚子，看什麼都是釘子），但MIDAS總算是所有多層技術中，最簡單的之一了。

歸根到底一句話：技術不是根本，使用技術的人--這才是根本。