如果有以上需求，我想大家应该都比较认同这种异构分布式处理方案：客户端用C# .Net开发，通过Web Services调用服务器端Java组件。服务器组件测试一次，起容器特慢，而且客户端调用也慢。

　　我想大家一定会问?为什么你们项目中要用到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安全问题，花了我将近一个月的时间，次要是学习和处理如下四个问题：

　　XML和Web Services安全规范

　　WAS的 Web Services引擎的安全部署

　　Axis和参考的Xfire引擎的Web Services安全

　　.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安全的原理和具体配置，非常深入浅出。

　　《Se