cxf 调用 .net webservice
1. 问题背景
现在我们两套语言并行,其中必然会涉及到不同系统的相互访问。 .net 的会员信息是用 webservice 提供服务的。那如何对现有 .net webservice 不做任何改动的情况下,用 Java 的 cxf 来访问呢,公司的知识库里面也有这个技术专题,但是我们公司招投标的 .net webservice 涉及到一些比较特别的加密方式 和 特有的数据返回结构,比如加密信息是放在 SoapHeader 里面,返回的数据格式为 DataSet 。特别是 DataSet 这个是 .net 特有的,这个时候通用的方法就显得不能为力了,我们需要做点小小的改动。
2. cxf 拦截器
要处理这个问题,我们要需要回归到最初的 soap (Simple Object Access Protocol),可以理解为一份有规定格式的xml 文件。我们需要自己来处理发送和返回的 xml 文件。为了做这件事情,我们先来了解一下 cxf 的拦截器
上图显示了一个请求流程中的各个拦截点。我们使用其中的 WRITE、PRE_STREAM、RECEIVE
1) WRITE 拦截器 我们增加SoapHeader认证信息
2)PRE_STREAM 拦截器 ,获取发送报文,这个拦截器可以不加,我加只是为了获取发送的报文,方便我们最后对比发送报文和返回的报文。
3)Receive 拦截器,获取返回的报文,这个拦截器非常重要,这里面有我们需要的全部信息。
3. 解析SOAP 报文
这个时候我们已经完成了80% 的工作。现在我们来看一下获取的报文。重点关注一下文件的结构。
1) 发送的报文,已经添加了认证需要的SoapHeader信息。
2) 返回的报文,已经有我们需要的信息,然后当作一份 xml 文件来处理就可以了。
4. 小结
在这个问题处理当中,我们需要注意的一点就是,不同语言对这份规定格式的 xml 文件有不同的解析,会对我们的处理造成一定的困扰。这个时候我们要不忘初心,回到最原始的起点,二进制流 、字符串、xml 文件。方得始终,需要的信息就隐藏在里面。
5. 小疑问
为什么我们用的是 Write、PreStream、Receive 这三个拦截器,其他的行不行。要说明这个问题,我们就要了解每个拦截器的作用以及在流程中所处的位置。可以看一下这篇文章 https://www.cnblogs.com/luangeng/p/6602667.html,可能看完了还是有点云里雾里,那也没有关系,你可以每个拦截都去试一下,看一下获取的是什么,输出的什么,这个过程当中,可能还需要其他一些协议来帮助你理解,也许会有一些意想不到的新发现,那就边学边试吧。
6. 展望一下
经过这么一番折腾,也算解决了一些问题,那么有没有一种协议、标准、设计风格可以优雅的在不同的系统中畅行呢,或许RESTful 可以试一下, REST(Representational State Transfer )这个词是Roy Thomas Fielding在他2000年的博士论文中提出的(文末有论文中文版附件),最后引用一下 Roy Thomas Fielding 博士介绍论文写作目的来结尾,原文如下: "本文研究计算机科学两大前沿,软件和网络的交叉点。长期以来,软件研究主要关注软件设计的分类、设计方法的演化,很少客观地评估不同的设计选择对系统行为的影响。而相反地,网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现,常常忽视了一个事实,那就是改变应用程序的互动风格比改变互动协议,对整体表现有更大的影响。我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。"