Web Service 、WS-Security、Java和.net的互通（二）
这就是刚才配置中提到的默认没有配置固定策略的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的了解，有一位朋友给我留了言，说还是要一些实际的开发者来说这些为好，架构师之类的人只会玩虚的，我想我记录着一路的历程也就是让大家知道，其实走好每一小步，才能够让系统性的架构发挥其更大的作用。
