架構Web Service: 實戰Web服務
內容：
案例需求描述
應用的系統架構
Catalog Service
Order Service
Feedback Service
交互，交互些什麼?
爲什麼選擇基於Web服務的解決方案?
什麼是需要公開的?
參考資料
作者簡介
相關內容：
基於Web服務的應用、解決方案和開發平臺
什麼是Web服務?
爲什麼需要Web服務?
動態電子商務模式
柴曉路 ([email protected])
Chief System Architect
2001年8月14日
本文是架構Web服務的系列文章的第四篇，繼探討了Web服務的商業需求，技術定義和技術規範以及現有現有的Web服務實踐之後，通過使用一個具體的案例開始對Web服務實戰的篇章。在本文中給出了一個實際的具有實用性並且能夠延伸出去的計算機產品交易市場的案例，通過簡要的系統分析、模塊劃分，對鬆散系統間待交換的數據進行了界分，同時爲定義基於Web服務的API的數據結構奠定了系統和分析的基礎。
在先前的文章系列裏面，我已經對Web服務的商業需求、Web服務的技術實現以及Web服務當前的應用以及開發工具做了全面的介紹，那麼在接下來的文章中，我將結合一個實例來詳細地描述如何真正地規劃、設計和創建一個Web服務的具體應用。
本文所引用的資源主要包括兩類，一類是Web服務的技術資源網站，包含了大量Web服務的技術信息，另一類是Web服務“stack"系列技術規範，他們是一個整體的技術體系，包括UDDI、SOAP、WSDL、XML等。本文的最後給出了這些資源的鏈接，有興趣的讀者可以通過這些資源鏈接找到所需的內容。
案例需求描述
在這裏我們假設應用背景是一個計算機產品銷售市場，其中的角色及其對應的行爲描述如下：
計算機產品交易市場，該市場是聯繫計算機產品生產商/零售商與消費者之間的營銷平臺。其職責和功能包括：收集併發布來自各個計算機產品生產商/零售商的產品目錄；接受消費者的購買請求並可靠地遞送給生產商/零售商系統完成購買事務；採集來自消費者的消費反饋，給出商品購買的導引建議，並傳送給生產商/零售商。
生產商/零售商，這是直接銷售計算機產品的商家，他能夠通過自己的Web發佈產品目錄，同時也能將目錄傳送給計算機產品交易市場。他能夠接受訂單(來自自己的Web網站或者來自計算機產品交易市場)並轉入內部管理系統，至於資金流和物流則由離線系統完成。
消費者，計算機產品的購買者(可能是個人，也可能是企業)，他能夠訪問計算機產品目錄，能夠利用在線的定購服務進行購買。
通過對以上角色及其行爲的分析，我們認爲在最終的實現系統中應該有這樣幾種概要層次上的對象：
產品目錄，產品目錄由生產商/零售商產生，由計算機產品交易市場彙總歸類，由消費者瀏覽使用。
訂單，訂單由消費者生成，由計算機產品交易市場傳遞，由生產商/零售商接受。
反饋信息，由消費者產生，由計算機產品交易市場彙總歸類，由消費者和生產商/零售商使用。
用戶，用戶分兩類，一類是消費者用戶，一類是生產商/零售商用戶，分別用於處理兩類事務。
應用的系統架構
綜合上面的分析，我們可以將整個系統按如下架構劃分：
Figure 1. 系統劃分概要
大家可能會發現，Marketplace System和Retailer System這兩個系統沒什麼大區別嘛? 的確是這樣，我們在設計的時候應當無時無刻不能忘記"重用"這個概念，重用的組件越多，開發的代價就越少，維護的代價也越低，可擴展性也就越好，當然重用不能導致功能的異化，這也是我們需要注意的。
下面我花一點篇幅稍微解析一下框架中的三個主要服務：Catalog Service、Order Service和Feedback Service。
Catalog Service
對於這個服務而言，Retailer System中的Catalog Service應當是Marketplace System功能的子集。Retailer System中，Catalog Service應當具備如下功能：
類別(Category)管理，包括增加一個Category、刪除一個Category、修改一個Category等；
產品(Product)管理，包括增加一個Product、刪除一個Product、修改一個Product、移動一個Product(從一個Category下移動到另一個Category下)等；
數據交換，包括單個類別下所有產品的導入導出(Import/Export)，單個產品數據的導入導出，整個類別樹的導入導出等；
數據備份，整個目錄下所有產品數據的備份/恢復等。
而Marketplace System中，需要增加一個功能：在數據交換和數據備份模塊應當提供對指定數據擁有者的相關數據的操作，比如導出某個類別下IBM的所有產品等等。
Order Service
對於這個服務而言，Retailer System中的Order Service和Marketplace System中的Order Service可以說基本沒有什麼本質上的差別。他們都將具備如下功能：
接受訂單
向其他接受訂單的服務發送訂單
兩者的區別，僅僅在於Retailer System中的Order Service接受的訂單來自用戶界面，而需要向Marketplace System中的Order Service傳送。Marketplace System中的Order Service接受的訂單來自Retailer System中的Order Service，而需要向自己內部的企業應用傳送訂單。
Feedback Service
對於Feedback Service而言，在兩個系統中的地位與Catalog Service是類似的。
反饋信息(Feedback)管理，包括增加一條反饋信息、刪除一條反饋信息、修改一條反饋信息等，反饋信息可以掛在Category下，也可以掛在Product下(有針對一類產品的評測報告，也有針對一個產品的使用評價等)；
數據交換，包括與單個類別關聯或與單個產品關聯的反饋信息的導入導出(Import/Export)，以及與單個用戶(Retailer用戶，數據擁有者)相關的所有反饋信息的導入導出等；
Feedback可以看作是與整個產品目錄樹的各個結點相關聯的評論文章。不僅在Marketplace系統中由消費者發佈並歸消費者查詢，同時也將在相關的Retailer系統保存並可供Retailer使用。
交互，交互些什麼?
我們將以上功能描述加以總結，去除內部實現的部分，我們可以發現在Internet上需要傳輸的數據的邏輯視圖如下：
Figure 1. 數據實體關係圖
其中黃色的三個實體完全可以看成是一個樹狀的信息目錄，其中有三個層次的結點：Category，Product和Feedback，Category的子結點可以是Category、Product和Feedback，而Product的子節點只能是Feedback，整個目錄樹的根結點是Category。
而對於每個Product而言，都有一個數據擁有者，這個數據擁有者應當是Marketplace中的一個Retailer帳號。
另一類實體是訂單，對於一張訂單而言，將可以包含多個Product的定購記錄，以及定購對象：某個Retailer。
在系統之間交互數據是交互的第一層次：數據交換，然而對於Web服務而言，光光有數據交換是不夠的，應當提供更高層次：服務集成的支持。
因此，交互的內容不光包括互相交互的數據，同時應當包含對數據的操作(比如數據請求，數據添加，數據更新等等)。這些往往會對應與服務端的一個處理模塊。
無論是對數據的操作，還是數據本身，爲了在系統與系統之間進行交互，尤其是異構平臺之間，我們需要將所有的操作(服務調用)和操作的數據(服務調用的參數和返回值)進行規範化的描述，形成規範文檔後發佈以供所有需要參與互操作的系統共同遵守。
爲什麼選擇基於Web服務的解決方案?
我在前面已經就爲什麼電子商務需要Web服務作了初步的論述。電子商務需要擺脫獨立解決方案的實現模式，需要捨棄複雜系統連接的實現方法。一個有效的電子商務應用絕對不應該是僅僅基於程序員以及那些複雜的代碼的。對於電子商務而言，傳統的由程序員主導的由裏向外的開發模式應當被由用戶主導的由外向裏的開發模式取代。冗長的串行的開發循環應當被即時的，快速的應用裝配所取代。同時這樣的應用應當天生就具備高可定製性。如果探究其商業本質，這是來自經過時間考驗的商業技術概念："即時製造"以及"規模可伸縮"等概念，我們需要做的就是將傳統的商業概念延伸到電子商務中去。
通過使用Web服務，企業能夠以前所不可能的方式通過抽象和混合將自身的電子商務組件化。當一個企業的核心競爭力被組件化之後，那麼這些核心競爭力就能夠很方便地在不同的企業之間共享，同時架構跨企業的電子商務應用，形成商務Web。
在我們的這個計算機產品銷售網絡應用中，我們可以預見到不同的銷售商採用的系統很可能是多種多樣的，有基於Windows/IIS的Web應用，有基於Java Platform的Web應用，也有基於Windows平臺的桌面應用，也有可能是基於UNIX的ERP應用部分，要兼容那麼多種類的應用，用一般的集成技術很難滿足所有場合的需要。即使滿足了，當有其他想加入這個體系的新的Retailer出現的時候，彼此的集成代價也是無法預知的。而通過公佈預先定義好的可擴展的服務訪問規範，使得這些需要集成入體系的Retailer系統都可以以一種方便地標準的方式進入。
