歡迎光臨有關 Java 和 CORBA 技術的這一定期欄目。此第一期將概述 Java 和 CORBA 技術，並幫助您決定如何最有效地讓它們為您工作。以後的欄目將提供 Java 和 CORBA 編程的內行指導和代碼。
在 1855 年，時年 26 歲的 Joshua Chamberlain 是 Bowdoin 大學的修辭學教授，在一次演講中講述了規則與自由之間的關系，以及二者之間失衡帶來的危害。沒有自由的規則是專制，而沒有規則的自由是混亂。
公司信息系統部門的管理可能會形成過度的規則或過度的自由。規則過度的一個例子是只適用於一個廠商的管理指令，這樣您的系統在擴展時，或在與潛在的公司合作伙伴集成時就會有問題。如果自由過多，個人或者開發小組就會根據他們來選擇技術，這樣，如果這些技術高手遇到他們“生疏的”優先認股權這樣的話題時，擴展或集成又會變得很困難。開發人員可能會受業務環境不斷變化的影響。
努力實現環境平衡
多種環境因素在決定我們的系統必須遵守的的規則。存在於一個業務環境中的系統應有足夠長的壽命，以為公司和客戶創造價值。持續為一個組織創造長期價值的系統必須能夠應付經常的變化。合並、並購、新的管理和市場力量在改變系統的環境，以及通過使用該系統完成業務過程的用戶的需求。變化是一個常數，必須將它添加到評估方程式中。當然，我們無法預知未來，但我們可以分析趨勢並努力設計我們的系統，使之能夠接受大量潛在的變化或系統擴展，同時對組織產生的影響又可以盡可能小。
為了做出正確的決策和評估，我們需要理解支配著環境的規則，以及我們的應用程序在該環境中應具有的自由。要理解的最重要的規則是，我們的系統處在不斷發展的組織中，無論是在公司、政府還是教育組織中，都是業務問題支配技術問題。許多體系結構和平台評估都將主要問題漏掉了。他們通常會將兩項或多項技術並排放在一起，然後比較技術特性列表。在完成的時候，大多數參與者會達成一致，因為他們不願與評估小組中嗓門最大、最強硬、勢力最大的派別爭吵。顯然，這不是作出選擇的最有效方法。
確定關鍵業務問題
將業務問題轉換為對組織需要的實際評估意味著應該著重考慮以下問題：
組織內的技術力量
不抑制程序員的開發環境
不對應用程序構成限制的運行時環境
運行時環境和開發環境的許可證問題和法律問題（可以說是規則的規則）
可找到有經驗的開發人員
能找到收費合理、有見地的咨詢服務公司
對組織的客戶的影響
對廠商或技術合作伙伴的影響
組織的文化和策略
組織的上級管理聯盟
“大亨們”是否在討論並購或合並
誰是決策者
這些業務問題通常比其他問題（比如采用每個會話一個線程的並發模型還是每個請求一個線程的並發模型）更重要。您可以走進老板的辦公室，向他發表足可以充斥一次軟件研討會的技術觀點，但是除非您強調了組織的需要，否則您的觀點將顯得非常空洞。
走近 CORBA
現在讓我們用 CORBA 來解決這些問題。CORBA 是一種開放的行業標准，它由參加“對象管理組織 (OMG)”的 600 多家公司支持。這些公司包括硬件或軟件公司、電信公司、金融公司、大學、醫藥研究所和政府機構。OMG 並不實現它們自己的規范；它們依靠廠商的實現，這些實現有助於將竟爭導向到功能、性能、價格和令人鼓舞的質量這些方面。OMG 本身是一個充滿生機的、活躍的組織，它的許多官員在各種會議上撰寫文章並發表演講。只要留心觀察，您就會發現，他們總在關注將會對他們的組織及您的組織造成影響的各種變化。
除上述優勢外，CORBA 還提供了高度的交互操作性。這保證了在不同的 CORBA 產品基礎之上構建的分布式對象可以相互通信。因此，大型組織不需要讓所有開發工作都使用同一 CORBA 產品。OMG 一直都在辛勤工作，以期通過加強 CORBA 規范來提供更高級別的可移植性。要知道，當廠商分化它們的產品以及開發人員添加限制時，他們往往會忘記源代碼的可移植性這回事。應當指出，可移植性比以前的版本中有了實質性的提高，並且隨著因特網互操作性協議 (IIOP) 形成強大的用戶集團和眾多聯盟，可移植性將越來越好。
我們很快變會轉入 Java 技術的討論，但我們首先應將語言看作一個整體。信息系統有一個確定的規則，那就是不確定性本身。Java 編程語言可能是今天的語言，但誰知道下一種更好的語言哪一天會使它暗然失色呢？應當知道，就在此時此刻，有人正在他們的車庫裡加緊編寫一種更好的語言。因此，CORBA 的語言無關性有助於您長期遵守信息系統環境中的這一法則。CORBA 支持一種經典的、穩定的對象模型，此模型將繼續步入未來。它一直在憑借最新的語言不斷發展，並將繼續向極好的新語言（如 Python）擴展。
Java 編程語言及其他
此環境中可確定的另一點是它的復雜性，這是我們所不願看到的，Java 技術正好可以派上用場。它能很好地滿足需要，因為它的簡單性將有助於使開發免於陷入底層的復雜性中。Java 語言在許多方面隱藏了一些基本的細節，但就整體而言，Java 技術改善從分析、設計到執行的整個過程。
在分析和設計階段要盡可能統一和明確地表示您的系統和設計模式，這一點極為重要。“統一建模語言 (UML)”事實上已成為表述系統設計的標准語言。UML 的開發是協作方面的一個極好的故事。UML 的標准化過程也相當引人注意。UML 的標准化是通過 OMG 來實現的。OMG 認識到需要一種標准建模語言，以跨語言和環境表示分布式對象模型。Java 對象模型與 CORBA 對象模型幾乎完全相同，從而很容易將您的 UML 設計映射到一種實現，同時也很容易將 UML 圖映射到“Interface Definition Language (IDL)-to-Java 語言”實現。
經過分析和設計階段的對象將有一些接口，這些接口定義其他組件將如何訪問您的服務。現在需要將那些接口轉換為一種實現語言。Java 技術同樣使這一步很容易實現。“IDL-to-Java 語言”映射相當直接。Java 語言和 IDL 分別提供一個接口關鍵字，這個關鍵字有助於說明用每種語言表示的數據類型之間的緊密關系。Java 技術提供一種從 Java 接口到 IDL 的反向映射。不管選擇哪個方向，您都應該用 IDL 表示您的接口；這使您能夠使用所有其他語言與 IDL 之間的映射，並為您提供了為了在以後具有更大自由而必需的語言無關性。
體系結構案例
除了設計之外，系統的體系結構也很重要。許多系統體系結構問題涉及對現有系統（數據庫、舊有系統、可用對象或可能用其他語言編寫的應用程序）的包含。Java 和 CORBA 語言使得可以（而不是禁止）將這些強有力的系統帶給更多的用戶。這是一種解放 -- 許多系統可能許多年來都在發揮著作用。實際上，當完成將這些系統帶入新世紀的所有 Y2K 以前的工作以後，在今後幾年它們可能還將存在。由於其編譯後的字節碼結構，Java 語言將使您很容易創建和分發可移植的對象，而 CORBA 允許您將這些對象與您計算環境的其余部分進行連接和集成。
我並非想用 Java 和 CORBA 技術來排斥 Java 語言的遠程方法調用、Enterprise JavaBeans 技術、Microsoft 的 DCOM 甚至 DCE。Java 和 CORBA 語言最自由的方面是，OMG 正在加緊工作，以確保 CORBA 對象能夠與大量的對象交互。當然，這些連接中有些較難實現，並且最終可能會很脆弱。請記住，這些類型的連接常常是因體系結構、成本、時間或業務等原因而建立的。
小結
異構系統環境中的互連和通信應該是我們的目標。我們要選擇使用的規則應該允許自由地將現有的系統與新系統一起使用以滿足組織的需要。在這個變化的世界中，當變化被強加給您的組織時，這些規則應該提供最大的靈活性。這些規則提供了一個限制我們的自由的操作范圍，這樣就不易陷入盲目開發的境況。
謝謝您耐著性子讀完了本文。我不是修飾學教授，我只是一個程序員，所以在下一期我們將開始討論一個簡單的示例 -- 使用 Java 技術實現 CORBA 客戶機和服務器。
