總結這些概念都是易混淆,最基本概念定義複習和深入理解,同時也是架構師必備課程
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協議,客戶端直接調用服務端上的一些方法。優點是強類型,編譯期可檢查錯誤,缺點是隻能基於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是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命名目錄服務器中,然後使用JNDI對遠程對象進行訪問和調用
各個對象都有側重點,作爲架構師(技術選型)、性能優化都需要基本知識給予強大的理論支持,各有千秋,充
分結合項目的實際情況做出選擇。