RPC or noRPC,这是个问题

/**

   * author:ahuaxuan

   * date:2010-04-21

   */

修改,避免引起混淆,特别说明本文中的非RPC方式其本质也是RPC,只是非RPC由服务器端定义好序列化规则和协议,然后让调用者自己去实现,而本文中的RPC指服务提供者提供Jar,客户端可以直接调用接口.不需要考虑到网络,协议,序列化算法.

 

很多公司都会遇到应用集成的一些问题,其中一项就是RPC的问题.


企业内部应用集成(请求应答模式)的通信一般有方式,一种是RPC方式,另外一个是非RPC方式.
先说说非RPC方式的实现:比如说A-Y这25个应用依赖于Z这个应用,那么Z应用将丢一个开发文档给A-Y个应用的开发人员,告诉他们说,
照着文档开发吧,A-Y个应用的开发人员打开文档,看到一个URL, 然后就是URL中需要的参数.

于是A-Y个应用开始开发各自和Z应用通信的程序.

RPC方式实现:
Z应用直接提供一个jar包给A-Y个应用,然后A-Y应用导入这个jar,然后直接调用接口.具体的实现可以参考hessian RPC.

使用RPC的好处是你不需要考虑对象这么序列化成bytes传到server,也不需要考虑从server过来的bytes这么反序列化成接口的返回值.

这些内部的实现A-Y的开发者完全不需要考虑.

很多人偏向RPC方式,也有人偏向非PRC方式.那么ahuaxuan先来阐述一下他们的优缺点:

非RPC方式:
优点:
1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包
2.A-Y的代码不需要引入Z应用的J <script src="/javascripts/tinymce/themes/advanced/langs/zh.js" type="text/javascript"></script><script src="/javascripts/tinymce/plugins/javaeye/langs/zh.js" type="text/javascript"></script> ar包.
3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任.

缺点:
1.A-Y的开发者重复造轮子,25次.
2.A-Y的测试者重复测试.
3.如果一个client的实现+单元测试+ 集成测试和调试需要4 manday,那么24次多余的劳动会带来96个manday的浪费
4.重复的测试达到24次,每次是2个manday,那么又48个manday的浪费,总共的浪费高达96+48=144manday.
5.每次Z的修改都可能造成这样的浪费.

6.文档中要定义接口的错误状态码.然后客户端需要关心这些状态码的实现.


再说说RPC方式:
优点:
1.A-Y个应用不需要开发这个功能,直接引入jar包,调用接口,2分钟完成这部分工作.
2.Z应用对外的接口在Z的新版本开发时不修改老接口,只增加新接口.达到一定的兼容性.

3.不需要考虑对象这么序列化成bytes传到server,也不需要考虑从server过来的bytes这么反序列化成接口的返回值.

这些内部的实现A-Y的开发者完全不需要考虑.

4.不需要考虑序列化完成之后的bytes怎么传输,是http,还是直接基于TCP, 是nio还是bio等等

5.异常可以直接序列化到客户端,客户端调用者不需要去研究什么状态码,只要看一下异常的种类就行了.

6.客户端可以直接验证输入参数的合法性,无需到服务器上验证, 提供接口的人更清楚他们接受什么样的参数

缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.




接下来请各位同学做一道选择题:

请站在非A-Z应用的开发者角度(请站在对整个架构有利的角度)来选择这些企业内部应用集成的方式:

 

A. RPC方式
B. 非RPC方式
如果你有除了我上面列出的其他优缺点,可以在你选择的答案后面列出来.


虽然这不是一个纯技术贴,但是我想大家在发展的过程中都或多或少会遇到这样的问题(这个问题是:很多时候你坚信是正确的事情但是却得不到上面的执行和认可,所以我们只有两个选择,1.曲线救国,2.放下不管,).希望大家支持,踊跃参与.

评论

60 楼 yin_bp 2010-04-04  

andot 写道

yin_bp 写道

rpc要做的事情就是远程方法调用，能够方便地实现rpc的方式很多，协议也很多corba，rmi，ejb等等，但是缺少一种在这些协议之上的一种通用rpc处理框架，因此我发了点时间在bbossgroups项目中写了一个通用的rpc服务调用框架，将复杂的协议封装在框架内核，用户可以选择性地配置和使用相关的协议方便地实现远程服务组件的开发、部署和调用

看了您的bbossgroups项目后，很是佩服，能够将这么多的RPC方式封装在一起，确实看得出您在这方面做了很大的努力。
这里提一点小小的建议，就是您目前所作的工作全部是都是在Java这一个平台上的，而目前可以用于纯Java平台的RPC方式并不少，好用易用的也相当的多，而且人们在选择RPC方式时，一般也不会同时选择这么多方式而只用于一种语言之间的沟通。RPC方式更多的用于不同语言不同平台之间的分布式应用。所以希望您能够更多的关注一下多语言之间的互通。比如我们现在做的PHPRPC、Hprose就是一个高性能跨平台跨语言的无差别分布式应用开发的RPC，如果您有兴趣的话，不妨看一看，更希望您看过之后也能给我们多提点好的建议。

看了一下您写的hprose文章，对hprose有了一个大概的认知，应该是一个类webservice的服务调用框架，挺不错的，呵呵，正如您所说的：bbossgroups是一个综合型的j2ee项目，也可以说是一个大杂烩，rpc框架只是里面的一个小模块，目前只适用于j2ee平台应用，因项目需要而开发的一个小组件，因此也没有考虑到多语言之间的互通，这些还需要向您学习，之所以要支持多种协议也是考虑到项目实际情况中应用部署的复杂环境，比如集群，跨网段，跨防火墙，节点路由等因素，呵呵，最后还是要谢谢您的建议。
在我的另外一个帖子里面详细介绍了一下这个rpc框架的一些基本特性，感兴趣的话可以看一下：
http://www.iteye.com/topic/631264

59 楼 andot 2010-04-03  

yin_bp 写道

rpc要做的事情就是远程方法调用，能够方便地实现rpc的方式很多，协议也很多corba，rmi，ejb等等，但是缺少一种在这些协议之上的一种通用rpc处理框架，因此我发了点时间在bbossgroups项目中写了一个通用的rpc服务调用框架，将复杂的协议封装在框架内核，用户可以选择性地配置和使用相关的协议方便地实现远程服务组件的开发、部署和调用

看了您的bbossgroups项目后，很是佩服，能够将这么多的RPC方式封装在一起，确实看得出您在这方面做了很大的努力。
这里提一点小小的建议，就是您目前所作的工作全部是都是在Java这一个平台上的，而目前可以用于纯Java平台的RPC方式并不少，好用易用的也相当的多，而且人们在选择RPC方式时，一般也不会同时选择这么多方式而只用于一种语言之间的沟通。RPC方式更多的用于不同语言不同平台之间的分布式应用。所以希望您能够更多的关注一下多语言之间的互通。比如我们现在做的PHPRPC、Hprose就是一个高性能跨平台跨语言的无差别分布式应用开发的RPC，如果您有兴趣的话，不妨看一看，更希望您看过之后也能给我们多提点好的建议。

58 楼 andot 2010-04-03  

JE帐号 写道

andot 写道

restful 接口和 WebService 接口都是用来推脱责任的最好借口。如果不希望自己承担责任，又不在乎实施项目的两方互相踢皮球浪费时间的话，使用 Restful 接口或 WebService 接口就是最佳选择。

反之，如果希望项目能够做的又快又好，后期维护又方便，实施两方都不愿意扯皮，并且都是有责任感的人的话，那就使用RPC方式。

汗死我了,我倒是觉得restful 接口和 WebService 接口比较不容易推脱责任,因为接口完全透明啊.

而且相比restful接口和 WebService 方式 导入一个第三方依赖包,还会对你的项目引入侵入式的风险.如果是个简单的包也就算了,稍微复杂点,第三方包的实现和你的项目架构不匹配怎么办?第三方包的依赖包升级或者和你的其他依赖包冲突怎么办?或者第三方包内容的某种实现机制对你的项目构成影响怎么办?

再退一步说了,实在觉得A-X都去实现浪费,那就让Z去提供一个默认的解析包好了,不是也可以做到所说的noRPC方式使用嘛.

关键是这个一个公用的模块,其提供数据的方式一定要简单且透明,越简单透明改动成本越低,适用范围越广.就我所遇到的现实场景是,有的项目是自己开发的B/S系统,有的是别人开发的B/S系统,还有自己开发的C/S系统,还有局域网内部的C/S/S(局域网内部子服务器),甚至还有基于本机上的B/S系统,面向的语言至少java,c,.net有.而且有些客户系统是很多年前的,有些客户系统除了部署的时候可以在中控系统中发布一下应用,其余时候根本无法接触系统.而且,涉及的单位也很多.而且就应用本身来讲,因客户需求不同同时还有好几个版本并存.所以希望接口部分越透明越好,大家都去关注自己项目好了,真要是出现这个项目要求那样,但是另外一个项目有要求暂时不能那样,那就难协调了.

你上面列举的这些理由本身就是用来扯皮推脱责任的借口。

你上面所谓的接口透明不过是接口简陋的一个美化说法。实际上是被接入方没有能力提供给接入方一个封装好的易调用的RPC接口，于是干脆直接以最原始的方式来提供一个简陋的接入方式，在这种方式下提供自定义的文本或XML描述形式，之后让接入方自己去实现解析。这明显的是把接口提供方该做的事情转嫁给了接口使用方。

而这种情况下，接口使用方拿到接口提供方提供的自定义文本或XML描述之后，开始以自己的理解来实现，因为每个人的理解不同，所以作出来的实现也是千差万别的，当接入方根据提供方给出的描述做好实现之后，发现不能互通的时候，接入方就会去找提供方，说提供方提供的描述不对，而提供方就会说接入方所作的实现不对，于是两方就开始了扯皮拉锯踢皮球。这样的事情，在之前很多的公司都有，如果你不知道的话，只能说明你根本没有实际接触过这样的项目。

而如果接口提供方给出的是封装好的RPC方式，那么只需要提供跟本地应用接口一样的描述即可，接入方使用RPC方式调用如果遇到问题，那只有两个问题，一个是接入方所用的语言在接口提供方给的RPC包中没有实现，这种情况下，只需要让接口提供方提供实现，或者提供实现细节来自己实现即可。让接口提供方提供实现这个完全没有扯皮问题，如果让接口提供方提供实现细节然后让接入方自己实现，所遇到的扯皮问题最多跟直接提供简陋的非RPC接口的问题一样，而不会更坏。而这种情况是少数的，因为目前很多RPC方式都提供大多数常用语言的支持，例如PHPRPC、Hprose。不支持的语言都是很偏门的，这样就保证了不用跟大多数接入者扯皮。第二个问题就如你说的引入一个第三方包有引入侵入式的风险，但这个问题即使是让接入者自己实现那简陋的Restful接入或WebService接入，也避免不了要引入用于实现这个简陋调用的第三方包，而这种依赖往往更为严重。直接引入一个RPC包让调用变得透明，实际上侵入性是最小的，而且目前许多RPC方式都没有第三方依赖，例如PHPRPC、Hprose，都是没有第三方依赖的，选择这些RPC方式可以有效的避免第三方依赖造成的侵入性问题。还有就是RPC方式是业务接口和远程调用部分是分离的，同一个业务接口在不需要修改的情况下，就可以以多种不同的RPC方式提供接入，这样，对于不同的接入者来说，还可以自由选择不同的RPC接入方式，而完全不会增加任何一方的开发工作量，这一点Restful或WebService方式也是做不到的。

所以，使用不使用RPC方式，还有一个重点要看使用的RPC方式是否可靠，如果是接口提供方自己实现的一个简陋的没有经过大量实践考验的RPC方式，这确实是有风险的。但如果接口提供方提供的是一个经过大量实际项目考验的，有保证的RPC接口方式，例如PHPRPC、Hprose。就会有效的降低接入者接入的难度，降低接口提供者接口开发的难度，降低开发成本，缩短开发时间，避免扯皮行为，提高工作效率，不管是对接入者还是对接口提供者来说，都是有利的。

57 楼 yin_bp 2010-04-03  

likeblood 写道

RPC怎么定义的？一定是使用RPC协议才算么？HTTP算不算呢？
有些东西也看api的提供者了，也得看部署方式，以及客户需要
我前些日子做个短信发送，很简单的东西而已 ，就要支持MAS机 网关 短信modem方式，这个问题也类似吧，全做了让客户或者实施人员去选吧。

另外说说非RPC的方式的缺点，我觉得这个缺点都不算什么，你说的缺点后4条都是测试上的问题，基本可以算是一个问题，分4条说显得问题扩大了，而且A-Y的测试是必须的，也不见得是为了测试Z而测试A-Y吧？如果Z有问题，也许A就已经测试出来了，B-Y可以坐等，如果Z有修改，出了问题也是Z的事情。对于问题1，我觉得RPC方式也会存在吧

让我选用哪个方式，我还真不知道怎么选了，也得看你的项目大不大吧，有没有外部系统和遗留系统，就做个宣传用的小网站的话，几个静态页面就够了吧。

我们现在做都是对外提供个ws接口，而别人对我们是什么接口，我们主宰不了

另：to robbin 能简单解释一下你在第一页的回帖么？我感觉有歧义，你说的耦合性是指一个大系统内部，还是指多个系统之间

rpc要做的事情就是远程方法调用，能够方便地实现rpc的方式很多，协议也很多corba，rmi，ejb等等，但是缺少一种在这些协议之上的一种通用rpc处理框架，因此我发了点时间在bbossgroups项目中写了一个通用的rpc服务调用框架，将复杂的协议封装在框架内核，用户可以选择性地配置和使用相关的协议方便地实现远程服务组件的开发、部署和调用

56 楼 ahuaxuan 2010-04-03  

downpour 写道

这就能解释ahuaxuan提出的问题，有许多人是这么想的，所以他们的选择会让你很不爽。这参杂了许多非技术因素在里面，所以这时候需要一个铁腕的人来做决定。我觉得技术总监就应该干这活。
。

恩,这个确实是技术总监要干的活(不在这个位置上的人通常会站在自己的立场,这个不奇怪),只是很多时候如果项目的技术方向和我的判断不符合的时候,而且我坚信我是对的时候,我会想尽各种办法来劝说他们.不能当面说的,我就曲线救国,不能曲线救国的,我就旁敲侧击,呵呵.总之就是不能让项目就这么烂掉.

55 楼 troyconder 2010-04-02  

赞同Robbin的说法

54 楼 downpour 2010-04-02  

自私一点说，A-Z那么多个项目，我可能只负责1，2个，最多也不超过5个。说实话，其他project，和我一点关系都没有，所以我只要管好我这5个project就好了。

这就能解释ahuaxuan提出的问题，有许多人是这么想的，所以他们的选择会让你很不爽。这参杂了许多非技术因素在里面，所以这时候需要一个铁腕的人来做决定。我觉得技术总监就应该干这活。

如果ahuaxuan是Z系统的开发者，我会毫不犹豫选择RPC，因为我信赖你的人品和水平。但是换了一个我完全不认识的人，或者完全不了解的人，如果我把宝全押在此人身上，我的风险系数就会一下子上去。

53 楼 cx6445 2010-04-02  

按照你定义的RPC和NORPC来分，我倾向于NORPC。

目前我就面临这个问题，我的答案是我第一阶段提供RPC，第二阶段提供NORPC。

我的考虑和技术上关系不大，我要服务好用户，我需要给用户更多的选择，我需要和其它系统竞争来抢占市场份额。

如果只是内部系统，你属于垄断地位，你提供任何接口用户都只能接受。个人认为NORPC更适合，也许技术上不是，但是能更好的划分责任，技术只是为业务服务，能相对快速分清责任的技术是好技术。


你如果提供各语言的lib，就是你一个team需要维护各语言的不同版本的lib。如果是NORPC，这个任务是分布在各个team的工作，且相应有责任人，这个开发测试工作量是可以并行的。如果集中在Z team维护，如果应用依赖上百个，我已经深受其害。

52 楼 JE帐号 2010-04-02  

andot 写道

restful 接口和 WebService 接口都是用来推脱责任的最好借口。如果不希望自己承担责任，又不在乎实施项目的两方互相踢皮球浪费时间的话，使用 Restful 接口或 WebService 接口就是最佳选择。

反之，如果希望项目能够做的又快又好，后期维护又方便，实施两方都不愿意扯皮，并且都是有责任感的人的话，那就使用RPC方式。

汗死我了,我倒是觉得restful 接口和 WebService 接口比较不容易推脱责任,因为接口完全透明啊.

而且相比restful接口和 WebService 方式 导入一个第三方依赖包,还会对你的项目引入侵入式的风险.如果是个简单的包也就算了,稍微复杂点,第三方包的实现和你的项目架构不匹配怎么办?第三方包的依赖包升级或者和你的其他依赖包冲突怎么办?或者第三方包内容的某种实现机制对你的项目构成影响怎么办?

再退一步说了,实在觉得A-X都去实现浪费,那就让Z去提供一个默认的解析包好了,不是也可以做到所说的noRPC方式使用嘛.

关键是这个一个公用的模块,其提供数据的方式一定要简单且透明,越简单透明改动成本越低,适用范围越广.就我所遇到的现实场景是,有的项目是自己开发的B/S系统,有的是别人开发的B/S系统,还有自己开发的C/S系统,还有局域网内部的C/S/S(局域网内部子服务器),甚至还有基于本机上的B/S系统,面向的语言至少java,c,.net有.而且有些客户系统是很多年前的,有些客户系统除了部署的时候可以在中控系统中发布一下应用,其余时候根本无法接触系统.而且,涉及的单位也很多.而且就应用本身来讲,因客户需求不同同时还有好几个版本并存.所以希望接口部分越透明越好,大家都去关注自己项目好了,真要是出现这个项目要求那样,但是另外一个项目有要求暂时不能那样,那就难协调了.

51 楼 oakeye 2010-04-02  

讨论到现在
我有点分不清rpc和非rpc的界限了

50 楼 ahuaxuan 2010-04-02  

dennis_zane 写道

你这里谈的非RPC，仍然是普通意义上的RPC，这里我认为你想要表达的是：是否提供一个封装client来屏蔽RPC的复杂度给用户的问题，从代码复用和编程简便的角度来说答案是肯定的啦。

是的,是这个意思,只是我的声音太小,所以只能眼睁睁的看着很多不合理的现象发生,包含之前谈到的成本之类的问题.甚至直接影响到项目的周期,互联网项目周期长短对项目影响很大

49 楼 sorphi 2010-04-02  

Z的client包开发者水平，的确是一个考虑要素。

但是如果是一个异构系统，A-Y系统采取的开发语言、架构都不一样，Z的水平再高，也没精力没必要为A-Z都开发一套client，无缝的用在A-Y的系统中。所以这个时候，提供协议/规范就是首选了。

换个角度来看，这其实是个可重用性的问题。

48 楼 dennis_zane 2010-04-02  

你这里谈的非RPC，仍然是普通意义上的RPC，这里我认为你想要表达的是：是否提供一个封装client来屏蔽RPC的复杂度给用户的问题，从代码复用和编程简便的角度来说答案是肯定的啦。

47 楼 ahuaxuan 2010-04-02  

downpour 写道

看来绝大多数人都选择RPC。如果是我，我的选择取决于，我对Z这个系统开发者的水平的评估，如果他们靠得住，并且和我关系很好，那么我选择RPC。否则，我宁可选择noRPC。

理由很简单

引用

缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.

1) jar有bug，固然是Z的开发者，但是对我的系统功能，也有重大影响，如果Z的开发者靠不住，那么这个问题会被无限放大，影响所有的A-Y。

2) 第二个问题很致命，没的说，这个工作还要借助于A-Y的部署人员和QA参与。你能确保这jar包的功能那么靠得住？还得一个一个系统去看下。

3) 不做评论了

也就是说downpour兄的选择是取决于Z的client的开发者的水平,对吧

46 楼 ahuaxuan 2010-04-02  

huzhenyu 写道

非RPC方式:
优点:
1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包
2.A-Y的代码不需要引入Z应用的Jar包.
3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任.

这三点再仔细想想，能出在非RPC的优点里吗？

显然你没有看我前面的回帖,为了节省你查找的时间我贴到下面:

ahuaxuan 写道

skzr.org 写道

我选择选择RPC：
楼主提的缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.

第一点，Z应用是提供者当然有责任解决bug了，而且多了25个使用者，可以很好的覆盖所有的功能，加速功能的进化（根据开闭原则，对外部开放接口，封闭内部的实现细节）
第二点，这个看你怎么实现了，一般rpc出bug也只是你的服务端吧！应该客户端的jar修改基本上比教少！如果接口发生变动是不是可以利用classloader来动态装载新的jar来热部署！
第三点，既然是企业内部，那还不好说，重复的劳动要不得阿！或者内部开放你的rpc源代码，有冲动的人提出修改申请来冲动下也可以的！
^ ^

非常同意你的观点.其实上面我提出的缺点我也不认为全部都是缺点,我只是站在不同的角度来预先考虑了一些其他观点.打个预防针,呵呵

45 楼 downpour 2010-04-02  

看来绝大多数人都选择RPC。如果是我，我的选择取决于，我对Z这个系统开发者的水平的评估，如果他们靠得住，并且和我关系很好，那么我选择RPC。否则，我宁可选择noRPC。

理由很简单

引用

缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.

1) jar有bug，固然是Z的开发者，但是对我的系统功能，也有重大影响，如果Z的开发者靠不住，那么这个问题会被无限放大，影响所有的A-Y。

2) 第二个问题很致命，没的说，这个工作还要借助于A-Y的部署人员和QA参与。你能确保这jar包的功能那么靠得住？还得一个一个系统去看下。

3) 不做评论了

44 楼 likeblood 2010-04-02  

RPC怎么定义的？一定是使用RPC协议才算么？HTTP算不算呢？
有些东西也看api的提供者了，也得看部署方式，以及客户需要
我前些日子做个短信发送，很简单的东西而已 ，就要支持MAS机 网关 短信modem方式，这个问题也类似吧，全做了让客户或者实施人员去选吧。

另外说说非RPC的方式的缺点，我觉得这个缺点都不算什么，你说的缺点后4条都是测试上的问题，基本可以算是一个问题，分4条说显得问题扩大了，而且A-Y的测试是必须的，也不见得是为了测试Z而测试A-Y吧？如果Z有问题，也许A就已经测试出来了，B-Y可以坐等，如果Z有修改，出了问题也是Z的事情。对于问题1，我觉得RPC方式也会存在吧

让我选用哪个方式，我还真不知道怎么选了，也得看你的项目大不大吧，有没有外部系统和遗留系统，就做个宣传用的小网站的话，几个静态页面就够了吧。

我们现在做都是对外提供个ws接口，而别人对我们是什么接口，我们主宰不了

另：to robbin 能简单解释一下你在第一页的回帖么？我感觉有歧义，你说的耦合性是指一个大系统内部，还是指多个系统之间

43 楼 yin_bp 2010-04-02  

robbin 写道

需要很高的性能，模块之间耦合程度高就用RPC

不需要很高的性能，模块之间独立性强，就用REST

感兴趣的朋友可以参考一下bbossgroups中的RPC框架，目前支持多种协议jms，jgroups，mina，webservice，restful，而且协议可扩展，提供强有力的安全管理插件（可插拔的认证、鉴权、数据包加/解密插件）目前bbossgroups发布的版本是1.0，我将在1.0rc版本中增加对jboss netty协议框架的支持，呵呵

bbossgroups rpc框架包含在子项目bboss aop框架中，下载地址：
http://sourceforge.net/projects/bboss/files/bbossgroups-1.0/bbossaop.zip/download
文档下载地址：
http://sourceforge.net/projects/bboss/files/bbossgroups-1.0/bbossgroups%20document.zip/download

42 楼 huzhenyu 2010-04-02  

非RPC方式:
优点:
1.A-Y的代码功能相同,但是实现方式不一样,一个出现bug,不会影响其他24个应用.其他24个应用不需要重启以导入新的jar包
2.A-Y的代码不需要引入Z应用的Jar包.
3.Z应用的开发者由于不需要提供client的jar包,所以不需要承担bug带来的责任.

这三点再仔细想想，能出在非RPC的优点里吗？

41 楼 andot 2010-04-01  

restful 接口和 WebService 接口都是用来推脱责任的最好借口。如果不希望自己承担责任，又不在乎实施项目的两方互相踢皮球浪费时间的话，使用 Restful 接口或 WebService 接口就是最佳选择。

反之，如果希望项目能够做的又快又好，后期维护又方便，实施两方都不愿意扯皮，并且都是有责任感的人的话，那就使用RPC方式。