Axis2的session 會話 管理

2021-07-24 17:22:44 字數 4299 閱讀 7235

本文是對《axis2 session management》的翻譯,所依據的英文在以下是翻譯內容。

web服務有著很大的需求,很多人進入了web服務這一領域,其結果是人們需要web服務具有更多的特性,以便使用web服務可以完成任何事情。但web服務從設計上來說是沒有狀態的。在web服務世界起初的時候是沒有管理會話的概念的,但是現在形勢改變了:沒有會話管理,開發者是無法開發出高階的應用程式的。乙個很好的例子是銀行系統,您登入進入系統,然後取錢,最後退出登入。

如果我們把這一場景對映到web服務:

您可以很容易的看出上述3個操作是相互關聯的,同乙個使用者進行3個呼叫操作。所以,這意味著需要有地方來跟蹤使用者,另外有地方在使用者呼叫方法期間跟蹤使用者資料。這也就暗含了需要會話管理。

當開發高階應用程式時,我們必須打破現有的規則;否則,沒有人能夠開發出真正的web應用程式。雖然web服務本質上是無狀態的,但是需要在web服務之上增加一層會話管理的功能。

axis2的無狀態本質

axis2的優秀設計原則之一是保持邏輯和狀態的分離,所以它沒有元件需要維護會話,實際上也是這樣做的。在axis2的處理程式中,傳輸部分,甚至aixs引擎部分都是無狀態的。因此,對axis2來說多個例項和乙個例項是沒有區別的。

作為最佳實踐,處理程式或傳輸部分不應該保持任何例項變數(如果可能會變化的話),因為那樣會打破axis2無狀態的本質。所以,如果處理程式或傳輸部分需要有狀態的方式,正確的做法是在需要的時候儲存狀態和axis2的狀態層次,而不是保持例項變數。

axis2的會話型別

像上面提到的,企業級web服務無法得到認可除非引在web服務引擎中入了會話概念。換種說法,因為存在不需要維持會話的web服務,讓每種web服務引擎都支援會話管理這樣的說法是不對的。乙個很好的例子是google搜尋服務和google拼寫檢查服務。

會話管理的直接影響是占用記憶體空間的上公升和效能的降低,所以您需要乙個折中:您的服務是否要支援會話並提供狀態。axis2是定位於企業級web服務引擎的,所以它必須提供會話管理。

有幾種型別的會話,它們的生命週期是各不相同的。有些會話存在幾秒鐘,而有些會話的生命週期和系統一樣長。axis2設計為支援4種型別會話,它們存在很多差別,希望您能夠使用以下4種會話型別開發出各種web服務。

axis2的上下文層次結構

在深入討論axis2的會話之前,理解axis2的各種上下文是很有幫助的。如上所述,axis2保持邏輯和狀態的分離,上下文是儲存狀態的地方。在axis2中有5種型別的上下文:

與會話範圍無關,當會話開始和結束時,axis2會通知服務的實現類,但是需要在服務的實現類中增加兩個方法。

public void init(servicecontext servicecontext)  

public void destroy(servicecontext servicecontext)

除此之外,當服務接收到乙個請求時,它會傳入相應的操作上下文作為引數進行通知。如果服務想訪問輸入訊息的上下文或輸入的soap訊息,可以在服務的實現類中加入以下方法來做到這一點,在真正的方法呼叫之前呼叫這一方法。

public void setoperationcontext(operationcontext operationcontext)

請求會話範圍(request session scope)

請求會話是axis2預設的會話型別,部署服務時沒有指定會話管理的內容,服務會被部署為請求會話型別。這種會話的生命週期被限定在方法呼叫的生命週期之內,或者請求的處理時間內。所以,當部署服務為請求範圍的服務時,是沒法管理會話的;這與沒有會話是一樣的。

一旦把服務部署為請求會話範圍的服務時,每個服務的實現類就會準備建立服務例項。例如以請求範圍的方式建立了乙個名為「foo」的服務,如果客戶端呼叫了10次,就會有這個服務實現類的10個例項。如果想顯式的指定服務的會話範圍,可以在services.xml中的service標籤中增加乙個scope屬性,如下:

即使把服務部署為請求範圍內的,在axis2中也有一些方法管理會話。一種方法是在axis2的全域性執行時(配置上下文)中儲存狀態,在需要的時候獲取它。

soap會話範圍(soap session scope)

soap會話的生命週期比請求會話的稍長,以soap會話的方式部署服務需要修改services.xml。管理soap會話需要客戶端和服務都能識別會話,換句話說,客戶端訪問相同會話需要傳輸會話相關的資料,服務需要以會話相關的資料來驗證使用者。

管理soap會話,客戶端需要在soap頭中增加名為「servicegroupid」的引數。soap會話不僅提供乙個服務呼叫的會話,還提供乙個服務組中多個服務的會話。只要在同乙個soap會話中,可以在服務上下文中管理服務相關的資料;如果想在組中多個服務中共享資料,可以使用服務組上下文。

以soap會話的方式部署了服務,當客戶端第一次訪問服務的時候,axis2會產生「servicegroupid」,並在wsa:replyto中以引用引數的方式向客戶端傳輸:

urn:uuid:65e9c56f702a398a8b11513011677354   

如果客戶端想保持在同乙個會話內,它要複製那個引用引數,並在第二次呼叫服務的時候傳回伺服器。只要客戶端傳輸了正確的「servicegroupid」,它就會在同乙個會話內,服務也可以維護會話相關的資料。與請求會話不同,soap有預設的失效期,如果客戶端超過30秒沒有連線服務,會話就會過期。如果客戶端傳送了過期的「servicegroupid」,會得到axis錯誤。

管理soap會話需要銜接服務端和客戶端的對應模組。部署服務為soap會話方式需要以如下方式修改services.xml:

傳輸會話範圍(transport session scope)

在傳輸會話方式下,axis2以傳輸相關的會話管理技術來管理會話。例如,在http協議下,以http cookies的方式來管理會話。會話的生命週期是由傳輸來控制的,而不是axis2;axis2在傳輸會話內儲存服務上下文和服務組上下文,所以在會話生命期內服務都可以訪問這些上下文。

傳輸會話的主要優勢是在乙個會話內與多個服務組互動。在soap會話中,無法在兩個服務組間進行互動,而在傳輸會話中就可以。這種情況下,服務例項的數量取決於傳輸會話的數量。

部署服務為傳輸會話方式需要以如下方式修改services.xml:

如果打算使用axis2,以傳輸會話方式部署服務需要對axis2.xml做些修改。這主要是為了提高記憶體的使用率;否則,無論是否以傳輸會話方式部署服務,axis2都會在傳輸的級別建立會話物件;有了這些變化,axis就不會建立無用的物件了。為了管理傳輸級別的會話,需要在axis2.xml中設定「managetransportsession」引數為「true」:

true

應用範圍的會話與其他會話方式相比具有最長的生命週期,應用會話的生命週期與系統的生命週期一樣長。如果以應用範圍會話的方式部署服務,只會有服務的乙個例項,並且這個服務只有乙個服務上下文。在axis2中,如果考慮記憶體占用,並且不想管理會話,乙個好的方法是把服務部署為應用範圍的。

當把服務部署為應用範圍的會話方式時,客戶端不需要傳送額外的資料以使用同乙個會話。部署服務為應用範圍會話方式需要以如下方式修改services.xml:

服務客戶端管理會話

客戶端管理會話需要做一些工作。如上所述,客戶端如果想在soap會話和傳輸會話方式下保持在同乙個會話中,需要傳輸一些會話相關的資料。對soap會話來說,需要複製所需的引用引數;對傳輸會話來說,需要訪問傳輸以複製和傳送cookies。

為了簡化開發,axis2有內建的管理會話的功能,在客戶端設定乙個標誌就可以了。這樣,只要使用同乙個客戶端,就會往服務端傳送會話相關的資料。所以,如果想保持在同乙個會話內,最主要的一點就是使用同乙個客戶端呼叫服務。

如果想保持在同乙個會話內,可以用以下的方式建立服務客戶端,並且重用客戶端物件呼叫服務。

options options = new options();

options.setmanagesession(true);

serviceclient sender = new serviceclient(); 

sender.setoptions(options);

一旦按照如上方式建立了服務客戶端,如果服務部署為soap會話方式,客戶端會複製「servicegroupid」並在第二次呼叫的時候上傳服務端;如果伺服器是傳送的會話id,例如http cookies,客戶端就會復**務上下文(在客戶端)並在第二次呼叫的時候傳送給伺服器。

總結

無狀態是web服務的主要特性之一,但這對高階web服務開發來說是乙個限制。使用web服務開發企業級的應用並不容易,除非有乙個會話管理層。axis2有4中會話型別以解決企業級服務開發的問題。

axis2接收json 利用AXIS2返回JSON

在已經有axis2的基礎之上操作 4 在axis2.xml中新增json訊息格式,找到標籤,在這個標籤裡新增如下 段 class org.apache.axis2.json.jsonmessageformatter class org.apache.axis2.json.jsonbadgerfish...

axis2學習 axis2訊息處理機制

為了更好的理解axis2,我們首先看web services的訊息生命週期的概念。通常,訊息的生命週期如下圖 img 訊息傳送者應用建立原始的soap訊息 由相應的訊息頭和訊息體組成的xml檔案,一旦訊息準備完畢,就會把這些訊息通過http jms等方式傳送出去。如果axis2載入了其他的ws 模組...

Axis2 呼叫 流程

axis2看了一些資料 自己總結下 客戶端呼叫介面流程 首先是先 建立request soap包工廠 fac。建立 請求soap 包的工廠 private static omfactory fac omabstractfactory.getomfactory 先通過fac工廠 建立 sopa的 命名...