当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

WebSphere 与 .Net 平台间的 Web 服务互操作性

Joel A. Farrell (joelf@us.ibm.com), Senior Technical Staff Member, IBM　

Joel 自 1981 年加入 IBM 以来一直从事高级软件项目。他现在是 Emerging Internet Technologies 组织的成员，探索的技术领域包括：面向服务的架构（Services Oriented Architecture）、医疗信息学、在线社区以及社会网络软件。Joel 还参与了软件架构模式的开发和其他简化软件解决方案创建方面的工作。他现在是 MedBiquitous Consortium（一个卫生保健标准机构）的技术指导委员会主席。最近，他一直关注如何利用 wiki 为团队和在线社区带来便利，以及如何扩展 wiki 概念本身以便支持更多类型的以内容为中心的协作。

简介： 互操作性是 Web 服务取得成功的重要因素之一，当提议新的 Web 服务规范、创建初始实现时，互操作性也显得更加重要。IBM 和 Microsoft 已创建了一组应用程序，这些应用程序演示了 Web 服务在 WebSphere 和 .NET 平台间复杂的互操作性。本文描述了那些应用程序并特别描述了如何使用新提议的 Web 服务标准和 WS-Security 发送基于 X.509v3 证书的已签名、加密的消息。现在 IBM Web Services Toolkit 版本 3.2.2. 也提供了在这些应用程序的 IBM 版本中使用的技术。

标记本文！

发布日期： 2001 年 8 月 01 日
级别： 初级
访问情况： 957 次浏览
评论：

概述

IBM 和 Microsoft 已创建了一组应用程序，这些应用程序演示了在 WebSphere 和 .NET 应用程序平台间复杂的 Web 服务的互操作性。这些应用程序在一个产品级部署案例中说明了三层交互作用。在这个产品级部署案例中，利用了对 Web 服务的基本支持和 IBM 与 Microsoft 对最新 Web 服务规范的实现。这两家公司于 2002 年 8 月 26 日至 8 月 30 日在波士顿召开的 XML Web Services One 大会上演示了这个互操作性案例。

这个案例演示的是一家对其客户提供各种服务的经纪行，其提供的服务包括买卖股票、回答帐户查询、提供关于特定证券的招股说明书以及一般管理功能。这个经纪行有两个交易台，一个是为纽约证券交易所（New York Stock Exchange）服务的，另一个是为纳斯达克交易所（Nasdaq exchange）服务的。这两个交易台执行交易。经纪行的客户经由 Web 浏览器或本机 windows 应用程序访问经纪服务。客户与经纪行之间、经纪行与两个交易台之间通过 Web 服务进行通信。所有的交易都是安全的并且都是基于请求者的经过认证的身份。

这个演示案例中的所有应用程序都是由 IBM 和 Microsoft 使用各自的工具 IBM WebSphere Studio Application Developer（WSAD）和 Microsoft Visual Studio.Net（VS.Net）开发的。VS.Net 中将会导入在 WSAD 中使用的 WSDL 文件。这些 WSDL 文件的这种导出／导入以及随后两个平台间案例的成功执行演示了这两个平台间的 Web 服务工具的互操作性。

为了说明互操作性，该案例的任意层都可以在 WebSphere 或 .Net 之一上实现。例如，当经纪行的 Web 服务在 WebSphere 上实现时，Web 客户机可以由 .Net 来提供。在这两个平台上的任何一个之上都可以实现这两个交易台。这次演示说明了执行这些角色的 WebSphere 和 .Net 的不同组合。

下图显示了这个演示案例的结构与流程。

图 1：演示案例的结构与流程

浏览器客户机与动态生成的用户界面交互。对于 WebSphere 应用程序来说，这种交互是经过经纪行节点提供的 JavaServer 页面组件完成的。在 .Net 的实现中，经纪行为 UI 提供一个活动服务器页面（Active Server Page）。当客户按下“submit”按钮时，它不是向 Web 应用程序提交回请求，而是通过简单对象访问协议（Simple Object Access Protocol，SOAP）发出一个 Web 服务调用。这意味着 UI 的提供者与 Web 服务的提供者不必非得是同一个应用程序，可以在不同的平台上实现它们。

接着，经纪行使用 SOAP 来调用由远程操作的交易台提供的 Web 服务来完成交易请求。在不使用交易台 Web 服务的情况下，经纪行也可以满足一些操作。

回页首

Web 服务技术

这个案例利用了基础 Web 服务技术和一些新设施，加强核心标准需要这些新设施。首先在 WSDL 中定义经纪行和交易台服务的接口。对这些服务的访问被定义为使用文档（与远程过程调用（Remote Procedure Call，RPC）相对）样式的交互的 SOAP over HTTP。WSDL 文档包含各方间交换的业务文档的 XML 模式定义。

Web 服务交互作用会按照由 IBM、Microsoft 和 Verisign 共同开发的 WS-Security [1]规范受到保护。结构化信息标准促进组织（Organization for the Advancement Structured Information Standards，OASIS）已成立了一个技术委员会来制定一个基于该规范的正式 Web 服务标准。最后，演示应用程序按照由 IBM 和 Microsoft 联合编写的 WS-Attachments [2]规范发送 SOAP 附件。W3C XML Protocol 工作组正在使用本规范作为 SOAP 附件标准化工作的来源之一。

应用程序的 IBM 版本在 WebSphere Application Server 上运行，并利用新的 Web 服务安全性支持。作为技术预览，在即将问世的版本 5 产品中提供了这种新的支持。在 IBM Web Services Toolkit（WSTK）版本 3.2.2 中也提供了这项技术以及对 WS-Attachments 的支持。该应用程序将在 WebSphere Application Server 4.0.2 上的 WSTK 3.2.2 上运行。

回页首

流描述

下图说明了本案例中的请求与响应 SOAP 消息流。

图 2：请求与响应 SOAP 消息流

客户机应用程序经 HTTPS 发出一个 SOAP 请求。SOAP 头包含客户机的用户名和密码。
经纪 Web 服务本身成为了请求方，并发送 SOAP 消息至交易台。SOAP 头（WS-Security）包含中介者的二进制安全令牌（即一个 X509 V3 证书）。使用这个遵循 X.509v3 证书的公共密钥对 SOAP 主体进行签名与加密。
使用遵循 X.509v3 的公共密钥对 SOAP 响应的主体进行签名与加密。SOAP 头中携带这个证书。
响应被返回到客户机。

参与全部三个应用程序层的还有另外一个流，该流程使用 WS-Attachments 规范的一个实现来获取某个公司的 PDF 格式的招股说明书。

在客户机与中介者之间流动的 SOAP 消息（流程 1 和流程 4）未经过签名，个人消息也未经过加密。这两个流程使用传输层安全性（也就是 SSL）。当在传输层上实现消息的完整性与机密性时，将把用户标识与密码作为消息头的一部分传送。这个演示应用程序反映了目前常见的环境，在这个环境中，最终用户客户机没有像 X.509v3 证书这样的二进制安全性令牌。因此我们使用用户名／密码认证，正如 WS-Security SOAP 头支持的那样。

在经纪行与交易台之间（流程 2 和流程 3），我们反映了一个更加复杂的安全性解决方案，在这个方案中认证是基于证书的，并且证书还构成了消息的数字签名与加密的基础。对于这种服务器到服务器（server-to-server）交互，在将应用程序上线之前，我们交换证书并建立密钥库。

不用向 Web 服务调用代码或 Web 服务的实现中添加代码，就可以在应用程序的 WebSphere 版本中使用二进制安全性令牌、数字签名以及消息的加密。WS-Security 的 WebSphere 实现为应用程序做了艰难的工作。通过在基于 XML 的配置文件中提供信息，应用程序部署者定义了 WebSphere 的 Web 服务的安全性需求。WebSphere Web 服务支持构建合适的 SOAP 头以及对消息进行签名与加密，对于入站消息则验证签名并对消息进行解密。

我们将检查发送方配置文件与接收方配置文件，看看应用程序开发者与部署者有哪些选项，以及我们要为这个演示案例选择哪个备用方案。

首先，这里是中介者配置文件，在这个例子中，这个配置文件充当消息发送方这一角色。

清单 1

<?xml version="1.0"?>
<clientbinding>
  <service-ref>
    <port-qname-binding>
      <SenderServiceConfig>
        <SigningParts>
          <Reference part="body"/>
        </SigningParts>
        <LoginConfig>
          <AuthMethod>BasicAuth</AuthMethod>
        </LoginConfig>
        <IDAssertion>
          <IDType>Username</IDType>
          <TrustMode confidential="yes">BasicAuth</TrustMode>
        </IDAssertion>
        <EncryptedParts>
          <Reference part="bodyContent"/>
        </EncryptedParts>
    <Timestamp>
          <Expires after="7200"/>
          <SignTimestamp flag="yes"/>
        </Timestamp>
      </SenderServiceConfig>
      <SenderBindingConfig>
        <SigningKey>
          <KeyStore type="jks"
	            path="c:/lpp/websphere/appserver/bin/client/SOAPclient.ks"
		    storepass="client"/>
          <PrivateKey alias="soaprequester" keypass="client"/>
        </SigningKey>
        <LoginBinding>
          <CallbackHandler>com.ibm.xml.soapsec.token.DebugSenderCallbackHandler
          </CallbackHandler>
       </LoginBinding>
        <EncryptionKey>
	  <KeyStore type="jks" path="c:/lpp/websphere/appserver/bin/deployment/SOAPserver.ks"
	   storepass="server"/>
          <Key alias="soapprovider"/>
        </EncryptionKey>
      </SenderBindingConfig>
    </port-qname-binding>
  </service-ref>
</clientbinding>

我们已经在这个配置文件中指定了一些调用，所有的选项都要显示这个请求者将如何按照消息层安全性与它调用的 Web 服务进行交互。具体说来，它做出如下断言：

发送方的认证凭借使用在消息头内发送的用户名和密码的“基本认证”。
将对 SOAP 消息体进行加密。
安全头内将包含一个时间戳记。
将用于签名和加密的专用密钥的位置。

其它的几个项目未指定，使用的是它们的缺省值。

将使用 RSA-SHA1 算法对 SOAP 消息签名。
使用 RSA 算法对在证书中发送的密钥进行加密。
将使用 W3C 专用规范化算法（xml-exc-c14n）创建组成 SOAP 消息的 XML 规范格式。
用三重 DES 算法对 SOAP 主体加密。

作为部分交易台的 Web 服务是 SOAP 请求消息的接收方，其安全需要必须符合发送方的定义。这里是一个交易台接收方配置文件。

清单 2

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: wssecurity-receiver.xml,v 1.1 2002/06/27 08:42:08 kent Exp $ -->
<wsbinding>
  <ws-desc-binding>
    <pc-binding>
      <ReceiverServiceConfig>
        <RequiredSignedParts>
          <Reference part="body"/>
        </RequiredSignedParts>
      </ReceiverServiceConfig>
     <ReceiverBindingConfig>
        <TrustAnchorList>
          <TrustAnchor>
            <KeyStore path="c:/lpp/websphere/appserver/bin/deployment/SOAPserver.ks"
            storepass="server" type="jks"/>
          </TrustAnchor>
	  <!--No Trust Anchor defined for this demo-->
        </TrustAnchorList>
        <DecryptionKeys>
          <KeyStore path="c:/lpp/websphere/appserver/bin/deployment/SOAPServer.ks"
          storepass="server" type="jks"/>
          <Key alias="soapprovider" keypass="server"/>
        </DecryptionKeys>
      </ReceiverBindingConfig>
    </pc-binding>
  </ws-desc-binding>
</wsbinding>

这个配置文件做出了一系列相应的断言，但是，它并未定义自己将做什么事，而是定义了这个服务的调用者要成功地调用它必须做些什么事。发送方与接收方必须在细节问题上达成一致。在这个配置文件中，我们已定义了：

必须对消息体进行签名。
必须对消息体进行加密。
请求方的公共密钥在 SOAPServer.ks 密钥库中。
我们正在使用缺省算法来对消息体进行规范、签名与加密。

本案例中的 Web 服务交互对于请求与响应来说都是安全的。对于交易台 Web 服务的调用来说，这意味着发送回中介者的响应消息也是经过数字签名与加密的。因此，发送方与接收方的角色换了过来，这种调换意味着我们还必须为交易台创建一个发送方配置文件，为中介者创建一个接收方配置文件。这些配置文件本质上与上面给出的配置文件相同。

从中介者到交易台的请求的 SOAP 消息包括一个安全头和一个用 base64 编码的已加密且已签名的 SOAP 主体。消息被从中介者发送到交易台 Web 服务。

清单 3

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
    <wsse:Security xmlns:wsse=http://schemas.xmlsoap.org/ws/2002/07/secext
     soapenv:mustUnderstand="1">
      <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
       <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <wsse:SecurityTokenReference>
            <wsse:KeyIdentifier>qXMOUFv1E3fPO7AWtNnf7oOM7cA=</wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </KeyInfo>
        <CipherData>
           <CipherValue>0xPUweJeB9iXfEg4xRZeiYTyPEbpR+03C/CPNqtZtsKxufdn2gkC/kkMUKtj
           V4PO2zq6SMty5/8be2fwqKiR4x0XN7VCTyMjleqeLWgfb3NSgqclKvXygvdFN8dKoLnydGED2
           H/bLQ/wp98MqZ3tIQBxa9MoiGEsab8NR+gD+JE=</CipherValue>
        </CipherData>
	<ReferenceList>
          <DataReference
           URI="#wssecurity_encryption_id_2292400449337222770_1028754478593"/>
          <DataReference
           URI="#wssecurity_encryption_id_4760361111283981830_1028754471093"/>
        </ReferenceList>
      </EncryptedKey>
      <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary"
       Id="wssecurity_binary_security_token_id_505593818417089891_1028754465265"
       ValueType="wsse:X509v3">MIIDnTCCAwagAwIBAgICAQAwDQYJKoZIhvc
       ... (bytes deleted for brevity)
      </wsse:BinarySecurityToken>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
           Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <Reference URI="#wssecurity_body_id_4210358434918171051_1028754465140">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>+W5M4tkctquXilLgruzph5ohxTI=</DigestValue>
          </Reference>
	<Reference URI="#tsc_1215593452612540159_1028754465125">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>sYjzCy2Nnz4otq237TSBvtaVDdU=</DigestValue>
          </Reference>
          <Reference URI="#tse_1934713756347723119_1028754465125">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
           </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>dldRAravjKkROYlXZPvN50IW6rU=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>
          SwsD2tRsLagDAiX+W+Pt5yk3gk9KKuAhnsmNGvpZNns8wkXPPpPXwZkSo48QXz6yoP
          mccHpdEq1LzBeyd88MJwkUKWHn+qDhEWGMBLDvRmZi4jyiiqmlN06ub9TD7C9MLJGd
          LJkMRyBdw/D76ihgtswscekRLcUg/PKlVNYwLtY=
        </SignatureValue>
	<KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference
  URI="#wssecurity_binary_security_token_id_505593818417089891_1028754465265"/>
          </wsse:SecurityTokenReference>
        </KeyInfo>
      </Signature>
      <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
       Id="wssecurity_encryption_id_4760361111283981830_1028754471093"
       Type="http://www.w3.org/2001/04/xmlenc#Element">
        <EncryptionMethod
         Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
         <CipherData>
           <CipherValue>ylYtct1veOCzAZJCA6+FpZb2UFfm+l01fqKq7atTajsQ
            Wo+h0OsSzT6/tvG76iTd4fOO0zekEWHxnVOKepJlbIYjNo+BTii/Bacd
            HTxBpgdyj1ls7pavTcn5sSiz4u1Nd0zv6Deo1xZ+o+mvppWSN0wlFqfz0
            TgHOgOhjFRQG1r9u6ccP1zJfYAOACWo5QCGMR9HFcrSHa1YR1Cih4Lj2gA
            QW4wBd3IfT1BTe7dajDFrebSp+B73Bq5CV5Yzbuk1</CipherValue>
         </CipherData>
      </EncryptedData>
    </wsse:Security>
    <wsu:Timestamp xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
      <wsu:Created
       wsu:Id="tsc_1215593452612540159_1028754465125">2002-08-07T21:07:45Z
      </wsu:Created>
      <wsu:Expires
       wsu:Id="tse_1934713756347723119_1028754465125">2002-08-07T23:07:45Z
      </wsu:Expires>
    </wsu:Timestamp>
  </soapenv:Header>
 <soapenv:Body
  xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
  wsu:Id="wssecurity_body_id_4210358434918171051_1028754465140">
   <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
    Id="wssecurity_encryption_id_2292400449337222770_1028754478593"
    Type="http://www.w3.org/2001/04/xmlenc#Content">
   <EncryptionMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <CipherData>
        <CipherValue>qTmV9j9oCe34PtqknztlrqQCn1M6ySVLwn+P7s+LxjaUS4Kx5
        QFfjt/i7LwYJmU1xY+YUAXMNpZWHrsa5fNnqNMu1qNtQe5kYV0AK1GcuL4QikP
        elg1SKhSF5DcdvX5evRYtZb0Lx7jvRT7+pxbvMA==</CipherValue>
      </CipherData>
</EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

在这条 SOAP 消息中，请注意我们在发送方配置文件中指定的信息是包括在 WS-Security 头中的。这个 WS-Security 头由 wsse:Security 元素组成。SOAP 消息主体是加密数据的 base64 编码表示。它包含在 EncryptedData 元素中，该元素包括密码值。

这个演示应用程序的最终用户可以请求某种股票或基金的招股说明书。在这个应用程序中，招股说明书是一个 PDF 文件，用户可以在其 web 浏览器上阅读它。中介者将招股说明书作为一个 SOAP 消息的二进制附件返回。今年六月 IBM 和 Microsoft 发布了新规范，即 WS－Attachments，在其中定义了关于如何完成这一步骤的规则与格式。它定义了一个或多个二进制文件如何能够经由直接因特网消息封装（Direct Internet Message Encapsulation ，DIME）与 SOAP 消息封装在一起 [3]。客户机发送一条常规 SOAP 消息（它未封装任何附件或 DIME）并接收一条 SOAP 消息作为响应（该消息包含二进制简要说明文件作为附件）。

回页首

总结

Web 服务取得成功的中心因素之一为它的互操作性。这些因素将用于完全不同的组织间的通信，同时还可用于集成不同的应用程序。通过构建这个案例证明了 Web 服务可用于在用不同语言编写、在具有不同基础结构的应用程序平台上运行并完成复杂的多方处理的应用程序间架起桥梁。这里我们说明了在 Web 服务标准连接 Enterprise JavaBeans 组件与 COM+ 组件的情况下，二者交互的情形。我们已经演示了核心 Web 服务标准与其它标准的可互操作的实现，这些标准在一起构成了 Web 服务的整个框架。WSDL、SOAP、WS-Security 和由 WebSphere 以及 .Net 提供的 WS-Attachments 的实现组合在一起，产生了一个多供应商和可互操作的解决方案，这一切说明了 Web 服务正在实现其作为一个强有力的集成技术的诺言。

参考资料

注解参考资料：