hprose 跟 PHPRPC、Hessian、AMF3 等效率比较
hprose 是一个新的远程过程调用协议，你可以认为它是 PHPRPC 的商业版本，但是它跟 PHPRPC 完全不同，hprose 协议是全新设计的，比 PHPRPC 更加高效，实现也完全是全部从头开始的，比 PHPRPC 更加易用。下面的附件是它们在 java 中的序列化、反序列化效率的比较。hprose 不仅仅是序列化本身效率提高，在通讯传输上也更加高效，而且反序列化数据一步到位，无需类型转换，因此，实际应用的效率要比 PHPRPC 还要高的多。
13 楼 pan_java 2009-06-23 要用事实说话,hprose有几个人用过,再说phprpc又有几个有用过.
单凭LZ一个人说好,什么商业支持.没用的.
再说你们phprpc还没有得到大众的认可.
小公司不会花钱买你的东西,大公司看重的是稳定,后台技术团队.
hprose就开始收费,我看是不明之举.
要让大家用了都说好,那才是好.凭你搞一下效率比较就会有人去钱买.我看不可能.
LZ太心急了,不利于你们hprose的发展.
我希望LZ为了中国的开源做一定的供献.
等你hprose有点一定成绩,再考虑收费才是最重要.
14 楼 gqf2008 2009-06-23 老实说PHPRPC我们用下来真的很痛苦（PHP、JAVA、.NET），PHPRPC都还没做好又来个商业的HPROSE，是不是浮躁了点，这样下去phprpc也会很快被开发者抛弃而选择ICE 15 楼 wing5jface 2009-06-23 国内PHP开源都是这种风气，后果我就不说了 16 楼 smilerain 2009-06-23 lz大叫一声好,难道就真的好吗?自己认为好的东西,也不见得别人会认为好啊!
多少拿点数据,和成熟的东西说明一下啊. 17 楼 yuyoo4j 2009-06-23 gqf2008 写道老实说PHPRPC我们用下来真的很痛苦（PHP、JAVA、.NET），PHPRPC都还没做好又来个商业的HPROSE，是不是浮躁了点，这样下去phprpc也会很快被开发者抛弃而选择ICE
我在hessian ,xfire, ice, phprpc比较后,选择了ice.
其实 phprpc还有很多改进的地方,我原来是想让公司使用这个东西,但是领导一句用的人多吗? 我是不多,还在稳定中.
我们讨论后,我还是首先淘汰了phprpc. 不好意思, 原来是想为国内开源做些贡献的.
最后我们选择了ice.
我觉得lz还是首先让phprpc开发社区壮大起来, 即使以后你出hprose,也更值钱.
切忌短视, 往回看,很多项目在立意,成长环境一开始都是很好的, 可就是没在合适的时间内成长起来.
最后很容易被无数的同类项目淹没了. 18 楼 sword.cai 2009-06-23 hprose说得这么好，供个URL让下源码看看 19 楼 mikewang 2009-06-23 是否提供源代码先不提， 就拿andot 提供的数据来说， 在简单类型的测试中， 和 hessian 比没有优势， 复杂类型和java比 也没有优势。
我想，提供的对比数据中， java 的序列化是采用的默认方式吧？ 如果采用java.io.Externalizable 来进行序列化，我估计hprose 的优势会更小， 甚至没有。 hessian 同样也存在这个问题。（hessian也可以对特定类型采用自定义的序列化方式）
总之， 就目前的数据而言， hprose 没有优势。
另外， 任何东西都用自己适用的场景， andot 不妨提供一些 hprose 的适用场景， 并且在hprose 的适用场景下， 做一些和其他类似的产品的对比， 这样会更好一些。 20 楼 mathgl 2009-06-23 andot 写道hessian 稳定的版本仅仅只有 java 而已。其它的版本都不够稳定，而且很多都是第三方提供的，没有任何保证和支持。
hessian 的python版本不是一般的差，连个复杂点的对象都传不了。 21 楼 harry 2009-06-23 恕我直言，向来不看好这个东西 22 楼 airport 2009-06-23 harry 写道恕我直言，向来不看好这个东西
呵呵，我也有同感，实际应用环境很少采用，就好似SOA叫的响，成熟案例也很少
为了完成业务需要可选方案很多嘛，Webservice也用的挺好 23 楼 wkpub 2009-06-24 “使用 hprose 可以将工期缩短一半，人力缩减一半”，呵呵，一般项目中rpc部分占项目总工期及总人力多少：1%，10%，100% 24 楼 andot 2009-06-24 wkpub 写道“使用 hprose 可以将工期缩短一半，人力缩减一半”，呵呵，一般项目中rpc部分占项目总工期及总人力多少：1%，10%，100%
单机版 0%，网络版 100%。 25 楼 mikewang 2009-06-24 andot 写道wkpub 写道“使用 hprose 可以将工期缩短一半，人力缩减一半”，呵呵，一般项目中rpc部分占项目总工期及总人力多少：1%，10%，100%
单机版 0%，网络版 100%。
呵呵， 网络通讯确实占网络编程的大部分，hprose 只是rpc的一种而已，但目前而已， 就我们看到的资料，hprose 和其他的rpc相比确实没有什么优势。 26 楼 andot 2009-06-24 mikewang 写道andot 写道wkpub 写道“使用 hprose 可以将工期缩短一半，人力缩减一半”，呵呵，一般项目中rpc部分占项目总工期及总人力多少：1%，10%，100%
单机版 0%，网络版 100%。
呵呵， 网络通讯确实占网络编程的大部分，hprose 只是rpc的一种而已，但目前而已， 就我们看到的资料，hprose 和其他的rpc相比确实没有什么优势。
目前来说，我们还没有公开这方面的资料。我们需要等产品成熟之后才会开放出关于它的资料来。本帖那个对比，只是 for java 1.2 版本的一个序列化的小对比而已。所以看不出太多优势是正常的。总的来说，hprose 支持的语言要比目前可以选择的 rpc 技术支持的语言更多，在每种支持的语言上都会非常方便的使用，这些是其它 rpc 技术还不能提供的。 27 楼 UlsterBoy 2009-06-24 恕我直言，不认为 HPROSE 是明智之举。
与 Web Service 比，PHPRPC 在理论上劣势；与同类 RMI比，PHPRPC 也没有绝对优势，也没有固定用户群 和 相对适合的领域。
在没有打好基础的情况下，把重心转移，到最后可能两手空空。 28 楼 andot 2009-06-24 UlsterBoy 写道恕我直言，不认为 HPROSE 是明智之举。
与 Web Service 比，PHPRPC 在理论上劣势；与同类 RMI比，PHPRPC 也没有绝对优势，也没有固定用户群 和 相对适合的领域。
在没有打好基础的情况下，把重心转移，到最后可能两手空空。
与 Web Service 比，PHPRPC 在使用上更方便，更高效。
同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
用户群在2年之前如果说没有我承认，但是现在我们已经有了相当多的客户，并且已经形成了稳定的用户群。
PHPRPC 使用的领域很广泛，从桌面到web，到移动设备终端，在这些上面我们都已经有了很多成熟的案例。这几天我也正在整理这些案例，过些日子就可以在 PHPRPC 官方网站上看到这些案例啦，而且这些案例都是我们客户开发的，而不是我们自己，所以，这应该很有说服力啦。
至于 hprose，就是要从底层完善 phprpc 上固有的硬伤，将 phprpc 中现在存在的一些问题从根本上解决。因此，hprose 并不是没有基础的重建楼台，而是在 phprpc 理论基础上的发展和扩充。 29 楼 mikewang 2009-06-24 andot 写道UlsterBoy 写道恕我直言，不认为 HPROSE 是明智之举。
与 Web Service 比，PHPRPC 在理论上劣势；与同类 RMI比，PHPRPC 也没有绝对优势，也没有固定用户群 和 相对适合的领域。
在没有打好基础的情况下，把重心转移，到最后可能两手空空。
与 Web Service 比，PHPRPC 在使用上更方便，更高效。
同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
用户群在2年之前如果说没有我承认，但是现在我们已经有了相当多的客户，并且已经形成了稳定的用户群。
PHPRPC 使用的领域很广泛，从桌面到web，到移动设备终端，在这些上面我们都已经有了很多成熟的案例。这几天我也正在整理这些案例，过些日子就可以在 PHPRPC 官方网站上看到这些案例啦，而且这些案例都是我们客户开发的，而不是我们自己，所以，这应该很有说服力啦。
至于 hprose，就是要从底层完善 phprpc 上固有的硬伤，将 phprpc 中现在存在的一些问题从根本上解决。因此，hprose 并不是没有基础的重建楼台，而是在 phprpc 理论基础上的发展和扩充。
你说的这些确实是事实， 但是 webservice 的适用范围更广， 成功案例更多， 而且， 就基于http协议的衍生出来的rpc 而言 ， 低速， 不稳定 低传输，也是其特点， 这个也是所有基于http协议的rpc所共有的问题， 如果 hprose 是基于http的， 那么也有上面所说的那些问题， 所以你说比webservice 更高效， 更方便，是没有依据的！（webservice 遇到的soap 是基于文本的， 可以被压缩传输， 这个你应该知道！）
至于和rmi 相比， 这个更是没有依据， rmi 是java 原生支持的，其底层是基于sock的实现， 如果真的能比rmi更快的话， 那么我想你的适用范围也一定就没有rmi那么广泛了。 30 楼 ▄︻┳═一 2009-06-25 andot 写道UlsterBoy 写道恕我直言，不认为 HPROSE 是明智之举。
与 Web Service 比，PHPRPC 在理论上劣势；与同类 RMI比，PHPRPC 也没有绝对优势，也没有固定用户群 和 相对适合的领域。
在没有打好基础的情况下，把重心转移，到最后可能两手空空。
与 Web Service 比，PHPRPC 在使用上更方便，更高效。
同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
用户群在2年之前如果说没有我承认，但是现在我们已经有了相当多的客户，并且已经形成了稳定的用户群。
PHPRPC 使用的领域很广泛，从桌面到web，到移动设备终端，在这些上面我们都已经有了很多成熟的案例。这几天我也正在整理这些案例，过些日子就可以在 PHPRPC 官方网站上看到这些案例啦，而且这些案例都是我们客户开发的，而不是我们自己，所以，这应该很有说服力啦。
至于 hprose，就是要从底层完善 phprpc 上固有的硬伤，将 phprpc 中现在存在的一些问题从根本上解决。因此，hprose 并不是没有基础的重建楼台，而是在 phprpc 理论基础上的发展和扩充。
咋们都是做技术的，要用你这套东西的人也是做技术的人才会用，凭你这几句高效、方便、跨语言之类的甜言蜜语也是说服不了人的。
引用与 Web Service 比，PHPRPC 在使用上更方便，更高效。
方便和高效也许是真的，毕竟你不用考虑很多规范的约束。这点来说，很久很久以前，ws还不是很普及的时候，我们自己弄了一些xml格式的数据作为参数和返回值，用得很随意没有通用性，那时候我们用得很high，用起来很简单，也没有现在ws这么臃肿。如果你的这个框架也只局限这个层面的话，也就别跟ws比较了，还处于家庭作坊阶段，不具备工业标准。
引用同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
风险同上，你说的跨语言和跨平台，也是基于你自己私有协议的，没得到广泛认可，如果真的用了你的框架就等于绑死了，而且hprose不开源，风险更大
引用使用 hprose 可以将工期缩短一半，人力缩减一半
这个有点扯谈，我所经历过的SOA相关的项目，接口远程调用耽误时间的从来不是技术上的问题，更多是接口设计是否清晰易于被调用，业务分解是否合理，开发人员间的协作.....熟练的人把环境搭起来以后，已经没有任何技术难题。
引用现在我们已经有了相当多的客户，并且已经形成了稳定的用户群
成功案例还拭目以待 31 楼 linbzh 2011-12-08 为什么JSON不用java的org.json测试呢，这比json.lib快几倍啊 32 楼 myyate 2012-08-02 ▄︻┳═一 写道andot 写道UlsterBoy 写道恕我直言，不认为 HPROSE 是明智之举。
与 Web Service 比，PHPRPC 在理论上劣势；与同类 RMI比，PHPRPC 也没有绝对优势，也没有固定用户群 和 相对适合的领域。
在没有打好基础的情况下，把重心转移，到最后可能两手空空。
与 Web Service 比，PHPRPC 在使用上更方便，更高效。
同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
用户群在2年之前如果说没有我承认，但是现在我们已经有了相当多的客户，并且已经形成了稳定的用户群。
PHPRPC 使用的领域很广泛，从桌面到web，到移动设备终端，在这些上面我们都已经有了很多成熟的案例。这几天我也正在整理这些案例，过些日子就可以在 PHPRPC 官方网站上看到这些案例啦，而且这些案例都是我们客户开发的，而不是我们自己，所以，这应该很有说服力啦。
至于 hprose，就是要从底层完善 phprpc 上固有的硬伤，将 phprpc 中现在存在的一些问题从根本上解决。因此，hprose 并不是没有基础的重建楼台，而是在 phprpc 理论基础上的发展和扩充。
咋们都是做技术的，要用你这套东西的人也是做技术的人才会用，凭你这几句高效、方便、跨语言之类的甜言蜜语也是说服不了人的。
引用与 Web Service 比，PHPRPC 在使用上更方便，更高效。
方便和高效也许是真的，毕竟你不用考虑很多规范的约束。这点来说，很久很久以前，ws还不是很普及的时候，我们自己弄了一些xml格式的数据作为参数和返回值，用得很随意没有通用性，那时候我们用得很high，用起来很简单，也没有现在ws这么臃肿。如果你的这个框架也只局限这个层面的话，也就别跟ws比较了，还处于家庭作坊阶段，不具备工业标准。
引用同 RMI 比，PHPRPC 跨语言、跨平台能力更强。
风险同上，你说的跨语言和跨平台，也是基于你自己私有协议的，没得到广泛认可，如果真的用了你的框架就等于绑死了，而且hprose不开源，风险更大
引用使用 hprose 可以将工期缩短一半，人力缩减一半
这个有点扯谈，我所经历过的SOA相关的项目，接口远程调用耽误时间的从来不是技术上的问题，更多是接口设计是否清晰易于被调用，业务分解是否合理，开发人员间的协作.....熟练的人把环境搭起来以后，已经没有任何技术难题。
引用现在我们已经有了相当多的客户，并且已经形成了稳定的用户群
成功案例还拭目以待
楼上说的绝对有道理，很多东西不是靠方便、快速就能使用的。当你做一个项目，需要和不同的平台和语言的项目整合时，没有比标准更简洁的通信了，至于性能问题，更应该是人的问题，而不是框架本身问题，仅仅依靠框架本身来提高项目运行速度不可取。
