bindingTemplate與Web服務調(diào)用

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

bindingTemplate與Web服務調(diào)用

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

Chief System Architect

2001年11月22日

本文通過介紹UDDI數(shù)據(jù)模型中的bindingTemplate數(shù)據(jù)實體，對如何使用bindingTemplate中的信息實施Web服務調(diào)用進行了討論，闡明了利用緩存bindingTemplate加速服務多次調(diào)用的方法，也介紹了在災難恢復的情況下如何再次緩存的方法。同時通過對hostingRedirector的功能的分析，介紹了簡單間接模式和重定向模式對于非直接提供服務，而是由ASP供應商提供服務這一模式的重要性。

Web服務的技術描述是通過單獨包含的bindingTemplate結(jié)構的實例來實現(xiàn)的。這些結(jié)構提供對決定技術入口點的支持，或者可選地支持遠端主機宿主的服務，同時還提供一個輕量級的工具用于描述指定服務實現(xiàn)的唯一技術特征。技術和應用相關的參數(shù)和配置文件也同時被支持。

由于UDDI的主要作用是用來描述和發(fā)現(xiàn)Web服務信息，所以bindingTemplate被用來描述最令人感興趣的技術信息。

每一個bindingTemplate結(jié)構都有一個單一的businessService邏輯父結(jié)構，并且該businessService也有一個單一的businessEntity邏輯父結(jié)構。

bindingTemplate結(jié)構規(guī)范

下層子結(jié)構說明

下面用粗體表示的字段是必要字段，必須出現(xiàn)。

字段名 描述 數(shù)據(jù)類型 長度 bindingKey 給定的bindingTemplate的唯一的鍵值。當保存一個新的bindingTemplate結(jié)構時，應當傳入一個值為空的bindingKey值。上述操作將促使UDDI注冊中心生成一個新的UUID值。為更新一個已經(jīng)存在的bindingTemplate結(jié)構，應當傳入與該綁定信息相對應的UUID值。如果數(shù)據(jù)是通過一個查詢操作得到，bindingKey值可以不為空。 UUID 41 serviceKey 當bindingTemplate數(shù)據(jù)包含在一個已經(jīng)完整表達信息的同時已經(jīng)包含一個serviceKey值的businessService父結(jié)構時，這個屬性是可選的。如果bindingTemplate數(shù)據(jù)被生成為XML文檔，同時這個文檔中沒有包含一個具有serviceKey的businessService父結(jié)構，那么必須在bindingTemplate中提供父結(jié)構的serviceKey值。這種行為支持了以任何核心元素作為起點而進行瀏覽的行為，在這種情況下這樣的數(shù)據(jù)描述能夠輕松地處理核心元素給定的父/子關系。 UUID 41 description 可選的可重復元素。對技術服務入口點的具備國家語言代碼修飾的零個或多個文本描述。 string 255 accessPoint 必要的由屬性修飾的數(shù)據(jù)元素。本元素是用來描述為調(diào)用服務所需的合適入口點地址的文本字段。它可以是URL、e-mail地址，或者是一個電話號碼。在對于該Web 服務的技術要求有所了解之前，不應當對該文本欄中出現(xiàn)的信息有任何的理解假設。 string w/attributes 255 hostingRedirector 如果沒有提供accessPoint元素，那么本元素是必須的。這個字段是一個可重定向到另一個bindingTemplate的引用。如果你查詢一個bindingTemplate并且在其中找到一個hostingRedirector的值，你就應該獲取這個重定向的bindingTemplate，并且將該bindingTemplate取代原先那個包含hostingRedirector的bindingTemplate。 empty w/attributes tModelInstanceDetails 本結(jié)構是一個tModelInstanceInfo的列表。這些信息的全體形成了一個可區(qū)別的技術指紋，可用于標識兼容的服務(具有相同技術指紋的可認為是兼容服務)。 structure

accessPoint和hostingRedirector子元素應當必須出現(xiàn)一種，并且僅能出現(xiàn)一種。

名為tModelInstanceDetails 的結(jié)構的內(nèi)容可以在bindingTemplate結(jié)構中被發(fā)現(xiàn)同時是作為技術指紋服務于服務描述的。這一技術指紋是一系列對可唯一標識的規(guī)范和/或概念的引用。為了實現(xiàn)一個與某個tModel兼容的新的服務，該tModel所對應的規(guī)范是必須被正確理解的。而為了注冊一個服務并聲明它是與某個規(guī)范相兼容的，那么應當在該服務下的bindingTemplate實例中的tModelInstanceDetails下包含一個對該規(guī)范的tModel的引用，引用的鍵值是tModelKey。

accessPoint

accessPoint元素是一個由屬性修飾的指向服務入口點的指針。在這里表示的元數(shù)據(jù)層次的服務概念是相當抽象的，同時在這里出現(xiàn)很多服務入口點的類型都是合適的。

一個名為URLType的屬性被提供用于修飾accessPoint元素。設置該屬性的目的是為了查找匹配指定服務入口點類型的那些特定服務入口點。例如，一個采購訂單服務提供了3個入口點，一個是基于HTTP，一個是基于SMTP的，還有一個是基于FAX的。在這個例子中，我們就可以去查找一個businessService元素，該元素包含有個3個bindingTemplate條目，每一個都包含相同的數(shù)據(jù)，除了accessPoint的值及其附帶的URLType的值是不同的。

URLType的有效值包括:

mailto: 表明accessPoint的內(nèi)容字符串是電子郵件的格式。(例如，mailto:program@uddi-china.org)

http: 表明accessPoint的內(nèi)容字符串是一個兼容HTTP規(guī)范的URL(統(tǒng)一資源定位符)的格式。(例如，http://www.fabrikam.com/purchasing)

https: 表明accessPoint的內(nèi)容字符串是一個兼容安全HTTP規(guī)范的URL(統(tǒng)一資源定位符)的格式。(例如，https://www.fabrikam.com/purchasing)

ftp: 表明accessPoint的內(nèi)容字符串是一個可寫的FTP目錄地址的格式。 (例如，ftp://ftp.dealeasy.com/public)

fax: 表明accessPoint的內(nèi)容字符串是一個可連入某個傳真機的電話號碼的格式。(例如，1 425 555 5555)

phone: 表明accessPoint的內(nèi)容字符串是一個可與某人聯(lián)系或與某個語音/音頻響應系統(tǒng)相關聯(lián)的電話號碼的格式。 (例如，1 425 555 5555)

other: 表明accessPoint的內(nèi)容字符串是其他的尋址格式。當使用該值時，一個或多個在tModelInstanceInfo聚集中的tModel必須蘊含一個必需的特定格式或傳輸類型。

hostingRedirector

hostingRedirector元素被用來表明這個bindingTemplate條目是一個指向另外一個bindingTemplate的指針。當一個商業(yè)實體想發(fā)布一個服務描述(例如，宣布他們有一個特定用途的服務已經(jīng)可用了)，而這個服務已經(jīng)在另一個獨立的bindingTemplate中被描述了，此時就會使用這種機制。該情況可能發(fā)生于，當服務是部署在遠端主機上的(這也是本元素名字的由來)，或是當很多的服務描述可以基于一個單一的服務描述。

hostingRedirector元素只有一個單一的屬性而沒有元素的內(nèi)容。這個屬性是一個bindingKey值(UUID)，這個bindingKey值可以用于在同一個UDDI注冊中心實例中查詢和獲取將要被使用的bindingDetail數(shù)據(jù)。

關于hostingRedirector元素的使用，我們將在后面詳細給出。

tModelInstanceDetails

這個結(jié)構是一個或多個tModelInstanceInfo結(jié)構的簡單容器。當以一個信息組的形式被使用的時候，在tModelInstanceDetails結(jié)構中描述的數(shù)據(jù)就形成一個描述性的技術指紋，這個技術指紋是通過在這個結(jié)構中包含了一個無順序的tModelKey引用的列表而表現(xiàn)的。也就是說，如果有用戶注冊了一個bindingTemplate(在一個businessEntity數(shù)據(jù)集內(nèi))，那么它就會包含一個或多個對于特定的并且是可標識的規(guī)范的引用，這些規(guī)范是在注冊過程中通過tModelKey值所蘊含的。在對于一個服務的查詢過程中，有興趣的用戶會利用這些信息來尋找一個特定的包含有一個甚至多個指定的tModel引用的bindingTemplate。如果通過這個方式來注冊特定的技術指紋，那么軟件開發(fā)人員就能夠很容易地以這種方式表示出他們所提供的服務能夠與tModelKey所蘊含的規(guī)范相兼容。

基于bindingTemplate的服務調(diào)用模式

當我們需要編制實現(xiàn)一個應用程序：這個應用程序需要使用一個已被其它商業(yè)實體注冊在UDDI注冊中心的遠端Web服務，那么你需要從注冊中心中發(fā)現(xiàn)為調(diào)用指定服務所需要的調(diào)用規(guī)范信息，并在程序編制時使用。這種類型的跨商業(yè)實體的服務調(diào)用在傳統(tǒng)上將被視為是開發(fā)階段的任務。盡管，這樣的開發(fā)模式并不會因UDDI注冊信息的出現(xiàn)而完全改變，但起碼，如果使用了UDDI注冊所支持的特別的調(diào)用模式，將可以解決一個非常顯著而重要的問題。

從UDDI注冊中心中獲得的bindingTemplate信息集中的數(shù)據(jù)表示了一個指定的遠端Web服務的調(diào)用規(guī)范實例。程序應當緩存該信息并且使用這個調(diào)用規(guī)范通過該Web服務注冊的地址來訪問這個Web服務。使用以前流行的遠程過程調(diào)用技術的工具已經(jīng)能夠?qū)⑦@樣一種工作自動化地實現(xiàn)，無論是通過緩存其調(diào)用位置或是通過寫入固定代碼的方式，都可以做到。然而，當遠程服務在沒有通知調(diào)用者的情形下發(fā)生了遷移，那么就會引起問題，該程序無法自動地更新訪問代碼或訪問地址。這樣的遷移可以是由各種原因造成的，包括服務器升級，災難恢復以及服務入口或企業(yè)名稱的改變等。

當使用從UDDI注冊表中獲得并緩存下來的信息進行調(diào)用發(fā)生失敗時，正確的做法是去查詢當初獲得該數(shù)據(jù)的UDDI注冊中心并獲取與其對應的更新了的bindingTemplate信息。正確的調(diào)用是使用get_bindingDetails，并傳入原始的bindingKey鍵值。如果返回的數(shù)據(jù)與緩存的信息不同，那么應該使用新的調(diào)用信息來重新嘗試服務調(diào)用。如果這一重試操作獲得成功的話，新的信息應當取代原先緩存的信息進入當前的緩存。

在使用Web服務中，使用這樣的調(diào)用模式，那么使用UDDI操作入口站點(Operator Site)的商業(yè)實體就得以在不加重通信與協(xié)調(diào)開銷的情況下自動完成與大量合作伙伴的服務恢復。例如，如果一個企業(yè)激活了一個災難恢復站點以取代某個崩潰的原服務提供站點，來自合作伙伴的大部分調(diào)用想訪問那個已經(jīng)崩潰的服務提供站點時，會遭遇失敗。通過把新的提供服務的地址更新到UDDI信息中，那些使用調(diào)用模式的合作者將可以自動地獲取新的服務調(diào)用信息并在無需管理員介入的情況下恢復系統(tǒng)連接。

這一過程的詳細程序式描述如下：

服務提供者使用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)用。

服務重定向

在許多情況下，在get_bindingDetail消息中定義的API是直接的。當一個企業(yè)或應用程序知道需要調(diào)用的服務時，該服務相關的bindingTemplate信息就可以被緩存以供使用。如果緩存信息在真正需要被調(diào)用時發(fā)生失敗的話(比如被緩存的bindingTemplate結(jié)構的accessPoint信息被用于調(diào)用一個遠程的合作伙伴所提供的服務)，該應用可以通過被緩存的信息中的bindingKey來得到一個bindingTemplate信息的最新副本。這種緩存操作可以避免多余的對注冊中心的訪問。

然而在一些情況下，通過get_bindingDetail消息獲得的bindingTemplate所描述的信息并非是直接的某個Web服務的綁定信息，在這個bindingTemplate中可能通過hostingRedirector機制指向了另一個bindingTemplate，而由這個bindingTemplate完成對目標服務的最終描述。這就是間接描述的使用方式。

需要使用hostingRedirector的特殊情況

兩種不能被bindingTemplate中accessPoint信息直接支持的特殊需求是：

Web服務在技術上由第三方提供主機：一個企業(yè)可以選擇這樣一種方式來發(fā)布一種服務，該服務邏輯上屬于本企業(yè)，但實際上該服務是在遠程的或者第三方的主機上運行的(比如ASP模式的企業(yè)應用)。應用服務提供商和網(wǎng)絡交易市場運營商是這種情況的典型代表。在這種情況下，實際上是作為第三方的應用服務提供商和網(wǎng)絡交易市場運營商實際上控制了綁定信息bindingTemplate的運行時態(tài)的取值。

由用戶指定的對綁定位置的訪問控制：在其他情況中，比如與調(diào)用上下文相關的重定向是基于調(diào)用者的用戶標識的(比如具備某種權限的用戶被重定向入一個管理入口，而其他用戶被重定向入一個普通入口)，或者甚至是每天的路由，此時，提供更動態(tài)的對遠程服務的實際聯(lián)絡信息的方式是非常必需的，相比起緩存accessPoint數(shù)據(jù)以支持調(diào)用的方式更為必要。

由于這些原因，bindingTemplate結(jié)構包括了另一個數(shù)據(jù)元素，被稱為hostingRedirector。hostingRedirector元素的存在表明了調(diào)用者如果需要調(diào)用由指定bindingTemplate所表示的Web服務時必須使用一個額外的步驟去獲得accessPoint信息(即，調(diào)用地址)。當在解析一個hostingRedirector引用時，需要經(jīng)過兩個步驟。

使用hostingRedirector數(shù)據(jù)

當一個包含hostingRedirector元素的、同時表示了一個服務入口(稱為服務綁定)的bindingTemplate被UDDI注冊中心返回時，程序員可以使用該信息來定位實際的描述站點服務的bindingTemplate，這個實際的描述站點服務的bindingTemplate包含了描述真正提供服務的主機的相關的accessPoint信息。

一般的，hostingRedirector元素的內(nèi)容包括一個bindingKey，該鍵引用了另一個bindingTemplate。這個包含在hostingRedirector元素中的、引用了在同一個UDDI注冊中心中的另一個bindingTemplate的可解析的bindingKey是在最初的get_bindingDetail消息返回的。

在訪問這第二個綁定信息(稱為間接綁定)之后，調(diào)用者就可以完全著眼于這個間接綁定的技術指紋。如果這個間接綁定的技術指紋與服務綁定的技術指紋是一樣的，那么這個間接綁定中的accessPoint就可以用來與最終的Web服務交互。hostingRedirector的這種使用方式稱為簡單間接模式(simple indirection)。如果，這個間接綁定的技術指紋表明這個間接綁定是實現(xiàn)了一個hostingRedirector服務，那么需要再一次使用get_bindingDetail消息，這個消息被發(fā)往在這個間接綁定信息中包含的accessPoint所指明的地址，以獲得真正的服務綁定信息。hostingRedirector的這種使用方式稱為重定向模式(redirection)。

在簡單間接模式中，描述最終服務的bindingTemplate將簡單地被初始的服務綁定所引用。在這種場合下，并沒有復雜的邏輯。(參見下圖)

Figure 1. 簡單間接模式示意

而對于重定向模式，以下的具體描述表述了重定向使用的步驟：

一個商業(yè)實體為一個寄宿于遠程站點或需重定向的商業(yè)服務S注冊了一個bindingTemplate A。這個bindingTemplate包括一個bindingKey值Q來引用另外一個bindingTemplate B。這個bindingTemplate B典型地由提供重定向服務的組織來控制。這個bindingTemplate B包含了指向?qū)嶋H上的hostingResirector服務R的accessPoint元素。

應用程序需要調(diào)用步驟一中注冊的服務S，首先需要得到公布的服務的綁定信息。這個bindingTemplate信息包含了一個hostingRedirector元素，該元素同時包含了對應于bindingTemplate B的bindingKey值K。

程序員使用bindingKey值K對原始bindingTemplate A所在的UDDI注冊中心發(fā)送get_bindingDetail消息。這樣就能得到返回的bindingTemplate B?，F(xiàn)在程序員就能得到實現(xiàn)重定向的服務的地址。這個信息就是在bindingTemplate B中所能找到的accessPoint元素。該服務知道如何響應get_bindingDetail消息。

使用最初的bindingKey值Q，并發(fā)送一個get_bindingDetail消息到重定向服務R。這個服務負責返回被重定向的商務服務S的實際綁定信息或者返回一個錯誤信息。如果需要，程序員可以選擇緩存這個bindingTemplate。

使用上述這個算法，一個為其他企業(yè)提供主機服務的機構可以控制實際訪問該服務的信息。這不僅可以幫助提供主機服務的組織對各種情況實施有效管理，比如災難恢復，而且可以讓他們定義訪問實際上被調(diào)用的商務服務所使用的URL。這個URL可以由調(diào)用者來指定，也可以是一個宿主機或重定向服務的通用地址。(參見下圖)

Figure 2. 重定向模式示意

使用重定向服務的意義就在于那些提供ASP或者在線交易市場服務的服務提供商能夠動態(tài)地使用自身的重定向服務來決定某一企業(yè)的應用的入口，這對于使用動態(tài)路由的網(wǎng)絡應用環(huán)境或是動態(tài)的企業(yè)應用解決方案的服務提供商來說，是至關重要的。

在任何情況下，原始的調(diào)用者可以在不知道任何重定向存在的情況下，找到實際商業(yè)伙伴所發(fā)布的Web服務(通過bindingTemplate)，并通過該服務找到實際商業(yè)伙伴的數(shù)據(jù)。

小結(jié)

本文通過介紹UDDI數(shù)據(jù)模型中的bindingTemplate數(shù)據(jù)實體，對如果使用bindingTemplate中的信息實施Web服務調(diào)用進行了討論，闡明了利用緩存bindingTemplate加速服務多次調(diào)用的方法，也介紹了在災難恢復的情況下如何再次緩存的方法。同時通過對hostingRedirector的功能的分析，介紹了簡單間接模式和重定向模式對于非直接提供服務，而是由ASP供應商提供服務這一模式的重要性。