當你重視目標平臺和中間件時，構建基于Web的分布式應用會變得更容易。
?????????????????????????????????????????????????????????????????????????????????????????????????????????―― Peter Varhol??????

??????在軟件開發中，過去我們經常看到開發人員犯同樣的錯誤。其中意義比較重大，并且長期以來存在著很大分歧的錯誤，就是應用架構是在特定平臺和操作系統上寫成的。這個錯誤在大型分布式應用中尤其顯著。這種情況在最初時可能沒什么問題，但是隨著平臺和操作系統的變化，特別是遇到不可預見的情況時，問題就暴露出來了。

??????當然你可能還要依靠其他一些軟件，例如應用服務器、瀏覽器或者數據庫管理系統。在很多情況下，這些應用比底層的硬件和操作系統更加趨向與動態。最終導致的結果是，當底層的硬件或操作系統發生變化時，必須對應用做重大調整才能使其正常工作在新的環境下。有些情況就更加糟糕了，一些應用的架構與它的底層支撐技術緊密結合，當底層支撐技術發生變動時，往往意味著整個的上層應用都要被推翻重新設計。

???????進入MDA的世界吧！MDA能夠將應用框架和其實現相分離。MDA的支持者希望支撐軟件和硬件的改變不會使現有的企業應用無法使用。更重要的是，通過降低應用架構和其運行環境的耦合度，MDA能夠帶來更加優秀的設計，從而使應用壽命更加長久并且能夠很容易地移植到其他底層平臺上。

???????如你所料，MDA使基于統一建模語言的(UML)的。當然光有UML還遠遠不夠，MDA還要使用Meta-Object Facility (MOF) and Common Warehouse Meta-model (CWM)。MDA由許多核心模型、或用于企業級開發和其他一些用于實時開發的框架組成。其他的核心模型將會逐步作為標準開發并提供出來。MDA結構和工藝時對象建模組織(OMG)的一個標準，COBRA和UML也是這個組織維護的。

???????UML提供了能夠清除地描述嵌入式系統的可視化建模技術。UML定義了幾個圖形視圖為開發提供了不同的系統透視圖。每一個圖標表現完整模型的不同方面。例如：用例圖（use-case diagrams）和次序圖（sequence charts）用于分析和確定系統；系統的行為可以用狀態圖（State charts）來建模。盡管每一個圖表反應系統不同的方面，但是他們之間是有交迭的，至少是存在著依賴關系。UML圖可以軟件架構、行為以及與系統其他部分的協作建模。UML用部署圖（deployment diagrams）描述系統的物理架構。部署圖只是用幾個簡單的圖像，因此很容易理解和實施。節點（Node）代表系統的重要物理對象。而交互連接（Interconnect）代表物理對象之間的連接。活動對象（Active Object）定義了分派給對象的任務。節點可以通過活動對象組合成能夠在平臺上部署的子系統。

??????協作有助于決定在全局計算環境下應用適合什么位置，其中最重要的方面就是確定合適的目標平臺。UML通過使用協作圖來建模協作。協作圖關注協作對象的靜態結構。也可以是用次序圖來完成這一工作。次序圖描述了對象之間的信息。

??????應用MDA的第一步就是用UML創建應用的模型，建模主要集中在建立應用的架構、行為和協作。這些模型是平臺無關的。UML以框圖的形式清晰的描述了應用的架構，以及它的行為和其與其他系統元素的協作。

??????然而，目前為止，我們做的這些還不是軟件的實現。有很多有效的工具可以幫助你將UML建立的框圖轉換成實際代碼。但是你丟掉了很重要的一個因素，那就是應用可能用到的操作系統和中間件的特性。一個簡單的例子就是Windows和對話框。有時程序在觀念上就利用操作系統或平臺（包括Java）服務，在特定平臺上實現。

??????因此出現了中間件。要實現分布式系統，就要確定使用CORBA, COM,? Java信息服務(JMS), Web服務還是其他支持技術。在實現應用時這些技術都要考慮到，但是這些技術卻是在建模之外的。

??????那么下一步就是讓將模型轉化成。MDA這一步處理的結果就是使UML模型映射到特定平臺下的UML模型以及本地平臺結構。應用的UML標識也維護著相同的內容，但是許多通過特定技術指引實現的附加信息加入來了。

??????一旦UML模型指向了特定平臺和特定技術，那么它就可以在那個平臺上實現了。這是另一個有趣的過程。從特定平臺上的模型到特定平臺上的實現，你要作的當然不僅僅是代碼生成，而是比代碼生成多得多的事情，尤其是基于Web的分布式應用，要做的就更多了。因為基于Web的分布式應用要求你組合源文件、配置文件、定義文件和資源文件。用一句話概括，就是你構建一個基于Web的分布式應用時所需要創建的所有文件。

??????這個方法看起來并不會給你帶來多少利益除非某些文件創建工程時自動完成的。畢竟僅僅依靠UML模型和代碼生成器，你就得通過模型將代碼生成出來，然后再通過某些方法手工修改代碼使其適應你的特定平臺。讓平臺相關模型失去自動生成那些代碼的能力可能并不比目前所能作的更加優越。然而一旦工具鏈從UML模型延伸到創建平臺相關代碼，MDA的優勢就顯現出來了。

??????MDA當然不是專門為Java或Java 2 企業版（J2EE）而存在的。在保持技術獨立的前提下，MDA允許使用.NET、J2EE、Web服務以及其他支持分布式應用的技術來實現應用架構。但是Java應用，尤其是那些跨系統、跨平臺，使用Web界面的應用，最終都可以借助MDA來實現快速構建。

??????MDA對于J2EE開發者來說到底意味著什么？由于Java語言的動態屬性以及Java社區接受新技術的速度，MDA是延長應用的壽命，使其長于支持技術的壽命的唯一可行的方法。然而隨著時間的流逝，底層技術也在不斷的發展，一個合理架構的MDA能讓應用持續有效。

??????Java開發人員對此應該會萬分激動。由于Java社區的活力，使得Java更新的速度比其他任何語言都快。設計應用時可以不需要考慮Java技術和版本變化帶來的沖擊會帶來在開發時間和可靠性上會帶來很多好處。很多時候我們要花在使應用適應不同版本的虛擬機JDK上的時間和實際寫代碼的時間一樣多。MDA能夠將這些時間從你的開發周期里抽取出來，把它交給能夠完美的處理復雜平臺的工具來完成。

??????市面上生成支持MDA的開發工具越來越多，其中大多數是Java陣營里的，因為Java提供了從平臺無關到平臺相關的簡易的建模途徑。支持MDA意味著什么？沒什么，至少現在并不意味著什么。大體上看來，目前支持能夠傳見平臺無關模型的UML工具都被稱作支持MDA。這些工具提供的能力只是自動實現MDA工程的第一步，建立模型，并且在某些情況下生特定平臺下的代碼。

??????另一個不斷有新工具涌現的領域是平臺無關模型到平臺相關模型的映射工具。簡單地將模型轉換為平臺相關模型實際上卻并不是很好理解，這比代碼生成高級的多。這需要對構建技術有深厚的理解，而且知道如何將設計翻譯成技術的構建模塊。

??????然而實際情況比這更加復雜。每年Java會出好幾個版本和中間件技術。如果你使用流行應用服務的流行版本，MDA可以幫助開發團隊更好的管理復雜度。
為了獲得更好的軟件質量，MDA允許開發人員進行更高層次的提取，而讓軟件來做具體的工作。在過去，能夠很好地生成通用代碼和特定平臺和技術下的代碼。MDA代表了應用開發領域的下一個技術舞臺，并承諾大幅度改善J2EE應用的構建。

??????但是MDA不是萬能的。MDA并不能幫助開發人員寫出比目前能寫出的更好的代碼。質量在復雜的技術和中間件理解中并不凸現，但是能夠將用戶的需求翻譯成有用的、可靠的應用。與平臺技術不同，通過需求創建成功應用的技術不會過時。MDA能夠使開發變得簡單，但這僅當你已經充分理解了你要做什么的情況下。