RPC or noRPC,这是个问题

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

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

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

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

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

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

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

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


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

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

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

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

赞同Robbin的说法

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

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

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

你上面所谓的接口透明不过是接口简陋的一个美化说法。实际上是被接入方没有能力提供给接入方一个封装好的易调用的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。就会有效的降低接入者接入的难度，降低接口提供者接口开发的难度，降低开发成本，缩短开发时间，避免扯皮行为，提高工作效率，不管是对接入者还是对接口提供者来说，都是有利的。

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

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

在企业应用当中，只要提到接口，大部分人想到的就web service，而传的参数还是xml字符串，一点web service好处也没有用到。还不如使用原始socket和http get or post