專利名稱：用于使爪哇小服務程序與異步消息結合的系統的制作方法
技術領域：
本發明總的涉及應用和事務服務器，特別涉及用于支持消息排隊和具有多重執行隊列的線程的系統。
交叉引用本申請涉及2001年10月5日提交的申請號為60/327,543的臨時申請“SYSTEM FOR APPLICATION SERVER MESSAGING WITH MULTIPLEDISPATCH POOLS(用于與多重調度池進行消息接發的應用服務器的系統)”和2002年10月3日提交的申請號為＿＿＿＿、發明人為Adam Messinger和Don Ferguson的實用新型專利申請“SYSTEM FOR APPLICATION SERVERMESSAGING WITH MULTIPLE DISPATCH POOLS(用于與多重調度池進行消息接發的應用服務器的系統)”，通過引用將這兩個申請都合并于此。
背景技術：
Java 2平臺企業版(J2EE)規范定義了一種用于開發多層企業應用程序的現行標準。J2EE提供了一種設計、開發、組裝以及調配(deployment)企業應用程序的基于組件的途徑，其既減小了成本，又允許集中設計和實現。J2EE平臺為開發者提供了多層分布式應用模型、重新使用組件的能力、統一的安全模型以及靈活的事務控制。其不但可以提供能比以前更快地進行銷售的革新的用戶解決方案，而且所得到的獨立于平臺的、基于組件的J2EE解決方案并不受任何一個廠商的產品和應用程序接口(API)的約束。
J2EE規范定義了下述種類的組件應用客戶機組件；企業Java豆(EJB，Enterprise JavaBean)；小服務程序(servlet)和Java服務器頁面(JSP)(也稱為網絡組件)；以及小程序(applet)。多層分布式應用模型意味著根據功能將應用邏輯劃分為多個組件，而多個不同的應用組件可以組成同一個或不同服務器上的J2EE應用程序。應用組件實際安裝在哪里取決于該應用組件屬于多層J2EE環境中的哪一層。圖1中描繪了這些層。如其中所示，應用服務器層104用于開發EJB容器和/或諸如servlet、JSP、以及html頁面的顯示(presentation)容器114。而這些又用作客戶機層102與后端層106之間的接口，其中在客戶機層102調配客戶機108和客戶機應用程序，而后斷層106用于容納諸如企業資源計劃(ERP)系統的企業或遺留(legacy)應用程序。
客戶機層——其可以是瀏覽器、基于Java的程序或其它客戶機層內運行的網絡激活編程環境，既可在公司防火墻之內也可在公司防火墻之外。
應用服務器層——通常這一層容納顯示邏輯和業務邏輯的組合，以支持客戶機請求。顯示邏輯通過JSP頁面和顯示HTML頁面的servlet支持，而業務邏輯通過遠程方法調用(RMI)對象和EJB 112支持。EJB依賴于事務、生命周期、狀態管理、資源共享、安全性等的容器環境，其一起組成豆(bean)執行的運行時間環境。
后端層——這一般是現有應用程序和數據存儲的組合。由于其可能包括諸如企業資源計劃(ERP)、主機事務處理、數據庫系統以及其它遺留信息系統的系統，所以其也被稱為企業信息系統(EIS)層。
由于J2EE應用程序的組件分離地、并且經常在不同的器件上運行，所以需要有客戶機和應用服務器層代碼查找并引用其它代碼和資源的方式。客戶機和應用程序代碼可以例如使用Java命名和目錄接口(JNDI)116來查找用戶定義的諸如企業豆的對象，以及諸如Java數據庫連接器(JDBC)數據資源對象的位置和消息連接的環境條目，而所述位置又用于查找后端層中的資源。
可以在調配時間在網絡和企業豆組件上配置諸如安全性和事務管理的應用程序行為。這一調配時間特征使應用邏輯與可能隨組裝而改變的配置設置分離開來。J2EE安全模型讓開發者配置網絡或企業豆組件，使得僅由授權用戶訪問系統資源。例如，網絡組件可以配置為提示輸入用戶名和密碼。企業豆組件可以配置為只有特定組中的人員才可以調用其方法中的某些種類。或者，servlet組件可以配置為其一些方法可以被每個人訪問，而一些方法僅被一個組織中某些有特權的人訪問。相同的servlet組件可以對另一個環境配置為所有方法都可以被每個人訪問，或者所有方法都只能被選定的少數人訪問。
一些應用服務器，例如BEA系統公司，San Jose，Caiifomia的WebLogic服務器產品，使用訪問控制表(ACL)機制，其允許對服務器上運行的組件的利用進行精細控制。利用ACL，開發者可以在Java方法級定義哪個用戶或哪組用戶可以或不可以執行什么。這一ACL機制覆蓋了在應用服務器上運行的任何內容，除了在EJB規范中定義了其自身的訪問控制機制的EJB之外。安全領域允許管理員從現有授權或授權系統中引入信息到ACL。
Java Servletservlet是擴展網絡服務器的功能性的程序。servlet接收來自客戶機的請求，動態產生響應(可能查詢數據庫以滿足該請求)，然后向客戶機發送包含HTML或XML文件的響應。servlet與CGI類似，但是因為servlet使用Java類和流，所以通常更容易編寫。因為servlet被編譯為Java字節代碼，并且在運行時間servlet實例保持在存儲器中，所以其執行更快，每個客戶機請求產生一個新線程。servlet使得以動態方式產生數據給HTTP響應流更加容易。每個客戶機請求作為新連接執行，因此請求之間的流控制并不容易。為此，會話管理維持特定客戶機在請求間的狀態。在一些應用服務器中，servlet使用HTTP會話對象來保存其在方法請求之間的狀態。為了排除故障，這一對象可以在集群的環境中復制。
Java服務器頁面JSP頁面是基于文本的、用于開發servlet的顯示中心(presentation-centric)方式。JSP頁面提供servlet的所有優點，當其與JavaBean類合并時，提供一種使內容和顯示邏輯保持分離的容易的方式。JSP頁面和servlet都比公共網關接口(CGI)更理想，這是因為其是獨立于平臺的，并且使用較少的開銷。JSP頁面可以與JavaBean類一同使用，來定義用于建立由具有相似外觀和感覺的頁面組成的網站的網絡模板。JavaBean類執行數據呈現(rendering)，因此模板中沒有Java代碼。這意味著模板可以由HTML編輯器維持。使用JSP頁面的、簡單的基于網絡的應用程序可以用于使用自定義標記或小腳本(scriptlet)取代JavaBean類來將內容綁定到應用邏輯上。自定義標記被插入標記庫中，而標記庫被引入到JSP頁面中。scriptlet是直接嵌入JSP頁面的小Java代碼段。
Java消息接發服務(JMS)JMS是用于支持Java程序之間的消息交換的J2EE機制。即Java如何支持異步通信，其中發送者和接收者不需要彼此了解，因此可以獨立操作。JMS當前支持兩種消息接發模型點對點——其基于消息隊列。在這種模型中，消息產生者將消息發送到隊列中。消息用戶可以將其自身附在隊列上以傾聽消息。當消息到達隊列時，用戶將其從隊列中取出，并對其響應。消息可以僅發送到一個隊列，并僅由一個用戶使用。用戶具有過濾消息以指定其想要的確切消息類型的選項。
出版和定購——其允許產生者向一個主題、并向該主題的所有注冊用戶發送消息，以檢索這些消息。在這種情況下，許多用戶可以接收相同的消息。
現有ServletAPI的一個問題是完全同步的編程模型。在將請求調度到特定的線程之后，調用適當的servlet的服務()方法。當該服務()方法返回時，發送響應。這是一種簡單的編程模型，其適于許多類型的工作，但是在發送響應之前必須發生異步事件的情況下不是最優的，因為運行servlet的線程必須阻塞到該事件發生為止。
發明內容
本發明提供了一種用于異步穿線的系統和方法，其允許服務()方法在準備好發送請求之前返回(從而允許釋放線程)。這樣，當以后發生異步事件時，可以完成和發送響應。這一機制的示例使用是結合servlet使用JMS。
根據本發明，當執行servlet時開始該過程。servlet建立部分響應，但是通常需要更多數據來完成該響應。在servlet等待的同時，其將請求數據的JMS消息排入隊列，并在包含所需數據的JMS消息到達時，將響應對象設置在可能發現其的地方旁邊。在這一點上，servlet可以返回，但是還不會發送響應。在稍后的時間點，當數據經由例如JMS到達時，檢索對應的響應對象。然后可以產生剩余的響應。當響應完成時，可以將其明確地發送給客戶機。
這一特征還可以通過使用JSP標記庫而獲得。利用標記，JSP頁面創作者指定什么工作應在異步時間之前進行，而哪個工作應該在異步事件之后進行。這一特征與JSP上下文機制結合，以確保其在異步事件之后恢復，并且不受干擾地繼續處理。
圖1展示了可以利用本發明的J2EE兼容體系結構。
圖2展示了根據本發明實施例的具有異步線程池的穿線策略。
圖3展示了同步穿線處理的圖。
圖4展示了使用傳統方法處理的單個HTTP請求的生命周期。
圖5展示了使用異步消息接發處理的單個HTTP請求的生命周期。
圖6展示了使用傳統方法處理的多個HTTP請求的生命周期。
圖7展示了使用異步消息接發處理的多個HTTP請求的生命周期。
具體實施例方式
經過廣泛地描述，本發明提供了一種允許異步穿線的系統和方法。本發明可以并入允許經由應用程序接口(API)訪問servlet的應用服務器系統，或并入受益于異步穿線的其它系統中。
典型的Servlet API是完全同步的。在將請求調度給線程之后，調用適當的servlet的服務()方法。當該服務()方法返回時，發送響應。這種簡單的編程模型適于許多類型的工作，但是在發送響應之前必須發生異步事件的情況下不是最優的，因為運行servlet的線程必須阻塞到該事件發生為止。
在一個實施例中，本發明提供了Servlet API的擴展，其允許服務()方法在準備好發送請求之前返回(從而允許釋放線程)。這樣，當以后發生異步事件時，可以完成和發送響應。這一機制的一個示例使用是結合servlet使用JMS。
在這一實施例中，當執行servlet時，其建立部分響應，但是通常需要更多數據來完成該響應。servelt將請求數據的JMS消息排入隊列，并在包含所需數據的JMS消息到達時，將響應對象設置在可能發現其的地方旁邊。在這一點上，servlet可以返回，但是還不會發送響應。稍后，當請求的數據經由JMS到達時，檢索響應對象。然后可以產生剩余的響應。當完成時，可以明確地發送給客戶機。
本發明主要設計用于應用、事務以及消息接發服務器，例如BEA系統公司提供的WebLogic系列產品。典型服務器設計的核心是穿線模型，即分配線程執行工作請求的策略。當servlet請求到達服務器時，將其調度給線程。這一線程負責執行被請求的servlet。服務器采用使用兩個線程池、即異步池(通常稱為讀取線程)和同步池(稱為執行線程)的穿線模型。池的這種組合允許開發者或管理員有效地給請求設定優先級，同時容許執行阻塞操作的用戶代碼。
圖2展示了根據本發明實施例的穿線策略機制206。異步線程池208等待用于異步讀取結果的異步輸入機制202(多路復用器(muxer))變得可用。一旦有結果可用，來自池中的線程查看消息，并通過進行適當的回叫來調度該消息。調度回叫通常將要求由同步線程池進行后面處理的請求排入隊列。然而，某些非阻塞的有優先級的請求在回叫中被直接服務。通過積極地接受輸入，在低優先級的請求212運行的同時，高優先級的請求214不等待被讀取。由于這些線程應該從不阻塞，所以通常其數量較少，可能每個CPU只有一個。
同步線程池210等待請求的隊列204。一旦有請求可用，來自池中的線程從隊列中取出請求，對其進行處理，并發出結果216。在處理請求的同時，線程可以執行代碼，例如發出結果，這導致線程阻塞。所以，應該調節線程數，以使得每個CPU中總有一個線程處于可運行狀態。在2001年10月5日提交的申請號為60/327,543、發明人為Adam Messinger、題為“SYSTEM FORAPPLICATION SERVER MESSAGING WITH MULTIPLE DISPATCH POOLS(用于與多重調度池進行消息接發的應用服務器的系統)”的臨時申請和2002年10月3日提交的申請號為＿＿＿＿、發明人為Adam Messinger和DonFerguson、題為“SYSTEM FOR APPLICATION SERVER MESSAGING WITHMULTIPLE DISPATCH POOLS(用于與多重調度池進行消息接發的應用服務器的系統)”的實用新型專利申請中更詳細的描述了該調度策略。
圖3展示了傳統同步消息響應機制。如圖中所示，將來自客戶機應用程序302的請求，例如網絡瀏覽器應用程序，經由servlet 304發送到應用服務器。該請求可以是超文本傳輸協議(http)請求306的形式，對此客戶機通常期望超文本標記語言(html)響應308。在同步模型中，線程執行servlet，然后當servlet的執行完成時立即向客戶機發送響應。這一方案的問題在于在servlet的整個執行中消耗了執行線程。如果servlet正在執行可能因等待其它數據而阻塞的任務，則這可以表示服務器資源的浪費。
圖4圖解了客戶機訪問服務器資源的典型系統生命周期。如圖4所示，HTTP客戶機402訪問servlet 408，其通常在遠程網絡服務器上運行。對本領域技術人員而言顯而易見的是，盡管這里為了說明目的示出了HTTP客戶機，但是本發明不限于此，而是可以使用其它類型的客戶機應用程序。如圖4中的生命周期圖所示，HTTP客戶經由servlet容器404訪問servlet。servlet容器負責接收HTTP請求410，并將其傳送給servlet 408進行處理。處理這一HTTP請求的許多操作在servlet響應級406發生。如圖4所示，隨著時間沿頁面垂直地增加，該過程以由響應處理器406處理的對servlet的init(初始化)調用412繼續。然后servlet容器將service(服務)請求414傳送給servlet以例如檢索或更新數據。這樣的系統典型地用于電子商務環境，其中客戶機應用程序設計為檢索目錄列表，例如搜索飛行時間的結果等。servlet通常通過將輸出416寫到servlet響應處理器中來響應請求。經常為了緩沖和優化的目的而需要這一步驟。當servlet容器隨后請求將響應返回到客戶機時，其向響應處理器發送send(發送)請求418，而響應處理器向servlet容器返回sendresponse(發送響應)420。然后將該響應作為HTTP響應422發送給客戶機。
圖5圖解了可以根據本發明的實施例使用的類似生命周期。如圖5所示，再次使用HTTP客戶機502訪問遠程服務器、服務器資源或servlet 508。HTTP請求510由向servlet響應處理器506發布init請求512的servlet容器504處理。然而此時，當service請求514被發送到servlet處理時，servlet立即返回516到響應處理器。這一即時返回釋放了響應處理器以處理隨后的請求，因為其不需要為了處理那些請求而等待servlet積極地返回數據。在一段時間t520之后，當servlet具有要返回給該請求的適當的數據時，其向響應處理器發送send信號518，然后響應處理器向servlet容器發送send response 522。和前面一樣，后續的HTTP響應524被發送到客戶機。
作為上述過程的一部分，servlet設置響應代碼，直到其具有其它內容要發送，這有效地負責遠離容器級的響應，并將其至于servlet級。在實踐中，可以將servlet等待發布send響應的時間量定義為某個任意量，或者可以作為異步消息的結果執行，例如作為接收指示已有信息可用于發送給客戶機的JMS消息的結果。這種類型的處理在例如用戶在等待搜索結果時通常經歷延遲時間的電子商務網站中很有用。當根據本發明執行處理時，不是只具有凍結的屏幕，而是用戶可以接收一些項目信息，而隨著servlet發現適當的數據并將其返回，其它項目被一件一件地返回。同時，servlet響應處理器可用于處理其它客戶機請求。立即返回的數據的類型以及以后返回的類型可以由開發者指定。
圖6和圖7更詳細地圖解了本發明的操作，因為其可以應用來服務多個請求。如圖6所示，當未使用異步消息接發時，必須以按順序的方式處理來自客戶機的后續請求。因此，例如在圖6中，在處理來自客戶機B 403的第二個HTTP請求430之前，來自客戶機A的第一個HTTP請求410由servlet容器404和servlet響應處理器406處理，并被完全處理。總體的結果是花費兩倍時間來處理來自兩個客戶機的HTTP請求。如果不以這種按順序的方式處理請求，則非常有可能有一個或多個請求會產生對其它請求的積壓(backlog)，使得用戶將經歷處理的延遲。
圖7圖解了根據本發明實施例的機制的生命周期，其中使用異步消息接發，以異步方式來處理來自單個客戶機的多個請求和/或來自多個客戶機的請求，從而可以在不同的線程中運行處理。如圖7所示，第一HTTP客戶機A 502和第二HTTP客戶機B 503使用上述機制來訪問servlet資源508。根據這一實施例，當在servlet容器接收到第一個HTTP請求A 510時，由響應處理器使用init A調用512來進行處理，然后將其作為service請求514傳送到servlet508。Servlet立即返回516到servlet響應處理器，其然后釋放響應處理器以處理其它請求。如圖7所示，第二個HTTP請求B作為init B調用532由servlet響應處理器立即處理，并作為service請求534傳送給servlet以進行處理。Servlet再次立即返回536。以這種方式交織消息減少了處理兩個請求的總時間，并允許servlet在有信息變得可用時或者如果有信息變得可用，將信息返回給客戶機。例如，如圖7所示，當servlet發現響應請求A所需的消息時，其向servlet容器返回send response A信號522，以作為HTTP響應A524發送到客戶機。第二個send response B信號542和HTTP響應B 544以相同的方式進行處理。
實現在支持網絡上文件的異步發送的平臺上，文件servlet可以由快速文件servlet取代。這種類型的servlet的實現要求加入對servlet的異步響應，下面將對此進行描述。
同步和異步響應當來自遠程客戶機的servlet請求被服務時，經常需要響應。這一響應可以是同步的，即其由處理該請求的同一個線程發送，或者是異步的，即其以后在不同的線程中發送。這一分析是從服務器的角度進行的。從客戶機的角度來說，哪種類型的響應可以或不可以因等待而阻塞取決于如何進行遠程請求。
當前大多數請求是以同步方式處理的。當servlet請求被服務時，在服務線程可以移到另一個請求之前，必須完成所有處理。這一同步模型是由RMI和servlet規范所規定的。傳統上這樣做的原因是寫入異步代碼非常困難，從而易于出錯。
有一些情況下，以異步方式響應請求的能力對節約線程非常有益。在服務器需要對外部資源進行一次或多次長運行請求或服務器需要在處理請求的同時等待一些條件的情況下，通常是這樣的。這種情況的一個例子是從當前為空的JMS隊列中出列的客戶機請求。在同步模型中，為請求服務的線程阻塞，直到隊列中有要返回客戶機的消息。在異步模型中，線程可以將該請求放在一邊，而繼續為其它請求進行服務。當消息被放入隊列中時，可以發現該請求，并且將響應發送給客戶機。本發明允許服務器支持對RMI和servlet請求的異步響應。
Servelet特定的servlet可以在其調配描述符中聲明為異步。當異步servlet的服務方法返回時，不再對那個請求采取行動。servlet負責在某處存儲該請求，從而在發生其它行為之后，該請求可以被檢索，并發送響應。在此點上，必須對將要涌向流中的請求調用特定的發送()方法，將該請求記入日志，并且如果其保持有效連接，則用多路復用器登記界面以接收更多數據。創建以下執行是重要的，即確保資源通過使長運行請求超時而適當被釋放，由此釋放資源以進行無用數據收集和其它清除。
JSP還可以通過使用JSP標記庫以相似的方式支持異步模型。這些標記庫由http開發者/頁面創作者用來指定網頁中哪個部分應在異步事件之前執行而哪個部分應在異步事件之后執行。標記庫使得創作者能夠訪問應該在異步事件發生和JSP頁面執行應該恢復時被通知到的對象。
當使用標記庫時，頁面的執行上下文可以在登記異步事件之前自動存儲。以這種方式，有可能使JSP創作者隱藏許多異步編程的細節。JSP不需要關心狀態維持。任何標準范圍(頁面、請求、會話或應用程序)中存儲的狀態將按其使用同步JSP時采用的方式繼續工作。
前面對本發明的描述是為了說明和描述的目的而提供的。其并不打算窮盡，或將本發明限定為所公開的精確形式。顯然，許多修改和變更對本領域技術人員是顯而易見的。選用和描述實施例是為了最佳地說明本發明的原理及其實踐應用，從而使本領域技術人員能夠明白本發明適用于預想的特定用途的不同的實施例和各種修改。期望本發明的范圍由所附權利要求及其等價物限定。
權利要求
1.用于在爪哇小服務程序和小服務程序處理器之間進行異步消息接發的系統，包括服務器，包括小服務程序和小服務程序響應處理器；HTTP接口，用于從HTTP客戶機接收請求，并向HTTP客戶機發送響應；并且其中來自客戶的請求允許小服務程序立即返回一定的響應數據，并且設置響應代碼用于后續的響應。
2.如權利要求1所述的系統，其中所述小服務程序后續響應由響應命令觸發，以發送額外的響應數據。
3.如權利要求2所述的系統，其中所述響應命令是JMS消息。
4.如權利要求1所述的系統，其中小服務程序和小服務程序響應處理器的機能經由JSP標記庫對用戶公開。
5.如權利要求4所述的系統，其中所述JSP標記庫用于指示哪個HTTP響應數據應該立即返回，而哪個響應數據應該以后返回。
6.如權利要求4所述的系統，還包括對JSP執行上下文的支持。
7.一種用于在爪哇小服務程序和小服務程序處理器之間進行異步消息接發的方法，包括以下步驟從HTTP客戶機接收訪問小服務程序資源的請求；以及異步響應所述請求，其中來自客戶的請求允許小服務程序立即返回一定的響應數據，并且設置響應代碼用于后續的響應。
8.如權利要求7所述的方法，其中所述小服務程序后續響應由響應命令觸發，以發送額外的響應數據。
9.如權利要求8所述的方法，其中所述響應命令是JMS消息。
10.如權利要求7所述的方法，其中小服務程序和小服務程序響應處理器的機能經由JSP標記庫對用戶公開。
11.如權利要求10所述的方法，其中所述JSP標記庫用于指示哪個HTTP響應數據應該立即返回，而哪個響應數據應該以后返回。
12.如權利要求10所述的方法，還包括對JSP執行上下文的支持。
全文摘要
在使用小服務程序的傳統服務器中，當把HTTP客戶機(502)請求調度給線程時，調用適當的小服務程序(508)的服務方法。當該服務方法返回時，發送響應。在可以發送響應之前必須發生異步事件的情況下，這不是最佳的，因為運行該小服務程序的線程必須阻塞到該事件發生為止。本發明提供了這種請求的異步處理。在一個實施例中，本發明提供了小服務程序API的擴展，其允許服務器方法返回，從而在準備好發送請求之前釋放線程。這樣，當異步事件在以后發生時，可以完成和發送響應。
文檔編號G06F9/46GK1639703SQ02822993
公開日2005年7月13日 申請日期2002年10月4日 優先權日2001年10月5日
發明者亞當·梅辛杰, 薩姆·普拉拉, 戴夫·布朗 申請人:Bea系統公司