專利名稱：用于在面向服務(wù)的體系結(jié)構(gòu)中處理服務(wù)請求的方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種用于在面向服務(wù)的體系結(jié)構(gòu)中處理服務(wù)請求的方法和裝置。更具體地，本發(fā)明涉及一種用于在面向服務(wù)的體系結(jié)構(gòu)中批處理這樣的請求以及順序和并行地執(zhí)行這樣的經(jīng)批處理的請求的方法和裝置。
背景技術(shù)：
在本說明書中(通過使用加括號的標號)可參考下列出版物，所述出版物以印刷形式或者聯(lián)機形式存在，并在此將其并入作為參考1.W3C Note，“Web Services Description Language(WSDL)1.1”，2001年3月15日。
2.Ueli Wahli等人，WebSphere Version 5Web Services Handbook，IBMRedbook，SG24-6891-00，2003年3月。
3.W3C Working Drafts，“SOAP Version 1.2 Part 0Primer”，2002年6月26日。
4.W3C Working Drafts，“SOAP Version 1.2 Part 1MessagingFramework”，2002年6月26日。
5.W3C Working Drafts，“SOAP Version 1.2 Part2Adjuncts”，2002年6月26日。
6.Aaron Skonnard，“Understanding SOAP”，MSDN Library，2003年3月。
7.W3C Recommendation，“Extensible Markup Language(XML)1.0(Second Edition)”，2000年10月6日。
8.Peter Flynn(ed.)，“The XML FAQ v.3.01”，2003年1月14日。
9.Sun Microsystems，Inc.，“Java API for XML-Based RPC(JAX-RPC)”，出版于2003年8月28日。
10.Ian Foster等人，“The Physiology of the GridAn Open Grid ServicesArchitecture for Distributed Systems Integration”，2002年6月22日。
11.Steve Tuecke等人，“Grid Service Specification”，Draft 3，2002年7月17日。
12.W3C Note，“SOAP Messages with Attachments”，2000年12月11日。
在過去的幾年中，信息技術(shù)領(lǐng)域較顯著的事件之一是Web服務(wù)及其相近類型的網(wǎng)格服務(wù)的規(guī)范和實現(xiàn)的發(fā)展。如參考文獻[2]第7頁中所述，“Web服務(wù)是獨立的、模塊化的應(yīng)用，其可以通過網(wǎng)絡(luò)被描述、發(fā)布、定位和調(diào)用。Web服務(wù)執(zhí)行封裝業(yè)務(wù)功能，其范圍從簡單的請求回復(fù)到完整的業(yè)務(wù)過程交互?！盬eb服務(wù)已經(jīng)用這樣的標準規(guī)范被編碼為Web服務(wù)描述語言(WSDL)[1]。網(wǎng)格服務(wù)[10，11]已經(jīng)被定義為符合一組約定(接口和行為)的Web服務(wù)，所述的一組約定定義了客戶如何與網(wǎng)格服務(wù)進行交互。網(wǎng)格服務(wù)已經(jīng)被用來創(chuàng)建虛擬組織(VO)，在所述虛擬組織中實際上位于遠程的可用計算資源(應(yīng)用、處理器等等)對于用戶呈現(xiàn)為本地資源。
在類似于面向服務(wù)的體系結(jié)構(gòu)的Web服務(wù)中，服務(wù)提供商可以提供用來綁定以訪問服務(wù)的多個傳輸協(xié)議。這樣做是為了給客戶提供更好的服務(wù)質(zhì)量(QOS)的特征。基于互操作性的需求，大多數(shù)面向服務(wù)的體系結(jié)構(gòu)使用簡單對象訪問協(xié)議(SOAP)[3，4，5，6]作為用于交換結(jié)構(gòu)化消息的輕型協(xié)議。這是使用可擴展標記語言(XML)[7，8]作為構(gòu)件塊的簡單和可擴展模型。雖然這并不是SOAP的唯一應(yīng)用，但SOAP經(jīng)常被用作為用于傳輸遠程過程調(diào)用(RPC)請求和響應(yīng)(總體說來為“請求/響應(yīng)”)的手段。
使用SOAP作為消息交換機制的一個主要問題是它的不佳性能。存在很多建議來解決SOAP協(xié)議及其處理引擎的性能問題，包括二進制XML處理、XML處理器改進(例如拖解析器(pull parser))、預(yù)編譯的消息傳送框架等等。本發(fā)明解決在SOAP消息傳送體系結(jié)構(gòu)的服務(wù)請求過程中增加的等待時間的問題。關(guān)聯(lián)于服務(wù)調(diào)用的這個增加的等待時間是由于SOAPRPC的固有性質(zhì)。通常，無論何時做出服務(wù)請求調(diào)用，消息都會被格式化，并且被捆綁在SOAP主體中并通過導(dǎo)線被發(fā)送至服務(wù)器。傳統(tǒng)上，SOAP處理器被創(chuàng)建用來每次處理一個服務(wù)調(diào)用，其類似于進行遠程RPC調(diào)用。由于RPC調(diào)用的粒度屬性(進行多個小型調(diào)用或者一個大型調(diào)用)，這可在分布式體系結(jié)構(gòu)中引入增加的等待時間。
因此，當處理因特網(wǎng)寬的系統(tǒng)、大型廣域網(wǎng)和網(wǎng)格時，一個挑戰(zhàn)在于處理關(guān)聯(lián)于服務(wù)調(diào)用的增加的等待時間。必須做出對服務(wù)調(diào)用粒度的明智判定(即，進行大量的較小型調(diào)用或者較少量的大型調(diào)用)。但是大多數(shù)分布式系統(tǒng)被設(shè)計出來而沒有考慮這個特征(至少在RPC API層)。在SOAP協(xié)議中，因為SOAP被模擬成每次具有一個服務(wù)調(diào)用的簡單的RPC調(diào)用機制，所以會面臨相同的等待時間問題。它并不解決在單個程序運行中處理一組數(shù)據(jù)或作業(yè)的分布式系統(tǒng)的調(diào)用批處理需求。

發(fā)明內(nèi)容
一般而言，本發(fā)明涉及用于在面向服務(wù)的體系結(jié)構(gòu)中以最小化現(xiàn)有協(xié)議的等待時間問題的這樣一種方式來處理服務(wù)請求和響應(yīng)(總體說來為“請求/響應(yīng)”)的方法和裝置。積累的客戶服務(wù)請求被打包到單個消息中，該消息被傳輸?shù)骄W(wǎng)絡(luò)連接的服務(wù)器端。在網(wǎng)絡(luò)連接的服務(wù)器端，從消息中提取單獨請求，并將其路由到預(yù)定的服務(wù)供應(yīng)商。對所述服務(wù)請求的響應(yīng)同樣被打包到返回消息中，該返回消息被傳回客戶端，在客戶端，從消息中提取響應(yīng)，并將其路由到起始客戶。在優(yōu)選實施例中，單獨的請求/響應(yīng)作為簡單對象訪問協(xié)議(SOAP)消息的附件被傳送。另外，每個消息優(yōu)選地不僅包含請求，而且包含規(guī)定了執(zhí)行請求的順序的工作流信息(例如，不管給定請求可被并行地執(zhí)行，還是必須被順序地執(zhí)行)。此工作流信息被用來控制在服務(wù)器端執(zhí)行請求的順序，所以，例如可以啟動對新請求的執(zhí)行，而無需與客戶端進行額外的往返通信。
本發(fā)明解決在面向服務(wù)的體系結(jié)構(gòu)中增加的等待時間的問題。在優(yōu)選實施例中，它預(yù)期了在客戶和服務(wù)器端的服務(wù)請求批處理和分離框架，所述框架在通信路徑的每一端批處理請求或響應(yīng)用于傳輸?shù)酵ㄐ怕窂降牧硪欢?，并提取從通信路徑的另一端接收到的請求或響?yīng)。此外，本發(fā)明的優(yōu)選實施例預(yù)期了關(guān)于調(diào)用執(zhí)行過程的工作流定義，所述調(diào)用執(zhí)行過程是通過傳遞工作流信息到服務(wù)器(作為服務(wù)調(diào)用簡檔)并在服務(wù)器處使用該信息來執(zhí)行多個請求。(這里的“工作流信息”表示規(guī)定了執(zhí)行請求的順序的信息——例如，請求2在請求1之后執(zhí)行，請求3可以和請求2并行執(zhí)行等等。)最后，如在[12](在下文中稱為“帶附件的SOAP規(guī)范”)中定義和在圖4中所示，它預(yù)期了用于SOAP消息交換的有線消息格式(即，被視為字節(jié)串的消息的實際物理結(jié)構(gòu))，同時保留所有單獨的調(diào)用語義。(術(shù)語“調(diào)用語義”不僅包括工作流程信息，而且包括涉及安全性、事務(wù)需求、路由、定址和消息調(diào)用的其它方面的信息。)通過考慮若干假設(shè)而定義了此框架。首先，多數(shù)的服務(wù)不是和/或不能通過適用于一個請求調(diào)用而不是許多單個調(diào)用的集合業(yè)務(wù)邏輯而定義。其次，移動組成從客戶到服務(wù)器的業(yè)務(wù)邏輯工作流的一批服務(wù)調(diào)用將導(dǎo)致高性能。第三，客戶足夠智能化來批處理調(diào)用和選擇正確的工作流過程(會話過程)。
通過使用本發(fā)明，分布式系統(tǒng)的等待時間問題可以通過在低速SOAPRPC協(xié)議上批處理請求調(diào)用而被減小。它提供工作流機制，藉此客戶可以執(zhí)行服務(wù)器端的一系列請求，包括對業(yè)務(wù)邏輯的并行和順序執(zhí)行。它包含所有請求調(diào)用語義，諸如安全性、相關(guān)性和事務(wù)需求?？蛻艨梢宰裱蛻舳薃PI(類似于JAX-RPC)定義的相同編程模式，而基礎(chǔ)設(shè)施處理多數(shù)復(fù)雜性。這個框架給現(xiàn)有基礎(chǔ)設(shè)施提供透明度，并以客戶所請求的格式來提供結(jié)果。它可以支持同步或異步調(diào)用。最后，可以基于簡單啟用策略來處理故障，其中故障可能流回到客戶，或者可以通過使用工作流定義來支持復(fù)雜情況，其中服務(wù)調(diào)用中的故障可以影響其它服務(wù)調(diào)用。
雖然本發(fā)明優(yōu)選地在軟件中實現(xiàn)，它也可以在硬件、軟件或者兩者的某種組合中實現(xiàn)。當在軟件中實現(xiàn)本發(fā)明時，它可以采取機器可讀的程序存儲設(shè)備(諸如磁盤、光盤或半導(dǎo)體存儲器)的形式，其有形地包括了執(zhí)行所定義的方法步驟的機器可執(zhí)行的指令程序。


現(xiàn)在將只通過示例并參考下列附圖來描述本發(fā)明的實施例，在附圖中圖1示出了傳統(tǒng)的SOAPRPC實現(xiàn)中的客戶和服務(wù)器的交互。
圖2示出了本發(fā)明的SOAPRPC實現(xiàn)中的客戶服務(wù)器的交互。
圖3示出了傳統(tǒng)的SOAPRPC實現(xiàn)中SOAP消息的數(shù)據(jù)格式。
圖4示出了本發(fā)明的SOAPRPC實現(xiàn)中SOAP消息的數(shù)據(jù)格式。
圖5示出了本發(fā)明實施例的基本服務(wù)調(diào)用批處理引擎。
圖6示出了從客戶到服務(wù)器的樣本消息流。
圖7示出了使用調(diào)用批處理的從客戶到服務(wù)器的樣本消息流。
具體實施例方式
本發(fā)明預(yù)期了面向服務(wù)的體系結(jié)構(gòu)中的客戶和服務(wù)器通過批處理請求而更好地處理關(guān)聯(lián)于服務(wù)調(diào)用的增加的等待時間的服務(wù)請求批處理框架。此框架提供客戶端應(yīng)用編程接口(API)和客戶端請求批處理引擎來批處理調(diào)用。服務(wù)器端框架提供用于服務(wù)請求分解、標識、映射和分派的工具。此框架使用SOAP(簡單對象訪問協(xié)議)作為消息傳輸協(xié)議來用于服務(wù)綁定。還預(yù)期了基于客戶的優(yōu)選項和/或策略來管理服務(wù)的順序和并行執(zhí)行的工作流過程。
圖1示出了傳統(tǒng)的SOAP RPC實現(xiàn)中沒有批處理的情況下客戶和服務(wù)器的交互。如圖所示，客戶102使用SOAP/HTTP協(xié)議(即，使用HTTP傳輸綁定的SOAP消息協(xié)議)通過網(wǎng)絡(luò)106(例如，因特網(wǎng))與服務(wù)提供商104(或簡稱“服務(wù)”)104進行交互。在這個傳統(tǒng)實現(xiàn)中，客戶102通過對于每個調(diào)用發(fā)送一個消息來在服務(wù)提供商104上進行遠程過程調(diào)用(RPC)。以類似方式，服務(wù)提供商104通過對于每個響應(yīng)發(fā)送一個消息返回給客戶102來響應(yīng)這些調(diào)用。RPC可以是同步或異步的。在進行同步調(diào)用之前必須等候?qū)η耙粋€調(diào)用的響應(yīng)。另一方面，可以無需等待對前一個調(diào)用的響應(yīng)而進行異步調(diào)用。在此方案中，如果在傳輸協(xié)議中存在任何明顯的等待時間，則同步調(diào)用可導(dǎo)致顯著的性能損失，因為它們無法重疊。
圖2示出了本發(fā)明的SOAP RPC實現(xiàn)中具有請求批處理的情況下的客戶和服務(wù)器的交互。在此實現(xiàn)中，客戶102通過網(wǎng)絡(luò)106在服務(wù)提供商104上進行遠程過程調(diào)用(RPC)，服務(wù)提供商104如前所述響應(yīng)所述調(diào)用。然而，客戶102積聚調(diào)用并發(fā)送包含所積聚的調(diào)用的單個消息，而不是對于每個調(diào)用發(fā)送一個消息。以類似方式，服務(wù)提供商104積聚響應(yīng)并發(fā)送包含所積聚的響應(yīng)的單個消息，而不是對于每個響應(yīng)發(fā)送一個消息返回給客戶102。在圖1的方案中，RPC可以是同步或異步的。然而在這里，客戶102可以規(guī)定具有工作流信息的多種請求的執(zhí)行的任何必要次序，所述次序連同請求本身一起被發(fā)送到服務(wù)提供商104，如下所述。
在圖1和圖2兩者之中，客戶102可以是在客戶機器上未單獨示出的多個此類客戶(或“服務(wù)請求者”)中的一個。同樣地，服務(wù)提供商104可以是在服務(wù)器機器(或“服務(wù)器”)上的多個此類服務(wù)提供商中的一個。除在這里描述的之外，客戶102和服務(wù)提供商104的運行細節(jié)不構(gòu)成本發(fā)明的任一部分，因此在此未示出。同樣地，客戶102和服務(wù)提供商104所在的機器的運行細節(jié)不構(gòu)成本發(fā)明的任一部分，因此在此未單獨示出這些機器。同樣地，除能夠支持這里描述的協(xié)議之外，網(wǎng)絡(luò)106的運行細節(jié)不構(gòu)成本發(fā)明的任一部分，因此在此不作說明。
圖3示出了傳統(tǒng)SOAP實現(xiàn)中的SOAP消息300的數(shù)據(jù)格式。所示消息300是請求消息，但是響應(yīng)消息的格式與之類似。參考附圖，SOAP消息300包括包封302，包封302包含頭部304和主體306。頭部304和主體306的每一個由各自的XML標志對來定界，包封302也是如此。頭部304是可選的，其可包含組織到頭部塊之中的各種類型的控制信息。另一方面，主體306是必需的，其包含實際的端到端消息，例如，如圖所示的單個RPC方法調(diào)用。
圖3示出了SOAP消息300的邏輯結(jié)構(gòu)。嵌入HTTP請求的SOAP請求消息300的實際XML格式可以類似于從[2]中取得的示例的下列內(nèi)容POST/servlet/rpcrouter HTTP/1.1Host:www.messages.com
Content-Type:text/xml;charset="utf-8"Content-Length:nnnnSOAPAction:""<SOAP-ENV:Envelope>
Xmllns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"<SOAP-ENV:Body>
<nsl:getMessage xmlns:ns1="urnNextMessage"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<UserID xsi:type="xsd:string">JDoe</UserID>
<Password xsi:type="xsd:string">0JDOE0</Password>
</ns1:getMessage>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
在該例中，標準HTTP頭部(行1-5)包含SOAP服務(wù)器的URL，在該例中為/www.messages.com/servlet/rpcrouter。相對于這個URL，Web服務(wù)是通過urn:NextMessage所標識。在HTTP頭部之后是包含將被傳輸?shù)南⒌腟OAP包封302(行6-15)。在這個特定示例中，SOAP包封302包含主體306(行8-14)，但是沒有頭部304。這里，方法啟用是駐留于SOAP服務(wù)器上被稱為urn:Nextmessage的Web服務(wù)的方法getMessage(UserID，Password)的調(diào)用的SOAP RPC表示。在行10，http://schemas.xmlsoap.org/soap/encoding/規(guī)定了編碼，所述編碼被用來把來自客戶端和服務(wù)器端的編程語言的參數(shù)值轉(zhuǎn)換為XML，反之亦然。
圖4示出了本發(fā)明的SOAP實現(xiàn)中的SOAP消息400的數(shù)據(jù)格式。盡管所示消息400是請求消息，但是響應(yīng)消息格式與之類似。參考該圖，SOAP消息400包括包封402，包封402包含頭部404和主體406，如前一樣。此外，然而，SOAP消息400包含一個或多個MIME附件408(它們中的兩個被示出)，如在所引用的帶附件的SOAP規(guī)范[12]中所定義的。(圖4的邏輯視圖示出了包括附件408的包封402。然而，如[2]中示出的實際的消息格式中，附件408位于包封402外面。)圖4中示出的帶附件的SOAP格式被用來把那些本該是單獨的SOAP消息300打包到單一的SOAP消息400中。在優(yōu)選實施例中，包含在消息400中的每個單獨的SOAP消息(對應(yīng)于RPC請求或響應(yīng))的主體306被嵌入作為SOAP MIME附件408。SOAP頭部404包含所有單獨的SOAP頭部304的總集合，以及包含對MIME附件408的引用(即，指針)，使得單獨的SOAP消息300可以被重建。主體406包含關(guān)于附件408的信息，而不包含實際的消息。更具體地，主體406包含對應(yīng)于單獨SOAP消息300的主體306的MIME附件408的引用或指針。當與頭部404中的單獨頭部304的引用結(jié)合使用時，在主體406中的這些引用允許單獨消息300被重建。
圖5示出了本發(fā)明的基本服務(wù)調(diào)用批處理引擎。如圖所示，客戶102經(jīng)由請求批處理和響應(yīng)分離引擎502與網(wǎng)絡(luò)106相交互，而同樣地，服務(wù)器104經(jīng)由響應(yīng)批處理和請求分離引擎504與網(wǎng)絡(luò)106相交互。雖然只示出了單個客戶102和服務(wù)供應(yīng)商104，但是典型地，在連接的每一端可以存在多個此類實體。正如它們的名字所意味的，請求批處理和響應(yīng)分離引擎502把來自客戶102的單獨請求打包到包含用于通過網(wǎng)絡(luò)106傳輸?shù)亩鄠€請求的單個消息400(圖4)中，而響應(yīng)批處理和請求分離引擎504從消息400中提取單獨請求來由服務(wù)104處理。對于去往服務(wù)器的(請求)消息400，這將需要把單獨請求消息300的主體306作為MIME附件408嵌入消息400(通過指向主體406中附件408的指針)以及把單獨請求消息300的頭部304放入消息400的頭部404中(通過指向相應(yīng)附件408的指針)。對于入站(響應(yīng))消息400，這將需要從單個頭部304中提取單獨頭部304，從MIME附件408中提取單獨主體306，并且重建包含來自所提取的組件的單個RPC響應(yīng)的消息300。
同樣地，對于回程來說，響應(yīng)批處理和請求分離引擎504把來自客戶104的單獨請求打包到包含用于通過網(wǎng)絡(luò)106傳輸?shù)亩鄠€響應(yīng)的單個消息400中，而請求批處理和響應(yīng)分離引擎502從消息400中提取單獨響應(yīng)來由客戶處理。批處理和分離引擎502和504通過各自的調(diào)用相關(guān)器506和508的協(xié)助來執(zhí)行以上描述的功能?？蛻舳苏{(diào)用相關(guān)器506確保響應(yīng)被路由到適當?shù)目蛻?02，而服務(wù)器端調(diào)用相關(guān)器506確保請求被路由到適當?shù)姆?wù)提供商104。此外，服務(wù)器端的工作流處理單元510使用從客戶端接收的工作流信息來管理所接收請求的處理順序。
本發(fā)明預(yù)期了一種框架，其通過引入請求調(diào)用批處理的概念以及將工作流語義添加到請求消息中用于在服務(wù)器處連續(xù)和并行地執(zhí)行請求，而減少了與正常的SOAP請求調(diào)用相關(guān)聯(lián)的等待時間。主要的體系結(jié)構(gòu)目的之一是通過使用相同的客戶和服務(wù)器端API和SOAP消息傳送中間件來保持客戶和服務(wù)器端實現(xiàn)的完整。
如在上述摘要部分提到的，本發(fā)明通過提供下述內(nèi)容來解決在面向服務(wù)的體系結(jié)構(gòu)中增加的等待時間的問題，所述內(nèi)容為(1)在客戶和服務(wù)器處的服務(wù)請求調(diào)用批處理和分離框架(如圖5所示)；(2)在調(diào)用執(zhí)行過程中的工作流定義，其傳送工作流信息到服務(wù)器(作為服務(wù)調(diào)用簡檔)和在服務(wù)器處執(zhí)行此工作流信息(如圖5所示)；(3)有線消息格式，用于如帶附件的SOAP規(guī)范[12]所定義的SOAP消息交換，而同時保留所有的單獨調(diào)用語義(如圖4所示)。
這些項目中的第一項服務(wù)請求調(diào)用批處理和分離框架，支持客戶端API來定義調(diào)用批處理需求、與工作流程相關(guān)的信息和請求控制功能。此API包括開始請求批處理、結(jié)束請求批處理以及調(diào)用語義上相關(guān)聯(lián)的工作流，所述調(diào)用語義上相關(guān)聯(lián)的工作流包括哪些調(diào)用可以并行執(zhí)行、哪些調(diào)用應(yīng)該等待來自另一調(diào)用的結(jié)果、將以什么順序進行調(diào)用等等。此工作流可以是對WSDL語義的擴展或者可以是新的客戶端服務(wù)調(diào)用策略語言(例如服務(wù)調(diào)用會話語言)。
優(yōu)選地，服務(wù)請求調(diào)用批處理和分離框架支持同步和異步的客戶調(diào)用，這些調(diào)用使用了同步原語(primitive)和調(diào)用隊列并將消息關(guān)聯(lián)于消息相關(guān)器。
客戶端框架創(chuàng)建了如帶附件的SOAP規(guī)范所定義的SOAP消息，并發(fā)送該SOAP消息到公知的通過第一MIME部分(即，SOAP主體消息)所標識的服務(wù)器端框架。此SOAP消息包含所有相關(guān)的信息和指向其它MIME部分(每個MIME部分是在這里被分組的單獨SOAP請求)的指針，如帶附件的SOAP規(guī)范所定義的。
客戶端框架與相關(guān)性引擎協(xié)同工作來支持消息關(guān)聯(lián)，使得成功的響應(yīng)或故障被返回到正確的請求器。它處理服務(wù)調(diào)用響應(yīng)和故障，并且將它們分派到正確的客戶。在優(yōu)選實施例中，它是可插式框架并且基于請求調(diào)用批處理的需求而被使能。每個單獨請求的SOAP頭部(每個單獨請求可以有一個或多個頭部)被打包到經(jīng)批處理的請求的新的SOAP頭部。這些SOAP頭部被修改以指向MIME部分。通過具有以下所述的服務(wù)器框架，包括中間體系(intermediaries)的SOAP頭部處理器可以容易地解釋SOAP消息并做出適當決定。
服務(wù)器端提供用于分離請求和在工作流引擎下執(zhí)行它們的必要框架。服務(wù)器端框架與工作流引擎和調(diào)用相關(guān)器協(xié)同定義理解與該調(diào)用相關(guān)聯(lián)的語義的過程。這些調(diào)用語義與SOAP消息一起被發(fā)送到SOAP頭部中。此框架可以是服務(wù)端點(批處理服務(wù)實現(xiàn))或可以是服務(wù)入口點(小應(yīng)用程序或處理機)的一部分。此產(chǎn)物(即，服務(wù)入口點或端點)基于容器需求而被被模仿和管理。簡而言之，服務(wù)器端的框架負責請求分離、執(zhí)行(同步和/或并行)、結(jié)果/故障映射以及經(jīng)批處理的響應(yīng)處理。
如前所述，該工作流信息可在客戶端和/或服務(wù)器端請求處理引擎被定義。這可與WSDL相關(guān)聯(lián)或可被分開定義為策略文件。此工作流信息可以是簡單的(在調(diào)用方法中沒有順序或語義)或可以是非常復(fù)雜的。使用工作流引擎的服務(wù)器來進行執(zhí)行的控制。
所公開的用于SOAP消息交換的有線消息格式是本發(fā)明優(yōu)選實施例的核心特征之一。它定義了SOAP消息交換模式，而不泄露與每個調(diào)用相關(guān)聯(lián)的服務(wù)調(diào)用語義。如圖4所示，該優(yōu)選實施例使用由帶附件的SOAP規(guī)范[12]所規(guī)定的消息格式。每個請求通過使用MIME部分被標識，并且可以從SOAP頭部和SOAP主體進行引用。SOAP主體向服務(wù)器端框架定義RPC消息，服務(wù)器端框架負責分離每個消息部分和執(zhí)行請求。每個SOAP頭部屬性保持與請求相關(guān)聯(lián)，而未經(jīng)修改。SOAP頭部和MIME部分承載消息與相關(guān)信息來使請求和響應(yīng)/故障相關(guān)。主要的SOAP部分可承載工作流管理所需要的額外簡檔。
這是可插的框架，感興趣的客戶可連同其當前的基礎(chǔ)設(shè)施一起使用此框架，而不需要改變其當前代碼來支持在工作流過程中在服務(wù)器處的調(diào)用批處理和請求執(zhí)行。通過避免為完成作業(yè)而到服務(wù)器的多次往返，這可減少調(diào)用等待時間并且可導(dǎo)致增加的性能。
圖6和圖7例示了在使用JAX-RPC處理機的Java環(huán)境中本發(fā)明的批處理引擎的具體實現(xiàn)。更具體地，圖6示出在傳統(tǒng)實現(xiàn)中從客戶到服務(wù)器的樣本消息流，而圖7示出了使用本發(fā)明的調(diào)用批處理的從客戶到服務(wù)器的樣本消息流。這里，以普通方式通過任何面向服務(wù)的框架來定義所述體系結(jié)構(gòu)，其可被用于請求/響應(yīng)調(diào)用批處理并向工作流信息簡檔提供請求語義。
首先參考圖6，在傳統(tǒng)的SOAP RPC實現(xiàn)中，客戶102通過JAX-RPC[9]處理機或API 602與網(wǎng)絡(luò)106相交互，而服務(wù)104通過應(yīng)用服務(wù)器或SOAP調(diào)用接收器604與網(wǎng)絡(luò)106相交互。在客戶端，JAX-RPC[9]處理器602與SOAP消息處理機606合作來生成SOAP消息300(圖3)，SOAP消息300包含用于通過網(wǎng)絡(luò)106傳輸?shù)膯蝹€RPC請求。更具體地，JAX-RPC處理機602生成RPC請求，而SOAP消息處理機606以每個消息一個請求306的方式把請求打包到SOAP消息300(圖3)中。類似地，在服務(wù)器端，應(yīng)用服務(wù)器或SOAP調(diào)用接收器604與SOAP消息處理機608合作來從每個消息300提取單個RPC請求，用于服務(wù)104的處理。更具體地，應(yīng)用服務(wù)器604接收SOAP消息300，而SOAP消息處理機608從每個消息提取單獨的RPC調(diào)用。這些單元的運行與從服務(wù)器的返程相同。在服務(wù)器端，應(yīng)用服務(wù)器604與SOAP消息處理機608合作來生成SOAP消息300，SOAP消息300包含用于通過網(wǎng)絡(luò)106傳輸?shù)膯蝹€RPC響應(yīng)。類似地，在客戶端，JAX-RPC處理機602與SOAP消息處理機606合作來從每個消息300提取單個RPC響應(yīng)，用于客戶102的處理。
圖7示出圖6所示的傳統(tǒng)實現(xiàn)怎樣根據(jù)本發(fā)明被修改。在客戶端，JAX-RPC處理機602由SOAP調(diào)用批處理API 702所補充，而SOAP消息處理機606被客戶SOAP調(diào)用批處理發(fā)送處理機704、客戶SOAP調(diào)用批處理接收處理機708和調(diào)用相關(guān)器712所代替。客戶SOAP調(diào)用批處理發(fā)送處理機704把多個請求406作為單個SOAP消息400的附件被打包，用于傳輸?shù)椒?wù)器端，而客戶SOAP調(diào)用批處理接收處理機708從返回消息400中提取單獨的響應(yīng)，用于由調(diào)用相關(guān)器712分派到預(yù)定客戶102。
在服務(wù)器端，SOAP消息處理機608被服務(wù)器SOAP調(diào)用分離器處理機706、服務(wù)器SOAP調(diào)用批處理響應(yīng)處理機710、調(diào)用相關(guān)器714以及順序和并行調(diào)用處理引擎或工作流管理器716所代替。服務(wù)器SOAP調(diào)用分離器處理機706從通過應(yīng)用服務(wù)器604接收的消息400提取單獨的請求406，用于由調(diào)用相關(guān)器714分派到預(yù)定的服務(wù)提供商104，而服務(wù)器SOAP調(diào)用批處理響應(yīng)處理機710把響應(yīng)打包到單個消息400中，用于由應(yīng)用服務(wù)器604傳輸回客戶端。最后，順序和并行調(diào)用處理引擎716使用來自消息400的工作流信息來為從客戶端接收的請求400的執(zhí)行進行排序。因此，工作流信息指示出可以被并行執(zhí)行的請求被并行執(zhí)行，而工作流信息指示出必須被順序執(zhí)行的請求被順序執(zhí)行。
盡管已示出并描述了具體的實施例，但對于本領(lǐng)域技術(shù)人員來說，各種修改將是顯而易見的。
附錄縮寫詞和首字母縮略詞HTTP 超文本傳輸協(xié)議IIOP 因特網(wǎng)內(nèi)部對象請求代理(ORB)協(xié)議IPC 進程間通信JAX-RPC 用于基于XML的RPC的Java APIJMS Java 消息傳送服務(wù)
MIME 多用途因特網(wǎng)郵件擴展QOS 服務(wù)質(zhì)量RDF 資源描述框架RMI 遠程方法啟用RPC 遠程程序調(diào)用SLA 服務(wù)級協(xié)議SOAP 簡單對象訪問協(xié)議UDDI 通用描述、發(fā)現(xiàn)和集成WSDL Web 服務(wù)定義語言WSIF Web 服務(wù)啟用框架XML 可擴展標記語言
權(quán)利要求
1.一種用于在面向服務(wù)的體系結(jié)構(gòu)中處理請求和響應(yīng)的方法，其中，客戶發(fā)布服務(wù)請求到服務(wù)提供商以及從所述服務(wù)提供商接收對所述服務(wù)請求的響應(yīng)，所述客戶和所述服務(wù)提供商構(gòu)成在通信路徑第一和第二端的實體，所述方法包括以下步驟在所述通信路徑的一端積聚多個此類請求或響應(yīng)，用于傳輸?shù)剿鐾ㄐ怕窂降牧硪欢说膶嶓w；生成包含所積聚的多個請求或響應(yīng)的單個消息；以及傳輸所生成的包含所積聚的多個請求或響應(yīng)的消息到所述通信路徑的另一端的實體。
2.根據(jù)權(quán)利要求1所述的方法，其中所生成的消息是包含所積聚的多個請求或響應(yīng)作為簡單對象訪問協(xié)議附件的簡單對象訪問協(xié)議消息。
3.根據(jù)權(quán)利要求1所述的方法，其中所述消息從所述通信路徑的所述第一端進行傳輸并包含請求，所述方法還包括以下步驟從所述通信路徑的所述第二端接收消息，所述消息包含由所述服務(wù)提供商生成的對服務(wù)請求的多個響應(yīng)；以及從所接收的消息提取單獨響應(yīng)，用于在所述通信路徑的所述第一端進行處理。
4.根據(jù)權(quán)利要求1所述的方法，其中所述消息是從所述通信路徑的所述第一端傳輸?shù)牟埱?，所述方法還包括以下步驟在所述通信路徑的所述第二端接收所述消息；以及從所接收的消息提取單獨請求，用于在所述通信路徑的所述第二端進行處理。
5.根據(jù)權(quán)利要求4所述的方法，其中所述消息包含規(guī)定請求的執(zhí)行順序的工作流信息，所述方法還包括以下步驟以由所述工作流信息規(guī)定的順序來執(zhí)行請求。
6.根據(jù)權(quán)利要求5所述的方法，其中所述工作流信息規(guī)定所述消息中的請求是被順序執(zhí)行還是被并行執(zhí)行，所述請求按照所述工作流信息所規(guī)定的被順序或并行執(zhí)行。
7.一種在面向服務(wù)的體系結(jié)構(gòu)中處理請求和響應(yīng)的方法，其中客戶發(fā)布服務(wù)請求到服務(wù)提供商并從所述服務(wù)提供商接收對所述服務(wù)請求的響應(yīng)，所述客戶和所述服務(wù)提供商構(gòu)成通信路徑的第一和第二端的實體，所述方法包括以下步驟在所述通信路徑的一端從所述通信路徑的另一端接收包含多個此類請求或響應(yīng)的消息；以及從所接收的消息提取單獨請求或響應(yīng)，用于在所述通信路徑的所述一端進行處理。
8.根據(jù)權(quán)利要求7所述的方法，其中所述消息在所述通信路徑的所述第二端接收，并包含請求連同規(guī)定請求的執(zhí)行順序的工作流信息，所述方法還包括以下步驟以由所述工作流信息規(guī)定的順序執(zhí)行請求。
9.一種在面向服務(wù)的體系結(jié)構(gòu)中處理請求和響應(yīng)的裝置，其中客戶發(fā)布服務(wù)請求到服務(wù)提供商以及從所述服務(wù)提供商接收對所述服務(wù)請求的響應(yīng)，所述客戶和所述服務(wù)提供商構(gòu)成在通信路徑第一和第二端的實體，所述裝置包括用于在所述通信路徑的一端積聚多個此類請求或響應(yīng)用于傳輸?shù)剿鐾ㄐ怕窂降牧硪欢说膶嶓w的工具；用于生成包含所積聚的多個請求或響應(yīng)的單個消息的工具；以及用于傳輸所生成的包含所積聚的多個請求或響應(yīng)的消息到所述通信路徑的另一端的實體的工具。
10.根據(jù)權(quán)利要求9所述的方法，其中所述消息從所述通信路徑的所述第一端進行傳輸并包含請求，所述裝置還包括用于從所述通信路徑的所述第二端接收消息的工具，所述消息包含由所述服務(wù)提供商生成的對服務(wù)請求的多個響應(yīng)；以及用于從所接收的消息提取單獨響應(yīng)用于在所述通信路徑的所述第一端進行處理的工具。
11.根據(jù)權(quán)利要求9所述的裝置，其中所述消息是從所述通信路徑的所述第一端傳輸?shù)牟埱?，所述裝置還包括用于在所述通信路徑的所述第二端接收所述消息的工具；以及用于從所接收的消息提取單獨請求，用于在所述通信路徑的所述第二端進行處理的工具。
12.根據(jù)權(quán)利要求11所述的裝置，其中所述消息包含規(guī)定請求的執(zhí)行順序的工作流信息，所述裝置還包括用于以由所述工作流信息規(guī)定的順序來執(zhí)行請求的工具。
13.一種在面向服務(wù)的體系結(jié)構(gòu)中處理請求和響應(yīng)的裝置，其中客戶發(fā)布服務(wù)請求到服務(wù)提供商并從所述服務(wù)提供商接收對所述服務(wù)請求的響應(yīng)，所述客戶和所述服務(wù)提供商構(gòu)成通信路徑的第一和第二端的實體，所述裝置包括用于在所述通信路徑的一端從所述通信路徑的另一端接收包含多個此類請求或響應(yīng)的消息的工具；以及用于從所接收的消息提取單獨請求或響應(yīng)用于在所述通信路徑的所述一端進行處理的工具。
14.根據(jù)權(quán)利要求13所述的裝置，其中所述消息在所述通信路徑的所述第二端接收，并包含請求連同規(guī)定請求的執(zhí)行順序的工作流信息，所述方法還包括以下步驟以由所述工作流信息規(guī)定的順序執(zhí)行請求。
15.一種機器可讀的程序存儲設(shè)備，其有形地包括可由機器運行用于執(zhí)行權(quán)利要求1至8中的任一項的方法步驟的指令的程序。
全文摘要
在面向服務(wù)的體系結(jié)構(gòu)中，以最小化現(xiàn)有協(xié)議的等待時間問題的這樣一種方式來處理服務(wù)請求和響應(yīng)。積聚的客戶服務(wù)請求與規(guī)定了請求的執(zhí)行順序的工作流信息一起被打包到單個消息中，該消息被傳輸?shù)骄W(wǎng)絡(luò)連接的服務(wù)器端。在網(wǎng)絡(luò)連接的服務(wù)器端，從消息連同工作流信息中提取單獨請求，并將其路由到預(yù)定的服務(wù)提供商，在預(yù)定服務(wù)提供商處，它們以由工作流信息規(guī)定的順序執(zhí)行。對服務(wù)請求的響應(yīng)同樣地被打包到返回消息中，該返回消息被傳輸回客戶端，在客戶端，從該消息中提取響應(yīng)，并將其路由到起始客戶。在優(yōu)選實施例中，單獨的請求和響應(yīng)作為簡單對象訪問協(xié)議(SOAP)消息的附件被傳送。
文檔編號G06F9/50GK1867898SQ200480029747
公開日2006年11月22日 申請日期2004年10月5日 優(yōu)先權(quán)日2003年10月14日
發(fā)明者J·約瑟夫 申請人:國際商業(yè)機器公司