在cxf中自定義jsr的簡單介紹

• 1、cxf 如何獲取異常報文 在代碼中是怎麼實現的
• 2、SpringBoot+CXF 實現簡單的webservice,並支持Basic驗證
• 3、cxf怎樣提高webservice性能，及訪問速度調優

　1. 單獨建立線程池，線程池中的所有工作線程從線程池任務隊列中讀取任務，啟動SOAP報文下發工作。

2. 建立連接池，線程池中線程從連接池獲取一個連接將SOAP報文下發到網元上。

3. 其他線程：SOAP報文讀取線程，將生成的SOAP報文文件映射到內存文件，每次讀取1w條數據到SOAP報文下發隊列，SOAP下發隊列數據結構進行

封裝，添加信號量，每次數據push_back一條信號量遞增

SOAP報文下發線程，獨立的線程從SOAP報文下發隊列中取數據，等待下發隊列的信號，如果有信號則從隊列中取數據，構建下發任務

將下發任務壓入線程池工作任務隊列，同時信號量遞減1

SOAP報文保存線程，SOAP報文下發後會收到網元的響應報文，解析模塊分析響應報文，獲取SOAP發送報文的執行結果，並將執行失敗

的SOAP報文進行保存，對執行成功的報文寫入日誌。

4. 連接池：連接池工廠，連接池，連接器實體

連接池工廠建立連接池名稱和連接池實例的映射，管理所有連接池。

連接池管理所有會話連接（IOSession），建立空閑會話隊列和使用會話隊列，如果空閑隊列為空，同時又有新的連接請求，則建立一條新的連接。

連接數不能超過最大連接數，如果已經達到最大連接數，則進入等待狀態，當空閑隊列空狀態取消

AttachHttpHeader() // 附加Http報頭

DetachHttpHeader() // 獲取Http響應報頭

PraseHttpHeader(); // 解析Http響應報頭

隊列採用狀態模式，空閑狀態

隊列包含一個事件，類型轉換操作符到事件句柄，當空閑隊列為空時，事件變為無信號狀態，當變為非空時變為有信號狀態。每次出現這種狀況都要寫日誌信息。

CXF內置了很多攔截器，大部分默認添加到攔截器鏈中，有些攔截器也可以手動添加，如CXF的日誌攔截器。如果需要自定義攔截器，只要繼承AbstractPhaseInterceptor或者AbstractPhaseInterceptor的子類（如AbstractSoapInterceptor）

如果是傳統的spring+cxf 項目，攔截器的寫法是一樣的，只是發布和配置的方法在cxf的配置文件的xml中進行

WSDL 地址：

CXF 自動編譯解析的客戶端

客戶端basic 認證調用

1、 啟用FastInfoset(快速信息集)

webservice的性能實在是不敢恭維。曾經因為webservice吞吐量上不

去，對webservice進行了一些性能方面的優化，採用了FastInfoset，效果很明顯，極端條件下的大數據量傳輸，性能提高60%，他可以減

少傳輸成本，序列化成本和xml解析成本。

Cxf提供了FastInfoset協商機制，實現類見org.apache.cxf.feature.FastInfosetFeature，在bus中啟用如下配置：

cxf:featurescxf:fastinfoset force=”false”//cxf:features

Force=false表示服務端和客戶端第一次通信時會協商(通過檢查標準的HTTP頭的Accept欄位，值為MIME類型的application/fastinfoset)是否啟用FastInfoset支持，如果客戶端不支持，則不啟用快速信息集。

需要在pom中添加依賴：

dependency

groupIdcom.sun.xml.fastinfoset/groupId

artifactIdFastInfoset/artifactId

version1.2.9/version

typejar/type

scopecompile/scope

/dependency

FastInfoset參考：

client和service端都要配置

2、 啟用gzip壓縮支持

客戶端和伺服器端是否使用Gzip壓縮，也是基於http協議協商的(檢查請求

header 中是否有Accept-encoding:gzip)。但是這裡需要仔細權衡下。對於小數據量，啟用gzip壓縮支持是吃力不討好的行為，

數據量很小的時候，gzip壓縮結果不明顯，還浪費cpu。我們需要權衡數據大小，按照經驗設置threshold為10*1024byte。

在bus中啟用如下配置：

bean class=”org.apache.cxf.transport.common.gzip.GZIPFeature “

property name=”threshold”value10240/value/property

/bean

官方文檔指定是是配置org.apache.cxf.transport.http.gzip.GZIPFeature，但是這個類會找不到，可能是官方文檔年久失修，造成一些混亂。官方文檔中也沒提示指定threshold，請參考GZIPFeature源代碼。

參考

3、 使用slf4j代替cxf默認日誌組件

CXF 默認使用java.util.logging作為日誌列印組件，其性能我就不過多評價，也不太便於我們做統一日誌管理。目前系統使用的slf4j作為日誌列印組件，替換如下：

在classpath中加入META-INF/cxf/org.apache.cxf.Logger文件，文件內容為

org.apache.cxf.common.logging.Slf4jLogger

4、 測試中啟用日誌

bus中加入cxf:logging/，請在測試環境中啟用有助於debug

補充：

1、如何自定義返回碼：

請求在service中處理遇到異

常後，會調用請求鏈中所有攔截器的handleFault方法，參考PhaseInterceptorChain#unwind，然後判斷請求是否單向請

求，如果不是，則構建異常請求鏈，並構建異常message對象，調用異常請求鏈中的handleMessage 方法(參

考：AbstractFaultChainInitiatorObserver)

JAXWSMethodInvoker

轉發soap請求到指定對象的方法，如果在請求處理失敗，調用updateHeader方法，把請求時的soap

header放入返回header中。但是不同通過繼承JAXWSMethodInvoker來實現清除異常時soap

header也返回給客戶端的問題，因為JAXWSMethodInvoker沒有採用注入的機制

(JaxWsServerFactoryBean#createInvoker)也沒有chain.異常時，會由這些攔截器處理返回請求：

setup [ServerPolicyOutFaultInterceptor]

prepare-send [MessageSenderInterceptor, Soap11FaultOutInterceptor]

pre-stream [LoggingOutInterceptor, StaxOutInterceptor]

pre-protocol [WebFaultOutInterceptor]

write [SoapOutInterceptor]

攔截器初始化類OutFaultChainInitiatorObserver

我們可以在異常鏈中加入清理soap header的攔截器SoapHeaderOutFilterInterceptor，清理掉在系統異常時soapheader中有信息的問題。

返回錯誤狀態碼，在執行Soap11FaultOutInterceptor攔截器中被寫死。

message.put(org.apache.cxf.message.Message.RESPONSE_CODE, new Integer(500));

為了使返回數據中有錯誤碼，需要在Soap11FaultOutInterceptor後面加入攔截器

2、在項目測試時遇到一個報錯

invalid LOC header (bad

signature)，這個問題是因為jar包損壞照成的，雖然構建路徑中有這個jar，但是還是會出現loadClass失敗，清理maven 本地倉

庫目錄的jar，修改pom(比如加上一空行)讓m2e重新載入。

3、Cxf中有一個很不錯的特性，支持javascript訪問soap

webservice，客戶端訪問類似的請求，會生成

javascript 客戶端，js編程時就可以使用此客戶端提供的對象，啟用此功能需要在引入

import resource=”classpath:META-INF/cxf/cxf-extension-javascript-client.xml” /並且在依賴中加入：

dependency

groupIdorg.apache.cxf/groupId

artifactIdcxf-rt-javascript/artifactId

version2.4.1/version

typejar/type

scopecompile/scope

/dependency