目前的分布式架構主要由corba和JavaEE搭建，JavaEE優點是跨平台，開發成本低、周期短，不需要學習IDL語言；CORBA的優點是服務器響應速度更快。決定這些架構優缺點的，主要就是通信方式。
在分布式服務框架中，一個最基礎的問題就是遠程服務是怎么通訊的，特別是在Java領域 中有很多可實現遠程通訊的技術，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什么 關系呢，它們背后到底是基於什么原理實現的呢，了解這些是實現分布式服務框架的基礎知識，而如果在性能上有高的要求的話，那深入了解這些技術背后的機制就 是必須的了。
基本原理
要實現網絡機器間的通訊，首先得來看看計算機系統網絡通信的基本原理，在底層層面去看，網絡通信需要做的就是將流從一台計算機傳輸到另外一台計算機，基於 傳輸協議和網絡IO來實現，其中傳輸協議比較出名的有http、tcp、udp等等，http、tcp、udp都是在基於Socket概念上為某類應用場 景而擴展出的傳輸協議，網絡IO，主要有bio、nio、aio三種方式，所有的分布式應用通訊都基於這個原理而實現，只是為了應用的易用性，各種語言通 常都會提供一些更為貼近應用易用的應用層協議。
應用級協議
遠程服務通訊，需要達到的目標是在一台計算機發起請求，另外一台機器在接收到請求后進行相應的處理並將結果返回給請求端，這其中又會有諸如one way request、同步請求、異步請求等等請求方式，按照網絡通信原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端計算機在接 收到請求的流后進行處理，處理完畢后將結果轉化為流，並通過傳輸協議返回給調用端。
但為了應用的方便，業界推出了很多基於此原理之上的應用級的協議，使得大家可以不用去直接操作這么底層的東西，通常應用級的遠程通信協議會提供：
1、為了避免直接做流操作的麻煩，提供一種更加易用或符合語言的標准傳輸格式；
2、網絡通信機制的實現，就是替你完成了將傳輸格式轉化為流，通過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流后轉化為傳輸格式，並進行存儲或以某種方式通知遠端計算機。
所以在學習應用級的遠程通信協議時，我們可以帶着這幾個問題進行學習：
1、傳輸的標准格式是什么？
2、怎么樣將請求轉化為傳輸的流？
3、 怎么接收和處理流？
4、傳輸協議是？
不過應用級的遠程通信協議並不會在傳輸協議上做什么多大的改進，主要是在流操作方面，讓應用層生成流和處理流的這個過程更加的符合所使用的語言或標准，至 於傳輸協議則通常都是可選的，在java領域中知名的有：RMI、XML-RPC、Binary- RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通信的應用級協議：
RPC（Remote Procedure Call Protocol）
RPC使用C/S方式，采用http協議,發送請求到服務器，等待服務器返回結果。優點是跨語言跨平台，C端、S端有更大的獨立性，缺點是不支持對象，不支持異步調用，無法在編譯器檢查錯誤，只能在運行期檢查。
它是早期的支持分布式一種，缺點rpc是面向過程的遠程調用，不支持面向對象，所以現在用的人就少了。不支持異步調用
WebService
Web Service提供的服務是基於web容器的，底層使用http協議，類似一個遠程的服務提供者，比如天氣預報服務，對各地客戶端提供天氣預報，是一種請求應答的機制，是跨系統跨平台的。就是通過一個servlet，提供服務出去。
首先客戶端從服務器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責與WebService服務器進行Request 和Response 當一個數據（XML格式的）被封裝成SOAP格式的數據流發送到服務器端的時候，就會生成一個進程對象並且把接收到這個Request的SOAP包進行解 析，然后對事物進行處理，處理結束以后再對這個計算結果進行SOAP包裝，然后把這個包作為一個Response發送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行后續操作。這就是WebService的一個運行過程。
Web Service大體上分為5個層次:
1. Http傳輸信道
2. XML的數據格式
3. SOAP封裝格式
4. WSDL的描述方式
5. UDDI UDDI是一種目錄服務，企業可以使用它對Webservices進行注冊和搜索
RMI （Remote Method Invocation）
RMI 采用stubs 和 skeletons 來進行遠程對象(remote object)的通訊。stub 充當遠程對象的客戶端代理，有着和遠程對象相同的遠程接口，遠程對象的調用實際是通過調用該對象的客戶端代理對象stub來完成的，通過該機制RMI就好 比它是本地工作，采用tcp/ip協議，客戶端直接調用服務端上的一些方法。優點是強類型，編譯期可檢查錯誤，缺點是只能基於JAVA語言，客戶機與服務 器緊耦合；
JRMP是Java持有的，基於流的協議，完成一個對象的Java到Java的遠程調用；IIOP是CORBA對象請求代理之間交流的協議，Java中使得程序可以和其他語言的CORBA實現互操作性的協議，和JRMP互補。
優點：支持分布式對象、跨平台，stubs/skeletons機制；缺點：不能跨語言。
JMS（Java Messaging Service）
JMS是Java的消息服務，JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點對點和發布訂閱模型。
優點：支持異步通信、消息produce和recept松耦合。
EJB(enterprise java bean)
EJB是javaEE中的一個規范，該規范描述了分布式應用程序需要解決的問題，例如事務處理、安全、日志、分布式等，而同時呢，sun公司也實現了自己定義的這一個標准，相當於自己頒布一個標准然后，又給出了實現供別人使用，實現以很多API的方式提供給用的人。
EJB是按照java服務器接口定義的java類，可以理解為一個特殊的java類，放在容器里容器可以幫助該類管理事務、分布式、安全等，一般小的程序 不會用到，只有大型分布式系統才會用到EJB，既然ejb是一個java類或是一個組件，顆粒較小，這也是與Webservice的區別之一，下面會說 到，它就可以被其它一個或多個模塊調用。
包含了三種類型的Bean，可以通過注釋JPA一個規范來標記,其中有一種Bean，叫MDB消息驅動bean，它的通信機制涉及到了JMS協議。
EJB可以進行遠程調用，但是不能夠跨語言，ejb是同步調用，而平時我們說的的ejb異步調用指的是ejb的MDB異步通信。
JNDI（Java naming and Directory Interface）
Java命名與目錄接口，包含兩個服務，命名服務獎名稱和對象聯系起來，使得我們可以用名稱訪問對象，目錄服務是一種命名服務，在這種服務里，對象不但有名稱，還有屬性。
使用JNDI，一個J2EE應用程序可以存儲和動態獲取任何類型的命名Java對象。因為JNDI不依賴於任何特定的執行，應用程序可以使用 JNDI訪問各種命名目錄服務，包括現有的諸如LDAP、NDS、DNS、NIS、COS命名和RMI注冊等服務。這使得J2EE應用程序可以和傳統的應 用程序和系統共存。
從JNDI的架構中可以看出，JNDI分為三部分，應用程序編程接口（API）和服務供應商接口（SPI），前者Java應用程序訪問各種命名和目錄服 務，開發上層應用的程序員就不必去關心底層具體的技術細節，后者則是設計來供任意一種服務的供應商（也包括目錄服務供應商）使用，這一層一般由供應商去完 成。
EJB與JMS
它們其實是沒有多大關系的，它們都是javaEE的規范，EJB的一種類MDB實現了JMS規范，當然是先JMS規范的不止有ejb的mdb，比如apache ActiveMQ也是
WebService與EJB
對這兩個常常有點迷惑人，因為他們都實現了分布式應用調用，雖然他們很相似但是還是有很多區別的，首先通信協議是不一樣的，EJB采用rmi-iiop協 議，Web service利用http協議傳輸數據，優點，http協議支持的較廣泛，從這點來看Web Service層次要高一些、俗話說站得高看得遠。
WebService主要關注於解決異構系統、不同語言系統通信，其關注的是分布式服務開發、着手點要高、站的角度高，而EJB可以看做是分布式編程平台，通過容器和組件，簡化了程序開發、調試和部署等它關注的是分布式組件開發，粒度小。
WebService可以看做是異構系統、異構語言系統間通信的一個標准，而EJB只屬於J2EE規范的一部分。
EJB底層用rmi-iiop協議進行通信，防火牆會阻止；WebService是基於http協議進行通信，防火牆不會阻止。
RPC與RMI
RPC和RMI之間的一個重要差別是RPC用快速而不夠可靠的UDP協議，RMI用低速而可靠的TCP/IP協議。
（1）RPC 跨語言，而 RMI只支持Java。
（2）RMI 調用遠程對象方法，允許方法返回 Java 對象以及基本數據類型，而RPC 不支持對象的概念，傳送到 RPC服務的消息由外部數據表示 (External Data Representation, XDR) 語言表示，這種語言抽象了字節序類和數據類型結構之間的差異。只有由 XDR 定義的數據類型才能被傳遞， 可以說 RMI 是面向對象方式的 Java RPC 。
（3）在方法調用上，RMI中，遠程接口使每個遠程方法都具有方法簽名。如果一個方法在服務器上執行，但是沒有相匹配的簽名被添加到這個遠程接口上，那么這個新方法就不能被RMI客戶方所調用。
在RPC中，當一個請求到達RPC服務器時，這個請求就包含了一個參數集和一個文本值，通常形成“classname.methodname”的形式。這 就向RPC服務器表明，被請求的方法在為 “classname”的類中，名叫“methodname”。然后RPC服務器就去搜索與之相匹配的類和方法，並把它作為那種方法參數類型的輸入。這里 的參數類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼后返回客戶方。
JMS與RMI
JMS 服務，對象是在物理上被異步從網絡的某個JVM 上直接移動到另一個JVM 上（是消息通知機制）
而RMI 對象是綁定在本地JVM 中，只有函數參數和返回值是通過網絡傳送的（是請求應答機制）。
RMI一般都是同步的，也就是說，當client調用Server的一個方法的時候，需要等到對方的返回，才能繼續執行client端，這個過程調用本地方法感覺上是一樣的，這也是RMI的一個特點。
JMS 一般只是一個點發出一個Message到Message Server,發出之后一般不會關心誰用了這個message。
所以，一般RMI的應用是緊耦合，JMS的應用相對來說是松散耦合應用。
WebService與JMS
WebService專注於遠程服務調用，JMS專注於信息交換。
大多數情況下WebService是兩系統間的直接交互（Consumer <–> Producer），而大多數情況下JMS是三方系統交互（Consumer <- Broker -> Producer）。當然，JMS也可以實現request-response模式的通信，只要Consumer或Producer其中一方兼任 broker即可。
JMS可以做到異步調用完全隔離了客戶端和服務提供者，能夠抵御流量洪峰； WebService服務通常為同步調用，需要有復雜的對象轉換，相比SOAP，現在JSON，rest都是很好的http架構方案；（舉一個例子，電子 商務的分布式系統中，有支付系統和業務系統，支付系統負責用戶付款，在用戶在銀行付款后需要通知各個業務系統，那么這個時候，既可以用同步也可以用異步， 使用異步的好處就能抵御網站暫時的流量高峰，或者能應對慢消費者。）
JMS是java平台上的消息規范。一般JMS消息不是一個xml，而是一個java對象，很明顯，jms沒考慮異構系統，說白了，JMS就沒考慮 非java的東西。但是好在現在大多數的jms provider（就是JMS的各種實現產品）都解決了異構問題。相比WebService的跨平台各有千秋吧。
RMI與JNDI
RMI是一個能夠建立一個N層應用，擴展中間層，將屬於不同應用的分布對象包容起來，使用跨過中間層來共享數據和邏輯，能真正實現分布式的解決方案。通過 它能夠在運行時，通過網絡發現不同機器的服務程序，並對應用間的通信進行管理，能確保像本地一樣使用遠程對象。在RMI中使用rmiregistry時存 在一定的問題，rmiregistry只是用作測試基於RMI的應用程序的一種方法，當停止並重新啟動rmiregistry時，需要中心注冊其中的所有 對象，針對這種情況，一般會使用JNDI為遠程對象使用一個命名和目錄服務，使用LDAP來保存遠程對象。RMI只是一種遠程對象訪問的接口規范，遵循此 規范的對象可被遠程訪問，但是要使用rmi的服務注冊程序注冊之后才能夠被遠程調用。JNDI是Java命名和目錄服務訪問接口，通過JNDI，可以訪問 已經在命名和目錄服務器中注冊的服務對象，因此，可以把RMI對象注冊在Ldap命名目錄服務器中，然后使用ＪＮＤＩ對遠程對象進行訪問和調用各個對象都 有側重點，作為架構師（技術選型）、性能優化都需要基本知識給予強大的理論支持，各有千秋，充分結合項目的實際情況做出選擇。