配置完成，并保存。接下去就是要做一些wse3自动作的事情，而在wse2中需要手动修改的内容。首先把project菜单的show all files去掉，然后再选上，就会发现项目中多了一个文件：policyCache.config，选中这个文件然后右键选择Include in project，不然的话每次调试都不会被拷贝到项目执行目录下面（类似于eclipse的src目录中文件在调试中会被拷贝到bin目录下），然后将这个文件的属性Copy to Output Directory设置为Copy always,这样每次修改以后都会被同步过去。然后选择项目右击add reference，加入Microsoft.Web.Services2这个类库，修改Web References下定义的服务的Reference.cs，将服务继承类修改一下，例如我的项目中的服务自动生成以后这么继承：

　　AccountService : System.Web.Services.Protocols.SoapHttpClientProtocol

　　修改成为：

    AccountService : Microsoft.Web.Services2.WebServicesClientProtocol

　　这样定义的代理类就可以有WSSE服务增强功能了，不过注意的是如果Update了Web Reference的话，自动会从新生成新的客户端代理，那么又要手动去修改了。（发现如果再次通过wse 2 的配置工具打开app.config文件,选中General下面的框就可以类似于3自动生成了）

　　然后双击打开policyCache.config文件，做部分的修改：

　　首先在文件头部有这么一段描述：

      <defaultEndpoint>

      <defaultOperation>

        <request policy="#Sign-X.509" />

        <response policy="#Sign-X.509-1" />

        <fault policy="" />

      </defaultOperation>

　　</defaultEndpoint>

　　这就是刚才配置中提到的默认没有配置固定策略的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，因此还是加上为好）：

<security>

      <x509 storeLocation="CurrentUser" allowUrlRetrieval="true" useRFC3280="true" />

      <timeToleranceInSeconds>86400</timeToleranceInSeconds>

    </security>

　　最后在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的了解，有一位朋友给我留了言，说还是要一些实际的开发者来说这些为好，架构师之类的人只会玩虚的，我想我记录着一路的历程也就是让大家知道，其实走好每一小步，才能够让系统性的架构发挥其更大的作用。