Web Services开发体会和项目教训

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

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

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

针对上面的若干帖子，我回复一下相关作者吧：
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生成一系列源文件供你调用。

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

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

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

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

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

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

诚心请教！

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

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

总结得很好啊，真是受益非浅了。
借此我也想说说接触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服务器布署，
觉得它还是挺好用的，可能是因为他们的内部文档比较多吧。