论坛首页 Java企业应用论坛

一次艰难的web service对接开发

浏览 6657 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-04-19  
这次的需求是将我们的系统与一个客户系统对接,对接的方式是通过web service。今天终于基本联调成功了,由于各种主观和客观原因,过程十分艰难,在此记录一下

这次对接,双向的wsdl都是由客户系统提供的,并且没有提供测试的环境,只能我们自己搭建服务端的桩来测试

由于以前用cxf开发过web service应用,过程比较顺利,所以就考虑这回也用cxf来做

先看了一下现有的系统,发现里面已经有cxf2.0.13的jar包了。不过cxf2.0.13版本有点老,想着做个jar包升级应该也是问题不大,所以就草率决定用cxf2.5.2来开发

另外感觉用客户提供的wsdl反向生成的代码很冗余,因为了解过一些wsdl,觉得对着wsdl手写应该也能搞定,所以就没有用反向生成的方式,想自己根据wsdl手写java代码

现在看来,这2个决定都太草率了,最终都造成了返工。整个过程一波三折:

1、jar包冲突

对照着wsdl,很快就手写好了客户端和服务端的代码,包括接口和领域模型。然后配一配cxf和spring的集成,搭了一个桩,一下就弄好了

可是将这部分代码放到项目里验证,用cxf2.5.2.jar替换了cxf2.0.13,就抛异常了:java.lang.IncompatibleClassChangeError: Implementing class

2、jar包升级后,旧功能不好用

好不容易定位出来,原来是2个版本的cxf所依赖的jar包是不同的,将相关的jar包也替换之后,发布成功了。可是系统中原来的几个老功能坏了,看来cxf的版本不能随便替换

3、jar包回退后,新功能不好用

于是又把cxf2.0.13替换了回去,这次老功能是可以了,我们新开发的web service也发布起来了,可是调用的时候报异常:
java.lang.IllegalArgumentException: object is not an instance of declaring class

后来发现,是cxf2.0.13和cxf2.5.2的配置文件的写法不同,改了一下以后,调用成功了

这3个问题的解决方法,见http://kyfxbl.iteye.com/blog/1467354

4、spring注入异常

当我们往服务端web service里注入业务逻辑组件,或者往业务逻辑组件里注入web service客户端接口时,依赖注入经常发生一些奇怪的问题,经常声明的bean找不到什么的

最后通过各种方式解决了,详情见http://kyfxbl.iteye.com/blog/1470923

不过还是遗留了一些问题没想通,以后再慢慢研究

5、根据wsdl手写的代码不好使

由于客户提供的wsdl比较复杂,手写的代码联调不通,最终还是只能用wsdl2java工具来做反向生成

6、用wsdl2java生成的代码,发布失败

生成了代码以后,发布又失败了,报了以下异常
Schema name conflict in collection. Namespace:xxxxxx

又花了1天时间解决了这个问题,详情见http://kyfxbl.iteye.com/blog/1483953

7、https证书问题

经过上面几个步骤,web service是发布起来了,通过http可以调通,但是客户要求用https协议来走,而且要求是双向认证。大家对https都不熟悉,这块花了3天时间才做出来,可以说是最困难的一步

8、实际联调时,客户端校验不通过

搞定了https协议问题之后,终于能业务联调了,可是失败了,客户系统那边报
Error code 'BEA-382505'. OSB Validate action failed validation: Expected element 'requestHeader' instead of 'requestBody' here in element XXX

定位发现原来是我们发送请求的时候,只填写了RequestBody的内容,以为不重要就没有填写RequestHead的内容,所以客户那边校验没通过

把这块改完以后,就OK了

总结一下:

1、开发新功能时,尽量在现有的jar包基础上开发。因为如果用与实际环境不同的jar包,很难保证不会出现jar包冲突,或者影响现有功能的问题

2、根据wsdl手写代码不是那么容易的,对于比较复杂的wsdl,还是用wsdl2java工具会比较保险

3、用spring配置文件来配置cxf还是很容易的,但是当集成spring和cxf的时候,依赖注入要特别小心,会有一些很异常的情况。这块的原因我现在还没有搞清楚
   发表时间:2012-04-20  
jar冲突是java的一大问题
0 请登录后投票
   发表时间:2012-04-21  
我最近也在开发webservice,用的是axis1.4,试了好多技术,碰到很多和楼主样的问题,关键是和调用别人的jar包版本一直,要不问题会很多的。。。
0 请登录后投票
   发表时间:2012-04-21  
ws是挺烦人的
0 请登录后投票
   发表时间:2012-04-21  
cxf版本问题真是麻烦,有些东西都不兼容
0 请登录后投票
   发表时间:2012-04-22  
为什么不用JDK自带的JAX-WS呢......那样就不出楼主说的各种问题了.....
0 请登录后投票
   发表时间:2012-04-22  
有了json, 为什么还要开发苦逼的webservice呢? json协议简洁, 而且大多数语言支持, 没必要为了webservice而webservice啊. 难道是历史遗留产物???
0 请登录后投票
   发表时间:2012-04-23  
wujiazhao88 写道
有了json, 为什么还要开发苦逼的webservice呢? json协议简洁, 而且大多数语言支持, 没必要为了webservice而webservice啊. 难道是历史遗留产物???


正是历史遗留产物

不过你可能只领会了JSON的优点,没有意识到WS也确实有其优势。我也认识不深,只说2点。1是WSDL可以生成成各平台代码,这点json做不到。2是可以自动处理soap协议,这也是json做不到的
0 请登录后投票
   发表时间:2012-04-23  
ws是企业开发的产物,虽然效率不高,但是标准很全。现在更倾向于restful ws开发。
0 请登录后投票
   发表时间:2012-04-23  
kyfxbl 写道
wujiazhao88 写道
有了json, 为什么还要开发苦逼的webservice呢? json协议简洁, 而且大多数语言支持, 没必要为了webservice而webservice啊. 难道是历史遗留产物???


正是历史遗留产物

不过你可能只领会了JSON的优点,没有意识到WS也确实有其优势。我也认识不深,只说2点。1是WSDL可以生成成各平台代码,这点json做不到。2是可以自动处理soap协议,这也是json做不到的


不太赞同这两个优势.
1. 自动生成的代码不一定好用,比如LZ就觉得生成的代码冗余.
2. 用JSON传递数据了,也就没有soap的事了.协议本来是为了互通.json或是xml都是文本的,解决了互通问题了.

个人喜欢直接用servlet的服务器端,写一份调用的接口参数规范就好了.
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics