從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論的問題。據我們所知，最近幾乎所有的 SOA 項目或專題研討會都將這樣的服務建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審視。
為什么 BPM、EA 和 OOAD 還不夠？
早期的 SOA 實現項目經驗表明，諸如 OOAD、EA 和 BPM 這樣的現有開發流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如，服務編排、服務庫和服務總線中間件模式，在建模時需要對它們給予特別的關注。
圖 1 展示了現有的 EA、BPM 和 OOAD 建模方法的主要應用領域，也是我們隨后討論 SOAD 的出發點。圖中的水平軸表示項目生命周期階段；垂直軸表示不同抽象層或領域之間的區別，而建�；顒油ǔ＞褪窃谄渖线M行的。
圖 1. BPM、EA 和 OOAD 的位置
SOA 的遠景是相當容易理解的，因為它的技術基礎眾所周知。例如，在任何 SOA 工作中，應用通用的軟件體系結構原則和 OO 技術都是一個有效的開端。然而，正如我們已經提到的，早期采用者最常詢問的問題是如何標識正確的服務。如前所述，OOAD、EA 和 BPM 在各自獨立地應用時不能提供滿意的答案，而這正是我們現在要說明的。
在由 Booch 和 Jacobson 撰寫的開創性的書（大約 10 年前出版的）中介紹的 OOAD 方法在定義 SOA 方面提供了非常好的起點。同樣地，雖然許多年來在體系結構層次中應用 OOAD 技術和統一建模語言（Unified Modeling Language，UML）表示法是一個常見的實踐，但是 OOAD 還是與像類和單獨的對象實例這樣的微觀層次的抽象有關。由于每個問題域常常都創建單獨的用況模型，因此，應用程序開發項目，這個企業的大方向在許多情況下變得模糊。此外，由于種種原因，用況模型并不總是與其對等的 BPM 保持同步。
諸如 Treasury 企業體系結構框架（Treasury Enterprise Architecture Framework，TEAF）、面向特征的領域分析（Feature-Oriented Domain Analysis，FODA）和 Zachman 這樣的 EA 方法都將城市規劃級的觀點加在解決方案體系結構之上，但是并沒有解決如何找到易于重用且具有持久性的高質量企業抽象的問題。
雖然 BPM 方法（如 BPMI）在功能工作單元之上提供了端到端視圖，但是它們通常都沒有觸及體系結構和實現領域。例如，在像用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL）這樣的語言出現之前，BPM 表示法缺少操作語義。此外，我們還看到了許多流程建模與開發活動彼此分離的情況。
最后，現有的規則中沒有一個可以解決如何為 SOA 啟用現有的應用程序的問題；大部分時間都采用自頂向下流程�，F有的系統通常都存放有大量的重要數據和業務邏輯，并且不能簡單地加以替代。因此，為了研究包裝和重構策略，必須對這些系統進行自底向上的分析。因此，對現有應用程序的考慮會將我們帶到中間相遇的流程。
由于這些原因的存在，所以需要混合 SOAD 建模方法。這種方法以最佳的方式組合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有創新性的原理。圖 2 展示了這種新的方法的 SOAD 資源（原理和技術）：
圖 2. SOAD 及其組成部分：OOAD、BPM 和 EA
EA
將企業應用程序和 IT 基礎設施發展成 SOA 可能是一個大的負擔，會影響多個業務線和組織單元。因此，需要應用 EA 框架和參考體系結構（如開放組織體系結構框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力實現單獨的解決方案之間體系結構的一致性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
