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 的了解，有一位朋友給我留了言，說還是要一些實際的開發者來說這些為好，架構師之類的人隻會玩虛的，我想我記錄着一路的曆程也就是讓大家知道，其實走好每一小步，才能夠讓系統性的架構發揮其更大的作用。