这就是刚才配置中提到的默认没有配置固定策略的URI 请求采用的策略。去查找文件中response 对应的策略配置，修改其中的内容，这儿就是修改Sign-x.509-1 的配置。
将：
< wsp:MessagePredicate wsp:Usage = "wsp:Required " Dialect = "http://schemas.xmlsoap.org/2002/12/wsse#part "> wsp:Body() wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID) wse:Timestamp()wsp:MessagePredicate >
修改成为：
< wsp:MessagePredicate wsp:Usage = "wsp:Required " Dialect = "http://schemas.xmlsoap.org/2002/12/wsse#part "> wsp:Body()wsp:MessagePredicate >
因为我们回签的时候并没有设置 address 部分，也没有 timestamp 的签名，因此都需要去掉，不然就会出错。
再将 < wssp:Integrity wsp:Usage = "wsp:Required "> 中的：
< wssp:MessageParts Dialect = "http://schemas.xmlsoap.org/2002/12/wsse#part "> wsp:Body() wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From) wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo) wsp:Header(wsa:ReplyTo) wsp:Header(wsa:To) wse:Timestamp()wssp:MessageParts >
修改成为：
< wssp:MessageParts Dialect = "http://schemas.xmlsoap.org/2002/12/wsse#part "> wsp:Body()wssp:MessageParts >
打开app.config 文件，增加如下一句（据说会有缺陷，关于超时判断的bug ，因此还是加上为好）：
?
?????
???? ? 86400
???
?
?
??? 最后在Form1.cs 添加测试代码运行测试看看，不过这里的代码如下：
??????? private void button1_Click(object sender, EventArgs e)
??????? {
??????????? AccountService service = new AccountService ();
?
??????????? accountService.ArrayOfAccountBean result = service.getUserAccountArr("test" );
?
??????? }
不在类似于WSE 3 需要配置对应的策略，因为在配置文件中已经包含了配置策略的信息。
??? 运行通过，艰难的历程告一段落，一句话，平台跨得不容易啊。
?
结束语：
??? 这次的WSSE 跨平台问题的查找真的花费了很多精力，也证明了我早先所担心的，那就是对于跨平台客户端的兼容性测试可能问题会很多，现在才是开始，当ISV 上线调试以后，可能问题会暴露的更多，其实SAAS 模式几大技术问题中，有一项就是如何让SOA 在ISV 和平台之间以及ISV 之间搭起桥梁，这个问题不仅框架结构上需要设计好，同时细节上也有多需要去实践的，细节决定成败啊，记得我在上次CSDN 的采访中谈了自己对于SCA 的了解，有一位朋友给我留了言，说还是要一些实际的开发者来说这些为好，架构师之类的人只会玩虚的，我想我记录着一路的历程也就是让大家知道，其实走好每一小步，才能够让系统性的架构发挥其更大的作用。