Web Service Case Study: 認證考試申請服務

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

Web Service Case Study: 認證考試申請服務  

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

Chief System Architect

2002年4月10日

本文是Web Service Case Study系列文章的第二篇。在這篇文章中，我將圍繞一個認證考試申請系統(tǒng)展開設計和討論，這個應用與本文的系統(tǒng)不同，主要是面向B2C模式的應用，著眼點在于如何將這個系統(tǒng)的客戶端插入到盡可能多的公共平臺、桌面系統(tǒng)中去，同時借助這個Case Study，我將著重講解在Web服務設計的時候，如何有效地使用XML Schema設計系統(tǒng)中使用的XML數(shù)據(jù)模式。
本文中針對的應用實例是一個認證考試系統(tǒng)，應用背景如下：(以下陳述純屬虛構)

UDDI-China.org是中國的Web Services技術組織，提供Web服務系列技術的技術認證服務，具體負責這個技術認證服務的是UDDI-China.org下的WSTA機構。任何技術人員都可以向WSTA機構提出申請，要求進行某一項Web服務技術(比如XML Schema、SOAP、WSDL、UDDI等)的技術認證，一般流程是要經(jīng)過申請、修讀相應課程、考試這三個主要步驟。WSTA認證考試系統(tǒng)就是為了管理和加速這個流程而開發(fā)的一套系統(tǒng)。

在介紹具體的系統(tǒng)流程之前，我們先來看看這個系統(tǒng)的實體關系圖：

Figure 1.   認證考試系統(tǒng)實體關系圖 

結合圖1中，我們的系統(tǒng)中，基本上可以有這樣三個主要的流程：

注冊：申請人需要填寫申請表，經(jīng)過申請審核其資格，通過后準許進入課程修讀以及考試流程；

課程修讀：通過了申請之后，系統(tǒng)將為這個申請人自動安排一個課程的修讀日程，并安排指定授課老師；

考試：當申請人經(jīng)過課程的修讀(當然也可以不讀書直接考試)，可以申請參加考試，系統(tǒng)將自動為其安排一個考試日程，當申請人完成考試后，將得到相應的成績單以及認證證書(當然要是通過的)。

設計人員希望這個系統(tǒng)的使用者不但能夠通過UDDI-China.org的Web Page來使用認證考試系統(tǒng)，同時設計人員還希望能讓各種桌面工具能夠直接與UDDI-China.org的認證考試系統(tǒng)集成，比如用戶在使用個人事務計劃軟件時，就能夠?qū)⑸暾垺⒙犝n和考試等事務納入系統(tǒng)的安排，涉及的事務安排可以通過個人事務計劃軟件與UDDI-China.org的認證考試系統(tǒng)的交互來自動完成。交互的界面被設計為使用Web服務調(diào)用接口，而Web服務接口中輸入/輸出的數(shù)據(jù)應當是XML格式的，拋開Web服務調(diào)用接口先不談，我們先來看看系統(tǒng)接口中需要使用的XML數(shù)據(jù)模型。

經(jīng)過系統(tǒng)分析，設計人員認為以下實體是需要使用XML來描述的：

Application，在這個XML描述實體中，將涉及圖1中的Applicant和Application；

CourseSession，在這個XML描述實體中，將涉及圖1中的Applicant、Employee、CourseSession和Course；

ExamSession，在這個XML描述實體中，將涉及圖1中的Applicant、ExamSession、Exam和Test。

下面，我們分別給出這三個XML實例文檔的模式。

XML Schema建模

Application

首先，我們給出Application文檔的XML Schema定義及其模式圖示，隨后我們再一一詳細解釋模式的細節(jié)。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="Application" type="applicationType">
    <xs:annotation>
      <xs:documentation>Application的模式定義</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="applicationType">
    <xs:annotation>
      <xs:documentation>Application類型定義</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="person" type="personType"/>
      <xs:element name="company" type="xs:string"/>
      <xs:element name="experience" type="xs:string"/>
      <xs:element name="reference" type="xs:string" minOccurs="0" maxOccurs="3"/>
      <xs:element name="certificationID" type="xs:long"/>
      <xs:element name="applicationDate" type="xs:date"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="personType">
    <xs:annotation>
      <xs:documentation>個人信息類型定義</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="personID" type="xs:long"/>
      <xs:element name="name">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="surname" type="xs:string"/>
            <xs:element name="givenName" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="contact" type="contactType" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="contactType">
    <xs:annotation>
      <xs:documentation>聯(lián)系方法類型定義</xs:documentation>
    </xs:annotation>
    <xs:choice>
      <xs:element name="email"/>
      <xs:element name="phone"/>
      <xs:group ref="mailAddress"/>
    </xs:choice>
  </xs:complexType>
  <xs:group name="mailAddress">
    <xs:sequence>
      <xs:element name="streetAddress" type="xs:string"/>
      <xs:element name="postCode" type="xs:string"/>
    </xs:sequence>
  </xs:group>
</xs:schema>

上面的代碼給出了Application的XML Schema文檔，其中定義了一個Application元素，這個元素是Application數(shù)據(jù)文檔的根元素。Application元素使用了applicationType這個復合類型作為它的類型定義。而applicationType類型定義引用了personType這個類型定義作為個人信息的描述，personType類型定義中使用了contactType類型定義來描述個人的聯(lián)系方式，而contactType類型定義還使用了mailAddress這個組定義，以支持choice的定義方式。

在詳細介紹這個層次結構之前，我們可以先來看一看圖2的模式圖示。

Figure 2.   Application模式圖示 

applicationType復合類型用于描述一個申請表，applicationType復合類型定義包含了6個子元素：person、company、experience、reference、certificationID、applicationDate，分別表示個人信息、所屬公司、工作經(jīng)驗、參考技能認證、認證考試ID、申請日期。其中person的類型是復合類型personType，而其他5個元素都是簡單類型。company、experience、reference的類型都是字符串xs:string，certificationID的類型是xs:long，而applicationDate的類型是xs:date。其中除reference的出現(xiàn)次數(shù)可以是0到3次以外，其他的元素都是出現(xiàn)且僅出現(xiàn)1次。

person子元素應用了personType復合類型，personType復合類型定義包含了3個子元素：personID、name和contact，分別表示個人ID、姓名和聯(lián)系方法。personID是一個簡單類型元素，類型為xs:long。name是一個復合結構，包含了兩個子元素surname和givenName，共同描述了人的姓名。

而contact子元素則是應用了contactType復合類型定義，contactType是一個選擇類型，應用contactType類型的元素可以選擇是包含一個email子元素、或是包含一個phone子元素，或是包含一個mailAddress子元素，mailAddress使用了在后面定義的元素組定義mailAddress。

為了使得對contact元素的定義理解地更為具體一些，我們下面給出一些contact元素的實例表示的例子，具體的，包含在person元素內(nèi)。

<person>
  <personID>20302290</personID>
  <name>
    <surname>Joe</surname>
    <givenName>Huang</givenName>
  </name>
  <contact><email>Joe.Huang@hotmail.com</email></contact>
  <contact><email>Joe.Huang@yahoo.com</email></contact>
  <contact>
    <mailAddress>
      <streetAddress>No.2000, Huangxing Road, Shanghai</streetAddress>
      <postCode>200433</postCode>
    </mailAddress>
  </contact>
</person>

上面的代碼給出了一個person的實例文檔，其中這個個人信息包含了三個聯(lián)絡方式，兩個是email地址，一個是寄信地址，此人沒有留下聯(lián)系電話。

最后，我們給出Application模式的一個完整的實例文檔。

<?xml version="1.0" encoding="UTF-8"?>
<Application>
  <person>
    <personID>20302290</personID>
    <name>
      <surname>Joe</surname>
      <givenName>Huang</givenName>
    </name>
    <contact><email>Joe.Huang@hotmail.com</email></contact>
    <contact><email>Joe.Huang@yahoo.com</email></contact>
    <contact>
      <mailAddress>
        <streetAddress>No.2000, Huangxing Road, Shanghai</streetAddress>
        <postCode>200433</postCode>
      </mailAddress>
    </contact>
  </person>
  <company>Innoteck Company</company>
  <experience>System Architect of Innoteck</experience>
  <certificationID>X00910</certificationID>
  <applicationDate>2002-2-18</applicationDate>
</Application>

CourseSession

同樣，我們先給出CourseSession的XML模式文檔，CourseSession用于描述一門課程的某一個學期的安排。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="CourseSession" type="CourseSessionType">
    <xs:annotation>
      <xs:documentation>CourseSession Schema Definition</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="CourseSessionType">
    <xs:sequence>
      <xs:element name="Course" type="CourseType"/>
      <xs:element name="Session" type="SessionType"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="SessionType">
    <xs:sequence>
      <xs:element name="CourseSessionID" type="xs:long"/>
      <xs:element name="CourseLocation" type="xs:string"/>
      <xs:element name="CourseDate" type="CourseDateListType"/>
      <xs:element name="Teacher" type="EmployeeType"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="CourseType">
    <xs:sequence>
      <xs:element name="courseID" type="xs:long"/>
      <xs:element name="certificationID" type="xs:long"/>
    </xs:sequence>
  </xs:complexType>
  <xs:simpleType name="CourseDateListType">
    <xs:list itemType="xs:date"/>
  </xs:simpleType>
  <xs:complexType name="EmployeeType">
    <xs:complexContent>
      <xs:extension base="personType">
        <xs:sequence>
          <xs:element name="jobTitle"/>
          <xs:element name="department"/>
          <xs:element name="roomNumber"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="personType">
    <xs:sequence>
      <xs:element name="personID" type="xs:long"/>
      <xs:element name="name">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="surname" type="xs:string"/>
            <xs:element name="givenName" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="contact" type="contactType" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="contactType">
    <xs:choice>
      <xs:element name="email"/>
      <xs:element name="phone"/>
      <xs:group ref="mailAddress"/>
    </xs:choice>
  </xs:complexType>
  <xs:group name="mailAddress">
    <xs:sequence>
      <xs:element name="streetAddress" type="xs:string"/>
      <xs:element name="postCode" type="xs:string"/>
    </xs:sequence>
  </xs:group>
</xs:schema>

其中復合類型personType、contactType以及元素組mailAddress的定義與前面代碼中的Application模式文檔中的定義是一樣的，在這個文檔中，我們給出這部分定義是為了EmployeeType的定義需要，在這里，EmployeeType類型定義擴展繼承了personType的類型定義。

其次，CourseSession模式文檔的其他部分分別定義了CourseSessionType、CourseType和SessionType三個復合類型以及一個列表類型CourseDateListType。在詳細介紹這些類型定義之前，我們先給出CourseSession的模式圖示，以加深形象認識。

Figure 3.   CourseSession模式圖示 

下面我們結合圖3的模式圖示來講解一下CourseSession模式定義。

課程學期安排描述CourseSession由兩部分組成(定義在CourseSessionType中)：Course課程和Session學期安排。其中Course子元素應用了CourseType復合類型，該復合類型包含了兩個子元素CourseID和certificationID，分別表示這個課程的ID標識以及這個課程對應的認證考試ID標識。而Session子元素則是應用了SessionType復合類型，該復合類型包含四個子元素：CourseSessionID、CourseLocation、CourseDate和Teacher。CourseSessionID、CourseLocation是兩個簡單類型的子元素，分別表示課程學期安排的標識ID以及課程的授課地點。CourseDate是一個列表類型的元素，它的值是日期列表，表示課程的授課時間。而Teacher子元素應用了EmployeeType復合類型，表示該課程這個學期的授課老師。

其中EmployeeType復合類型定義擴展繼承了personType的類型定義。關于擴展繼承的特性，在這里暫時先不詳細介紹，我將在后面的章節(jié)中給出描述的細節(jié)。

最后，按照前面的慣例，我們給出CourseSession模式的一個實例文檔作為本節(jié)的結尾。

<?xml version="1.0" encoding="UTF-8"?>
<CourseSession>
  <Course>
    <CourseID>X0091001</CourseID>
    <certificationID>X00910</certificationID>
  </Course>
  <Session>
    <CourseSessionID>X009100120020220</CourseSessionID>
    <CourseLocation>Shanghai Education Center</CourseLocation>
    <CourseDate>2002-2-20 2002-2-22 2002-2-26</CourseDate>
    <Teacher>
      <personID>10307827</personID>
      <name>
        <surname>Mike</surname>
        <givenName>Liu</givenName>
      </name>
      <contact><email>Mike.Liu@uddi-china.org</email></contact>
      <contact><phone>13717652090</phone></contact>
      <contact>
        <mailAddress>
          <streetAddress>No.1 UDDI-China Way, Shanghai</streetAddress>
          <postCode>200400</postCode>
        </mailAddress>
      </contact>
    </Teacher>
  </Session>
</CourseSession>

ExamSession

同樣，我們先給出ExamSession的XML模式文檔，ExamSession用于描述某一門認證考試的某一場考試的安排。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="ExamSession" type="ExamSessionType">
    <xs:annotation>
      <xs:documentation>ExamSession Schema Definition</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="ExamSessionType">
    <xs:sequence>
      <xs:element name="Exam" type="ExamType"/>
      <xs:element name="Session" type="eSessionType"/>
      <xs:element name="finished" type="xs:boolean"/>
      <xs:element name="ScoreReport" type="ScoreReportType" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="ExamType">
    <xs:sequence>
      <xs:element name="examID" type="xs:long"/>
      <xs:element name="certificationID" type="xs:long"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="eSessionType">
    <xs:sequence>
      <xs:element name="examSessionID" type="xs:long"/>
      <xs:element name="examLocation" type="xs:string"/>
      <xs:element name="examDate" type="xs:date"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="ScoreReportType">
    <xs:sequence>
      <xs:element name="personID" type="xs:long"/>
      <xs:element name="score" type="xs:integer"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

這個模式文檔相對于Application模式文檔和CourseSession模式文檔來說比較簡單。在這個模式文檔中，主要為定義一個XML文檔元素ExamSession，ExamSession元素應用了ExamSessionType復合類型。ExamSessionType復合類型定義包含了三個四元素Exam、Session、finished和ScoreReport，分別表示認證考試、認證考試的某一場考試的安排、考試是否完成以及成績單。這個XML文檔用于在客戶端和服務器端互相交換ExamSession，比如用戶期望申請某一項認證考試，當然會希望獲得所有的相關ExamSession信息。當某一個ExamSession結束后，這個XML文檔也用于傳輸用戶的成績。

圖4給出了這個XML模式的模式圖示，通過這個模式圖示，大家應該能夠更好地理解這個模式的結構。

Figure 4.   ExamSession模式圖示 

最后我們按照這個模式文檔，給出它的一個實例文檔，作為本節(jié)的結束。

<?xml version="1.0" encoding="UTF-8"?>
<ExamSession>
  <Exam>
    <examID>EX00910</examID>
    <certificationID>X00910</certificationID>
  </Exam>
  <Session>
    <examSessionID>EX0091020020309</examSessionID>
    <examLocation>Shanghai Education Center</examLocation>
    <examDate>2002-3-9</examDate>
  </Session>
  <finished>true</finished>
  <ScoreReport>
    <personID>20302290</personID>
    <score>92</score>
  </ScoreReport>
</ExamSession>

應用模式演示

在這里，我們將外部的應用假設也加入到整個應用模式中來，參照下圖，其中National Education Information Portal是一個國家范圍的教育信息門戶網(wǎng)站，而Global IT Education Web Service則是一個全球IT教育機構提供的一個在線Web服務。它們都以這個認證考試申請系統(tǒng)的Web服務客戶端應用的角色出現(xiàn)在應用模式中。(以下的應用模式發(fā)展流程完全屬于應用假設，其中的所有實體和細節(jié)純屬虛構)

Figure 5.   應用模式演示 

如圖所示，Web服務認證機構WSTA開始向公眾提供Web服務技術認證服務，一開始這個服務僅在機構內(nèi)部工作，工作人員通過手工或Email收取報名表格，然后在自己的桌面應用中為客戶完成相關的注冊，上課和考試等申請流程，按照這種方式，整個機構的運行效率不高，所有的流程瓶頸集中在機構內(nèi)部的桌面應用上。隨著申請認證考試的學員不斷增多，WSTA不得不使用其提供認證的技術：Web服務技術來改造他的應用。完成認證考試各項申請的邏輯被包裝成EJB Web Service，并部署在機構內(nèi)部的BEA Weblogic Application Server上，而桌面應用也被升級以支持對Web服務調(diào)用(也就是成為了一個Web Service Client)，為了使得這個認證申請Web服務(WSTK Web Service)能夠被更多的人通過各種平臺進入并使用，這個Web服務被注冊進了Public UDDI Registry，并發(fā)布了它的WSDL描述文檔。同時，WSTA也積極與公共教育平臺進行接觸并嘗試合作可能。經(jīng)過一番接觸，國家教育信息門戶(National Educastion Information Portal, NEIP)同意與WSTA進行系統(tǒng)對接，以實現(xiàn)在NEIP平臺上直接對WSTA提供的Web服務技術認證考試處理申請流程。NEIP采用的是Microsoft .NET的平臺，因此在這里實施了J2EE和.NET平臺的連接集成。同時由于將自身注冊入了Public UDDI Registry，WSTA的認證考試申請服務有機會被更多的外部平臺集成使用。如圖中的Global IT Education Web Service就是一例，Global IT Education通過對Public UDDI Registry的搜索，搜索全球提供IT認證的機構，WSTK的Web服務是處于搜索結果集中的，Global IT Education通過處理搜索到的WSDL文檔，完成了對WSTK的Web服務的綁定，實現(xiàn)了Global IT Education Web Service與WSTK Web Service的連接。

下面，我們按照圖中的序號標明的順序，逐一講解在這個Web服務的應用場景下，各個組件是如何協(xié)同實施和運作的：

用戶可以通過NEIP的Web界面申請Web服務技術認證的注冊、課程和考試；

NEIP的Web站點把請求通過Internet發(fā)送給WSTK的認證管理Web服務；

WSTK的認證申請管理Web服務通過與機構數(shù)據(jù)庫的交互，完成申請事務，并響應NEIP的Web站點，并最終將響應返回終端用戶；

WSTK認證服務的技術信息(比如WSDL文檔)被注冊入了Public UDDI Registry供公共查詢；

Global IT Education的在線服務通過搜索Public UDDI Registry，尋找到了WSTK認證申請服務；

Global IT Education獲得WSTK認證申請服務的技術信息，實現(xiàn)動態(tài)綁定；

Global IT Education建立與WSTK認證申請服務的應用集成；

任何使用Global IT Education的應用(包括各種應用、Web站點、Web服務)都可以通過Global IT Education的Web服務來使用WSTK認證申請服務；
WSTK內(nèi)部的桌面應用同樣是使用Web服務界面綁定的技術來調(diào)用WSTK認證申請服務的。

服務的可用性和連接的持久性

既然這個認證考試申請服務是面向廣大的個人用戶的，用戶不但可以通過WSTK機構進行申請，同時也可以通過任何的集成了WSTK認證考試申請服務的應用、平臺、網(wǎng)站等使用這個認證考試申請服務。對于WSTK而言，使用的用戶越多，就越證明WSTK認證考試申請服務的成功，而使用的用戶越多，一般而言，也意味著與WSTK認證考試申請服務建立Web服務連接的應用程序、平臺或網(wǎng)站也越多。然后，任何事情都有其正反兩方面的影響，如果使用的用戶非常多，接入的平臺、應用的數(shù)量也非常多的話，WSTK認證考試申請服務的可用性，以及連接的持久性就成為了一個非常非常關鍵的問題。

關于傳統(tǒng)軟件領域，甚至是硬件領域中涉及的穩(wěn)定性、可用性和持久性方面，我就不再在這里探討了，這不屬于我們正面對的基于Internet的分布式應用環(huán)境的這個分布式應用集成。那么我們需要面對的是什么呢？

如果WSTK認證考試申請服務這個Web Service所在的系統(tǒng)發(fā)生崩潰或者因為系統(tǒng)維護的原因，WSTK不得不把這個服務臨時遷移到備份服務器上，服務所在服務器的IP地址發(fā)生了變化，甚至，服務入口的URL也可能發(fā)生了變化。此時，現(xiàn)存的所有連接將不再有效(地址和入口都變了，自然不會持續(xù)有效)，那么快速地恢復連接是我們需要處理的問題。

回顧一下，以前我們在做EAI時候的方法，對每個相關模塊/系統(tǒng)的開發(fā)人員、維護人員發(fā)出通知，要求他們更改相應的代碼，這在企業(yè)內(nèi)部情況尚好，我們還是能夠在一定時間內(nèi)通知到每個人，然后各個模塊依照人員的技術能力和工作時間的多少，一一完成了連接的恢復，不過萬一負責某個模塊的技術人員出差或其他一些原因無法更新相應的代碼，那么這個模塊將有一段時間無法使用。現(xiàn)在將這一情況從企業(yè)內(nèi)拓展到了企業(yè)間、機構與個人之間后，情況似乎變得更為復雜，相同的意外情況往往導致非常惡劣的后果。

首先，我們是否還能通知到每個與WSTK服務相連接的企業(yè)或機構，其中部分按照合約方式建立連接的也許可以，然而由于是位于不同企業(yè)，之間的協(xié)同存在問題。同時還有一大部分是通過查詢Public UDDI Registry找到WSTK的服務從而和WSTK服務建立連接的應用，這些應用的維護者，我們根本無法通過一般的途徑找到他們，如果仍然只能使用人與人的交流方式，那么這些連接將在一段時間內(nèi)中斷，如果服務被永久性地遷移了，那么這些好不容易發(fā)展起來的連接將從此中止。

其次，WSTK服務是一個最終服務，中間會有很多門戶網(wǎng)站、機構網(wǎng)站以WSTK服務的代理的形式直接向最終用戶提供服務。如果WSTK服務的質(zhì)量出現(xiàn)問題，這些門戶網(wǎng)站、機構網(wǎng)站可能因他們自身網(wǎng)站、服務的聲譽問題，而考慮是否以后還要在他們的網(wǎng)站、服務中提供對WSTK認證考試申請的服務。因為對于最終用戶而言，他們使用的就是這些網(wǎng)站、機構所提供的服務，他們并不知道最終WSTK認證考試申請服務才是最終的服務提供者，因此如果WSTK認證考試申請服務不工作，他們就是認為是這些網(wǎng)站、機構的服務不工作了。

再次，還有相當一部分是直接被集成到終端用戶的桌面應用的，對于這種情況，WSTK更是沒有辦法通過傳統(tǒng)的方式重建連接了……

我們面臨的問題是很嚴峻，不過由于我們采用的是Web服務架構，利用的是UDDI作為我們的服務發(fā)現(xiàn)機制，因此這種服務連接恢復的問題，我們可以通過UDDI所提供的機制來嘗試解決。

我們知道，WSTK一開始就把WSTK認證申請服務注冊到了UDDI注冊中心，具體的說，是在UDDI注冊中心中注冊了一個businessService(對應于這個服務)，這個businessService中包含了一個bindingTemplate用于描述這個服務的技術調(diào)用規(guī)范，其中包含了這個Web服務的訪問入口以及如何訪問這個Web服務的WSDL文檔等等。對于搜索UDDI Registry的企業(yè)/機構而言，他們需要得到的就是bindingTemplate信息，從UDDI注冊中心中獲得的bindingTemplate信息集中的數(shù)據(jù)表示了一個指定的遠端Web服務的調(diào)用規(guī)范實例。這些企業(yè)/機構的應用程序應當緩存該信息并且使用這個調(diào)用規(guī)范通過該WSTK服務注冊的地址來訪問這個WSTK Web Service。

當使用從UDDI注冊中心中獲得并緩存下來的信息(調(diào)用入口等)進行調(diào)用發(fā)生失敗時，正確的做法是去查詢當初獲得該數(shù)據(jù)的UDDI注冊中心并獲取與其對應的更新了的bindingTemplate信息。也就是說，當一個服務因為維護或災難恢復發(fā)生遷移時，一旦遷移完成這個服務應當主動去更新在UDDI Registry中相應的bindingTemplate記錄。對應于前面的WSTK服務的情形，WSTK服務應當去更新其對應的bindingTemplate中的訪問入口地址URL等。

在使用Web服務中，使用這樣的調(diào)用模式，那么使用UDDI操作入口站點(Operator Site)的商業(yè)實體就得以在不加重通信與協(xié)調(diào)開銷的情況下自動完成與大量合作伙伴的服務恢復。這一過程的詳細程序式描述如下：

服務提供者使用save_xx在UDDI注冊中心中注冊了Web服務S；

調(diào)用者使用find_xx查詢UDDI注冊中心，獲得所需的服務S的概要信息；

調(diào)用者使用get_xx再一次查詢UDDI注冊中心，獲得所需服務S的詳細信息；

調(diào)用者緩存服務S的bindingTemplate信息，通過服務綁定，實施對服務S的調(diào)用；

服務S由于某種原因出現(xiàn)問題，無法繼續(xù)提供服務；

服務提供者在新的位置重新部署了服務S，同時更新了UDDI注冊中心的關于Web服務S的技術描述；

調(diào)用者使用緩存的服務S的bindingTemplate信息再一次進行調(diào)用，調(diào)用失敗；(服務S的部署位置已經(jīng)更改)

調(diào)用者使用緩存的bindingTemplate的bindingKey鍵值查詢UDDI注冊中心，獲得服務S的更新后的bindingTemplate信息。

調(diào)用者緩存服務S的新的bindingTemplate信息，通過服務綁定，重新實施對服務S的調(diào)用。

服務的延伸

由于WSTK認證考試申請服務已經(jīng)以Web服務的方式架構起來了，在成功應用一定時間之后，這個服務架構將成為一個解決方案在一定范圍內(nèi)實施推廣，一個快速有效的辦法是將這個認證考試申請服務升級為一個ASP服務，供各種提供認證考試的機構通過Internet租用。這是一個有效利用資源和盈利的渠道。不過此時我們面臨的情況將更加復雜。由于是ASP服務，一般來說，在ASP服務中，租用者并不是ASP服務的所有者，他們各自的服務入口可能是彼此不同的，但不排除彼此相同的實現(xiàn)可能(比如通過提供不同的用戶名/密碼，但入口是一個)，同時這些入口調(diào)用信息并不是由租用者來管理的，事實上，當ASP服務的提供者更改入口地址也是可能發(fā)生的異常情況。此時仍然要求由服務提供者去更新bindingTemplate信息以滿足服務遷移的平滑性變得不再實際了。

那么，馬上可以想到的，就是所有與這個ASP服務相關的bindingTemplate都由ASP服務的提供者來管理。不過，這仍然不切實際，因為如此一來，就違背UDDI Registry搜索的初衷了，首先搜索者是要搜索商業(yè)實體businessEntity，如果不同的機構的businessService都被保存在ASP服務提供者的businessEntity下，顯然與用戶的搜索方式相悖，同時對于businessService的描述信息，那些提供認證考試的機構都期望自己來維護，顯然這不是一個正確的合適的解決方案。UDDI在bindingTemplate機制里面提供了一個重定向的方法來試圖解決這個問題，關于這個方法我將在本系列的下一篇文章中結合下一個實例給出。

大家對于這兩個問題的任何建議以及大家想到的其他可能的問題，都歡迎到論壇來提出意見或給出評論。

參考資料