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 基礎架構以及傳統存儲與細存儲之間操作上的差異：
圖 1. 當前系統的上下文
圖 2. 今后系統的上下文
約束
SoT 項目必須處理下面的主要問題和約束：
細存儲概念的存在需要被確認及驗證。
組織中文化變遷的影響：客戶端需要被調整以適合于現有的 COTS 業務流程和規則，以便優化未經優化的 COTS 應用程序組件及新技術的使用效果，并且為了今后的功能及技術停留在已更新的路徑上。
需要評估 COTS 供應商的能力來配置必要的基于極度挑戰性的時間線的資源（Gartner Group 評估，2004 年 9 月和 11 月）。
部署日程安排，需要適合于季節性的銷售日程。
需要將存儲的部署配置的數目降到最小。
SOA、服務和組件的概述
面向服務的體系結構的更新及集成
正如 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 零售映射的當前版本：
表 1. 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 領域。
表 2. CBM 命中映射
延伸閱讀
文章來源于領測軟件測試網 http://www.k11sc111.com/