摘要：對(duì)于與而言，則可以看做是消息傳遞技術(shù)的一種衍生或封裝。在生產(chǎn)者通知消費(fèi)者時(shí)，傳遞的往往是消息或事件，而非生產(chǎn)者自身。通過消息路由，我們可以配置路由規(guī)則指定消息傳遞的路徑，以及指定具體的消費(fèi)者消費(fèi)對(duì)應(yīng)的生產(chǎn)者。采用和來進(jìn)行遠(yuǎn)程對(duì)象的通訊。

歸根結(jié)底，企業(yè)應(yīng)用系統(tǒng)就是對(duì)數(shù)據(jù)的處理，而對(duì)于一個(gè)擁有多個(gè)子系統(tǒng)的企業(yè)應(yīng)用系統(tǒng)而言，它的基礎(chǔ)支撐無疑就是對(duì)消息的處理。與對(duì)象不同，消息本質(zhì)上是一種數(shù)據(jù)結(jié)構(gòu)（當(dāng)然，對(duì)象也可以看做是一種特殊的消息），它包含消費(fèi)者與服務(wù)雙方都能識(shí)別的數(shù)據(jù)，這些數(shù)據(jù)需要在不同的進(jìn)程（機(jī)器）之間進(jìn)行傳遞，并可能會(huì)被多個(gè)完全不同的客戶端消費(fèi)。消息傳遞相較文件傳遞與遠(yuǎn)程過程調(diào)用（RPC）而言，似乎更勝一籌，因?yàn)樗哂懈玫钠脚_(tái)無關(guān)性，并能夠很好地支持并發(fā)與異步調(diào)用。

對(duì)于Web Service與RESTful而言，則可以看做是消息傳遞技術(shù)的一種衍生或封裝。

發(fā)起請(qǐng)求將消息序列化傳遞→接受請(qǐng)求將消息反序列化→返回結(jié)果給請(qǐng)求端將消息序列化傳遞

按照網(wǎng)絡(luò)通信原理，需要實(shí)現(xiàn)這個(gè)需要做的就是將請(qǐng)求轉(zhuǎn)換成流，通過傳輸協(xié)議傳輸至遠(yuǎn)端，遠(yuǎn)端計(jì)算機(jī)在接收到請(qǐng)求的流后進(jìn)行處理，處理完畢后將結(jié)果轉(zhuǎn)化為流，并通過傳輸協(xié)議返回給調(diào)用端。

一種方式是廣播機(jī)制，這時(shí)消息通道中的消息在出列的同時(shí)，還需要復(fù)制消息對(duì)象，將消息傳遞給多個(gè)訂閱者。

另一種方式則屬于搶占機(jī)制，它遵循同步方式，在同一時(shí)間只能有一個(gè)訂閱者能夠處理該消息。

平臺(tái)無關(guān)性

生產(chǎn)者與消費(fèi)者只要遵守消息通道的數(shù)據(jù)傳遞格式、處理消息的機(jī)制與時(shí)機(jī)就可以了

支持并發(fā)

消息是以隊(duì)列的形式存在，先進(jìn)先出，可以很好的保證消息的順暢

異步調(diào)用

生產(chǎn)者與消費(fèi)者之間是通過消息通道（Message Channel）連接，是低耦合的。

生產(chǎn)者和消費(fèi)者必須知道通道資源的位置，否則無法知道從哪里發(fā)送（接受）消息（考慮引用Lookup服務(wù)進(jìn)行查找）

以隊(duì)列形式存在，先進(jìn)先出

可以存在多個(gè)生產(chǎn)者和消費(fèi)者

Lookup服務(wù)

Lookup服務(wù)是用來查找通道資源，可以將與通道相關(guān)的信息存儲(chǔ)到配置文件中，Lookup服務(wù)首先通過讀取配置文件來獲得通道。在JMS中就可以通過JNDI來獲取消息通道Queue。

兩種模型的選擇：拉模型與推模型

拉模型是由消息的消費(fèi)者發(fā)起的，主動(dòng)權(quán)把握在消費(fèi)者手中，它會(huì)根據(jù)自己的情況對(duì)生產(chǎn)者發(fā)起調(diào)用。

在基于消息的分布式系統(tǒng)中，拉模型的消費(fèi)者通常以Batch Job的形式，根據(jù)事先設(shè)定的時(shí)間間隔，定期偵聽通道的情況。一旦發(fā)現(xiàn)有消息傳遞進(jìn)來，就會(huì)轉(zhuǎn)而將消息傳遞給真正的處理器（也可以看做是消費(fèi)者）處理消息，執(zhí)行相關(guān)的業(yè)務(wù)。

推模型的主動(dòng)權(quán)常常掌握在生產(chǎn)者手中，消費(fèi)者被動(dòng)地等待生產(chǎn)者發(fā)出的通知，這就要求生產(chǎn)者必須了解消費(fèi)者的相關(guān)信息。

對(duì)于推模型而言，消費(fèi)者無需了解生產(chǎn)者。在生產(chǎn)者通知消費(fèi)者時(shí)，傳遞的往往是消息（或事件），而非生產(chǎn)者自身。同時(shí)，生產(chǎn)者還可以根據(jù)不同的情況，注冊(cè)不同的消費(fèi)者，又或者在封裝的通知邏輯中，根據(jù)不同的狀態(tài)變化，通知不同的消費(fèi)者。

特點(diǎn)

廣播機(jī)制，這時(shí)消息通道中的消息在出列的同時(shí)，還需要復(fù)制消息對(duì)象，將消息傳遞給多個(gè)訂閱者

特點(diǎn)

屬于搶占機(jī)制，它遵循同步方式，在同一時(shí)間只能有一個(gè)訂閱者能夠處理該消息。

無論是Message Channel模式，還是Publisher-Subscriber模式，隊(duì)列在其中都扮演了舉足輕重的角色。然而，在企業(yè)應(yīng)用系統(tǒng)中，當(dāng)系統(tǒng)變得越來越復(fù)雜時(shí)，對(duì)性能的要求也會(huì)越來越高，此時(shí)對(duì)于系統(tǒng)而言，可能就需要支持同時(shí)部署多個(gè)隊(duì)列，并可能要求分布式部署不同的隊(duì)列。這些隊(duì)列可以根據(jù)定義接收不同的消息，例如訂單處理的消息，日志信息，查詢?nèi)蝿?wù)消息等。這時(shí)，對(duì)于消息的生產(chǎn)者和消費(fèi)者而言，并不適宜承擔(dān)決定消息傳遞路徑的職責(zé)。事實(shí)上，根據(jù)S單一職責(zé)原則，這種職責(zé)分配也是不合理的，它既不利于業(yè)務(wù)邏輯的重用，也會(huì)造成生產(chǎn)者、消費(fèi)者與消息隊(duì)列之間的耦合，從而影響系統(tǒng)的擴(kuò)展。

既然這三種對(duì)象（組件）都不宜承擔(dān)這樣的職責(zé)，就有必要引入一個(gè)新的對(duì)象專門負(fù)責(zé)傳遞路徑選擇的功能，這就是所謂的Message Router模式。

通過消息路由，我們可以配置路由規(guī)則指定消息傳遞的路徑，以及指定具體的消費(fèi)者消費(fèi)對(duì)應(yīng)的生產(chǎn)者。例如指定路由的關(guān)鍵字，并由它來綁定具體的隊(duì)列與指定的生產(chǎn)者（或消費(fèi)者）。路由的支持提供了消息傳遞與處理的靈活性，也有利于提高整個(gè)系統(tǒng)的消息處理能力。同時(shí)，路由對(duì)象有效地封裝了尋找與匹配消息路徑的邏輯，就好似一個(gè)調(diào)停者（Meditator），負(fù)責(zé)協(xié)調(diào)消息、隊(duì)列與路徑尋址之間關(guān)系。

為了應(yīng)用的方便，業(yè)界推出了很多基于此原理之上的應(yīng)用級(jí)的協(xié)議，使得大家可以不用去直接操作這么底層的東西，通常應(yīng)用級(jí)的遠(yuǎn)程通信協(xié)議會(huì)提供：

為了避免直接做流操作這么麻煩，提供一種更加易用或貼合語言的標(biāo)準(zhǔn)傳輸格式；

網(wǎng)絡(luò)通信機(jī)制的實(shí)現(xiàn)，就是替你完成了將傳輸格式轉(zhuǎn)化為流，通過某種傳輸協(xié)議傳輸至遠(yuǎn)端計(jì)算機(jī)，遠(yuǎn)端計(jì)算機(jī)在接收到流后轉(zhuǎn)化為傳輸格式，并進(jìn)行存儲(chǔ)或以某種方式通知遠(yuǎn)端計(jì)算機(jī)。

在學(xué)習(xí)應(yīng)用級(jí)的遠(yuǎn)程通信協(xié)議時(shí)，我們可以帶著這幾個(gè)問題進(jìn)行學(xué)習(xí)：

傳輸?shù)臉?biāo)準(zhǔn)格式是什么？

怎么樣將請(qǐng)求轉(zhuǎn)化為傳輸?shù)牧鳎?/p>

怎么接收和處理流？

傳輸協(xié)議是？

不過應(yīng)用級(jí)的遠(yuǎn)程通信協(xié)議并不會(huì)在傳輸協(xié)議上做什么多大的改進(jìn)，主要是在流操作方面，讓應(yīng)用層生成流和處理流的這個(gè)過程更加的貼合所使用的語言或標(biāo)準(zhǔn)，至于傳輸協(xié)議則通常都是可選的，在java領(lǐng)域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS、HTTP，來具體的看看這些遠(yuǎn)程通信的應(yīng)用級(jí)協(xié)議。

RMI（遠(yuǎn)程方法調(diào)用）

RMI是個(gè)典型的為java定制的遠(yuǎn)程通信協(xié)議，我們都知道，在single vm中，我們可以通過直接調(diào)用java object instance來實(shí)現(xiàn)通信，那么在遠(yuǎn)程通信時(shí)，如果也能按照這種方式當(dāng)然是最好了，這種遠(yuǎn)程通信的機(jī)制成為RPC（Remote Procedure Call），RMI正是朝著這個(gè)目標(biāo)而誕生的。

RMI 采用stubs 和 skeletons 來進(jìn)行遠(yuǎn)程對(duì)象(remote object)的通訊。stub 充當(dāng)遠(yuǎn)程對(duì)象的客戶端代理，有著和遠(yuǎn)程對(duì)象相同的遠(yuǎn)程接口，遠(yuǎn)程對(duì)象的調(diào)用實(shí)際是通過調(diào)用該對(duì)象的客戶端代理對(duì)象stub來完成的，通過該機(jī)制RMI就好比它是本地工作，采用tcp/ip協(xié)議，客戶端直接調(diào)用服務(wù)端上的一些方法。優(yōu)點(diǎn)是強(qiáng)類型，編譯期可檢查錯(cuò)誤，缺點(diǎn)是只能基于JAVA語言，客戶機(jī)與服務(wù)器緊耦合。

來看下基于RMI的一次完整的遠(yuǎn)程通信過程的原理：

客戶端發(fā)起請(qǐng)求，請(qǐng)求轉(zhuǎn)交至RMI客戶端的stub類；
stub類將請(qǐng)求的接口、方法、參數(shù)等信息進(jìn)行序列化；
基于socket將序列化后的流傳輸至服務(wù)器端；
服務(wù)器端接收到流后轉(zhuǎn)發(fā)至相應(yīng)的skelton類；
skelton類將請(qǐng)求的信息反序列化后調(diào)用實(shí)際的處理類；
處理類處理完畢后將結(jié)果返回給skelton類；
Skelton類將結(jié)果序列化，通過socket將流傳送給客戶端的stub；
stub在接收到流后反序列化，將反序列化后的Java Object返回給調(diào)用者。

根據(jù)原理來回答下之前學(xué)習(xí)應(yīng)用級(jí)協(xié)議帶著的幾個(gè)問題：

傳輸?shù)臉?biāo)準(zhǔn)格式是什么？是Java ObjectStream。

怎么樣將請(qǐng)求轉(zhuǎn)化為傳輸?shù)牧鳎炕贘ava串行化機(jī)制將請(qǐng)求的java object信息轉(zhuǎn)化為流。

怎么接收和處理流？根據(jù)采用的協(xié)議啟動(dòng)相應(yīng)的監(jiān)聽端口，當(dāng)有流進(jìn)入后基于Java串行化機(jī)制將流進(jìn)行反序列化，并根據(jù)RMI協(xié)議獲取到相應(yīng)的處理對(duì)象信息，進(jìn)行調(diào)用并處理，處理完畢后的結(jié)果同樣基于java串行化機(jī)制進(jìn)行返回。

傳輸協(xié)議是？Socket。

XML-RPC

RPC使用C/S方式，采用http協(xié)議，發(fā)送請(qǐng)求到服務(wù)器，等待服務(wù)器返回結(jié)果。這個(gè)請(qǐng)求包括一個(gè)參數(shù)集和一個(gè)文本集，通常形成“classname.methodname”形式。優(yōu)點(diǎn)是跨語言跨平臺(tái)，C端、S端有更大的獨(dú)立性，缺點(diǎn)是不支持對(duì)象，無法在編譯器檢查錯(cuò)誤，只能在運(yùn)行期檢查。

XML-RPC也是一種和RMI類似的遠(yuǎn)程調(diào)用的協(xié)議，它和RMI的不同之處在于它以標(biāo)準(zhǔn)的xml格式來定義請(qǐng)求的信息(請(qǐng)求的對(duì)象、方法、參數(shù)等)，這樣的好處是什么呢，就是在跨語言通訊的時(shí)候也可以使用。

來看下XML-RPC協(xié)議的一次遠(yuǎn)程通信過程：

客戶端發(fā)起請(qǐng)求，按照XML-RPC協(xié)議將請(qǐng)求信息進(jìn)行填充；
填充完畢后將xml轉(zhuǎn)化為流，通過傳輸協(xié)議進(jìn)行傳輸；
接收到在接收到流后轉(zhuǎn)換為xml，按照XML-RPC協(xié)議獲取請(qǐng)求的信息并進(jìn)行處理；
處理完畢后將結(jié)果按照XML-RPC協(xié)議寫入xml中并返回。

同樣來回答問題：

傳輸?shù)臉?biāo)準(zhǔn)格式是？標(biāo)準(zhǔn)格式的XML。

怎么樣將請(qǐng)求轉(zhuǎn)化為傳輸?shù)牧?？將XML轉(zhuǎn)化為流。

怎么接收和處理流？通過監(jiān)聽的端口獲取到請(qǐng)求的流，轉(zhuǎn)化為XML，并根據(jù)協(xié)議獲取請(qǐng)求的信息，進(jìn)行處理并將結(jié)果寫入XML中返回。

傳輸協(xié)議是？Http。

Binary-RPC

Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在于傳輸?shù)臉?biāo)準(zhǔn)格式由XML轉(zhuǎn)為了二進(jìn)制的格式。

同樣來回答問題：

傳輸?shù)臉?biāo)準(zhǔn)格式是？標(biāo)準(zhǔn)格式的二進(jìn)制文件。

怎么樣將請(qǐng)求轉(zhuǎn)化為傳輸?shù)牧?？將二進(jìn)制格式文件轉(zhuǎn)化為流。

怎么接收和處理流？通過監(jiān)聽的端口獲取到請(qǐng)求的流，轉(zhuǎn)化為二進(jìn)制文件，根據(jù)協(xié)議獲取請(qǐng)求的信息，進(jìn)行處理并將結(jié)果寫入XML中返回。

傳輸協(xié)議是？Http。

SOAP

SOAP原意為Simple Object Access Protocol，是一個(gè)用于分布式環(huán)境的、輕量級(jí)的、基于XML進(jìn)行信息交換的通信協(xié)議，可以認(rèn)為SOAP是XML RPC的高級(jí)版，兩者的原理完全相同，都是http+XML，不同的僅在于兩者定義的XML規(guī)范不同，SOAP也是Webservice采用的服務(wù)調(diào)用協(xié)議標(biāo)準(zhǔn)，因此在此就不多加闡述了。

Web Service提供的服務(wù)是基于web容器的，底層使用http協(xié)議，類似一個(gè)遠(yuǎn)程的服務(wù)提供者，比如天氣預(yù)報(bào)服務(wù)，對(duì)各地客戶端提供天氣預(yù)報(bào)，是一種請(qǐng)求應(yīng)答的機(jī)制，是跨系統(tǒng)跨平臺(tái)的。就是通過一個(gè)servlet，提供服務(wù)出去。

首先客戶端從服務(wù)器獲得WebService的WSDL，同時(shí)在客戶端生成一個(gè)代理類(Proxy Class)，這個(gè)代理類負(fù)責(zé)與WebService服務(wù)器進(jìn)行Request和Response。當(dāng)一個(gè)數(shù)據(jù)（XML格式的）被封裝成SOAP格式的數(shù)據(jù)流發(fā)送到服務(wù)器端的時(shí)候，就會(huì)生成一個(gè)進(jìn)程對(duì)象并且把接收到這個(gè)Request的SOAP包進(jìn)行解析，然后對(duì)事物進(jìn)行處理，處理結(jié)束以后再對(duì)這個(gè)計(jì)算結(jié)果進(jìn)行SOAP包裝，然后把這個(gè)包作為一個(gè)Response發(fā)送給客戶端的代理類(Proxy Class)，同樣地，這個(gè)代理類也對(duì)這個(gè)SOAP包進(jìn)行解析處理，繼而進(jìn)行后續(xù)操作。這就是WebService的一個(gè)運(yùn)行過程。

Web Service大體上分為5個(gè)層次:

Http傳輸信道；
XML的數(shù)據(jù)格式；
SOAP封裝格式；
WSDL的描述方式；
UDDI UDDI是一種目錄服務(wù)，企業(yè)可以使用它對(duì)Webservices進(jìn)行注冊(cè)和搜索；

JMS

JMS是實(shí)現(xiàn)java領(lǐng)域遠(yuǎn)程通信的一種手段和方法，基于JMS實(shí)現(xiàn)遠(yuǎn)程通信時(shí)和RPC是不同的，雖然可以做到RPC的效果，但因?yàn)椴皇菑膮f(xié)議級(jí)別定義的，因此我們不認(rèn)為JMS是個(gè)RPC協(xié)議，但它確實(shí)是個(gè)遠(yuǎn)程通信協(xié)議，在其他的語言體系中也存在著類似JMS的東西，可以統(tǒng)一的將這類機(jī)制稱為消息機(jī)制，而消息機(jī)制呢，通常是高并發(fā)、分布式領(lǐng)域推薦的一種通信機(jī)制，這里的主要一個(gè)問題是容錯(cuò)。

JMS是Java的消息服務(wù)，JMS的客戶端之間可以通過JMS服務(wù)進(jìn)行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點(diǎn)對(duì)點(diǎn)和發(fā)布訂閱模型。

來看JMS中的一次遠(yuǎn)程通信的過程：

客戶端將請(qǐng)求轉(zhuǎn)化為符合JMS規(guī)定的Message；
通過JMS API將Message放入JMS Queue或Topic中；
如為JMS Queue，則發(fā)送中相應(yīng)的目標(biāo)Queue中，如為Topic，則發(fā)送給訂閱了此Topic的JMS Queue。
處理端則通過輪訓(xùn)JMS Queue，來獲取消息，接收到消息后根據(jù)JMS協(xié)議來解析Message并處理。

同樣來回答問題：

傳輸?shù)臉?biāo)準(zhǔn)格式是？JMS規(guī)定的Message。

怎么樣將請(qǐng)求轉(zhuǎn)化為傳輸?shù)牧鳎繉?shù)信息放入Message中即可。

怎么接收和處理流？輪訓(xùn)JMS Queue來接收Message，接收到后進(jìn)行處理，處理完畢后仍然是以Message的方式放入Queue中發(fā)送或Multicast。

傳輸協(xié)議是？不限。

基于JMS也是常用的實(shí)現(xiàn)遠(yuǎn)程異步調(diào)用的方法之一。

RPC與RMI

RPC跨語言，而RMI只支持Java。

RMI調(diào)用遠(yuǎn)程對(duì)象方法，允許方法返回Java對(duì)象以及基本數(shù)據(jù)類型，而RPC不支持對(duì)象的概念，傳送到RPC服務(wù)的消息由外部數(shù)據(jù)表示 (External Data Representation, XDR) 語言表示，這種語言抽象了字節(jié)序類和數(shù)據(jù)類型結(jié)構(gòu)之間的差異。只有由 XDR 定義的數(shù)據(jù)類型才能被傳遞，可以說 RMI 是面向?qū)ο蠓绞降腏ava RPC。

在方法調(diào)用上，RMI中，遠(yuǎn)程接口使每個(gè)遠(yuǎn)程方法都具有方法簽名。如果一個(gè)方法在服務(wù)器上執(zhí)行，但是沒有相匹配的簽名被添加到這個(gè)遠(yuǎn)程接口上，那么這個(gè)新方法就不能被RMI客戶方所調(diào)用。在RPC中，當(dāng)一個(gè)請(qǐng)求到達(dá)RPC服務(wù)器時(shí)，這個(gè)請(qǐng)求就包含了一個(gè)參數(shù)集和一個(gè)文本值，通常形成“classname.methodname”的形式。這就向RPC服務(wù)器表明，被請(qǐng)求的方法在為 “classname”的類中，名叫“methodname”。然后RPC服務(wù)器就去搜索與之相匹配的類和方法，并把它作為那種方法參數(shù)類型的輸入。這里的參數(shù)類型是與RPC請(qǐng)求中的類型是匹配的。一旦匹配成功，這個(gè)方法就被調(diào)用了，其結(jié)果被編碼后返回客戶方。

RPC本身沒有規(guī)范,但基本的工作機(jī)制是一樣的，即：serialization/deserialization+stub+skeleton，寬泛的講，只要能實(shí)現(xiàn)遠(yuǎn)程調(diào)用，都是RPC，如:rmi .net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer。

在Java里提供了完整的sockets通訊接口，但sockets要求客戶端和服務(wù)端必須進(jìn)行應(yīng)用級(jí)協(xié)議的編碼交換數(shù)據(jù)，采用sockets是非常麻煩的。一個(gè)代替Sockets的協(xié)議是RPC(Remote Procedure Call), 它抽象出了通訊接口用于過程調(diào)用，使得編程者調(diào)用一個(gè)遠(yuǎn)程過程和調(diào)用本地過程同樣方便。RPC 系統(tǒng)采用XDR來編碼遠(yuǎn)程調(diào)用的參數(shù)和返回值。但RPC并不支持對(duì)象，所以，面向?qū)ο蟮倪h(yuǎn)程調(diào)用RMI(Remote Method Invocation)成為必然選擇。采用RMI，調(diào)用遠(yuǎn)程對(duì)象和調(diào)用本地對(duì)象同樣方便。RMI 采用JRMP(Java Remote Method Protocol)通訊協(xié)議，是構(gòu)建在TCP/IP協(xié)議上的一種遠(yuǎn)程調(diào)用方法。

JMS與RMI

采用JMS服務(wù)，對(duì)象是在物理上被異步從網(wǎng)絡(luò)的某個(gè)JVM 上直接移動(dòng)到另一個(gè)JVM 上（是消息通知機(jī)制），而RMI對(duì)象是綁定在本地JVM 中，只有函數(shù)參數(shù)和返回值是通過網(wǎng)絡(luò)傳送的（是請(qǐng)求應(yīng)答機(jī)制）。

RMI一般都是同步的，也就是說，當(dāng)client調(diào)用Server的一個(gè)方法的時(shí)候，需要等到對(duì)方的返回，才能繼續(xù)執(zhí)行client端，這個(gè)過程調(diào)用本地方法感覺上是一樣的，這也是RMI的一個(gè)特點(diǎn)。JMS 一般只是一個(gè)點(diǎn)發(fā)出一個(gè)Message到Message Server,發(fā)出之后一般不會(huì)關(guān)心誰用了這個(gè)message。所以，一般RMI的應(yīng)用是緊耦合，JMS的應(yīng)用相對(duì)來說是松散耦合應(yīng)用。

Webservice與RMI

RMI是在tcp協(xié)議上傳遞可序列化的java對(duì)象，只能用在java虛擬機(jī)上，綁定語言，客戶端和服務(wù)端都必須是java。webservice沒有這個(gè)限制，webservice是在http協(xié)議上傳遞xml文本文件，與語言和平臺(tái)無關(guān)。

Webservice與JMS

Webservice專注于遠(yuǎn)程服務(wù)調(diào)用，jms專注于信息交換。

大多數(shù)情況下Webservice是兩系統(tǒng)間的直接交互（Consumer Producer），而大多數(shù)情況下jms是三方系統(tǒng)交互（Consumer Producer）。當(dāng)然，JMS也可以實(shí)現(xiàn)request-response模式的通信，只要Consumer或Producer其中一方兼任broker即可。

JMS可以做到異步調(diào)用完全隔離了客戶端和服務(wù)提供者，能夠抵御流量洪峰；WebService服務(wù)通常為同步調(diào)用，需要有復(fù)雜的對(duì)象轉(zhuǎn)換，相比SOAP，現(xiàn)在JSON，rest都是很好的http架構(gòu)方案；

JMS是java平臺(tái)上的消息規(guī)范。一般jms消息不是一個(gè)xml，而是一個(gè)java對(duì)象，很明顯，jms沒考慮異構(gòu)系統(tǒng)，說白了，JMS就沒考慮非java的東西。但是好在現(xiàn)在大多數(shù)的jms provider（就是JMS的各種實(shí)現(xiàn)產(chǎn)品）都解決了異構(gòu)問題。相比WebService的跨平臺(tái)各有千秋吧。

目前java領(lǐng)域可用于實(shí)現(xiàn)遠(yuǎn)程通訊的框架或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、Mina、Mule、EJB3等等，來對(duì)每種做個(gè)簡單的介紹和評(píng)價(jià)，其實(shí)呢，要做分布式服務(wù)框架，這些東西都是要有非常深刻的了解的，因?yàn)榉植际椒?wù)框架其實(shí)是包含了解決分布式領(lǐng)域以及應(yīng)用層面領(lǐng)域兩方面問題的。

當(dāng)然，你也可以自己根據(jù)遠(yuǎn)程網(wǎng)絡(luò)通信原理(transport protocol+Net IO)去實(shí)現(xiàn)自己的通訊框架或library。

那么在了解這些遠(yuǎn)程通訊的框架或library時(shí)，會(huì)帶著什么問題去學(xué)習(xí)呢？

是基于什么協(xié)議實(shí)現(xiàn)的？

怎么發(fā)起請(qǐng)求？

怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？

使用什么傳輸協(xié)議傳輸？

響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？

怎么將流還原為傳輸格式的？

處理完畢后怎么回應(yīng)？

Spring-Remoting

Spring-remoting是Spring提供java領(lǐng)域的遠(yuǎn)程通訊框架，基于此框架，同樣也可以很簡單的將普通的spring bean以某種遠(yuǎn)程協(xié)議的方式來發(fā)布，同樣也可以配置spring bean為遠(yuǎn)程調(diào)用的bean。

是基于什么協(xié)議實(shí)現(xiàn)的？作為一個(gè)遠(yuǎn)程通訊的框架，Spring通過集成多種遠(yuǎn)程通訊的library，從而實(shí)現(xiàn)了對(duì)多種協(xié)議的支持，例如rmi、http+io、xml-rpc、binary-rpc等。
怎么發(fā)起請(qǐng)求？在Spring中，由于其對(duì)于遠(yuǎn)程調(diào)用的bean采用的是proxy實(shí)現(xiàn)，發(fā)起請(qǐng)求完全是通過服務(wù)接口調(diào)用的方式。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Spring按照協(xié)議方式將請(qǐng)求的對(duì)象信息轉(zhuǎn)化為流，例如Spring Http Invoker是基于Spring自己定義的一個(gè)協(xié)議來實(shí)現(xiàn)的，傳輸協(xié)議上采用的為http，請(qǐng)求信息是基于java串行化機(jī)制轉(zhuǎn)化為流進(jìn)行傳輸。
使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如rmi、http等等。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？響應(yīng)端遵循協(xié)議方式來接收請(qǐng)求，對(duì)于使用者而言，則只需通過spring的配置方式將普通的spring bean配置為響應(yīng)端或者說提供服務(wù)端。
怎么將流還原為傳輸格式的？按照協(xié)議方式來進(jìn)行還原。
處理完畢后怎么回應(yīng)？處理完畢后直接返回即可，spring-remoting將根據(jù)協(xié)議方式來做相應(yīng)的序列化。

Hessian

Hessian是由caucho提供的一個(gè)基于binary-RPC實(shí)現(xiàn)的遠(yuǎn)程通訊library。

是基于什么協(xié)議實(shí)現(xiàn)的？基于Binary-RPC協(xié)議實(shí)現(xiàn)。
怎么發(fā)起請(qǐng)求？需通過Hessian本身提供的API來發(fā)起請(qǐng)求。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Hessian通過其自定義的串行化機(jī)制將請(qǐng)求信息進(jìn)行序列化，產(chǎn)生二進(jìn)制流。
使用什么傳輸協(xié)議傳輸？Hessian基于Http協(xié)議進(jìn)行傳輸。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？響應(yīng)端根據(jù)Hessian提供的API來接收請(qǐng)求。
怎么將流還原為傳輸格式的？Hessian根據(jù)其私有的串行化機(jī)制來將請(qǐng)求信息進(jìn)行反序列化，傳遞給使用者時(shí)已是相應(yīng)的請(qǐng)求信息對(duì)象了。
處理完畢后怎么回應(yīng)？處理完畢后直接返回，hessian將結(jié)果對(duì)象進(jìn)行序列化，傳輸至調(diào)用端。

Burlap

Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC協(xié)議的。

是基于什么協(xié)議實(shí)現(xiàn)的？基于XML-RPC協(xié)議實(shí)現(xiàn)。
怎么發(fā)起請(qǐng)求？根據(jù)Burlap提供的API。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？將請(qǐng)求信息轉(zhuǎn)化為符合協(xié)議的XML格式，轉(zhuǎn)化為流進(jìn)行傳輸。
使用什么傳輸協(xié)議傳輸？Http協(xié)議。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？監(jiān)聽Http請(qǐng)求。
怎么將流還原為傳輸格式的？根據(jù)XML-RPC協(xié)議進(jìn)行還原。
處理完畢后怎么回應(yīng)？返回結(jié)果寫入XML中，由Burlap返回至調(diào)用端。

XFire、Axis

XFire、Axis是Webservice的實(shí)現(xiàn)框架，WebService可算是一個(gè)完整的SOA架構(gòu)實(shí)現(xiàn)標(biāo)準(zhǔn)了，因此采用XFire、Axis這些也就意味著是采用webservice方式了。

是基于什么協(xié)議實(shí)現(xiàn)的？基于SOAP協(xié)議。
怎么發(fā)起請(qǐng)求？獲取到遠(yuǎn)端service的proxy后直接調(diào)用。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？將請(qǐng)求信息轉(zhuǎn)化為遵循SOAP協(xié)議的XML格式，由框架轉(zhuǎn)化為流進(jìn)行傳輸。
使用什么傳輸協(xié)議傳輸？Http協(xié)議。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？監(jiān)聽Http請(qǐng)求。
怎么將流還原為傳輸格式的？根據(jù)SOAP協(xié)議進(jìn)行還原。
處理完畢后怎么回應(yīng)？返回結(jié)果寫入XML中，由框架返回至調(diào)用端。

ActiveMQ

ActiveMQ是JMS的實(shí)現(xiàn)，基于JMS這類消息機(jī)制實(shí)現(xiàn)遠(yuǎn)程通訊是一種不錯(cuò)的選擇，畢竟消息機(jī)制本身的功能使得基于它可以很容易的去實(shí)現(xiàn)同步/異步/單向調(diào)用等，而且消息機(jī)制從容錯(cuò)角度上來說也是個(gè)不錯(cuò)的選擇，這是Erlang能夠做到容錯(cuò)的重要基礎(chǔ)。

是基于什么協(xié)議實(shí)現(xiàn)的？基于JMS協(xié)議。
怎么發(fā)起請(qǐng)求？遵循JMS API發(fā)起請(qǐng)求。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？不太清楚，猜想應(yīng)該是二進(jìn)制流。
使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如socket、http等等。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？監(jiān)聽符合協(xié)議的端口。
怎么將流還原為傳輸格式的？同問題3。
處理完畢后怎么回應(yīng)？遵循JMS API生成消息，并寫入JMS Queue中。

Mina

Mina是Apache提供的通訊框架，在之前一直沒有提到網(wǎng)絡(luò)IO這塊，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO的，NIO在并發(fā)量增長時(shí)對(duì)比BIO而言會(huì)有明顯的性能提升，而java性能的提升，與其NIO這塊與OS的緊密結(jié)合是有不小的關(guān)系的。

是基于什么協(xié)議實(shí)現(xiàn)的？基于純粹的Socket+NIO。
怎么發(fā)起請(qǐng)求？通過Mina提供的Client API。
怎么將請(qǐng)求轉(zhuǎn)化為符合協(xié)議的格式的？Mina遵循java串行化機(jī)制對(duì)請(qǐng)求對(duì)象進(jìn)行序列化。
使用什么傳輸協(xié)議傳輸？支持多種傳輸協(xié)議，例如socket、http等等。
響應(yīng)端基于什么機(jī)制來接收請(qǐng)求？以NIO的方式監(jiān)聽協(xié)議端口。
怎么將流還原為傳輸格式的？遵循java串行化機(jī)制對(duì)請(qǐng)求對(duì)象進(jìn)行反序列化。
處理完畢后怎么回應(yīng)？遵循Mina API進(jìn)行返回。

MINA是NIO方式的，因此支持異步調(diào)用是毫無懸念的。

RPC（Remote Procedure Call）是一種遠(yuǎn)程調(diào)用協(xié)議，簡單地說就是能使應(yīng)用像調(diào)用本地方法一樣的調(diào)用遠(yuǎn)程的過程或服務(wù)，可以應(yīng)用在分布式服務(wù)、分布式計(jì)算、遠(yuǎn)程服務(wù)調(diào)用等許多場(chǎng)景。說起 RPC 大家并不陌生，業(yè)界有很多開源的優(yōu)秀 RPC 框架，例如 Dubbo、Thrift、gRPC、Hprose 等等。下面先簡單介紹一下 RPC 與常用遠(yuǎn)程調(diào)用方式的特點(diǎn)，以及一些優(yōu)秀的開源 RPC 框架。

RPC 與其它遠(yuǎn)程調(diào)用方式比較，RPC 與 HTTP、RMI、Web Service 都能完成遠(yuǎn)程調(diào)用，但是實(shí)現(xiàn)方式和側(cè)重點(diǎn)各有不同。

RPC與HTTP

HTTP（HyperText Transfer Protocol）是應(yīng)用層通信協(xié)議，使用標(biāo)準(zhǔn)語義訪問指定資源（圖片、接口等），網(wǎng)絡(luò)中的中轉(zhuǎn)服務(wù)器能識(shí)別協(xié)議內(nèi)容。HTTP 協(xié)議是一種資源訪問協(xié)議，通過 HTTP 協(xié)議可以完成遠(yuǎn)程請(qǐng)求并返回請(qǐng)求結(jié)果。

HTTP 的優(yōu)點(diǎn)是簡單、易用、可理解性強(qiáng)且語言無關(guān)，在遠(yuǎn)程服務(wù)調(diào)用中包括微博有著廣泛應(yīng)用。HTTP 的缺點(diǎn)是協(xié)議頭較重，一般請(qǐng)求到具體服務(wù)器的鏈路較長，可能會(huì)有 DNS 解析、Nginx 代理等。

RPC 是一種協(xié)議規(guī)范，可以把 HTTP 看作是一種 RPC 的實(shí)現(xiàn)，也可以把 HTTP 作為 RPC 的傳輸協(xié)議來應(yīng)用。RPC 服務(wù)的自動(dòng)化程度比較高，能夠?qū)崿F(xiàn)強(qiáng)大的服務(wù)治理功能，和語言結(jié)合更友好，性能也十分優(yōu)秀。與 HTTP 相比，RPC 的缺點(diǎn)就是相對(duì)復(fù)雜，學(xué)習(xí)成本稍高。

RPC與RMI

RMI（Remote Method Invocation）是指 Java 語言中的遠(yuǎn)程方法調(diào)用，RMI 中的每個(gè)方法都具有方法簽名，RMI 客戶端和服務(wù)器端通過方法簽名進(jìn)行遠(yuǎn)程方法調(diào)用。RMI 只能在 Java 語言中使用，可以把 RMI 看作面向?qū)ο蟮?Java RPC。

RPC與Web Service

Web Service 是一種基于 Web 進(jìn)行服務(wù)發(fā)布、查詢、調(diào)用的架構(gòu)方式，重點(diǎn)在于服務(wù)的管理與使用。Web Service 一般通過 WSDL 描述服務(wù)，使用 SOAP通過 HTTP 調(diào)用服務(wù)。

RPC 是一種遠(yuǎn)程訪問協(xié)議，而 Web Service 是一種體系結(jié)構(gòu)，Web Service 也可以通過 RPC 來進(jìn)行服務(wù)調(diào)用，因此 Web Service 更適合同一個(gè) RPC 框架進(jìn)行比較。當(dāng) RPC 框架提供了服務(wù)的發(fā)現(xiàn)與管理，并使用 HTTP 作為傳輸協(xié)議時(shí)，其實(shí)就是 Web Service。

相對(duì) Web Service，RPC 框架可以對(duì)服務(wù)進(jìn)行更細(xì)粒度的治理，包括流量控制、SLA 管理等，在微服務(wù)化、分布式計(jì)算方面有更大的優(yōu)勢(shì)。

RPC 可基于 HTTP 或 TCP 協(xié)議，Web Service 就是基于 HTTP 協(xié)議的 RPC，它具有良好的跨平臺(tái)性，但其性能卻不如基于 TCP 協(xié)議的 RPC。會(huì)兩方面會(huì)直接影響 RPC 的性能，一是傳輸方式，二是序列化。

眾所周知，TCP 是傳輸層協(xié)議，HTTP 是應(yīng)用層協(xié)議，而傳輸層較應(yīng)用層更加底層，在數(shù)據(jù)傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。

相關(guān)文檔
Java 遠(yuǎn)程通訊技術(shù)及原理分析

更多內(nèi)容可以關(guān)注微信公眾號(hào)，或者訪問AppZone網(wǎng)站