在SOA中有三個抽象層次，按照SOA的第一條準則：業務驅動服務、服務驅動技術。AM將業務模型直接和實踐連接起來，表現在平臺相關的模型之中。MDA并沒有把業務模型和平臺無關模型分開來，而是把平臺無關模型做為起點。SOA必須連接這些模型，或者說抽象層次，得到單一的架構方法。我們將從五個視圖的架構實現方法來實現這個連接。
SOA的五視圖實現方法
企業架構設計師發現他們的職業非常有競爭力并且值得驕傲，因為他們要從很多方面來通盤考慮IT系統。Kruchten（RUP的開發負責人）將這些方面提取出來，在應用到SOA時，我們稱為五視圖實現方法（five-view approach）。
四個方框表示對一個架構的不同審視方法，分別代表不同的涉眾（stakeholder）。弟五個視圖，use-case視圖涵蓋了其它視圖，在架構中扮演的是一個特殊的角色。部署視圖將軟件映射到底層平臺和相關硬件上，是系統部署人員對架構的視圖；實現視圖描述了軟件代碼的組織，是從開發人員角度出發的視圖；業務分析人員則利用過程視圖進行工作，它描述的是軟件系統的運行時特性。最后，邏輯視圖表示的是用戶的功能需求。在SOA中，面向服務的架構必須能夠以use-case視圖中的用例將用戶連接到服務，將服務連接到底層的技術。
為了表示面向對象的架構是如何工作在這些視圖之上，讓我們將他們置于SOA元模型的上下文之中。SOA中兩個領域存在重疊：由業務模型和服務模型表示的業務領域和由服務模型及平臺相關模型表示的技術領域（兩個領域共享服務模型）。業務用戶通過邏輯視圖和過程視圖處理粗粒度的業務服務，根據變化的業務需求，按照需要將它們安排在過程之中。另一方面，技術專家的工作是創建并維護服務和地層技術之間的抽象層。表示這些服務的中間模型，起到的是軸心的作用，業務以它為中心進行。
SOA元模型從MDA中繼承平臺無關模型和平臺相關模型，但是添加了AM和用戶交互以及敏捷的反饋這兩部分，后者通過橢圓之間的雙向箭頭來表現。類似地，元模型通過引入由中心的服務模型提供的中間層抽象解決了AM在伸縮性方面的問題。這樣，服務模型中的任何需求的變化，都會反映到用戶每天的業務處理中。同樣，由于底層技術是模型驅動的，技術專家也可以根據這些變化的需求迅速而有效地作出應變。
SOA實踐和過去解決企業架構傳統方式的不同之處就在于其對敏捷性的支持。如前所說，SOA的第三條原則就在于它總在變化之中。這種恒在的變化性環境是SOA實踐的基石。如圖所示，涉眾（stakeholders，譯者注：RUP中也有這個詞，表示軟件開發中涉及到的各種角色如：用戶、設計人員、開發人員乃至測試人員等等。）在一個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業務需求作出響應的這種情況下，設計階段和運行階段之間的界限變得模糊起來，很難清晰地分離這兩個階段。
我們已經為面向服務的架構提供了一個高層次的框架，其中MDA和AM的元素幫助工具的使用者來創建和維護SOA。但是，SOA中還缺少一些內容－那就是軟件開發商和專業的服務組織必需提供的。理想情況下，開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務；另外，能夠以一種敏捷的、平臺無關的方式充分反映業務服務的建模工具也是必須的；技術專家必須配備可以從模型中自動生成代碼，并在代碼變化時更新模型的工具，最后，開發商必須提供支持SOA的軟件，幫助面向服務的架構設計師以一種可信并且可伸縮的方式創建位于服務和底層技術之間的抽象層次。幸運的是，這方面的產品即將上市。
另外，最重要的就是貫穿本文的自頂而下的SOA實現方法了。今天關于Web services的大部分思考都是自底而上的：“這是如何創建Web services的方法，現在，我們來使用它們集成吧”，對Web services技術的這種方法是偉大的第一步，因為它可以驚人地降低集成的開銷，這是現在的技術管理人員最樂意見到的了。但當經濟進一步發展，IT走出低谷，企業會尋求IT的幫助來提高組織戰略意義上的核心價值。使用面向服務的架構，IT可以提供給企業實現業務敏捷性的這樣一個框架。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
