- 浏览: 785767 次
- 性别:
- 来自: 成都
最新评论
-
天塔上的猫:
技术孵化,任重道远啊!不过大哥能力牛逼啊,相信会有实现的一天的 ...
技术孵化的探索之路 -
SIHAIloveYAN:
谢谢分享,刚刚考上研究生,对我有很大的帮助,希望5年后再回到这 ...
我的2015 -
MUMU影子:
...
技术孵化的探索之路 -
tonyyan:
谢谢分享!
Java源码阅读的真实体会 -
cauchenlu:
http://ez.web126.cn/这个不错,完全颠覆目前 ...
一种快速开发的Java Web架构设计和实现(续)
去年,在一个大型项目(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本这方面的书籍,我觉得以下资料对我帮助最大:
四、开发过程中的的沟通问题
这应该不是一个技术问题,而是一个软件开发方法学的问题,但对整个软件开发过程影响极大。
我们面对的现实:.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有不兼容问题,如果要兼容,就会以牺牲性能和灵活性为代价。
另外,我们写项目建议书时很被动,但也没办法,因为有好几家公司竞争。对我们影响极大的几个问题:
当然,这个子系统只是我们那个庞大系统的一个部分。上面也就算我做的一点点总结吧,也是教训啊!不过,从个人角度考虑,学到的东西还是很多的。
这个子系统花去了我们将近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、项目持续一年多,人都换了几批了,工作交接很大问题。
.....
不过,说实话,项目团队,特别是进公司一、两年的员工都很努力,没有人抱怨什么,我和他(她)们一起合作,还是很开心的。
不过, 1500W竟然是这样做出来的,大概我在文章中说过,我们整个系统包括很多子系统,像CMS、OA、IM、BO等,用Web Services的这个子系统应该算一个MIS系统,只是一个模块,大概分量是30%。
其实,做项目不是我们软件工程书籍写的那么理想,譬如政治因素啊,虽然我们开始用RUP,但实际上更多的是瀑布开发,开发模式也不是我们可以决定的,和客户很大关系,他就认需求说明书,设计文档,分阶段付款,你该如何?而且,做大项目,技术有时候只是影响成败的一个因素,也许还不是最关键的。
一个成功的项目,我认为最高的评价标准是:客户的满意度。而不是你用了什么先进技术(我就要一个很简单实用的,别把流程弄得这么复杂),你节省了多少时间(再延期两个月可以,你把我们提出的一些新要求给搞定吧,ok?),等等.....
我认为,对于用到Web Services这个子系统,从 技术角度来说,当初的架构有些是合理的,只是太过复杂,再加上项目组成员整体实力比较薄弱,所以会导致后来的系统不稳定(bug多)。要说性能这块,Web Services和使用不当的Hibernate是系统慢的罪魁祸首。但这种异构分布式,除了Web Services,我还真的想不出有更简单的解决方案。也许,选择C/S本身就是不对的,只是我们一直这样固执的走了下去。
如果从过程和方法学的角度考虑,我认为需求不明确、缺乏及时与客户沟通是最大的问题。
后者我认为要摆在第一位。
此贴确实好,经验教训。
不过,能接1500W的项目应该是相当有实力的公司,怎么还会有“需求不明确、缺乏及时与客户沟通的问题”的存在啊,这些应该都是非常重要且明了的问题啊。
Websphere AppServer的评价不妨看看我以前一篇文章:[url]http://www.iteye.com/topic/74737 [/url]
我现在也在做一个cs架构的项目,跟楼主一样,前台是c#,后台是java.
前后通迅用的是http协议,格式是text/xml。
不过,我们现在是进行第三期的项目开发。像前后台通迅的速度问题,
也有得到了解决。它主要是采用压缩xml格式的方法,这样可以减轻不少
的网络io传输。
一年前,我们跟IBM一起做了一个Soa的项目就用于wesphere服务器布署,
觉得它还是挺好用的,可能是因为他们的内部文档比较多吧。
我想大家一定会问?为什么你们项目中要用到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)能承受失败带来的灾难!(不能是灭顶之灾)
(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呢?
给所有的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竟然是这样做出来的,
其实,做项目不是我们软件工程书籍写的那么理想,譬如政治因素啊,虽然我们开始用RUP,但实际上更多的是瀑布开发,开发模式也不是我们可以决定的,和客户很大关系,他就认需求说明书,设计文档,分阶段付款,你该如何?而且,做大项目,技术有时候只是影响成败的一个因素,也许还不是最关键的。
一个成功的项目,我认为最高的评价标准是:客户的满意度。而不是你用了什么先进技术(我就要一个很简单实用的,别把流程弄得这么复杂),你节省了多少时间(再延期两个月可以,你把我们提出的一些新要求给搞定吧,ok?),等等.....
如果从过程和方法学的角度考虑,我认为需求不明确、缺乏及时与客户沟通是最大的问题。
后者我认为要摆在第一位。
此贴确实好,经验教训。
不过,能接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好。
借此我也想说说接触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好。
终于一口气看完84楼的贴子了,我感受颇深。
借此我也想说说接触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好。
借此我也想说说接触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。
多线程也许用不着,即使用,也不是重点,核心需求。
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的缺点就是什么都要自己来写,来关注,多线程等问题非常麻烦。
诚心请教!
客户端用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简单多了。
还是上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生成一系列源文件供你调用。
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
还从来没有接触过这么大型复杂的项目,的确用到了很多的东西。失败的经验其实比成功的经验更宝贵,更值得珍惜一些。而且你们最后成功了的
发表评论
-
一个优秀的Java企业应用框架的设计和实现
2013-10-25 17:43 52一个优秀的Java企业应用框架的设计和实现: http:/ ... -
一个Java框架引发的思考:语言、框架、范式转换和软件生产力
2011-09-10 13:26 3651前几天,iteye上的pojo同学,发来了他四年前写的一个框架 ... -
电子商务网站,前后台是否该分离?
2011-08-21 12:44 7983做电子商务网站,一般 ... -
Java源码阅读的真实体会
2011-08-20 19:51 25631刚才在论坛不经意间,看到有关源码阅读的帖子。回想自己前几年,阅 ... -
我理解的互联网应用和企业应用开发
2011-07-12 12:01 3115前段时间,我写过一篇该主题的博客,但写完了,我觉得还是没有谈到 ... -
一个在读学生的疑问及我的回复
2011-06-24 11:39 2999我经常收到类似的站内信,然后花上半个来小时回复(我摆文字真的非 ... -
一位技术人员成长历程
2010-05-26 15:52 125144、坚持了第一个月,再坚持半年,以后的学习速度越来越快,你离 ... -
Java虚拟机技术总结(07年写的,原JavaEye精华帖)
2010-04-17 11:15 8302原文:IBM WebSphere Application Se ... -
IBM WebSphere Application Server 诊断和调优(07年写的,原JavaEye精华帖)
2009-12-19 11:07 8183这是上篇文章的续篇, ... -
JBPM源码浅析
2007-09-13 15:04 16358离职啦,工作交接中, ... -
JBPM阶段性工作总结
2007-09-12 15:20 14363快要离职了,工作交接 ... -
AIX学习总结笔记一
2007-07-03 18:07 8426公司项目用到AIX和Websphe ... -
软件开发的一点感想
2007-06-29 10:53 6014这两天,遇到工作中的两个小问题,加深了我以前对软件开发的看法。 ... -
Java线程安全系列(1)--Servlet线程安全
2007-06-16 23:19 13191刚才search的时候,竟然 ... -
从分布式系统的角度看REST
2007-05-28 20:37 3534原帖:http://www.iteye.com/t ... -
也说说项目成败、企业信息化
2007-05-19 15:25 2559这篇文章是我对nbsp同学 ... -
读HSQLDB的源码想到的
2007-05-17 10:36 9152昨天在论坛看到一篇讨 ... -
Seasar Framework介绍(一)
2007-04-21 00:18 10847近段时间,给公司一项 ... -
Struts的html:options 标签内幕
2007-04-20 18:14 7875最近用一个在日本很流 ... -
HTTP客户端POST方式中文解决方案
2007-01-17 20:26 17464这段时间,在给一个地 ...
相关推荐
项目体会WebServices开发体会和项目教训软件测试去年,在一个大型项目(1500w)中用到WebServices,现在项目进入了尾声,所以对以前的开发经历做一个总结。我想大家一定会问?为什么你们项目中要用到WebServices,因为...
全方位解析 Web Services 开发步骤
webservices的开发图片和文档适合初学者
部分web services的开发文档,也许大家有更好的,希望多多分享!
这是一本全面介绍使用JSWDP来开发Web服务的实用参考书。Java Web服务开发人员包(Java Web Services Developer Pack ,JWSDP)是一个工具和库的集合,设计这些工具和库使得用Java开发Web服务尽可能地简单。
Web Services系列教程四 利用UDDI发布和查询Web Services 基于WSE 3.0 的 Web Services开发(安全的Web Services 开发,Web Services路由,Web Services 附件) 下一代的Web Services 框架-Indigo
WebServices开发文档[收集].pdf
本书的内容涵盖了Web Services的各种关键技术、Web Services的整体体系架构和应用体系架构,以及Web Services应用的设计和开发。本书以Web Services技术系列为主线,逐一详细分析解释包括Web Services的各种核心技术...
Web Services 教程Web Services 教程Web Services 教程Web Services 教程
Spring Web Services 官网 Spring Web Services API。 Spring Web Services 开发文档。
web services web services web services web services web services
在java开发services中,会用到: 1.webservices-api.jar 2.webservices-extra.jar 3.webservices-rt.jar 4.webservices-tools.jar 5.webservices-extra-api.jar 此压缩文件里就是这五个jar文件。
Web Services与传统Web应用
webServices 开发教程,最简单的开发说明文档
Web ServicesWeb ServicesWeb Services
Web Service技术应用开发
一、Axis的安装 <br/>应用Axis开发Web Services,你需要安装如下软件: 1.JDK1.4.2或以上 2.http://ws.apache.org/axis/dist/1_1/下载得到 3.一个支持Servlet的服务器引擎,比如广为人知的Tomcat。...
delphi开发的webservices接口 目前服务端和客户端都支持
WEB SERVICES原理与研发实践