最初的面向服務的體系結構（Service-Oriented Architecture，SOA） 的實現項目的經驗表明，諸如面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（EnterPRise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有開發流程和表示法僅僅涵蓋了支持目前出現在 SOA 中的體系結構模式所需的部分要求。在 Info World 最近的訪談（請參見參考資料）中，Grady Booch 宣稱“像對問題的良好抽象和良好的分離這樣的工程基礎決不會過時”，不過，他也指出“還是有現實的機會提升抽象的級別。過去的經驗表明，必須將抽象的級別提升到公司處理的業務領域，從而將整個企業 IT 前景都納入考慮的范疇。正如 Mark Colan 在文章“面向服務的體系結構擴展 Web 服務的前景，第 1 部分”中介紹的，SOA 是一種新興的企業結構形式，可以用于設計下一代企業應用程序。SOA 方法在有力地加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了一些其他的主題，例如服務編排、服務庫和服務總線中間件模式。需要結構化方法或分析與設計方法來設計高質量的 SOA。因為現有的方法中沒有一種能夠滿足程序設計人員對最新的 SOA 項目的要求，所以他們建議將已經形成的良好實踐（如 OOAD、EA 和 BPM）中的原理組合起來，并且使用根據需要創新的原理來對其加以補充。引言面向服務的體系結構（SOA）和 Web 服務的基本觀念是成為我們日常語言的一部分，并可看作是適于設計現代企業應用程序的體系結構形式。在這種背景下，什么構成好的服務這個基本問題就成為確保成功實現 SOA 的要害。像面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（Enterprise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有建模規則為我們提供了高質量的實踐，可以長期幫助標識和定義體系結構內的適當抽象。然而經驗表明，這些實踐各自單獨應用時達不到要求。在本文中，我們將研究 OOAD、EA 和 BPM 中的適當原理。我們還將推動對混合方法的需求，這種方法把所有這些規則中的原理與許多獨特的新原理組合起來。這樣得到的交叉學科 OOAD 方法使成功地進行 SOA 開發更輕易，我們稱之為面向服務的分析與設計（Service-Oriented Analysis and Design，SOAD），它還有待正式定義。我們還只是剛剛跨入 SOAD 的殿堂。面向服務的概念在發現新的商機或威脅的預期下，SOA 體系結構形式旨在提供企業業務解決方案，這些業務解決方案可以按需擴展或改變。SOA 解決方案由可重用的服務組成，帶有定義良好且符合標準的已發布接口。SOA 提供了一種機制，通過這種機制，可以集成現有的遺留應用程序，而不管它們的平臺或語言。從概念上講，SOA 中有三個主要的抽象級別：
業務流程：為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。業務流程的例子有：接納新員工、出售產品或服務和完成訂單。 在 SOA 術語中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。
從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論的問題。據我們所知，最近幾乎所有的 SOA 項目或專題研討會都將這樣的服務建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審閱。 為什么 BPM、EA 和 OOAD 還不夠？
早期的 SOA 實現項目經驗表明，諸如 OOAD、EA 和 BPM 這樣的現有開發流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如，服務編排、服務庫和服務總線中間件模式，在建模時需要對它們給予非凡的關注?，F有的 EA、BPM 和 OOAD 建模方法的主要應用領域，也是我們隨后討論 SOAD 的出發點。圖中的水平軸表示項目生命周期階段；垂直軸表示不同抽象層或領域之間的區別，而建?；顒油ǔ＞褪窃谄渖线M行的。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 中的原理，并且融入了一些具有創新性的原理。這種新的方法的 SOAD 資源（原理和技術）：EA
將企業應用程序和 IT 基礎設施發展成 SOA 可能是一個大的負擔，會影響多個業務線和組織單元。因此，需要應用 EA 框架和參考體系結構（如開放組織體系結構框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力實現單獨的解決方案之間體系結構的一致性。根據過去的經驗，大多數現有的 EA 框架都在一個或多個方面有限制。例如，假如主要的問題是表示技術設備的低級構塊如何在宏觀層次互連，則無法獲得業務層流程或服務視圖。然而，在 SOA 的背景下，這種考慮問題的方式必須轉換為以表示業務服務的邏輯構件為中心，并且集中于定義服務之間的接口和服務級協定（Service Level Agreements，SLA）。此外，許多企業級參考體系結構和框架是相當普通的，并沒有觸及設計領域。這樣的高級體系結構無法為架構師和開發人員提供具體的戰術意見，并且經常導致企業體系結構和解決方案體系結構之間出現根本性的分歧。SOAD 必須幫助 SOA 架構師定義服務前景的整體業務級視圖。這是當今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強；按需操作系統（On Demand Operating Environment，ODOE）是IBM 針對這種趨勢制定的主要戰略。BPM
BPM 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，正如 Barker 和 Longman 所定義的。這第二種技術使用了不同于 UML 的表示法。此外，還有許多專用方法（如 BPM 技術）可能被咨詢公司和企業資源規劃（Enterprise Resource Planning，ERP）軟件包廠商視為具有競爭優勢。ARIS Implementation Platform 就是這樣的產品的一個例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的組件業務建模（Component Business Modeling，CBM）戰略。最近的趨勢是定義表示可執行流模型（如用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL））的標準方法。BPEL 將流程的范圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：
目前與 SO 有關的 OO 設計實踐的主要問題在于，它的粒度級別集中在類級，對于業務服務建模來說，這樣的抽象級別太低了。諸如繼續這樣的強關聯產生了相關方之間一定程度的緊耦合（因而具有依靠性）。與此相反，SO 范式試圖通過松耦合來促進靈活性和靈敏性。目前，在 SOA 中還沒有服務實例的跨平臺繼續支持和一流的表示法來避免需要處理服務生命周期維護治理問題（如遠程垃圾收集）。這些考慮事項使 OO 難以與 SO 體系結構樣式直接保持一致。然而，對于設計已定義的服務中的底層類和組件結構，OO 仍然是一種有價值的方法。此外，許多 OOAD 技術（例如類、責任、協作（CRC）卡）也可以用于服務建模（假如它們提升到更高層次的抽象的話）。在本文后面，我們將回過頭來討論這一點。可見性層次和 OO、面向組件 和 SO 設計提供的重點之間的對應關系。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關系。至于表示法，統一建模語言（Unified Modeling Language，UML）——通過一些附加的定型（Stereotype）和概要加以增強——自然成為 SOAD 的重要基礎。在使用 Rational Unified Process (RUP)——被認為是支持迭代軟件開發的分析與設計的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價值。然而，RUP 以 OOAD 的原則為基礎，因而使其不輕易與 SOA 設計保持一致。從 RUP 的角度來看，系統的體系結構是其通過已定義接口交互的主要組件的體系結構。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在 SOA 中，系統的體系結構通常包括滿足普通業務服務需要的無狀態、全封裝且自描述的服務組成，它更接近于映射到 BPM。這些服務可能包括許多協作或編排服務。這并沒有排除 RUP 采用的 OO 觀點，而是在其上實現了另一個抽象層。這個超層的作用是封裝作為正式的跨層接口結構中的 RUP 構件（軟件服務）設計的組件。更多的請看：http://www.QQread.com/windows/2003/index.Html最初的面向服務的體系結構（Service-Oriented Architecture，SOA） 的實現項目的經驗表明，諸如面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（Enterprise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有開發流程和表示法僅僅涵蓋了支持目前出現在 SOA 中的體系結構模式所需的部分要求。在 Info World 最近的訪談（請參見參考資料）中，Grady Booch 宣稱“像對問題的良好抽象和良好的分離這樣的工程基礎決不會過時”，不過，他也指出“還是有現實的機會提升抽象的級別。過去的經驗表明，必須將抽象的級別提升到公司處理的業務領域，從而將整個企業 IT 前景都納入考慮的范疇。正如 Mark Colan 在文章“面向服務的體系結構擴展 Web 服務的前景，第 1 部分”中介紹的，SOA 是一種新興的企業結構形式，可以用于設計下一代企業應用程序。SOA 方法在有力地加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了一些其他的主題，例如服務編排、服務庫和服務總線中間件模式。需要結構化方法或分析與設計方法來設計高質量的 SOA。因為現有的方法中沒有一種能夠滿足程序設計人員對最新的 SOA 項目的要求，所以他們建議將已經形成的良好實踐（如 OOAD、EA 和 BPM）中的原理組合起來，并且使用根據需要創新的原理來對其加以補充。引言面向服務的體系結構（SOA）和 Web 服務的基本觀念是成為我們日常語言的一部分，并可看作是適于設計現代企業應用程序的體系結構形式。在這種背景下，什么構成好的服務這個基本問題就成為確保成功實現 SOA 的要害。像面向對象的分析與設計（Object-Oriented Analysis and Design，OOAD）、企業體系結構（Enterprise Architecture，EA）框架和業務流程建模（Business Process Modeling，BPM）這樣的現有建模規則為我們提供了高質量的實踐，可以長期幫助標識和定義體系結構內的適當抽象。然而經驗表明，這些實踐各自單獨應用時達不到要求。在本文中，我們將研究 OOAD、EA 和 BPM 中的適當原理。我們還將推動對混合方法的需求，這種方法把所有這些規則中的原理與許多獨特的新原理組合起來。這樣得到的交叉學科 OOAD 方法使成功地進行 SOA 開發更輕易，我們稱之為面向服務的分析與設計（Service-Oriented Analysis and Design，SOAD），它還有待正式定義。我們還只是剛剛跨入 SOAD 的殿堂。面向服務的概念在發現新的商機或威脅的預期下，SOA 體系結構形式旨在提供企業業務解決方案，這些業務解決方案可以按需擴展或改變。SOA 解決方案由可重用的服務組成，帶有定義良好且符合標準的已發布接口。SOA 提供了一種機制，通過這種機制，可以集成現有的遺留應用程序，而不管它們的平臺或語言。 從概念上講，SOA 中有三個主要的抽象級別：
業務流程：為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。業務流程的例子有：接納新員工、出售產品或服務和完成訂單。 在 SOA 術語中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。
從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論的問題。據我們所知，最近幾乎所有的 SOA 項目或專題研討會都將這樣的服務建模方面作為重要的主題，并引起了許多的爭論。因此，讓我們更近地作一番審閱。 為什么 BPM、EA 和 OOAD 還不夠？
早期的 SOA 實現項目經驗表明，諸如 OOAD、EA 和 BPM 這樣的現有開發流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如，服務編排、服務庫和服務總線中間件模式，在建模時需要對它們給予非凡的關注。現有的 EA、BPM 和 OOAD 建模方法的主要應用領域，也是我們隨后討論 SOAD 的出發點。圖中的水平軸表示項目生命周期階段；垂直軸表示不同抽象層或領域之間的區別，而建?；顒油ǔ＞褪窃谄渖线M行的。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 中的原理，并且融入了一些具有創新性的原理。這種新的方法的 SOAD 資源（原理和技術）：EA
將企業應用程序和 IT 基礎設施發展成 SOA 可能是一個大的負擔，會影響多個業務線和組織單元。因此，需要應用 EA 框架和參考體系結構（如開放組織體系結構框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力實現單獨的解決方案之間體系結構的一致性。根據過去的經驗，大多數現有的 EA 框架都在一個或多個方面有限制。例如，假如主要的問題是表示技術設備的低級構塊如何在宏觀層次互連，則無法獲得業務層流程或服務視圖。然而，在 SOA 的背景下，這種考慮問題的方式必須轉換為以表示業務服務的邏輯構件為中心，并且集中于定義服務之間的接口和服務級協定（Service Level Agreements，SLA）。此外，許多企業級參考體系結構和框架是相當普通的，并沒有觸及設計領域。這樣的高級體系結構無法為架構師和開發人員提供具體的戰術意見，并且經常導致企業體系結構和解決方案體系結構之間出現根本性的分歧。SOAD 必須幫助 SOA 架構師定義服務前景的整體業務級視圖。這是當今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強；按需操作系統（On Demand Operating Environment，ODOE）是IBM 針對這種趨勢制定的主要戰略。BPM
BPM 是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，正如 Barker 和 Longman 所定義的。這第二種技術使用了不同于 UML 的表示法。此外，還有許多專用方法（如 BPM 技術）可能被咨詢公司和企業資源規劃（Enterprise Resource Planning，ERP）軟件包廠商視為具有競爭優勢。ARIS Implementation Platform 就是這樣的產品的一個例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的組件業務建模（Component Business Modeling，CBM）戰略。 最近的趨勢是定義表示可執行流模型（如用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL））的標準方法。BPEL 將流程的范圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：
