監(jiān)理公司管理系統(tǒng) | 工程企業(yè)管理系統(tǒng) | OA系統(tǒng) | ERP系統(tǒng) | 造價(jià)咨詢管理系統(tǒng) | 工程設(shè)計(jì)管理系統(tǒng) | 甲方項(xiàng)目管理系統(tǒng) | 簽約案例 | 客戶案例 | 在線試用
X 關(guān)閉

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

申請免費(fèi)試用、咨詢電話:400-8352-114

AMTeam.org

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




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

Chief System Architect

2001年11月22日

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

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

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

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

bindingTemplate結(jié)構(gòu)規(guī)范














下層子結(jié)構(gòu)說明

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

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


accessPoint和hostingRedirector子元素應(yīng)當(dāng)必須出現(xiàn)一種,并且僅能出現(xiàn)一種。

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

accessPoint

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

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

URLType的有效值包括:

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

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

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

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

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

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

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

hostingRedirector

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

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

關(guān)于hostingRedirector元素的使用,我們將在后面詳細(xì)給出。

tModelInstanceDetails

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

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

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

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

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

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

這一過程的詳細(xì)程序式描述如下:

服務(wù)提供者使用save_xx在UDDI注冊中心中注冊了Web服務(wù)S;

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

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

調(diào)用者緩存服務(wù)S的bindingTemplate信息,通過服務(wù)綁定,實(shí)施對服務(wù)S的調(diào)用;

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

服務(wù)提供者在新的位置重新部署了服務(wù)S,同時(shí)更新了UDDI注冊中心的關(guān)于Web服務(wù)S的技術(shù)描述;

調(diào)用者使用緩存的服務(wù)S的bindingTemplate信息再一次進(jìn)行調(diào)用,調(diào)用失??;(服務(wù)S的部署位置已經(jīng)更改)

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

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

服務(wù)重定向

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

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

需要使用hostingRedirector的特殊情況

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

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

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

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

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

當(dāng)一個(gè)包含hostingRedirector元素的、同時(shí)表示了一個(gè)服務(wù)入口(稱為服務(wù)綁定)的bindingTemplate被UDDI注冊中心返回時(shí),程序員可以使用該信息來定位實(shí)際的描述站點(diǎn)服務(wù)的bindingTemplate,這個(gè)實(shí)際的描述站點(diǎn)服務(wù)的bindingTemplate包含了描述真正提供服務(wù)的主機(jī)的相關(guān)的accessPoint信息。

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

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

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

Figure 1. 簡單間接模式示意


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

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

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

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

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

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

Figure 2. 重定向模式示意

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

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

小結(jié)

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

參考資料

  • UDDI執(zhí)行白皮書, UDDI-China.org, UDDI.org
  • UDDI技術(shù)白皮書, UDDI-China.org, UDDI.org
  • UDDI程序員API規(guī)范 v2.0, UDDI-China.org, UDDI.org
  • UDDI數(shù)據(jù)結(jié)構(gòu)參考 v2.0, UDDI-China.org, UDDI.org
  • UDDI程序員API規(guī)范 v1.0, UDDI-China.org, UDDI.org
  • UDDI數(shù)據(jù)結(jié)構(gòu)參考 v1.0, UDDI-China.org, UDDI.org
  • Microsoft UDDI Resource Center & UDDI Operator, Microsoft Cooperation
  • Web Service and UDDI, IBM
  • SOAP Version 1.2 中文版, W3C Working Draft 9 July 2001/UDDI-China Translation

作者簡介

柴曉路: 系統(tǒng)架構(gòu)師, Web Service技術(shù)顧問, UDDI Advisor Group成員, UDDI規(guī)范中文版編輯。專長于Web Service架構(gòu)、Web Service系列技術(shù)以及基于XML的系統(tǒng)集成和數(shù)據(jù)交換技術(shù),同時(shí)對數(shù)據(jù)庫、面向?qū)ο蠹夹g(shù)及CSCW等技術(shù)比較擅長。2001年加入UDDI Advisor Group,參與了UDDI Specification V2的開發(fā)。目前作為UDDI-China.org的主要核心成員參與UDDI-China.org的核心技術(shù)工作。2000年獲復(fù)旦大學(xué)計(jì)算機(jī)科學(xué)碩士學(xué)位,曾在國際計(jì)算機(jī)科學(xué)學(xué)術(shù)會議(ICSC)、亞太區(qū)XML技術(shù)研討會(XML Asia/Pacific'99)、中國XML技術(shù)研討會(北京)、計(jì)算機(jī)科學(xué)期刊等各類國際、國內(nèi)重要會議與期刊上發(fā)表論文多篇。

發(fā)布:2007-03-25 13:25    編輯:泛普軟件 · xiaona    [打印此頁]    [關(guān)閉]
相關(guān)文章:
石家莊OA系統(tǒng)
聯(lián)系方式

成都公司:成都市成華區(qū)建設(shè)南路160號1層9號

重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓

咨詢:400-8352-114

加微信,免費(fèi)獲取試用系統(tǒng)

QQ在線咨詢