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

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

评论

57 楼 pufan 2007-04-28  

引用

xml编码解码确实是慢，不过这也和具体类库有关系。
我们的客户端主要是“Static stub”，不是“Dynamic invocation interface (DII)”调用方式，也不是REST方式，所以，实际的开发中并不直接和xml打交道。另外，服务端是Bottom up方式，WS只是一个部署的问题。

客户端慢点就慢摆，又不影响服务器性能。
主要看服务器端的xml编码解码能力，服务器端是java写的xml解析生成吗？

56 楼 winterwolf 2007-04-28  

可能采用xml开发框架能避免很多麻烦, 楼主的问题我都用cocoon绕开了.

ws唯一特别的地方是它按照标准格式输出xml文档. 调用WS其实很简单 用soap也可以 其实直接post就可以了. 比如rss也可以看做ws的一种.

如果系统是ws结构的 频繁的使用xml传递数据 数据库部分依然采用关系数据库 肯定要付出性能的代价. 而且有些东西保存到关系数据库是很别扭的. 最主要的是将xml映射进关系数据库 xml就死掉了 失去了xml原先的灵活和柔性. 数据被关系数据库套死 整个系统也死了.

如果是内部调用可以不用提供ws接口 但是可以保留ws接口 这样做便于测试和日后对系统进行调整. 比如将他们拆开放到其他服务器上 变集中为分布.

55 楼 zwchen 2007-04-28  

我就一起回复几个问题吧：

题目应该改成采用ibm产品和解决方案的ws开发体会和项目教训
我认为我们的WS问题，与IBM的产品关系并不大，它绝不可能造成灾难性的影响，问题更多出在需求理解和WS技术应用。
确实，SOAP只是WS实现的一种方式，但开发效率比REST高，不过性能问题严重。

xml编码解码确实是慢，不过这也和具体类库有关系。
我们的客户端主要是“Static stub”，不是“Dynamic invocation interface (DII)”调用方式，也不是REST方式，所以，实际的开发中并不直接和xml打交道。另外，服务端是Bottom up方式，WS只是一个部署的问题。

你试过SOAPUI这个工具没？
我们试过一个“.NET Webservice Studio”的工具，它可以根据wsdl文件自动生成方法列表，然后可以输入每个方法的参数，直接调用，省去了自己写单元测试的麻烦，非常方便。但每次不得不重新输入测试数据。eclipse和RAD附带的那个插件和它使用类似。不知道SOAPUI是否是类似的东西？
但我们始终没有解决这样一个问题：象我们这种异构系统，服务器端怎么做功能测试？因为你直接测试服务器端时，回避了一个异构WS兼容性问题。而客户端的C#我还不知道怎么制作脚本，就象IBM的Function Test工具或loadrunner那样录入htpp交互脚本，我对.net不太熟，不知道是否有人用过这类录入工具，专门针对.net客户端的。回归测试和持续集成时测试脚本太重要了。

在用RMI，EJB时如果你用的Hibernate返回对像时，客户端必须有hibernate包，而WS...
那是因为RMI这种协议返回的是stub proxy的序列化对象，而WS返回只是xml文本描述，具体到客户端，就看该种语言对这种xml进行mapping转换了，而wsdl这种IDL定义了这种映射关系，它是各语言之间的桥梁。WS不存在客户端import服务器端package这种强制性要求。



我现在做的项目架构也经过了很长时间的选型。你们遇到的技术上的问题很多我也遇到过 ....
我觉得WS开发，还是遵循很多分布式开发模式，譬如EJB，那本《Core J2EE patterns》很实用。
一般针对WS开发，也有一些类似的最佳实践，网上很多介绍了，我也随便总结一下，特别是我们这个项目用到的：
1、和WS-I兼容
确保最大的互操作性。譬如对于SOAP message模式Document/Literal比RPC/Literal更具有平台中立性，不过前者Axis支持不好，用.net客户端会出现问题，纳闷。

2、使用简单类型
譬如对于Java服务器端，最好用String、int这类，或是自定义的User或User数组等复杂类型(User里面也是简单类型)，但不要用List，Map等。其实我们想想，我们对外就是提供别人关心的服务，把我们平台特定的信息或冗余信息传给别人也不妥吧。

3、避免使用细粒度的调用
如果你客户端执行updateUser操作，最好该操作就是一个完整的、包括所有操作的一个facade，譬如该方法里面有更新用户基本信息，更新账号信息，更新用户组等一系列细粒度操作。试想，如果我们客户端依次调用这些细粒度操作，怎么去控制事务？而且，有严重的网络传输问题：http是短连接协议。

4、避免使用空值(nillable)
这些有夸语言兼容性问题。不是每种语言都对空值或null默认值处理友好。有人遇到这种类似问题http://weblogs.asp.net/pgreborio/archive/2003/11/14/37591.aspx http://www.mcse.ms/message908331.html

5、尽量避免在应用内部通讯时使用WS
WS主要是为了SOA做的，只是把它当成一种分布式协议太浪费了，因为复杂的XML序列化、反序列化，XML为平台中立做出的IDL描述能力都是需要付出代价的。另外，远程调用协议，消息封装格式有很多种选择啊，SOAP不是惟一选择。我们这个项目恰恰犯了这个大忌，但也无奈。

6、尽量避免对象的深层次嵌套
想想那复杂的xml解析时的性能问题就明白了，也就是说我们的对象最好是plain结构，而不是tree结构。

其它最佳实践，欢迎大家补充！

54 楼 liyangzxx 2007-04-28  

"另外一个问题是，我们的service方法，如果直接给WebWork这样的框架在服务端用的的话，是不会出问题，当提供给.net客户端用时，就会出现lazy loading的错误"
决得你们在架构上就有问题(呵呵个人见解)，首先你要明白service是什么，按照DDD的说法，他就是一个服务，我们要完全把它以下的实现隔离开，在使用时不会去考虑里面是怎样实现的，只要想他是怎么样的就可以，他应该屏蔽以下的所有信息，lazy loading 应该是你DAO层的hibernate抛出来的吧，我个人决得他应该DAO层就应该被屏蔽掉了，而且我还有一点不明，为什么webwork调用就不出现lazy loading呢，webservice调用就出现问题呢，很难理解，你这块是怎么作的，我就知道，在用RMI，EJB时如果你用的Hibernate返回对像时，客户端必须有hibernate包，是因为，hibernate返回的有些对象是自已封装过的，例如List,所以如果你不想hibernate的包出现在客户端，你可以对List进行重新copy一下，呵呵，还是那句话，个人见解可能说的不对，请指示

53 楼 leebai 2007-04-27  

楼主辛苦，大厂商可恨，我只能这么说。

上一拨是EJB的白老鼠，这一拨是WebService的白老鼠，下一拨不知道还有什么白老鼠，为什么我们总要做白老鼠？

为什么我们总是这么热衷新技术？
为什么我们总是相信大厂商？
为什么总是大厂商吃肉我们喝汤？

52 楼 yiqing1982 2007-04-27  

我也做过这样的项目，也是去年开发了一年！采用的架构方式也和楼主一样！其实我觉得更多的是我们没有把握业务，Hibernate滥用的结果！不过调试还是比较好的，特别是我们java端的！你试过SOAPUI这个工具没？

51 楼 JerryZheng 2007-04-27  

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本身就是不对的，只是我们一直这样固执的走了下去。
如果从过程和方法学的角度考虑，我认为需求不明确、缺乏及时与客户沟通是最大的问题。

后者我认为要摆在第一位。
我想看了这个帖子后，可能有人能想到更好的点子，不妨分享一下。BTW：从全局分析。

我发这个帖子，也希望对大家有点帮助，不要再犯我们的错误啊！

我对WS不熟，不过对老兄说的“我认为需求不明确、缺乏及时与客户沟通是最大的问题。”深以为然

50 楼 pufan 2007-04-27  

xml编码解码确实是慢，不过这也和具体类库有关系。
就拿最常用的dom4j+xerces来说吧，写个最简单的测试：10线程并发每线程解析1000次xml，用jprofiler看那一个字就叫红。
当然这也不是没有解决办法，楼主用的是什么？

49 楼 winterwolf 2007-04-27  

题目应该改成采用ibm产品和解决方案的ws开发体会和项目教训

因为WS的实现方式有很多种 也包括rest模式的WS.

我这里也在用WS开发系统 效率高于php asp. 具体细节以后再谈.

只想强调几点
1 数据库必需采用xmldb才有灵活性

2 开发框架必需适合直接对xml进行处理
 

48 楼 dovecat 2007-04-27  

slaser 写道

引用

不过“选择.net作为客户端通过ws和java服务器段通讯是个错误的选择”，一定程度上我还是认同。

我现在做的项目架构也经过了很长时间的选型。你们遇到的技术上的问题很多我也遇到过。
最早我们也是采用.net客户端+java服务器段通过ws来通讯，问题如下：
1.发布webservice服务的复杂性.
    java服务器段我们用xfire来发布服务，最早传递一般pojo还可以忍受，因为xfire可以自动产生WSDL,但是对于一些复杂的bean，涉及到继承和多态关系的一组对象的传输时，自动生成机制似乎就哦排不上用场了，就需要手写WSDL(可能是我xfire还没吃透).相对来说,如果是java2java的引用，我完全可以不用webservice，而用rmi,httpinvoker来替代，如果采用.net,ws的应用就是必须付出的代价。

2.java类库和.net类库的不匹配。
    我在对象中使用java.util.List等java中常见对象时，.net客户端怎么识别？需要服务器段一个encoder,客户端一个decoder，还只能传数据，不能传方法。有人说我就用ws里面的基本内型，那没问题，可是这个对于类设计造成了极大限制。所以这样使用必然出现一个dto层。dto层我个人感觉极大降低开发效率，当然还有个好处，就是可以避免hibernate的lazy loading问题。

使用java客户端直接解决以上2点问题。所以我们最后还是决定用eclipse rcp作为客户端。

lazy loading的问题这个在什么客户端里面都可能遇到，dto确实可以解决这个问题，不过dto带来了开发效率的大幅降低。目前我感觉解决的最好方案在sdo上，dto要是一个动态对象，简单点说就像一个Map一样再2端传数据，而不是pojo。

确实,你遇到的问题,我们是这样解决的.
1.集合类库不兼容,使用对象数组.
2.xfire的功能其实很强大.并没发现它不能序列化复杂类型的情况,另外,
夸网络传输,还是用简单类型比较好.
3..NET本身在反序列化对象的时候有层次限制,并且他反序列化过来会加些有BUG的代码.这点非常令人恼火.
WS本来就是用来解决不同平台间通信的方案之一.
可以用相同平台的情况下,能不用WS就不用.
HOHO~~

47 楼 slaser 2007-04-27  

引用

不过“选择.net作为客户端通过ws和java服务器段通讯是个错误的选择”，一定程度上我还是认同。

我现在做的项目架构也经过了很长时间的选型。你们遇到的技术上的问题很多我也遇到过。
最早我们也是采用.net客户端+java服务器段通过ws来通讯，问题如下：
1.发布webservice服务的复杂性.
    java服务器段我们用xfire来发布服务，最早传递一般pojo还可以忍受，因为xfire可以自动产生WSDL,但是对于一些复杂的bean，涉及到继承和多态关系的一组对象的传输时，自动生成机制似乎就哦排不上用场了，就需要手写WSDL(可能是我xfire还没吃透).相对来说,如果是java2java的引用，我完全可以不用webservice，而用rmi,httpinvoker来替代，如果采用.net,ws的应用就是必须付出的代价。

2.java类库和.net类库的不匹配。
    我在对象中使用java.util.List等java中常见对象时，.net客户端怎么识别？需要服务器段一个encoder,客户端一个decoder，还只能传数据，不能传方法。有人说我就用ws里面的基本内型，那没问题，可是这个对于类设计造成了极大限制。所以这样使用必然出现一个dto层。dto层我个人感觉极大降低开发效率，当然还有个好处，就是可以避免hibernate的lazy loading问题。

使用java客户端直接解决以上2点问题。所以我们最后还是决定用eclipse rcp作为客户端。

lazy loading的问题这个在什么客户端里面都可能遇到，dto确实可以解决这个问题，不过dto带来了开发效率的大幅降低。目前我感觉解决的最好方案在sdo上，dto要是一个动态对象，简单点说就像一个Map一样再2端传数据，而不是pojo。

46 楼 cskysnew 2007-04-27  

比较同意slaser的观点，这种情况下确实ws不太适合，可以考虑使用ejb了，c/s客户端用java实现也是个不错的选择。

45 楼 YuLimin 2007-04-26  

某些地方还不如直接就走http好了，Key-Value，全String

44 楼 zwchen 2007-04-26  

slaser 写道

关于客户端为何一定要选择.net？
我们现在就是在ecplise的RCP下面构筑应用，这样我们的通讯就走HttpInvoker就可以了，不用去搞WSDL,开发效率和运行效率都得到提升。.net客户端坐出来的效果是会好些，开发效率也稍微高点，eclipse里面ve虽然差点，总归实现好了拖拉功能，也差不到哪里去。
我觉得这个项目里面选择.net作为客户端通过ws和java服务器段通讯是个错误的选择。

你说的客户端是用Java开发吧，从技术的角度也许可行，我们的现实情况是：
1、会用Java的人非常少，就几个。
2、客户端工作量非常大，大约有18个模块，估计至少有10w行代码。
3、客户端的用户很多来自中小城市的企业主管，他们有些人连防火墙的概念都不知道，很多用户的电脑染上病毒的惟一解决办法是格式化硬盘。
4、上网部分是modem，高级的可能有ADSL。

我们是在这种条件下做选择的。我们有一个非常苛刻的原则：怎么让这些电脑盲正确、熟练使用我们的系统。遗憾的是，当初并没有太多考虑这些，导致后来的不可收拾。

不过“选择.net作为客户端通过ws和java服务器段通讯是个错误的选择”，一定程度上我还是认同。

43 楼 sorphi 2007-04-26  

ahuaxuan 写道

zwchen 写道

Web Services慢是确定的，我们测试过，另外Hibernate用得也不妥，都是eager loading。

不需要用的对象，都应该手动将其引用置空，这个我想大概是你在分布对象是hibernate的使用cglib增强关联对象造成的，这个时候应该就是手动将这个po转化为vo，特别说明，hibernate在分布式环境下会比较难用一些，很多在单jvm上能做的事在分布环境中确实是不能做的。比如说hibernate自己的集合包装类没有序列化id啊，等等，这时候就需要一个比较精通hibernate的人在团队中

“不需要用的对象，都应该手动将其引用置空”，这么做的依据或教训是什么？愿闻其详。

使用httpinvoker算是在分布式环境中么？我在这种场景下从来没手动置空过po中不需要的属性，但也还没碰到过什么莫明其妙的问题。

42 楼 slaser 2007-04-26  

关于hibernate lazy loading的问题，这个我在开发C/S结构的程序也经常遇到。简单的做法是把hibernate的po转化为dto，不过这样方法非常的浪费开发时间。可以考虑用sdo的方案来代替。

41 楼 slaser 2007-04-26  

关于客户端为何一定要选择.net？
我们现在就是在ecplise的RCP下面构筑应用，这样我们的通讯就走HttpInvoker就可以了，不用去搞WSDL,开发效率和运行效率都得到提升。.net客户端坐出来的效果是会好些，开发效率也稍微高点，eclipse里面ve虽然差点，总归实现好了拖拉功能，也差不到哪里去。
我觉得这个项目里面选择.net作为客户端通过ws和java服务器段通讯是个错误的选择。

40 楼 sunnyshuhai 2007-04-26  

是啊，项目复杂才好和客户说价钱阿

39 楼 zhangfeiyu2005 2007-04-26  

我们公司开始用hibernate时，项目组的大部分人都是第一次接触，结果用得非常不爽，到后来就干脆用jdbc了。
感觉hibernate的性能不如jdbc，原来还以为是正常的，现在看来是我们不了解hibernate啊！

38 楼 youway 2007-04-26  

理想化的开发流程在书上，大家都看到过
可是现实中的教训，才真值得我们回味

看来，在开发初期，好像很多技术是听来的，
而真正开发的时候，我们是在用痛苦来买单