轉 我觀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總算是所有多層技術中，最簡單的之一了。

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

BTW：今天夏至，今年最長的一天。

2004年6月21日 12:07

href="http://borland.mblogger.cn/raptor/Services/Pingback.aspx" target="_blank" rel="external nofollow" rel="pingback" />

評論

說不了任何評論，因為三層我隻用SocketConnection，其他的連接配接的性能沒有做過，沒有發言權。

非常贊同一點，不能為了三層而三層。也不是什麼東西都是“萬金油”。看具體。

其實還是上次說：下棋低手和高手的差別，一個是要下成什麼模樣，一個是根據具體的分析使用什麼樣的模樣。

不知怎麼，我一直在重新審度C/S結構體系，确實能用C/S何必三層。C/S比三層有很多優勢。盡管三層，甚至分布式應用範圍廣。

嗬嗬，沒有發言權的我不再多說了。：〉

2004-6-21 12:24   by reallike--

# 回複: 我觀MIDAS

呵呵。 我在BLOG裡發的牢騷并不是想否定SOCKET CONNECTION

的大方向。 我想否定的是衆多人等為了三層而三層，不去分析一種技術的實質而盲目跟風。 确實，從DCOM的機理上來說， 我認為DCOM 已死， 除非是MS 再重新修改DCOM的實作，不過從MS的态度上來看， MS修改DCOM的積極性不大.

至于SOCKET CONNECTION， 大方向不錯， 但是BORLAND 的實作手段錯了，把好好的一個SOCKET CONNECTION 寫的沒有應用前景， 如果SOCKET CONNECTION 能夠應用完成端口技術重新寫過， 所需要修改的僅僅是它傳輸的資料包 IDATABLOCK的

格式， 在每個DATABLOCK的頭部加上 REMOTEDATAMODULE的位址或特殊HANDLE辨別即可， IOCP 是非常高效的， 如果這樣寫出來的中間層，中間層服務的CLIENTS 數目，将從0-200提高到0-1500， 這樣的性能我認為是有本錢和TUEXDO 拼一拼的

2004-6-21 14:27   by catchbug--

# 回複: 我觀MIDAS

老鳥，你做過TUXEDO服務嗎？

2004-6-22 1:55   by FS--

# 回複: 我觀MIDAS

M$的三層政策基本上分為兩個部分同步進行.

一是web service enhancement, 剛釋出WSE 2.0, 以soap為載體, 增加很多進階應用, 比如ws-trust, ws-security, ws-route, 涵蓋了事務, 安全性, 通路, 可靠消息等很多方面. M$用這個來先占領市場, 推銷他的SOA加構.

另一是indigo, 這主要是用來解決傳輸瓶頸問題的, 用一種低層次的基于二進制的協定, 是M$和IBM聯合設計的, 在設計的時候, 他考慮了由WEB SERVICE系統轉化的問題, 是以程式設計風格很象現有的asp.net web service, 都是用attribute的, 當更新的時候, 隻要把attribute改一下, 底層傳輸協定就由soap變成indigo了. 而且WSE的進階功能還保留. INDIGO計劃2004中旬完成, 将會內建到vs.net 2005裡去, 而且他會成為longhorn的首要消息機制. 

#  回複: 我觀MIDAS