架構(gòu)Web Service:實(shí)戰(zhàn)Web服務(wù)

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

架構(gòu)Web Service:實(shí)戰(zhàn)Web服務(wù)  

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

Chief System Architect

2001年8月14日

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

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

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

案例需求描述

在這里我們假設(shè)應(yīng)用背景是一個(gè)計(jì)算機(jī)產(chǎn)品銷售市場(chǎng)，其中的角色及其對(duì)應(yīng)的行為描述如下：

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

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

消費(fèi)者，計(jì)算機(jī)產(chǎn)品的購(gòu)買者(可能是個(gè)人，也可能是企業(yè))，他能夠訪問(wèn)計(jì)算機(jī)產(chǎn)品目錄，能夠利用在線的定購(gòu)服務(wù)進(jìn)行購(gòu)買。

通過(guò)對(duì)以上角色及其行為的分析，我們認(rèn)為在最終的實(shí)現(xiàn)系統(tǒng)中應(yīng)該有這樣幾種概要層次上的對(duì)象：

產(chǎn)品目錄，產(chǎn)品目錄由生產(chǎn)商/零售商產(chǎn)生，由計(jì)算機(jī)產(chǎn)品交易市場(chǎng)匯總歸類，由消費(fèi)者瀏覽使用。

訂單，訂單由消費(fèi)者生成，由計(jì)算機(jī)產(chǎn)品交易市場(chǎng)傳遞，由生產(chǎn)商/零售商接受。

反饋信息，由消費(fèi)者產(chǎn)生，由計(jì)算機(jī)產(chǎn)品交易市場(chǎng)匯總歸類，由消費(fèi)者和生產(chǎn)商/零售商使用。

用戶，用戶分兩類，一類是消費(fèi)者用戶，一類是生產(chǎn)商/零售商用戶，分別用于處理兩類事務(wù)。

應(yīng)用的系統(tǒng)架構(gòu)

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

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

大家可能會(huì)發(fā)現(xiàn)，Marketplace System和Retailer System這兩個(gè)系統(tǒng)沒(méi)什么大區(qū)別嘛? 的確是這樣，我們?cè)谠O(shè)計(jì)的時(shí)候應(yīng)當(dāng)無(wú)時(shí)無(wú)刻不能忘記"重用"這個(gè)概念，重用的組件越多，開(kāi)發(fā)的代價(jià)就越少，維護(hù)的代價(jià)也越低，可擴(kuò)展性也就越好，當(dāng)然重用不能導(dǎo)致功能的異化，這也是我們需要注意的。

下面我花一點(diǎn)篇幅稍微解析一下框架中的三個(gè)主要服務(wù)：Catalog Service、Order Service和Feedback Service。

Catalog Service

對(duì)于這個(gè)服務(wù)而言，Retailer System中的Catalog Service應(yīng)當(dāng)是Marketplace System功能的子集。Retailer System中，Catalog Service應(yīng)當(dāng)具備如下功能：

類別(Category)管理，包括增加一個(gè)Category、刪除一個(gè)Category、修改一個(gè)Category等；

產(chǎn)品(Product)管理，包括增加一個(gè)Product、刪除一個(gè)Product、修改一個(gè)Product、移動(dòng)一個(gè)Product(從一個(gè)Category下移動(dòng)到另一個(gè)Category下)等；

數(shù)據(jù)交換，包括單個(gè)類別下所有產(chǎn)品的導(dǎo)入導(dǎo)出(Import/Export)，單個(gè)產(chǎn)品數(shù)據(jù)的導(dǎo)入導(dǎo)出，整個(gè)類別樹(shù)的導(dǎo)入導(dǎo)出等；

數(shù)據(jù)備份，整個(gè)目錄下所有產(chǎn)品數(shù)據(jù)的備份/恢復(fù)等。

而Marketplace System中，需要增加一個(gè)功能：在數(shù)據(jù)交換和數(shù)據(jù)備份模塊應(yīng)當(dāng)提供對(duì)指定數(shù)據(jù)擁有者的相關(guān)數(shù)據(jù)的操作，比如導(dǎo)出某個(gè)類別下IBM的所有產(chǎn)品等等。

Order Service

對(duì)于這個(gè)服務(wù)而言，Retailer System中的Order Service和Marketplace System中的Order Service可以說(shuō)基本沒(méi)有什么本質(zhì)上的差別。他們都將具備如下功能：

接受訂單

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

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

Feedback Service

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

反饋信息(Feedback)管理，包括增加一條反饋信息、刪除一條反饋信息、修改一條反饋信息等，反饋信息可以掛在Category下，也可以掛在Product下(有針對(duì)一類產(chǎn)品的評(píng)測(cè)報(bào)告，也有針對(duì)一個(gè)產(chǎn)品的使用評(píng)價(jià)等)；

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

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

交互，交互些什么?

我們將以上功能描述加以總結(jié)，去除內(nèi)部實(shí)現(xiàn)的部分，我們可以發(fā)現(xiàn)在Internet上需要傳輸?shù)臄?shù)據(jù)的邏輯視圖如下：

Figure 2. 數(shù)據(jù)實(shí)體關(guān)系圖

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

而對(duì)于每個(gè)Product而言，都有一個(gè)數(shù)據(jù)擁有者，這個(gè)數(shù)據(jù)擁有者應(yīng)當(dāng)是Marketplace中的一個(gè)Retailer帳號(hào)。

另一類實(shí)體是訂單，對(duì)于一張訂單而言，將可以包含多個(gè)Product的定購(gòu)記錄，以及定購(gòu)對(duì)象：某個(gè)Retailer。

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

因此，交互的內(nèi)容不光包括互相交互的數(shù)據(jù)，同時(shí)應(yīng)當(dāng)包含對(duì)數(shù)據(jù)的操作(比如數(shù)據(jù)請(qǐng)求，數(shù)據(jù)添加，數(shù)據(jù)更新等等)。這些往往會(huì)對(duì)應(yīng)與服務(wù)端的一個(gè)處理模塊。

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

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

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

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

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

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

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

什么是需要公開(kāi)的?

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

Programmer's API：這是類似傳統(tǒng)含義的API定義，不過(guò)承載的介質(zhì)是SOAP Message，也就是說(shuō)Programmer's API是一組SOAP API，不同的API用于完成不同的服務(wù)調(diào)用，在這部分中需要定義不同的SOAP API的行為和實(shí)現(xiàn)的調(diào)用/響應(yīng)的功能描述；

Data Structure：這部分定義了在SOAP消息中傳輸?shù)膮?shù)/數(shù)據(jù)和響應(yīng)數(shù)據(jù)的XML模式，這部分為每個(gè)API補(bǔ)充的消息格式，同時(shí)為最終的API處理提供了數(shù)據(jù)層解析/包裝的規(guī)范。

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

參考資料

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