模板
教程
環境
性能
功能
管理
SOA面向服務的業務轉換在零售業中的最佳實踐
SOA面向服務的業務轉換在零售業中的最佳實踐
blueski推薦 [2005-4-8]
出處：IBM DeveloperWorks
作者：Min Luo等
Min Luo （minl@us.ibm.com） , 高級認證 IT 架構師, IBM Global Services
Prakash Mall （mprakash@in.ibm.com） , 咨詢 IT 架構師, IBM Global Services
Diptiman Dasgupta （ddasgupt@in.ibm.com） , 咨詢 IT 架構師, IBM Global Services
Rajesh Nachaloor （rnachalo@in.ibm.com） , 咨詢 IT 架構師, IBM Global Services
Julian C. Petriuc （jpetriuc@us.ibm.com） , 認證咨詢 IT 架構師, IBM Global Services
Liang-Jie Zhang （zhanglj@us.ibm.com） , 總架構師，行業標準, IBM Software Group
Richard Baca （rbaca@us.ibm.com） , 管理顧問, 分配實踐, IBM Global Services
Jack Ehrhardt （Jack_Ehrhardt@circuitcity.com） , 系統架構師——零售存儲操作, Circuit City Stores
2005 年 3 月
從最近多個百萬美元的項目（包括服務、硬件、軟件和托管）的實施框架中發現創新的解決方案框架，將其用于能夠創建更有效基礎架構的最大的電子零售鏈之一。該框架有助于線形存儲銷售并支持辦公操作，具備中央辦公功能，勞動力管理、訂單管理和庫存管理。項目開發組及本文作者采用了以模型為中心的解決方案來分析并設計用于集成包解決方案組件和遺留系統中的面向服務的集成層。此外，他們設計并開發了輕量級的企業服務總線（Enterprise Service Bus，ESB）來實現基于服務的集成。解決方案提供者使用此套標準服務規范通過 ESB 提供或使用這種服務。提出的這個解決方案框架提供了以零售業為中心、技術和平臺獨立的、基于服務的整合層（最終是一個以零售為中心的 ESB 實現），其他零售商可以無需費力地將其采用。本文（該系列文章中的第一部分）重在創建用于集成的以零售為中心的服務模型創新解決方案。
引言
六年多的時間里，我們的客戶試著將他們的超過 16 年的以存儲為中心的（高級分布式的，每個存儲都是自我提供的計算島）、包羅萬象的、重量級的零售終端（Point of Sale，POS）系統。遺留 POS 系統使用私有設備（包括存儲服務器本身），提供了越來越復雜的僵化的業務邏輯，并且需要越來越昂貴的支持和維護。經過這些年，存儲系統已經發展成能夠支持許多復雜的業務流程，適合于內部的存儲及共有的操作?，F有的系統被建立在高度定制的體系結構上，使得修改非常困難且繁瑣。此外，客戶端不再是老式的私有 POS 設備的替代部分的來源，并且生產更多在財政上是不可行的。最終，存儲服務器的容量不能再被擴大了，并且它不再完全支持對于最繁忙的存儲的需求。它是緩慢的、不響應的，并且將對存儲銷售和客戶服務產生越來越重大的影響。
在九十年代末，替代的系統被開發出來，它試著利用商業現貨供應（commercial-off-the-shelf，COTS）POS 產品，但是它只能代替原始系統的一部分功能。對于替代系統被安裝的位置的存儲，老式的系統仍舊需要許多內部存儲的共有功能。這導致了過量開銷的影響和風險，因為它需要客戶端來維護兩個系統。廣泛的定制和以存儲為中心的特性使它非常昂貴，并且客戶端不能承受研究出詳細的解決方案所需的時間。
在本文中，我們提出了新的系統，最初設想它不僅能克服以前系統中的許多問題，而且能夠引入新的細存儲操作的概念，它僅提供了存儲中需要的最少的系統功能，并且在托管和數據中心環境下集中了許多其他功能。我們采用了一個創新的解決方案來分析并設計基于服務的集成層，利用業務流程建模和執行中最新的技術，面向服務的體系結構（Service-Oriented Architecture，SOA）和 Web 服務，并且有效地使用建模及設計開發工具。這個最終的系統被稱作 Store of Tomorrow (SoT).
確定關鍵業務的目標
SoT 項目的目標是利用現有的基于零售的知識并且應用行業標準、最佳的實踐和商業現貨供應應用程序。下面的關鍵目標是有幫助的：
- 采用主要行業的最佳實踐及 POS 的零售業標準。
- 利用 COTS POS 和其它支持應用程序組件的最佳類別。
- 最小化定制。
- 調整業務流程和規則以適應所選的應用程序組件。
- 推動細存儲的基礎架構。
- 增長客戶的經驗。
- 減少應用程序支持。
- 應用開放技術標準。
細存儲概念
SoT 將存儲 IT 的基礎架構最小化。僅每個銷售終端和基本的正常存儲操作上的必要 POS 功能仍舊被存儲，所有其它的業務功能交給集中的托管環境。這導致：
- 減少了存儲 POS 的設備并且更好地利用了不太昂貴的工作站和大眾化設備。
- 在傳統存儲中的軟件堆棧被轉換成了中央托管環境（如圖 1 和 2 所示）。
- 不太強大的、非常有成本效益的內部存儲的服務器僅被用于數據引用及其它設備和位置之間傳遞信息。
- 增長客戶的存儲經驗，因為銷售事務是非常有效的，并且客戶的需求能適合于更多的服務、銷售代表和其它設備（例如，手持和不太昂貴的工作站）。
- 更多的資源被定向到核心策略業務指導。
下兩圖描述了基本的 IT 基礎架構以及傳統存儲與細存儲之間操作上的差異：
約束
SoT 項目必須處理下面的主要問題和約束：
- 細存儲概念的存在需要被確認及驗證。
- 組織中文化變遷的影響：客戶端需要被調整以適合于現有的 COTS 業務流程和規則，以便優化未經優化的 COTS 應用程序組件及新技術的使用效果，并且為了今后的功能及技術停留在已更新的路徑上。
- 需要評估 COTS 供應商的能力來配置必要的基于極度挑戰性的時間線的資源（Gartner Group 評估，2004 年 9 月和 11 月）。
- 部署日程安排，需要適合于季節性的銷售日程。
- 需要將存儲的部署配置的數目降到最小。
面向服務的體系結構的更新及集成
正如 Albert Einstein 所提出的，“事情應當處理得盡可能簡單，但是不能太簡單?！痹S多過去已建立的軟件系統沒有通過該測試，因為它們太復雜、太昂貴，或走向另一個極端 —— 太簡單以至于不能完成實際的業務需求。達到恰當的簡單化水平好像是不現實的。將事情變得更加困難的是，在 SOA 出現之前，不存在有效的機制來消除業務需求與 IT 功能之間的隔閡。
SOA 是一種體系結構樣式，它努力實現交互的軟件組件之間的松耦合。通過使用 SOA，服務集通過簡單傳遞的數據或調整業務活動（包括兩個或更多的服務）來彼此傳遞信息。它通過一套簡單通用的接口（在接口上僅編碼通用的語義）實現了交互軟件組件之間的松耦合。所有提供者和客戶都應當能夠使用該接口。此外，SOA 采用了描述的消息，該消息受可擴展的通過接口傳遞的 schema 的限制。這樣的 schema 限制了消息的詞匯和結構，并且允許在不破壞現有服務的條件下引入服務的新版本。即便要也是非常少的，系統行為通過描述的消息來指定。以這種方式，您可以有效地建立一套服務，它有明確定義的接口，并且能夠在多重業務上下文中潛在地被復用。使用 SOA，應用程序是松耦合的，并且可以在服務/接口（協議）級被集成，而不是在實現級，如同過去的實踐一樣。這使得在 IT 滿足任何業務需求的變更時更加靈活、機動、可擴展。
SOA 不是新概念；Common Object Request Broker Architecture（CORBA）和 Distributed Component Object Model（DCOM）早就提供了類似的功能。然而，這些對于服務定位的解決方案受一些問題的困擾，如緊耦合場景和所有權設計及實現。
服務與組件
什么是服務？服務只是一些應用程序功能，它們被發布成業務流程的組件。同組件一樣，它提供了獨立的構建模塊，這些模塊共同代表業務應用程序環境。服務是明確定義的、獨立的工作單位，不依賴于上下文或其它服務的聲明，由服務提供者執行來完成服務客戶所需的最終結果。提供者及客戶都通過代表他們自己的軟件組件來承擔職責。使用 SOA，所有的業務任務或流程都可以被設計并作為互聯網（或其它任何網絡）上使用的服務來構建。
軟件組件體系結構已經作為應用程序開發的許多領域中的標準設計范例而形成了。它從面向對象的技術發展而來，通過提供高級別的提取并將低級別的對象封裝進可復用的技術組件（調整以適合于業務操作并可以被反復設計、開發和提煉）中而實現。
為了解釋組件和服務之間的關系，通過閱讀組件如何被定義成“可執行的代碼單元，它提供了相關服務的物理黑盒封裝。僅通過包含交互標準的一致的、發布的接口才能訪問它的服務。組件必須能連接到其它組件上（通過通信接口） 來組成大組”（企業系統中基于組件的開發：應用選擇透視圖——請見參考資料）可以得到啟發。
企業 JavaBean 是構建基于 Java 的桌面應用程序的組件標準。COM 是通用的 Microsoft® 組件模型，它是應用程序互用性的核心。在 1999 年 7 月，Object Management Group 通過了 CORBA 組件模型（CCM）規范，它擴展了用于電子商務部門的應用程序的企業 JavaBean。在所有情況下，組件體系結構的目標是簡化應用程序設計流程并提高應用程序開發的速度。
業務建模
業務模型是實際的復雜業務的簡化視圖及業務如何運轉的提取。業務結構表示在模型“將承擔交流、提高或創新的基本任務，并定義了支持業務所必需的信息系統需求。這樣的業務模型對于指導業務起到規劃的作用”（使用工作中的 Uml 業務模式的業務建模：工作中的業務模式——請見參考資料）中。
挑戰是以精確且對用戶友好的方式來將業務流程和業務系統建模。業務系統的描述包括流程描述和靜態結構。流程的最直接的模型是為了達到某一目的而執行的活動或任務的序列。如同普遍接受的符號標準一樣，統一建模語言（Unified Modeling Language，UML）及其可能的擴展對于描述軟件系統來說是足夠豐富的。UML 也可被用于抽象層，這里不涉及實現細節。一些 UML 圖表從直觀上看（例如，活動圖、時序圖或協作圖）與域專家使用的那些非常類似。而且，他們的語義是精確定義的。為了軟件設計，如果必要的話，同一圖表可以配有實現細節。例如，UML 時序圖和 UML 活動圖是對用戶友好而且精確的業務流程規范。
在我們的以模型為中心的解決方案中，使用標準流程建模軟件（例如 Microsoft Visio）創建的業務流程被轉換成 IBM® Websphere® Business Integration Modeler（Business Integration Modeler），并且使用 IBM Rational® Rose 中的 UML 時序圖來將內部組件的交互建模并分析。
連同我們的以業務為中心的服務模型一起，一套適合業務的服務被結合進來（包含并編排）以實現業務目標。IT 系統提供了這些服務的接口并將它們結合進應用程序中以支持快速變更的業務需求。將服務顯示成一套接口，該接口完全不依賴于它們的實現或位置。有時（不必經常）需要在業務用例級創建這些服務。在這個級別上，我們處理業務希望在業務流程中發布、觸發或支持的原始活動。
采用 IBM 的組件業務建模（Component Business Modeling，CBM）和面向服務的模型和體系結構（Service-Oriented Modeling and Architecture，SOMA）（請見參考資料），我們采用從上到下的解決方案來從基礎零售組件模型中確定一套以零售為中心的業務服務。我們創新的解決方案及適當地使用 Business Integration Modeler and Rational Rose 使我們能夠發現適合業務的服務、它們的從屬和支持的大規模的業務應用程序組件。同時，我們也采用從下往上的解決方案來確定 COTS 或現有的遺留應用程序最好提供哪個服務，并且最終將確定的業務服務映射到選定的 COTS 零售應用程序組件或遺留系統中。
組件業務建模（CBM）
組件業務建模（CBM）是 IBM 分析和建模的技術，它將企業表示成一套不重疊的協作業務構建模塊（組件），它提供了通過交互來實現業務需求的業務服務。它提供了其它業務分析方法（例如價值鏈或流程分解）沒有提出的重要的觀點。
在 CBM 中，業務組件是企業的部分邏輯視圖，該企業是由資源、人、IT 知識資本和需要傳遞一些業務值的性能測試支持的。組件具有不連續的邊界，由它提供的業務服務和它使用的業務服務來定義。類似于基于組件的開發方法中使用的軟件組件概念，CBM 業務組件是黑盒：它的服務用戶無需知道組件如何知道它是怎樣實現的。這使得業務應用程序組件可以很好地更新或還原。此外，業務組件映射被用于組織列表視圖中的業務組件，表的縱行代表業務資格（諸如商品、產品、開發或營銷），表的橫行代表責任級別，它表現了決策和業務活動的范圍和意圖。
目前，CBM 組件為一些已經開發的關鍵行業映射，一些已經被確定并組織成候選服務。對于零售業，創建初步的組件映射（表 1），沒有很多細節或服務鑒定。本文的一個目的是使用更加具體的規范來擴展 CBM Retail Component Model，用于組件和它們的服務。此外，實行以模型為中心的解決方案利用 UML 和 Rational Rose 的功能來獲取業務需求和業務流程及用例，并逐漸將它們轉換成業務組件和服務。當然，本文我們更強調集成。
下表展示了 CBM 零售映射的當前版本：
| 銷售及客戶管理 | 產品 | 存儲及通道 | 分配及入庫 | 業務管理 | |
| 規劃 | 客戶分段，客戶關系策略，銷售策略及規劃 | 商品策略，銷售規劃，分類規劃，產品開發（如私有標簽），商標管理，定價策略，資源規劃 | 多通道策略，存儲及通道策略，存儲設計和布局，通道設計和布局 | 分配、倉庫、供應鏈策略；運輸規劃，供應者關系規劃（物流） | 法人策略，財政管理及規劃，LOB 規劃，位置策略 |
| 管理 | 客戶行為建模，市場及競爭者的研究，客戶滿意度的衡量及管理，委托，呼叫中心，活動管理 | 價格/提升管理，存貨管理，供應期限管理及定價，產品生命周期管理（product lifecycle management，PLM） | 存儲及通道的收益率，存儲操作管理，事務管理，計劃管理 | 供應者性能管理，內部物流，公司內部及外部物流，運輸/車隊管理，倉庫管理 | 聯合管理，業務性能報告，合法的常規命令，實際的資產及結構管理，風險管理，股票分類帳，人力資源（職業發展、培訓和招聘） |
| 執行 | 客戶服務，誠實，客戶交流，大規模銷售及廣告，目標營銷，售后服務，客戶庫 | 分配，PO 和貿易資金管理，購買/來源，需求預測，主數據管理 | 補給，服務發送，價格變更，時間及出現，庫存層，密室任務管理，失去防范，勞動力管理，POS 執行/現金管理，多通道呼叫中心 | 分配中心操作，衡量標準管理，返回及回收，產品跟蹤，運輸/車隊操作 | 人力資源管理/薪水冊，法人的審計，法人的賬目（GL、AP、財政部等），銷售審計，間接獲得，存款操作，PR 及投資者關系，IT 系統及操作 |
什么是服務模型？
如何確定、設計及構造服務仍舊保持藝術形式。服務沒有以標準的形狀或大小實現，并且它們都承擔著如我們前面所述的不同職責。依賴于利用那些服務的程度，可以在主要方面實現大量的標準化，例如：
- 應用程序體系結構
- 企業基礎架構
- 全球的數據交換
服務模型被用于統一標準化的工作并提供系統的標準方法來描述服務及它們之間的關系。Thomas Erl 最初指定并提倡 XML & Web Services Integration Framework（XWIF），其中闡述了服務的主要概念，尤其業務服務、流程服務和許多其它公共有效的服務類型（面向服務的體系結構——集成 XML 和 Web 服務的領域指導——請見參考資料）。Ali Arsanjani 也討論了被引入到 SOMA 中的分層的 SOA 模型，不僅是服務而且將它們關聯的屬性及關系形式化（請見參考資料）。我們依照解決方案并將它們擴展到某種水平，即將所有服務都建模并利用它們。
基于服務的集成
SOA 通過引入邏輯服務集成層（建立集成的公共基礎）來擴展了傳統的多層應用程序體系結構。一套標準程序接口被發布成表示層和業務層之間的服務，或一個業務（伙伴）與另一業務（另一伙伴）之間的服務。因此可以創建開放的共同操作的環境，它統一了異類的遺留平臺并超出了任何個人應用程序的范圍。本文重在應用 SOA 和面向服務的集成（service-oriented integration，SOI）方法和最佳實踐來設計適用于 SoT 的 SOI 層。
設計以零售為中心的，基于服務的集成層
下面，我們描述了設計以零售為中心的、基于服務的集成層的步驟和流程，以通用的購買項目業務流程為例。特別地，我們使用該業務實例來闡述服務確定、設計和實現細節的步驟。
這些步驟表明我們如何從 Business Integration Modeler 中的 CBM 邏輯業務組件中獲取候選服務，我們如何在 Rational Rose 中創建服務模型，以及我們如何使用 Business Integration Modeler 來發布業務流程文件，最終我們將這些文件引入到 WebSphere Studio Application Developer——集成版（Application Developer）中來生成 Web 服務描述語言（Web Services Description Language，WSDL）中的服務規范。我們連續地展示了這些步驟，即使現實中它們是試探性的，并且實際上是這樣反復的。
1）領域分解
我們將 SoT 項目范圍的業務領域分解成了功能范圍的價值鏈。我們引導了并行的工作來確定并將業務流程（使用 Microsoft Visio）及用例（使用 Microsoft Word）建模。在那些工作中，我們也重新設計并確認了未被優化的 COTS POS 應用程序組件中的現有的實現的業務流程。
如前面所描述的一樣，我們使用 CBM 零售業映射作為創建邏輯組件模型的起點，因為它提供了該套業務組件（遍及零售業的各領域）的第一個入口?；跇I務流程及支持的用例，我們確定了與 SoT 相關的功能范圍，如表 2 所述。這樣的領域可以作為技術子系統實現的候選。
表 2 展示了與 SoT 相關的確定的 CBM 領域。
| 銷售及客戶管理 | 產品 | 存儲及通道 | 分配及入庫 | 業務管理 | |
| 指導 | 商品和位置規劃 | ||||
| 控制 | 價格/提升管理，存貨管理，訂單管理，種類管理，產品生命周期管理 | 存儲操作管理，事務管理，經營，計劃管理 | 業務性能報告，人力資源管理（職業發展、培訓等） | ||
| 執行 | 售后支持，客戶庫，客戶服務，誠實 | 主數據管理 | 補給/價格變更，時間及出現，產品生命周期管理，失去防范，POS 執行和現金管理 | 產品跟蹤 | 存款操作 |
業務流程建模
從業務流程建模的實踐中，我們創建了相關的完整的（還可以被提煉）適用于 SoT 的業務流程，然后將它們引入到 Business Integration Modeler 中。我們進一步提煉那些流程以幫助確定候選服務。
流程分解
通過使用 Business Integration Modeler，多個業務流程的公共任務被結合并發布成全球的任務。對于業務流程的特定任務被聲明成本地任務。一套公共的實現多個業務流程中可復用的業務功能的連續的任務被設計成子流程。
圖 3 展示了流程、子流程及任務的等級關系：
圖 4 展示了購買項目的業務流程模型：
服務確定
我們確定了基于內部組件交互的候選服務，我們從業務流程中獲得了這樣的交互?；谒x的 CBM 零售業務組件，我們首先通過組件將業務任務分組，然后確定內部組件的交互模式。這種內部組件的交互最初在 Rational Rose 中使用 UML 時序圖將其建模。
為了最終得出服務規范（在 WSDL 中適用的），將這種內部組件的交互建模得更好的方式是有效地使用 Business Integration Modeler。在回顧了產品特征之后，我們發現實現該功能的一種創新的方法：我們可以使用組織單元結構來表示組件，并且我們可以使用這種組織單元的出入流作為天然的服務候選。以這種方式，將任務分配給特定的組織單元依照它的核心業務功能，并且任何通過組織單元傳遞的信息都代表內部組件的交互并且可以作為候選服務。
圖 5 通過組織單元以泳道視圖展示了購買項目的業務流程模型。
從泳道視圖中可以明顯看出下列是可以被發布的用于購買項目業務流程的兩個候選服務：
- 在 Web 上找到存貨——由 Web Store 組織單元發布
- 在商店中找到存貨——由 Inventory Management 組織單元發布
為了確定數據服務，我們進一步分析了核心 POS 解決方案和已支持的或即將被支持的遺留系統之間的數據流。此外，設計數據服務使它們能夠被訪問以滿足應用程序的大多數（或所有的）數據需求。這里有 SoT 解決方案所需的三種類型的數據服務：
- 支持內部組件交互的數據服務
- 支持將 POS 事務數據上傳到遺留系統（私有格式）的數據服務
- 從遺留系統中下載公共支持的數據（包括商品、價格和財政等）的數據服務
我們也提取了通用的安全及工具服務來幫助內部組件的交互。
然后，我們列出了在這一步中確定的服務并將它們映射到文檔中。圖 6 展示了購買項目的候選服務清單。
3）業務流程實現
在這一步中，我們使用已確定的一套服務來說明可以通過應用程序組件和集成服務來實現所有需要的業務流程（請參閱圖 14 的購買項目的服務組合視圖。
4）服務分配及組件規范
如先前所述，我們通過將流程分解合并及對現有系統的分析來確定所有需要的服務。在這一步中，我們確保所有已確定的服務都有一個起點，它們都可以被業務流程及支持的組件追蹤到。
在這個過程中，我們進一步提煉并重構了候選服務，按照它們與邏輯業務組件的調整。最終，我們確定了業務應用程序服務的有限集，并將它們映射到提供這些服務的實現和管理的業務組件中。隨后，我們擴展了邏輯組件的規范使其包含分配的服務。
在這一階段，我們開發了實際平臺、產品和具備獨立供應商的以零售為中心的由邏輯 CBM 功能組件（可以被看作 CBM 零售組件模型的擴展）分類的服務的清單。
5）構造企業組件
在這一步中，我們分析并構建了所有選定的 COTS POS 應用程序組件、客戶端遺留應用程序和數據系統，從當前或今后系統的上下文中啟動并保持與所選的 CBM 邏輯組件的協調。我們稱那些技術組件為子系統。技術子系統是現有的客戶端企業系統或遺留系統，由供應商的產品或伙伴系統、或新確定的用于消除 COTS 產品性能與客戶端需求之間的障礙的應用程序封裝。該確定的 CBM 組件被映射到那些基于功能匹配的技術子系統中。
此外，我們將應用程序集成模式（流程集成及協作）應用到構建集成組件中。我們采用了企業服務總線（Enterprise Service Bus，ESB）模式來為所有應用程序提供統一的集成層。圖 8 描述了高級集成系統的視圖。
6）確定及構建技術子系統
如同我們前面所討論的一樣，SoT 的關鍵決策之一是使用 COTS POS 應用程序組件并將對這些 COTS 產品和客戶端遺留系統的更改降到最小?；谝惶坠餐_發的選擇標準，我們必須選擇一些 COTS 產品。此外，為了滿足標準業務的需求，我們必須定制 COTS 產品并設計開發一些新的應用程序組件。
在這一步中，我們采用從下至上的解決方案來分析如何構建 COTS 產品、新的應用程序組件和客戶端遺留系統，來幫助邏輯組件和服務的設計向物理實現的轉變。為了簡化，我們使用現有的 COTS 應用程序組件作為供應商封裝的解決方案和從新的應用程序中創建的新技術子系統。圖 9 展示了我們確定的技術子系統。
7）將功能組件映射到技術子系統中
在這一步中，我們將每個邏輯業務組件都映射到體系結構中的技術子系統中。下面是為了達到該目的而設計的電子表格的實例：
為了擴展 CBM，我們創建了下面的映射電子表格來說明 CBM 邏輯零售組件如何能被映射到確定的技術子系統中。
圖 11. 將 CBM 邏輯零售組件映射到確定的技術子系統中
8）創建服務模型
服務模型是我們的基于服務的集成的核心。分析和設計執行下面操作的構件是非常有用的：
- 確定需要被發布的服務。
- 指定服務提供者和服務客戶之間的合約。
- 指定關系、層次（如果存在的話），及其它服務屬性。
- 指定實現服務所需的組件。
下面的部分簡要地描述了如何將我們的創新的服務模型建模并歸檔。
服務組合：服務清單
該部分以業務功能或業務區域的年月日的次序列出了所有前面確定的服務。
a）服務映射（組合）
服務映射包含我們使用從上到下和從下到上的分析而確定的服務的清單。這里，我們列舉了前面步驟中確定的候選服務，以及它們的用法和調用關系。我們創建它來可視化地描述核心業務組件或技術子系統提供及使用的所有服務。圖 12 展示了為 SoT 所開發的一個版本。
b）服務層次
服務層次將服務分類。我們將未分類的服務的候選清單依照業務服務路線、多路業務服務和企業服務將它們組織在一起。我們使用服務層次來說明服務是否可以調用其它服務，它是否是其它現有服務的簡單組合。
c）服務發布決策
我們需要確定發布哪些服務，我們可以使用服務最終測試（回答問題：這些服務是否與業務相關以及業務是否要在企業周邊發布它們？）來完成。最終測試包括：
- 業務校準：業務是否同意發布服務？子流程和高級業務用例是服務發布的優秀候選。
- 透明度：服務提供者對服務客戶是否透明？
- 服務粒度：服務是否以適當的粒度水平來發布？服務不應當發布技術工具除非技術工具對服務客戶來說是有價值的。
d）服務流
該部分描述了如何使用確定的服務來將各種應用程序組件綁定在一起以完成業務流程的特定需求。下面的 UML 時序圖展示了內部組件的服務與實現購買項目的業務流程的交互。
e）服務組成
服務組成提供了服務的動態視圖。它展示了我們如何將這些服務編排進支持業務功能的組合服務中。如服務流部分中所示，我們也設計了組合服務，購買項目，它由許多小的服務組成，如Authenticate、FindInventory 等等，如圖 14 中所描述的。
您可以使用 Application Developer 來執行服務編排（關注該系列文章的第二部分，將討論如何使用 Business Integration Modeler 和支持的開發工具來創建基于服務的集成層）。
f）服務相關性
這里有兩種服務相關性：
- 前提條件的相關性：在開始執行當前調用之前另一服務調用必須已經成功地執行了。例如，找到存貨應當發生在存儲存貨之前；
- 處理相關性：另一服務調用需要成功地執行當前服務。
g）其它服務屬性
其它服務屬性包括服務級協議（如性能需求）、能力和安全。在這個階段，我們詳述并實驗了如何使那些屬性更合理且可實現。
9）服務規范及實現
當考慮如何實現服務時，我們需考慮：
- 服務細節
- 服務的數據輸入及輸出
- 服務是同步的還是異步的
- 協議需求（XML/HTTP、SOAL/HTTP、JMS、XML/MQ 等等）
- 服務組合
- 對于服務無功能需求。
我們也需要確定如何使用遺留和現有的企業功能，通過詢問諸如“我們要不要在遺留功能上放置包裝器？”或“我們需要為企業服務更改發布的接口嗎？”之類的問題。在回答完這樣的問題之后，就能做出服務實現決策并在服務模型中歸檔。
10）向 Application Developer 輸出服務模型
最后，我們將來源于 Business Integration Modeler 的模型作為 Business Process Execution Language（BPEL）和 WSDL 輸出，然后我們將它們引入 Application Developer 中。然后，我們進一步地編輯、增強、開發 Application Developer 中的流程編排。
結束語
作者提出了以模型為中心的解決方案，用于分析和設計基于服務的適用于集成包解決方案組件和遺留系統的集成層。他們使用 CBM 零售映射作為邏輯組件模型的啟動，過濾掉與 SoT 的當前范圍無關的內容。使用業務分析組開發的可用業務流程及用例文檔作為主要輸入，它們使用 WebSphere Business Integration Modeler 來為內部組件的交互建模，并將每個交互都確定成那些邏輯組件中的候選業務服務。他們分析輸入輸出消息和數據需求，并指導對每個服務的復雜性的最初的評估。他們將那些服務構建到邏輯服務模型中，他們進一步擴大邏輯服務模型使其包括公共業務和工具服務、數據和安全服務。他們將所選的邏輯業務組件映射到確定的包應用程序組件（子系統）中，并合并邏輯服務到那些子系統中。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
- 在文章soa-design1/index.shtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> "面向服務的建模和體系結構：如何確定、指定和實現您的 SOA 的服務"中發現分析和設計 SOA 所需的關鍵活動（developerWorks，2004 年 11 月）。
- 著手于應用程序開發工具及 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的中間件產品。您可以免費下載產品的測試版，或選擇 developerWorks 免費的 Software Evaluation Kit 的 Linux® 或 Windows® 版本。
- 獲得由 Thomas Erl 所著的書籍面向服務的體系結構：集成 XML 和 Web 服務的領域指導（Prentice Hall，2004）。
- 閱讀 IBM Redbook 中有關 SOA 和 Web 服務的內容——由 M. Endrei、J. Ang、A. Arsanjani、S. Chua、P. Comte、P. Krogdahl、M. Luo 和 T. Newling 所著的模式：面向服務的體系結構和 Web 服務（IBM 印刷，2004 年 4 月）。
- 了解更多關于企業系統中基于組件的開發：應用選擇透視圖，在 P. Allen 和 S. Frost 所著的書中（Cambridge 劍橋大學印刷，1998）。
- 了解更多關于業務建模的內容，在書使用工作中的 Uml 業務模式的業務建模：工作中的業務模式中（OMG 印刷，2000）。
- 通過參與 developerWorks blogs 加入 developerWorks 社區。
- IBM developerWorks 小組在全球了主持數百次技術簡報，您可以免費參加。
- 想獲取更多信息嗎？developerWorks SOA 和 Web 服務專區有成百上千篇信息文章，以及關于如何開發 Web 服務應用程序的入門級、中級和高級教程。
| 作者簡介 Min Luo 在 IT 行業有超過 15 年的經驗，對于管理軟件應用程序的設計和開發的整個生命周期有 8 年多的經驗。他完全了解業務上的各種技術的作用，并且知道如何有效地將它們應用于解決大規模且復雜的實際問題。他是面向對象的分析和設計、基礎組件和面向服務的計算和改進的開發方法的早期采用者、提倡者及導師。他成功地設計并實現了運輸、財政、制造業和大規模的政府社會福利事業。他也具備設計和開發與在線的分析處理和數據采集相集成的數據倉庫、各種操作的應用程序的研究和管理科學技術的專門技能。在 2000 年進入 IBM 之前，Luo 博士作為 Fortune 400 的兩個公司的高級經理和主管。自從 1997 年他作為一些大學的助理研究員。他擁有計算機科學的 B.S.（1982）和 M.S.（1987）以及電子計算機工程的 Ph.D.（1992）。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
