Web Services开发体会和项目教训

liping 写道：
以前像是做个测试，WS的效率是最低的，譬如EJB 0.5s，WS方式可能是6s。我看网上有人比较过WS、Burlap、Hessian等协议性能，WS也是最差的。不过对于我们，开始对解决方案的依据是，哪一种协议最方便开发：有很好的类库、多语言支持。对于性能问题，以及开发过程的技术、技艺风险，都没有放在首位。

以前用过Caucho公司的Resin服务器，太棒了，是我见过的最好用的Web服务器！
Hessian协议：http://www.caucho.com/resin-3.0/protocols/index.xtp

Hessian and Burlap are compact binary and XML protocols for applications needing performance without protocol complexity. Hessian is a small binary protocol. Burlap is a matching XML protocol.
Unlike older binary protocols, Hessian is both self-describing and portable across languages。

我像是没有看到它为.net提供很好封装的类库，不过其官方规范还是蛮简单的，不知道要用它替代WS，开发效率如何？

如果有人有Hessian的实际使用经验，不妨在这分享一下。

请问你们的web service有没有考虑异步？如何做的？刚接触java，特此请教

这点我不能理解了，难道客户投了1500万中途就没有看过系统，真的这么不在乎？或者是对你们公司充分信任，认为你们是万能的，跟他们想的一样？

用ibatis是不会出现这种问题的，ibatis是半orm的，不会使用cglib来增强po，手动置空的问题我想还是试试吧，不过我想理论上是没有问题的，有可能出现我们想不到的问题，当时我们使用hibernate的时候也没有想到会出这些问题，但是问题还是解决了

感觉象在说我们公司啊，是不是大部分中小软件公司都这样？

系统构架师水平太差，这么大的系统并且开发人员都是从外面项目组调入的还用hibernate，N差！hibernate是建立在所有开发人员对该系统的领域建模都很理解并且有一定hibernate基础上的。

Rod Johnson在“without EJB”中说了很多真诚的话，其中就有“以复杂性为生的行业”这样的说法。
说句实话，大多数B/S系统用asp、php就可以轻松搞定，而大多数C/S系统用传统的VB、PB、Delphi也很容易完成。硬件要求低，开发周期短。也就是说，90%的问题都可以用这些简单的技术解决。
可是，asp、VB太easy了，easy的东西自然就不值钱了。于是国际巨头们盯住了那10%，声称必须运用新一代的高级技术，如J2EE、.NET等等，可以轻松解决所有问题。新的价值链得以产生，巨头们又开心了。而程序员们怀着极大的期望投入新一轮的技术竞争。但结果是，为了那10%的复杂问题得以较容易地解决，我们把原先那90%的简单问题变得复杂。这正是笼罩在软件业头上的一道魔咒。

本人原先一直是新技术的狂热爱好者。好似一个新技术的追星族，精疲力尽之后才明白新老技术的共通性。其实做应用系统，你是用asp还是J2EE并不重要，重要的是你对业务的领悟能力和对技术的运用能力。有些业务是该用重型武器的，你得上J2EE；有些业务却是asp这样的小刀来得顺手，不可一概而论。asp用得精纯，也可以做到相当高的稳定和性能，以至于好的扩展性和可维护性；而生手弄出的J2EE，很多时候跑都跑不起来，再大的口号也是白费。
总之用什么技术并不重要，重要的是你熟不熟，精不精。整个IT技术圈子如果不能有这样的共识，就只能活跃着一大群满口新鲜术语的菜鸟，搞出一大堆费钱费力的豆腐渣工程。而国内的IT界也只能在这种烂泥潭中挣扎。

httpClient 比web service 好使
所有客户端都通用

对前面几个帖子的回复：

web service有没有考虑异步？
考虑过，不过.net这块不是我负责，最终还是选择了默认的同步方式。但是异步并不是为了解决性能问题而设计的，不过可以提升用户体验。客户端很多需要即时交互的地方，异步不太可行。

难道客户投了1500万中途就没有看过系统？
请注意，Web Services部分是这个大项目的一个部分，约30％吧。当时客户是确认我们的需求说明书、以及后来的设计书，并且签字付款了。不过当时没有demo，所以客户可能自己也没看懂，要知道，上千页的文档两三天看完，可能吗？客户那边很多是领导呢，他们没到出乱子时，也不会太在意。真正的项目成功，不只决定于开发方，还决定于甲方，我们的甲方很不成熟，而且经费不是它们自己淘。另外，很多问题可能是客户关系处理的问题，也许比较灰色。


就一字:蒙！
说实话，我们并没有去蒙，我们这边的人也都尽力想做好，但确实对业务问题比客户理解肤浅得多，后来大约有一半的需求都有变更。当然，最根本的问题，可能是我们没有主动和客户密切沟通。但你要知道，客户那边也不怎么配合，一个北京，一个大连，沟通也不方便，我们后来还集体到那边开发。而且，他们那边恐怕没人对此项目承担直接责任。
另外，我们这个系统，相关子系统太多，20来个；半年下来才理出头绪，我开始进入项目，对业务也是一头雾水。

系统构架师水平太差
我承认，我们架构师也没有WS方面的项目经验，而且做技术架构时很仓促，leader在催，就给架构师几天时间，我当时就坐在架构师旁边。 差不多WS问题和很多技术问题都交由我去处理。
另外，架构师是一个技术职位，在我们这样的大公司，往往让位于行政leader，公司官僚气氛较浓。

httpClient 比web service 好使
解决一些简单的问题可能确实如此，我曾经负责一个SSO集成项目，客户端有php、java、ruby、ajax，当时就用它。
不过，当项目很大，很多对象调用问题，就不太好使：我们必须想办法去屏蔽这些底层通讯协议，对象序列化、反序列化的问题。另外我还碰到一个问题，就是分布式事务，补偿事务有时也不奏效，譬如网络超时。当然WS这类基于http的short connection协议本身也有这个问题。

以前用xfire的时候，遇到过hibernate lazy的问题，解决的办法就是用spring的opensessioninview，让spring的这个filter对xfire的地址也生效。

同样的，用dwr的时候也有类似的问题，也是让opensessioninview对/dwr/*生效。