RPC（Remote Procedure Call Protocol）

       RPC使用C/S方式，採用http協議,傳送請求到伺服器，等待伺服器返回結果。這個請求包括一個引數集和一個文字集，通常形成“classname.methodname”形式。優點是跨語言跨平臺，C端、S端有更大的獨立性，缺點是不支援物件，不支援非同步呼叫，無法在編譯器檢查錯誤，只能在執行期檢查。

Web Service

      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協議，客戶端直接呼叫服務端上的一些方法。優點是強型別，編譯期可檢查錯誤，缺點是隻能基於

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是Java EE 中的一個規範，該規範描述了分散式應用程式需要解決的問題，例如事務處理、安全、日誌、分佈

式等，而同時呢，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的關係

它們其實是沒有多大關係的，它們都是Java EE的規範，ejb的一種類MDB實現了JMS規範，當然是先JMS規範的

不止有ejb的mdb，比如apache  ActiveMQ也是

Web service與EJB

對這兩個常常有點迷惑人，因為他們都實現了分散式應用呼叫，雖然他們很相似但是還是有很多區別的，首先通

信協議是不一樣的，ejb採用rmi-iiop協議，Web service利用http協議傳輸資料，優點常識的都知道http協議支援的較廣

泛，從這點來看Web Service層次要高一些、俗話說站得高看得遠。

Webservice主要關注於解決異構系統、不同語言系統通訊，其關注的是分散式服務開發、著手點要高、站的角度高，

而ejb可以看做是分散式程式設計平臺，通過容器和元件，簡化了程式開發、除錯和部署等它關注的是分散式元件開發，粒

度小。
 Web service可以看做是異構系統、異構語言系統間通訊的一個標準，而ejb只屬於J2EE規範的一部分。
ejb底層用rmi-iiop協議進行通訊，防火牆會阻止；web service是基於http協議進行通訊，防火牆不會阻止。

幾者的區別與聯絡

RPC與RMI

（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命名目錄伺服器中，然後使用ＪＮＤＩ對遠端物件進行訪問和呼叫

       各個物件都有側重點，作為架構師（技術選型）、效能優化都需要基本知識給予強大的理論支援，各有千秋，充

分結合專案的實際情況做出選擇。