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

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

首先，李維所說的：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，我也同意王兄的看法?；旧纤拇蠖鄶祪烖c，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總算是所有多層技術中，最簡單的之一了。

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