rpc代理

㈠ 什麼是rpcss服務

即遠程過程調用，全稱為Remote Procere Call，遠程過程調用是對數據進行處理後顯示或列印；SAP系統回RPC調用的原理其實很簡答單，有一些類似於三層構架的C/S系統，第三方的客戶程序通過介面調用SAP內部的標准或自定義函數，獲得函數返回的數據進行處理後顯示或列印。

RPC的概念與技術早在1981年由Nelson提出。1984年，Birrell和Nelson把其用於支持異構型分布式系統間的通訊。Birrell的RPC 模型引入存根進程( stub) 作為遠程的本地代理，調用RPC運行時庫來傳輸網路中的調用。

(1)rpc代理擴展閱讀：

遠程過程調用可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的，按理說它和REST不是一個層面意義上的東西，不應該放在一起討論，但是誰讓REST這么流行呢，它是目前最流行的一套互聯網應用程序的API設計標准，某種意義下，我們說 REST 可以其實就是指代 HTTP 協議。

遠程過程調用是服務端提供好方法給客戶端調用，客戶端需要知道服務端的具體類，具體方法，然後像調用本地方法一樣直接調用它。

㈡ 當我們調用第三方介面時屬於RPC調用嗎

是rpc吧
rpc一般指的是像調用本地代碼那樣調用遠程代碼，一般都是在本地建了個代理來完成

㈢ 消息代理 與 RPC框架 有什麼區別和聯系

Q 是生產者消費者模式。
RPC 是請求響應模式。
MQ 是面向數據的。
RPC 是面向動作的。

protocol buffer 只是一個序列化方式，並不是 RPC。

㈣ IIS服務中的「web服務擴展」中為什麼沒有「RPC代理服務」

你看看這個吧，搞Exchange要通讀文檔後才好弄。當初我把exchange和windows 2003的所有的官方文檔都看遍了。

http://technet.microsoft.com/zh-cn/library/bb124876%28EXCHG.65%29.aspx

>你誤會我的意思了！我是專門做ISA的，相對懂一些郵件和系統，但是IIS中缺少一個插件，我的 exchange sp2的。打了補丁，但是就是沒有哪個擴展選項，你能告訴我如何才能有這個擴展選項么？你那個文檔我看了，裡面沒有提及如何才能有，只是在配置完成的情況下如何搭建「RPC代理服務」

上面的文檔里有，但你沒仔細看。我在我的一台win2k3上找了下，你要做如下操作：
1、在 add or remove programs 裡面選擇
add/remove windows components
2、在networkings services 里找到 rpc over http proxy,鉤上它。
3、安裝完畢後，在IIS的web service extensions里就有rpc proxy server extension 了

㈤ 如何驗證 RPC 代理伺服器是否已配置基本身份驗證

過程驗證 RPC 代理虛擬伺服器是否已配置為使用基本身份驗證 啟動「Internet 信息服務 (IIS) 管理器」內。 展開「computername」（本容地計算機），再展開「網站」，再展開在其中配置 Rpc 應用程序的網站，用滑鼠右鍵單擊「Rpc」，然後單擊「屬性」。 單擊「目錄安全性」選項卡，再單擊「身份驗證和訪問控制」下的「編輯」。 單擊以選中「基本身份驗證(以明文形式發送密碼)」復選框。您將收到以下消息： 您所選擇的驗證選項會造成未經過加密的密碼在網路上傳輸。想危害您的系統安全的人可用協議分析器檢查在身份驗證過程中使用的用戶密碼。有關用戶身份驗證的詳細信息，請參照聯機幫助。此警告不適用於 HTTPS (orSSL) 連接。 您確定要繼續嗎?注意： 在此消息中，「HTTPS (orSSL)」一詞是單詞「HTTPS (or SSL)」的錯誤拼寫。 單擊「確定」兩次。

㈥ 為什麼需要RPC，而不是簡單的HTTP介面

伺服器通訊原理就來是一台自socket伺服器A,另一台socket客戶端B,現在如果要通訊的話直接以流方式寫入或讀出。這樣能實現通訊，但有個問題。如
何知道更多信息？比如需要發送流大小，編碼，Ip等。這樣就有了協議，協議就是規范，就是發送的流中攜帶了很多的內容。那回到剛剛的問題。

發送的內容就是文本類型，客戶端就得序列化，那麼常用的就有json，xml之類

如果想把內容變得更小，那就有二進制了。把文本變成二進制傳遞。

說到 rpc 與http介面，不要太復雜了。rpc 協議更簡單內容更小，那麼來說效率是要高一點

然後rpc 是什麼。就是socket 加動態代理，你去想想，為什麼客戶端能調用你的service .

㈦ 如何驗證 RPC 代理伺服器擴展是否正確載入

過程驗證 RPC 代理伺服器擴展是否正確載入 在 Exchange Server 上，單擊「開始」，指向「管理工具」，然後單擊 RPC 代理伺服器上的「Internet 信息服務 (IIS) 管理器」。 在 RPC 代理伺服器圖標下，單擊「Web 服務擴展」。 在右窗格中，單擊「RPC 代理伺服器擴展」，然後單擊「屬性」。 確認 Rpcproxy.dll文件的路徑是否正確。正確位置如下： %systemroot%\system32\rpcproxy\rpcproxy.dll 例如，正確位置可能是： c:\windows\system32\rpcproxy\rpcproxy.dll 請仔細檢查路徑條目，因為它可能被錯誤設置為： %systemroot%\system32\rpcproxy.dll 例如，當前位置可能被設置為： c:\windows\system32\rpcproxy.dll 此錯誤路徑匆匆一看似乎是正確的。 注意：Rpcproxy.dll 文件可能在這兩個位置中都存在；您不必刪除或修改其中任何一個位置中的該文件。如果發現此路徑條目設置正確，那麼 Rpcproxy.dll 文件可能已丟失或損壞。如果是這樣，可能需要放回或重新注冊 Rpcproxy.dll 文件。 此外，如果遇到此問題，會在 RPC 代理伺服器上的 IIS 日誌中記錄以下 404 錯誤： 此 404 錯誤可能是由已禁用或不能正常運行的 Web 服務擴展引起的。有關詳細信息，請參閱以下 Microsoft 知識庫文章 248033：

㈧ 請分析面向消息的通信方式與rpc和rmi有什麼區別

RPC（ Procere 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語言，客戶機與伺服器緊耦合。
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 <--> Procer），而大多數情況下jms是三方系統交互（Consumer <- Broker -> Procer）。當然，JMS也可以實現request-response模式的通信，只要Consumer或Procer其中一方兼任broker即可。
JMS可以做到非同步調用完全隔離了客戶端和服務提供者，能夠抵禦流量洪峰； WebService服務通常為同步調用，需要有復雜的對象轉換，相比SOAP，現在JSON，rest都是很好的http架構方案；（舉一個例子，電子商務的分布式系統中，有支付系統和業務系統，支付系統負責用戶付款，在用戶在銀行付款後需要通知各個業務系統，那麼這個時候，既可以用同步也可以用非同步，使用非同步的好處就能抵禦網站暫時的流量高峰，或者能應對慢消費者。）
JMS是java平台上的消息規范。一般jms消息不是一個xml，而是一個java對象，很明顯，jms沒考慮異構系統，說白了，JMS就沒考慮非java的東西。但是好在現在大多數的jms provider（就是JMS的各種實現產品）都解決了異構問題。相比WebService的跨平台各有千秋吧。

㈨ 主流的RPC框架有哪些

Thrift 是由 Facebook 開源的一個 RPC 框架，現在已經掛在 apache.org 下了。主要的幾個好處：
1. 支持非常多語言，包括在內 WEB 開發中很常容用的 PHP，以及最重要的 C++/Python/Java 等 WEB後端常用語言，當然，還包括很 cool 的 Ruby、Erlang。
2. 完整的 RPC 框架實現，用腳本生成通訊相關的框架代碼，開發者只需要集中精力處理好 業務邏輯。比如搭建一個 Hello World Service 只需要幾分鍾。
3.擁有被 Facebook、Last.fm 等不少大規模互聯網應用驗證過的性能和可用性。

Hessian是一款基於HTTP協議的RPC框架，採用的是二進制RPC協議，非常輕量級 ，且速度較快。

當然，還有Hetty，它是一款構建於Netty和Hessian基礎上的高性能的RPC框架。