WebServiceCaseStudy:軟件反饋跟蹤平臺(tái)

柴曉路([email protected])

ChiefSystemArchitect

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)用的思想。所以從本次開始的"WebServiceCaseStudy"文章系列中，我將在每一篇文章中使用一個(gè)具體的應(yīng)用實(shí)例，通過應(yīng)用分析來詳細(xì)闡述使用Web服務(wù)技術(shù)的好處和優(yōu)越性，同時(shí)從Web服務(wù)的角度結(jié)合實(shí)例介紹各種Web服務(wù)技術(shù)在具體的項(xiàng)目中應(yīng)該如何被使用。

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

案例背景簡介-軟件反饋跟蹤平臺(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ù)收集等。

首先，我們先來分析一下在這個(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ù)人員以描述方式提供，或通過軟件產(chǎn)品的某種日志接口導(dǎo)出文件并提供給軟件公司。

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

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

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

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

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

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

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

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

CatalogService

根據(jù)前面的應(yīng)用背景描述，CatalogService應(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)出(ImportExport)，單個(gè)反饋數(shù)據(jù)的導(dǎo)入導(dǎo)出，整個(gè)類別樹的導(dǎo)入導(dǎo)出等；

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

AuthenticationService

而AuthenticationService則相對(duì)簡單，它的功能可描述如下：

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

權(quán)限審核，用戶權(quán)限審核，為除AuthenticationService之外的服務(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)，一般來說主要的反饋數(shù)據(jù)，包括BUG報(bào)告，性能數(shù)據(jù)以及描述性反饋都是屬于葉子結(jié)點(diǎn)，也就是軟件產(chǎn)品的，不過在非葉子結(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è)處理模塊。

無論是對(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)盡可能地簡單和統(tǒng)一，這樣才能保障軟件產(chǎn)品的代碼的可維護(hù)性。

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

基于XML技術(shù)的Web服務(wù)正是解決這一問題的最佳手段。Web服務(wù)的使用將改變目前的開發(fā)模式和應(yīng)用部署的費(fèi)用規(guī)模。各種Web服務(wù)分別實(shí)現(xiàn)了一定的模塊功能，通過將各種提供不同功能的Web服務(wù)進(jìn)行組合和集成以創(chuàng)建動(dòng)態(tài)應(yīng)用。Web服務(wù)能夠統(tǒng)一地封裝信息、行為、數(shù)據(jù)表現(xiàn)以及商務(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)用者來說，只要Web服務(wù)的調(diào)用界面不變，Web服務(wù)的實(shí)現(xiàn)任何變更對(duì)他們來說都是透明的，甚至是當(dāng)Web服務(wù)的實(shí)現(xiàn)平臺(tái)從J2EE遷移到了.NET或者是相反的遷移流程，用戶都可以對(duì)此一無所知。

使用協(xié)約的規(guī)范性，這一特征從對(duì)象而來，但相比一般對(duì)象其界面規(guī)范更加規(guī)范化和易于機(jī)器理解。首先，作為Web服務(wù)，對(duì)象界面所提供的功能應(yīng)當(dāng)使用標(biāo)準(zhǔn)的描述語言來描述(比如WSDL)；其次，由標(biāo)準(zhǔn)描述語言描述的服務(wù)界面應(yīng)當(dāng)是能夠被發(fā)現(xiàn)的，因此這一描述文檔需要被存儲(chǔ)在私有的或公共的注冊(cè)庫里面。同時(shí)，使用標(biāo)準(zhǔn)描述語言描述的使用協(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ī)范的方法來描述、傳輸和交換。最后，在所有層次的處理都應(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ù)采取簡單的、易理解的標(biāo)準(zhǔn)Web協(xié)議作為組件界面描述和協(xié)同描述規(guī)范，完全屏蔽了不同軟件平臺(tái)的差異，無論是CORBA、DCOM還是EJB都可以通過這一種標(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ī)范該如何定義呢，從總體上來說，規(guī)范定義可以分為兩部分:

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

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

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

簡單性，由于這是一個(gè)對(duì)于公共開放的Web服務(wù)，它的API的設(shè)計(jì)首先應(yīng)當(dāng)是簡單的，要被大量用戶接受，要獲得比較好的應(yīng)用，那么API必須簡單，沒有哪個(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)持簡單性的前提下，兼顧高效性，當(dāng)某些組合操作應(yīng)用地非常頻繁的時(shí)候，我們應(yīng)當(dāng)為這樣的組合操作調(diào)用設(shè)計(jì)一個(gè)只需一次交互的單一入口調(diào)用，這樣能夠提升外部應(yīng)用的效率，同時(shí)減輕Web服務(wù)的負(fù)載。

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

DataStructure設(shè)計(jì)

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

Category的具體描述格式：

categorycategoryKey="…"parentCategoryKey="…"
name……name
description……description
categorycategoryKey="…"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è)賮矶x反饋數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)：

feedbackfeedbackKey="…"parentCategoryKey="…"type="…"
name……name
description……description
dataBag
fieldname="[fieldname]"……field*
dataBag
feedback

其中，feedback元素的屬性feedbackKey和parentCategoryKey分別表示當(dāng)前feedback元素的UUID以及其所在類別結(jié)點(diǎn)的UUID。Name和description子元素與前面的含義是類似的。下面我們來介紹一下dataBag這個(gè)子元素，這是一個(gè)字段值的聚集，一個(gè)dataBag可以包含0個(gè)或多個(gè)字段。每個(gè)字段都是以fieldname="……"……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)這些字段的合法性(比如字段名有沒有寫錯(cuò)，字段值的類型是否正確等)卻是非常不利的。

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

dataBagTemplatetemplateKey="…"
fieldname="Applicationo"type="xs:string"
fieldname="Module"type="xs:string"
fieldname="Exception"type="xs:integer"
fieldname="Description"type="xs:string"
dataBagTemplate

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

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

feedbackfeedbackKey="…"parentCategoryKey="…"type="…"
name……name
description……description
dataBagtemplateKey="……"
fieldname="[fieldname]"……field*
dataBag
feedback

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

CatalogServiceAPI設(shè)計(jì)

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

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

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

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

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

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

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

get_categoryDetail:獲取category的完整信息，包括包含的所有category的簡要信息和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描述格式，那么下面我們就可以來定義API消息了。在這里，我們僅僅定義一個(gè)消息save_feedback，其他的消息則可以類似推得。

save_feedback

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

save_feedback
authInfo……authInfo
feedbackfeedbackKey="…"parentCategoryKey="…"type="…"*
name……name
description……description
dataBagtemplateKey="……"
fieldname="[fieldname]"……field*
dataBag
feedback
ave_category

在上述的語法描述中，大家應(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ù)庫中，在返回消息中，將回送這些元素的鍵值。

當(dāng)消息中任意一個(gè)feedback的parentCategoryKey沒有發(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)令牌。用戶通過向AuthenticationService登錄而獲得這個(gè)令牌，當(dāng)CatalogService得到這個(gè)令牌后，則是向AuthenticationService詢問令牌的合法性，如果合法方能執(zhí)行相應(yīng)的消息，用戶在交互完畢之后，應(yīng)向AuthenticationService注銷令牌。

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

result
feedbackfeedbackKey="f02"parentCategoryKey="a01"
feedbackfeedbackKey="f03"parentCategoryKey="a01"
feedbackfeedbackKey="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í)踐來進(jìn)一步介紹Web服務(wù)技術(shù)系列中的XMLSchema、SOAP、WSDL、UDDI等在服務(wù)實(shí)現(xiàn)的過程中是如何被一一使用的。

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

XMLSchema數(shù)據(jù)建模

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

save_feedback的XMLSchema描述定義：

?xmlversion="1.0"encoding="UTF-8"?
xs:schemaxmlns:xs=""elementFormDefault="qualified"attributeFormDefault="unqualified"
xs:elementname="save_feedback"type="save_feedback"
xs:annotation
xs:documentationsave_feedbackAPISchemaDefinitionxs:documentation
xs:annotation
xs:element
xs:complexTypename="save_feedback"
xs:sequence
xs:elementname="authInfo"type="xs:base64Binary"
xs:elementname="feedback"type="feedbackType"
xs:sequence
xs:complexType
xs:complexTypename="feedbackType"
xs:sequence
xs:elementname="name"type="xs:string"
xs:elementname="description"type="xs:string"
xs:elementname="databag"type="dataBagType"
xs:sequence
xs:complexType
xs:complexTypename="dataBagType"
xs:sequence
xs:elementname="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消息示例

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

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

POSTcatalogHTTP1.1
Content-Type:textxml;charset="utf-8"
Content-Length:nnnn
SOAPAction:""
Host:www.sagitta.com

?xmlversion="1.0"encoding="UTF-8"?
env:Envelopexmlns:env=""
env:Body
save_feedbackxmlns=""
authInfo5Az784kJceHCE982eBauthInfo
feedbackfeedbackKey=""parentCategoryKey="……"
nameBugReportname
description……description
dataBagtemplateKey="……"
fieldname="Application"AgilityBusinessPlatformfield
…………
dataBag
feedback
ave_feedback
env:Body
env:Envelope

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

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

WSDL服務(wù)描述

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

一般來說，有了XMLSchema，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í)的連接保持能力，我們需要使用UDDISDK將這個(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è)FeedbackService。同時(shí)我們也預(yù)先注冊(cè)了一個(gè)ServiceType(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"。

?xmlversion="1.0"encoding="UTF-8"?
Envelopexmlns=""
Body
save_servicegeneric="1.0"xmlns="urn:uddi-org:api"
authInfoudditestauthInfo
businessServicebusinessKey="434554F4-6E17-1342-EA41-36E642531DA1"serviceKey=""
namefeedbackServicename
descriptionxml:lang="en"OnlineWebServiceforFeedbackdescription
bindingTemplates
bindingTemplatebindingKey=""serviceKey=""
descriptionxml:lang="en"feedbackService"sBindingTemplatedescription
accessPointURLType="http"
tModelInstanceDetails
tModelInstanceInfotModelKey="uuid:231A569A-EEFF-4448-BA4D-2B222FE4ACEF"
……
tModelInstanceInfo
tModelInstanceDetails
bindingTemplate
bindingTemplates
businessService
ave_service
Body
Envelope

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

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

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

具體的流程一般是：

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

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

遺留的問題

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

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

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

大家對(duì)于這兩個(gè)問題的任何建議以及大家想到的其他可能的問題，都?xì)g迎來到"?forum=15topic=7show="提出意見或給出評(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è)CaseStudy，我將著重講解在Web服務(wù)設(shè)計(jì)的時(shí)候，如何有效地使用XMLSchema設(shè)計(jì)系統(tǒng)中使用的XML數(shù)據(jù)模式。

參考資料

• WebService技術(shù)評(píng)論網(wǎng)站
  
  • UDDI-China.ORG,以UDDI為主的Web服務(wù)技術(shù)網(wǎng)站。
    
  • WebServices.ORG,Web服務(wù)的綜合類技術(shù)網(wǎng)站。
    
  • IBMdeveloperWorksWebServiceZone,IBM的Web服務(wù)技術(shù)資源中心
    
  • MSDNOnlineWebServicesDeveloperResources,Microsoft的Web服務(wù)的開發(fā)者資源網(wǎng)站
    
  • ITPapersWebService,ITPapers的Web服務(wù)評(píng)論文章
    
  • • 解決B2B電子商務(wù)應(yīng)用交互和集成的InterOPStack系列技術(shù)標(biāo)準(zhǔn)規(guī)范
      
      • UDDI執(zhí)行白皮書,UDDI-China.org,UDDI.org
        
      • UDDI技術(shù)白皮書,UDDI-China.org,UDDI.org
        
      • UDDI程序員API規(guī)范,UDDI-China.org,UDDI.org
        
      • UDDI數(shù)據(jù)結(jié)構(gòu)參考,UDDI-China.org,UDDI.org
        
      • WebServiceDescriptionLanguage(WSDL)1.0,IBM,25Sep2000
        
      • SOAP:SimpleObjectAccessProtocolSpecification1.1,IBM,Microsoft,DevelopMentor,2000
        
      • XMLSchemaPart0:Primer,W3C,2May2001
        
      • ExtensibleMarkupLanguage(XML)1.0(SecondEdition),W3C,6Oct2000

      • • 作者簡介