载自http://tech.it168.com/j/2007-05-09/200705091034468.shtml
去年,在一个大型项目(1500w)中用到Web Services,现在项目进入了尾声,所以对以前的开发经历做一个总结。
我想大家一定会问?为什么你们项目中要用到Web Services,因为客户有如下需求:
1、客户要求项目用C/S架构,并且服务器端是IBM那一套:WebSphere AppServer+DB2+AIX5.3+RS/6000。
2、最终用户上报数据,因为网络原因,譬如Modem上网,可以离线操作,等填写了几十张报表后,可以一次提交。同时,在登录时,可以将服务端数据同步到本地Access或MSSQL数据库,这样提高客户端响应速度。
3、由于有些报表以后可能需要修改,或添加一些新报表,又不想重新开发,这样客户那边工作人员可以通过客户端自定义。
如果有以上需求,我想大家应该都比较认同这种异构分布式解决方案:客户端用C# .Net开发,通过Web Services调用服务器端Java组件。
其实,上面的解决方案太过于理想,最后我们不得不面对残酷的现实:三种客户端中的两种最后被迫改为B/S。
在项目中,我主要负责Web Services和服务器端组件开发中所遇到的种种问题,相当于技术支持吧,以及部分模块的开发。
以下是我们开发中遇到的实际问题,虽然最终都一一解决,但遇到了几个无法突破的瓶颈:客户端不稳定,客户端响应迟缓,后期测试和维护困难巨大。
一、异构平台的Web Services兼容性
开发过程中,我们用Axis做Web Services引擎,Tomcat做容器。因为我们只有IBM提供的RAD6.0的60天试用版。该工具超级占内存,用内置的WebSphere开发测试极其缓慢,严重影响开发效率,经过我初期试用后,基本废弃了。推荐项目组二三十开发人员用Lomboz eclipse3.12开发,基本满意。
由于Axis是一个嵌入式引擎,所以可以将其打包到最终的WebSphere AppServer(WAS)上,也就是说,我们没有用到WAS提供的Web Services引擎,这引出了后面会谈到的一个问题:Web Services安全性怎么部署?
用Axis时,Axis一直都有一个bug或是说缺陷,官方文档也详细注明,只是我们当时没有发现而走了很多弯路:用Axis发布的Web Services给.net客户端调用时,必须用RPC风格,不能用Web Services标准的跨平台风格Document,而后者是Lomboz axis插件的默认方式。也就是说,我们发布的Web Services总是莫名其妙的不好用。我们用JBuilder2007自带的Axis插件发布,竟然非常顺利。
二、Web Services开发中服务器端组件问题
我们服务器端开发,是用Spring+Hibernate,在Spring的Service层上再封装一层,也就是façade模式了,该façade直接发布为Web Services,必须经过这个转换,一是因为性能,二是因为Hibernate的复杂Model对象,在wsdl描述后,被.net客户端识别有些问题,List、Map也会有问题,总之这些对象太复杂了,我们包装成简单的VO对象。
另外一个问题是,我们的service方法,如果直接给WebWork这样的框架在服务端用的的话,是不会出问题,当提供给.net客户端用时,就会出现lazy loading的错误,因为.net客户端不能接收Proxy对象,必须将数据全部load出来,但这时Hibernate的session已经关闭。项目组很多人遇到这些问题,最后大家不约而同的全部用eager模式,导致了最后的恶果:严重的的性能问题。由于我不是leader,所以当时这个问题发现了,也没法要求别人,毕竟很大的一个团队。
切身体会:一个团队,如果不熟悉Hibernate就随便上,技术风险非常大。Hibernate带来的开发效率,是以团队成员掌握它为前提。
当然,性能问题不只是由Hibernate引起,Web Services本身的性能也非常严重:XML的序列化和反序列化耗时,XML文件的膨胀导致的网络传输,HTTP的无状态导致网络IO性能。切身体会:如果系统必须用分布式,而不是追求所谓的SOA架构,Web Services应该是下下策,因为还有很多协议和方式可以选择:IIOP、RMI、Hessian、burlap、RPC,另外,做系统集成还有Message方式。
Web Services开发中其它问题比较少,因为Web Services本身不用编程,只是部署的事情,开发工具和服务器会自动为我们做,我们只需要理解SOAP引擎的原理和使用就够了,真的遇到问题,可以通过Axis的TcpMonitor监视SOAP数据包。
开发过程中,.net客户端那边,VSStudio做得很智能,它会根据wsdl文件生成我们所要的一切,当然,wsdl文件的变化,会导致VSStudio重新生成所有的类和接口,也很耗时,并且容易出问题。
三、Web Services的安全问题
当时解决Web Services安全问题,花了我将近一个月的时间,主要是学习和处理如下四个问题:
1. XML和Web Services安全规范
2. WAS的 Web Services引擎的安全部署
3. Axis和参考的Xfire引擎的Web Services安全
4. .net客户端WSE3.0的安全以及和WAS的通讯
最后这些问题基本上都解决了,不过还是没有用上,因为在我们已经开发的几种客户端和服务器端部署上很麻烦,还要测试,另外,客户也没法验收这个啊。
当然,我们还回避了一个严肃的问题:我们的Web Services是发布在Axis引擎上,还没有移植到WAS的Web Services引擎,而发布在这个平台,必须有RAD这类开发工具支持,几乎没法手动做。WAS引擎的Web Services安全配置异常复杂:我们当时只配置了Authentication和Integration,没有做Encryption,但完全够用。我当时用Sun的NetBean开发工具发布了一下Web Serivces,也是挺好用的,不过没有配置安全。顺便说一下,Sun的web Services引擎jwsdp2.0设计有点类似于EJB容器,很不好用,移植性特差。
我们当时用Axis引擎是1.3版本,而该版并不支持标准的OASIS的WS-Security,只有到2.0版才开始,而且几乎都是手写配置文件。
WAS的Web Services安全配置,对照IBM的红皮书,不是很难,但很复杂,安全相关的xml代码都好几百行,好几个文件。配置过程中,和.net客户端通讯时遇到一个问题,怎么也不能互通,但.net和.net客户端可以互通,Java和Java客户端也可以互通,最后我通过拦截soap包,找到了解决办法: 必须手动更改http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 后的v3,IBM工具生成的是v1,这是标准不兼容引起的,因为当时RAD是04年底,而微软的WSE3.0比较新。后来发现这篇文章有相似的经历:http://pluralsight.com/blogs/kirillg/archive/2005/04/13/7315.aspx
在处理Web Services安全过程中,我通过emule和IBM网站下载了上10本这方面的书籍,我觉得以下资料对我帮助最大:
IBM的红皮书:《WebSphere Version 6 Web Services Handbook Development and Deployment.pdf》、《WebSphere Application Server V6 Security Handbook.pdf》,它专门讲述了Web Services安全的原理和具体配置,非常深入浅出。
《Securing Web Services with WS-Security》:这本书很理论化,但我认为非常好,虽然Amazon排行不高。
WSE3.0的MSDN文档。
四、开发过程中的的沟通问题
这应该不是一个技术问题,而是一个软件开发方法学的问题,但对整个软件开发过程影响极大。
我们面对的现实:.net客户端开发人员不懂服务器端Java,服务器端Java开发人员不懂.net。
除了技术壁垒外,还有业务衔接性的问题,因为我们不是纵向分模块开发,而横向开发的前提是我们服务器端开发人员很熟悉业务,知道客户端需要的接口,但实际上,业务主要由客户端推动。所以,两端的开发人员都遇到很大的沟通壁垒。
从技术的角度表达就是:客户端开发人员需要的接口,服务器端开发人员不清楚;服务器端开发人员也不知道怎么把握粒度。譬如,有个updateUser方法,但更新用户信息时,可能需要更新很多信息:用户信息、用户角色、用户所属组….。loadUser时也有同样的按需加载问题。
当然,从技术角度,开发Web Serivces有Bottom-up和Top-down两种开发模式。我们选择了前者,也是最常见的方式,也许用后者更适合我们的项目:从定义的wsdl文件开始,客户端和服务器端开发都遵循它。但问题是:我们怎么确定wsdl,也就是我们所要求的接口,因为我们自己对业务都不是很熟。
五、客户端和服务端开发测试方法
我们当时做得很笨,也最直接:等服务器端组件发布完毕后,通知客户端开发人员,然后客户端开发人员通过VSStudio提供的Web Services生成工具,根据Axis发布的wsdl文件,生成所需的.net对象,然后像本地调用一样使用。
但问题是:
wsdl随时都在变,这意味着客户端生成的组件总在变化,经常出现编译错误。
客户端开发过程中遇到的问题,一会是客户端自己,一会是服务器端组件:我要的方法包含的信息不够啊。
服务器组件测试一次,起容器特慢,而且客户端调用也慢。
我们的测试,最后走入了一个怎样的泥潭:譬如测试一张报表,都是在客户端手工填写,然后观察服务器端日志和响应。有人会问,用LoadRunner或Function Tester这类自动测试工具不就ok了吗?我都用过,它们对Web UI确实好用,后者对Swing客户端也好用,但对.net客户端,像是不太现实。
另外,Debug非常困难,因为它要求两端开发人员必须在一起密切配合。
我自己认为的解决方案,但未必真的好用:
服务器端Service方法必须写单元测试TestCase,可能代码量非常大,测试好后方发布为Web Services。
同时,服务器端提供同一套接口的Mock实现,供客户端开发测试,解决并行开发的问题。
六、其它问题
当然,上面的几点,具体到细节,我都省略了,总之问题非常非常多:技术问题、管理问题、方法和过程问题。
特别提的一点是,我们几乎开发了两套“业务层+持久化”解决方案,因为离线客户端也用了NHibernate持久化,这样导致开发测试工作量巨大,就说一点吧:两边同步是通过打包的sql语句,通过SOAP传输,但Access和DB2的sql有不兼容问题,如果要兼容,就会以牺牲性能和灵活性为代价。
另外,我们写项目建议书时很被动,但也没办法,因为有好几家公司竞争。对我们影响极大的几个问题:
2、我们没有针对WAS的开发工具RAD。但说实话,那试用版的RAD也是一个字:慢,而且安装时超级大,约4个G。而且和我们已经在用的版本控制工具VSS没法集成。
3、项目的C/S架构不是很合理,就是原来客户的B/S架构,也运行挺好的,而且用asp,跑在一个pc server上。我们一定程度上为了技术而技术。最后也达不到客户需求:性能+稳定。
4、自定义报表最后没有投入使用,只是一个半成品。本来自定义报表就很难,要是容易,一个软件外行人员,就可以把表现层到持久化轻松搞定,那一般MIS开发人员不要失业了,MDA也没那么强。很多OA平台一直在解决这个问题,也没有发现特别好用的。我们做技术调研期间试过MS的InfoPath和Adobe Designer,以及Excel Server,都不能满足需求。
当然,这个子系统只是我们那个庞大系统的一个部分。上面也就算我做的一点点总结吧,也是教训啊!不过,从个人角度考虑,学到的东西还是很多的。
这个子系统花去了我们将近200个人月,如果说那浪费的部分,估计至少是100个人月的工作量。是什么导致?从我这篇文章只能窥其一角,因为整个系统涉及CMS、OA、BI、E-commerce、GIS、IM、MIS。我自己总结一下,有以下原因:
1、项目建议书空洞,不切实际:公司也很无奈,客户也不成熟。
2、需求调研后的需求分析闭门造车:客户的合同是分阶段,我们上交需求说明书后付20%款,上交设计书后又付20%。全一个瀑布开发,虽然按RUP文档写。到半年后的实际开发时,发现很多需求都不合理。
3、整个过程都没有和客户沟通,到最后开发完毕才让客户看,那时客户也懵了:这不是我要的产品啊。改呀,改呀,熬夜啊。
4、项目团队整体技术实力薄弱,当时调来做Java开发的人员,只有少数几个以前做Java,大多数是临时学。想起那Hibernate使用,心寒啊。另外,WAS问题、AIX问题在产品环境下都出来了:系统不稳定、宕机。
5、整个开发阶段流程没有把握好,像项目规范、测试方法、日志、版本控制,这些后期都出现了,而且非常严重。就说那日志吧,最后出问题都不知道怎么查,日志一遍混乱。
6、缺乏做大项目经验,整个系统架构都比较松散,项目开始时很多都不知从何入手,也很仓促。
7、项目持续一年多,人都换了几批了,工作交接很大问题。
.....
不过,说实话,项目团队,特别是进公司一、两年的员工都很努力,没有人抱怨什么,我和他(她)们一起合作,还是很开心的。