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 博士介绍论文写作目的来结尾，原文如下： “本文研究计算机科学两大前沿，软件和网络的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。”
版权声明：本文为EllisQian原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。