當你重視目标平台和中間件時，建構基于Web的分布式應用會變得更容易。
<script type="text/javascript"> </script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script> name="google_ads_frame" marginwidth="0" marginheight="0" src="http://pagead2.googlesyndication.com/cpa/ads?client=ca-pub-4751025308591894&cpa_choice=CAAQycb8zwEaCNrmdvgKt1bFKJnA93M&oe=utf-8&dt=1162469741718&lmt=1162498541&prev_fmts=468x60_as_rimg&format=468x60_as_rimg&output=html&url=http%3A%2F%2Fwww.blogjava.net%2Fhsith%2Farchive%2F2006%2F06%2F15%2F52918.html®ion=_google_cpa_region_&ref=http%3A%2F%2Fwww.blogjava.net%2Fhsith%2Fcategory%2F10366.html&cc=127&u_h=768&u_w=1024&u_ah=740&u_aw=1024&u_cd=32&u_his=11&u_java=true" frame width="468" scrolling="no" height="60" allowtransparency="allowtransparency"> ―― 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能夠使開發變得簡單，但這僅當你已經充分了解了你要做什麼的情況下。
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)