RPC or noRPC,这是个问题

ls的意思是  我们改讨论RPC和REST好了

REST结构简单的系统用，设计上简单，功能就是普遍的东西，伸缩性也强，
RPC那就复杂的系统用

嗯，REST适合于典型的Web系统（例如门户前台、新闻网站前台、论坛、留言板等等），RPC则适合于Web应用系统、企业应用系统、网络游戏等。
上面的划分也不是绝对的，大部分时候，这两者还是可以结合使用的。例如在典型的Web系统中可以使用RPC来完成Ajax效果，前端和后端之间的通讯也可以借助RPC来完成。
适合用REST的系统不一定就是简单的，RPC也不是一定要复杂的系统才可以用。

那就混合模式，好像很多都是这么干的。。。

那本restful web services里面介绍的好多都是混合模式  非rcp就是restful
然后加上rcp  不过里面的都是ruby实现的  现在spring3的MVC液有自己的rest实现了 不错

我举个场景：
A项目中要应用到一个B项目组开发的一个组件，比如叫通用查询，可以用数据库和HTML动态组装和查询数据，来实现业务。那么A项目获取到一个JAR，和对应的部署配置方式，附加到A项目中进行开发应用。
这样的话，JAR不单B需要进行维护，而且B对JAR升级或者修改，还需要考虑A是否能够正确运行，工作量加大。这个就是强耦合了。

还有一个场景：
C项目需要和银行D之间进行扣款，那么就是采用webservice的方式。
银行D给出的接口是不能变化的，C或者其他的项目F，G等都可以进行对应功能开发。
这个是弱耦合

你的第一个场景其实也不是问题,我前面已经回帖说明过了.如果第一场景中提供的是一个平台服务,那么你升级jar包的时候完全可以做到对修改封闭,对扩展开发,而且你只要看一下apache上的开源项目,你会发现所有的开源项目都是以提供jar的方式来提供服务.所以做到后面,你会发现,真正的耦合其实并不是来自于是否是接口(就算你用restful或者自己根据协议开发,如果别人升级,难道你还指望自己不用改,绝大多数情况你都需要跟着改).而是来自于数据.数据的耦合往往上是应用集成的大忌.

第二个场景我也认为是应该是用webservice,我一直认为不同组织之间的沟通,一般上应该选择webservice.

第一个场景的问题不是RPC本身的问题，是应用接口改变的问题。这个你用Rest也一样，你Rest的接口改了，对方一样没法对接。你传输纯XML也一样，你的XML数据格式都改了，一样没法对接。所以，在开发分布式应用时，需要保证的就是对外公开的接口不要改变，这时，你不管采用WebService也好，其他RPC也好，Rest也好，传输纯XML也好，都不是问题。

第二个场景同第一个场景，跟具体采用什么调用方式无关，只跟对外接口是否变化有关。

弱耦合还是强耦合不是看是WebServic还是其他RPC技术，而是看你对外的接口是否是固定的。

这个。。弱弱地说一句 要是A-Y个应用 不全是用JAVA开发的 怎么办？还有数据的大端小端问题，包装成一个jar，不同CPU上并不能保证一致

这个用跨平台的RPC解决方案就可以啊，比如Hprose。