基于CXF的SOA應用設計與實現

張同楊

摘要：本文針對異構系統集成中數據共享問題，通過剖析Apache CXF開源框架體系結構及其組件構成，分析CXF框架及SOA同類框架在不同條件下的性能對比，結合集團級業務信息系統整合特點，給出基于CXF框架構建SOA的方法。理論分析與系統測試都表明Apache CXF在集團級異構信息系統集成方面具有明顯優勢。

Abstract： Aiming at the problem of data sharing between heterogeneous systems， by analyzing the open source framework architecture of Apache CXF and its components， this paper analyzes the performance comparison between the CXF framework and the other SOA framework under different conditions. Combined with the practice of group business information system integration， this paper gives the method of building SOA application based on CXF framework. Both theoretical analysis and system test show that Apache CXF has the obvious advantages in the integration of heterogeneous information systems.

關鍵詞：面向服務架構；CXF；系統集成；SOA

Key words： service-oriented architecture；CXF；system integration；SOA

中圖分類號：TP399 文獻標識碼：A 文章編號：1006-4311（2017）32-0083-05

1 SOA

集團級業務系統數據一般涉及總部、區域公司、二級單位、基層單位業務數據，以及諸如身份認證系統、人力資源系統、郵件系統、設備信息系統等其他集團級業務數據，業務數據范圍廣泛、種類繁多。集團級業務系統持續集成所屬單位業務系統、其他集團級業務系統的實時數據，豐富和完善集團級業務系統數據、提高數據質量、降低數據導入導出復雜度、減少人工介入整理數據的工作量，在業務運營實踐中具有重要的現實意義。

然而，基于功能或過程的企業架構一般是不同平臺、不同開發工具、不同管理規范、不同需求、不同時期研發的多階段交錯復雜業務系統，體系結構、平臺技術類型差異較大。這種差異和復雜嚴重影響了企業業務系統的敏捷性和穩定性，從而影響到企業領導者的業務決策和企業核心能力的發揮。面對瞬息萬變的市場需求，企業需要具有快速反應、敏捷生存的能力，從而要求企業管理業務系統必須具有敏捷服務、快速重構、資源重用及自由擴充等特點。

1.1 SOA設計理念

SOA設計理念以“支持異質、分散和容錯”保持系統靈活性，以編排松散耦合軟件服務發布業務邏輯。在企業應用集成領域中，SOA理念復用企業現有應用，保護企業既有信息投資，對企業中的業務流程進行靈活重構與優化，以服務方式構建業務流程和服務對象，增強業務的適應性和敏捷性。

1.2 SOA設計原則

SOA設計保持靈活性和松散耦合，設計原則主要是一致性原則，SOA架構應采用所有參與者都一致理解的方式整合內容，統一管理，以減少開發、集成及維護工作；服務粒度封裝適中原則，即應有利于可用性、可維護性、可操作性、可拓展性及易用性，統籌適度封裝操作數量；自治原則，所有服務自我管理，獨立部署、版本控制及管理，單一更改不影響整個系統；高內聚原則，一個服務基于一個主題進行合并和組裝；松耦合原則，服務之間透明訪問，一服務改變不影響其他服務；服務調用原則，平臺技術中立，支持多種可傳輸協議和數據格式。

1.3 SOA協議棧

SOA架構通過統一不同廠家和用戶的技術標準共識，構建協作規范以屏蔽差異。目前SOA技術標準分3類：元數據標準、基礎通信標準和信息交互標準，從角色功能上劃分為傳輸層、消息層、描述層、管理層、服務組合層和表示層等6層，如圖1所示為SOA協議棧層次結構。

2 Apache CXF基礎架構及組件

ApacheCXF框架是由ObjectWeb Celti和CodeHaus XFire合并成立。ObjectWeb Celtix是開源Java ESB框架，XFire則是SOAP堆棧。ApacheCXF融合ObjectWeb Celtix和CodeHaus XFire兩個開源框架的功能，提供實現SOA所需要的核心ESB功能，包括SOA服務創建，服務路由，及QoS功能。CXF支持JAX-WS標準，提供對多種 Binding、DataBinding、Transport 以及各種 Format 的支持。CXF可以根據實際需要，采用代碼優先（Code First）或 WSDL 優先（WSDL First）發布和使用Web Services。Apache CXF支持SOAP、XML/HTTP、RESTful HTTP或CORBA等協議，簡化Service創建，易于和Spring無縫集成、易于異構信息系統的持續集成，并提供數據安全傳輸機制。

2.1 Apache CXF體系結構

CXF框架不為各組件創建和維護單獨的信道，而是使每個組件邏輯上與總線相連，以使所有組件相互連接起來。Bus組件是CXF框架的核心組件，為共享資源提供了一個可配置的場所。CXF框架使用Spring依賴注入、以總線方式串接Messaging組件、Interceptors組件、Transport組件、Data Binding組件、Frontend組件、Service Model組件、Binding組件和WS-Support組件，以使得各個組件相互通訊。endprint

在具體實現中，抽象類AbstractBasicInterceptor Provider實現InterceptorProvider接口，CXFBusImpl繼承AbstractBasicInterptorProvider類。ExtensionManagerBus類繼承CXFBusImpl類以實現Bus拓展性。所有對CXF的Data Bindings、Binding、Transport等功能的引用最終轉化為Bus組件的方法和內容。圖3示出了BUS組件的實現類結構圖。

通過對Bus進行擴展，可以方便地容納自己的資源，或替換現有的資源。Bus默認以Spring依賴注入，串接運行態各組件。Bus默認由SpringBusFactory實現，在構造過程中，SpringBusFactory搜索META-INF/cxf（就包含在 CXF的Jar中）下的所有Bean配置文件，構建單獨ApplicationContext。

2.2 消息組件和攔截器

消息組件、攔截器組件和相位組件共同構成CXF框架消息層。Apache CXF的Messaging、Phase和Interceptors類結構如圖4所示。Messaging 接口是CXF傳遞信息的基礎，所有操作最終都轉化成對一定格式消息的操作。圖4示出了CXF中消息層各組件實現類結構圖。

CXF以消息處理為中心，建立在一個由消息、攔截器和攔截器鏈（Interceptpr Chain）組成的通用消息層之上。CXF通過Interceptors對消息進行處理，實現諸如消息壓縮、SOAP消息處理等主要功能。攔截器的通用方法主要有handleMessage和handleFault，分別對應消息處理和錯誤處理。一般在消息傳遞及處理的過程中，通過攔截器對CXF進行安全認證等功能拓展。圖5示出的代理模式，將在生成目標對象前創建一個具有與原初目標對象相同接口方法的代理，并在真實方法生效前，在代理的方法中添加定制特性方法實現細節業務邏輯。

CXF框架組合多個攔截器形成攔截器鏈，其中InterceptorChain用于實現增減Interceptor、控制消息處理及處置異常消息功能。圖6及圖7示出Apache CXF攔截器客戶端實現過程和Apache CXF攔截器服務端實現基本過程。

2.3 前端編程模型

前端組件（Front-Ends）為CXF框架提供了創建服務的編程模型。CXF服務器端基于JAX-WS和JAX-RS規范的Frontend組件與客戶端交互。在實現上，JAX-WS和JAX-RS提供FactoryBean部件依賴于Frontend組件的FactoryBean類，而FactoryBean類由依賴于由Client、Endpoint及Server接口實現的Endpoint組件，該組件通過Interceptor接口、Fault接口和Interceptorchain接口依賴于Interceptors組件。圖8示出了CXF前端應用類結構，ServerFactoryBean類作用于服務器端點，AbstractServiceFactory類應用于簡化前端模式的實現，而ClientFactoryBean類和ClientProxyFactoryBean類都基于ClientFactoryBean類。（圖8）

2.4 Service模型

CXF框架中的服務通過服務模型來表示。它主要有兩部分：ServiceInfo和服務本身。ServiceInfo作用類似WSDL，包含接口信息、綁定、端點（EndPoint）等信息；服務則包含了ServiceInfo、數據綁定、攔截器和服務屬性等信息。可使用Java類和WSDL來創建服務。一般是由前端ServiceFactory完成服務的創建。

在具體實現上，動態客戶端應用中Service組件包括Service、ServiceBuilder和ServiceImpl三個接口實現factory、invoker和model組件。其中model核心接口是ServiceInfo根組件，分別由InterfaceInfo組件、BindingInfo組件和EndpointInfo組件繼承。

2.5 數據綁定、綁定及傳輸協議組件

綁定提供了在傳輸之上映射具體格式和協議的方法，主要的兩個類是Binding和BindingFactory。BindingFactory負責創建Binding。

Data Bindings以生成XML schema的方式實現XML和Java之間的映射，數據綁定組件由Data Bindings主接口和Aegis組件、JAXB組件、XMLBeans組件及MTOM組件構成。綁定組件由Bindings接口（Binding、BindFactory、BindFactoryManager）和coloc、CORBA、http、object、SOAP和XML六個實現組件構成。

為了對綁定和前端屏蔽傳輸細節，CXF框架通過注冊MessageObserver獲得通知的方式，提供用于消息發送的Conduit傳輸對象和Destination消息接收對象。在具體實現上，CXF傳輸組件由Transport接口（Conduits對象和Destiations對象）和8個基礎業務實現組件（http、http_jetty、http_osgi、https、https_jetty、jms、servlet和loca Transport組件）構成。

3 異構系統集成體系結構

在設計實現中，基于SOA設計理念定義的規范和標準，無須了解交互方系統內部實現細節，屏蔽Windows、Linux及Android等不同平臺下的Java、.NET、C/C++、C#各類語言的差異，業務系統CXF框架作為對外界業務系統交互的SOA引擎，通過webservice的方式對基于XML規范的WSDL文件操作，實現異構系統數據共享。圖9指出了集團級業務系統基于CXF框架集成異構業務系統的基本結構。endprint

服務器端調用方法把XML格式的SOAP請求/響應消息轉換成Java目標方法調用，客戶端調用方法把對SEI代理的方法調用轉換成XML格式的SOAP請求和響應，SOAP消息處理結構如圖10所示，SOAP消息的序列化與反序列化。

基于CXF基礎框架構建SOA應用，實現上述序列化與反序列化過程，一般采用以下基本步驟：

①導入%CXF_HOME%＼ lib下jar包配置基礎編譯環境。

②編寫服務接口基類。

package com.cnpc.server；

import java.util.List；

import javax.jws.WebParam；

import javax.jws.WebService；

import com.cnpc.pojo.User；

@WebService

public interface HelloWorld {

String sayHi（@WebParam（name="text"）String text）；

String sayHiToUser（User user）；

String[] SayHiToUserList（List userList）；

}

③編寫服務接口的實現類

package com.cnpc.server；

import java.util.LinkedHashMap；

import java.util.List；

import java.util.Map；

import javax.jws.WebParam；

import javax.jws.WebService；

import com.cnpc.pojo.User；

@WebService（

endpointInterface="com.CNPC.server.HelloWorld"，

serviceName="HelloWorld"）

public class HelloWorldImpl implements HelloWorld {

Map users =

new LinkedHashMap（）；

public String sayHi（@WebParam（name = "text"） String text） {

return "Hello，"+text；

}

public String sayHiToUser（User user） {

users.put（users.size（）+1， user）；

return "Hello，"+user.getName（）；

}

public String[] SayHiToUserList（List userList） {

String[] result = new String[userList.size（）]；

int i = 0；

for（User u：userList）{

result[i] = "Hello " + u.getName（）；

i++；

}

return result；

}

}

④服務發布實現類

package com.cnpc.server；

import javax.xml.ws.Endpoint；

public class webServiceApp {

/**

* @param args

*/

public static void main（String[] args） {

System.out.println（"web service start"）；

HelloWorldImpl implementor =

new HelloWorldImpl（）；

String address =

"http：//localhost：8080/helloWorld"；

Endpoint.publish（address， implementor）；

System.out.println（"web service started"）；

}

}

⑤驗證服務發布情況如圖11。

⑥編寫實現客戶端實現類

package com.cnpc.client；

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean；

import com.cnpc.pojo.User；

import com.cnpo.server.HelloWorld；

public class HelloWorldClient {

/**

* @param args

*/

public static void main（String[] args） {

JaxWsProxyFactoryBean jwpfb = new JaxWsProxyFactoryBean（）；

jwpfb.setServiceClass（HelloWorld.class）；

jwpfb.setAddress（"http：//localhost：8080/helloWorld"）；

HelloWorld hw = （HelloWorld） jwpfb.create（）；

User user = new User（）；

user.setName（"某油田"）；

user.setDescription（"第一采油廠"）；

System.out.println（hw.sayHiToUser（user））；

}

}

4 傳輸性能分析

4.1 無附加安全策略測試

圖12測試時間表明，至少在測試程序中使用的數據，Metro2.0平均請求處理速度快于Axis2及CXF。在XML數據轉換中，此三種框架協議棧具有相同的處理速度。這是在Metro和CXF框架中可以預料的，因為Metro和CXF都是基于JAXB標準實現數據轉換的。由此可以判斷，Axis2數據綁定框架實現以及Axis2采用也默認采用的數據綁定實現具有與JAXB一樣的運行速度。

具有安全策略的測試性能比較，圖13顯示了基于如下安全配置的測試時間：①普通型：無安全策略（數據同圖12）。②用戶名令牌：WS安全策略基于純文本用戶令牌環請求。③標記：WS安全策略基于消息體和消息頭標記時間戳。④加密標記：安全策略基于標記時間錯的消息體和消息頭，并加密消息體。圖13，顯示了對于1000個輕量級請求的指標化測試時間。

4.2 歸一化耗時對比

圖14顯示了基于相同的1000個請求及輕量級響應的歸一化相對時間。以上四種安全配置的測試結果顯示，Axis2總是響應最慢的集成框架。Metro與CXF的差別小于CXF與Axis2：的差別， Metro框架總是最快的，Metro 框架比CXF框架快了10%，CXF比Axis2快近兩倍。圖15顯示基于100個重量級響應指標化測試時間對比結果。

圖16顯示相對時間（均歸一化為CXF結果）基于相同的100個請求和較重量級響應。在這個測試用例中，Axis2又一次比Metro和CXF（再次約是CXF的一半速度）慢好多，在輕量級消息響應中 Metro和CXF的差別大于逆轉 CXF大約快了15%。在這個測試用例中，Axis2又一次比Metro和CXF（再次約是CXF的一般速度）慢好多，在輕量級消息響應中Metro和CXF的差別大于逆轉CXF大約快了15%。基于以上測試報告，Metro 2.0在基本的請求/響應處理過程中比Axis 2及CXF 2.17要快。對于WebService安全性問題，Metro的XWSS函數庫整體上比Axis2和CXF采用的函數庫快。

4.3 性能分析

綜合以上測試結果分析，CXF框架在服務提供應用中對重量級長消息（500KB及以上）的傳輸性能比Axis2具有更短的時間響應時間。

5 結束語

本文在解析SOA設計理念的基礎上，深入剖析了Apache CXF開源框架體系結構及其組件構成，剖析附加安全策略與非附加安全策略的情況下CXF傳輸性能，并給出基于CXF異構系統集成的一種實現方法。SOA和開源框架對各類異構系統的集成在企業業務整合開展過程中具有重要作用。SOA的實施過程無論采用自頂而下逐步深入細化的過程，還是采用自底向上業務逐步融合的過程，都是一個持續集成生長發展的過程。SOA實施過程無論從初始、到受控管理、到定義清晰、到量化管理以致持續優化不斷成熟并使組織受益，都是一個持續發展、逐步推進的過程。

參考文獻：

[1]盧致杰，覃正，韓景倜，王立華，等.SOA體系設計方法研究[J].工業工程，2004，7（6）：14-16.

[2]湯瀚秋.基于Axis2和CXF的Web Service傳輸性能測試方案研究[J].軟件導刊，2012，11（6）：15-16.

[3]Krafzig D， Banke K， Slama D. Enterprise SOA： Service-Oriented Architecture Best Practices. USA， Prentice Hall PTR， 2004： 41-59.

[4]Nicolai M.著.SOA實踐指南：分布式系統的設計藝術[M]. 程樺譯.北京：電子工業出版社，2008：1-283.

[5]Mark D.Hansen著.使用Java Web 服務構建SOA[M].成保棟譯.北京：電子工業出版社，2009：1-535.

[6]SOA Design Patterns [M]. 1st ed. Boston： Pearson Education， Inc， 2009.

[7]A Study Case of Restful Frameworks in Raspberry Pi：A Performance and Energy Overview： Luiz Henrique Nunes， Edvard Oliveira， Julio Cezar Estrella， Stephan Reiff-Marganiec

[8]劉壯業.面向服務架構若干關鍵問題研究 [J].計算機工程與設計，2009，30（3）：600-603

[9]盧致杰.覃正.韓景倜.王立華.SOA體系設計方法研究[J].工業工程，2004，7（6）：15-19

[10]Hanscn M.D.著.使用Java.Web服務構建SOA[M].成保棟譯.北京：電子工業出版社，2009：1-283.

[11]吳家菊.劉剛.基于面向服務架構的敏捷供應鏈信息集成研究 [J].計算機工程與設計，2006，27（19）：3445-3448.

[12]Nicolai M.Josuttis著.SOA 實踐指南-分布式系統設計的藝術[M].程樺譯.北京：電子工業出版社，2008：1-283.

[13]余浩，朱成，丁鵬，著.SOA實踐-構建基于Java Web 服務和BPEL的企業級應用[M].北京：電子工業出版社，2008：1-310.

[14]Thomas Erl著.SOA服務設計原則[M].郭耀譯.北京：人民郵電出版社，2009：1-346.

[15]Thomas Erl Clive Gee.Jurgen Kress著.下一代SOA服務技術與面向服務簡明指南[M].盧濤譯.北京：電子工業出版社，2015：1-196.endprint