RPC與RMI的區別以及jax-rpc、jax-ws和 axis、xfire的聯絡和區別

1. RPC 不支援對象， 採用http協議

 

2. RMI支援傳輸對象。採用tcp／ip 協議

 

3. RMI只限於JAVA語言，RPC跨語言

 

RPC和RMI的簡單比較

 

　　在RMI和RPC之間最主要的區別在於方法是如何別調用的。在RMI中，遠程介面使每個遠程方法都具有方法簽名。如果一個方法在伺服器上執行， 但是沒有相匹配的簽名被添加到這個遠程介面上，那麼這個新方法就不能被RMI客戶方所調用。在RPC中，當一個請求到達RPC伺服器時，這個請求就包含了 一個參數集和一個文本值，通常形成“classname.methodname”的形式。這就向RPC伺服器表明，被請求的方法在為 “classname”的類中，名叫“methodname”。然後RPC伺服器就去搜尋與之相匹配的類和方法，並把它作為那種方法參數類型的輸入。這裡 的參數類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼後返回客戶方。

 

分散式運算系統要求運行在不同地址空間不同主機上的對象互相調用。各種分布式系統都有自己的調用協議，如CORBA的IIOP(Internet InterORB Protocol), MTS的DCOM。那麼EJB組件呢？在Java裡提供了完整的sockets通訊介面，但sockets要求用戶端和服務端必須進行應用級協議的編碼交 換資料，採用sockets是非常麻煩的。 

一個代替Sockets的協議是RPC(Remote Procedure Call), 它抽象出了通訊介面用於程序呼叫，使得編程者調用一個遠程過程和調用本地過程同樣方便。RPC 系統採用XDR來編碼遠程調用的參數和傳回值。 

 

但RPC 並不支援對象，而EJB構造的是完全物件導向的分布式系統，所以，物件導向的遠程調用RMI(Remote Method Invocation)成為必然選擇。採用RMI，調用遠程對象和調用本機物件同樣方便。RMI採用JRMP(Java Remote Method Protocol)通訊協議，是構建在TCP/IP協議上的一種遠程調用方法。 

 

RMI調用機制 

RMI 採用stubs 和 skeletons 來進行遠程對象(remote object)的通訊。stub 充當遠程對象的用戶端代理，有著和遠程對象相同的遠程介面，遠程對象的調用實際是通過調用該對象的用戶端代理對象stub來完成的。

 

 

jax-rpc、jax-ws和 axis、xfire的聯絡和區別

 

Sun 和 Java 標準 

 

JAX-RPC 1.0 是 Java 方面的 Web 服務的原始標準。雖然 JAX-RPC 的設計思想是可以為實際 Web 服務實現使用不同的協議實現，但在實踐中，僅將其用於 SOAP 服務。已經開發了多個不同的 JAX-RPC 實現，其中使用最廣泛的可能就是 Apache 架構了，其次是 Sun Microsystems 作為 Java Web Services Developer Pack 的一部分分發的 Reference Implementation。 

 

在開發 JAX-RPC 1.0 時，行業中的很多人認為 rpc/enc 樣式的 SOAP 將成為最方便和易用的 Web 服務。JAX-RPC 1.0 規範要求對 rpc/enc 和 doc/lit 樣式進行支援，但並不要求對很多模式特性進行支援。這樣就帶來了一個很不幸的副作用，使 doc/lit SOAP（此技術是基於模式的）事實上成了一個二流選項。 

 

JAX-RPC 1.0 對 Web 服務功能的認識也有一定的局限。從其名稱可以看出，最初的目的是為了支援使用 XML 的遠端程序呼叫（Remote Procedure Call，RPC）操作。Java 當時已經有了一項面向 Java 應用程式間的 RPC 調用的現有技術，即遠程方法調用（Remote Method Invocation，RMI）。該規範團隊選擇了在現有 RMI 介面上對 JAX-RPC 進行建模。只要通過要求-回應操作使用 rpc/enc SOAP，此模型就可相當接近地進行匹配，不過映射到非同步作業或其他傳輸的效果並不理想。到 2003 年底，有關人員認識到，總要對 JAX-RPC 進行大幅修訂，以處理這些問題和其他問題，因此 Sun 組成了一個專家組開始進行 JAX-RPC 2.0 規範的開發。 

 

 

JAX-* 

 

JAX-RPC 2.0 開發工作的主要目標是對各項標準進行更新，以支援 JAX-RPC 1.X 的強制要求（基於 Java 5 特性，如 Annotation 和泛型），改進訊息傳遞支援（包括除 HTTP 外的非同步作業和傳輸），並通過使用 JAXB 2.0 綁定替代 JAX-RPC 1.X 的簡單（但局限性很強）內建綁定來改進模式支援。出於對更改範圍的強調和其他原因，這個後續標準的名稱更改成了 JAX-WS 2.0。JAX-WS 2.0 現在已經提供了預發布版本，其生產版本預計將在 2006 中期推出。 

 

JAX-WS 2.0 成功實現了對 JAX-RPC 1.X 的各種期望，甚至還提供一些額外的功能，如有限的 REST 支援。因為 JAX-WS 2.0 大量使用了 Annotation 和其他 Java 5 特性（這樣就不能使用較舊的 JVM），因而一些開發人員可能會在使用時遇到一些問題，但對於很多開發人員而言，依賴 Java 5 特性將是一大優勢。一個較為突出的顧慮是，JAX-WS 2.0 並不支援 Web 服務配置的 Annotation 的任何後備選項，這樣就可能限制該架構的靈活性和長期優勢。 

 

JAX-WS 2.0 和 JAXB 2.0 都在準備綁定到 J2SE 規範的發布 Java 5 版本中。將這些組件作為標準 JVM 安裝的一部分將無疑增加對開發人員的吸引力，因為這將避免在各個應用程式中包含大量架構的需求。將大量架構套件含在標準 JVM 中的缺點在於（除了會增加基本下載大小外），在需要進行錯誤修複時，可能會導致很難進資料列版本設定，就像已經發生在 JAXP 之類的組件身上的情況一樣（這些組件已經採用了綁定的方式）。 

 

向互通性進發 

 

JAX-WS 2.0 直接支援 XOP/MTOM，而並不是其他新的 WCF 技術。不過，在 Sun 聲明的與 Microsoft 互通性承諾中，他們宣布將開發 WCF 中包含的其他技術的 Java 開放原始碼版本。這些開放原始碼實現將作為大型項目“GlassFish”的一部分進行開發，此項目涵蓋了作為 Sun 的應用伺服器（包括 JAX-WS 2.0 和 JAXB 2.0 參考實現）的一部分使用的所有技術。 

 

在這些新的開放原始碼項目成形之前，我們需要拭目以待。在 Sun 所公布的時間表中，將在 2006 年中期提供一些可用的東西，因此在本系列的後續文章中將能夠提供更多的詳細資料。 

 

 

Apache 方法 

 

Apache 項目數年來已在 Web 服務方面進行了大量的工作，其主要精力放在 Java 平台開發上。Apache 當前的 Java SOAP Web 服務生產平台是第三代 Axis 架構。Axis 得到了廣泛的使用，這既包括開發人員下載並直接使用，也包括將其作為 SOAP 引擎嵌入到若干不同的應用伺服器中。Axis 通常被認為是使用最廣泛的 Java SOAP Web 服務平台。 

 

不過，Axis 也有一些缺點。首先，它是基於 JAX-RPC 1.0 標準設計的，而後者在很大程度上約束了 Axis 體繫結構，限制了其靈活性。隨著為了以 SOAP 處理核心為基礎構建新技術而對擴充的需求的增加，這個有限的靈活性就越來越成問題了。同時，轉向 doc/lit SOAP 服務也帶來了對更好模式支援的需求，對 Axis 代碼而言，這在當時是非常不實際的。到 2004 年中期，Axis 團隊認為需要重新進行編寫工作，要在進行重新編寫工作中應用通過實現 Axis 獲得的經驗，並同時提供更好的靈活性，以便將來進行擴充。 

 

“救世主”Axis2 

 

Axis2 是 Axis 的後續版本。它設計為輕量 SOAP 處理引擎（儘管對於 JAX-WS 2.0，Axis2 也包含一些對 REST 的支援），可以採用很多方式進行擴充。與原來的 Axis 不同，Axis2 並不刻意對實現任何特定 API 進行約束（儘管一些 JAX-WS 2.0 支援級計劃使用 Axis2 核心代碼的封裝）。Axis2 的開發工作已經持續了一年多，不久就將投入生產。 

 

Axis2 最好的特性之一就是為 SOAP 訊息使用的 AXIOM 物件模型。XML 物件模型存在的時間幾乎和 XML 本身一樣長，最早的版本是來自 W3C 的 DOM 標準。AXIOM 和其他 XML 物件模型不同的地方在於，它利用新的 XML 解析器提供的靈活性來允許按需構造物件模型。這意味著，只有為實際需要通過模型訪問的 XML 文檔部分構建物件模型才會帶來效能損失。

 

另一個主要 Axis2 特性是對可插入資料繫結的支援。此特性允許您選擇最簡單的方式來處理 SOAP 文檔的 XML 有效載荷，對產生的程式碼進行自訂，以使用所選擇的方法。可能的選擇包括，直接使用 AXIOM，使用與原來的 Axis 相似的簡單資料繫結方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等專用資料繫結架構。 

 

擴充 Axis2 

 

儘管 Axis2 仍然在開發中，不過已經有了一系列在 Axis2 基礎上實現 SOAP 延伸模組的項目。這些項目包括 WCF 所支援的所有主要技術以及 Microsoft 計劃在附加元件（即獨立計價的）應用程式中的一些擴充。Axis2 的體繫結構允許使用一個稱為模組 的組件方便地開發此類擴充。 

 

WS-Addressing 和 WS-Security 模組當前包含在基礎 Axis2 分發中（在將來將可能作為獨立部分下載，或者甚至成為獨立的項目，因為這些模組和核心 Axis2 代碼之間並沒有緊密耦合關係）。WS-ReliableMessaging 支援正在通過 Sandesha 項目開發，而 WS-Trust 和 WS-SecureConversation 正在通過 WSS4J 項目開發（已經提供了 WS-Security 實現）。WS-AtomicTransaction 和 WS-Coordination 正在通過 Kandula 項目進行實現。 

 

 

 

總結：由此可見，Axis對JAX-RPC進行了實現，但Axis2並沒有完全實現JAX-WS規範。 

 

JAX-RPC和JAX-WS是WebService的規範。

 

JAX-WS 2.0 是 JAX-RPC 1.1 的後續版本。

 

@see http://www.ibm.com/developerworks/cn/webservices/ws-jaxrpc/part1/

@see http://www.ibm.com/developerworks/cn/webservices/ws-tip-jaxwsrpc.html

 

axis和xfire是WebService的開源實現。

 

axis現在有兩個版本axis1和axis2,xfire已經更名為cxf

@see ws.apache.org

@see cxf.apache.org