SOA 案例研究：SOA 设计
|
我們在本文中介紹的案例研究包括以下人員和角色：
- Sandy Osbourne-Archer，首席技術架構師
- Edmund Smythe-Barrett，企業架構師
- Ursula DeBarry，軟件架構師兼服務設計團隊主管
- Henry Lee，業務分析人員
- Jason Smith，集成開發人員
- Willy Sheng Duo Li（也叫 Willy Li），應用程序開發人員
帳戶開立項目的挑戰
我們在本文中定義的帳戶開立項目挑戰與“SOA 設計場景”相關。該場景的重點包括用于 SOA 設計（更具體地說是服務和流的設計）的方法、構件和工具。
軟件架構師兼服務設計團隊主管 Ursula DeBarry 從業之初擔任的是 J2EE? 開發人員，后來成為了軟件架構師。
她擁有嫻熟的設計技能，在應用諸如 Rational? Unified Process? (RUP?) 和面向服務的建模與體系結構 (Service Oriented Modeling and Architecture，SOMA) 之類的方法方面非常熟練。除了使用 IBM? Rational Software Architect 之類的工具對她所負責的項目進行應用程序建模和組裝以外，她還為同事組織了多個關于方法和工具使用的研討會，并在其中負責授課。
Ursula 對專門從事 SOA 設計方面的工作特別感興趣。在 Ursula 之前擔任的職位中，她完成了 Web 服務試驗項目的設計和實現。不過，這個試驗項目由于政治原因而取消了。
她非常渴望尋找新的 SOA 機會。Ursula 從以前的同事——應用程序開發人員 Willy Li——那里了解到，JKHL Enterprises 正在尋找有經驗的軟件架構師和服務設計師來實施 SOA 計劃。Ursula 前去 JKHL Enterprises 應聘。
首席技術架構師 Sandy Osbourne-Archer 對 Ursula 進行了面試，由于她本身具有豐富的經驗、嫻熟的技能，并且有 Willy Li 推薦，因此當場就被錄用了。Ursula 非常高興能擔任軟件架構師兼服務設計團隊主管。
在與 Sandy 的首次會面中，Ursula 了解了帳戶開立項目的目標和挑戰。Sandy 表示，自己對業務和 IT 之間存在的語義差異和細節差異不甚滿意，因為這些差異容易出現不同步或不完全一致的現象（請參見圖 1）。
Sandy 強調了保持業務設計和 IT 解決方案一致的需求，以便保持企業對新業務機會的敏捷性和響應能力。
圖 1 當前業務和 IT 不同步（不一致）
Sandy 列出了帳戶開立項目的高級業務目標：
- 目標 1：降低成本：
- 1.1: 降低創建和管理帳戶的成本
- 1.1.1: 降低帳戶激活的成本
- 1.2: 減少紙質文檔的數量
- 1.2.1: 增加電子應用程序的數量
- 1.1: 降低創建和管理帳戶的成本
- 目標 2：提高每個客戶擁有的產品數量
- 目標 3：提高可用性
- 目標 4：減少不遵從法律法規的風險
- 目標 5：增加客戶自助服務
- 目標 6：加快上市時間
Sandy 總結了高級設計目標和挑戰：
- 業務設計：
- 清楚地定義業務戰略和目標
- 以業務驅動的方式對服務需求、設計和實現進行優先排序
- 提高服務重用，以加速上市時間并降低成本
- IT 解決方案設計：
- 為關鍵業務活動的服務提供顯式的可跟蹤性
- 可重復且可擴展的設計方法
- 能實現更好重用的服務組合
- 用于多通道訪問的服務綁定策略
- 方便組裝、部署和管理的解決方案
|
SOA 設計場景的帳戶開立計劃
通過一系列的會議，Ursula 和企業架構師 Edmund Smythe-Barrett 共同制定了 SOA 設計場景的帳戶開立計劃。
他們與業務分析人員 Henry Lee 進行了討論，對為帳戶開立項目定義的關鍵業務需求有了更好的理解。圖 2 描述了帳戶開立高級流程，提供了該流程的關鍵元素的概念視圖。
圖 2 帳戶開立高級流程
為了提高 SOA 設計的成熟度和改進帳戶開立流程，Ursula 計劃應用用于服務設計的 SOMA 并執行用于流程組合的業務服務設計。
應用 SOMA 進行服務設計
Ursula 指出，IBM Global Services 的架構師和專家開發的 SOMA 方法基于從客戶合作項目中獲得的知識。Ursula 希望能夠利用經過驗證的 SOMA 方法進行帳戶開立服務設計。
IBM 提供了兩種應用 SOMA 進行服務設計的方法：
- 用于服務設計的 SOMA
在此方法中，客戶通過服務約定雇用 IBM，讓他們的架構師和專家來應用 SOA 方法和 IBM 工具來代表客戶進行服務設計。
Ursula 和 Edmund 一致同意，對于該帳戶開立項目，他們將參加與 IBM 的服務合作項目，以便在使用“用于服務設計的 SOMA 方法”來創建服務設計方面獲得幫助。服務設計團隊和 IBM 將應用 SOMA 方法來確定服務，指定服務和流，并實現該服務設計。與 IBM 的合作將幫助服務設計團隊為將來的項目獲得 SOAM 的實際應用知識。
- 業務轉換分析 (BTA) 和服務設計
在此方法中，客戶通過應用 IBM Rational Method Composer 中包含的 RUP SOMA 方法直接創建服務設計。BTA 和服務設計的重點是通過應用自動化的設計工具和流程，以改進設計一致性和加速上市時間，從而提供正式的說明性服務設計方法。或者，客戶可以雇請 IBM Services 代表他們應用 BTA 和服務設計。
在旨在使將來的 SOA 變得更加自給自足的工作中，Ursula 領導的服務設計團隊將開始培訓 BTA 和服務設計的使用。
用于流程組合的業務服務設計
Ursula 將領導帳戶開立項目的用于流程組合的業務服務設計。
|
將 SOA 場景模式應用于該案例研究
SOA 設計場景的重點是通過使用經過證明的 IBM 方法和工具，從而使業務設計與 IT 解決方案設計保持一致。諸如組件業務模型（Component Business Model，CBM）、SOMA 和 RUP for SOMA 等方法提供了概念框架，用于定義建模的方方面面以使業務與 IT 設計保持一致。使用 IBM 工具來支持設計方法，以對可跟蹤性建模并創建整個生命周期中的設計構件。SOA 設計場景可應用于每個基本 SOA 場景。
SOA 設計場景模型的基本構造包括流、服務和組件（請參見圖 3）。
- 流或流程表示完成某個業務流程所需要的活動流。流是旨在實現業務目標的相關和集成服務的組合。
- 服務是代表性的可重復業務任務。通過提供定義良好并且與實現無關的接口，從而將服務用于封裝應用程序的功能單元。服務可由其他服務或客戶端應用程序調用（使用）。
- 組件表示服務向服務使用者公開的功能，以及由實現服務的服務提供者提供的服務質量 (QoS)。
圖 3 服務提供業務與 IT 之間的一致性
注意：SOA 設計場景的關鍵元素是服務設計。
服務設計以及最終的服務通過在業務流和目標與 IT 組件之間提供橋梁，從而提供一致性能力（如圖 3 所示）。
以下幾個部分將詳細描述該案例研究解決方案元素，這些元素映射到 SOA 設計場景實現：
- 用于服務設計的 SOMA
- 業務轉換分析和服務設計
- 用于流程組合的業務服務設計
用于服務設計的 SOMA
注意： 用于服務設計的 SOMA 實現特別利用了 SOMA 標識、規范和實現階段來交付所需的 SOA 設計成果。
Ursula 和 IBM Services 合作項目團隊開始通過應用用于服務設計的 SOMA 方法來處理帳戶開立服務設計。該團隊集中于服務設計的以下方面：
- 服務標識
- 服務規范
- 服務實現
SOMA 方法是用于 SOA 設計和構造以支持目標業務流程的分析和設計方法。SOMA 通過服務、組件和流的標識、規范和實現來完成此任務。SOMA v3.1 擴展了 SOMA，以提供同時還包括實現、測試、部署、監視和管理活動的端到端方法，如圖 4 所示。
圖 4 SOMA 方法
SOMA 方法提供了用于 SOA 設計的描述性指導，并且是 SOA 解決方案設計模式的基礎（請參見圖 5）。
圖 5 用于 SOA 參考體系結構分層解決方案的 SOMA 指導
服務標識
服務標識的目標是創建候選服務及其對業務有意義的關聯操作的初始集合。服務標識主要由軟件架構師來完成，并且通常包括業務分析人員以支持角色形式的參與。
在服務標識期間，將創建服務模型工作產品，并移交給負責服務規范的軟件架構師。服務標識與產生服務模型的分析級別同義，而服務規范則是設計級別。
服務標識的關鍵輸入包括：
- 業務分析和建模
用于定義業務體系結構。CRM 通常用于業務分析，以幫助客戶了解其業務和能力，并確定能力差距。也可以使用其他方法來進行業務分析。
- 服務注冊中心和存儲庫
現有的服務和有關它們的信息通常存儲在服務注冊中心和存儲庫中。該帳戶開立項目是第一次采用 SOA；因此不存在現有的服務。
讓我們進一步了解三種用于確定候選服務的補充技術：
- 目標-服務建模
- 領域分解
- 現有資產分析
目標-服務建模
目標-服務建模的關鍵目標是證明服務的可跟蹤性和與業務目標的一致性。目標-服務模型是一種由內向外 (middle-out) 的方法，在相應輸出可用時迭代地用于驗證通過領域分解和現有資產分析技術確定的候選服務列表的完整性。
在開發目標-服務模型時，您通常與業務主管、業務分析人員和主題專家緊密合作，以確定范圍內的業務目標和項目的階段。對于每個目標和子目標，您將確定可用于評估業務性能的關鍵性能指標 (KPI) 和度量。
JKHLE 銷售管理業務組件中的服務標識重點目標是確定支持該業務組件的服務。表 1 提供了一個業務目標的摘要和支持 KPI，以說明目標-服務模型。
表 1 目標-服務模型的業務目標和 KPI
| 1.1 將創建和管理帳戶的成本降低 10% | $1,000,000 | 1.1.1 將帳戶激活成本降低 50% | AccountActivation 組合
|
領域分解
對于領域分解，我們采用自頂向下的方式工作，將業務領域分解為主要的功能區域和子系統。在下一個級別，我們進一步將功能區域分解為流程、子流程和高級業務用例。
注意：高級業務用例通常是作為服務公開的理想候選者，并且可以提供初始的設計范圍。
領域分解使用并增強領域分析和領域工程方法的子集，包括：
- 功能區域分析
將領域分解為功能區域可以為 IT 子系統及其實現服務的對應服務組件的設計提供業務邊界。如果沒有提供 CBM，則為 SOMA 合作項目執行領域分析。
- 流程分解
執行業務流程建模以將流程分解為子流程和任務。對于初始的候選服務列表，三個級別的分解通常就足夠了（請參見圖 6）。
- 面向變化的分析
全面觀察流程、規則、策略和結構（數據），以確定候選共性。下一步，分離出流程、規則和結構的變化。
圖 6 流程分解
分解集中于“帳戶開立”流程以及“帳戶激活”和“驗證”功能區域，如圖 7 所示。
圖 7 帳戶開立流程和功能區域的領域分解輸出
現有資產分析
現有資產分析的主要目標是最大限度地重用現有的應用程序事務、現有系統中的模塊和打包的應用程序。在執行現有資產分析時，我們采用自底向上的方法以確定候選服務。可能會確定一些新服務，并且在其他情況下，該技術將確認前一項技術的標識結果。
觀察圖 7，Ursula 與 Edmund 使用自底向上的方法，共同確定 JKHLE 環境中的現有應用程序和事務，以最大限度地實現重用。Edmund 讓 Ursula 知道許多現有的中間件和后端應用程序，例如 CICS、IMS、SAP 和 Siebel。Ursula 評估每個現有的應用程序，以確定應該將哪些應用程序作為帳戶開立流程應用程序的服務公開。他們可以使用 IBM WebSphere Studio Asset Analyzer 來掃描 IBM System z?（大型機）和分布式軟件，以確定并在存儲庫中存儲相關的應用程序信息，其目的是促進和了解哪些資產可以成為可重用組件并作為服務公開。
現有資產分析并不只是將現有的應用程序接口作為 Web 服務公開。需要周密考慮以確定現有應用程序的接口是否允許良好的服務設計（請參見圖 8）。
圖 8 將現有應用程序作為服務公開的選項
如圖 8 所示，存在幾種公開現有應用程序的選項：
- 將現有應用程序包裝為服務
將功能保留原樣，但是使用工具或中間件將現有功能作為服務公開。例如，將 CICS 應用程序作為 SOAP Web 服務公開（也稱為直接公開）。
- 將現有功能包裝并替換為服務
按上述方式包裝功能，但是在以后使用最終的服務規范來重新開發服務。然后，替換原始服務，并將客戶端重定向到新的實現。
- 使用更適合于服務調用的適配器
在某些情況下，無法包裝某個功能并將其作為服務公開。
但是，能夠以更容易集成的形式包裝該功能，例如消息隊列接口或 Java 連接器體系結構（Java Connector Architecture，JCA），從而允許新服務就地訪問該功能（也稱為間接公開）。
- 將功能集成到服務中
在某些情況下，只需將現有的功能用作服務實現中的一個邏輯組件，即可讓新服務就地訪問該功能。
在執行每一項標識技術之后，將確定一個修訂后的候選服務組合，這樣就為制定規范做好了準備。
服務規范
服務規范定義依賴關系、組合、公開決策、消息、服務質量約束以及與服務狀態管理相關的決策。服務規范任務的目標是詳細描述服務模型。
服務規范包括以下子任務：
- 應用 Service Litmus Test 以做出公開決策
- 確定服務依賴關系
- 確定服務組合和流
- 確定非功能性需求
- 指定服務消息
- 編寫狀態管理決策文檔
應用 Service Litmus Test 以做出公開決策
使用 Service Litmus Test 以做出服務公開決策。圖 9 突出顯示了需要公開的 JKHLE 候選服務。
圖 9 要公開的服務
確定服務依賴關系
詳細的服務檢查可以揭示對用于實現服務功能的其他服務或應用程序的服務依賴關系。
存在兩種需要考慮的依賴關系類型：
- 功能依賴關系是這樣的服務之間的依賴關系，即這些服務彼此依賴以交付所需交付的服務。例如，AccountActivation 組合服務具有對 ARSetup、AccountSetup 和 CreateAccount 服務的依賴關系。
- 流程依賴關系是這樣的服務之間的依賴關系，即這些服務編排在一起以構成業務流程。例如，帳戶開立流程依賴“確定資格”前提條件和“創建帳戶”流程依賴關系。
確定服務組合和流
檢查功能區域和業務流程可以幫助詳細描述服務及其流的組合。服務流規范描述服務之間的編排。例如，帳戶激活組合服務是一個長時間運行的可中斷流程宏流。“帳戶查詢”是一個短時間運行的不可中斷流程（微流）。
確定非功能性需求
服務模型必須考慮用于指定服務質量 (QoS) 的非功能性需求。例如，“帳戶查詢”服務可用性需求為 99.999%，帳戶激活服務的帳戶激活性能需求為在四天內激活。
指定服務消息
服務模型中的數據流通常以在服務之間流動的消息的形式表示。在確定服務規范的過程中，存在數據模型未完成的情況。要考慮有關將實現的服務的詳細信息在此時間點不足夠的情況。雖然如此，仍然需要考慮用于服務輸入和輸出的數據和消息。例如，表 2 指定了 AccountInquiry 服務的服務消息。
表 2 指定服務消息
| 服務 | AccountInquiry |
| 主題 | QueryAccount |
| 輸入消息 | CustomerInformation |
| 輸出消息 | AccountInformation |
編寫狀態管理決策文檔
在某些情況下，服務組合需要編寫狀態管理文檔，例如有狀態、無狀態、帶有緩存狀態的狀態等等。
例如，存在流程的某些部分的狀態管理可能由組合服務或其他元素控制的情況。
服務組件規范
服務規范任務的最后一部分是組件規范。孤立地執行此任務通常是非常困難的，因此實現任務通常并行地執行并且是迭代的。服務組件規范包括以下子任務：
- 確定組件屬性
- 確定事件和消息
- 確定組件內部流
- 創建組件類關系圖
- 面向變化的設計
可以使用 IBM Rational Software Architect，以 UML 的形式為服務組件規范任務創建若干工作產品。
服務實現
在確定并指定服務以后，需要做出有關每個組件如何實現功能的關鍵體系結構決策。
服務分配
在整個生命周期中以迭代的方式將服務分配到組件，以執行用于將服務分配到企業組件的服務分配。例如，帳戶查詢服務被分配到客戶 CICS 后端系統（請參見第 12 頁上的圖 7）。
技術可行性探索
需要確定并評估技術約束，以確保公開候選服務在技術上是可行的，對于在現有系統分析期間確定的服務尤其是如此。通常使用技術原型來探索技術可行性。
將組件分配到各層
將組件分配到應用程序體系結構中的各個 SOA 參考體系結構層是在指定組件并編寫實現決策文檔之后執行的（請參見第 12 頁上的圖 7）。
表 3 提供了關鍵的服務實現決策的摘要
表 3 服務實現決策
| 客戶/帳戶 | 帳戶查詢 |
|
|
| 帳戶激活 |
|
|
SOMA 建模環境
SOMA 建模環境（Modeling Environment，ME）提供模型、方法、IBM 工具和內容的內聚聯系，以支持對用于 IBM 客戶服務合作項目的 SOA 解決方案進行基于資產的開發。
業務轉換分析和服務設計
注意：業務轉換分析（Business Transformation Analysis，BTA）和服務設計實現使用 RUP SOMA 業務轉換分析方法。
服務設計使用 IBM Rational Method Composer 包括的 RUP SOMA 方法中捕獲的過程。 IBM Rational Software Architect 用于創作和重用服務設計模式和最佳實踐，包括數據和部署建模以及服務組裝。
Ursula 和服務設計團隊成員開始進行有關如何使用 BTA 和服務設計的培訓。該團隊計劃使用此方法為將來的 SOA 項目創建服務設計。
在“用于服務設計的 SOMA”中，我們在“帳戶開立項目”的上下文中描述了 SOMA 的核心元素。在本部分，我們將重點介紹業務轉換分析 (BTA) 和服務設計實現的關鍵元素，這些元素利用了 IBM Rational Method Composer 中包括的 RUP SOMA 方法。 BTA 和服務設計實現通過應用自動化的設計工具和流程，以改進設計一致性和縮短上市時間，從而提供正式的說明性 SOA 設計方法。
圖 10 顯示了核心 RUP SOMA 用例和參與者。RUP SOMA 利用了“應用基于模式的工程方法”的概念。
請注意，參與者將帶模式的 BTA 和服務設計應用于執行業務轉換分析用例，以及包括標識、指定和實現服務的核心 SOMA 用例。
圖 10 核心 RUP SOMA 用例
圖 11 顯示了用于 BTA 和服務設計的擴展流程。RUP SOMA 流程步驟顯示得非常粗略。更詳細的信息在 IBM Rational Method Composer 包括的 RUP SOMA 方法中。
請注意數據建模、集成服務和部署建模的連鎖流程。在此例中，RUP SOMA 流程使用數據建模的結果。集成服務和部署建模主要是 RUP SOMA 的后續流程。管理可重用資產是擴充所有其他流程的基礎結構流程。
IBM 推出的重用管理解決方案基于 IBM Rational Asset Manager，后者用于管理和治理對任何角色和規則有利的幾乎任何資產的重用。Rational Asset Manager 可以與 IBM WebSphere 集成在一起。服務注冊中心和存儲庫支持在組織的標準資產重用流程上下文中重用和治理與服務相關的運行時資產。
圖 11 BTA 和服務設計擴展流程關系圖
圖 12 顯示了 RUP SOMA 中定義的主要活動：
- 執行業務轉換分析：生成用作服務設計輸入的業務和業務流程模型。
- 標識服務：發現候選服務并將其組織為層次結構以便于理解。
- 指定服務：指定服務的外部視圖，并充實服務傳遞的消息。
- 實現服務：做出有關服務實現的決策。
RUP SOMA 流程沒有充分強調可靠的需求管理在整個 SOA 設計生命周期中的作用。因此，添加了管理需求流程元素。如圖 12 所示，整個生命周期中非常協調地使用了 IBM WebSphere Business Modeler、IBM Rational RequisitePro? 和 IBM Rational Software Architect。
圖 12 用于 BTA 和服務設計的核心 RUP SOMA 流程
在下面的幾個部分中，我們將重點介紹核心 BTA 和服務設計用例的重要參與者、方法與模式、工具和工作產品。
執行 BTA
圖 13 顯示了執行 BTA 流程中的主要活動。BTA 的結果是創建了描述以下內容的工作產品：
- 業務的靜態結構
創建業務分析模型并執行功能區域分析的活動。
- 業務的動態特性
創建業務用例模型，并通過 WebSphere Business Modeler 業務流程實現業務用例。
BTA 活動可以產生業務體系結構的完整描述。BTA 活動還可以提供與業務相關并且是服務設計的必需輸入的模型。服務設計還使用業務規則和業務目標作為服務發現的輸入。BTA 還包括集中于那些構件的活動。
圖 13 RUP SOMA——執行 BTA
標識服務
圖 14 顯示了用于標識服務的 RUP SOMA 流程。該流程依賴并行執行的子任務，這些任務用于標識候選服務。同時使用不同的方法可以極大地提高發現完整候選服務集的機會。
圖 14 RUP SOMA——標識服務
指定服務
圖 15 顯示了用于指定服務的 RUP SOMA 流程。該流程用于定義服務的外部視圖，以及用于實現服務的子系統和組件的外部視圖的設計。在每個抽象級別，描述了接口、接口簽名、接口協議和消息。此外，將在總體流程的此部分期間處理更細粒度的元素（例如原子服務）的編排，以實現更抽象的元素（例如組合服務的接口操作）。
在此級別的設計完成之后，可以使用產品化的 Rational Software Architect 轉換來創建可供 IBM WebSphere Integration Developer 使用的項目和內容，包括描述服務接口的 WSDL 文件和描述元素（這些元素用于實現服務）執行的 BPEL。內容為集成開發人員提供了起點，此起點基于解決非功能性以及功能性需求的已架構 IT 解決方案，從而給集成開發人員帶來好處。
圖 15 RUP SOMA——指定服務
實現服務
圖 16 顯示了用于實現服務的 RUP SOMA 流程。做出有關使用哪些現有資產來實現服務的決策。
在使用新組件以實現服務的情況下，將做出有關在總體系統體系結構中的何處使用那些組件的決策。
圖 16 RUP SOMA——實現服務
用于流程組合的業務服務設計
注意：用于流程組合的業務服務設計實現演示了使關鍵業務度量與業務目標保持一致的流程建模和模擬。
Ursula 從業務分析人員那里了解到需要對帳戶驗證流程進行流程改進。Ursula 使用 IBM WebSphere Business Modeler 來模擬現有的流程，然后在通過關鍵度量模擬來實現的流程優化基礎上創建了建議的流程。
當前帳戶驗證流程
下面，我們將描述當前帳戶驗證流程（如第 26 頁上的圖 17 所示）。帳戶協調人員檢查客戶申請，并研究有關多個不同系統的信息，以確定是否需要信用報告。
如果不需要信用報告，則客戶申請將跳過該流程的大部分內容。如果需要信用報告，則帳戶協調人員將向信用調查機構打電話或發送傳真，以請求信用報告。由于通信方法（傳真或電話）問題，信用調查機構沒有為 JKHLE 提供針對其服務的優惠定價。獲得多個信用報告非常昂貴并且耗時。
JKHLE 無法區分高風險和中等風險的客戶，從而導致遠高于行業平均水平的大量拒絕受理請求。最后，帳戶協調人員發出了批準。批準的定價是通過參考一組復雜的紙質手冊來確定的。
當前流程中存在多處流程改進余地。
- 缺乏單一客戶視圖和信用流程業務規則導致我們定購了超過需要的信用報告。
- 手動的信用報告檢索流程高度不一致、代價昂貴并且非常耗時。
- 太多的客戶請求被拒絕，導致潛在客戶不愉快并導致銷售代表不滿。
- 雖然定價和帳戶規則相當簡單，但是其值更改得非常頻繁。由于該過程是手動的，很難實現快速更改。
圖 17 帳戶驗證（現有）
預期的帳戶驗證流程
Ursula 在 WebSphere Business Modeler 中修改了模擬的帳戶驗證流程來處理上述流程改進，以創建如圖 18 所示的基準。接下來，Ursula 可以通過更改流程中的關鍵度量或值，從而試著優化該業務流程。這稱為流程優化（請參見圖 19）。
優化后的流程具有以下改進：
- 自動化的完整客戶視圖減少了需要信用報告的客戶數量。
- 自動化的信用報告顯著降低了成本并更加快速。
- 批準更大比例的客戶請求。
- 基于規則的動態定價，可在業務需求的基礎上根據需要進行更改。
- 平均持續時間變化百分比：加速 97.6%
- 加權平均利潤：增加 84.7%
圖 18 帳戶驗證（預期）
圖 19 帳戶驗證——用于優化的流程模擬
集成開發人員 Jason Smith 根據前面的實現中描述的方法，使用指定的服務和實現的組件組裝并組合了該業務流程。
|
總結
了解到 Ursula 已完成了帳戶開立項目的設計，Sandy 非常高興。通過與 IBM 的合作，Ursula 能夠將用于服務設計的 SOMA 方法應用于帳戶開立服務設計。此外，服務團隊學會了如何使用 RUP SOMA 方法來為將來的 SOA 采用創建服務設計。
帳戶開立服務的設計和開發團隊發現，用于 SOA 設計場景的 IBM 工具集成良好并且很容易使用。諸如 IBM Rational RequisitePro、Rational Method Composer 和 Rational Software Architect 等工具提供了功能豐富的工具環境，可用于加速創建應用 IBM 方法的服務設計。使用 IBM WebSphere Business Modeler 對于業務服務設計和流程組合非常有幫助。
總而言之，帳戶開立案例研究中對 SOA 設計場景使用了以下 IBM 產品：
- Rational Method Composer
- IBM Rational RequisitePro
- IBM Rational Software Architect
IBM Rational Software Architect 中包括的產品功能：
- IBM Rational Application Developer
- IBM Software Modeler
- IBM Rational Data Architect
- IBM WebSphere Business Modeler
- IBM WebSphere Integration Developer
- IBM WebSphere Studio Asset Analyzer
總結
以上是生活随笔為你收集整理的SOA 案例研究：SOA 设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SOA 的基本概念及设计原则浅议
- 下一篇： 进入公司前与Boss的会谈话