SOA面向服務的軟件架構（Service Oriented Architecture）
是一種計算機軟件的設計模式，主要應用於不通應用組件中通過某種協議來互操作
它的基本設計原理是：服務提供了一個簡單的接口，抽象了底層的複雜性，然後用戶可以訪問獨立的服務，而不需要去了解服務底層平臺實現。
RPC（Remote Procedure Call Protocol）
RPC使用C/S方式，採用http協議,發送請求到服務器，等待服務器返回結果。這個請求包括一個參數集和一個文本集，通常形成“classname.methodname”形式，這就向RPC服務器表明，被請求的方法在爲“classname”的類中，名叫“methodname”。然後RPC服務器就去搜索與之相匹配的類和方法，並把它作爲那種方法參數類型的輸入。這裏的參數類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼後返回客戶方。 RPC 不支持對象的概念，傳送到 RPC 服務的消息由外部數據表示 (External Data Representation, XDR) 語言表示，這種語言抽象了字節序類和數據類型結構之間的差異。只有由 XDR 定義的數據類型才能被傳遞， RPC 不允許傳遞對象。優點是跨語言跨平臺，C端、S端有更大的獨立性，缺點是不支持對象，無法在編譯器檢查錯誤，只能在運行期檢查。
Web Service
Web Service提供的服務是基於web容器的，底層使用http協議，類似一個遠程的服務提供者，比如天氣預報服務，對各地客戶端提供天氣預報，是一種請求應答的機制，是跨系統跨平臺的。
首先客戶端從服務器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責與WebService
服務器進行Request 和Response 當一個數據（XML格式的）被封裝成SOAP格式的數據流發送到服務器端的時候，就會生成一個進程對象並且把接收到這個Request的SOAP包進行解析，然後對事物進行處理，處理結束以後再對這個計算結果進行SOAP
包裝，然後把這個包作爲一個Response發送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行後續操作。這就是WebService的一個運行過程。
webservice是一種標準，他可以通過soap或rest的方式來實現。
傳統的soap-webservice，使用了soap協議（基於xml包裝）等。如果使用restful-webservice的話，則不需要soap與之相關的協議等，而是通過最簡單的 http 協議傳輸數據 ( 包括 xml 或 json) 。既簡化了設計，也減少了網絡傳輸量（因爲只傳輸代表數據的 xml 或 json ，沒有額外的 xml 包裝）。
Web Service主要涉及的概念:
1. Http傳輸信道
2. XML的數據格式
3. SOAP封裝格式
4. WSDL的描述方式
5. UDDI UDDI是一種目錄服務，企業可以使用它對Webservices進行註冊和搜索
關於SOAP
SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴格定義的信息交換協議，用於在Web Service中把遠程調用和返回封裝成機器可讀的格式化數據。事實上SOAP數據使用XML數據格式，定義了一整套複雜的標籤，以描述調用的遠程過程、參數、返回值和出錯信息等等。而且隨着需要的增長，又不得增加協議以支持安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另一方面，各個服務器都可以基於這個協議推出自己的API，即使它們提供的服務及其相似，定義的API也不盡相同，這又導致了WSDL的誕生。WSDL
(Web Service Description Language) 也遵循XML格式，用來描述哪個服務器提供什麼服務，怎樣找到它，以及該服務使用怎樣的接口規範，簡言之，服務發現。現在，使用Web Service的過程變成，獲得該服務的WSDL描述，根據WSDL構造一條格式化的SOAP請求發送給服務器，然後接收一條同樣SOAP格式的應答，最後根據先前的WSDL解碼數據。絕大多數情況下，請求和應答使用HTTP協議傳輸，那麼發送請求就使用HTTP的POST方法。
RMI （Remote Method Invocation）
RMI 採用stubs 和 skeletons 來進行遠程對象(remote object)的通訊。stub 充當遠程對象的客戶端代理，有着和遠程對象相同的遠程接口，遠程對象的調用實際是通過調用該對象的客戶端代理對象stub來完成的，通過該機制RMI就好比它是本地工作，採用tcp/ip協議，客戶端直接調用服務端上的一些方法。優點是強類型，編譯期可檢查錯誤，缺點是隻能基於Java語言，客戶機與服務器緊耦合。
JMS（Java Messaging Service）
JMS是Java的消息服務，JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點對點和發佈訂閱模型。
幾者的區別與聯繫
1、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請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼後返回客戶方。
2、JMS和RMI
採用JMS 服務，對象是在物理上被異步從網絡的某個JVM 上直接移動到另一個JVM 上（是消息通知機制）
而RMI 對象是綁定在本地JVM 中，只有函數參數和返回值是通過網絡傳送的（是請求應答機制）。
RMI一般都是同步的，也就是說，當client調用Server的一個方法的時候，需要等到對方的返回，才能繼續執行client端，這個過程調用本地方法感覺上是一樣的，這也是RMI的一個特點。
JMS 一般只是一個點發出一個Message到Message Server,發出之後一般不會關心誰用了這個message。
所以，一般RMI的應用是緊耦合，JMS的應用相對來說是鬆散耦合應用。
3、Webservice與RMI
RMI是在tcp協議上傳遞可序列化的java對象，只能用在java虛擬機上，綁定語言，客戶端和服務端都必須是java
webservice沒有這個限制，webservice是在http協議上傳遞xml文本文件，與語言和平臺無關
4、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的跨平臺各有千秋吧。
5.REST與SOAP
REST(Representational State Transfer)一種輕量級的Web Service架構，可以完全通過HTTP協議實現。其實現和操作比SOAP和XML-RPC更爲簡潔，還可以利用緩存Cache來提高響應速度，性能、效率和易用性上都優於SOAP協議。
REST架構對資源的操作包括獲取、創建、修改和刪除資源的操作正好對應HTTP協議提供的GET、POST、PUT和DELETE方法(Verb)