專利名稱：在面向服務的體系結構中選擇服務綁定協(xié)議的方法和裝置的制作方法
技術領域：
本發(fā)明涉及一種在面向服務的體系結構中選擇服務綁定協(xié)議的方法和裝置，在該服務體系結構中，客戶使用選定的傳輸綁定從服務提供者調用服務。更具體地說，本發(fā)明涉及一種通過協(xié)商和診斷來選擇這種服務綁定協(xié)議的方法和裝置。
背景技術：
本說明書中(使用帶方括號的標號)參考了以下出版物，這些出版物可以通過印刷形式或在線的形式獲取，現于此引入以作參考1. W3C Note，“Web Services Description Language(WSDL)1.1”，2001.3.152.Ueli Wahli等人，Websphere Version 5 Web ServicesHandbook，IBM Redbook，SG24-6891-00，2003.
3.W3C Working Draft，“SOAP Version 1.2 Part 0Primer”，2002.6.264.W3C Working Draft，“SOAP Version 1.2 Part 1MessagingFramework”，2002.6.265.W3C Working Draft，“SOAP Version 1.2 Part 2Adjuncts”，2002.6.266.Aaron Skonnard，“Understanding SOAP”，MSDN Library，2003.37.W3C Recommendation，“Extensible Makeup Language(XML)1.0(Second Edition)”，2000.10.6
8.Peter Flynn(ed.)，“The XML FAQ v.3.01”，2003.1.149.Sun Microsystems，Inc.，“Java API for XML-BasedRPC(JAX-RPC)”，2003.8.2810.Ian Foster等人，“The Physiology of the GridAn OpenGrid Services Architecture for Distributed SystemsIntegration”2002.6.2211.Steve Tuecke等人，“Grid Service Specification”，Draft 3，2002.7.1712.W3C Note，“SOAP Messages with Attachments”，2000.12.11最近幾年來，在信息技術領域中眾多重要事件之一就是Web服務及其近親網格服務的規(guī)范及其實現的發(fā)展。正如文獻[2]第7頁中所描述的，“Web服務是一些可以通過網絡描述、發(fā)布、定位以及調用的自含式(self-contained)、模塊化的應用。Web服務執(zhí)行封裝的業(yè)務功能，其范圍可以從簡單的請求-響應到整個業(yè)務處理的交互”。Web服務已經被編纂為諸如Web服務描述語言(WSDL)[1]這樣的標準規(guī)范。網格服務[10，11]已經被定義為符合一套定義客戶如何與網格服務交互的約定(接口和行為)的Web服務。網格服務已經被用來創(chuàng)建虛擬組織(VO)，在該組織中，實際上遠程的可利用的計算資源(應用程序，處理器等)在用戶看來就像是本地的資源。
在一個面向服務的體系結構如Web服務中，服務提供者可以提供若干用于綁定的傳輸協(xié)議以便訪問一項服務。這樣做是為了向客戶提供更好的服務質量(QOS)特性。這種綁定的一個例子是服務的傳輸綁定使用IIOP代替SOAP/HTTP以獲得更好的性能(關于這些及其他縮寫見下面附錄中的術語表)。服務提供者在部署一項服務時在一個WSDL文檔中定義該綁定信息，并啟動服務器端框架(樁模塊(stub)/JMS監(jiān)聽程序等)以支持這些綁定。創(chuàng)建服務骨架(skeleton)來以特定于綁定的方式處理進入的請求并把該進入的請求轉化成特定于平臺的服務調用模型?？捎腥舾山壎▍f(xié)議模型(SOAP/HTTP，IPC，IIOP，RMI，SOAP/JMS等)能夠基于例如性能、互用性、服務容器能力以及QOS需求等標準而被創(chuàng)建。使用服務的客戶可以從一些注冊表(UDDI)或服務本身(通過HTTP GET)來獲取用于服務的WSDL文檔并對WSDL文檔進行評估?？蛻艨梢陨伸o態(tài)樁模塊或為服務調用動態(tài)地內省(introspect)WSDL文檔。這就導致了一個客戶有若干傳輸協(xié)議綁定信息代理，而客戶需要從這些代理中選擇出一個來調用服務。
圖1的概念圖示出客戶102、服務104(這里也稱為“服務提供者”)、各種綁定106、以及一個WSDL文檔108之間的關系。正如圖中所示，客戶102使用WSDL文檔108生成一項服務綁定106，而后客戶102使用生成的綁定106調用服務104(通過發(fā)出一項服務請求)。轉過來，服務104也使用選定的綁定106。
如圖1所示，現在客戶面臨的一個主要問題是選擇哪一項綁定來達到需要的QOS特性。服務提供者假定客戶能夠基于其在例如性能及吞吐量、平臺能力及配置等QOS需求的需要對選擇協(xié)議綁定做出明智的決定。如今，該方法可以通過WSDL擴展以及綁定排序提供一些靜態(tài)信息模型以及綁定選擇優(yōu)選項。但是這對于客戶在綁定選擇時做出明智的決定是不夠的。
當前正在努力為客戶提供服務協(xié)議綁定方面的更加詳細的信息模型。這樣客戶可以基于以下幾點來選擇綁定(1)WSDL綁定擴展性信息以及綁定選擇策略(服務等級協(xié)議及策略)；(2)客戶配置以及部署策略，包括靜態(tài)部署選項和服務等級協(xié)議(SLA)需求，以及動態(tài)策略和SLA需求(編程模型配置、策略等等)；(3)通過用于RDF的WSDL擴展的與客戶關聯的機器可解釋的語義信息；以及(4)自動施加的綁定規(guī)則，例如綁定順序。另外地或可替代地，可以通過諸如由服務提供的部署策略(例如，僅在某一特定時間點遭受某些綁定)等服務提供者策略或者使一個服務器通過SLA、UDDI等提供策略，來實現這一點。
然而，這些努力僅僅是對現存的WSDL描述及編程模型進行的擴展，而沒有通過一個動態(tài)握手(協(xié)商)過程在運行時為客戶解決動態(tài)配置需求。類似地，WSIF(Web服務調用框架)是一個被提供用來根據來自WSDL文件的靜態(tài)信息在客戶端創(chuàng)建多綁定通道的框架。
與此同時，上面提到的解決方法存在幾個問題。它們需要關于客戶端和服務器端的傳輸綁定選擇的預先知識。大多數QOS需求必須事先知道并需要在服務調用前進行配置。它們在性質上是非常靜態(tài)的，幾乎沒有靈活性?；诓煌姆仗峁┱叩男枨螅鼈円蕾囉谌舾傻墓ぞ摺Ｋ鼈冎С种薪?intermediary)的能力非常有限，它們針對某一特定QOS需求動態(tài)改變一個綁定的能力也同樣如此。最后，它們不能與服務器就傳輸綁定選擇進行會話以達到更好的QOS控制。
所以，需要的是一種用于動態(tài)選擇傳輸綁定的機制。

發(fā)明內容
總的來說，本發(fā)明構想的是一種在面向服務的體系結構中調用服務的方法和裝置，在該體系結構中，客戶使用一項選擇的服務綁定從服務提供者調用這種服務。首先使用第一傳輸綁定在協(xié)商過程中協(xié)商一個用于來自服務提供者的服務調用的服務綁定。然后使用在協(xié)商過程中已協(xié)商的服務綁定處理該服務調用。
客戶可以首先決定服務器是否能夠協(xié)商一項服務綁定，比如說通過“砰”(ping)服務器。如果服務器能夠協(xié)商一項服務綁定，則客戶將與服務器協(xié)商一個服務綁定。否則，根據客戶可獲得的不與服務器協(xié)商的信息(比如診斷信息)來選擇一項服務綁定。
或是通過客戶與服務提供者，或是通過通信路徑中的中介，對于一條通信路徑的每個不同的部分可協(xié)商選擇單獨的服務綁定。
本發(fā)明因而構想了在客戶與服務之間的一種握手協(xié)議，用于在面向服務的體系結構中在運行時選擇一項恰當的傳輸綁定，以便獲得更好的性能和吞吐量?？蛻敉ㄟ^使用本發(fā)明的協(xié)商協(xié)議與服務器協(xié)商，可以達到希望的QOS需求。當協(xié)商協(xié)議不被支持時，客戶使用診斷基準測試工具，通過某一診斷決策過程可以達到希望的QOS需求。
本發(fā)明沒有處理特定于服務的綁定需求以獲得某些QOS特性。這包括綁定尋址方案、消息格式、編碼、消息類型(DOC/RPC)、調用模型以及其他特定于綁定的QOS(相關性、事務處理以及安全性等等)。另外，本發(fā)明對綁定的使用沒有施加計劃性的規(guī)定?？蛻舳丝蚣苓x擇這些綁定，并且客戶獨立于該綁定選擇。一種實現可以是WSIF框架(為Web服務提供若干綁定)，其可以與一個JAX-RPC處理程序(綁定選擇器)一起用于Web服務綁定選擇。
雖然本發(fā)明用軟件實現比較好，但用硬件，軟件或者二者的某種結合也都可以實現。當用軟件實現時，它可以采取可被機器讀取的程序存儲裝置(比如磁盤、光盤或者半導體存儲器)的形式，該程序存儲裝置有形地體現可由機器執(zhí)行以完成所定義的方法步驟的指令程序。


圖1的概念圖示出了客戶、服務、各種綁定以及WSDL文檔之間的關系。
圖2示出了客戶使用不同綁定調用兩項服務的情形。
圖3示出了使用定制的綁定協(xié)議時客戶與網關交互及網關與服務交互的情形。
圖4示出了一種在一個協(xié)商過程中涉及中介的特殊情況。
圖5A示出了通過協(xié)商選擇服務綁定。
圖5B示出了通過診斷選擇服務綁定。
圖6示出了一個傳輸綁定協(xié)商協(xié)議框架。
圖7示出了使用IIOP綁定的傳輸綁定協(xié)商協(xié)議框架。
圖8示出了一個尋找最合適傳輸綁定的服務器診斷過程。
圖9示出了一個用于一個WSDL端口類型的傳輸綁定選擇過程。
具體實施例方式
在詳細論述優(yōu)選實施例之前，作為預備，先描述幾種可能的網絡拓撲。
在上述簡要說明中，假定客戶和服務提供者相互直接通信，而沒有任何的中介，并且在整個通信路徑中僅使用一種服務綁定。然而，在實際的實現中，可能為通信路徑中的不同部分協(xié)商不同的服務綁定，并且在協(xié)商過程中，可能會主動地或被動地涉及中介。在下面所述的使用例子的情形中，作如下假定1.服務提供者可以使用用于HTTP、JMS、IIOP的協(xié)議綁定將服務部署在容器中。
2.如果不需要進行可靠消息傳送，則客戶可以通過HTTP綁定使用該服務。
3.如果需要進行可靠消息傳送，則客戶可以通過JMS綁定使用該服務。
4.如果客戶與該服務被部署在同一容器中，則可以使用IIOP以獲得最佳性能。
客戶可以直接參與到與服務器(服務提供者)的協(xié)商中，以選擇適當的傳輸綁定。一旦選擇了傳輸綁定，客戶將使用它進行下一層的通信。圖2示出了第一種情形(使用例子1)，在該情形中，客戶102使用用于服務調用的不同的綁定(IIOP和SOAP/HTTP)調用兩個不同的服務104(服務A和B)。更具體地說，對于服務104中的每一個服務，客戶102首先在協(xié)商過程中(圖中每對鏈接中的上側鏈接)使用第一個、非協(xié)商的用于協(xié)商過程的傳輸綁定來協(xié)商一個服務綁定。在所示的例子中，用于協(xié)商過程的傳輸綁定是SOAP/HTTP。但本發(fā)明并不僅局限于這種綁定，而可以使用其它綁定來代替這個綁定。協(xié)商可以集中于服務質量(QOS)特性方面，或者協(xié)商方所感興趣的、傳輸綁定的任何其它方面。
在協(xié)商用于一特定的服務提供者104的傳輸綁定后，客戶102就在服務調用(圖中每對鏈接的下側鏈接)中使用所協(xié)商的傳輸綁定從服務提供者處調用一個服務。在該特定例子中，客戶102與服務A協(xié)商了IIOP傳輸綁定并且與服務B協(xié)商了SOAP/HTTP綁定。注意對于服務B，服務調用所使用的傳輸綁定(SOAP/HTTP)和協(xié)商過程中所使用的相同。不過，通常協(xié)商過程使用的綁定與服務調用所使用的綁定之間沒有關系(除了它們是被協(xié)商過程和服務調用的參與方所支持之外)。
在各圖中，客戶102可能只是客戶機上多個這樣的客戶(或稱“服務請求者”)中的一個，圖中不將它們分別示出。類似地，服務提供者104可能只是服務器機器(或稱“服務器”)上多個這樣的服務提供者中的一個。除了如這里描述的以外，客戶102和服務提供者104的運行的細節(jié)不屬于本發(fā)明的部分，因此沒有示出。同樣地，客戶102和服務提供者104所駐留的機器的運行的細節(jié)不屬于本發(fā)明的部分，因此這些機器也沒有被分別示出。類似地，除了能夠支持此處描述的協(xié)議外，連接客戶102和服務提供者104的網絡的運行的細節(jié)不屬于本發(fā)明的部分，因此沒有被描述。
在前面的情形中，特定協(xié)商過程的參與方是客戶和服務提供者，雙方之間直接打交道。圖3示出了第二個情形(使用例子2)，其中通過使用單獨的綁定協(xié)議，客戶102與網關302交互，而網關302與相應的服務104交互。在圖3示出的情形中，與前面相同，SOAP/HTTP綁定用于各協(xié)商過程。但是，對于來自服務A的服務調用，SOAP/HTTP綁定被用于客戶102和網關302之間的通信路徑，而IIOP綁定被用于網關302和服務104之間的通信路徑。類似地，對于來自服務B的服務調用，SOAP/HTTP綁定被用于客戶102和網關302之間的通信路徑，而JMS綁定被用于網關302和服務104之間的通信路徑。
在圖3示出的情形中，網關302可以參與到與服務提供者104之間的協(xié)商中，以選擇適當的傳輸綁定。一旦傳輸綁定被選擇，網關302將該綁定應用于與服務104的下一層通信，服務調用?？蛻?02也可以參與到該綁定協(xié)商過程中，并可以對一特定的綁定選擇和協(xié)商過程表示它的興趣。而且，通過本發(fā)明的協(xié)商協(xié)議，在運行時，客戶102還可以使用它的QOS需求通過綁定選擇來影響網關302。
在圖3的情形中，客戶102和服務104可以為它們之間的通信路徑的每一路徑段協(xié)商一個傳輸綁定，而網關302擔當協(xié)商的代理?；蛘撸W關302可以作為委托人(principal)并為它自己協(xié)商與客戶102以及服務104之間的綁定。換句話說，在客戶102和一個特定的服務104之間，可以有一個(在客戶和服務之間的)或兩個(在客戶和網關之間以及網關和服務之間的)協(xié)商過程。二者中的每個選擇都是可能的，這取決于網關的功能性(即，取決于它是一個智能代理還是一個簡單的代理)。
圖4進一步示出了第三個情形，這一特別的例子在協(xié)商過程中涉及了中介(就“中介”和“網關”的區(qū)別來說，與中介相比，網關通常有更多的功能性-如消息處理、調度和路由選擇，而中介通常是通向目的地的消息路由器)。這可以通過本發(fā)明的傳輸綁定選擇協(xié)議連同相關的路由選擇協(xié)議來完成。一旦協(xié)商完成，即可以使用不同的綁定通道選擇經由中介的合適的綁定協(xié)議。更具體地說，在圖4示出的情形中，客戶102和服務104通過客戶102和服務104之間的通信路徑中的第一和第二中介402和404進行通信。雖然在該例中顯示的是兩種中介402和404，但可以包含更多的中介或僅包含一種中介。
在圖4示出的情形中，每對相鄰的節(jié)點進入一個單獨的協(xié)商過程，并為如前所述的目的使用SOAP/HTTP綁定。但是，對于實際的服務調用，在特定的一對節(jié)點中使用的傳輸綁定依賴于這兩個節(jié)點間協(xié)商的結果。因而，在圖4的示例中，服務調用在客戶102和第一中介402之間使用SOAP/HTTP傳輸綁定，而在第一中介402和第二中介404之間使用IIOP綁定，以及在第二中介404和服務104之間使用JMS綁定。
本發(fā)明考慮了兩種機制用于服務綁定選擇(1)通過協(xié)商的服務綁定選擇；(2)通過診斷過程的服務綁定選擇。
第一種機制是客戶和服務器之間的協(xié)商過程，它利用了一個定義的協(xié)商協(xié)議，該協(xié)議在這里也稱“通過協(xié)商的服務綁定選擇”(SBSN)協(xié)議。通常，一個定義服務的WSDL文檔會提供有關可用的傳輸綁定的必要信息，以便客戶可以與該服務進行對話。客戶會創(chuàng)建若干客戶端綁定，它可以根據需要從中選擇出最好的一個。在運行時，客戶可以啟動一個與服務器的協(xié)商過程，然后在此基礎之上，客戶可以選擇一個匹配需求的協(xié)議綁定。一旦完成該綁定選擇，就可以使用運行時的綁定協(xié)議如WSIF或其它協(xié)議與服務通信。
SOAP基于報頭的模型可以用于協(xié)商中，以允許消息經由中介發(fā)送，啟動用于協(xié)商協(xié)議的公共簡檔(profile)，并支持各種客戶和服務的實現。這種SOAP報頭可以承載關于消息呼叫的與綁定相關的信息，而服務簡檔的信息(例如，客戶/服務容器屬性，定制的用戶定義的屬性，類裝入器信息)也可以作為一個或多個附件隨SOAP消息一同承載[12]。
通過協(xié)商的服務綁定選擇是按如下方式工作的。在運行時，客戶和服務器根據它們的QOS需求以及它們的能力進入一個協(xié)商過程。這些QOS需求包括較好的性能、吞吐量和可伸縮性。圖5A示出了其基本方案?？蛻?02和服務104使用諸如SOAP/HTTP等第一傳輸綁定，進入了一個在網絡上的、相互的協(xié)商過程502，以協(xié)商一個用于來自服務提供者104的調用服務的傳輸綁定。然后，客戶102將協(xié)商的傳輸綁定(其可以與第一傳輸綁定相同或不同)應用到服務調用504，以調用來自服務提供者104的服務。
第二種機制用于服務提供者不支持傳輸綁定協(xié)商框架的情況。在這里，一個過程以基于服務器“砰”(ping)(使用可用的綁定向服務器發(fā)送抽象消息)的動態(tài)簡檔信息的收集、消息的相關性(收集錯誤消息、日志)以及基于事件相關性過程的解釋(使消息、日志以及調用時間相關)為基礎?；谠摵啓n，客戶可以作出關于綁定選擇的某些決定。
圖5B示出了通過診斷進行服務綁定選擇的一般方案。在圖5B中示出的方案與圖5A中的基本類似，與圖5A不同的是，客戶并不是與服務提供者協(xié)商服務綁定，而是通過選擇過程506來選擇綁定，該選擇過程依據的是本地可獲得的信息，例如下述類型的診斷信息。
在一個優(yōu)選實施中，為了支持在客戶和服務器之間關于服務綁定選擇的會話，提供了以下各項(1)協(xié)商協(xié)議；(2)用于綁定協(xié)商過程的在客戶和服務器二者中的綁定框架；以及(3)掛入(hook into)客戶端運行時系統(tǒng)的框架。
協(xié)商協(xié)議最好是一個基于XML的協(xié)議，它用于支持客戶和服務之間的綁定協(xié)商。在協(xié)商協(xié)議不需要使用任何特別的語言的同時，它可以具有以下幾個部分(a)一個協(xié)商動作和會話報頭；(b)協(xié)商數據；以及(c)幫助會話的簡檔。最好該協(xié)議還具有可擴展性以便支持消息擴展。協(xié)商動作可以指定一些動作，例如列出綁定、選擇綁定、使用綁定、綁定屬性列舉等。會話報頭可以包含消息的相關信息。協(xié)商數據包括用于上述動作的數據。所述簡檔用于幫助綁定選擇。這可以包括客戶/服務容器信息、用戶定義的需求以及任何其它可以幫助綁定選擇的信息。簡檔可以采用任意的數據格式，包括二進制數據。就SOAP來說，SOAP附件[12](為MIME類型附件)可以用來發(fā)送這些基于MIME的簡檔。
協(xié)商協(xié)議可以定義其經由中介的傳播和使用(如上所述)，以便綁定選擇過程對中介友好。這使得中介與協(xié)商協(xié)議能夠共同工作，以便為通信選擇所需的綁定并允許客戶和服務適度地使用綁定，例如，通過允許根據需要發(fā)送SOAP報頭和允許發(fā)送消息而不影響協(xié)商過程。
用于綁定協(xié)商過程的、客戶和服務器二者中的綁定框架能夠在運行時啟動一個綁定選擇過程，例如以SOAP消息啟動。SOAP報頭可以用來控制該會話并用來傳送包含在該會話中的簡檔。服務簡檔的附加信息(例如，客戶/服務容器屬性，定制的用戶定義的屬性以及類裝入器信息)可以作為附件(如，SOAP附件)隨消息一同被承載。所有這些會話都使用如前所述的協(xié)商協(xié)議而實現。即使在綁定選擇已經完成后，客戶和服務器也可以通過當前的綁定通道發(fā)送該協(xié)商信息并可以根據需要啟動一個新的綁定選擇過程?？梢远x一個框架來內省客戶端和服務器端的環(huán)境信息，從而在綁定選擇方面做出恰當的決定。
客戶端框架使得客戶能夠在方法調用前啟動一個與服務之間的綁定協(xié)商過程，并基于指定的生存期需求高速緩存所選擇的綁定。它使得客戶可以向服務器提供用于協(xié)商過程的必要的信息。此外，它還可以定義用于協(xié)商的簡檔、標準和規(guī)則，并使得客戶能夠根據需要重新協(xié)商綁定。
用來支持服務綁定協(xié)商協(xié)議的服務器端框架使得一個服務在服務調用前可以支持一個服務綁定協(xié)商過程。它使得服務器可以根據協(xié)商中使用的簡檔和支持數據(例如包含在SOAP附件中的)來確定客戶的QOS需求(例如包含在SOAP報頭中的)。
服務器端框架可以內省服務器以檢測QOS特性需求并找出服務運行環(huán)境的細節(jié)。服務器端框架也可以內省服務器運行時間以驗證客戶運行時環(huán)境，并內省客戶環(huán)境信息以選擇合適的綁定。例如，如果客戶和服務器都在使用相同的類裝入器，則應當使用Java綁定。
就基于Java的服務來說，掛入客戶端運行時系統(tǒng)的框架可以是一個JAX-RPC處理程序框架。這就允許客戶在進行服務調用調度之前對綁定選擇做出決定。本發(fā)明的傳輸綁定協(xié)議允許客戶端框架動態(tài)地改變綁定，從而根據客戶的配置動態(tài)地部署綁定。這一方法很靈活，并可以適應于其它的Web服務環(huán)境。一旦完成綁定選擇，該運行時框架將決定該綁定選擇的范圍。這個范圍可以是應用程序范圍(所有的服務調用)、WSDL端口類型范圍(由WSDL綁定來規(guī)定)或基于每個服務調用。而且，客戶可以通過例如定時器、簡檔等定制方法控制該綁定協(xié)商的生存期。還有一種方法也是可能的，通過該方法，服務器可以使用相同的協(xié)商協(xié)議來控制綁定的使用。
圖6和圖7示出了在本發(fā)明的一個優(yōu)選實施例中，該協(xié)商過程在運行時是怎樣進行的。如圖所示，客戶102通過在客戶端的JAX-RPC處理程序602和在服務器端的JAX-RPC處理程序(或小服務程序)604與服務104交互(雖然在本具體例子中是以JAX-RPC處理程序為例，但本發(fā)明的方法也可以應用于其它消息處理程序，尤其是SOAP處理程序)。JAX-RPC處理程序602在可以訪問策略610的綁定協(xié)商協(xié)議處理程序606的協(xié)助下處理服務綁定協(xié)商。類似地，在服務器端，JAX-RPC小服務程序604在可以訪問策略612的綁定協(xié)商協(xié)議處理程序608的協(xié)助下處理服務綁定協(xié)商。將圖6中示出的元素與以上描述的組件相聯系，綁定協(xié)商協(xié)議處理程序606和608分別構成了在客戶端和服務器端的綁定框架，并在它們之間使用所定義的協(xié)議進行服務綁定協(xié)商，而JAX-RPC處理程序602構成了用于掛入客戶端運行時系統(tǒng)的框架。
現在來看圖6，下面將講述客戶102對于一個服務操作調用啟動的兩步操作。第一步，當客戶102通過發(fā)信號通知JAX-RPC處理程序602來調用這兩步操作時，使用協(xié)商綁定協(xié)議的協(xié)商過程啟動。作為響應，JAX-RPC處理程序602啟動與服務器端的JAX-RPC小服務程序604之間的一個交換以確定它支持哪一個服務綁定。在這個具體例子中，JAX-RPC小服務程序604發(fā)回信號通知它使用的是IIOP綁定(如果JAX-RPC604標識了若干綁定，則JAX-RPC處理程序602將根據一個或多個標準選擇一個綁定，并且可選地，根據具體協(xié)議，向服務器端發(fā)回信號通知它的選擇)。
現在來看圖7，第二步是實際的服務調用，JAX-RPC602處理程序使用所協(xié)商的綁定(此處為IIOP)調用服務104，在調用服務104時，JAX-RPC處理程序602使用例如在參考[2]的89-99頁中所述類型的Web服務調用框架(WSIF)614與服務104直接通信。
如上所述，有些情況可能是其中并沒有可以支持用于綁定選擇的協(xié)商過程的服務器端框架。在這類情況中，客戶或客戶管理員可以根據其需求通過一個診斷過程來找出最適合的綁定(圖5B和圖8)。一個用來選擇合適的服務綁定的診斷框架可以具有用于與服務客戶運行時框架一起工作的客戶端診斷處理程序，用于收集基于服務器調試(包括日志、砰(ping)和跟蹤(trace))的詳細數據的診斷工具，以及用于處理收集到的數據以得到綁定性能和吞吐量的細節(jié)的綁定選擇協(xié)議。診斷工具可以包括用于從診斷信息中選擇服務綁定的關聯邏輯，并且還可以在綁定選擇時使用簡檔。
圖8示出了圖6和7中的實施例如何通過診斷來完成綁定選擇(第一步)。在該情形中，JAX-RPC處理程序602砰(ping)在服務器端的JAX-RPC小服務程序604并確定沒有綁定協(xié)商框架。確定這一點后，JAX-RPC處理程序602使得協(xié)議處理程序606基于策略612、服務日志和蹤跡(trace)616決定一個合適的綁定。以這種方式選擇服務綁定后，JAX-RPC處理程序602進入第二步，在這一步中，它按照圖7示出的方式工作。
該診斷過程可以非常廣泛，并可以運行于在客戶能夠決定要使用的綁定之前的整個時間段?？梢陨扇舾稍\斷工具(服務器砰(ping)、事件數據、日志/蹤跡評估器(log/trace evaluator)等)與該模型一起工作以生成所需的日志和蹤跡。該診斷過程變成客戶端服務框架的一部分并可以影響服務調用以便在運行時選擇最合適的協(xié)議綁定。就基于JAX-RPC的系統(tǒng)來說，我們定義一個診斷處理程序框架來支持這一過程。
圖9示出了用于WSDL端口類型的傳輸綁定選擇過程的高級流程圖。在進行服務調用的調用(步驟902)時，首先客戶和服務進入到一個傳輸綁定協(xié)商過程(步驟904)。根據綁定選擇策略和由協(xié)商協(xié)議定義的協(xié)議定義，客戶可以選擇具有最大的QOS能力的綁定(步驟906)。一旦完成協(xié)商，客戶就可以根據客戶需求，基于應用程序范圍、端口類型范圍或操作范圍來應用綁定選擇信息(步驟908)?，F在，綁定即可應用由WSDL綁定元素和綁定協(xié)商協(xié)議二者指定的特定于綁定的屬性910。此時，客戶已準備好使用選擇的綁定來調用操作(步驟912)。此后，客戶可以通過重復上述步驟來改變綁定選擇。
盡管已經示出和描述了具體實施例，對本領域的技術人員來說，各種變形是顯而易見的。
附錄縮寫詞及首字母縮略詞HTTP超文本傳輸協(xié)議IIOP因特網對象請求代理間協(xié)議IPC 過程間通信JAX-RPC 用于基于XML的RPC的Java APIJMS Java消息服務MIME多用途因特網郵件擴充QOS 服務質量RDF 資源描述框架RMI 遠程方法調用RPC 遠程過程調用SLA 服務等級協(xié)議SOAP簡單對象訪問協(xié)議UDDI通用描述、發(fā)現和集成WSDLWeb服務定義語言WSIFWeb服務調用框架XML 可擴展標記語言
權利要求
1.一種在面向服務的體系結構中調用服務的方法，其中客戶使用所選擇的傳輸綁定調用來自服務提供者的服務，該方法包括以下步驟在協(xié)商過程中使用第一傳輸綁定協(xié)商用于來自所述服務提供者的服務調用的服務綁定；以及使用在所述協(xié)商過程中所協(xié)商的服務綁定處理所述服務調用。
2.權利要求1的方法，其中所述客戶位于通信路徑的客戶端，所述步驟在所述通信路徑的所述客戶端執(zhí)行。
3.權利要求1的方法，其中所述服務提供者位于通信路徑的服務器端，所述步驟在所述通信路徑的所述服務器端執(zhí)行。
4.權利要求1的方法，其中所述客戶位于通信路徑的客戶端，所述服務提供者位于所述通信路徑的服務器端，所述服務綁定直接在所述通信路徑的所述客戶端及所述服務器端之間協(xié)商。
5.權利要求1的方法，其中所述客戶位于通信路徑的客戶端，所述服務提供者位于所述通信路徑的服務器端，所述步驟在所述通信路徑的所述客戶端及所述服務器端執(zhí)行。
6.權利要求1的方法，其中所述服務調用經由在作為端節(jié)點的所述客戶及所述服務器之間的一條通信路徑的一個或多個中介節(jié)點，所述方法步驟被沿所述客戶及所述服務器之間的所述通信路徑的所述中介節(jié)點中的一個及其相鄰節(jié)點執(zhí)行。
7.權利要求1的方法，其中所述服務調用經由在作為端節(jié)點的所述客戶及所述服務器之間的一條通信路徑的一個或多個中介節(jié)點，所述方法包含以下步驟使沿所述客戶及所述服務器之間的所述通信路徑的每對相鄰節(jié)點在所述節(jié)點之間的協(xié)商過程中協(xié)商用于所述服務調用經過所述節(jié)點之間部分的服務綁定；以及使每對相鄰節(jié)點使用在所述節(jié)點間的所述協(xié)商過程中所協(xié)商的服務綁定處理所述服務調用經過所述節(jié)點的部分。
8.權利要求1的方法，其中所述客戶位于通信路徑的客戶端，所述服務位于所述通信路徑的服務器端，所述協(xié)商步驟包含以下步驟確定所述服務器端是否能夠協(xié)商一服務綁定；如果確定所述服務器端能夠協(xié)商一服務綁定，則與所述服務器端協(xié)商一服務綁定；以及否則，根據所述通信路徑的客戶端中的可用信息選擇一服務綁定而不與所述服務端協(xié)商。
9.權利要求8的方法，其中根據所述通信路徑的客戶端中的可用診斷信息來選擇所述服務綁定。
10.一種在面向服務的體系結構中調用服務的裝置，其中客戶使用所選擇的傳輸綁定調用來自服務提供者的服務，包括用于在協(xié)商過程中使用第一傳輸綁定協(xié)商用于來自所述服務提供者的服務調用的服務綁定的裝置；以及用于使用在所述協(xié)商過程中所協(xié)商的服務綁定處理所述服務調用的裝置。
11.權利要求10的裝置，其中所述客戶位于通信路徑的客戶端，所述協(xié)商裝置以及所述處理裝置位于所述通信路徑的所述客戶端。
12.權利要求10的裝置，其中所述服務提供者位于通信路徑的服務器端，所述協(xié)商裝置以及所述處理裝置位于所述通信路徑的所述服務器端。
13.權利要求10的裝置，其中所述客戶位于通信路徑的客戶端，并且所述服務提供者位于所述通信路徑的服務器端，所述服務綁定在所述通信路徑的所述客戶端及所述服務器端之間直接協(xié)商。
14.權利要求10的裝置，其中所述客戶位于通信路徑的客戶端，并且所述服務提供者位于所述通信路徑的服務器端，所述協(xié)商裝置及所述處理裝置位于所述通信路徑的所述客戶端及所述服務器端。
15.權利要求10的裝置，其中所述服務調用經由在作為端節(jié)點的所述客戶及所述服務器之間的一條通信路徑的一個或多個中介節(jié)點，所述協(xié)商裝置及所述處理裝置與所述客戶端及服務器端之間所述通信路徑上的所述中介節(jié)點之一相關聯。
16.權利要求10的裝置，其中服務調用經由在作為端節(jié)點的所述客戶及所述服務器之間的一條通信路徑的一個或多個中介節(jié)點，在所述客戶及服務器之間的每一對相鄰節(jié)點之間，所述服務調用可能使用不同的傳輸綁定，所述裝置包含在沿所述客戶及服務器之間的所述通信路徑的每一對相鄰節(jié)點處，用于在所述節(jié)點之間的協(xié)商過程中，為所述服務調用經過所述節(jié)點的部分協(xié)商服務綁定的裝置；以及在每對相鄰節(jié)點處，用于使用在所述節(jié)點之間的所述協(xié)商過程中所協(xié)商的服務綁定處理所述服務調用經過所述節(jié)點之間的部分的裝置。
17.權利要求16的裝置，其中根據在所述通信路徑的客戶端中的可用診斷信息選擇所述服務綁定。
18.一種機器可讀的程序存儲裝置，有形地體現一個可由該機器執(zhí)行以完成在一個面向服務的體系結構中調用服務的方法步驟的指令程序，在該面向服務的體系結構中客戶可以使用所選擇的傳輸綁定調用來自服務提供者的所述服務，所述方法步驟包含在協(xié)商過程中使用第一傳輸綁定協(xié)商用于來自所述服務提供者的服務調用的服務綁定；以及使用在所述協(xié)商過程中所協(xié)商的服務綁定處理所述服務調用。
19.權利要求18的程序存儲裝置，其中所述客戶位于通信路徑的客戶端，所述服務位于所述通信路徑的服務器端，所述協(xié)商步驟包含以下步驟確定所述服務器端是否能夠協(xié)商服務綁定；如果確定所述服務器端能夠協(xié)商服務綁定，則與所述服務器端協(xié)商服務綁定；否則，根據所述通信路徑的客戶端中的可用信息選擇服務綁定而不與所述服務端協(xié)商。
20.權利要求19的程序存儲裝置，其中根據所述通信路徑的客戶端中的可用診斷信息來選擇所述服務綁定。
全文摘要
本發(fā)明是一種在面向服務的體系結構中調用服務的方法及裝置，在該面向服務的體系結構中，客戶使用所選擇的傳輸綁定調用這種來自服務提供者的服務。用于來自服務提供者的服務調用的服務綁定首先在協(xié)商過程中使用第一傳輸綁定被協(xié)商。然后，使用在協(xié)商過程中所協(xié)商的服務綁定來處理服務調用?？蛻艨梢允紫扰卸ǚ掌魇欠窨梢詤f(xié)商服務綁定。如果服務器可以協(xié)商服務綁定，則客戶與服務器協(xié)商服務綁定。否則，根據客戶可用的診斷信息來選擇一項服務綁定而不與服務器協(xié)商。對于通信路徑的每一個部分，可以由客戶及服務提供者協(xié)商或者由通信路徑中的中介來協(xié)商單獨的服務綁定。
文檔編號H04L29/06GK1607791SQ20041007026
公開日2005年4月20日 申請日期2004年7月30日 優(yōu)先權日2003年10月14日
發(fā)明者J·約瑟夫 申請人:國際商業(yè)機器公司