理解UDDI(3):bindingTemplate與Web服務調用（下）

MILY: 黑體; mso-ascii-font-family: 'Arial Black'">(本文是我在developerWorks專欄發表的bindingTemplate與Web服務調用
的縮減版，需要瀏覽未縮減版原文，請訪問http://www.ibm.com/developerWorks/cn/)

基于bindingTemplate的調用模式

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

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

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

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

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

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

2.    調用者使用find_xx查詢UDDI注冊中心，獲得所需的服務S的概要信息；

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

4.    調用者緩存服務S的bindingTemplate信息，通過服務綁定，實施對服務S的調用；

5.    服務S由于某種原因出現問題，無法繼續提供服務；

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

7.    調用者使用緩存的服務S的bindingTemplate信息再一次進行調用，調用失??；(服務S的部署位置已經更改)

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

9.    調用者緩存服務S的新的bindingTemplate信息，通過服務綁定，重新實施對服務S的調用。

服務重定向

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

需要使用hostingRedirector的特殊情況

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

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

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

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