在使用 Rational Unified Process (RUP)——被認為是支持迭代軟件開發的分析與設計的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價值。然而，RUP 以 OOAD 的原則為基礎，因而使其不容易與 SOA 設計保持一致。從 RUP 的角度來看，系統的體系結構是其通過已定義接口交互的主要組件的體系結構。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在 SOA 中，系統的體系結構通常包括滿足普通業務服務需要的無狀態、全封裝且自描述的服務組成，它更接近于映射到 BPM，如圖 5 所示。
圖 5. SOAD 服務定義層次
這些服務可能包括許多協作或編排服務。這并沒有排除 RUP 采用的 OO 觀點，而是在其上實現了另一個抽象層。這個超層的作用是封裝作為正式的跨層接口結構中的 RUP 構件（軟件服務）設計的組件。
SOAD 原理
在這一部分中，我們將更詳細地描述 SOAD 的需求，并且開始確定它的主題和原理。目的是將關于這個主題的討論引到進一步的設計工作。進一步的工作無疑需要形式化 SOAD 方法。
SOAD 必須提供什么？
已經為 SOAD 確定了下列需求：
正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義流程和表示法。通過選擇和組合 OOAD、BPM 和 EA 原理，就可以在需要時確定額外的原理。
必須有結構化的方法來概念化服務：
OOAD 為我們提供了應用程序層上的類和對象，而 BPM 具有事件驅動的流程模型。SOAD 需要將它們結合在一起。
方法不再是面向用況的，而是由業務事件和流程驅動的。用況建模是在更低的層次上作為第二步進行的。
方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發現。
SOAD 必須提供定義良好的品質因素和最佳實踐（例如回答粒度問題）。必須回答 BPEL 提出的角色問題。例如，誰為哪部分工作負責：是開發人員、架構師，還是分析人員？
SOAD 活動還必須回答這樣的問題：什么不是好的服務？例如：不可重用的任何東西都不可能成為好的一流 SOA 成員（即服務）。另一個例子就是帶有挑戰性的非功能要求的嵌入式實時系統，它們不能承受任何 XML 處理開銷。
SOAD 必須易于進行端到端建模，并且有全面的工具支持。假如 SOA 給業務帶來了靈活性和敏捷性，就應該對從企業到體系結構和應用程序設計領域產生的支持方法有相同的期望。
品質因素
一些通用原則或品質因素已經確定，并且可以作為 SOAD 中的設計基準：
構思良好的服務給業務帶來了靈活性和敏捷性；它們通過松散耦合、封裝和信息隱藏使重構更加容易。
設計良好的服務是有意義的，并且不只適用于企業應用程序；服務之間的依賴性減到最少，并且是顯式聲明的。
服務抽象是內聚、完整和一致的；例如，在設計服務和它們的操作簽名時應該考慮創建（Create）、讀�。≧ead）、更新（Update）、刪除（Delete）和搜索（Search）(CRUDS) 隱喻。
常常聲明的假定是，服務是無狀態的（例如非對話式的）；為了要求服務在特定的問題域和上下文中是無狀態的，將削弱這種聲明。
領域專家無需深奧的專業知識就可以理解服務命名。
在 SOA 中，所有的服務都遵循相同的設計體系（通過模式和模板連接的）和交互模式；底層體系結構形式可以容易地標識（例如在體系結構復審期間）。
服務和服務使用者的開發除了領域知識之外只需要基本的編程語言技能；中間件專業知識只有少數的專業人員才需要，在理想的情況下，這種知識是為工具和運行時廠商所用，而不是為制作像 SOA 這樣的企業應用程序的公司所用。
服務標識和定義
自頂向下的業務級建模技術（如 CBM）可以為 SOA 建�；顒犹峁┢瘘c。但是正如我們在前面提到的，SOA 實現很少是在全新的項目中開始的；創建 SOA 解決方案幾乎總需要涉及集成現有的遺留系統，方法是將它們分解成服務、操作、業務流程和業務規則
文章來源于領測軟件測試網 http://www.kjueaiud.com/
