Web Service Case Study:軟件反饋跟蹤平臺(tái)

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

Web Service Case Study:軟件反饋跟蹤平臺(tái)  

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

Chief System Architect

2002年3月26日

在我以前的developerWorks的專欄文章中，我已經(jīng)系統(tǒng)地介紹了各種Web服務(wù)技術(shù)標(biāo)準(zhǔn)及其細(xì)節(jié)，然而Web服務(wù)并不僅僅是一種技術(shù)，更是一種應(yīng)用框架，一種系統(tǒng)架構(gòu)的方式，和一種應(yīng)用的思想。所以從本次開始的 "Web Service Case Study" 文章系列中，我將在每一篇文章中使用一個(gè)具體的應(yīng)用實(shí)例，通過(guò)應(yīng)用分析來(lái)詳細(xì)闡述使用Web服務(wù)技術(shù)的好處和優(yōu)越性，同時(shí)從Web服務(wù)的角度結(jié)合實(shí)例介紹各種Web服務(wù)技術(shù)在具體的項(xiàng)目中應(yīng)該如何被使用。

本文是先前文章的一個(gè)延伸，通過(guò)一個(gè)軟件反饋跟蹤平臺(tái)來(lái)考察如何具體設(shè)計(jì)一個(gè)Web服務(wù)應(yīng)用，如何評(píng)估Web服務(wù)解決方案的適用性等。我將陸續(xù)推出這個(gè)文章系列，希望大家通過(guò)這個(gè)系列的文章，能夠從實(shí)踐中掌握Web服務(wù)構(gòu)架。

案例背景簡(jiǎn)介 - 軟件反饋跟蹤平臺(tái)

在本系列的第一篇文章中，我們將從軟件行業(yè)自身的應(yīng)用開始。我們知道，對(duì)于一個(gè)軟件企業(yè)而言，不論是提供軟件產(chǎn)品、還是提供軟件解決方案，或是承接軟件項(xiàng)目，對(duì)于用戶反饋的獲取都是非常重要的，這不僅是優(yōu)質(zhì)服務(wù)的必要保證，同時(shí)也是軟件產(chǎn)品、解決方案升級(jí)換代的重要依據(jù)。

在這樣的應(yīng)用背景下，用戶反饋不僅僅包括用戶對(duì)產(chǎn)品的意見，同時(shí)也包含軟件產(chǎn)品的BUG自動(dòng)報(bào)告，以及一些性能參數(shù)的采集等。當(dāng)然其中的有些是需要客戶授權(quán)方可進(jìn)行的，比如性能參數(shù)收集等。

首先，我們先來(lái)分析一下在這個(gè)應(yīng)用背景下的角色及其對(duì)應(yīng)的行為描述如下：

軟件公司：軟件公司是生產(chǎn)軟件、提供軟件產(chǎn)品的企業(yè)。它對(duì)自己的軟件產(chǎn)品的質(zhì)量負(fù)有責(zé)任，對(duì)客戶需要提供技術(shù)支持，同時(shí)在獲取足夠的反饋的前提下，需要即時(shí)地對(duì)自己的軟件產(chǎn)品進(jìn)行升級(jí)，或者開發(fā)新的軟件產(chǎn)品，因此它需要即時(shí)地獲取有關(guān)其提供的軟件產(chǎn)品的各種反饋信息。

客戶：使用、消費(fèi)軟件產(chǎn)品的商業(yè)實(shí)體或個(gè)人。為了更好地接收軟件公司的服務(wù)，它需要提供必要的和充分的軟件使用反饋，反饋包括由客戶的技術(shù)人員以描述方式提供，或通過(guò)軟件產(chǎn)品的某種日志接口導(dǎo)出文件并提供給軟件公司。

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

反饋信息分類目錄，反饋信息分類目錄由軟件公司維護(hù)，所有的反饋信息都位于反饋信息分類目錄的不同結(jié)點(diǎn)下分類組織。

反饋信息，由客戶或運(yùn)行中的軟件產(chǎn)品產(chǎn)生，經(jīng)過(guò)反饋信息分類目錄歸類組織，由軟件公司使用。

用戶，用戶分兩類，一類是客戶用戶(包括客戶消費(fèi)的軟件產(chǎn)品中可能用到的用戶)，一類是軟件公司用戶，分別用于處理兩類事務(wù)：軟件公司用戶的目錄管理/信息查詢，以及客戶用戶的信息提交。

系統(tǒng)構(gòu)架概述

Figure 1. 系統(tǒng)結(jié)構(gòu)概述

應(yīng)該說(shuō)，這個(gè)系統(tǒng)還是比較簡(jiǎn)單的。其中，Catalog Service管理所有各種類型的反饋信息，Authentication Service負(fù)責(zé)用戶登錄和權(quán)限認(rèn)證。Catalog Service和Authentication Service組成了服務(wù)平臺(tái)。這個(gè)服務(wù)平臺(tái)有兩個(gè)標(biāo)準(zhǔn)客戶端：User Client Module是為使用軟件的客戶所準(zhǔn)備的，主要是提交反饋信息用途，而Administrator Client Module則是軟件公司的管理模塊，功能包括管理配置反饋信息目錄(Catalog)，查詢?yōu)g覽反饋信息目錄以及進(jìn)行用戶管理。

下面我花一點(diǎn)篇幅稍詳細(xì)解析一下框架中的兩個(gè)個(gè)主要服務(wù)：Catalog Service和Authentication Service。

Catalog Service

根據(jù)前面的應(yīng)用背景描述，Catalog Service應(yīng)當(dāng)具備如下功能：

類別(Category)管理，包括增加一個(gè)Category、刪除一個(gè)Category、修改一個(gè)Category等；其中Category不光用于表示軟件產(chǎn)品的分類，同時(shí)軟件產(chǎn)品也將以葉子類別結(jié)點(diǎn)的形式出現(xiàn)。

反饋數(shù)據(jù)管理，包括增加一則反饋數(shù)據(jù)、刪除一個(gè)反饋數(shù)據(jù)、修改一個(gè)反饋數(shù)據(jù)、移動(dòng)一個(gè)反饋數(shù)據(jù)(從一個(gè)Category下移動(dòng)到另一個(gè)Category下)等；

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

數(shù)據(jù)備份，整個(gè)目錄下所有反饋數(shù)據(jù)的備份/恢復(fù)等。

Authentication Service

而Authentication Service則相對(duì)簡(jiǎn)單，它的功能可描述如下：

用戶登錄/注銷，完成用戶登錄服務(wù)和從服務(wù)注銷的功能，這個(gè)功能是由用戶使用的(包括管理員用戶和一般用戶)。

權(quán)限審核，用戶權(quán)限審核，為除Authentication Service之外的服務(wù)提供權(quán)限審核功能。

系統(tǒng)間的交互

我們將以上功能各個(gè)模塊的功能描述加以總結(jié)，去除內(nèi)部實(shí)現(xiàn)的部分，我們可以發(fā)現(xiàn)在Internet上需要傳輸?shù)臄?shù)據(jù)也就是兩類：目錄和反饋數(shù)據(jù)。

目錄由多個(gè)目錄結(jié)點(diǎn)組成，目錄包含一個(gè)根結(jié)點(diǎn)，每個(gè)目錄結(jié)點(diǎn)(除根結(jié)點(diǎn)以外)有一個(gè)父目錄結(jié)點(diǎn)，一個(gè)目錄結(jié)點(diǎn)可以包含多個(gè)子結(jié)點(diǎn)。一般而言目錄的葉子結(jié)點(diǎn)是某個(gè)軟件產(chǎn)品，而中間結(jié)點(diǎn)則是表示軟件產(chǎn)品的分類。

反饋數(shù)據(jù)總是從屬于一個(gè)目錄結(jié)點(diǎn)，一般來(lái)說(shuō)主要的反饋數(shù)據(jù)，包括BUG報(bào)告，性能數(shù)據(jù)以及描述性反饋都是屬于葉子結(jié)點(diǎn)，也就是軟件產(chǎn)品的，不過(guò)在非葉子結(jié)點(diǎn)下也會(huì)包含一些描述性反饋數(shù)據(jù)。

自具體定義中，我們需要先定義一個(gè)抽象反饋信息類，然后以這個(gè)類為基類，派生出BUG報(bào)告反饋類、性能數(shù)據(jù)反饋類以及描述性反饋類等。

總之，在我們這個(gè)應(yīng)用環(huán)境下，有兩種數(shù)據(jù)是我們要主要關(guān)心的：目錄和反饋數(shù)據(jù)。

在系統(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ù)解決方案?

我們知道，對(duì)于一個(gè)軟件產(chǎn)品的信息采集系統(tǒng)而言，以下兩個(gè)特性是不可缺少的：

使用的方便性，我們知道在軟件產(chǎn)品中的反饋數(shù)據(jù)采集模塊，尤其是那些Bug報(bào)告模塊或者是性能數(shù)據(jù)收集模塊，需要嵌入在軟件產(chǎn)品的代碼中的，在嵌入的時(shí)候應(yīng)當(dāng)盡可能地簡(jiǎn)單和統(tǒng)一，這樣才能保障軟件產(chǎn)品的代碼的可維護(hù)性。

客戶端模塊的跨平臺(tái)性，對(duì)于一個(gè)公司而言，它的軟件產(chǎn)品可能是會(huì)跨越多個(gè)平臺(tái)的，同時(shí)開發(fā)環(huán)境也不盡相同，如何能讓客戶端在各種平臺(tái)下的軟件產(chǎn)品中被嵌入，是一個(gè)非常重要的問(wèn)題。同時(shí)，跨平臺(tái)性這個(gè)特性還能使得這個(gè)平臺(tái)能夠拓展到ASP(Application Service Provider)的模式下，為多個(gè)軟件企業(yè)服務(wù)，從而成為公共的網(wǎng)絡(luò)服務(wù)平臺(tái)。

基于XML技術(shù)的Web服務(wù)正是解決這一問(wèn)題的最佳手段。Web服務(wù)的使用將改變目前的開發(fā)模式和應(yīng)用部署的費(fèi)用規(guī)模。各種Web服務(wù)分別實(shí)現(xiàn)了一定的模塊功能，通過(guò)將各種提供不同功能的Web服務(wù)進(jìn)行組合和集成以創(chuàng)建動(dòng)態(tài)應(yīng)用。Web服務(wù)能夠統(tǒng)一地封裝信息、行為、數(shù)據(jù)表現(xiàn)以及商務(wù)流程，而無(wú)需考慮應(yīng)用所在的環(huán)境是使用何種系統(tǒng)和設(shè)備。

從外部的使用者的角度而言，Web服務(wù)是一種部署在Web上的對(duì)象/組件，它具備以下特征：

完好的封裝性，Web服務(wù)既然是一種部署在Web上的對(duì)象，自然具備對(duì)象的良好封裝性，對(duì)于使用者而言，他能且僅能看到該對(duì)象提供的功能列表。

松散耦合，這一特征也是源于對(duì)象/組件技術(shù)，當(dāng)一個(gè)Web服務(wù)的實(shí)現(xiàn)發(fā)生變更的時(shí)候，調(diào)用者是不會(huì)感到這一點(diǎn)的，對(duì)于調(diào)用者來(lái)說(shuō)，只要Web服務(wù)的調(diào)用界面不變，Web服務(wù)的實(shí)現(xiàn)任何變更對(duì)他們來(lái)說(shuō)都是透明的，甚至是當(dāng)Web服務(wù)的實(shí)現(xiàn)平臺(tái)從J2EE遷移到了.NET或者是相反的遷移流程，用戶都可以對(duì)此一無(wú)所知。

使用協(xié)約的規(guī)范性，這一特征從對(duì)象而來(lái)，但相比一般對(duì)象其界面規(guī)范更加規(guī)范化和易于機(jī)器理解。首先，作為Web服務(wù)，對(duì)象界面所提供的功能應(yīng)當(dāng)使用標(biāo)準(zhǔn)的描述語(yǔ)言來(lái)描述(比如WSDL)；其次，由標(biāo)準(zhǔn)描述語(yǔ)言描述的服務(wù)界面應(yīng)當(dāng)是能夠被發(fā)現(xiàn)的，因此這一描述文檔需要被存儲(chǔ)在私有的或公共的注冊(cè)庫(kù)里面。同時(shí)，使用標(biāo)準(zhǔn)描述語(yǔ)言描述的使用協(xié)約將不僅僅是服務(wù)界面，它將被延伸到Web服務(wù)的聚合、跨Web服務(wù)的事務(wù)、工作流等，而這些又都需要服務(wù)質(zhì)量(QoS)的保障。其次，我們知道安全機(jī)制對(duì)于松散耦合的對(duì)象環(huán)境的重要性，因此我們需要對(duì)諸如授權(quán)認(rèn)證、數(shù)據(jù)完整性(比如簽名機(jī)制)、消息源認(rèn)證以及事務(wù)的不可否認(rèn)性等運(yùn)用規(guī)范的方法來(lái)描述、傳輸和交換。最后，在所有層次的處理都應(yīng)當(dāng)是可管理的，因此需要對(duì)管理協(xié)約運(yùn)用同樣的機(jī)制。

使用標(biāo)準(zhǔn)協(xié)議規(guī)范，作為Web服務(wù)，其所有公共的協(xié)約完全需要使用開放的標(biāo)準(zhǔn)協(xié)議進(jìn)行描述、傳輸和交換。這些標(biāo)準(zhǔn)協(xié)議具有完全免費(fèi)的規(guī)范，以便由任意方進(jìn)行實(shí)現(xiàn)。一般而言，絕大多數(shù)規(guī)范將最終有W3C或OASIS作為最終版本的發(fā)布方和維護(hù)方。

高度可集成能力，由于Web服務(wù)采取簡(jiǎn)單的、易理解的標(biāo)準(zhǔn)Web協(xié)議作為組件界面描述和協(xié)同描述規(guī)范，完全屏蔽了不同軟件平臺(tái)的差異，無(wú)論是CORBA、DCOM還是EJB都可以通過(guò)這一種標(biāo)準(zhǔn)的協(xié)議進(jìn)行互操作，實(shí)現(xiàn)了在當(dāng)前環(huán)境下最高的可集成性。

Web服務(wù)的這些特點(diǎn)的的確確能夠滿足我們的這個(gè)反饋數(shù)據(jù)收集平臺(tái)的需求，并且為這個(gè)反饋數(shù)據(jù)收集平臺(tái)賦予了功能延伸和規(guī)模延伸的可能。

交互界面設(shè)計(jì)

之前，我們已經(jīng)談到了需要為我們自己開發(fā)的Web服務(wù)制訂調(diào)用規(guī)范，那么調(diào)用規(guī)范該如何定義呢，從總體上來(lái)說(shuō)，規(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 Schema，這部分為每個(gè)API補(bǔ)充的消息格式，同時(shí)為最終的API處理提供了數(shù)據(jù)層解析/包裝的規(guī)范。

API設(shè)計(jì)原則

簡(jiǎn)單性，由于這是一個(gè)對(duì)于公共開放的Web服務(wù)，它的API的設(shè)計(jì)首先應(yīng)當(dāng)是簡(jiǎn)單的，要被大量用戶接受，要獲得比較好的應(yīng)用，那么API必須簡(jiǎn)單，沒(méi)有哪個(gè)復(fù)雜難用的API會(huì)得到大家的廣泛接受的。

可擴(kuò)展性，作為更新頻率較高，開放性較強(qiáng)的Web服務(wù)，其API應(yīng)當(dāng)具有很好的向后擴(kuò)展性，當(dāng)應(yīng)內(nèi)部需求的改變或外部需求的改變的需要時(shí)，API將根據(jù)新的邏輯發(fā)生變化，此時(shí)不應(yīng)當(dāng)將API從根本上推翻重建，而應(yīng)當(dāng)具備增量式的可擴(kuò)展的能力。

高效性，API應(yīng)該在堅(jiān)持簡(jiǎn)單性的前提下，兼顧高效性，當(dāng)某些組合操作應(yīng)用地非常頻繁的時(shí)候，我們應(yīng)當(dāng)為這樣的組合操作調(diào)用設(shè)計(jì)一個(gè)只需一次交互的單一入口調(diào)用，這樣能夠提升外部應(yīng)用的效率，同時(shí)減輕Web服務(wù)的負(fù)載。

完備性，所謂完備性就是說(shuō)整個(gè)API要覆蓋所有需要對(duì)外公開的功能，這相對(duì)而言是最好實(shí)現(xiàn)的目標(biāo)，只要設(shè)計(jì)階段考慮得完備，就能達(dá)到完備性的要求。而且萬(wàn)一發(fā)現(xiàn)不完備的情況，修正起來(lái)也是相對(duì)容易的。

Data Structure設(shè)計(jì)

本系統(tǒng)的數(shù)據(jù)主要有兩類：目錄和反饋數(shù)據(jù)。首先，我們先來(lái)給出相對(duì)簡(jiǎn)單的目錄XML數(shù)據(jù)結(jié)構(gòu)定義。

Category的具體描述格式：

<category categoryKey="…" parentCategoryKey="…">
  <name>……</name>
  <description>……</description>
  <category categoryKey="…" parentCategoryKey="…"> *
</category>

這是一個(gè)縮略版的目錄數(shù)據(jù)格式定義，我們可以看到一個(gè)category可以包括0個(gè)或多個(gè)category，同時(shí)每個(gè)category具有兩個(gè)子元素name和description分別描述這個(gè)類別結(jié)點(diǎn)的名稱和描述，category還包含兩個(gè)屬性：categoryKey和parentCategoryKey，分別表示一個(gè)類別結(jié)點(diǎn)的UUID(唯一標(biāo)識(shí)符)及其父類別結(jié)點(diǎn)的UUID。由一個(gè)根類別結(jié)點(diǎn)開始及其包含的所有子孫類別結(jié)點(diǎn)一起組成了我們的目錄數(shù)據(jù)。

在給出了目錄的數(shù)據(jù)之后，我們?cè)賮?lái)定義反饋數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)：

<feedback feedbackKey="…" parentCategoryKey="…" type="…">
  <name>……</name>
  <description>……</description>
  <dataBag>
    <field name="[fieldname]">……</field> *
  </dataBag>
</feedback>

其中，feedback元素的屬性feedbackKey和parentCategoryKey分別表示當(dāng)前feedback元素的UUID以及其所在類別結(jié)點(diǎn)的UUID。Name和description子元素與前面的含義是類似的。下面我們來(lái)介紹一下dataBag這個(gè)子元素，這是一個(gè)字段值的聚集，一個(gè)dataBag可以包含0個(gè)或多個(gè)字段。每個(gè)字段都是以<field name="……">……</field>的形式出現(xiàn)的，

可以想象，采用了諸如dataBag這樣的數(shù)據(jù)聚集的描述方式，將使得這個(gè)系統(tǒng)的適用性非常強(qiáng)，可以適應(yīng)大多數(shù)用戶的特殊需求，用戶可以在其中自由地定義字段并為字段賦上相關(guān)的字段值。對(duì)于系統(tǒng)的適應(yīng)性和可擴(kuò)展性，這樣的數(shù)據(jù)描述方式是非常有效的，然而如此自由的描述方式，對(duì)于系統(tǒng)平臺(tái)去檢驗(yàn)這些字段的合法性(比如字段名有沒(méi)有寫錯(cuò)，字段值的類型是否正確等)卻是非常不利的。

鑒于合法性校驗(yàn)的考慮，我們認(rèn)為，可以引入dataBag Template的概念，所謂dataBag Template就是一種預(yù)先定義好的在某個(gè)特定領(lǐng)域應(yīng)用中使用的反饋信息數(shù)據(jù)的模版，這個(gè)模版定義了所有合法的字段，包括字段名稱及其字段值類型。下面我們給出一個(gè)dataBag Template的例子：

<dataBagTemplate templateKey="…">
  <field name="Applicationo" type="xs:string" />
  <field name="Module" type="xs:string" />
  <field name="Exception" type="xs:integer" />
  <field name="Description" type="xs:string" />
</dataBagTemplate>

這個(gè)dataBag Template定義了三個(gè)字段，Application(應(yīng)用名稱)、Module(模塊名稱)、Exception(異常編號(hào)，注意這是整型字段)以及Description(錯(cuò)誤描述)，這個(gè)Template用于定義一般的錯(cuò)誤報(bào)告的模版結(jié)構(gòu)。

由于使用了dataBag Template，我們需要更新反饋數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)：

<feedback feedbackKey="…" parentCategoryKey="…" type="…">
  <name>……</name>
  <description>……</description>
  <dataBag templateKey="……">
    <field name="[fieldname]">……</field> *
  </dataBag>
</feedback>

如此，系統(tǒng)平臺(tái)就可以利用templateKey找到相應(yīng)的dataBag Template，從而進(jìn)行數(shù)據(jù)校驗(yàn)。需要注意的是，databag Template并不在系統(tǒng)的一般交互中被傳輸，它是作為系統(tǒng)的插件安裝在平臺(tái)系統(tǒng)或者客戶端中的，也就是說(shuō)，當(dāng)平臺(tái)系統(tǒng)接收到反饋數(shù)據(jù)XML文檔后，從這個(gè)文檔中獲得templateKey，然后通過(guò)templateKey在系統(tǒng)中查找，看看這個(gè)對(duì)應(yīng)的dataBag Template是否已經(jīng)被安裝(導(dǎo)入)進(jìn)平臺(tái)，如果已經(jīng)安裝了，那么就按照這個(gè)Template來(lái)校驗(yàn)合法性，如果尚則安裝，則可以選擇報(bào)錯(cuò)，或忽略合法性校驗(yàn)。

Catalog Service API設(shè)計(jì)

Catalog Service的API設(shè)計(jì)如下：

save_category: 保存category，在這個(gè)API調(diào)用中，包含了更新和新建的操作，同時(shí)category的遷移也可以通過(guò)這個(gè)API來(lái)完成。

delete_category: 刪除category，將指定category及其全部子元素從Catalog中刪除。

find_category: 在catalog中定位尋找category，可以通過(guò)多種方式，比如名稱，鍵值等。

save_feedback: 保存product，在這個(gè)API調(diào)用中，同樣可以包含更新、新建和遷移的操作。

delete_feedback: 刪除product，將指定product的信息從Catalog中刪除。

find_feedback: 在catalog中定位尋找product，可以通過(guò)多種方式，比如名稱，比如所在的category，比如使用的template等等。

get_categoryDetail: 獲取category的完整信息，包括包含的所有category的簡(jiǎn)要信息和feedback的詳細(xì)信息。

get_productDetail: 獲取feedback的完整信息。

get_categoryInfo: 獲取category及其所有子孫category和feedback的所有信息。

如果我們把用戶分為軟件產(chǎn)品生產(chǎn)者用戶和軟件產(chǎn)品使用(消費(fèi))者用戶的話，那么功能基本上可以被分為兩類。軟件產(chǎn)品使用者僅能使用find_category和save_feedback，而軟件產(chǎn)品生產(chǎn)者則可使用所有功能。如果平臺(tái)提供商與軟件產(chǎn)品生產(chǎn)者并非同一家的話，那么軟件產(chǎn)品生產(chǎn)者將不能使用delete_category和save_category消息API。

由于我們先前已經(jīng)確定了category和feedback這兩個(gè)實(shí)體的數(shù)據(jù)結(jié)構(gòu)的XML描述格式，那么下面我們就可以來(lái)定義API消息了。在這里，我們僅僅定義一個(gè)消息save_feedback，其他的消息則可以類似推得。

save_feedback

用于提交反饋數(shù)據(jù)，使用這個(gè)API調(diào)用，可以完成對(duì)反饋數(shù)據(jù)的更新、新建和遷移的操作。一般來(lái)說(shuō)對(duì)于普通用戶，僅僅可以新建反饋數(shù)據(jù)(提交新的反饋數(shù)據(jù))，而不能進(jìn)行更新和遷移等操作。

<save_feedback>
  <authInfo>……</authInfo>
  <feedback feedbackKey="…" parentCategoryKey="…" type="…"> *
    <name>……</name>
    <description>……</description>
    <dataBag templateKey="……">
      <field name="[fieldname]">……</field> *
    </dataBag>
  </feedback>
</save_category>

在上述的語(yǔ)法描述中，大家應(yīng)該可以發(fā)現(xiàn)，save_feedback能夠用于保存一個(gè)或多個(gè)feedback反饋數(shù)據(jù)，這樣的設(shè)計(jì)是為了達(dá)到高效性的設(shè)計(jì)目標(biāo)。

當(dāng)整個(gè)消息中的任意一個(gè)feedback所屬的表示自身實(shí)體的鍵值feedbackKey為空，即表示這是一個(gè)新增的feedback，需要被插入到數(shù)據(jù)庫(kù)中，在返回消息中，將回送這些元素的鍵值。

當(dāng)消息中任意一個(gè)feedback的parentCategoryKey沒(méi)有發(fā)生更改時(shí)，表明是要更新該元素的信息。而若parentCategoryKey發(fā)生更改的時(shí)候，表明該元素將從之前的由原有parentCategoryKey所標(biāo)識(shí)的category結(jié)點(diǎn)下被遷移到由新的parentCategoryKey所標(biāo)識(shí)的category結(jié)點(diǎn)下。當(dāng)然如果包含了數(shù)據(jù)更新操作，同樣會(huì)實(shí)施該數(shù)據(jù)更新操作。

細(xì)心的讀者一定已經(jīng)發(fā)現(xiàn)了在這個(gè)消息中，有一個(gè)authInfo元素，這是一個(gè)用于權(quán)限檢驗(yàn)的授權(quán)令牌。用戶通過(guò)向Authentication Service登錄而獲得這個(gè)令牌，當(dāng)Catalog Service得到這個(gè)令牌后，則是向Authentication Service詢問(wèn)令牌的合法性，如果合法方能執(zhí)行相應(yīng)的消息，用戶在交互完畢之后，應(yīng)向Authentication Service注銷令牌。

save_feedback消息調(diào)用的返回是一個(gè)或多個(gè)完整的被接受的feedback信息，與提交的信息的差別就是僅有概要信息，沒(méi)有詳細(xì)信息，同時(shí)原先空著的鍵值都被填上Web服務(wù)所指派的鍵值。下面是一個(gè)返回消息的例子：

<result>
  <feedback feedbackKey="f02" parentCategoryKey="a01" />
  <feedback feedbackKey="f03" parentCategoryKey="a01" />
  <feedback feedbackKey="f04" parentCategoryKey="a01" />
</result>

Web服務(wù)實(shí)現(xiàn)

在本文的前面的內(nèi)容中，我們已經(jīng)設(shè)計(jì)了這個(gè)軟件反饋跟蹤平臺(tái)的實(shí)現(xiàn)方案，并著重地討論了服務(wù)組件的Web服務(wù)界面，下面我將依靠一些實(shí)踐來(lái)進(jìn)一步介紹Web服務(wù)技術(shù)系列中的XML Schema、SOAP、WSDL、UDDI等在服務(wù)實(shí)現(xiàn)的過(guò)程中是如何被一一使用的。

在這部分中，我將把save_feedback這個(gè)SOAP API拿出來(lái)，看看在具體的實(shí)現(xiàn)上，應(yīng)當(dāng)如何對(duì)這個(gè)消息使用W3C XML Schema進(jìn)行建模，在具體的服務(wù)交互中，SOAP消息的格式是如何的，如果使用WSDL將基于該消息調(diào)用的Web服務(wù)進(jìn)行規(guī)范描述并交付調(diào)用者，以及如何將這個(gè)Web服務(wù)連同它的WSDL規(guī)范化描述文件一起發(fā)布到UDDI注冊(cè)中心中去。

XML Schema數(shù)據(jù)建模

一個(gè)XML Schema文檔中的定義通常分為兩部分，型(Type)定義和元素(Element)定義。下面我們結(jié)合save_feedback具體的XML Schema定義來(lái)說(shuō)明如何使用XML Schema來(lái)進(jìn)行模式定義。

save_feedback的XML Schema描述定義：

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="save_feedback" type="save_feedback">
    <xs:annotation>
      <xs:documentation>save_feedback API Schema Definition</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="save_feedback">
    <xs:sequence>
      <xs:element name="authInfo" type="xs:base64Binary"/>
      <xs:element name="feedback" type="feedbackType"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="feedbackType">
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="description" type="xs:string"/>
      <xs:element name="databag" type="dataBagType"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="dataBagType">
    <xs:sequence>
      <xs:element name="field" type="xs:anyType" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

在這個(gè)模式文檔中，以此非別定義了save_feedback元素、save_feedback類型、feedbackType類型和dataBagType類型。其中，save_feedback元素的類型是save_feedback類型，而在save_feedback類型定義中引用了feedbackType類型定義，同時(shí)feedbackType類型定義中使用了dataBagType類型定義。

SOAP消息示例

有了XML Schema之后，我們就可以參照XML Schema在Web服務(wù)實(shí)現(xiàn)時(shí)使用SOAP進(jìn)行互相通信了。以下是一個(gè)save_feedback的調(diào)用例子，在例子中使用了SOAP HTTP Binding(使用的SOAP規(guī)范的版本是1.2)，假設(shè)目標(biāo)Web服務(wù)被部署在假象的www.sagitta.com，而調(diào)用的Web服務(wù)的入口位置將是http://www.sagitta.com/feedback/。

在這個(gè)消息中，將在一個(gè)現(xiàn)有的category中添加一個(gè)新的feedback。

POST /catalog HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://www.sagitta.com/feedback/"
Host: www.sagitta.com

<?xml version="1.0" encoding="UTF-8" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
  <env:Body>
    <save_feedback xmlns="http://www.sagitta.com/schema/">
      <authInfo>5Az784kJceHCE982eB</authInfo>
      <feedback feedbackKey="" parentCategoryKey="……">
        <name>Bug Report</name>
        <description>……</description>
        <dataBag templateKey="……">
          <field name="Application"> Agility Business Platform</field>
          …………
        </dataBag>
      </feedback>
    </save_feedback>
  </env:Body>
</env:Envelope>

從中我們可以看到在save_feedback元素后面帶了一個(gè)xmlns的修飾"http://www.sagitta.com/schema/"。這個(gè)URI唯一表示了該元素及其所有子元素的的命名空間。同時(shí)通過(guò)這個(gè)URL可以獲得這些元素的Schema定義。

使用W3C XML Schema描述的XML文檔的模式定義在整個(gè)Web服務(wù)的技術(shù)系列中處于一個(gè)支持工具的地位。W3C XML Schema是任何類型的XML文檔的建模工具。在Web服務(wù)體系中，無(wú)論在SOAP消息的表示上，還是在WSDL的界面描述上，XML Schema都是不可缺少的重要工具和底層支持。

WSDL服務(wù)描述

對(duì)SOAP API消息完成Schema建模之后，一方面這個(gè)數(shù)據(jù)模型可以由SOAP Interface來(lái)使用，當(dāng)發(fā)生具體調(diào)用時(shí)可以使用這個(gè)數(shù)據(jù)模型來(lái)處理傳入的參數(shù)并生成傳出的參數(shù)。同時(shí)，利用這個(gè)數(shù)據(jù)模型，我們可以生成相應(yīng)的WSDL描述，從而將這個(gè)Web服務(wù)的接口文檔發(fā)布給使用者，該接口文檔是具備被程序自動(dòng)處理的能力的。

一般來(lái)說(shuō)，有了XML Schema，WSDL文檔的生成是非常方便的，我們?cè)诟鱾€(gè)平臺(tái)上都有豐富的工具可以使用，這里就不給出具體的WSDL文檔了。

UDDI服務(wù)發(fā)布

由于我們?cè)谠O(shè)計(jì)這個(gè)軟件反饋跟蹤平臺(tái)的一開始，就致力于將它往公共平臺(tái)或者是可重用平臺(tái)的方向發(fā)展，為了使更多的潛在用戶能夠發(fā)現(xiàn)這個(gè)Web服務(wù)，同時(shí)也為了加強(qiáng)這個(gè)Web服務(wù)的互操作能力和災(zāi)難恢復(fù)時(shí)的連接保持能力，我們需要使用UDDI SDK將這個(gè)Web服務(wù)注冊(cè)到UDDI注冊(cè)中心中去。

我們之前已經(jīng)注冊(cè)了一個(gè)businessEntity，叫做www.sagitta.com，一個(gè)在線服務(wù)提供商，這個(gè)businessEntity的鍵值是"434554F4-6E17-1342-EA41-36E642531DA1"，那么我們要在這個(gè)businessEntity下注冊(cè)一個(gè)businessService，以用于描述我們的這個(gè)Feedback Service。同時(shí)我們也預(yù)先注冊(cè)了一個(gè)Service Type(tModel)，這個(gè)tModel描述了我們這個(gè)需要發(fā)布的Web服務(wù)的調(diào)用規(guī)范，具體內(nèi)容是我們先前已經(jīng)生成的WSDL文檔，在UDDI中，注冊(cè)的是這個(gè)描述文檔的鏈接URL。

businessService注冊(cè)的SOAP消息如下，其中使用了Microsoft的test.uddi.microsoft.com站點(diǎn)，因此authInfo中可以填入測(cè)試用的"udditest"。

<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Body>
    <save_service generic="1.0" xmlns="urn:uddi-org:api">
      <authInfo>udditest</authInfo>
      <businessService businessKey="434554F4-6E17-1342-EA41-36E642531DA1" serviceKey="">
        <name>feedbackService</name>
        <description xml:lang="en">Online Web Service for Feedback</description>
        <bindingTemplates>
          <bindingTemplate bindingKey="" serviceKey="">
            <description xml:lang="en">feedbackService's BindingTemplate</description>
            <accessPoint URLType="http">http://www.sagitta.com/feedback/</accessPoint>
            <tModelInstanceDetails>
              <tModelInstanceInfo tModelKey="uuid:231A569A-EEFF-4448-BA4D-2B222FE4ACEF">
              ……
              </tModelInstanceInfo>
            </tModelInstanceDetails>
          </bindingTemplate>
        </bindingTemplates>
      </businessService>
    </save_service>
  </Body>
</Envelope>

通過(guò)上述的API調(diào)用，我們就已經(jīng)把這個(gè)服務(wù)注冊(cè)進(jìn)了UDDI注冊(cè)中心，其中bindingTemplate的accessPoint是服務(wù)的入口。

潛在的使用者可以通過(guò)查詢UDDI注冊(cè)中心找到這個(gè)Web服務(wù)，通過(guò)overviewURL中保存的URL找到服務(wù)的描述，然后通過(guò)accessPoint所指定的訪問(wèn)地址來(lái)訪問(wèn)這個(gè)服務(wù)。

當(dāng)發(fā)生緊急服務(wù)崩潰的時(shí)候，Web服務(wù)可能被遷移到另一臺(tái)主機(jī)上，IP地址，甚至是訪問(wèn)的URL都可能有很大變化，此時(shí)原先的集成的連接將不再工作。但是由于UDDI注冊(cè)的存在，我們可以通過(guò)自動(dòng)化的程序手段來(lái)解決這個(gè)問(wèn)題，使得類似的服務(wù)災(zāi)難恢復(fù)的過(guò)程非常迅速。

具體的流程一般是：

當(dāng)恢復(fù)的服務(wù)啟動(dòng)后，自動(dòng)去更新UDDI注冊(cè)中心上的數(shù)據(jù)，將訪問(wèn)入口修改到新的URL位置;

連入的客戶端系統(tǒng)當(dāng)發(fā)現(xiàn)無(wú)法訪問(wèn)最終服務(wù)的時(shí)候，將會(huì)定期去查詢UDDI注冊(cè)中心，看看新的BindingTemplate數(shù)據(jù)和本地緩存的有沒(méi)有差別，如果有的話，就下載到本地，重新建立服務(wù)綁定，完成服務(wù)連接的遷移。

遺留的問(wèn)題

這里給出了軟件反饋跟蹤平臺(tái)的簡(jiǎn)要設(shè)計(jì)，而關(guān)于一些更深入的功能和實(shí)現(xiàn)上的一些考慮，我想就留給廣大讀者，下面，我謹(jǐn)提出兩個(gè)可能的問(wèn)題：

在dataBag Template的設(shè)計(jì)中，如果用戶認(rèn)為類似關(guān)系數(shù)據(jù)庫(kù)的平坦的數(shù)據(jù)結(jié)構(gòu)尚不能滿足需要，而需要有層次性的數(shù)據(jù)結(jié)構(gòu)來(lái)支持，我們應(yīng)該如何更新dataBag Template的設(shè)計(jì)？

在具體實(shí)現(xiàn)中，尤其是在大規(guī)模使用的公共平臺(tái)實(shí)現(xiàn)中，如果訪問(wèn)量大幅度增大，應(yīng)該如何對(duì)實(shí)施架構(gòu)的部署進(jìn)行進(jìn)一步設(shè)計(jì)？

大家對(duì)于這兩個(gè)問(wèn)題的任何建議以及大家想到的其他可能的問(wèn)題，都?xì)g迎來(lái)到"http://forum.uddi-china.org/cgi-bin/topic.cgi?forum=15&topic=7&show="提出意見或給出評(píng)論。

小結(jié)

在本系列下一篇文章中，我將圍繞一個(gè)認(rèn)證考試申請(qǐng)系統(tǒng)展開設(shè)計(jì)和討論，這與本文的系統(tǒng)不同，主要是面向B2C模式的應(yīng)用，著眼點(diǎn)在于如何將系統(tǒng)的Client插入到盡可能多的公共平臺(tái)、桌面系統(tǒng)中去，同時(shí)借助這個(gè)Case Study，我將著重講解在Web服務(wù)設(shè)計(jì)的時(shí)候，如何有效地使用XML Schema設(shè)計(jì)系統(tǒng)中使用的XML數(shù)據(jù)模式。

參考資料

 柴曉路: 上海得易電子商務(wù)技術(shù)有限公司(DealEasy)首席系統(tǒng)架構(gòu)師、XML Web Sevices技術(shù)顧問(wèn)，UDDI-China.org創(chuàng)始人，UDDI Advisory Group成員，IBM developerWorks專欄作家。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)于Web Services技術(shù)架構(gòu)、基于XML的系統(tǒng)集成和數(shù)據(jù)交換應(yīng)用及方法，同時(shí)對(duì)數(shù)據(jù)庫(kù)、面向?qū)ο蠹夹g(shù)及CSCW等技術(shù)比較擅長(zhǎng)。