面向服務的分析與設計原理

面向服務的分析與設計原理

撰文/ Olaf Zimmermann, Pal Krogdahl, Clive Gee

最初的面向服務體系結構（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服務的前景》中介紹的，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中有三個主要的抽象級別：
l 操作：代表單個邏輯工作單元（LUW）的事務。執行操作通常會導致讀、寫或修改一個或多個持久性數據。SOA操作可以直接與面向對象（OO）的方法相比。它們都有特定的結構化接口，並且返回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。
l 服務：代表操作的邏輯分組。例如，如果我們將CustomerProfiling視爲服務，則按照電話號碼查找客戶、按照名稱和郵政編碼列出顧客和保存新客戶的數據就代表相關的操作。
l 業務流程：爲實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。業務流程的例子有：接納新員工、出售產品或服務和完成訂單。
在SOA術語中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱爲服務或流程編排。典型的情況是調用已編排服務來響應業務事件。
從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特徵以及如何系統地構造它們。這些相關問題都是當前行業內和學術界最常討論的問題。據我們所知，最近幾乎所有的SOA項目或專題研討會都將這樣的服務建模方面作爲重要的主題，並引起了許多的爭論。因此，讓我們更近地作一番審視。

爲什麼BPM、EA和OOAD還不夠？
早期的SOA實現項目經驗表明，諸如OOAD、EA和BPM這樣的現有開發流程和表示法僅僅涵蓋支持SOA範式所需的部分要求。SOA方法在加強已經制定的良好通用軟件體系結構原則（如信息隱藏、模塊化和問題分離）的同時，還增添了附加的主題，例如，服務編排、服務庫和服務總線中間件模式，在建模時需要對它們給予特別的關注。
圖1 展示了現有的EA、BPM和OOAD建模方法的主要應用領域，也是我們隨後討論SOAD的出發點。圖中的水平軸表示項目生命週期階段；垂直軸表示不同抽象層或領域之間的區別，而建模活動通常就是在其上進行的。
 SOA的遠景是相當容易理解的，因爲它的技術基礎衆所周知。例如，在任何SOA工作中，應用通用的軟件體系結構原則和OO技術都是一個有效的開端。然而，正如我們已經提到的，早期採用者最常詢問的問題是如何標識正確的服務。如前所述，OOAD、EA和BPM在各自獨立地應用時不能提供滿意的答案，而這正是我們現在要說明的。
在由 Booch和Jacobson 撰寫的開創性的書（Object-Oriented Software Engineering: A Use Case Driven Approach，大約10年前出版的）中介紹的OOAD方法在定義SOA方面提供了非常好的起點。同樣地，雖然許多年來在體系結構層次中應用OOAD技術和統一建模語言（Unified Modeling Language，UML）表示法是一個常見的實踐，但是OOAD還是與像類和單獨的對象實例這樣的微觀層次的抽象有關。由於每個問題域常常都創建單獨的用況模型，因此，應用程序開發項目，這個企業的大方向在許多情況下變得模糊。此外，由於種種原因，用況模型並不總是與其對等的BPM保持同步。
諸如Treasury企業體系結構框架（Treasury Enterprise Architecture Framework，TEAF，http://www.software.org/pub/architecture/teaf.asp）、面向特徵的領域分析（Feature-Oriented Domain Analysis，FODA，http://www.sei.cmu.edu/domain-engineering/FODA.html）和Zachman（http://www.zifa.com/）這樣的EA方法都將城市規劃級的觀點加在解決方案體系結構之上，但是並沒有解決如何找到易於重用且具有持久性的高質量企業抽象的問題。
雖然BPM方法（如BPMI，http://www.bpmi.org/）在功能工作單元之上提供了端到端視圖，但是它們通常都沒有觸及體系結構和實現領域。例如，在像用於Web服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL，http://www.research.ibm.com/journal/sj/412/leymann.html）這樣的語言出現之前，BPM表示法缺少操作語義。此外，我們還看到了許多流程建模與開發活動彼此分離的情況。
最後，現有的規則中沒有一個可以解決如何爲SOA啓用現有的應用程序的問題；大部分時間都採用自頂向下流程。現有的系統通常都存放有大量的重要數據和業務邏輯，並且不能簡單地加以替代。因此，爲了研究包裝和重構策略，必須對這些系統進行自底向上的分析。因此，對現有應用程序的考慮會將我們帶到中間相遇的流程。
由於這些原因的存在，所以需要混合SOAD建模方法。這種方法以最佳的方式組合了OOAD、BPM和EA中的原理，並且融入了一些具有創新性的原理。圖2 展示了這種新的方法的SOAD資源（原理和技術）：
EA
將企業應用程序和IT基礎設施發展成SOA可能是一個大的負擔，會影響多個業務線和組織單元。因此，需要應用EA框架和參考體系結構（如開放組織體系結構框架，The Open Group Architecture Framework，TOGAF，http://www.opengroup.org/architecture/togaf）以及Zachman，以努力實現單獨的解決方案之間體系結構的一致性。
根據過去的經驗，大多數現有的EA框架都在一個或多個方面有限制。例如，如果主要的問題是表示技術設備的低級構塊如何在宏觀層次互連，則無法獲得業務層流程或服務視圖。然而，在SOA的背景下，這種考慮問題的方式必須轉換爲以表示業務服務的邏輯構件爲中心，並且集中於定義服務之間的接口和服務級協定（Service Level Agreements，SLA）。
此外，許多企業級參考體系結構和框架是相當普通的，並沒有觸及設計領域。這樣的高級體系結構無法爲架構師和開發人員提供具體的戰術意見，並且常常導致企業體系結構和解決方案體系結構之間出現根本性的分歧。
SOAD必須幫助SOA架構師定義服務前景的整體業務級視圖。這是當今的EA框架所無法提供的，它們需要未來特定於SOA的增強；按需操作系統（On Demand Operating Environment，ODOE，http://www-1.ibm.com/partnerworld/pwhome.nsf/weblook/ebod_environment.html）是IBM針對這種趨勢制定的主要戰略。

BPM
BPM是一個不完整的規則，其中有許多不同的形式、表示法和資源。另一種常用的技術是定義表示概念性流程流的事件驅動流程鏈，這第二種技術使用了不同於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將流程的範圍從分析擴展到實現。這樣的可執行模型引發了一系列的新問題，其中包括：
l 哪些方面應該用BPEL描述，哪些方面應該用WSDL描述？流程模型和傳統的編程模型之間的區別在什麼地方？
l 如何將非功能性要求和服務質量特徵這樣的方面加入模型之中？
l 同更傳統的編碼（例如在J2EE中）相比，在BPEL引擎的編程語言擴展中執行多少邏輯？
l 如何評定可執行流程模型的質量，其應用的最佳實踐是什麼？
l 什麼工作角色進行BPEL流管理；是業務專家（分析人員），還是開發角色（軟件架構師）？
必須利用所有現有的BPM方法作爲SOAD的起點；然而，必須使用流程模型中用於驅動候選服務和它們的操作的附加技術來對其加以補充。此外，SOAD中的流程建模必須與設計層用況建模保持同步，並且必須給出與BPEL有關的問題的答案。

OO範式與面向服務（SO）範式
OO分析是一種非常強大且廣爲讚譽的方法，同樣，SOAD應該儘可能多地利用OO分析技術。要將OO分析成功地應用於SOA項目，您就必須一次分析多個系統。用況模型必須繼續扮演重要的角色。然而，SOAD必須主要是流程，而不是用戶驅動的。因此，SOAD需要BPM和用況建模活動之間的強鏈接。
在設計層，OO的目標是能夠進行快速而有效的設計、開發以及執行靈活且可擴展的應用程序。對象是軟件構造，其行爲就像它們建模的真實世界的實體。例如，顧客（Customer）將有名稱和聯繫信息，並且還可能有一個或多個與之相關的帳戶對象。從OO的角度看，每件事情都是對象。
OO的基本原則是：
l 封裝：軟件對象就是包含模擬真實世界的對象的物理屬性（數據）和功能（行爲）的離散包。例如，帳戶對象保持收支平衡並且包含平衡中的借貸機制。
l 信息隱藏：結構良好的對象有簡單的接口，並且不向外界顯漏任何內部機制。真實世界信息隱藏的例子是，您不需要詳細瞭解汽車的工作原理就能夠駕駛它。
l 類和實例：類是定義特定類型的軟件對象具有什麼類型的屬性和行爲的模板，而實例是具有這些屬性值的個別對象。創建類的新實例稱爲實例化。利用生物學進行類比，人就是一個類。所有的人都具有一些屬性，比如身高、體重、頭髮和眼睛顏色等等。我們中的每個人都是這個類HumanBeing的實例，具有一些特定的身高、體重以及其他的屬性值。類是一直存在的，而實例具有有限的生命週期。
l 關聯和繼承：在OO中，表達類和對象之間的關聯的能力是一個關鍵的概念；繼承是關聯的強形式，用於表達有關係：按照同樣的方式，生物物種由這樣的層次構成：界（Kingdom）、門（Phylum）、綱（Class）、目（Order）、科（Family）、類（Genus）、種（Species）。我們常常發現軟件對象的自然層次。例如，當您創建一個財務應用程序實體時，您可能需要構造像經常帳戶（Checking Account）、儲蓄帳戶（Savings Account）和貸款帳戶（Loan Account）這樣的對象。如果您看得更仔細一點（請參見圖3），您將發現這些類共享許多屬性，比如都有收支平衡帳戶、借方帳戶和貸方帳戶等等。
與其重複定義和管理這些屬性的代碼，不如創建一個通用的帳戶（Account）類，該類具有現金收支平衡並且可以處理借貸事務。所有其他的類都是這個帳戶（Account）類對象的專門形式。例如，貸款帳戶（LoanAccount）將在零和某個約定的最大值之間具有負平衡，而儲蓄帳戶（SavingsAccount）將具有負平衡，並且將展示增加利息的行爲，等等。
l 消息傳遞：爲了完成一些有用的工作，軟件對象需要相互通信。它們通過相互發送消息來這樣做。例如，假定我們想將$1000從經常帳戶轉到儲蓄帳戶，要達到此目的，可以將帶有參數$1000的借消息發送到經常帳戶（CheckingAccount）實例，並且將相應的貸消息發送到儲蓄帳戶（SavingsAccount）實例。當實例接收消息時，它執行相應的功能，稱爲方法，它有與消息相同的名稱。
l 多態：這個術語描述兩個或兩個以上的類接受相同的消息但是以不同的方式進行實現的情況。例如，自由經常帳戶（FreeCheckingAccount）實例和經常帳戶（CheckingAccount）實例將響應借（$100）消息，但是自由經常帳戶（FreeCheckingAccount）實例將正好$1000記入它的帳戶平衡的借方，而經常帳戶（CheckingAccount）實例將$1000加上交易費記入它的帳戶平衡的借方。

OO支持應用程序分析、設計和開發的完整生命週期：
l OOAD試圖找到最優的對象和最自然的類繼承來實現它們。
l OO開發集中於應用程序的漸進式開發，每次實現一個業務場景或用況。像IBM WebSphere Studio Application Developer這樣的工具有助於開發人員快速地構造和測試OO應用程序。
l OO運行時環境，例如由Java虛擬機提供的，提供應用程序服務（如垃圾收集（刪除因使用它們的對象已經被丟棄而不再使用的資源））以及框架（如J2EE）來爲駐留在不同的服務器上的對象提供相互通信的機制。
目前與SO有關的OO設計實踐的主要問題在於，它的粒度級別集中在類級，對於業務服務建模來說，這樣的抽象級別太低了。諸如繼承這樣的強關聯產生了相關方之間一定程度的緊耦合（因而具有依賴性）。與此相反，SO範式試圖通過鬆耦合來促進靈活性和敏捷性。目前，在SOA中還沒有服務實例的跨平臺繼承支持和一流的表示法來避免需要處理服務生命週期維護管理問題（如遠程垃圾收集）。
這些考慮事項使OO難以與SO體系結構樣式直接保持一致。然而，對於設計已定義的服務中的底層類和組件結構，OO仍然是一種有價值的方法。此外，許多OOAD技術（例如類、責任、協作（CRC）卡）也可以用於服務建模（如果它們提升到更高層次的抽象的話）。在本文後面，我們將回過頭來討論這一點。
圖4 展示了可見性層次和OO、面向組件和SO設計提供的重點之間的對應關係。它還展示了在SOA和SOAD背景中它們之間的相互關係。
至於表示法，統一建模語言（Unified Modeling Language，UML）—通過一些附加的定型（Stereotype）和概要加以增強—自然成爲SOAD的重要基礎。
在使用 Rational Unified Process （RUP，http://www-306.ibm.com/software/awdtools/rup/）—被認爲是支持迭代軟件開發的分析與設計的主流OOAD流程之一—的流程方面，使用UML模型具有首要價值。然而，RUP以OOAD的原則爲基礎，因而使其不容易與SOA設計保持一致。從RUP的角度來看，系統的體系結構是其通過已定義接口交互的主要組件的體系結構。此外，這些組件還由逐漸減小到類級粒度的更小組件組成。相反，在SOA中，系統的體系結構通常包括滿足普通業務服務需要的無狀態、全封裝且自描述的服務組成，它更接近於映射到BPM，如圖5所示。
這些服務可能包括許多協作或編排服務。這並沒有排除RUP採用的OO觀點，而是在其上實現了另一個抽象層。這個超層的作用是封裝作爲正式的跨層接口結構中的RUP構件（軟件服務）設計的組件。

SOAD原理
在這一部分中，我們將更詳細地描述SOAD的需求，並且開始確定它的主題和原理。目的是將關於這個主題的討論引到進一步的設計工作。進一步的工作無疑需要形式化SOAD方法。

SOAD必須提供什麼？
已經爲SOAD確定了下列需求：
l 正如任何其他的項目和方法一樣，必須正式（至少半正式）地定義流程和表示法。通過選擇和組合OOAD、BPM和EA原理，就可以在需要時確定額外的原理。
l 必須有結構化的方法來概念化服務：
m OOAD爲我們提供了應用程序層上的類和對象，而BPM具有事件驅動的流程模型。SOAD需要將它們結合在一起。
m 方法不再是面向用況的，而是由業務事件和流程驅動的。用況建模是在更低的層次上作爲第二步進行的。
m 方法包括語法、語義和策略。這就需要特別的組合、語義代理和運行時發現。
l SOAD必須提供定義良好的品質因素和最佳實踐（例如回答粒度問題）。必須回答BPEL提出的角色問題。例如，誰爲哪部分工作負責：是開發人員、架構師，還是分析人員？
l SOAD活動還必須回答這樣的問題：什麼不是好的服務？例如：不可重用的任何東西都不可能成爲好的一流SOA成員（即服務）。另一個例子就是帶有挑戰性的非功能要求的嵌入式實時系統，它們不能承受任何XML處理開銷。
l SOAD必須易於進行端到端建模，並且有全面的工具支持。假如SOA給業務帶來了靈活性和敏捷性，就應該對從企業到體系結構和應用程序設計領域產生的支持方法有相同的期望。

品質因素
一些通用原則或品質因素已經確定，並且可以作爲SOAD中的設計基準：
l 構思良好的服務給業務帶來了靈活性和敏捷性；它們通過鬆散耦合、封裝和信息隱藏使重構更加容易。
l 設計良好的服務是有意義的，並且不只適用於企業應用程序；服務之間的依賴性減到最少，並且是顯式聲明的。
l 服務抽象是內聚、完整和一致的；例如，在設計服務和它們的操作簽名時應該考慮創建（Create）、讀取（Read）、更新（Update）、刪除（Delete）和搜索（Search）（CRUDS）隱喻。
l 常常聲明的假定是，服務是無狀態的（例如非對話式的）；爲了要求服務在特定的問題域和上下文中是無狀態的，將削弱這種聲明。
l 領域專家無需深奧的專業知識就可以理解服務命名。
l 在SOA中，所有的服務都遵循相同的設計體系（通過模式和模板連接的）和交互模式；底層體系結構形式可以容易地標識（例如在體系結構複審期間）。
l 服務和服務使用者的開發除了領域知識之外只需要基本的編程語言技能；中間件專業知識只有少數的專業人員才需要，在理想的情況下，這種知識是爲工具和運行時廠商所用，而不是爲製作像SOA這樣的企業應用程序的公司所用。

服務標識和定義
自頂向下的業務級建模技術（如CBM）可以爲SOA建模活動提供起點。但是正如我們在前面提到的，SOA實現很少是在全新的項目中開始的；創建SOA解決方案几乎總需要涉及集成現有的遺留系統，方法是將它們分解成服務、操作、業務流程和業務規則（同時參見圖6）：
l 將現有的應用程序和廠商軟件包分解成表示相關操作組的離散服務集（自底向上方法）。
l 從應用程序中將業務流程和規則抽象爲由業務編排模型管理的單獨BPM。
所有的OOAD都同標識和定義服務有關；但是還需要具有更高層的觀點。此外，當SOA致力於比經典開發項目層次更高的開發時，就有了發揮其他創造性思維的空間。
直接和間接業務分析
通過項目相關人員的會談和CBM來進行BPM和直接需求分析是一個容易理解且非常合適的標識候選服務的方法。
過去的經驗表明，這條主要的途徑應該通過補充間接技術來加以改進。在選擇候選服務時，產品經理和其他業務領導應該進行協商。例如，什麼是計劃付款和開票模型？應該商議假定使用正在構建中的系統的企業的組織結構圖。建議還考慮一下非SOA項目中任何現有的用況模型。用於對正在構造的系統進行營銷介紹的術語是另一個很好的關於服務操作候選者的來源（特別是動詞，很少關注營銷動詞！）。

域分解
在Endrei（http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246303.html?Open）中定義的域分解、子系統分析、目標模型創建和相關技術是SOA流程構造方法或服務概念化框架（它是基於Levi and Arsanjani先前完成的工作構建的）最有希望的提議。來自SEI的FODA（http://www.sei.cmu.edu/domain-engineering/FODA.html）工作也爲這方面的討論做出了貢獻。
服務粒度
選擇正確的抽象級別是服務建模的一個關鍵問題。您常常會聽到進行粗粒度建模的建議。這有點過於簡單化了。您應該將其改爲在不損失或損害相關性、一致性和完整性的情況下儘可能地進行粗粒度建模。在任何SOA中，都有細粒度服務抽象的空間（假定有業務要求的話）。由於SOA並不等同於Web服務和SOAP，因此可以使用不同的協議綁定來訪問抽象級別不同的服務。另一種選擇就是將一些相關的服務捆綁成粗粒度的服務定義，這是門面模式的變種。
命名約定
應該定義企業命名模式（XML名稱空間、Java包名、Internet域）。簡單的例子就是始終用名詞來命名服務，而用動詞來命名操作。這種最佳實踐來源於OOAD空間。
第一類SOAD原理
除了組合OOAD、BPM和EA技術之外，還有幾個重要的SOAD概念和方面有待充實：
l 服務分類和聚合
l 策略和方面
l 中間相遇流程
l 語義代理
l 服務獲取和知識代理
服務分類和聚合
服務有不同的用法和用途；例如，軟件服務可以不同於業務服務（如前面的圖5 所示）。此外，還可以將原子服務編排成級別更高、功能齊全的服務。
服務組合可以通過可執行模型（如BPEL建模的模型）來加以簡化；這是傳統的建模工具和方法不能處理的事情。
策略和方面
服務具有語法、語義和QoS特徵，所有這些都必須進行建模；正式的接口契約必須涵蓋的比Web服務描述語言（Web Services Description Language，WSDL）的多。因此，Web服務策略框架（WS-Policy，http://www.ibm.com/developerWorks/cn/webservices/ws-polfram/）是一個重要的相關規範。
除了已經制定的良好體系結構可跟蹤性原則之外，業務可跟蹤性也是一個理想的品質：應該有可能將所有的運行時構件直接與非技術領域專家可以理解的語言聯繫起來。這對於直接在業務和服務層公開的抽象非常重要。Sarbanes-Oxley （SOX）法案（請參閱來自Astor的文章，http://sys-con.com/author/?id=526）是需要這種業務可跟蹤性的業務驅動程序的一個例子。
流程：中間相遇
在真實世界中，並沒有全新的項目，必須始終考慮遺留系統（遺留系統是現有系統的同義詞）。因此，需要中間相遇的方法，而不是單純的自頂向下或自底向上的流程。
在設計取決於現有的IT環境而不是現在和將來的業務需要的情況下，自底向上的方法往往會導致不好的業務服務抽象。而自頂向下的方法可能會產生不足的非功能性需求特徵，並且損害其他的體系結構品質因素（例如因域模型中缺乏標準化而導致的性能問題），另外，也會在服務和組件中產生不匹配的不良問題。
服務獲取和知識代理
這是一個知識管理和生命週期問題：如何成功地準備好服務並且使其在概念化之後可以重用？
應該將重用看作是標識和定義服務最主要的推動標準之一。如果組件（或服務）不可能重用，就不無法將其作爲服務進行部署。它可以連接到另一個與企業體系結構相關的服務，但是不能單獨作爲一個服務而存在。
然而，即使從開始就計劃好了重用，還必須形式化服務獲取流程。由多個使用者使用服務是明確的SOA設計目標。構建時服務註冊中心（例如企業UDDI目錄）可能能夠解決部分問題。

示例：汽車工作訂單
汽車工作訂單（Automotive Work Order）描述了一家汽車維修公司管理其顧客運營的流程。我們將通過這個領域中的問題來闡述SOAD的觀點。
工作訂單代表汽車服務公司和顧客之間的約定，以進行一系列例行維修或應急維修，例如例行50,000英里服務，更換剎車片或輪胎，或者換油。
業務場景（如圖7所示）如下：
l 當顧客打電話預約時創建工作訂單。
l 爲每個計劃的維修活動或操作創建一個獨立的工作訂單項，其中包括需要使用的零件、備件和勞務的詳細情況。
l 在安排預約之前確保所有必需的零件都有庫存。
l 需要爲每個工作訂單項安排具有適當的裝備的維修間以及具備適當的條件的機器。
l 計算估計的總成本，接着顧客認可該預約；或者方案終止，隨即取消工作訂單。
l 在預約之前，立即在選定的維修間裝配必需的零件、備件、工具和設備。
l 當顧客到達時，進行計劃的活動以及在檢查交通工具時顯得有必要的任何其他活動。
l 記錄所用的零件和備件的實際價值以及勞務。
l 在完成所有的維修時計算總費用。
l 創建發票並且將其交給顧客。
如果您將此作爲一個獨立的應用程序從頭開始創建，您就可能創建一組如圖8所示的類。
如果您將工作訂單構造爲一個OO應用程序，這些軟件對象將包含所有必需的業務規則，並且理解應該遵循的業務流程。
然而，這種方法在實踐方面存在着一些缺點：
l 許多步驟涉及與現有遺留系統和數據庫（例如帳單編制、日程安排以及庫存系統）的連接，它們不可能遵循OO範式進行設計（在這樣的情況下，應用適配器或仲裁器會有所幫助）。
l 爲了使系統儘可能地靈活，將一些規則外化是有幫助的，這樣就可以在不更改代碼的情況下修改流程或工作流。例如像下面這樣的規則：
l 標準的24,000英里服務包括四公升油。只是在使用四升以上的油或顧客要求優質油（如合成油）時才應該收取額外的郵費。
l 在遺留應用程序中有一套工業標準爲普通汽車維修活動進行勞務估價。除非維修人員收取的費用超過該估價的X%並且報告產生差別的有根據的原因，否則顧客就應該支付標準的勞務費。
l 如果超過估價的Y%以上，就應該聯繫顧客以進行確認。
SOAD爲這些問題提供了極好的解決方案。由於它基於相關的行爲對服務進行分組，而不是進行封裝（行爲及數據），所以這組服務與業務對象略有不同。
例如，您可能將工作訂單（Work Order）和工作訂單項（Work Order Item）一起分到工作訂單服務（Work Order Services），並且創建日程安排（Scheduling）、目錄（Catalog）和庫存（Inventory）服務。另外，因爲沒有服務實例，所以沒有與服務之間的關係等價的東西。工作訂單的服務模型可能看起來如圖9所示。
與OO範式不同，這個模型並不表示功能系統。既沒有考慮流，也沒有描述業務事件或規則。在SOA範式中，在服務外面維護的業務流程編排決定了執行服務調用的順序和時間。
從概念上講，從第一次顧客聯繫到完成工作和帳單支付的整個業務表示單個宏觀層次的工作單元，並具有數天到數週不等的生命週期。畢竟，從企業的角度來看，工作單元會產生收入。
然而，實際出現的情況是在一段相對長的時間內單獨發生的一系列集中活動，例如，定義活動、安排預約、選擇零件和備件、進行維修活動等等。在IT系統中，沒有實際的流程會持續幾分鐘以上；事件之間的業務流程狀態以數據的形式保存在數據庫中。
這種類型的流程可以用狀態轉換模型（例如UML中可用的）很好地進行表示。圖10 顯示了用有限狀態機（Finite-State Machine）方法如何對業務流進行建模的示例。它是在業務流程進行時工作訂單的狀態如何改變的高級視圖。
業務流程編排集中於狀態之間的這些轉變。單獨的操作永久地記錄相關的狀態改變。
圖11顯示了部分編排的示例，其中包括圖10 所示的業務場景中的步驟1到5（例如，顧客定義他們的交通工作所需的工作，並且安排預約以進行實施）。

總結和展望
在本文中，我們已經討論和激發了對創新的中間相遇的方法的需求，這種方法搭建了業務和IT之間的橋樑，並且支持SOA項目的分析和設計階段。我們還提議將這種新的交叉學科的SOAD方法作爲一個整體的建模規則，它以現在構建良好且廣爲讚譽的OOAD、EA、和BPM爲基礎。
在詳細定義SOAD表示法和流程的同時，還確定了關鍵的原理，比如服務概念化（或標識）、服務分類或聚合、策略和方面、中間相遇流程、語義代理和服務獲取（以供重用）。
SOAD需要增強現有的軟件開發方法，進一步提高企業應用程序開發項目的可用性和適用性。隨着時間的推移，還將發展相關的最佳實踐。
我們還認識到，UML在流程的表示法選擇方面將繼續佔支配地位；可能需要進行增強以滿足更廣泛的SOAD的要求。
完成SOAD方法的下一步就是定義所需的端到端流程和表示法，複審活動中的角色和它們的責任，並且繼續檢查所提議的方法在項目中的有效性。