Web Services开发体会和项目教训

三、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本这方面的书籍，我觉得以下资料对我帮助最大：

Axis的若干文档：Reference、developers-guide、architecture-guide等，非常详细
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有不兼容问题，如果要兼容，就会以牺牲性能和灵活性为代价。

另外，我们写项目建议书时很被动，但也没办法，因为有好几家公司竞争。对我们影响极大的几个问题：

1、IBM的WAS比起WebLogic Server易用性差远了，导致部署时极其耗时。而且还有一些bug，譬如连接池资源，当时不得不和IBM工程师咨询。实际上，我们只用到强大的WAS的一个非常小的部分：Web容器。
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、项目持续一年多，人都换了几批了，工作交接很大问题。
.....

    不过，说实话，项目团队，特别是进公司一、两年的员工都很努力，没有人抱怨什么，我和他（她）们一起合作，还是很开心的。

1