CORBA宗師Steve Vinoski

       在QCon舊金山2007大會期間，InfoQ的編輯Stefan Tikov采訪了CORBA宗師Steve Vinoski，就他對REST的關注，使用CORBA的場景，以及分布式系統中描述語言的角色等問題做了深入的探讨。其他主題還包括了解多門語言的好 處，Erlang在建構分布式系統時的好處等。

個人簡介

        Steve Vinoski是一家美國創業公司Verivue的技術員工。他被公認為是CORBA領域裡世界領先的專家之一，在加入Verivue之前他在IONA呆 了10多年之久，是IONA的首席架構師和創始人之一。此前他還在惠普、Apollo計算機和德州儀器等公司從事過軟體和硬體相關的工作。

         今天我采訪的是我兒時的偶像之一Steve Vinoski。這些天您在忙什麼？ 

         現在我還不能說我的公司是做什麼的。二月份我離開了IONA公司，出于保密的原因，新公司的創始人不想對外界透漏太多相關的情況。但是我可以告訴你，現在我很快樂。就像呼吸了一口新鮮的空氣。相比于我在IONA的那十幾年，這種感覺是非常不同的，充滿了快樂。

        這個新公司跟中間件或者新型分布式對象相關嗎？

        不相關，完全不同的領域。你也知道，我是硬體工程師出身，是以公司裡有一些搞硬體的朋友，這倒有點追根溯源的意思。我現在并沒有從事硬體相關的工作，而主要是做中間件。我已經從一個供應商過渡到使用者的角色了。

也許有人會說這些已經展現在你的部落格中了，那些内容現在還可以看到。您過去曾批判過供應商、中間件、WS-*和ESB等，能展開談一談嗎？ 

         我想如果你回頭看一下我四年前發表在《網際網路世界》（Internet Computing）上的文章（其實我的第一個REST專欄是5年前寫的），就會發現我的有些觀點是“将WSDL用作抽象是做事情的好方法”，還有些是 “這些（技術）還沒有被真正地标準化，有那麼多的規範，那麼多的供應商戰争和摩擦。”。說實話一直以來我真的看不慣這些事情，但由于身在IONA，礙于多 種原因我不能講出實話，因為那是公司的事情。但一旦這個負擔被拿走了，我就可以說說我的真實感受了。其實和從前我所說的差别不遠，隻是現在所言全是實話， 沒人給我壓力。

        如果您現在是一個大型公司的架構師，要為一整套系統或者一個大型分布式系統設計架構的話，您會選擇什麼技術？ 

        我想我會先看看REST。如果你研究一下SOA，你會發現它主要關注業務和文化，裡面都是談我們如何整合業務，如何使事物能彼此合作，如何制作共享組 件，以及如何避免重複勞動和雇員多餘等等問題。SOA關注的重點是文化，而不是技術架構。有些人在談論技術SOA，但是技術SOA還是依靠現在我們所用的 産品，因為每一個産品都是不同的。從技術角度來看，SOA還沒有具體到讓這些産品看上去都一樣的地步。轉而來看REST，它就是一個全新的架構類型，全是 關于規約以及如何從這些規約中找到價值的方面。有些人已經将大量的規約用于分布式系統，并取得了可喜的成績。那麼為什麼我認為我可以做的更好呢？因為我從 前做過類似的工作，如果必須使用那些規約的話，我也能設計得非常松耦合。在我看來，如果單純考慮工程造價的話，REST是有意義的。

        談談您會使用CORBA的一些場景吧。 

        在确實需要和正在（或已經）用CORBA編寫的應用互動時，我會用CORBA。我從1991年就開始用CORBA，現在還在用，在最近我和Michi Henning寫的一本書裡面對其做了反思。雖然CORBA現在不如過去應用的那麼廣泛，但是我還沒有完全放棄它的想法。有許多領域仍然在用CORBA， 那些接口也不會明天馬上消失，在未來的5到10年裡它們還會存在。如果需要和那些用CORBA建構的系統互動，我肯定用CORBA。另外如果我正在開發某 個小規模系統，而且開發人員對CORBA比較熟悉，我也會選擇用CORBA。但是如果要建構一個企業級系統，我會選擇REST。

        假設我們要讨論一個不同之處，一個在讨論REST時經常被提及的問題，比如在REST論述（指Fielding博士關于REST的論文）中沒有定義任何描 述和契約定義，隻有一個通用的定義。而在這一點上，CORBA對IDL的依賴非常強烈，您覺得這是CORBA的一個問題嗎？這是CORBA所缺失的特性 嗎？ 

        關于你的這個問題，我過去也有很多的想法。在CORBA裡，一個人可以從事的層面和領域很多，也很明顯。我幾乎幹過所有事 情，但是在我從事CORBA工作時，我大部分時間專注于IDL和将它映射到其他語言之上。至于為什麼這樣，我想是可以了解的。我知道有很多人對于了解C+ +映射方面存在問題，但那它（即C++映射）是為C++高手所寫的。我個人對此沒有什麼困難。如果你隻知道IDL的使用方式就去用它定義一個接口，這就會 有問題。那種方式并不能正常工作。沒有人在使用IDL時會說“就是這個方法，我要調用它，傳遞它。我隻需要看一下IDL就知道要做什麼。”

        沒有人會這樣做。IDL隻是用來代碼生成。如果我想知道如何使用一個服務，不論它是否有IDL，隻要開發人員在旁邊我就會去問他們；如果他們不在旁邊， 我就去看文檔。比如打算使用Amazon、Google或者其他站點的REST服務，我就去找它們在網上的文檔，然後閱讀和查找。我不曉得擁有一個IDL 是否真的有用。現在這個接口被修正了，成為一個HTTP動詞（Verbs）。你需要處理資料定義，而資料定義和媒體類型通常被注冊的IANA類型所定義。 如果你想知道這些資料如何展現，那麼就去看看那些媒體類型或者MIME類型。我不認為你的問題和分布式對象的CORBA風格是同樣的問題。

        我聽說現在的争論焦點之一是：如果你使用的是一門諸如Java或者C++這樣的典型靜态類型語言，那麼當你建構那些在調用過程中需要交換的對象時，從代 碼生成那一步所得到的對象就得是類型安全的。如果你沒有一個可以生成代碼的描述語言的話，在你的IDE裡面就不會有代碼實作，你也不會有我們過去習以為常 的東西。 

       我猜是有這樣的情況，但是我不使用IDE。從前在我的部落格評論有人說“你應該使用IDE，你應該嘗試所有新的事物”， 就這個問題我從前還和一個同僚讨論過。但我一直使用Emacs。我曾經試用過Eclipse，有些工作它做的真的很棒，但是我想我現在隻是一條“老狗”。 回到你說的這個類型安全的問題，你最好稱它為“僞類型安全”，因為我可以将一個在用戶端應用上假定類型安全的消息傳遞到你的伺服器上，而你的伺服器能通過 完全不同的定義進行編譯，還能夠離線讀那些位元組，換句話說它們看上去符合你的消息定義，而其實兩個定義可能是完全不同的。對于你的對象、服務或者其他任何 我能通過使用IDL得到的類型安全也是如此，現實中它們可能都有完全不同的類型，但卻不是在我的用戶端上，原因是它是完全分布式的。你的版本變更可能和我 的變更有所不同。是以你最好稱它為“僞類型安全”。但是我認為名稱的變化改變了整個等式（譯注：之前的“類型安全”隐含對象必須在分布式系統中各個部分都 是相等的，但是改為‘僞類型安全’之後，這一等式不再成立，隻需要系統中傳遞的消息契約一緻即可。），因為你是在建構一個分布式系統，而不是建構一個本地 程式然後分發之。而且在建構分布式系統的時候，你恰好使用你選擇的語言寫了一些這個系統的部分程式。我想我們應該關注分布式系統，而不是考慮哪個語言在編 寫這個系統時更容易使用。我知道很多人不同意我的觀點。

       我知道您花了很多時間來讨論動态語言，能多講一些這方面的事情嗎？我很難想象一個C++老程式員會忽然轉到Ruby上來。  

       你這兒說的“老”是指我從1988年就使用C++對嗎？而不是說我年齡已經很老了……：）我使用C++确實有些年頭了，但是很久以來我也是動态語言的粉 絲。我的專業是電子工程，從來沒有上過什麼計算機科學課程。是以我一直感覺應該自己學習一些關于計算機科學方面的知識，回想我當年自學程式設計語言（主要是C 和C++）的時候，因為身處硬體組是以周圍沒有人和我交流程式設計方面的想法。在1987年我加入Apollo計算機公司時，我開始接觸軟體人員，但是他們主 要是嵌入式開發者，大多數人使用彙編語言，也有部分人使用C。當時我使用C++對其他人而言是很反常的行為，要知道在那個環境中即使用C也算得上是激進分 子了，而C++則完全不在考慮之列。

        沒有人交流可能會讓我錯失了一些東西，現在想想我當時應該多看幾門語言，而不僅僅是C++和 C等。我一直堅持自學語言，幾乎什麼都看。雖然我沒有用它們開發過真實的應用，但是至少我閱讀了很多相關的書籍。我還學習了使用Unix，那是一台硬體測 試機器，上面跑的是Berkeley Unix作業系統。當時我是什麼都學，Unix的很多工具，如greps、seds和awks等。後來Larry Wall推出了Perl，我看過之後驚呼，“哇，這些都是我曾經學習過的，但一個語言全包括了”。1988年我将Perl移植到Domain OS上，也就是Apollo的作業系統，我想現在你可能還能拿在Perl源代碼裡找到我的名字。是以說，我在學習使用C++時就接觸到了動态語言。對我來 說，它不是一個新事物，我用了很久了。

       您說現在更傾向于使用REST，而不是CORBA，對于語言的選擇也是如此嗎？現在您更傾向于使用Ruby或者其他動态語言，而不是C++或者Java嗎？ 

       我确實傾向于首先看看那些語言，雖然有時候它們并不是正确的選擇。我喜歡做的是将多個語言放在一起，對着某個問題問自己“有沒有解決這個問題最簡單的方 法？哪個語言能夠做到？”。不僅僅是能夠解決這個問題，還要最易于後期的維護，最易于擴充等。一般而言，我先看問題域，然後看看工具箱裡的語言，然後選擇 正确的那個。我之是以有點偏愛動态語言，是因為它們确實很強悍，也很簡潔。你用它們寫出的程式要比用Java、c++或者C小的多，而且能做同樣的事情。 它們也很快。有人常說動态語言很慢，但是這不是事實。有些比較慢，有些不是。Python就非常快。我并不是要抛棄Java或者C++。說實話，我不是 Java的忠實粉絲，因為如果我要程式設計解決什麼問題時，我會選擇C++。如果要選擇和C++完全不一樣的語言，我會選擇動态語言。于我而言，Java和C ++沒有太多的差別。

      我發現最近一段時間您在玩Erlang。我不知道這兒使用“玩”這個詞是不是确切，因為我了解到您在實作Tim Bray的Wide Finder。能給我們大體地講一下Wide Finder問題的背景，以及使用Erlang的經驗嗎？ 

       實際上我結緣Erlang已經有十幾年的時間了。過去我一直沒有使用過Erlang，但是近兩年我開始看一些相關的參考文檔。一般情況下，如果有人告訴 我說“有個語言你應該注意一下”，那麼我的第一反應是“好，我會看一下”。如果我在這個語言上沒有發現很實在的東西，我會回到我手頭的工作。這次也不例 外，Erlang吸引我的地方是它的可靠性和并發性方面。作為一個長期從事中間件程式設計的開發者，我會花很多時間來确定這些語言是否具有很好的生産力。傳遞 消息，分析資料等這些其實都是很簡單的地方。

        當某個東西需要長時間運轉的時候，你需要預防節點股障問題，或者需要容錯性、安全保 障以及需要花時間處理的并發性問題等。比如我鎖定了一個資料，需要跨線程共享，這時如果丢失一個的話，事情就很糟糕了。這兩點是始終伴随中間件開發人員的 兩大難題。在我研究Erlang的時候發現它是内置的。是以這也許需要多一些的調查，是以對Erlang我一直保持關注。我在IONA工作的時候，我正在 實作進階消息隊列協定，現在Apache的Qpid項目也在做。在那時，有些人請我給這個進階消息陣列協定增加容錯性，我回答他們說“如果你需要容錯性， 那麼你應該用Erlang，那會省掉很多麻煩。”

       兩周後，有家叫RabbitMQ的公司釋出了一個AMQP的Erlang版本， 很明顯他們在這方面已經做了很久。現在這個項目還在，很多人都在使用。我當時想我不能離這個東西太遠，這時Tim的Wide Finder出現了。Tim Bray是Sun的一個員工，他想分析他的網絡日志，可能最小的日志都要1/4G那麼大，有很多資料需要分析。他認為“Sun有新的機器出來了，我應該如 何用像Erlang這樣的語言去并行分析這些資料呢？”于是他寫了一個Erlang程式，但是他對它并不滿意。如果現在你去看他的部落格，你能看到他很不 爽，他認為Erlang并不是人們所吹噓的那麼厲害。

       看到這件事情，我想我也許能做得更好一些。于是就開始做，Erlang社群 裡的其他人也是如此。然後就看到處理時間不斷地下降。我想Tim在分析這個資料集時所用的時間應該是30~40秒。我将它降低到2~3秒。而有個家夥最後 竟然将這個時間降低到0.8秒。我想現在Tim系統的最快實作是另一個函數語言Ocaml實作的，第二名是Python，Erlang次之。許多人說 Erlang不能處理檔案的輸入輸出并引以為诟病，但是很明顯這不是事實，因為它能處理這些巨大的資料檔案，而且速度名列前茅。

        您認為像這樣的事情會繼續下去嗎？也就是說語言會變得更加強大，而不是說一門擁有大量類庫、工具或者中間件什麼的通用語言。語言要包含我們在類庫中期望的功能是一個趨勢嗎？ 

       類似的事情在多核系統的并發領域有很多。當你有兩個核的時候，将你原來的程式扔到那個機器上，不會有什麼問題。但是當你有八個核的時候，事情就變得很有 意思了，因為你會發現有的核在你運作程式的時候是空閑的。如果你沒有選擇合适的語言去利用它們，那麼你的應用就隻能使用其中的某一個核。作業系統不會幫你 處理這些，因為它不會拿着你的應用然後為你拆分到其他核上。你必須明确地将它進行多線程處理。在Java和C++語言中，現程是相當重量級的。即使它們比 程序要輕量一些，也是很重量的。而像Erlang或者類似Erlang的語言都有輕量級的線程，在我的Mac筆記本上可以輕松地跑 50,000~60,000個線程，很酷。它是一門非常特别的語言。

        下面我們看看面向對象和函數語言，現在函數語言好像要複蘇 了。我不清楚這背後的原因，也許是因為它們很小巧，但是卻可以用很少的代碼處理很多的事情。甚至像Ruby和Python這樣的語言都有函數的一面，也許 這是一個驅動因素吧。我還認為現在語言設計和人們對語言的了解也有“複古”的趨勢。過去一直将C作為進階語言的彙編語言，不僅C++而且Python、 Perl等都是在C上建構的。Java目前也有這個趨勢。Java就像JVM的彙編語言，它已經成為很多語言的虛拟機，比如Scala、Groovy和 Jython等。人們看上去在朝兩個方向前進，其實殊途同歸：建構更小的語言，然後基于這些通用語言更好地解決特定的問題！

        對于您提到的這些語言，最為推崇哪一個？

       我想過去十年或者二十年，關于語言有一些相關的調查。許多人認為C++也許是人們應該使用的語言；然後Java出現了，許多人轉向Java。我遇到許多 好像隻懂得Java的程式員。如果你向他們推薦說也許他們應該學習一下其他的語言，他們會和你争論，反駁說“Java都能做到！”。我想如果你問那些發明 這些語言的人，他們肯定不會說這些語言什麼都能做。除了這些，還有許多其他讨論小語言的多語言社群。Erlang已經有21年的曆史了， Smalltalk一直就有，現在人們還在使用它。我想正因為沒有哪個語言什麼都能做，開發人員才真的需要去學習多門語言，并能夠整合他們。

       當你真的遇到這種情況，當你學會了許多種語言，突然遇到一個問題，用兩行Ruby程式就解決了，而如果用Java語言的話可能需要兩百行，想想那是一種 多麼美妙的感覺。這會讓你成為一個更好的開發人員，因為你開始明白在不同的語言中如何使用不同的程式，你會從不同的語言中擷取知識。在Python中有很 酷的清單表達式，一行程式就可以處理一個清單中的各種疊代。Erlang也有類似很酷的功能，你會發現“原來在Erlang中也有和Python中語句基 本類似的清單表達式，它們有着同樣的功能。”其實并不是說每個語言都是一個完全不同的世界，都需要你一切從頭開始。你學會了一個，認識了這個語言中一些獨 特的地方，然後學習了另一個，會發現有很多相似的地方。

       從OO語言過渡到函數語言有那麼一些不同之處。而像Ruby和 Python這樣的語言是跨OO和函數語言的，使用這些語言可以幫你處理很多事情，同時還能夠擴充你的視野。對于并發，如果你在寫中間件程式，我想你最好 先看一下Erlang。這個語言本身就具有這樣的原語（primitive），它有一個稱為Open Telecom平台的庫，能夠友善地建構安全的軟體。這絕對不是說它簡單，隻是和你不用Erlang去做的事情相比起來，它确實容易了很多。是以，不要隻 看一門語言，都要涉獵！

受訪人 Steve Vinoski 采訪人 Stefan Tilkov 翻譯：霍泰穩     來自:InfOQ中文站