Web Services开发体会和项目教训

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

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

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

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

比较同意slaser的观点，这种情况下确实ws不太适合，可以考虑使用ejb了，c/s客户端用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~~

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

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

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

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

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

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

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

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

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

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

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