架構Web Service:實戰(zhàn)Web服務

申請免費試用、咨詢電話：400-8352-114

架構Web Service:實戰(zhàn)Web服務  

  
柴曉路 (fennivel@uddi-china.org)

Chief System Architect

2001年8月14日

本文是架構Web服務的系列文章的第四篇，繼探討了Web服務的商業(yè)需求，技術定義和技術規(guī)范以及現有現有的Web服務實踐之后，通過使用一個具體的案例開始對Web服務實戰(zhàn)的篇章。在本文中給出了一個實際的具有實用性并且能夠延伸出去的計算機產品交易市場的案例，通過簡要的系統(tǒng)分析、模塊劃分，對松散系統(tǒng)間待交換的數據進行了界分，同時為定義基于Web服務的API的數據結構奠定了系統(tǒng)和分析的基礎。

在先前的文章系列里面，我已經對Web服務的商業(yè)需求、Web服務的技術實現以及Web服務當前的應用以及開發(fā)工具做了全面的介紹，那么在接下來的文章中，我將結合一個實例來詳細地描述如何真正地規(guī)劃、設計和創(chuàng)建一個Web服務的具體應用。

本文所引用的資源主要包括兩類，一類是Web服務的技術資源網站，包含了大量Web服務的技術信息，另一類是Web服務“stack"系列技術規(guī)范，他們是一個整體的技術體系，包括UDDI、SOAP、WSDL、XML等。本文的最后給出了這些資源的鏈接，有興趣的讀者可以通過這些資源鏈接找到所需的內容。

案例需求描述

在這里我們假設應用背景是一個計算機產品銷售市場，其中的角色及其對應的行為描述如下：

計算機產品交易市場，該市場是聯(lián)系計算機產品生產商/零售商與消費者之間的營銷平臺。其職責和功能包括：收集并發(fā)布來自各個計算機產品生產商/零售商的產品目錄；接受消費者的購買請求并可靠地遞送給生產商/零售商系統(tǒng)完成購買事務；采集來自消費者的消費反饋，給出商品購買的導引建議，并傳送給生產商/零售商。

生產商/零售商，這是直接銷售計算機產品的商家，他能夠通過自己的Web發(fā)布產品目錄，同時也能將目錄傳送給計算機產品交易市場。他能夠接受訂單(來自自己的Web網站或者來自計算機產品交易市場)并轉入內部管理系統(tǒng)，至于資金流和物流則由離線系統(tǒng)完成。

消費者，計算機產品的購買者(可能是個人，也可能是企業(yè))，他能夠訪問計算機產品目錄，能夠利用在線的定購服務進行購買。

通過對以上角色及其行為的分析，我們認為在最終的實現系統(tǒng)中應該有這樣幾種概要層次上的對象：

產品目錄，產品目錄由生產商/零售商產生，由計算機產品交易市場匯總歸類，由消費者瀏覽使用。

訂單，訂單由消費者生成，由計算機產品交易市場傳遞，由生產商/零售商接受。

反饋信息，由消費者產生，由計算機產品交易市場匯總歸類，由消費者和生產商/零售商使用。

用戶，用戶分兩類，一類是消費者用戶，一類是生產商/零售商用戶，分別用于處理兩類事務。

應用的系統(tǒng)架構

綜合上面的分析，我們可以將整個系統(tǒng)按如下架構劃分：

Figure 1. 系統(tǒng)劃分概要

大家可能會發(fā)現，Marketplace System和Retailer System這兩個系統(tǒng)沒什么大區(qū)別嘛? 的確是這樣，我們在設計的時候應當無時無刻不能忘記"重用"這個概念，重用的組件越多，開發(fā)的代價就越少，維護的代價也越低，可擴展性也就越好，當然重用不能導致功能的異化，這也是我們需要注意的。

下面我花一點篇幅稍微解析一下框架中的三個主要服務：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可以說基本沒有什么本質上的差別。他們都將具備如下功能：

接受訂單

向其他接受訂單的服務發(fā)送訂單

兩者的區(qū)別，僅僅在于Retailer System中的Order Service接受的訂單來自用戶界面，而需要向Marketplace System中的Order Service傳送。
Marketplace System中的Order Service接受的訂單來自Retailer System中的Order Service，而需要向自己內部的企業(yè)應用傳送訂單。

Feedback Service

對于Feedback Service而言，在兩個系統(tǒng)中的地位與Catalog Service是類似的。

反饋信息(Feedback)管理，包括增加一條反饋信息、刪除一條反饋信息、修改一條反饋信息等，反饋信息可以掛在Category下，也可以掛在Product下(有針對一類產品的評測報告，也有針對一個產品的使用評價等)；

數據交換，包括與單個類別關聯(lián)或與單個產品關聯(lián)的反饋信息的導入導出(Import/Export)，以及與單個用戶(Retailer用戶，數據擁有者)相關的所有反饋信息的導入導出等；

Feedback可以看作是與整個產品目錄樹的各個結點相關聯(lián)的評論文章。不僅在Marketplace系統(tǒng)中由消費者發(fā)布并歸消費者查詢，同時也將在相關的Retailer系統(tǒng)保存并可供Retailer使用。

交互，交互些什么?

我們將以上功能描述加以總結，去除內部實現的部分，我們可以發(fā)現在Internet上需要傳輸的數據的邏輯視圖如下：

Figure 2. 數據實體關系圖

其中黃色的三個實體完全可以看成是一個樹狀的信息目錄，其中有三個層次的結點：Category，Product和Feedback，Category的子結點可以是Category、Product和Feedback，而Product的子節(jié)點只能是Feedback，整個目錄樹的根結點是Category。

而對于每個Product而言，都有一個數據擁有者，這個數據擁有者應當是Marketplace中的一個Retailer帳號。

另一類實體是訂單，對于一張訂單而言，將可以包含多個Product的定購記錄，以及定購對象：某個Retailer。

在系統(tǒng)之間交互數據是交互的第一層次：數據交換，然而對于Web服務而言，光光有數據交換是不夠的，應當提供更高層次：服務集成的支持。

因此，交互的內容不光包括互相交互的數據，同時應當包含對數據的操作(比如數據請求，數據添加，數據更新等等)。這些往往會對應與服務端的一個處理模塊。

無論是對數據的操作，還是數據本身，為了在系統(tǒng)與系統(tǒng)之間進行交互，尤其是異構平臺之間，我們需要將所有的操作(服務調用)和操作的數據(服務調用的參數和返回值)進行規(guī)范化的描述，形成規(guī)范文檔后發(fā)布以供所有需要參與互操作的系統(tǒng)共同遵守。

為什么選擇基于Web服務的解決方案?

我在前面已經就為什么電子商務需要Web服務作了初步的論述。電子商務需要擺脫獨立解決方案的實現模式，需要舍棄復雜系統(tǒng)連接的實現方法。一個有效的電子商務應用絕對不應該是僅僅基于程序員以及那些復雜的代碼的。對于電子商務而言，傳統(tǒng)的由程序員主導的由里向外的開發(fā)模式應當被由用戶主導的由外向里的開發(fā)模式取代。冗長的串行的開發(fā)循環(huán)應當被即時的，快速的應用裝配所取代。同時這樣的應用應當天生就具備高可定制性。如果探究其商業(yè)本質，這是來自經過時間考驗的商業(yè)技術概念："即時制造"以及"規(guī)?？缮炜s"等概念，我們需要做的就是將傳統(tǒng)的商業(yè)概念延伸到電子商務中去。

通過使用Web服務，企業(yè)能夠以前所不可能的方式通過抽象和混合將自身的電子商務組件化。當一個企業(yè)的核心競爭力被組件化之后，那么這些核心競爭力就能夠很方便地在不同的企業(yè)之間共享，同時架構跨企業(yè)的電子商務應用，形成商務Web。

在我們的這個計算機產品銷售網絡應用中，我們可以預見到不同的銷售商采用的系統(tǒng)很可能是多種多樣的，有基于Windows/IIS的Web應用，有基于Java Platform的Web應用，也有基于Windows平臺的桌面應用，也有可能是基于UNIX的ERP應用部分，要兼容那么多種類的應用，用一般的集成技術很難滿足所有場合的需要。即使?jié)M足了，當有其他想加入這個體系的新的Retailer出現的時候，彼此的集成代價也是無法預知的。而通過公布預先定義好的可擴展的服務訪問規(guī)范，使得這些需要集成入體系的Retailer系統(tǒng)都可以以一種方便地標準的方式進入。

大家可能會說Retailer系統(tǒng)不也是我們來開發(fā)的么？是的，一部分，甚至可能是很大一部分Retailer系統(tǒng)可能用的都是與Marketplace系統(tǒng)同構的平臺，而且只不過是服務模塊少了幾塊而已。然而，我們是處在Internet的開放互聯(lián)的時代，對于Marketplace來說，越多的Retailer的進入就代表著更多的商機，Marketplace的運營者一定會想盡辦法招攬，集成更多的Retailer系統(tǒng)，那么與其每出現一個異構的Retailer系統(tǒng)就要運用人力物力與其進行單點集成的項目開發(fā)，不如制定一種規(guī)范，使得這些新加入的Retailer能夠依照這些規(guī)范自主地加入系統(tǒng)。Marketplace同樣具備海納百川的能力，同時又不用指數倍地投入開發(fā)代價。

同時如果該規(guī)范成為一種公共接受的規(guī)范的話，其他的兼容該標準的Marketplace同樣也可以出現，而遵循該規(guī)范的Retailer系統(tǒng)則可以廣泛地以極低的代價接入到所有兼容該規(guī)范的Marketplace中去，獲得更多的銷售機會和渠道。甚至按照規(guī)范來實現，Retailer系統(tǒng)之間還能實現低代價的對等互聯(lián)?？梢哉f，依據規(guī)范的基于Web服務的服務集成是真正的按照Internet的開放互聯(lián)理念的Internet時代的服務集成的方式。

什么是需要公開的?

我們已經談到我們需要公開的是調用規(guī)范，那么調用規(guī)范該如何定義呢，如果大家在本專欄先前的關于UDDI的文章中跟隨我稍微研究了一下UDDI規(guī)范的話，那么基本可以了解對于Web服務而言(UDDI Registry就是一種標準的Web服務)，規(guī)范定義可以分為兩部分:

Programmer's API：這是類似傳統(tǒng)含義的API定義，不過承載的介質是SOAP Message，也就是說Programmer's API是一組SOAP API，不同的API用于完成不同的服務調用，在這部分中需要定義不同的SOAP API的行為和實現的調用/響應的功能描述；

Data Structure：這部分定義了在SOAP消息中傳輸的參數/數據和響應數據的XML模式，這部分為每個API補充的消息格式，同時為最終的API處理提供了數據層解析/包裝的規(guī)范。

在后面的文章中，我將就本文關注的這個Demo Case，一步一步地講述如何定義Programmer's API和Data Structure。

參考資料

 柴曉路: 上海得易電子商務技術有限公司(DealEasy)首席系統(tǒng)架構師、XML技術顧問。UDDI-China.org藍色火焰工作室(Blue Blaze Studio)成員。UDDI Advisor Group成員，WSUI Working Group成員。2000年獲復旦大學計算機科學碩士學位，曾在國際計算機科學學術會議(ICSC)、亞太區(qū)XML技術研討會(XML Asia/Pacific'99)、中國XML技術研討會(北京)、計算機科學期刊等各類國際、國內重要會議與期刊上發(fā)表論文多篇。專長于基于XML的系統(tǒng)集成和數據交換的技術研究，同時對數據庫、面向對象技術及CSCW等技術比較擅長。