Web Service Case Study:軟件反饋跟蹤平臺

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

Web Service Case Study:軟件反饋跟蹤平臺  

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

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

案例背景簡介 - 軟件反饋跟蹤平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

Catalog Service

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

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

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

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

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

Authentication Service

而Authentication Service則相對簡單，它的功能可描述如下：

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

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

系統(tǒng)間的交互

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

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

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

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

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

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

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

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

為什么使用Web服務(wù)解決方案?

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

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

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

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

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

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

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

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

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

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

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

交互界面設(shè)計

之前，我們已經(jīng)談到了需要為我們自己開發(fā)的Web服務(wù)制訂調(diào)用規(guī)范，那么調(diào)用規(guī)范該如何定義呢，從總體上來說，規(guī)范定義可以分為兩部分:

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

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

API設(shè)計原則

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

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

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

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

Data Structure設(shè)計

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

Category的具體描述格式：

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

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

在給出了目錄的數(shù)據(jù)之后，我們再來定義反饋數(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é)點的UUID。Name和description子元素與前面的含義是類似的。下面我們來介紹一下dataBag這個子元素，這是一個字段值的聚集，一個dataBag可以包含0個或多個字段。每個字段都是以<field name="……">……</field>的形式出現(xiàn)的，

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

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

這個dataBag Template定義了三個字段，Application(應(yīng)用名稱)、Module(模塊名稱)、Exception(異常編號，注意這是整型字段)以及Description(錯誤描述)，這個Template用于定義一般的錯誤報告的模版結(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)平臺就可以利用templateKey找到相應(yīng)的dataBag Template，從而進(jìn)行數(shù)據(jù)校驗。需要注意的是，databag Template并不在系統(tǒng)的一般交互中被傳輸，它是作為系統(tǒng)的插件安裝在平臺系統(tǒng)或者客戶端中的，也就是說，當(dāng)平臺系統(tǒng)接收到反饋數(shù)據(jù)XML文檔后，從這個文檔中獲得templateKey，然后通過templateKey在系統(tǒng)中查找，看看這個對應(yīng)的dataBag Template是否已經(jīng)被安裝(導(dǎo)入)進(jìn)平臺，如果已經(jīng)安裝了，那么就按照這個Template來校驗合法性，如果尚則安裝，則可以選擇報錯，或忽略合法性校驗。

Catalog Service API設(shè)計

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

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

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

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

save_feedback: 保存product，在這個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)品使用(消費)者用戶的話，那么功能基本上可以被分為兩類。軟件產(chǎn)品使用者僅能使用find_category和save_feedback，而軟件產(chǎn)品生產(chǎn)者則可使用所有功能。如果平臺提供商與軟件產(chǎn)品生產(chǎn)者并非同一家的話，那么軟件產(chǎn)品生產(chǎn)者將不能使用delete_category和save_category消息API。

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

save_feedback

用于提交反饋數(shù)據(jù)，使用這個API調(diào)用，可以完成對反饋數(shù)據(jù)的更新、新建和遷移的操作。一般來說對于普通用戶，僅僅可以新建反饋數(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īng)該可以發(fā)現(xiàn)，save_feedback能夠用于保存一個或多個feedback反饋數(shù)據(jù)，這樣的設(shè)計是為了達(dá)到高效性的設(shè)計目標(biāo)。

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

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

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

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

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

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

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

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

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

一個XML Schema文檔中的定義通常分為兩部分，型(Type)定義和元素(Element)定義。下面我們結(jié)合save_feedback具體的XML Schema定義來說明如何使用XML Schema來進(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>

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

SOAP消息示例

有了XML Schema之后，我們就可以參照XML Schema在Web服務(wù)實現(xiàn)時使用SOAP進(jìn)行互相通信了。以下是一個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/。

在這個消息中，將在一個現(xiàn)有的category中添加一個新的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元素后面帶了一個xmlns的修飾"http://www.sagitta.com/schema/"。這個URI唯一表示了該元素及其所有子元素的的命名空間。同時通過這個URL可以獲得這些元素的Schema定義。

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

WSDL服務(wù)描述

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

一般來說，有了XML Schema，WSDL文檔的生成是非常方便的，我們在各個平臺上都有豐富的工具可以使用，這里就不給出具體的WSDL文檔了。

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

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

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

businessService注冊的SOAP消息如下，其中使用了Microsoft的test.uddi.microsoft.com站點，因此authInfo中可以填入測試用的"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>

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

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

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

具體的流程一般是：

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

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

遺留的問題

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

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

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

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

小結(jié)

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

參考資料

 柴曉路: 上海得易電子商務(wù)技術(shù)有限公司(DealEasy)首席系統(tǒng)架構(gòu)師、XML Web Sevices技術(shù)顧問，UDDI-China.org創(chuàng)始人，UDDI Advisory Group成員，IBM developerWorks專欄作家。2000年獲復(fù)旦大學(xué)計算機科學(xué)碩士學(xué)位，曾在國際計算機科學(xué)學(xué)術(shù)會議(ICSC)、亞太區(qū)XML技術(shù)研討會(XML Asia/Pacific'99)、中國XML技術(shù)研討會(北京)、計算機科學(xué)期刊等各類國際、國內(nèi)重要會議與期刊上發(fā)表論文多篇。專長于Web Services技術(shù)架構(gòu)、基于XML的系統(tǒng)集成和數(shù)據(jù)交換應(yīng)用及方法，同時對數(shù)據(jù)庫、面向?qū)ο蠹夹g(shù)及CSCW等技術(shù)比較擅長。