一、实现
对方约定的有七八个方法以及三个复杂类型的定义，业务逻辑处理也不算复杂，两天时间开发加调试基本搞定。当然，调试是自己在.net平台模拟调用的，但和第三方对接测试的时候，对方调用后直接报异常，调试发现方法体都没有进，以及后来的种种问题，我完全懵了！但在这次的对接中，他们属于平台方，我们只能按照他们的要求来，不可能让他们为了适应我们的平台而改代码啦，只能硬着头皮去面对一个一个的问题并干掉它们了。
二、遇到的问题和处理方法
1.第三方为Java平台调用我们提供的WEB服务,对方收到错误:服务器未能识别HTTP头SOAPAction的值。
处理过程：网络搜索相关问题，初步判定为Java夸平台调用.net Web服务的问题，试了部分解决办法，但均无法解决问题，网上搜到很多解决办法都是Java调用端重新生成WEB引用之类的云云，由于对方是平台也不可能按照我们的WEB服务重新生成WEB引用。关键是也看不到具体的SOAPAction值是啥啊，后来试着在WEB请求到达前，跟踪传入的XML请求，分别对比从对方Java平台Web服务生成的引用和我们实现的.Net平台生成的WEB引用，比较两者传入的XML请求的差别；对比之后，发现Java平台生成的Action为空,而.net的不为空，另外java平台生成的XML请求和返回分别为"方法名Request"和“方法名Response”，而.net生成的则分别为“方法名SoapIn”和“方法名SoapOut"。
解决办法：添加XML序列化属性，指定.net序列化后的属性名和SoapAction值.后此问题解决添加的属性：
[SoapDocumentMethod(Action = "",
RequestNamespace = "http://est.eshore.com/ws/front",
RequestElementName = "CreateCorpRequest",
ResponseNamespace = "http://est.eshore.com/ws/front",
ResponseElementName = "CreateCorpResponse")]
2.终于，对方的调用可以进入方法体了,可悲的是,WEB服务方法内接收到的参数全为null
处理过程：网络搜索相关问题（很多都是Java端直接更新引用解决了），找不到其它有效解决办法。经过再次抓取两个平台生成的XML请求发现，Java平台生成XML请求中在类型名称后跟有"xmlns=”"字样，而.net没有。至此基本确认问题在.net反序列化时，命名空间导致的参数反序列化失败，经过网络搜索相关问题和尝试最后在参数前面加[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]这样一个属性。
解决办法：在所有方法的参数前面以及自定义类的属性前面加上此属性，干预其XML序列化和反序列化，如原来的方法定义 public int modifyCorp(IWCorp corp,String key)要改为
public int modifyCorp([System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]IWCorp corp, [System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]String key)
3.参数接收成功了,业务处理成功了,对方确无法解析返回值,就一个int型的返回值都不能解析？
解决办法：在方法定义前加此属性
[return: System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]。
至此，再查看两个平台生成的XML请求和XML返回就一模一样了！
四、总结
两个平台的WEB服务调用问题,关键点就在两个平台对方法和类型的XML序列化/反序列化的处理方式的差异，不一样的地方需要人为的去干预。
因害怕失败而不敢放手一搏，永远不会成功
