SOA没在忽悠

我觉得PHPRPC不错，值得鼓励，但发明者把PHPRPC所实现的功能就
等同与SOA,这就太狭隘了，SOA还包括SCA,SDO,BPEL,ESB等很多方面
PHPRPC跟HESSIAN解决的只是从另外一个角度去方便了不同种语言的
相互沟通而已,仅此而已,因此PHPRPC的发展应该更专一些,不应该去做的
更大,把自己造成三投六臂那样

我从来没有说过 PHPRPC 就是 SOA。我只说，有了它利用它可以更容易的构建 SOA，你觉得我这样说有错吗？

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？

你可以认为 PHPRPC 跟 HESSIAN 解决的是同一个问题，但 PHPRPC 对脚本、移动设备、服务器和普通客户端都提供比 Hessian 要好的支持，而且对目前来说进行系统集成的最迫切的需要不也就是这个吗？至于 IBM 定义的那一套概念 PHPRPC 压根也没打算去做。我不认为连基本问题都解决不好的 IBM 的那些东西会成为拯救企业的法宝。更何况事实也证明了这一点。

虽然我也讨厌IBM

但是PHPRPC  请问

你怎么解决 ESB 中面临 消息聚合 和 分发 这种模式？

你怎么解决 消息传递的可靠性

你怎么解决 消息定制和消息的持久化？

PHPRPC 只是一种 PRC 协议，以及该协议的实现品。和楼上所说的不是一个层次的东西。

ESB 也只是一种架构模式，具体到实现，你可以根据实际情况选择底层的技术和协议。比如消息传递，使用 PHPRPC 未尝不可。

至于消息传递的可靠性等问题，都可以通过设计来解决。当然如果确实有上 ESB 的需求，选择 IBM 成熟的产品和技术未免不是省时省力的解决方案。

最后说到消息定制和持久化，和底层的传输协议完全没有关系。

四个字就可以最灵活解决以上所有问题：编程实现。

另外，SCA, SDO, BPEL, ESB 等这一堆东西都是 IBM 带头定义的，目的自然只是为了他们的产品增加一点所谓的技术含量。可是你真的见过这些东西成功部署的案例吗？就连楼上的楼上的楼上不也是曾经被 IBM 那套东西差点折腾死的人吗？


带不带头定义谁不重要，关键是已经是事实标准。还有，BPEL,ESB的成功案例太多了，单国内普元
的案例就很多，可以去相关主页查看，很多大银行大企业也有很多用了的案例，楼主你不能就凭你
的想象就说没成功的案例。


归根到底，那就是楼主的PHPRPC应该继续搞下去，但应该务实些，低调些，没必要把时间花
在SOA的整个领域，也没必要花时间去说其他技术的不好，凡是存在肯定有其道理的，
踏踏实实把产品搞成熟

IBM也未必在忽悠,只是自己还没有投入成本去学习.毕竟IBM做成产品式的东西需要考虑的行业特性比较多.

如果按照你的答案，那么什么架构呀，系统都是垃圾

因为我们都可以编程实现。。。。。


首先PHPRPC的确是个不错的东西

但是完全没必要靠打嘴仗来宣传自己东西~

不是两个层面的东西，本来就不应该拿来比较~

赞成，国内的开源界还是应该踏实点，取长补短，不自卑的同时也不要自大，那才是发展之路

phprpc的代码就是踏实这两个字的体现.

写代码就要像个男人.