Web Service 、WS-Security、Java和.net的互通(七)

日期: 2007-12-24 来源:TechTarget中国

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

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐