Web Services开发体会和项目教训

去年，在一个大型项目(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安全问题，花了我将近一个月的时间，主要是学习和处理如下四个问题：
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比较新。后来发现这篇文章有相似的经历：[url]http://pluralsight.com/blogs/kirillg/archive/2005/04/13/7315.aspx [/url]

在处理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、项目持续一年多，人都换了几批了，工作交接很大问题。
.....

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

评论

97 楼 jack_jie 2008-04-07  

哥们给个demo look下

96 楼 liping 2007-08-27  

   新技术使用关键看自己公司的情况！有时候用了新技术可能使得你的项目更加安全 健壮 性能更好！有时候使用新技术使得你的项目进入混沌态，导致开发时间的加长，人员士气低落，最后造成不比要的损失！的确使用新技术风险是很大的！但是不可否认使用的好，带来的利益也是巨大的！所以使用新技术的时候要考虑一些事项：
（1）公司的积累
（2）牛人或牛团队（注意是谁评价的）
（3）高层的支持
（4）项目的控制能力
（5）一颗冒险的心
（6）能承受失败带来的灾难！（不能是灭顶之灾）

95 楼 yuanxiaofeng 2007-08-27  

非常好，我仔细看了，因为我们正准备上一个客户端+http+EJB的项目，原来有上ws的想法，现在已经取消了，非常感谢。

94 楼 tvjody 2007-08-17  

1500W的大项目，做起来的确很繁琐的

93 楼 vickcy 2007-08-15  

真的在这里学到很多东西.

92 楼 fool_leave 2007-08-14  

很不错的文章
给所有的pm敲响了一个警钟

我对新技术的概念是:
1:在小项目或者测试项目中使用,以兴趣为主
2:大项目中尽量使用自己熟悉的技术来降低风险

其实很多新技术只不过在旧的技术或者概念上封装了一下而已,并不一定可以提高效率,对于熟练开发人员来说是简单,可对于新手来讲会比较复杂。如果只是调不通还好说，最可怕的就是不稳定，上线后或者交付之前发现一些特殊现象很可能会害死你的。
WS和SAO我一直都没有用，包括RMI和RPC等等，这不是什么系统的关键部位（关键部位在于PM对于系统的把握和业务逻辑的深刻理解），如果可以用目前掌握的技术来做，而且效率不低的情况下，干吗非要去寻找刺激呢？

我觉得你说的整个项目不顺利，主要原因不是技术不到位，或是用了新的技术，而是PM或者更高一层的Leader没有做好业务逻辑的整理工作。
我这里做项目一直都把持一个概念，如果我是PM，那么我对业务逻辑的理解一定要到位。目前为止我们做的项目里，PM对业务的理解甚至要高于客户，尤其在细节上。这点在整个Program里是很重要的。


新技术是用来吓唬人的，如果你觉得有必要来吓唬一下你的客户的话，就用吧。


BTW：
我目前的项目里也是用Hibernate的。
上一个项目里用Hibernate处理数据库，感觉速度慢，不过没有做过多的改进。
我对Hibernate不熟悉，所以有些东西只是觉得不是很好，也不知道是不是本身就这样。
但现在这个项目，数据库处理可能会是瓶颈。我们没有专门做Hibernate的人手，大家对它都不熟悉。但据说Hibernate封装了很多东西，对于业务处理很方便。
为难ing...
该用Herbinate，还是JDBC呢？

91 楼 yushaocan 2007-08-02  

[list][img][/img][url][color=red][/color][size=24][/size]

90 楼 ljpcom 2007-08-01  

我们做的项目是delphi调用java的web service(axis)刚开始的时候传递的数据采用自定义java类，发现axis将其解析成XML时添加了很多垃圾描述符，导致传递的数据膨胀很厉害呈级数增长，严重影响效率，最后自己手工转换来传递数据，大大提高了数据传输效率，建议不要直接采用axis自带的方式传递对象。

89 楼 zhujinju 2007-07-30  

这样的文章好，很有实用价值，尤其是项目教训部分。

88 楼 xj4150 2007-06-12  

zwchen 写道

zwchen 写道

JavaVision 写道

rtdb 写道

这样的文章好，很有实用价值，尤其是项目教训部分。

不过， 1500W竟然是这样做出来的，

大概我在文章中说过，我们整个系统包括很多子系统，像CMS、OA、IM、BO等，用Web Services的这个子系统应该算一个MIS系统，只是一个模块，大概分量是30％。
其实，做项目不是我们软件工程书籍写的那么理想，譬如政治因素啊，虽然我们开始用RUP，但实际上更多的是瀑布开发，开发模式也不是我们可以决定的，和客户很大关系，他就认需求说明书，设计文档，分阶段付款，你该如何？而且，做大项目，技术有时候只是影响成败的一个因素，也许还不是最关键的。
一个成功的项目，我认为最高的评价标准是：客户的满意度。而不是你用了什么先进技术（我就要一个很简单实用的，别把流程弄得这么复杂），你节省了多少时间（再延期两个月可以，你把我们提出的一些新要求给搞定吧，ok？），等等.....

我认为，对于用到Web Services这个子系统，从 技术角度来说，当初的架构有些是合理的，只是太过复杂，再加上项目组成员整体实力比较薄弱，所以会导致后来的系统不稳定（bug多）。要说性能这块，Web Services和使用不当的Hibernate是系统慢的罪魁祸首。但这种异构分布式，除了Web Services，我还真的想不出有更简单的解决方案。也许，选择C/S本身就是不对的，只是我们一直这样固执的走了下去。
如果从过程和方法学的角度考虑，我认为需求不明确、缺乏及时与客户沟通是最大的问题。

后者我认为要摆在第一位。

此贴确实好，经验教训。
不过，能接1500W的项目应该是相当有实力的公司，怎么还会有“需求不明确、缺乏及时与客户沟通的问题”的存在啊，这些应该都是非常重要且明了的问题啊。

87 楼 aone 2007-06-07  

不会吧...这么惨.我现在才刚开始用webservice开发.

86 楼 zwchen 2007-06-07  

dy.f 写道

总结得很好啊，真是受益非浅了。
借此我也想说说接触Web服务器的一些体会：
曾经做过一个项目，客户需要用WebSphere AppServe+jdk 1.4
之前我们做个同类的项目，用的是Tomcat+jdk 1.5
所以我们就沿用了之前项目的数据结构和基层代码，开发时候用Tomcat+jdk 1.5,
开发完毕之后再移植过去。初次接触WebSphere AppServer，发现WebSphere AppServer
非常复杂，上网查过很多资料，发现资料很少，有先在Tomcat下打包成.war文件，然后移植过去就完事了。
我照做了，启动WebSphere AppServer服务器的时候后台出现一大堆错误。
我们也尝试过先把项目在Tomcat+jdk1.4下编译通过了，然后再移植到WebSphere AppServer还是不行。
后来收到项目经理一个好消息，可以在WebSphere AppServer和WebLogic之间选择一个，
在WebSphere AppServer尝试失败之后我就在WebLogic尝试了，
网上WebLogic的资料要比WebSphere AppServer多很多，而且WebLogic比WebSphere AppServer简单好用，
后来符合客户的需求我们在WebLogic9.0+jdk1.5发布了这个项目。
用了WebLogic之后发现它的连接池非常好用，要是Tomcat也像WebLogic一样搞一个连接池出来该多好啊！
Tomcat有它的有点,开发效率比WebSphere AppServe和WebLigic要高，但WebSphere AppServe和WebLigic要比
Tomcat稳定，WebLogic要比WebSphere AppServe易用，
所以，开发用Tomcat好，
发布用WebSphere AppServe和WebLigic好。

Websphere AppServer的评价不妨看看我以前一篇文章：[url]http://www.iteye.com/topic/74737 [/url]

85 楼 frankies 2007-05-23  

dy.f 写道

总结得很好啊，真是受益非浅了。
借此我也想说说接触Web服务器的一些体会：
曾经做过一个项目，客户需要用WebSphere AppServe+jdk 1.4
之前我们做个同类的项目，用的是Tomcat+jdk 1.5
所以我们就沿用了之前项目的数据结构和基层代码，开发时候用Tomcat+jdk 1.5,
开发完毕之后再移植过去。初次接触WebSphere AppServer，发现WebSphere AppServer
非常复杂，上网查过很多资料，发现资料很少，有先在Tomcat下打包成.war文件，然后移植过去就完事了。
我照做了，启动WebSphere AppServer服务器的时候后台出现一大堆错误。
我们也尝试过先把项目在Tomcat+jdk1.4下编译通过了，然后再移植到WebSphere AppServer还是不行。
后来收到项目经理一个好消息，可以在WebSphere AppServer和WebLogic之间选择一个，
在WebSphere AppServer尝试失败之后我就在WebLogic尝试了，
网上WebLogic的资料要比WebSphere AppServer多很多，而且WebLogic比WebSphere AppServer简单好用，
后来符合客户的需求我们在WebLogic9.0+jdk1.5发布了这个项目。
用了WebLogic之后发现它的连接池非常好用，要是Tomcat也像WebLogic一样搞一个连接池出来该多好啊！
Tomcat有它的有点,开发效率比WebSphere AppServe和WebLigic要高，但WebSphere AppServe和WebLigic要比
Tomcat稳定，WebLogic要比WebSphere AppServe易用，
所以，开发用Tomcat好，
发布用WebSphere AppServe和WebLigic好。

终于一口气看完８４楼的贴子了，我感受颇深。
我现在也在做一个cs架构的项目，跟楼主一样，前台是c#，后台是java.
前后通迅用的是http协议，格式是text/xml。
不过，我们现在是进行第三期的项目开发。像前后台通迅的速度问题，
也有得到了解决。它主要是采用压缩xml格式的方法，这样可以减轻不少
的网络io传输。
一年前，我们跟IBM一起做了一个Soa的项目就用于wesphere服务器布署，
觉得它还是挺好用的，可能是因为他们的内部文档比较多吧。

84 楼 dy.f 2007-05-18  

总结得很好啊，真是受益非浅了。
借此我也想说说接触Web服务器的一些体会：
曾经做过一个项目，客户需要用WebSphere AppServe+jdk 1.4
之前我们做个同类的项目，用的是Tomcat+jdk 1.5
所以我们就沿用了之前项目的数据结构和基层代码，开发时候用Tomcat+jdk 1.5,
开发完毕之后再移植过去。初次接触WebSphere AppServer，发现WebSphere AppServer
非常复杂，上网查过很多资料，发现资料很少，有先在Tomcat下打包成.war文件，然后移植过去就完事了。
我照做了，启动WebSphere AppServer服务器的时候后台出现一大堆错误。
我们也尝试过先把项目在Tomcat+jdk1.4下编译通过了，然后再移植到WebSphere AppServer还是不行。
后来收到项目经理一个好消息，可以在WebSphere AppServer和WebLogic之间选择一个，
在WebSphere AppServer尝试失败之后我就在WebLogic尝试了，
网上WebLogic的资料要比WebSphere AppServer多很多，而且WebLogic比WebSphere AppServer简单好用，
后来符合客户的需求我们在WebLogic9.0+jdk1.5发布了这个项目。
用了WebLogic之后发现它的连接池非常好用，要是Tomcat也像WebLogic一样搞一个连接池出来该多好啊！
Tomcat有它的有点,开发效率比WebSphere AppServe和WebLigic要高，但WebSphere AppServe和WebLigic要比
Tomcat稳定，WebLogic要比WebSphere AppServe易用，
所以，开发用Tomcat好，
发布用WebSphere AppServe和WebLigic好。

83 楼 zwchen 2007-05-17  

Caixiaopig: 今天下午和你聊天的体会，还是那句话，你们这种需求用Socket通讯是比较适合的。因为：
1、异构客户端，socket中立。
2、你们的Client与Server通讯的主要目的是为了交换数据，而不是所谓的对象、方法调用。
3、用CORBA，走IIOP，服务器端用EJB，客户端用C++也可以，但对于你们的需求太重量级了。而且，这种技术也主要是用在一些分布式MIS系统。
4、用消息队列也不太可取，因为你们是请求响应模型，也不是所谓的系统集成。

另外，安全用Socket下的自定义安全规范解决，可以参考如mysql C++ driver类似的SSL。
多线程也许用不着，即使用，也不是重点，核心需求。

82 楼 Caixiaopig 2007-05-17  

公司马上会上一个项目
客户端用vc开发，因为核心代码是C++写的，不可能重新用java来写客户端。而且客户端是做成sdk，为了给其他厂商的程序调用，也不可能用java来做。
服务器端用java来写，为了保证一定程度的程序安全（当然你说用linux或者unix的c++也行，那样技术上手难度比较大），平台安全和服务器安全。

现在是需要客户端发送图片到服务器端，然后服务器端验证之后返回标志位结果。这个项目对安全性要求很高。
本来想用web services做的，但是看了前面大家的讨论，觉得性能问题和兼容性问题的确比较严重。因为每次客户端会发送大约300k左右的数据过来，再加上是xml形式，而且web services里边必须用base64编码来带附件。 而且可以预见的是以后并发访问会非常的大，如果项目跟其他厂商合作的好的话。

想听听大家的意见，是用原始的socket来写，自己订通讯协议。还是继续用web services。 在我看来ws的优点就是封装了底层实现，你不用关心多线程，死锁等太多问题，而且xml是中立的。socket的缺点就是什么都要自己来写，来关注，多线程等问题非常麻烦。

诚心请教！

81 楼 jerrychen 2007-05-12  

xmlrpc 是soap的前身. 比较小巧易用,也有很多的开源客户端例子.

80 楼 ajoo 2007-05-12  

Soap based web service就是一坨屎啊一坨屎，这不是用什么xfire,Axis就能弥补的。

还是上rest吧，比soap简单多了。

79 楼 zwchen 2007-05-12  

针对上面的若干帖子，我回复一下相关作者吧：
1、lixigua: 数据仓库项目属于OLAP而不是OLTP，把OLAP，OLTP混合搞？那比我们的项目更奇怪了，我都以为我们的项目已经够奇怪了的。

我们的项目是OLAP和OLTP的混合体，对于某些客户端，只负责数据上报，最终是对这些数据进行整理，它属于OLAP；但是，对于像办事处管理人员，他们负责检查报上来的数据、管理这些填报人，这又是OLTP了。打个比方吧，全国人口普查的MIS系统。

2、steeven: 关于安全问题，不能用基于http的digest认证吗？和ws无关。

我们不用传输层(http,smtp,jms等)安全，只是用Message(SOAP包）级别的，因为这个有WS-Security标准支持，比digest更易实现。

3、我们是在这种条件下做选择的。我们有一个非常苛刻的原则：怎么让这些电脑盲正确、熟练使用我们的系统。遗憾的是，当初并没有太多考虑这些，导致后来的不可收拾。
clamp:  我是一定不会同意这种原则的……
电脑盲就是电脑盲，这不是靠技术能够解决的问题
无明：如果是选择了C/S结构，那么客户端一定要限制，包括硬件和软件环境，这个甚至要白纸黑字写死了，不然一大堆莫名其妙的问题。windows客户端调整好了，安全性并不差。

我们为客户专门配了好几百台全新的高性能PC，发往全国各地。说是电脑盲也许有点过分，但技术一定要考虑这个。像大医院内部的听诊系统，对于那些老专家，他们开始可能都不懂电脑，但还是得学会用那套医疗软件。我们组织过全国的相关人员来公司培训一周，最后还要结业考试，但回去，别人还是出问题。
我当时都怀疑，那些参加培训的都是公司领导，主要来大连旅游观光，实际的软件使用者，却是这些领导的部下。组织一次培训，几十万RMB就下去了。

4、seacat：我前段时间也接手了一个类似的项目，前台用Delphi，后台用EJB 2.x，通过web service调用。考察之后，我的结论是：需要一个直接的SQL->web service框架，中间不要再有任何java层，否则开发效率、运行效率都难以保证。

IBM的RAD里面确实有你说的这种东西：直接的SQL->web service框架：
DADX Web Service—Create a Web service from a stored procedure or SQL statement.
不过我没有试过，因为那只能应对最简单的WS，复杂一点就不实用。

5、heimu：和我去年做的一个项目很相似。
问一个.net端开发的题外话，这种直接由web service取出的数据其实对于做惯.net开发的人来说相当难用（用惯了dataset），不知道楼主有没有作.net端接口的开发

其实，在 .net下，用VSStudio提供的WS功能，使用WS和使用本地方法几乎没有区别，因为它会根据wsdl生成一系列源文件供你调用。

78 楼 不要脸2代 2007-05-08  

还从来没有接触过这么大型复杂的项目，的确用到了很多的东西。失败的经验其实比成功的经验更宝贵，更值得珍惜一些。而且你们最后成功了的