軟件開發(fā)接口資料

接口技術福建富士通信息軟件(ruǎnjiàn)有限公司FujianFujitsuCommunicationSoftwareCo.,Ltd.(FFCS)二〇一一年九月八日共七十六頁主流(zhǔliú)接口技術123XML解析(jiěxī)技術Webservice介紹內容提要4Webservice框架共七十六頁主流(zhǔliú)接口技術WEBServiceCorbaEJB消息(xiāoxi)隊列FTPHTTPSocket中間表共七十六頁WEBService基于HTTP傳遞xml定義的SOAP協議數據，是開放的標準，標準性高，擴展性好。優(yōu)點:因為是基于HTTP協議，耦合度低，可以方便穿越防火墻，目前有大量成熟應用，接口開發(fā)有很多支持工具和環(huán)境，開發(fā)工作量較低。缺點:性能方面相對于中間件服務(fúwù)調用較低共七十六頁Corba系統(tǒng)向外提供Corba服務，客戶端直接調用。優(yōu)點:跨平臺、跨系統(tǒng)、跨語言，性能很高，比較穩(wěn)定，擴展性良好。缺點:Corba產品不十分成熟、系統(tǒng)間耦合度增高，而且對于外部系統(tǒng)之間客戶端開發(fā)接口以及調試(diàoshì)工作量相對大一些，適用于實時性要求比較高的場合接口共七十六頁EJB系統(tǒng)向外提供服務供客戶端直接調用。優(yōu)點:性能很高，有成熟產品(chǎnpǐn)支持，可靠穩(wěn)定，擴展性良好。缺點:系統(tǒng)間耦合度增高，而且對于外部系統(tǒng)之間客戶端開發(fā)接口以及調試工作量相對大一些，十分適用于系統(tǒng)內部子系統(tǒng)之間的接口共七十六頁中間(zhōngjiān)表這種方式是通過數據庫中間表獲取系統(tǒng)的數據，將相關的數據同步到其他系統(tǒng)。優(yōu)點:接口實現簡單，效率高，缺點:系統(tǒng)間耦合度較高，對雙方(shuāngfāng)系統(tǒng)的穩(wěn)定性以及接口的穩(wěn)定性要求較高。共七十六頁接口(jiēkǒu)分類接口調用方式同步：調用方在調用接口后必須在接口的結果返回后才可以繼續(xù)執(zhí)行自己的任務異步：調用方在調用接口后不需要等待接口的結果返回，可以繼續(xù)執(zhí)行自己的任務接口交互方式實時：接口的響應速度有很高要求，通常(tōngcháng)要求接口處理能在秒級完成非實時：調用者對接口執(zhí)行速度要求不太高。接口數據量大數據量：指大量數據傳輸，通常是批量數據；小數據量：接口數據量偏小，一般小于100K的數據包接口頻率非周期：接口不按固定周期交互，通常為事件觸發(fā)，比如查詢；周期：接口按固定周期，比如按日、按周、按月、按小時、按分鐘或其他頻率交互。共七十六頁corba,ejb,webservice的區(qū)別(qūbié)Corba，EJB共同點：通過專有的網絡協議通訊(tōngxùn)不能跨平臺調用通過分布式對象調用來實現分布式架構,分布式架構是綁定在面向對象的機制上的分布式對象架構的缺陷在EJB2時代被充分暴露了出來webservices有一些明顯不同于Corba和EJB分布式對象架構的特征：通過標準SOAP協議通訊，一般走HTTP通道能夠跨平臺調用通訊格式是xml文本，而不是二進制數據格式通過RPC（RemoteProcedureCallProtocol）機制來實現分布式調用，而不是通過面向對象機制實現分布式調用

RPC是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。共七十六頁選擇(xuǎnzé)接口技術同步(tóngbù)實時小數據量WEBSERVICE、CORBA異步非實時小數據量接口表、WEBSERVICE異步非實時大數據量接口表、FTP

共七十六頁主流(zhǔliú)接口技術123XML解析(jiěxī)技術Webservice介紹內容提要4Webservice框架共七十六頁XML解析(jiěxī)技術XML解析技術分析(fēnxī)

所有的XML處理都從解析開始，無論是使用XSLT或Java語言，第一步都是要讀入XML文件，解碼結構和檢索信息等等，這就是解析，即把代表XML文檔的一個無結構的字符序列轉換為滿足XML語法的結構化組件的過程。XML解析技術的分類面向文檔的流式解析；面向文檔的對象式解析；面向文檔的指針式解析；面向應用的對象式解析；共七十六頁面向文檔的流式解析(jiěxī)技術流式解析是一種基于事件的解析過程，解析器順序讀取XML文檔，產生一個對應的事件流，并向事件處理程序發(fā)送所捕獲的各種事件，如元素開始和元素結束等，而事件處理程序則通過不同的方法處理這些事件。流式解析是將XML文檔作為一個數據流來處理，因此，它具有類似于流媒體的優(yōu)點，能夠立即開始讀取數據，而不是(bùshi)等待所有的數據被處理。而且，由于應用程序只是在讀取數據時檢查數據，不需要將整個文檔一次加載到內存中，使得在處理大型文檔時具有較好的時間和空間上的效率。然而效率的代價是易用性的降低，流式解析編程較為復雜，程序員需要負責更多的操作。并且由于應用程序沒有以任何方式存儲數據，所以使得更改數據或在數據流中往后移是不可能的。再加上它的單遍解析特性，意味著它也不支持隨機訪問。流式解析又分為兩種解析方式：推式解析(SAX)和拉式解析(StAX)。這兩種方式的主要區(qū)別在于是由解析器還是應用程序控制讀循環(huán)(讀入文件的循環(huán))。拉式解析:在這種解析方式中，應用程序控制著讀循環(huán)。循環(huán)中，應用程序負責反復調用解析器獲得下一個事件，直到文檔結束。推式解析:在這種解析方式中，解析器控制著讀循環(huán)，在文檔結束之前控制權不會返回給應用程序。解析器通過回調的方式進行數據處理。共七十六頁java常用(chánɡyònɡ)的XML解析技術DOM(DocumentObjectModel)W3C里邊一種成熟的標準。SAX(SimpleAPIforXML)一種被廣泛接受的XML的API，成為事實上的標準。StAX(StreamingAPIforXML)在JSR-173中提到的一種很有前途的新型解析模型。按照解析方式可分為:基于(jīyú)樹(tree-based),DOM基于事件(event-based),SAX,StAX共七十六頁DOM解析(jiěxī)技術DOM解析是面向文檔的對象式解析技術DOM解析器把XML文檔轉化為一個包含其內容的樹，并可以對樹進行遍歷。DOM是用與平臺和語言無關的方式表示XML文檔的官方W3C標準。DOM是以層次結構組織的節(jié)點或信息片斷的集合。這個層次結構允許開發(fā)人員在樹中尋找特定信息。分析該結構通常需要加載整個文檔和構造層次結構，然后才能做任何工作。由于它是基于信息層次的，因而DOM被認為是基于樹或基于對象的。DOM以及廣義的基于樹的處理具有幾個優(yōu)點。首先，由于樹在內存中是持久的，因此可以修改它以便應用程序能對數據(shùjù)和結構作出更改。它還可以在任何時候在樹中上下導航，而不是像SAX那樣是一次性的處理。DOM使用起來也要簡單得多。DOM解析模型的優(yōu)點是編程容易，開發(fā)人員只需要調用建樹的指令，然后利用navigationAPIs訪問所需的樹節(jié)點來完成任務?？梢院苋菀椎奶砑雍托薷臉渲械脑?。然而由于使用DOM解析器的時候需要處理整個XML文檔，所以對性能和內存的要求比較高，尤其是遇到很大的XML文件的時候。由于它的遍歷能力，DOM解析器常用于XML文檔需要頻繁的改變的服務中。共七十六頁SAX解析(jiěxī)技術SAX采用了“推模式”（pushmodal）解析SAX解析器采用了基于事件的模型，它在解析XML文檔的時候可以觸發(fā)一系列的事件，當發(fā)現給定的tag的時候，它可以激活一個回調方法，告訴該方法制定的標簽已經找到。SAX對內存的要求通常會比較低，因為它讓開發(fā)人員自己來決定所要處理的tag.特別是當開發(fā)人員只需要處理文檔中所包含的部分數據時，SAX這種擴展能力得到了更好的體現。但用SAX解析器的時候編碼工作會比較困難，而且很難同時訪問同一個文檔中的多處不同數據。SAX處理的優(yōu)點非常類似于流媒體的優(yōu)點。分析能夠立即開始，而不是等待所有的數據被處理。而且，由于應用程序只是在讀取數據時檢查數據，因此不需要將數據存儲在內存中。這對于大型文檔來說是個巨大的優(yōu)點。事實上，應用程序甚至不必(bùbì)解析整個文檔；它可以在某個條件得到滿足時停止解析。一般來說，SAX還比它的替代者DOM快許多。共七十六頁STAX解析(jiěxī)技術StAX是一種令人振奮的新型解析技術，和SAX一樣(yīyàng)，它也采用了事件驅動模型。不過，在對于事件的處理上，SAX采用了“推模式”（pushmodal），而StAX則使用的是“拉模式”（pullmodel）。從這個原理來判斷的話，StAX的實現顯然要更加靈活，程序可以選擇自己需要處理的部分，而SAX則一定會遍歷整個文檔。將StAX叫成“程序驅動模型”可能更利于理解一些。優(yōu)點：接口簡單，使用方便。采用流模型分析方式，有較好的性能。缺點：單向導航，不支持XPath，很難同時訪問同一文檔的不同部分。共七十六頁技術有利局限適用于DOM1.易于上手

2.豐富的

API，易于訪問

3.整棵樹被載入內存，能隨機訪問節(jié)點

4讀寫1.整個文檔必須一次解析完

2.載入文檔樹到內存代價昂貴

3.不利于實現對象類型綁定，需要給所有節(jié)點創(chuàng)建單獨的類型需要修改xml或者用來處理XSLT（不要用在對XML只有讀操作的程序中）SAX1.沒有將整個文檔讀入內存，內存耗費較低

2.“

推模式

”

允許注冊多種內容處理器

3只讀1.沒有內建的文檔導航支持

2.不能隨機訪問

XML文檔

3.不支持命名空間對XML只有讀操作的程序（不要用來操作和修改XML文檔）StAX1.有針對簡單和性能的兩種解析模式

2.由程序控制解析器，易于支持多輸入（

easilysupportingmultipleinputs）

3.強大的過濾功能有利于數據檢索

4讀寫

1.沒有內建的文檔導航支持

2.不能隨機訪問

XML文檔需要對XML文檔進行流處理而且支持命名空間的程序（不要用來操作和修改XML文檔）共七十六頁選擇(xuǎnzé)解析技術為了比較這五種方式在解析XML文檔時的性能表現，創(chuàng)建了三個不同大小的XML文檔：（100KB）、（1MB）、（10MB）。分別用以上解析方式對這三個XML進行解析，然后打印出所有的用戶信息，并分別計算它們所用的時間。測試代碼會在文章后面的附件中給出，這里只比較它們的耗時。由上面的測試結果可以看出，性能表現最好的是SAX，其次是StAXStream和StAXEvent，DOM和DOM4J也有著不錯的表現。性能最差的是JDOM。所以如果你的應用程序對性能的要求很高，SAX當然是首選。如果你需要(xūyào)訪問和控制任意數據的功能，DOM是個很好的選擇，而對Java開發(fā)人員來講，DOM4J是更好的選擇。如果只需要做XML文檔解析的話，綜合性能、易用性、面向對象特征等各方面來衡量，StAXEvent無疑是最好的選擇。

單位：s（秒）

100KB

1MB

10MB

DOM

0.146s0.469s

5.876sSAX

0.110s0.328s

3.547sJDOM0.172s0.756s45.447sDOM4J

0.161s0.422s5.103sStAXStream

0.093s0.334s

3.553sStAXEvent

0.131s0.359s

3.641s共七十六頁主流(zhǔliú)接口技術123XML解析(jiěxī)技術Webservice介紹內容提要4Webservice框架共七十六頁WebService簡介(jiǎnjiè)Webservice是描述一些操作（利用標準化的XML消息傳遞機制可以通過網絡訪問(fǎngwèn)這些操作）的接口。存在于互聯網當中的組件，具有獨立性，跨平臺和技術，通過URL進行定位調用Webservice體系結構基于三種角色（服務提供者、服務注冊中心和服務請求者）之間的交互。交互涉及發(fā)布、查找和綁定操作。共七十六頁WebService的功能(gōngnéng)WebService是一種(yīzhǒnɡ)跨編程語言和跨操作系統(tǒng)平臺的遠程調用技術所謂遠程調用，就是一臺計算機a上的一個程序可以調用到另外一臺計算機b上的一個對象的方法，譬如，銀聯提供給商場的pos刷卡系統(tǒng)（采用交互提問的方式來加深大家對此技術的理解）。遠程調用技術有什么用呢？商場的POS機轉賬調用的轉賬方法的代碼是在銀行服務器上，還是在商場的pos機上呢？什么情況下可能用到遠程調用技術呢？例如，amazon，天氣預報系統(tǒng)，淘寶網，校內網，百度等把自己的系統(tǒng)服務以webservice服務的形式暴露出來，讓第三方網站和程序可以調用這些服務功能，這樣擴展了自己系統(tǒng)的市場占有率，往大的概念上吹，就是所謂的SOA應用。所謂跨編程語言和跨操作平臺，就是說服務端程序采用java編寫，客戶端程序則可以采用其他編程語言編寫，反之亦然！跨操作系統(tǒng)平臺則是指服務端程序和客戶端程序可以在不同的操作系統(tǒng)上運行。除了WebService外，常見的遠程調用技術還有RMI（Remotemethodinvoke）和CORBA，由于WebService的跨平臺和跨編程語言特點，因此比其他兩種技術應用更為廣泛，但性能略低。共七十六頁WebService的調用(diàoyòng)原理WebService使用SOAP協議實現跨編程語言和跨操作系統(tǒng)平臺WebService采用HTTP協議傳輸數據，采用XML格式封裝數據（即XML中說明調用遠程服務對象的哪個方法，傳遞的參數是什么，以及服務對象的返回結果是什么）。WebService通過HTTP協議發(fā)送請求和接收結果時，發(fā)送的請求內容和結果內容都采用XML格式封裝，并增加了一些特定的HTTP消息頭，以說明HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議(simpleobjectaccessprotocol,簡單對象訪問協議)。SOAP協議=HTTP協議+XML數據格式SOAP協議是基于HTTP協議的，兩者的關系就好比高速公路是基于普通公路改造的，在一條公路上加上隔離欄后就成了高速公路。商店的服務員只要收到了錢就給客戶提供貨物，商店服務員不用關心客戶是什么性質的人，客戶也不用關心商店服務員是什么性質的人。同樣，WebService客戶端只要能使用HTTP協議把遵循某種格式的XML請求數據發(fā)送給WebService服務器，WebService服務器再通過HTTP協議返回遵循某種格式的XML結果數據就可以(kěyǐ)了，WebService客戶端與服務器端不用關心對方使用的是什么編程語言。HTTP協議和XML是被廣泛使用的通用技術，各種編程語言對HTTP協議和XML這兩種技術都提供了很好的支持，WebService客戶端與服務器端使用什么編程語言都可以完成SOAP的功能，所以，WebService很容易實現跨編程語言，跨編程語言自然也就跨了操作系統(tǒng)平臺。共七十六頁WebService框架的底層(dǐcénɡ)實現原理各類WebService框架的本質就是一個大大的Servlet，當遠程調用客戶端給它通過http協議發(fā)送過來soap格式的請求數據時，它分析這個(zhège)數據，就知道要調用哪個java類的哪個方法，于是去查找或創(chuàng)建這個對象，并調用其方法，再把方法返回的結果包裝成soap格式的數據，通過http響應消息回給客戶端。共七十六頁WebService的工作(gōngzuò)過程UDDI注冊(zhùcè)中心天氣WebServiceWebService消費者1創(chuàng)建WebService,定義WSDL;

部署WebService,URI標識;股票WebService2把自己注冊到UDDIviaSOAPWebService消費者3查找WebServiceviaSOAP4使用WebServiceviaSOAP（替代2和3）直接告知WSDL的URLWebService提供者共七十六頁WebService的開發(fā)(kāifā)應用WebService開發(fā)可以分為服務器端開發(fā)和客戶端開發(fā)兩個方面：把公司內部系統(tǒng)的業(yè)務方法發(fā)布成WebService服務，供遠程合作單位和個人調用。（借助一些WebService框架可以很輕松地把自己的業(yè)務對象發(fā)布成WebService服務，Java方面的典型WebService框架包括：axis，xfire，cxf等，javaee服務器通常也支持發(fā)布WebService服務，例如JBoss。這框架應用不是學習的重點，看看相關的技術手冊都很輕松地掌握，關鍵還是要了解WebService的工作原理。）調用別人發(fā)布的WebService服務，大多數人從事的開發(fā)都屬于這個(zhège)方面，例如，調用天氣預報WebService服務。（使用廠商的WSDL2Java之類的工具生成靜態(tài)調用的代理類代碼；使用廠商提供的客戶端編程API類；使用SUN公司早期標準的jax-rpc開發(fā)包；使用SUN公司最新標準的jax-ws開發(fā)包。）共七十六頁WebService的客戶端編程原理(yuánlǐ)我們給這各類WebService客戶端API傳遞(chuándì)wsdl文件的url地址，這些API就會創(chuàng)建出底層的代理類，我調用這些代理，就可以訪問到webservice服務。代理類把客戶端的方法調用變成soap格式的請求數據再通過HTTP協議發(fā)出去，并把接收到的soap數據變成返回值返回。共七十六頁WebService優(yōu)缺點WebService優(yōu)點Webservice的互操作性，平臺無關性。Webservice的SOAP協議是基于XML和HTTP這些業(yè)界的標準的，得到了所有的重要公司的支持。由于使用了SOAP，數據是以ASCII文本的方式而非二進制傳輸，調試很方便； 并且由于這樣，它的數據容易通過防火墻，不需要防火墻為了程序而單獨開一個“漏洞”。WebService實現的技術難度要比CORBA和DCOM小得多。要實現B2B集成，EDI比較完善與比較復雜；而用WebService則可以低成本的實現，小公司也可以用上。在C/S的程序中，WebService可以實現網頁無整體刷新的與服務器打交道并取數。

WebService缺點(quēdiǎn)

WebService使用了XML對數據封裝，會造成大量的數據要在網絡中傳輸。WebService規(guī)范沒有規(guī)定任何與實現相關的細節(jié)，包括對象模型、編程語言，這一點，它不如CORBA。共七十六頁

WEBSERVICE術語(shùyǔ)共七十六頁XMLXML(eXtensibleMarkupLanguage)擴展標記語言XML是一種簡單的數據存儲語言，使用一系列簡單的標記描述數據，而這些標記可以用方便(fāngbiàn)的方式建立。雖然XML占用的空間比二進制數據要占用更多的空間，但XML極其簡單易于掌握和使用。共七十六頁XSDXSD是XML結構定義(XMLSchemasDefinition)。XSD是DTD的替代品。描述了XML文檔的結構?？梢杂靡粋€指定的XSD來驗證某個XML文檔，以檢查該XML文檔是否符合其要求。文檔設計者可以通過XSD指定一個XML文檔所允許的結構和內容，并可據此檢查一個XML文檔是否是有效的。XSD本身是一個XML文檔，它符合XML語法結構?？梢杂猛ㄓ玫腦ML解析器解析它。一個XSD會定義：文檔中出現的元素、文檔中出現的屬性、子元素、子元素的數量、子元素的順序、元素是否為空、元素和屬性的數據類型、元素或屬性的默認和固定值。XSD是DTD替代者的原因，一是據將來的條件可擴展，二是比DTD豐富和有用，三是用XML書寫，四是支持數據類型，五是支持命名空間(kōngjiān)。XSD文件的后綴名為.xsd。共七十六頁SOAPSOAP(SimpleObjectAccessProtocol)簡單對象訪問協議。SOAP是一種輕量的、簡單的、基于XML的協議，它被設計成在Web上交換結構化的和固化的信息。SOAP可以和現存的許多因特網協議和格式結合使用，包括超文本傳輸協議(HTTP)，簡單郵件傳輸協議(SMTP)，多用途網際郵件擴充協議(MIME)。它還支持從消息系統(tǒng)到遠程過程調用(RPC)等大量的應用程序。SOAP包括三個部分：SOAP封裝：它定義了一個框架,該框架描述了消息中的內容是什么(shénme)，誰應當處理它以及它是可選的還是必須的。SOAP編碼規(guī)則：它定義了一種序列化的機制，用于交換應用程序所定義的數據類型的實例。SOAPRPC表示：它定義了用于表示遠程過程調用和應答的協定。SOAP消息基本上是從發(fā)送端到接收端的單向傳輸，但它們常常結合起來執(zhí)行類似于請求/應答的模式。所有的SOAP消息都使用XML編碼。一條SOAP消息就是一個包含有一個必需的SOAP的封裝包，一個可選的SOAP標頭和一個必需的SOAP體塊的XML文檔。把SOAP綁定到HTTP提供了同時利用SOAP的樣式和分散的靈活性的特點以及HTTP的豐富的特征庫的優(yōu)點。在HTTP上傳送SOAP并不是說SOAP會覆蓋現有的HTTP語義，而是HTTP上的SOAP語義會自然的映射到HTTP語義。在使用HTTP作為協議綁定的場合中，RPC請求映射到HTTP請求上，而RPC應答映射到HTTP應答。然而，在RPC上使用SOAP并不僅限于HTTP協議綁定。共七十六頁WSDLWSDL（webservicedescriptionlanguage）是基于XML格式的，它是WebService客戶端和服務器端都能理解的標準格式，其中描述的信息可以分為what,where,how等部分!好比我們去商店買東西，首先要知道商店里有什么東西可買，然后再來購買(gòumǎi)，商家的做法就是張貼廣告海報。WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務里有什么方法可以調用，所以，WebService務器端首先要通過一個WSDL文件來說明自己家里有啥服務可以對外調用，服務是什么（服務中有哪些方法，方法接受的參數是什么，返回值是什么），服務的網絡地址用哪個url地址表示，服務通過什么方式來調用。WSDL文件保存在Web服務器上，通過一個url地址就可以訪問到它?？蛻舳艘{用一個WebService服務之前，要知道該服務的WSDL文件的地址。WebService服務提供商可以通過兩種方式來暴露它的WSDL文件地址：注冊到UDDI服務器，以便被人查找直接告訴給客戶端調用者，例如，在自己網站給出信息或郵件告訴。共七十六頁UDDIUDDI（UniversalDescription,DiscoveryandIntegration）統(tǒng)一描述、發(fā)現和集成協議UDDI是為解決Web服務的發(fā)布和發(fā)現問題而制訂的新一代基于Internet的電子商務技術標準。包含一組基于Web的、分布式的Web服務信息注冊中心的實現標準，以及一組使企業(yè)(qǐyè)能將自己提供的Web服務注冊到該中心的實現標準。共七十六頁主流(zhǔliú)接口技術123XML解析(jiěxī)技術Webservice介紹內容提要4Webservice框架共七十六頁

Apache-Axis2

(ApacheEXtensibleInteractionSystem)

Apache-Axis2共七十六頁Axis2簡介(jiǎnjiè)

ApacheAxis2是ApacheAxisSOAP項目的后繼項目。此項目是Web服務核心引擎的重要改進，目標是成為Web服務和面向服務的體系結構（Service-OrientedArchitecture，SOA）的下一代平臺。作為一個干凈的可擴展的開放源代碼Web服務平臺，它正逐漸受到廣泛的關注。Axis2的體系結構高度靈活，支持很多附加功能，如可靠消息傳遞和安全性等。Axis本質上就是一個SOAP引擎，提供創(chuàng)建服務器端、客戶端和網關SOAP操作的基本框架。AXIS2支持更廣泛的數據并對，如XMLBeans，JiBX，JaxMe和JaxBRI和它自定義的數據綁定ADB；Axis2支持多語言-除了Java,他還支持C/C++版本；Axis2允許自己作為獨立的應用來發(fā)布WebService，并提供了大量的功能和一個很好的模型，這個模型可以通過它本身的架構（modulararchitecture）不斷添加新的功能。Axis2將不會對Web服務概念進行驗證，而將提供更好的SOAP處理模型，且與Axis1.x及其他現有Web服務引擎相比(xiānɡbǐ)，其速度和內容方面的性能都得到很大的提高。此外，它還為用戶提供了方便的API，用于部署服務、擴展核心功能和新客戶機編程模型?，F在已經進入了Axis2的時代了。共七十六頁Axis2體系結構Axis2具有模塊化體系結構，由核心模塊和非核心模塊組成。據說，Axis2核心是純SOAP處理引擎，并沒有包含Java?APIforXML-basedRPC(JAX-RPC)概念作為其核心的一部分。Axis2體系結構的設計充分考慮了以下原則：邏輯和狀態(tài)分離，以提供無狀態(tài)處理機制，因為Web服務是無狀態(tài)的。所有信息位于一個信息模型中，允許對系統(tǒng)進行掛起和恢復。能夠在不更改核心體系結構的情況(qíngkuàng)下擴展功能，能以最小或沒有核心更改的情況(qíngkuàng)下直接支持新Web服務規(guī)范。核心組件XML對象模型(AXIOM)SOAP處理模型：處理程序框架信息處理模型：上下文和描述其他組件部署模型傳輸客戶機API核心生成模型Axis2體系結構關系(guānxì)圖

共七十六頁Axis2主要(zhǔyào)特性Axis2不僅是Apache的新Web服務框架。它還體現了從Axis1.x系列獲得的經驗和最近兩年在Web服務領域(lǐnɡyù)的發(fā)展。推出Axis2的主要原因之一是從速度和內存方面獲得更好的性能——不過還添加了一些新特性和功能。大部分新特性都是為了提高Axis2的易用性，并同時保留通過各種方式擴展功能的空間。大部分新功能所添加到的主要領域如下所示：新XML對象模型(AXIOM) AXIOM是一個XML對象模型，設計用于提高XML處理期間的內存使用率和性能，基于Pull解析。通過使用StreamingAPIforXML(StAX)Pull解析器，AXIOM（也稱為OM）可以控制解析過程，以提供延遲構建支持。延遲構建是指AXIOM不完全構建對象模型，模型的其余部分基于用戶的需求構建?；谙鬟f的核心 Axis2是一個純SOAP處理器，并不依賴于任何Java特定的規(guī)范。例如，JAX-WS將作為Axis2上的一個層實現，而不會進入核心部分中。共七十六頁Axis2主要(zhǔyào)特性經過改進的部署模型 Axis2現在支持將服務熱部署到Axis2引擎中。這就允許用戶在不用重新啟動服務器的情況下部署服務。服務應該存檔為ZIP文件，且在文件名中使用.aar（Axis2存檔，Axis2archive）作為擴展名?？刹迦肽K體系結構 模塊為服務器提供了一個擴展機制。Axis2中的每個模塊都包含一組相關的處理程序。例如，WS-Addressing模塊將包含一組為Axis2引擎提供WS-Addressing支持的處理程序。Axis2管理員可以下載WS-Addressing模塊，并將其部署到Axis2引擎中，從而為Axis2引擎添加WS-Addressing支持。module.xml文件包含指定處理程序應屬于哪個管道和階段的規(guī)則?？刹迦霐祿壎?在純SOAP級別上工作有時候比較麻煩，因此大部分用戶更喜歡使用Java代碼，而讓框架處理XML和Java代碼間的轉換。這稱為數據綁定。有很多數據綁定框架可用，用戶會因為各種不同的原因而偏好使用某個框架。Axis2支持目前(mùqián)可用的大部分數據綁定框架，而且沒有任何限制。例如，Axis2內置了對XMLBeans、JAXB和JiBX的支持，用戶可以選擇使用其中任何一個。任何其他數據綁定框架都可以方便地插入。共七十六頁Axis2主要(zhǔyào)特性新客戶機API Axis2可以采用兩種方式調用Web服務。ServiceClientAPI是最簡單的方法，但為用戶提供的控制較少。OperationClientAPI在調用期間提供了大量(dàliàng)的控制。這兩個API都內置了基本In-Out和In-OnlyMEP。Axis2現在同時支持阻塞和非阻塞調用模型。非阻塞調用在設計用戶界面時以及服務調用非常費時的情況下很有用。REST支持 隨著Web2.0的推出，代表性狀態(tài)傳輸（REpresentationalStateTransfer，REST）得到了認可。一段時間以來，REST陣營和SOAP陣營一直在就使用哪個規(guī)范進行激烈的爭論。我們嘗試在Axis2中同時支持二者，采用了WSDL2.0中將REST與Web服務結合的工作成果。在Axis2中，用戶可以調用Axis2引擎中采用REST方式部署的所有Web服務，但受到WSDL2.0HTTPBindings規(guī)范中定義的約束的限制。共七十六頁

sun

JAX-WS

sun

JAX-WS共七十六頁概述(ɡàishù)

JAX-WS2.0(JSR224)是Sun新的webservices協議棧，是一個完全基于(jīyú)標準的實現。在binding層，使用的是theJavaArchitectureforXMLBinding(JAXB,JSR222)，在parsing層，使用的是theStreamingAPIforXML(StAX,JSR173)，同時它還完全支持schema規(guī)范。Sun最開始的webservices的實現是JAX-RPC1.1(JSR101)。這個實現是基于Java的RPC,并不完全支持schema規(guī)范，同時沒有對Binding和Parsing定義標準的實現。JAX-WS規(guī)范是一組XMLwebservices的JAVAAPI。JAX-WS允許開發(fā)者可以選擇RPC-oriented或者message-oriented來實現自己的webservices。在JAX-WS中，一個遠程調用可以轉換為一個基于XML的協議例如SOAP。在使用JAX-WS過程中，開發(fā)者不需要編寫任何生成和處理SOAP消息的代碼。JAX-WS的運行時實現會將這些API的調用轉換成為對應的SOAP消息。在服務器端，用戶只需要通過Java語言定義遠程調用所需要實現的接口SEI

（serviceendpointinterface），并提供相關的實現，通過調用JAX-WS的服務發(fā)布接口就可以將其發(fā)布為WebService接口。在客戶端，用戶可以通過JAX-WS的API創(chuàng)建一個代理（用本地對象來替代遠程的服務）來實現對于遠程服務器端的調用。當然JAX-WS也提供了一組針對底層消息進行操作的API調用，你可以通過Dispatch直接使用SOAP消息或XML消息發(fā)送請求或者使用Provider處理SOAP或XML消息。通過webservice所提供的互操作環(huán)境，我們可以用JAX-WS輕松實現JAVA平臺與其他編程環(huán)境（.net等）的互操作。

JAX-WS(JSR-224)是JavaArchitectureforXMLWebServices的縮寫,簡單說就是一種用Java和XML開發(fā)WebServices應用程序的框架,目前版本是2.0,它是JAX-RPC1.1的后續(xù)版本,J2EE1.4帶的就是JAX-RPC1.1,而JavaEE5里面包括了JAX-WS2.0,但為了向后兼容,仍然支持JAX-RPC.現在,SUN又把JAX-WS直接放到了JavaSE6里面,由于JAX-WS會用到CommonAnnotation(JSR250),JavaWebServicesMetadata(JSR181),JAXB2(JSR222),StAX(JSR173),所以SUN也必須把后幾個原屬于JavaEE范疇的Components下放到JavaSE,現在我們可以清楚地理解了為什么Sun要把這些看似跟JavaSE沒有關系的Components放進來,終極目的就是要在JavaSE里面支持WebServices.

共七十六頁JAX-WS2.0的架構(jiàɡòu)JAX-WS不是一個孤立的框架,它依賴于眾多其他的規(guī)范,本質上它由以下幾部分組成用來開發(fā)WebServices的JavaAPI用來處理(chǔlǐ)Marshal/Unmarshal的XMLBinding機制,JAX-WS2.0用JAXB2來處理JavaObject與XML之間的映射,Marshalling就是把JavaObject映射到XML,Unmarshalling則是把XML映射到JavaObject.之所以要做JavaObject與XML的映射,是因為最終作為方法參數和返回值的JavaObject要通過網絡傳輸協議(一般是SOAP)傳送,這就要求必須對JavaObject做類似序列化和反序列化的工作,在SOAP中就是要用XML來表示Javaobject的內部狀態(tài)眾多元數據(Annotations)會被JAX-WS用來描述WebServices的相關類,包括CommonAnnotations,WebServicesMetadata,JAXB2的元數據和JAX-WS2.0規(guī)范自己的元數據.AnnotationProcessingTool(APT)是JAX-WS重要的組成部分,由于JAX-WS2.0規(guī)范用到很多元數據,所以需要APT來處理眾多的Annotations.在<JDK_HOME>/bin下有兩個命令wsgen和wsimport,就是用到APT和CompilerAPI來處理碰到的Annotations,wsgen可以為WebServicesProvider產生并編譯必要的幫助類和相關支持文件,wsimport以WSDL作為輸入為WebServiceConsumer產生并編譯必要的幫助類和相關支持文件.JAX-WS還包括JAX-WSRuntime與應用服務器和工具之間的契約關系

共七十六頁JAX-WS2.0特性(tèxìng)加固數據綁定以前，在theJAXB(JavaAPIforXMLBinding)和JAX-RPC(JavaAPIforXMLRemoteProcedureCalls)中都有數據綁定工具。這顯然是混淆的，因此JAX-WS只選擇了JAXB2.0.我以前對JAXB有更詳細的文章。支持不斷演化的標準盡管很多現在的Webservices選擇了SOAP1.1標準作為協議、格式和Webservice消息的語法，但SOAP1.2標準已經出臺了一段時間，而且應該會被越來越多的應用。JAX-WS將支持SOAP1.2，并且支持早期的SOAP1.1。由于SOAP1.2改變了一些SOAP消息的語法，所以這不是個小問題。當SOAP剛出現時，它被SimpleObjectAccessProtocol支持。但由于很多人覺得SOAP并不簡單，而且對對象并沒什么用，我們只稱它為SOAP，而不附加什么含義。

類似的演化標準還有WSDL(WebServiceDescriptionLanguage),它被廣泛用在各種Webservices中。WSDL文檔是一個XML格式的文件，描述了與一個Webservice聯系所需要的細節(jié)。當前在用的版本是1.1版，它并非是真正的W3C標準。盡管W3C最近批準了2.0版本，但JAX-WS最近還沒有打算支持它。

另一個在演化的標準是WebServicesInteroperabilityOrganization。WS-IBasicProfile已經發(fā)展了，因為SOAP標準不足以良好定義來確保所有(suǒyǒu)的Webservice工具集都可以彼此交互。JAX-WS會順應該領域的發(fā)展。

共七十六頁JAX-WS2.0特性(tèxìng)利用Java語言的高級特性

Java能夠為源代碼提供某種形式的注釋，即用javadoc工具處理一套以@開頭的注釋關鍵字，生成HTML格式的文檔。這些文檔注釋不會在已編譯的Java類中消失。

最新版本的Java5或Java1.5能夠在你關注的文檔處添加一種重要的新特性。這是一種可以被編譯到類中并能在運行時訪問的注釋。你可以把這些注釋想象成描述一個類如何被使用的元數據。例如，它如何被作為Webservice訪問。

下面JAX-WS樣例Java源文件AddNumbersIF.java中的是兩個注釋，它讓一個Webservice返回(fǎnhuí)兩個數的和。

@WebService(targetNamespace=“”,name=“AddNumbers”)

@WebMethod(operationName=“add”,action=“urn:addNumbers”)

由于這些注釋生成在已編譯的類中，因此處理已編譯的Java類的JAX-WS工具能用Java反射機制獲取程序員設計這些類的意圖的額外信息。獨立傳輸

由于我們正在探討Webservice，人們就會忘記SOAP消息傳輸并沒有被HTTP限制。已經有很多利用email或者JavaMessageService來傳輸的應用了。JAX-WSAPI文檔指出，它想要改進在XML消息格式和低層傳輸機制之間的隔離，進而用非HTTP傳輸簡化JAX-WS的使用。使用其它傳輸機制的樣例看起來落后于HTTPWebservice樣例的開發(fā)，但我已經在Glassfish項目中找到了使用JavaMessageService的一個例子。

共七十六頁WebService框架(kuànɡjià)-

JAX-WSJAX-WS2.0是JAX-RPC1.1的后續(xù)版本JAX-WS的模型使用新的Java5.0功能，引入了異步功能。動態(tài)(dòngtài)編程模型JAX-WS的動態(tài)客戶機模型與JAX-RPC的對應模型差別很大。很多更改都是為了認可行業(yè)需求：引入了面向消息的功能。引入了動態(tài)異步功能。JAX-WS還添加了動態(tài)服務器模型，而JAX-RPC則沒有此模型。消息傳輸優(yōu)化機制（MessageTransmissionOptimizationMechanism，MTOM）JAX-WS通過JAXB（JavaArchitectureforXMLBinding)

添加了對新附件規(guī)范MTOM的支持。Microsoft從來沒有給SOAP添加附件規(guī)范；但似乎大家都支持MTOM，因此應該能夠實現附件互操作性。共七十六頁

codeHaus-XFire

codeHaus-XFire

共七十六頁概述(ɡàishù)XFire是codeHaus組織提供的一個開源框架，它構建了POJO和SOA之間的橋梁，主要(zhǔyào)特性就是支持將POJO通過非常簡單的方式發(fā)布成Web服務，這種處理方式不僅充分發(fā)揮了POJO的作用，簡化了Java應用轉化為Web服務的步驟和過程，也直接降低了SOA的實現難度，為企業(yè)轉向SOA架構提供了一種簡單可行的方式。XFire中另一塊核心的思想，就是其靈活而強大的binding機制，負責完成Java類型與SOAP消息的雙向轉換。XFire僅僅內建就支持POJO(Aegis),Castor,JAXB1.1,JAXB2.0和XMLBeans多種模式，你可以根據需求選擇從全自動POJO生成，到全手工xsd文件定義的不同方式。

共七十六頁XFire架構(jiàɡòu)

Service層Service層是XFire架構的靜態(tài)基礎，負責完成對服務的注冊及其管理。核心的ServiceRegistry接口完成對服務自身的生命期管理，如注冊/注銷/獲取等等；而ServiceFactory接口則負責從具體的POJO類型(lèixíng)，生成實現

Service接口的可被管理的服務代理。Transport層Transport層則是XFire的外部IO處理系統(tǒng)。由TransportManager接口對具體的Transport接口實現進行管理，默認提供了基于pipe的LocalTransport和基于Http協議的SoapHttpTransport。理論上可以任意進行擴展，例如XFire發(fā)布包中還提供了基于JMS和XMPP的實現。Invoker層Invoker則是XFire的動態(tài)調用層，負責在Transport層接受到請求后，解析內容、調用合適服務并最終返回SOAP封包給調用者。運行時Invoker負責維系Service和Transport之間的聯系。共七十六頁主要(zhǔyào)特性支持將Web服務綁定到POJO、XMLBeans、JAXB1.1、JAXB2.0和Castor；支持基于(jīyú)HTTP、JMS、XMPP等多種協議訪問Web服務；支持多種Web服務業(yè)界重要標準如SOAP、WSDL、Web服務尋址（WS-Addressing）、Web服務安全（WS-Security）等；支持JSR181，可以通過JDK5配置Web服務；高性能的SOAP實現；服務器端、客戶端代碼輔助生成；對Spring、Pico、Plexus等項目的支持等。

共七十六頁主要(zhǔyào)特性

1、支持一系列WebService的新標準--JSR181、WSDL2.0、JAXB2、WS-Security等；

2、使用Stax解釋XML,性能有了質的提高。XFire采用Woodstox作Stax實現；

3、容易(róngyì)上手，可以方便快速地從pojo發(fā)布服務；

4、Spring的結合；

5、靈活的Binding機制，包括默認的Aegis,xmlbeans,jaxb2,castor。

共七十六頁

ApacheCXFApacheCXF共七十六頁概述(ɡàishù)

CXF繼承了Celtix和XFire兩大開源項目的精華，提供了對JAX-WS全面的支持，并且提供了多種Binding、DataBinding、Transport以及各種Format的支持，并且可以根據實際項目的需要，采用(cǎiyòng)代碼優(yōu)先（CodeFirst）或者WSDL優(yōu)先（WSDLFirst）來輕松地實現WebServices的發(fā)布和使用。ApacheCXF是一個開源的Services框架，CXF幫助您利用Frontend編程API來構建和開發(fā)Services，像JAX-WS。這些Services可以支持多種協議，比如：SOAP、XML/HTTP、RESTfulHTTP或者CORBA，并且可以在多種傳輸協議上運行，比如：HTTP、JMS或者JBI，CXF大大簡化了Services的創(chuàng)建，同時它繼承了XFire傳統(tǒng)，一樣可以天然地和Spring進行無縫集成。

共七十六頁特性(tèxìng)

支持WebServices標準：CXF支持多種WebServices標準，包含SOAP、BasicProfile、WS-Addressing、WS-Policy、WS-ReliableMessaging和WS-Security。Frontends：

CXF支持多種“Frontend”編程模型，CXF實現了JAX-WSAPI（遵循JAX-WS2.0TCK版本(bǎnběn)），它也包含一個“simplefrontend”允許客戶端和EndPoint的創(chuàng)建，而不需要Annotation注解。CXF既支持WSDL優(yōu)先開發(fā)，也支持從Java的代碼優(yōu)先開發(fā)模式。容易使用：

CXF設計得更加直觀與容易使用。有大量簡單的API用來快速地構建代碼優(yōu)先的Services，各種Maven的插件也使集成更加容易，支持JAX-WSAPI，支持Spring2.0更加簡化的XML配置方式，等等。支持二進制和遺留協議：

CXF的設計是一種可插撥的架構，既可以支持XML，也可以支持非XML的類型綁定，比如：JSON和CORBA。共七十六頁特性(tèxìng)支持多種標準:

支持JAX-WS、JAX-WSA、JSR-181和SAAJ；

支持SOAP1.1、1.2、WS-IBasicProfile、WS-Security、WS-Addressing、WS-RM和WS-Policy；

支持WSDL1.1、2.0；支持MTOM；多種傳輸方式、Bindings、DataBindings和Format:

Bindings：SOAP、REST/HTTP；

DataBndings：目前支持JAXB2.0、Aegis兩種，默認是JAXB2.0。XMLBeans、Castor和JiBX數據綁定方式將在CXF2.1版本中得到(dédào)支持；

格式（Format）：XML、JSON；

傳輸方式：HTTP、Servlet、JMS和Jabber；

可擴展的API允許為CXF增加其它的Bindings，以能夠支持其它的消息格式，比如：CSV和固定記錄長度。靈活部署

輕量級容器：可在Tomcat或基于Spring的容器中部署Services；

集成JBI：可以在如ServiceMix,OpenESBorPetals等等的JBI容器中將它部署為一個服務引擎；

集成SCA：可以部署在如Tuscany之類的SCA容器中；

集成J2EE：可以在J2EE應用服務器中部署Services，比如：Geronimo、JOnAS、JBoss、WebSphereApplicationServer和WebLogicApplicationServer，以及Jetty和Tomcat；獨立的Java客戶端／服務器。共七十六頁特性(tèxìng)支持(zhīchí)多種編程語言

全面支持JAX-WS2.0客戶端／服務器編程模型；

支持JAX-WS2.0synchronous、asynchronous和one-wayAPI‘s；

支持JAX-WS2.0DynamicInvocationInterface(DII)API；

支持wrappedandnon-wrapped風格；

支持XMLmessagingAPI；

支持JavaScript和ECMAScript4XML(E4X)，客戶端與服務端均支持；通過Yoko支持CORBA；通過Tuscany支持SCA；通過ServiceMix支持JBI；代碼生成

JavatoWSDL；

WSDLtoJava；

XSDtoWSDL；

WSDLtoXML；WSDLtoSOAP；

WSDLtoService；共七十六頁WebService框架(kuànɡjià)-XFIRE(ApacheCXF)支持一系列WebService的新標準--JSR181、WSDL2.0、JAXB2、WS-Security等；使用Stax解釋XML,性能有了質的提高。XFire采用Woodstox作Stax實現；開發(fā)方便(fāngbiàn)，配置簡單，容易上手，與spring無縫集成，可以方便快速地從pojo發(fā)布服務支持Spring、Pico、Plexus、Loom等容器；靈活的Binding機制，包括默認的Aegis,xmlbeans,jaxb2,castor；高性能的SOAP棧設計；XFire比Axis1.3快2-6倍,響應時間是Axis1.3的1/2到1/5。共七十六頁Axis2,CXF的比較(bǐjiào)ApacheCXF支持WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-IBasicProfileAxis2支持WS-Addressing、WS-RM、WS-Security和WS-IBasicProfile，WS-Policy將在新版本里得到支持ApacheCXF是根據Spring哲學來進行編寫的，即可以無縫地與Spring進行整合(zhěnɡhé)

Axis2支持更多的databindings，包括XMLBeans、JiBX、JaxMe和JaxBRI，以及它原生的databinding（ADB）。ApacheCXF目前僅支持JAXB和Aegis，并且默認是JAXB2.0，與XFire默認是支持Aegis不同，XMLBeans、JiBX和Castor將在CXF2.1版本中得到支持，目前版本是2.0.2Axis2支持多種語言，它有C/C++版本。ApacheCXF提供方便的Spring整合方法，可以通過注解、Spring標簽式配置來暴露WebServices和消費WebServices

共七十六頁Axis2,CXF的比較(bǐjiào)在特性方面：CXF支持WS–Addressing、WS-Policy、WS-RM、WS-Security和WS-IBasicProfile。Axis2支持除了WSPolicy之外的所有(suǒyǒu)這些標準，WS-Policy預計會在未來版本中得到支持；CXF可以方便地和Spring集成在一起，Axis2不行;Axis2支持范圍更廣的數據綁定，包括XMLBeans、JiBX、JaxMe、JaxBRI，以及它自己的數據綁定ADB。在Axis21.2版中，JaxME和JaxBRI尚處于試驗階段。目前，CXF只支持JAXB和Aegis，對XMLBeans、JiBX和Castor的支持將在CXF2.1版中實現；Axis2支持多語言，除了Java版本，尚有C/C++版本。共七十六頁Axis2,CXF的比較(bǐjiào)在開發(fā)方面：Axis2更像一個微型服務器。Axis2被打包成一個WAR，可部署到任何Servlet容器中，為了更方便地在運行中管理和部署服務進行專門的設計(shèjì)。CXF更專注于對開發(fā)人員友好及可嵌入性。大部分配置只需使用API即可完成，與Spring緊密集成。CXF強調代碼優(yōu)先的服務開發(fā)方式。共七十六頁XFire與Axis2比較(bǐjiào)

雖然XFire與Axis2都是新一代的WebService平臺，但是Axis2的開發(fā)者太急于推出1.0版本，所以1.0還不是一個穩(wěn)定的版本，它的開發(fā)者宣稱1.1版本即將推出，希望1.1版本會是個穩(wěn)定的版本。在XFire捐獻給apache后有人認為Axis2將會滅亡。其實在很多人眼里，Axis2并不是pojo形式，DanDiephouse證明了XFire比Axis更有市場，我也發(fā)現了有很多人開始從Axis轉向XFire，包括我也在說服身邊的人轉向利用XFire進行WebService的開發(fā)，很典型的是我可以在幾分鐘之內教會我的團隊實用XFire來發(fā)布一個他自己的Web服務(fúwù)。本人傾向于XFire確實比Axis2簡單很多共七十六頁選擇(xuǎnzé)axis2,cxf的建議如果需要多語言支持，那么就采用Axis2；如果考慮到使用Java、與Spring集成，或將服務嵌入到其他程序中，那么CXF更好。當然，并不是所有人都說好。例如，在國內的一些論壇上，就有開發(fā)者抱怨CXF的入門比起XFire來要復雜得多。這是可以理解的，畢竟CXF本身(běnshēn)也比XFire要復雜得多。為了幫助Celtix和XFire的開發(fā)者向新工具的遷移，其官方網站也提供了相應的遷移指南。另外一個常見的問題是和SpringAOP相關的（如事務、安全），這在官方網站的FAQ中也有說明。共七十六頁選擇(xuǎnzé)axis2,cxf的建議CXF的功能特性非常多，要熟練(shúliàn)使用它非得花些功夫才行。熟悉工具涉及領域的協議是個不錯的主意。雖然CXF提供了簡化服務創(chuàng)建的編程模型，但是如果不了解WS-*協議，在遇到問題調試時必然會花不少時間。尤其是在SOA的環(huán)境中，客戶端和服務不一定是使用同一語言、同一工具實現的情況下，互操作問題經常是由于對協議的不同支持造成的；作為CXF實現內容的一個重點，JAX-WS是值得關注的；在Java的環(huán)境中，Spring幾乎已經成為開發(fā)服務器端應用的首選，應重點關注CXF和Spring的配合使用；近些年來，Java世界的動態(tài)語言旋風愈演愈烈。Groovy由于其語法和Java兼容且提供了不少方便的語法，吸引了不少Java開發(fā)者。更何況新興的Grails框架逐漸引人注目，其前途不可限量。GroovyWS專為Groovy開發(fā)，且底層就是CXF，作為CXF的開發(fā)者，沒有理由不去使用可以使自己生活過得舒適的工具；CXF攜帶了大量的例程，它們是熟悉和了解CXF的大門的；參與社區(qū)，參與討論，往往比起自己單干要有用得多。共七十六頁性能(xìngnéng)對比

遠程測試結果（單位：ms）服務器端axis2axis1xfirecxf客戶端axis2axis1axis1axis2xfire+springaxis1cxfaxis1客戶端初始化672.81040axis1772029942584421.610次中的初次調用值645.8606684.4427.810101190296.8321.810次平均值71.5870.3697.8260.28117.2139.135.343.37后9次平均值7.7810.5832.6419.4418.0427.136.24414.22從數據可以看出，有下面幾個特點：客戶端初次調用，初始化客戶端stub對象時，大約在：600ms～2500ms。由于需要建立網絡連接，初始化java相關對象，因此耗時較長?？蛻舳顺跏蓟痵tub后，接口初次調用，大約在：400ms～1000ms。相比后續(xù)的接口調用時間最長。在第一次調用完畢后，隨后的調用中，性能都明顯提升。大約在：7ms～30ms。本機測試與遠程測試，性能上差距很微小，在高速的局域網內，性能差別幾乎可以忽略。在相同的服務端下，采用不同框架生成(shēnɡchénɡ)的stub代碼調用時，時間上也存在一定的差異。最優(yōu)組合是最差組合性能的5倍多。最優(yōu)的組合為：cxf客戶端+cxf服務端，6ms左右。最差的組合為：axis1客戶端+axis1服務端，32ms左右。CXF作為服務端，對于不同的客戶端調用時，性能最佳。共七十六頁數據(shùjù)綁定對比DataBndings

XMLBeansJAXB1.1JAXB2.0CastorAegis(POJO)JiBXJaxMeJaxBRIADBxfire★★★★★

cxf2.0.2

★★

★

cxf2.1★★★★★★

Axis2★

★★★共七十六頁選擇(xuǎnzé)框架如果應用程序需要多語言的支持，Axis2應當是首選了；如果應用程序是遵循Spring哲學路線的話，ApacheCXF是一種更好的選擇，特別對嵌入式的WebServices來說；如果應用程序沒有新的特性(tèxìng)需要的話，就仍是用原來項目所用的框架，比如Axis1，XFire，Celtrix或BEA等等廠家自己的WebServices實現共七十六頁數據(shùjù)綁定