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框架。