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

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

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

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

Chief System Architect

2002年3月26日

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

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

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

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

在這樣的應用背景下，用戶反饋不僅僅包括用戶對產品的意見，同時也包含軟件產品的BUG自動報告，以及一些性能參數的采集等。當然其中的有些是需要客戶授權方可進行的，比如性能參數收集等。

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

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

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

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

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

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

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

系統(tǒng)構架概述

Figure 1. 系統(tǒng)結構概述

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

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

Catalog Service

根據前面的應用背景描述，Catalog Service應當具備如下功能：

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

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

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

數據備份，整個目錄下所有反饋數據的備份/恢復等。

Authentication Service

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

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

權限審核，用戶權限審核，為除Authentication Service之外的服務提供權限審核功能。

系統(tǒng)間的交互

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

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

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

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

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

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

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

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

為什么使用Web服務解決方案?

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

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

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

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

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

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

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

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

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

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

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

交互界面設計

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

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

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

API設計原則

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

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

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

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

Data Structure設計

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

Category的具體描述格式：

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

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

在給出了目錄的數據之后，我們再來定義反饋數據的數據結構：

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

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

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

鑒于合法性校驗的考慮，我們認為，可以引入dataBag Template的概念，所謂dataBag Template就是一種預先定義好的在某個特定領域應用中使用的反饋信息數據的模版，這個模版定義了所有合法的字段，包括字段名稱及其字段值類型。下面我們給出一個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(應用名稱)、Module(模塊名稱)、Exception(異常編號，注意這是整型字段)以及Description(錯誤描述)，這個Template用于定義一般的錯誤報告的模版結構。

由于使用了dataBag Template，我們需要更新反饋數據的數據結構：

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

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

Catalog Service API設計

Catalog Service的API設計如下：

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

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

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

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

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

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

get_categoryDetail: 獲取category的完整信息，包括包含的所有category的簡要信息和feedback的詳細信息。

get_productDetail: 獲取feedback的完整信息。

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

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

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

save_feedback

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

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

在上述的語法描述中，大家應該可以發(fā)現，save_feedback能夠用于保存一個或多個feedback反饋數據，這樣的設計是為了達到高效性的設計目標。

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

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

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

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

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

Web服務實現

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

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

XML Schema數據建模

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

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服務實現時使用SOAP進行互相通信了。以下是一個save_feedback的調用例子，在例子中使用了SOAP HTTP Binding(使用的SOAP規(guī)范的版本是1.2)，假設目標Web服務被部署在假象的www.sagitta.com，而調用的Web服務的入口位置將是http://www.sagitta.com/feedback/。

在這個消息中，將在一個現有的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服務的技術系列中處于一個支持工具的地位。W3C XML Schema是任何類型的XML文檔的建模工具。在Web服務體系中，無論在SOAP消息的表示上，還是在WSDL的界面描述上，XML Schema都是不可缺少的重要工具和底層支持。

WSDL服務描述

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

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

UDDI服務發(fā)布

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

我們之前已經注冊了一個businessEntity，叫做www.sagitta.com，一個在線服務提供商，這個businessEntity的鍵值是"434554F4-6E17-1342-EA41-36E642531DA1"，那么我們要在這個businessEntity下注冊一個businessService，以用于描述我們的這個Feedback Service。同時我們也預先注冊了一個Service Type(tModel)，這個tModel描述了我們這個需要發(fā)布的Web服務的調用規(guī)范，具體內容是我們先前已經生成的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調用，我們就已經把這個服務注冊進了UDDI注冊中心，其中bindingTemplate的accessPoint是服務的入口。

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

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

具體的流程一般是：

當恢復的服務啟動后，自動去更新UDDI注冊中心上的數據，將訪問入口修改到新的URL位置;

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

遺留的問題

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

在dataBag Template的設計中，如果用戶認為類似關系數據庫的平坦的數據結構尚不能滿足需要，而需要有層次性的數據結構來支持，我們應該如何更新dataBag Template的設計？

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

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

小結

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

參考資料

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