RPC与RMI的区别以及jax-rpc、jax-ws和 axis、xfire的联系和区别
1. RPC 不支持对象， 采用http协议
2. RMI支持传输对象。采用tcp／ip 协议
3. RMI只限于JAVA语言，RPC跨语言
RPC和RMI的简单比较
在RMI和RPC之间最主要的区别在于方法是如何别调用的。在RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行， 但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。在RPC中，当一个请求到达RPC服务器时，这个请求就包含了 一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向RPC服务器表明，被请求的方法在为 “classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里 的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。
分布式计算系统要求运行在不同地址空间不同主机上的对象互相调用。各种分布式系统都有自己的调用协议，如CORBA的IIOP(Internet InterORB Protocol), MTS的DCOM。那么EJB组件呢？在Java里提供了完整的sockets通讯接口，但sockets要求客户端和服务端必须进行应用级协议的编码交 换数据，采用sockets是非常麻烦的。
一个代替Sockets的协议是RPC(Remote Procedure Call), 它抽象出了通讯接口用于过程调用，使得编程者调用一个远程过程和调用本地过程同样方便。RPC 系统采用XDR来编码远程调用的参数和返回值。
但RPC 并不支持对象，而EJB构造的是完全面向对象的分布式系统，所以，面向对象的远程调用RMI(Remote Method Invocation)成为必然选择。采用RMI，调用远程对象和调用本地对象同样方便。RMI采用JRMP(Java Remote Method Protocol)通讯协议，是构建在TCP/IP协议上的一种远程调用方法。
RMI调用机制
RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的。
jax-rpc、jax-ws和 axis、xfire的联系和区别
Sun 和 Java 标准
JAX-RPC 1.0 是 Java 方面的 Web 服务的原始标准。虽然 JAX-RPC 的设计思想是可以为实际 Web 服务实现使用不同的协议实现，但在实践中，仅将其用于 SOAP 服务。已经开发了多个不同的 JAX-RPC 实现，其中使用最广泛的可能就是 Apache 框架了，其次是 Sun Microsystems 作为 Java Web Services Developer Pack 的一部分分发的 Reference Implementation。
在开发 JAX-RPC 1.0 时，行业中的很多人认为 rpc/enc 样式的 SOAP 将成为最方便和易用的 Web 服务。JAX-RPC 1.0 规范要求对 rpc/enc 和 doc/lit 样式进行支持，但并不要求对很多模式特性进行支持。这样就带来了一个很不幸的副作用，使 doc/lit SOAP（此技术是基于模式的）事实上成了一个二流选项。
JAX-RPC 1.0 对 Web 服务功能的认识也有一定的局限。从其名称可以看出，最初的目的是为了支持使用 XML 的远程过程调用（Remote Procedure Call，RPC）操作。Java 当时已经有了一项面向 Java 应用程序间的 RPC 调用的现有技术，即远程方法调用（Remote Method Invocation，RMI）。该规范团队选择了在现有 RMI 接口上对 JAX-RPC 进行建模。只要通过请求-响应操作使用 rpc/enc SOAP，此模型就可相当接近地进行匹配，不过映射到异步操作或其他传输的效果并不理想。到 2003 年底，有关人员认识到，总要对 JAX-RPC 进行大幅修订，以处理这些问题和其他问题，因此 Sun 组成了一个专家组开始进行 JAX-RPC 2.0 规范的开发。
JAX-*
JAX-RPC 2.0 开发工作的主要目标是对各项标准进行更新，以支持 JAX-RPC 1.X 的强制要求（基于 Java 5 特性，如 Annotation 和泛型），改进消息传递支持（包括除 HTTP 外的异步操作和传输），并通过使用 JAXB 2.0 绑定替代 JAX-RPC 1.X 的简单（但局限性很强）内置绑定来改进模式支持。出于对更改范围的强调和其他原因，这个后续标准的名称更改成了 JAX-WS 2.0。JAX-WS 2.0 现在已经提供了预发布版本，其生产版本预计将在 2006 中期推出。
JAX-WS 2.0 成功实现了对 JAX-RPC 1.X 的各种期望，甚至还提供一些额外的功能，如有限的 REST 支持。因为 JAX-WS 2.0 大量使用了 Annotation 和其他 Java 5 特性（这样就不能使用较旧的 JVM），因而一些开发人员可能会在使用时遇到一些问题，但对于很多开发人员而言，依赖 Java 5 特性将是一大优势。一个较为突出的顾虑是，JAX-WS 2.0 并不支持 Web 服务配置的 Annotation 的任何后备选项，这样就可能限制该框架的灵活性和长期优势。
JAX-WS 2.0 和 JAXB 2.0 都在准备绑定到 J2SE 规范的发布 Java 5 版本中。将这些组件作为标准 JVM 安装的一部分将无疑增加对开发人员的吸引力，因为这将避免在各个应用程序中包含大量框架的需求。将大量框架包含在标准 JVM 中的缺点在于（除了会增加基本下载大小外），在需要进行错误修复时，可能会导致很难进行版本控制，就像已经发生在 JAXP 之类的组件身上的情况一样（这些组件已经采用了绑定的方式）。
向互操作性进发
JAX-WS 2.0 直接支持 XOP/MTOM，而并不是其他新的 WCF 技术。不过，在 Sun 声明的与 Microsoft 互操作性承诺中，他们宣布将开发 WCF 中包含的其他技术的 Java 开放源代码版本。这些开放源代码实现将作为大型项目“GlassFish”的一部分进行开发，此项目涵盖了作为 Sun 的应用服务器（包括 JAX-WS 2.0 和 JAXB 2.0 参考实现）的一部分使用的所有技术。
在这些新的开放源代码项目成形之前，我们需要拭目以待。在 Sun 所公布的时间表中，将在 2006 年中期提供一些可用的东西，因此在本系列的后续文章中将能够提供更多的详细信息。
Apache 方法
Apache 项目数年来已在 Web 服务方面进行了大量的工作，其主要精力放在 Java 平台开发上。Apache 当前的 Java SOAP Web 服务生产平台是第三代 Axis 框架。Axis 得到了广泛的使用，这既包括开发人员下载并直接使用，也包括将其作为 SOAP 引擎嵌入到若干不同的应用服务器中。Axis 通常被认为是使用最广泛的 Java SOAP Web 服务平台。
不过，Axis 也有一些缺点。首先，它是基于 JAX-RPC 1.0 标准设计的，而后者在很大程度上约束了 Axis 体系结构，限制了其灵活性。随着为了以 SOAP 处理核心为基础构建新技术而对扩展的需求的增加，这个有限的灵活性就越来越成问题了。同时，转向 doc/lit SOAP 服务也带来了对更好模式支持的需求，对 Axis 代码而言，这在当时是非常不实际的。到 2004 年中期，Axis 团队认为需要重新进行编写工作，要在进行重新编写工作中应用通过实现 Axis 获得的经验，并同时提供更好的灵活性，以便将来进行扩展。
“救世主”Axis2
Axis2 是 Axis 的后续版本。它设计为轻量 SOAP 处理引擎（尽管对于 JAX-WS 2.0，Axis2 也包含一些对 REST 的支持），可以采用很多方式进行扩展。与原来的 Axis 不同，Axis2 并不刻意对实现任何特定 API 进行约束（尽管一些 JAX-WS 2.0 支持级计划使用 Axis2 核心代码的包装）。Axis2 的开发工作已经持续了一年多，不久就将投入生产。
Axis2 最好的特性之一就是为 SOAP 消息使用的 AXIOM 对象模型。XML 对象模型存在的时间几乎和 XML 本身一样长，最早的版本是来自 W3C 的 DOM 标准。AXIOM 和其他 XML 对象模型不同的地方在于，它利用新的 XML 解析器提供的灵活性来允许按需构造对象模型。这意味着，只有为实际需要通过模型访问的 XML 文档部分构建对象模型才会带来性能损失。
另一个主要 Axis2 特性是对可插入数据绑定的支持。此特性允许您选择最简单的方式来处理 SOAP 文档的 XML 有效载荷，对生成的代码进行自定义，以使用所选择的方法。可能的选择包括，直接使用 AXIOM，使用与原来的 Axis 相似的简单数据绑定方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等专用数据绑定框架。
扩展 Axis2
尽管 Axis2 仍然在开发中，不过已经有了一系列在 Axis2 基础上实现 SOAP 扩展的项目。这些项目包括 WCF 所支持的所有主要技术以及 Microsoft 计划在加载项（即独立计价的）应用程序中的一些扩展。Axis2 的体系结构允许使用一个称为模块 的组件方便地开发此类扩展。
WS-Addressing 和 WS-Security 模块当前包含在基础 Axis2 分发中（在将来将可能作为独立部分下载，或者甚至成为独立的项目，因为这些模块和核心 Axis2 代码之间并没有紧密耦合关系）。WS-ReliableMessaging 支持正在通过 Sandesha 项目开发，而 WS-Trust 和 WS-SecureConversation 正在通过 WSS4J 项目开发（已经提供了 WS-Security 实现）。WS-AtomicTransaction 和 WS-Coordination 正在通过 Kandula 项目进行实现。
总结：由此可见，Axis对JAX-RPC进行了实现，但Axis2并没有完全实现JAX-WS规范。
JAX-RPC和JAX-WS是WebService的规范。
JAX-WS 2.0 是 JAX-RPC 1.1 的后续版本。
@see http://www.ibm.com/developerworks/cn/webservices/ws-jaxrpc/part1/
@see http://www.ibm.com/developerworks/cn/webservices/ws-tip-jaxwsrpc.html
axis和xfire是WebService的开源实现。
axis现在有两个版本axis1和axis2,xfire已经更名为cxf
@see ws.apache.org
@see cxf.apache.org
2. RMI支持传输对象。采用tcp／ip 协议
3. RMI只限于JAVA语言，RPC跨语言
RPC和RMI的简单比较
在RMI和RPC之间最主要的区别在于方法是如何别调用的。在RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行， 但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。在RPC中，当一个请求到达RPC服务器时，这个请求就包含了 一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向RPC服务器表明，被请求的方法在为 “classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里 的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。
分布式计算系统要求运行在不同地址空间不同主机上的对象互相调用。各种分布式系统都有自己的调用协议，如CORBA的IIOP(Internet InterORB Protocol), MTS的DCOM。那么EJB组件呢？在Java里提供了完整的sockets通讯接口，但sockets要求客户端和服务端必须进行应用级协议的编码交 换数据，采用sockets是非常麻烦的。
一个代替Sockets的协议是RPC(Remote Procedure Call), 它抽象出了通讯接口用于过程调用，使得编程者调用一个远程过程和调用本地过程同样方便。RPC 系统采用XDR来编码远程调用的参数和返回值。
但RPC 并不支持对象，而EJB构造的是完全面向对象的分布式系统，所以，面向对象的远程调用RMI(Remote Method Invocation)成为必然选择。采用RMI，调用远程对象和调用本地对象同样方便。RMI采用JRMP(Java Remote Method Protocol)通讯协议，是构建在TCP/IP协议上的一种远程调用方法。
RMI调用机制
RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的。
jax-rpc、jax-ws和 axis、xfire的联系和区别
Sun 和 Java 标准
JAX-RPC 1.0 是 Java 方面的 Web 服务的原始标准。虽然 JAX-RPC 的设计思想是可以为实际 Web 服务实现使用不同的协议实现，但在实践中，仅将其用于 SOAP 服务。已经开发了多个不同的 JAX-RPC 实现，其中使用最广泛的可能就是 Apache 框架了，其次是 Sun Microsystems 作为 Java Web Services Developer Pack 的一部分分发的 Reference Implementation。
在开发 JAX-RPC 1.0 时，行业中的很多人认为 rpc/enc 样式的 SOAP 将成为最方便和易用的 Web 服务。JAX-RPC 1.0 规范要求对 rpc/enc 和 doc/lit 样式进行支持，但并不要求对很多模式特性进行支持。这样就带来了一个很不幸的副作用，使 doc/lit SOAP（此技术是基于模式的）事实上成了一个二流选项。
JAX-RPC 1.0 对 Web 服务功能的认识也有一定的局限。从其名称可以看出，最初的目的是为了支持使用 XML 的远程过程调用（Remote Procedure Call，RPC）操作。Java 当时已经有了一项面向 Java 应用程序间的 RPC 调用的现有技术，即远程方法调用（Remote Method Invocation，RMI）。该规范团队选择了在现有 RMI 接口上对 JAX-RPC 进行建模。只要通过请求-响应操作使用 rpc/enc SOAP，此模型就可相当接近地进行匹配，不过映射到异步操作或其他传输的效果并不理想。到 2003 年底，有关人员认识到，总要对 JAX-RPC 进行大幅修订，以处理这些问题和其他问题，因此 Sun 组成了一个专家组开始进行 JAX-RPC 2.0 规范的开发。
JAX-*
JAX-RPC 2.0 开发工作的主要目标是对各项标准进行更新，以支持 JAX-RPC 1.X 的强制要求（基于 Java 5 特性，如 Annotation 和泛型），改进消息传递支持（包括除 HTTP 外的异步操作和传输），并通过使用 JAXB 2.0 绑定替代 JAX-RPC 1.X 的简单（但局限性很强）内置绑定来改进模式支持。出于对更改范围的强调和其他原因，这个后续标准的名称更改成了 JAX-WS 2.0。JAX-WS 2.0 现在已经提供了预发布版本，其生产版本预计将在 2006 中期推出。
JAX-WS 2.0 成功实现了对 JAX-RPC 1.X 的各种期望，甚至还提供一些额外的功能，如有限的 REST 支持。因为 JAX-WS 2.0 大量使用了 Annotation 和其他 Java 5 特性（这样就不能使用较旧的 JVM），因而一些开发人员可能会在使用时遇到一些问题，但对于很多开发人员而言，依赖 Java 5 特性将是一大优势。一个较为突出的顾虑是，JAX-WS 2.0 并不支持 Web 服务配置的 Annotation 的任何后备选项，这样就可能限制该框架的灵活性和长期优势。
JAX-WS 2.0 和 JAXB 2.0 都在准备绑定到 J2SE 规范的发布 Java 5 版本中。将这些组件作为标准 JVM 安装的一部分将无疑增加对开发人员的吸引力，因为这将避免在各个应用程序中包含大量框架的需求。将大量框架包含在标准 JVM 中的缺点在于（除了会增加基本下载大小外），在需要进行错误修复时，可能会导致很难进行版本控制，就像已经发生在 JAXP 之类的组件身上的情况一样（这些组件已经采用了绑定的方式）。
向互操作性进发
JAX-WS 2.0 直接支持 XOP/MTOM，而并不是其他新的 WCF 技术。不过，在 Sun 声明的与 Microsoft 互操作性承诺中，他们宣布将开发 WCF 中包含的其他技术的 Java 开放源代码版本。这些开放源代码实现将作为大型项目“GlassFish”的一部分进行开发，此项目涵盖了作为 Sun 的应用服务器（包括 JAX-WS 2.0 和 JAXB 2.0 参考实现）的一部分使用的所有技术。
在这些新的开放源代码项目成形之前，我们需要拭目以待。在 Sun 所公布的时间表中，将在 2006 年中期提供一些可用的东西，因此在本系列的后续文章中将能够提供更多的详细信息。
Apache 方法
Apache 项目数年来已在 Web 服务方面进行了大量的工作，其主要精力放在 Java 平台开发上。Apache 当前的 Java SOAP Web 服务生产平台是第三代 Axis 框架。Axis 得到了广泛的使用，这既包括开发人员下载并直接使用，也包括将其作为 SOAP 引擎嵌入到若干不同的应用服务器中。Axis 通常被认为是使用最广泛的 Java SOAP Web 服务平台。
不过，Axis 也有一些缺点。首先，它是基于 JAX-RPC 1.0 标准设计的，而后者在很大程度上约束了 Axis 体系结构，限制了其灵活性。随着为了以 SOAP 处理核心为基础构建新技术而对扩展的需求的增加，这个有限的灵活性就越来越成问题了。同时，转向 doc/lit SOAP 服务也带来了对更好模式支持的需求，对 Axis 代码而言，这在当时是非常不实际的。到 2004 年中期，Axis 团队认为需要重新进行编写工作，要在进行重新编写工作中应用通过实现 Axis 获得的经验，并同时提供更好的灵活性，以便将来进行扩展。
“救世主”Axis2
Axis2 是 Axis 的后续版本。它设计为轻量 SOAP 处理引擎（尽管对于 JAX-WS 2.0，Axis2 也包含一些对 REST 的支持），可以采用很多方式进行扩展。与原来的 Axis 不同，Axis2 并不刻意对实现任何特定 API 进行约束（尽管一些 JAX-WS 2.0 支持级计划使用 Axis2 核心代码的包装）。Axis2 的开发工作已经持续了一年多，不久就将投入生产。
Axis2 最好的特性之一就是为 SOAP 消息使用的 AXIOM 对象模型。XML 对象模型存在的时间几乎和 XML 本身一样长，最早的版本是来自 W3C 的 DOM 标准。AXIOM 和其他 XML 对象模型不同的地方在于，它利用新的 XML 解析器提供的灵活性来允许按需构造对象模型。这意味着，只有为实际需要通过模型访问的 XML 文档部分构建对象模型才会带来性能损失。
另一个主要 Axis2 特性是对可插入数据绑定的支持。此特性允许您选择最简单的方式来处理 SOAP 文档的 XML 有效载荷，对生成的代码进行自定义，以使用所选择的方法。可能的选择包括，直接使用 AXIOM，使用与原来的 Axis 相似的简单数据绑定方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等专用数据绑定框架。
扩展 Axis2
尽管 Axis2 仍然在开发中，不过已经有了一系列在 Axis2 基础上实现 SOAP 扩展的项目。这些项目包括 WCF 所支持的所有主要技术以及 Microsoft 计划在加载项（即独立计价的）应用程序中的一些扩展。Axis2 的体系结构允许使用一个称为模块 的组件方便地开发此类扩展。
WS-Addressing 和 WS-Security 模块当前包含在基础 Axis2 分发中（在将来将可能作为独立部分下载，或者甚至成为独立的项目，因为这些模块和核心 Axis2 代码之间并没有紧密耦合关系）。WS-ReliableMessaging 支持正在通过 Sandesha 项目开发，而 WS-Trust 和 WS-SecureConversation 正在通过 WSS4J 项目开发（已经提供了 WS-Security 实现）。WS-AtomicTransaction 和 WS-Coordination 正在通过 Kandula 项目进行实现。
总结：由此可见，Axis对JAX-RPC进行了实现，但Axis2并没有完全实现JAX-WS规范。
JAX-RPC和JAX-WS是WebService的规范。
JAX-WS 2.0 是 JAX-RPC 1.1 的后续版本。
@see http://www.ibm.com/developerworks/cn/webservices/ws-jaxrpc/part1/
@see http://www.ibm.com/developerworks/cn/webservices/ws-tip-jaxwsrpc.html
axis和xfire是WebService的开源实现。
axis现在有两个版本axis1和axis2,xfire已经更名为cxf
@see ws.apache.org
@see cxf.apache.org