BlogJava-clant-文章分类-web services

Oracle 产品白皮书

BPM — Sun, 03 Dec 2006 03:13:00 GMT

http://www.oracle.com/global/cn/documentation/index.html

BPM 2006-12-03 11:13 发表评论

Web services 规范

BPM — Sun, 03 Dec 2006 02:32:00 GMT

http://www-128.ibm.com/developerworks/cn/webservices/ws-spec/index.html

BPM 2006-12-03 10:32 发表评论

多端口 Web 服务

BPM — Sat, 02 Dec 2006 05:27:00 GMT

http://www.chinaitpower.net/2006Aug/2006-08-30/213163.html

BPM 2006-12-02 13:27 发表评论

运用Web Services安全机制对SOAP消息加密

BPM — Sat, 02 Dec 2006 05:18:00 GMT

本文介绍了如何对 WebSphere Information Integrator Content Edition 的 SOAP 消息机制进行改进，以提供消息完整性和保密性。本文还解释了如何把 WebSphere IICE 现有的安全机制整合到 Web Services 安全实现中来。同时，本文也是实现 Web Services 安全机制的一次非常好的实践。

　　安全已经被公认为是电子商务市场成功与否的关键因素之一，尤其是在分布式系统中的Web Services应用。WebSphere Information Integrator Content Edition(以下简称为WebSphere IICE)作为企业信息集成领域的领导者，提供了若干基于SOAP消息的服务。

　　本文介绍了如何对WebSphere IICE SOAP消息机制进行改进，以提供消息完整性和保密性。这种机制包括使用XML 数字签名对消息进行签名来达到消息完整性，和使用XML加密对消息进行加密/解密来达到消息的保密性。本文还解释了如何把WebSphere IICE现有的安全机制整合到Web Services安全实现中来。同时，本文也是实现Web Services安全机制的一次非常好的实践。它不仅能便捷的实现安全模型、安全算法的随意扩展而且本文的实现原理能方便的移植到IBM所有需要实现Web Services安全的产品中。

　　1. 背景介绍和动机

　　WebSphere IICE作为企业信息集成的领导者，其基于J2EE框架的结构通过扩展SOAP消息接口实现了对Web Services的支持。它主要提供了三种SOAP服务，并把它们命名为WebSphere IICE Web Services。这些服务-Web Services 接口、SOAP 客户端代理和SOAP CONNECTOR代理-使得WEBSPHERE IICE能容易的部署在因特网中，并能被因特网中的其他服务访问。正是WebSphere IICE的这些特性不仅使得其各个分布式部件能异步的交互，而且还能使得WebSphere IICE各个分布式部件能无状态的交互，从而省略了会话状态管理，同时可以不必考虑实现服务的协议和服务的位置。

　　不幸的是，这种结构松散、协议开放的环境很容易被潜在的安全威胁所攻击。一个Web Services消息在到达目的地之前要在很多个中间介质中传递，这样拥有一个成熟的消息层面的安全机制就变得格外重要。

　　现在的WebSphere IICE提供的解决SOAP消息在现实电子商务网络环境中传输安全问题的技术方案还存在一些不足，譬如安全算法简单，加密结构灵活性有限等。

　　SOAP规范使得任何安全机制(数字签名、信息完整性保护、加密/解密等)能方便的应用到任何的基于Web Services的应用程序中。

　　IBM已经提供了一个完整的技术策略-WS-Security。这样整个行业就能各自实现此基于标准的结构来满足现实商业中复杂的、灵活的Web Services安全需求。通过提升Web Service核心模块的可扩展性，我们可以获得基于诸如SOAP、WSDL、XML数字签名、XML加密/解密和SSL/TLS等核心技术的解决方案。这样使得Web Services的提供者和需求者能根据各自的应用程序安全需求来开发解决方案。这些解决方案和标准使得我们能够方便的把Web Services安全解决方案和WebSphere IICE Web Services部件整合在一起。

　　2. 实现原理

　　2.1 WebSphere IICE Web Servives概述

　　现在WebSphere IICE提供两个层次的Web Services部件，一个是SOAP客户端代理、SOAP connector代理和Web Services API，我们把这部分叫做WebSphere IICE Web Services客户端:另外一部分是作为WebSphere IICE Web模块发布的服务器端SOAP实现。此Web模块把IICE接口作为Web Services发布出去并把这些接口和其他模块整合在一起。从技术角度来讲，WebSphere IICE Web Services部件利用了Apache Axis工具包。我们可以简单的把WebSphere IICE的两部分理解为Axis客户端和Axis服务器端。下面讲述了WebSphere IICE Web Services部件的细节。

　　SOAP客户代理层(如图1部件1)应用SOAP作为WebSphere IICE标准API和ACCESSSERVICES部件交互协议。

　　SOAP connector代理层(如图1部件2)应用SOAP作为ACCESSSERVICE EJB组件和已经部署的CONNECTOR EJB部件的交互协议。此实现机制和SOAP客户代理层的实现机制非常相象。

图1:WebSphere IICE Web Services部件

　　Web Services调用接口(如图1部件3)通过SOAP接口提供了WebSphere IICE整合接口的绝大部分内容。它包括一个WSDL文件，此文件定义了调用接口并且提供了一种语言无关的方式来访问 Internet 中非结构化的数据。
2.2 WebSphere IICE密文登录原理

　　WebSphere IICE加密机制是对BLOWFISH算法的一种实现。一旦安装成功，WebSphere IICE会使用此算法产生一个密钥文件同时要保证此文件在客户端和CONNECTOR端的CLASSPATH中。如下是应用BLOWFISH进行加/解密的一个过程示例。

　　列表1:应用blowfish进行加、解密过程

客户端的加密过程：

   //Create and encrypt an AuthBundle.
   AuthBundle aB = new AuthBundle(user, password);
   try {
      //Encrypt the auth bundle
      (new BlowfishSealer()).seal(aB);
   } catch(KeyNotFoundException knfe) {
      ...
   }

服务器端的解密过程：
...use the sealed bundle to logon to a chosen repository.
      ..
      // Unseal the auth bundle if sealed.
      if(authBundle.isSealed()) {
         // Instantiate an unsealer proxy.
         UnsealerProxy uP = new UnsealerProxy();
         try {
            // Attempt to unseal the bundle.
            // The UnsealerProxy will delegate unsealing
// to a new instance of "my.magic.Unsealer"
            uP.unseal(authBundle);
         } catch(UnsealerNotFoundException unfe) {
            throw new LogonException("Unable … unsealer.", unfe);
         } catch(KeyNotFoundException knfe) {
            throw new LogonException("Unable ….", knfe);
         } catch(InvalidKeyClassException ikce) {
            throw new LogonException("Invalid decryption...", ikce);
         } catch(EncryptionException ee) {
            throw new LogonException("An error ….", ee);
         }
      }
      ...

　　2.3 WebSphere IICE Web Services SOAP消息安全概述

　　由于WebSphere IICE使用Axis作为SOAP引擎，我们首先需要了解一下Axis的机制。可以说，Axis的任务就是处理消息。当Axis的核心处理逻辑启动时，一系列的句柄会被顺序的调用。调用的顺序是由两个因素来决定的--部署文件和此引擎为客户端还是服务器端。

　　WebSphere IICE Web Services会被一系列的客户端和服务器端Axis/JAX-RPC句柄处理。为了能使此安全解决方案正常工作，这些句柄必须被安装并且要保证安装顺序正确。本文提供了两套句柄分别实现消息的加密/解密和消息完整性验证功能，同时要保证这四个句柄被正确的安装在客户端和服务器端的WSDD配置文件中，这样才能保证对于每一个从客户端发出的消息都被客户端的证书加密和签名，同时才能保证服务器端接受到的每一个消息都是被验证的而且每一个消息都经过了解密。这样我们就实现了SOAP消息的完整性和机密性。

　　同时，用户可以选择是否使用此安全机制。如果用户倾向于非安全机制，他所需要做的就是注释客户端和服务器端的WSDD配置文件。

2.4 WEBSPHERE IICE WEB SERVICE SOAP消息安全实现细节

　　A. 配置

　　WebSphere IICE Web Services安全机制的配置工作是由客户端和服务器端两部分组成的。就如下面的配置文件实例说描述的一样，SOAP消息会在它被发送到目标服务器之前分别被不同的句柄签名和加密。相对应的，它也会在服务器端被验证和解密。

　　列表2:AXIS客户端配置文件示例

         type="java:com.venetica.vbr.webservices.handler.X509SignHandler"/>
         type="java:com.venetica.vbr.webservices.handler.EncryptHandler"/>


    type="java:com.venetica.vbr.webservices.handler.X509SignHandler"/>
    type="java:com.venetica.vbr.webservices.handler.DecryptHandler"/>

　　服务器端的配置文件和客户端的配置文件非常相像。

　　B. 签名和加密/解密过程:

　　SOAP消息的签名和加密/解密过程如图2所示:

图2:SOAP消息的签名和加密/解密过程

　　列表3: XML签名示例代码

public Message signSOAPEnvelope(SOAPEnvelope unsignedEnvelope) throws Exception
   { // WSSignEnvelope signs a SOAP envelope according to the
      // WS Specification (X509 profile) and adds the signature data
      // to the envelope.
      WSSignEnvelope signer = new WSSignEnvelope();
      String alias = "username";
      String password = "password";
      signer.setUserInfo(alias, password);
      Document doc = unsignedEnvelope.getAsDocument();
      Document signedDoc = signer.build(doc, crypto);
      // Convert the signed document into a SOAP message.
      Message signedSOAPMsg =         (org.apache.axis.Message)AxisUtil.toSOAPMessage(signedDoc);
      return signedSOAPMsg;
   }

　　列表3显示了XML签名的过程:首先得到SOAP信封，接下来是获得用户证书信息、产生签名对象，然后是用此签名对象对信封进行签名，最后是从被签名的信封中产生新的SOAP消息。

　　列表4:XML加密示例代码

public Message encryptSOAPEnvelope(
      SOAPEnvelope unsignedEnvelope, Message axisMessage)
      throws Exception
   {
      WSEncryptBody encrypt = new WSEncryptBody();
      // build the encrypted SOAP part
      Document doc = unsignedEnvelope.getAsDocument();
      Document encryptedDoc = encrypt.build(doc, crypto);
      // Convert the document into a SOAP message
      Message encryptedMsg =
         (Message)AxisUtil.toSOAPMessage(encryptedDoc);
      // Retrieve the desired SOAP part
      String soapPart = encryptedMsg.getSOAPPartAsString();
      ((SOAPPart)axisMessage.getSOAPPart()). setCurrentMessage(soapPart, SOAPPart.FORM_STRING);
      encryptedDoc =axisMessage.getSOAPEnvelope().getAsDocument();
      // Convert the document into a SOAP message
      Message encryptedSOAPMsg = Message)AxisUtil.toSOAPMessage(encryptedDoc);
      return encryptedSOAPMsg;
   }

列表4显示了加密过程:首先获得加密前的SOAP信封，接下来获得用户的证书信息并以此产生加密对象，然后是应用此加密对象对获得的SOAP信封进行加密，最后为根据被加密之后的SOAP消息产生新的SOAP消息并向下传递。

　　C. 消息对比:

　　图3和图4分别显示了签名消息和加密消息的对比情况。

　图3:应用数字签名前后SOAP消息对比

　图4:应用安全加密前后SOAP消息对比

　　3. 益处

　　A 本实践不仅有效的提高了WebSphere IICE Web Services SOAP消息的安全性，而且满足了对用户具有很大意义的新需求。
　　B 本实践提供了一个实现当前最新的、炙手可热的Web Services安全标准并把它应用于IBM产品的示例。
　　C 本实践提供了怎样把当前较新的技术和IBM已有的解决方案整合在一起来满足用户新的需求的示例。
　　D 本实践很好的显示了怎样在使用Web Services技术的IBM产品中应用Web Services安全。
　　E WebSphere IICE安全实现机制拥有良好可扩展性。

　　4. 结论

　　本实践对WebSphere IICE的Web Services SOAP消息安全机制进行了改良。同时提供了一个把最新技术标准应用于IBM产品的示例。这样不仅满足了用户新的需求而且很好的扩展了IBM产品的应用场景。

BPM 2006-12-02 13:18 发表评论

WS-Reliability 处理Web服务可靠性问题

BPM — Sat, 02 Dec 2006 05:14:00 GMT

随着Web服务的应用不断增多，对很多项目来说，只解决异构平台的分布式通信问题已经不够了。尽管互操作性是很多人考虑Web服务时的首要选择，但分布式系统还带来了很多难题使得互操作性不那么容易实现。在下面的文章中，我们将看看如何解决Web服务中的另一个分布式技术问题:可靠性。

　　可靠性一个关键概念，在涉及到金融相关数据时尤其如此。天气预报的Web服务代理信息与提供股票市场定单的Web服务是不能相提并论的。前者可以忍受网络失败并且接受新的请求而不产生大的影响，而如果后者没有必要的手段来处理这些问题就会产生严重的后果。基于此，在OASIS的赞助下出现了一个专门处理可靠性问题的Web服务说明书:WS-Reliability .

　　与其它Web服务说明书一样，WS-Reliability体现出可组合性的特点，它允许你按照需求混合匹配各种SOAP行为。通过这种方式，任何基于SOAP的应用都可以获得该可靠性层的好处，只需简单地添加SOAP头信息就能使用WS-Reliability中的任何规则。例如:

　　保证传送至少一次——发送的消息必须传送到接受端，要么给发送端一个发送失败的说明。
　　删除重复信息——最多发送一次，检测重复信息并在接受端删除。
　　保证消息顺序——消息按照顺序被发送

　　尽管WS-Reliability基于SOAP提供协议以某种方式传送有效负载等可靠数据，但还是要通过一个高层栈的翻译或处理来决定是否执行一个可靠通信。在WS-Reliability's中，高层栈是指能够进行转化的一种特殊环境，它可以是ESB或折like PHP/PEAR、 Java/Axis等Web服务框架。

　　这说明，就算用WS-Reliability实现的服务能够无缝地与其它服务交互，但唯一使用这些信息，还必须学习一个特殊的Web服务栈。有个例子，Apache Software Foundation创建的名为Sandesha 的WS-Reliability实现被加入了Axis框架中。而Axis框架是该基金会创建的一个Java Web服务栈。

　　现在，我们来看看Sandesha如何利用Axis框架创建可靠的Web服务。我们并不深入到细节，你可以查阅Sandesha的文档来看看它是如何加入到Axis架构中的。或者好好阅读Axis文档，如何你对它不熟悉的话。

　　我们的情景是一个Web服务客户端向一个股票报价系统发出一个可靠请求。表单1.1显示了我们的客户端如何使用Sandesha/Axis。

　　Listing 1.1

import org.apache.axis.client.Service;
import org.apache.axis.client.Call;
import org.apache.axis.encoding.XMLType;

import org.apache.sandesha.Constants;
import org.apache.sandesha.SandeshaContext;

import javax.xml.namespace.QName;
import javax.xml.rpc.ParameterMode;

public class StockQuoteClient {

private static String targetURL = "http://acmestockquote.com/axis/services/StockQuote";

   public static Double stockQuote(String symbol) {
        Double priceObject = new Double(0.0);
try {
         Service service = new Service();
Call call = (Call) service.createCall();
SandeshaContext ctx = new SandeshaContext();
     ctx.initCall(call, targetURL,"urn:wsrm:stockQuotePrice",Constants.ClientProperties.IN_OUT);
               call.setOperationName(new QName("acmestockquote.com", "stockQuotePrice"));
         call.addParameter("Text", XMLType.XSD_STRING, ParameterMode.IN);
         call.addParameter("Seq", XMLType.XSD_STRING, ParameterMode.IN);
         call.setReturnType(org.apache.axis.encoding.XMLType.XSD_DOUBLE);
      ctx.setLastMessage(call);
priceObject = (Double) call.invoke(new Object[]{"StockQuote", symbol});
        ctx.endSequence();
} catch (Exception e) {
            e.printStackTrace();
}
        return priceObject;
   }

    public static void main(String[] args) {
        StockQuoteClient.stockQuote("SLB");
StockQuoteClient.stockQuote("BCA");
StockQuoteClient.stockQuote("SNY");
    }
}

StockQuote方法包括我们的业务逻辑。首先，使用了Service和Call类，每个对象实例可以被基于Java Axis的Web服务客户端正常使用。在上面的例子中，它们都被保证可靠性的层SandeshaContext使用。

　　SandeshaContext用来维护在客户端和服务器端之间交互的状态。这就是为什么Call方法在ctx.initCall和ctx.endSequence之间被嵌套的原因。而它们正代表了Sandesha启动和结束一个可靠的过程。实际上，Call方法产生了一个不能被标准Web服务操作探测到的错误，例如被确保的传送或者重复的请求。Sandesha能够通过它的上下文来决定如何输出。

　　在表单中，你还能看到在ctx.initCall方法中有urn:wsrm:stockQuotePrice的命名空间。它代表了被加入到客户端请求中的额外SOAP头信息，它能被Web服务提供者识别用来完成可靠性过程。在Axis/Sandesha的例子中，尽管二者的结合提供了对构建具有翻译WS-Reliability客户端能力的服务提供者的支持，但它还具有本文没有提到的其它功能。不过，你应该注意到Axis/Sandesha框架已经与WS-Reliability进行了成功的测试，包括不同的Web服务栈上的客户端与服务器端，包括IBM、Microsoft 和Systinet。

　　至此，我们对Sandesha和WS-Reliability下一个结论。在解释了如何利用Web服务的可靠性特征后，你现在可以考虑实现其它的企业消息技术，例如至今可靠的分布式通信产品JMS (Java Messaging Service)，并且用WS-Reliability提供同样的可靠性，但要继承平台无关的Web服务的所有优点。

BPM 2006-12-02 13:14 发表评论

在面向服务的体系结构中管理状态

BPM — Sat, 02 Dec 2006 05:09:00 GMT

一个有关 Web 服务的最常见误解是，它们只适合于支持基于同步请求/响应 SOAP(简单对象访问协议)的交互。造成这种误解的主要原因之一是，许多 Web 服务是使用不可靠的无状态传输协议(如 HTTP)实现的。

　　因此，许多组织正避免用 Web 服务来处理复杂的业务交互(在复杂业务交互中，服务使用者可能同时与同一服务进行多个交互，或同时与多个服务进行多个交互)。 OASIS(结构化信息标准促进组织)将此类交互称作 Web 服务会话，并将支持会话的 Web 服务称作会话式 Web 服务。会话式 Web 服务是异步 Web 服务的基础，在实现持续长时间业务事务方面起着至关重要的作用。

　　本文将介绍如何使用显式状态标识符支持会话式 Web 服务。此外，还将概述如何使用 Oracle JDeveloper 10g 10.1.3 J2EE 开发人员预览版(为 J2EE 1.4 JAX-RPC 提供了内置的支持)实现该种方法。

　　会话式 Web 服务简介

　　服务使用者与服务提供者之间的大多数交互是 Web 服务会话，例如，某个服务端点可能同时从多个客户端收到多种类型的文档，处理这些文档并使用相应的响应联系使用者。在这样的应用程序中，特别要求正确识别每个客户端的交互，这使得 Web 服务实现更加复杂。为了避免这种复杂性，许多公司将 Web 服务实现局限于简单的单一请求/响应类型的交互(AuthorizeUser、CalculateTax、ConvertFunds 等)。

　　但就其理想情形而言，Web 服务应支持服务使用者和支持提供者之间的单一交互和复杂交互。无论传输协议如何，同步或异步 Web 服务都应能够代表单个客户端或在跨多个交互的特殊业务环境中保存状态或资源。

　　长期以来，解决 Web 服务中的状态性问题的需要一直是标准组织和主要供应商的焦点。为解决关键任务和冗长业务流程中的状态性问题，涌现了多个 Web 服务规范草案，如 WS-Addressing、WS-Resources 和 WS-Coordination。最重要的是，业务流程执行语言 (BPEL) 1.0 规范已经整合了 WS-* 标准建议的许多特性来处理持续时间较长的业务事务。但也应看到新标准和解决 Web 服务会话问题的相关供应商技术的广泛采用。

　　总之，实现会话式 Web 服务仍是一个相当大的设计挑战。当面临依赖 Web 服务的复杂应用程序时，应用程序开发人员别无选择，只能构建定制的解决方案。

　　会话式 Web 服务的工作方式

　　会话式 Web 服务(本质上是异步的)有两个重要的服务元素类型: 可调用方法和响应方法(通常称作回调)。会话式 Web 服务中的每个可调用方法和回调方法确定该服务、其客户端以及该服务所使用的任何执行控件(例如，Java 控件)之间的通信行为。可调用方法可以启动、继续或结束会话;而回调可以继续或停止会话。

　　为更好地描述会话式 Web 服务，我将介绍一个场景，在本文通篇将以该场景为基础。该示例采用两个会话: 一个是 Web 服务与它的客户端之间的会话，另一个是两个 Web 服务之间的会话(参见图 1)。

　　在本示例中，BestTermInsurance Web 服务通过使用另一个服务 (InsuranceQuote) 代表客户查找各种保险提供商。当客户端请求 BestTermInsurance 服务提供报价时，将启动第一个会话;当 BestTermInsurance 服务调用 InsuranceQuote 服务请求报价时，将启动第二个会话。当 InsuranceQuote 服务找到最低报价时，它将响应 BestTermInsurance 服务，第二个会话随即完成。然后，BestTermInsurance 服务恢复与客户端的第一个会话。

图 1: BestTermInsurance 服务

　　Web 服务会话保存 Web 服务的状态;后者包括用于链接 Web 服务、它的客户端和其他资源之间的通信的相关数据以及在会话完成之前由该服务保存的任何数据。该状态信息称作会话状态(也称作关联状态)。在本示例中，BestTermInsurance 服务保存客户端的每个报价以及关联的消息属性，直到找到最低报价。

管理会话状态

　　使用显式状态标识符是在 Web 服务交互中管理会话状态的最简单和最相当有效的方法。尽管名称暗示了单个 ID，但完全受管理的会话需要更多的信息，尤其是当与服务请求关联时。因此，状态标识符实际上是一个控制类，它保存以下一组针对每个请求-响应交互的与状态相关的信息:

　　Web 服务客户端的唯一标识符
　　为该客户端启动的 Web 服务会话的标识符
　　该会话中服务请求的标识符
　　服务请求者(客户端)与服务提供者之间的会话阶段指示器，服务使用该指示器进行正确的状态保持
　　Web 服务基础架构的分发函数与调用接口之间的交互状态指示器(在使用 Web 服务接口的晚期绑定进行动态调用方面很有帮助)

　　出于本文的需要，我采用静态 Web 服务调用，因此将不介绍第 5 种信息。

　　一般说来，用于关联请求的技术解决方案是让服务请求者将状态标识符信息(服务请求的唯一标识符(请求 ID)、会话标识符(会话 ID)和会话阶段指示器(阶段)添加到请求消息中，并让服务提供者将标识符信息复制到通过回调传递的响应消息中，这样请求者可以将回复消息与请求消息相关联。

　　有多种方法可以将状态标识符信息包含在消息交换中，具体包括:

　　将标识符信息以额外的参数形式传入 Web 服务方法;可以将 Web 服务接口设计为不但接受 XML 文档消息，而且接受其他代表状态标识符信息的参数。
　　将标识符信息作为 XML 文档的一部分传递 — XML 文档可以包嵌在其主体中的此种信息。
　　在 SOAP 消息标头中传递标识符信息。

　　但无论是通过添加额外的输入参数将标识符信息包含在服务接口中的第一种方法，还是将此类信息包含在 XML 文档本身中的第二种方法，事实上都会使标识符信息处理成为服务结构一部分，从而使代码更难以维护。此外，将来随着新 Web 服务标准被更广泛地接受，可能不再需要自定义解决方案了，从而将难以从服务实现中“拆除”嵌入的、与标识符相关的逻辑。

　　因此，第三种方法，即将标识符信息包含在 SOAP 消息标头中是最合理的方法。使用此方法时，服务请求者将标识符信息作为一组新的子元素添加到消息的 SOAP 标头中。服务提供者拦截该 SOAP 消息，然后提取标头中相应的状态标识符信息且不会破坏消息主体。

　　简单地说，将标识符信息添加到 SOAP 标头中将使相关的代码与文档处理逻辑和关联的业务逻辑以及服务接口的具体实现相分离。

　　实现显式的状态标识符 - 示例

　　现在，我们将继续介绍示例场景 - BestTermInsurance 服务。 (请参见图 2 以获得该场景的说明。) 正如边条中描述的，Oracle 应用服务器提供了两个服务实现选项: 无状态 Java 类(可以部署到 Web 容器中)或无状态会话 EJB。 (该设计基于将 EJB 与一个服务 fa ade — BestTermInsuranceServlet 一起使用)。建议您使用 fa?ade 将服务实现为 EJB，这是因为这样做不但具有更好的服务可用性和可伸缩性，还可以引入 SOAP JAX-RPC 处理程序(稍后将对其进行详细介绍)。

图 2: 示例场景

　　下面我们将逐步介绍此示例场景并了解该控件。当客户端通过调用 servlet 的 requestQuote 方法(传递有关客户年龄和健康状况的信息)提交搜索请求时，Web 服务交互将启动。 requestQuote() 方法包含一个 void 返回值，并立即返回，从而使客户端可以继续操作，而不必等待稍后将通过 onBestQuote() 回调发送的实际结果。显而易见，应将客户端设计为从回调方法中接受消息。

接下来，BestTermInsuranceServlet 调用 BestTermInsuranceEJB(用于保存客户年龄和健康状况指示器)和一个所获得的报价列表(与客户端 ID 和请求 ID 关联，作为与状态相关的数据)。 BestTermInsuranceEJB 随后调用 InsuranceQuote 服务的 obtainQuote() 方法以从参与的保险人那里获得报价。 (参见图 3，一个演示最重要的服务交互的序列图。)

图 3: 使用 JDeveloper Modeler 的示例 UML 序列图

　　InsuranceQuote 服务在特定客户端作用域内运行，因此该服务需要访问客户端 ID。在会话跟踪方面，InsuranceQuote 服务使用它自己的会话和请求 ID。

　　在根据给定的客户年龄和健康状况指示器收集所有保险报价时，InsuranceQuote 服务使用 onObtainQuoteComplete() 回调返回其结果。此回调完成第二个转换，并清除由 InsuranceQuote 服务保存的所有状态数据。但由 BestInsuranceQuoteServlet 控制的第一个会话仍继续执行: BestTermInsurance 服务可能从客户端获取其他请求，例如，根据特殊的保单条款(一年、十年等)提供最佳报价。结果以消息形式通过 onBestQuoteCallback() 方法发送给客户端。

　　编码技巧

　　现在，我们来着重介绍以下实现状态标识符的具体编码技巧。遗憾地是，由于篇幅有限，将只在代码中介绍与本文主题相关的元素。

　　正如前面所介绍的，假设状态标识符信息已传入 SOAP 消息标头中。用于基于 XML 的远程过程调用的 Java API (JAX-RPC) 非常适于处理 SOAP 消息标头 - 具体而言就是通过使用 JAX-RPC 的某个最有意义的特性: 消息处理程序。消息处理程序为 Web 服务提供了附加的消息处理逻辑，以作为对这些服务的业务逻辑实现的扩展。除了管理身份验证、加密和解密、日志记录和审计等外，处理程序还支持状态标识符的插入。为此，可以创建多个处理程序来管理每个具体问题。在 JAX-RPC 中，处理程序的这种用法称作处理程序链。

　　处理程序链表示一组有序的处理程序。使用有序组可以使应用程序开发人员能够定义处理程序调用策略 - 调用顺序、目标(“仅处理请求”或“仅处理响应”或两者都处理)等。处理程序链继续处理处理程序，直到引发 SOAP 错误或调用策略指示显式停止点。

　　因此，要使用 SOAP 标头内嵌的状态标识符实现 Web 服务，建议用三个步骤来进行开发:

　　设计基本的服务组件并进行编码。
　　开发 SOAP 消息处理程序。
　　用已开发的 J2EE 组件构造 Web 服务(公开)。

　　使用 Oracle JDeveloper 10g J2EE 开发人员预览版时，可以使用应用程序导航器下的类别“Business Tier”将已编译的 Java 类或 bean 公开为 Web 服务。从该类别中，开发人员可以选择一个上下文菜单项“Java Web services”。此菜单项包含两个选项“J2EE 1.4 (JAX-RPC) Web services”和“Oracle J2EE 1.3 Web services”。选择“J2EE 1.4 (JAX-RPC) Web services”。
　以下代码清单显示了一个符合要求的 SOAP 消息格式，其中的标头包含 BestTermInsurance 服务的外部(客户端-服务)会话的状态标识符:


      Client ID
      Conversation ID
      Request ID
      Phase


     Age
     Health
     Term


但在此进程的开头，该 SOAP 消息定义不包含状态标识符信息，如下所示：


     Age
     Health
     Term


这正是 SOAP 处理程序的用途所在: 对将状态限定符插入到标准 SOAP 消息定义进行处理。在 JAX-RPC 服务中，处理程序由实现 handleRequest() 和 handleResponse() 方法(用于修改请求和响应消息)的处理程序类表示。可以将处理程序类配置为在客户端或服务级别处理请求和响应。处理程序使用 javax.xml.soap.SOAPMessage 类来处理 SOAP 消息。 SOAPMessage 对象包含一个 SOAPPart 对象，该对象包含实际的 SOAP XML 文档和一个被分解为访问 SOAP 主体和标头的 SOAPEnvelope 对象。

　　以下代码清单演示了所描述的方法:

package exp.oracle.jaxrrpc.headers;

.............

import javax.xml.rpc.*;
import javax.xml.soap.*;

public class BestTermInsuranceRequestHandler implements javax.xml.rpc.handler.Handler
{

...........................

/*
*The handleRequest method processes the request message.
*/
try {
SOAPMessageContext msg = (SOAPMessageContext) context;
SOAPEnvelope env = msg.getMessage().getSOAPPart().getEnvelope();
SOAPHeader hdr = env.getHeader();
exit=processRequestHeader(hdr);

}
catch (Exception ex) {
ex.printStackTrace();
}

return exit;
}

/*
* This version of the process header method inserts the state identifier information.
*/
private boolean processRequestHeader (SOAPHeader hdr) {
boolean exit = false;

SOAPFactory sFactory = SOAPFactory.newInstance();
try {
SOAPElement he1 = sFactory.createElement("stateIdentifier",PREFIX,URI);
SOAPElement che11 = sFactory.createElement("ClientID",PREFIX,URI);
            che11.addTextNode("Cust1");
            ...............................
            he1.addChildElement(che11);
            he1.addChildElement(che12);
            he1.addChildElement(che13);

            // add the state identifier information to the SOAP header object
            hdr.addChildElement(he1);
            exit = true;

}
catch (Exception ex) {
ex.printStackTrace();
}

return exit;
}
开发 SOAP 处理程序后，可以使用 WSA 在相应的 webservices.xml 文件中配置它们。然后，可以继续创建部署描述文件并将 Web 服务安装到 OC4J 中。

　　结论

　　显而易见，将单个请求-响应交互与无状态的 Web 服务结合使用是最简单的实现方法。但伴随简单性而来的是一个很大的缺点: 无法实现用于处理复杂和长期运行的业务事务的 Web 服务。

　　本文介绍的状态管理方法所基于的策略以更出色的方法对长期运行的业务活动进行建模。具体而言，在本方法中，服务“注册”到良好控制的会话(将特定的工作单元表示为业务活动进度)。此功能对于连接企业内部以及跨企业的、支持 Web 服务的应用程序很重要，并包含一组支持对连接的应用程序之间的交互进行管理和监控的特性。

http://www.oracle.com/technology/global/cn/pub/articles/davydov_soa.html

BPM 2006-12-02 13:09 发表评论

普元软件

BPM — Sat, 02 Dec 2006 04:42:00 GMT

摘要：五年的普元还很小，也还很脆弱，在面向构件的新软件体系的道路上普元也才仅仅迈出了开始的几步。但是我们相信在茫茫的软件世界中，中国还是有独特机会，普元就像是星星之火。为了这星星之火可以燎原，普元还将付出5年、10年或者更长时间的努力，但是没有什么将可以阻止我们前进的步伐！

2 年多以前当搜索刚刚流行的时候，在Googel中敲进普元两个字，出来的多半是和某种钢材相关的信息，今天出来的58000多条信息中关于普元软件的基本上在前30页都是。普元用了2年多的时间，把普元和面向构件技术紧密地联系起来，普元也成为软件构件化的代名词，成为世界领先的构件领域专家企业。

很多人可能还不清楚为什么我们公司的名称是“普元”两个字。这个听起来像庙宇名字一样的“普元”是什么意思呢？

“ 普”意指普遍的，“元”代表基本元素，所以合起来的解释就是“普遍存在的基本元素”。就像物理世界存在基本粒子为代表的基本元素一样，我们认为在软件世界也存在基本元素，这些普遍存在的基本元素的集合是有限的、是可数的，因此就决定了我们可以用一组基本信息元素构建复杂而庞大的信息系统，就像物理世界复杂系统（如分子、蛋白质、器官、人）都是由一组基本元素（电子、中子和质子）组成的一样。在此哲学思想的指导之下，我们就可以构筑一个面向构件的新软件体系。在这个新的体系中，复杂的软件系统将最终可以分解成为这些简单的元素（基础构件）。

就像物理学家几百年探索物理世界，寻找物理世界的本质一样，普元在探索信息世界，寻找软件世界的本质。今天的软件形态就像19世纪的物理学的分支热力学，基本上属于现象学的。人们观察并总结了温度、压力等概念，并且找到了一些规律。一直到基于分子运动的统计力学出来以后，人们才明白温度乃是分子运动强度的表现，压力是强度和密度的集合表现等等。由于历史的原因，今天软件的分类如CRM，ERP等等都是从用户的视角来进行的，无论是开发商还是用户都还没有拥有一个构造分析的视角，能够用分析的视角看待软件体系只有在面向构件的时代才真正成为可能。

这个基于有限构件集合的新软件体系必将取代旧的无序的基于代码的传统软件体系，黄博士的书《软件的涅磐》就是阐述这个思想。

企图用构件的思想来攻克软件世界的并不是普元的原创，为什么这样的机会留给了普元？为什么软件大国美国没有去做？软件大鳄IBM没有做？我们经常会遇到这样的提问。回答这个问题需要两个方面的视角，一是技术的视角，另一个是商业的、市场的视角。

从技术的视角来看，软件构件思想虽然已经提出近四十年，但是昂贵技术的壁垒和由此所带来的标准壁垒使得这样的思想无法在通用的领域商业上成为可能。就像理论上我们今天可以用核聚变技术把海水变为电能一样，商业上利用海水来发电还是遥不可及的。即使是在10多年以前，人们对软件的功能企图不过是相对简单的客户管理、生产流程管理、内部审批等等内容，基本限于部门级别的使用，少数也可以在公司范围内使用。一台大型主机动辄几十万上百万美元，交换机也非常昂贵，软件接口没有标准，市面流行着35种电脑之间的通讯协议，在10多年前的那个时代这些也就足够了。

随着互联网的出现，我们迎来了电子商务和一个数亿人参与的信息互动时代。基于部门的非标准的软件系统不能再满足人们对信息系统的要求了，同时技术价格的在不断的急剧下降，互联网电子商务的全民互动时代强制了标准的迅速建立，TCP/IP统治了网络通讯协议，软件标准也在逐步形成。当2001年4月普元把J2EE技术，WebService技术，XML技术和构件技术作为未来的标准技术集成在一起的时候，应该说我们是先驱者之一。那个时候由于应用性能问题，这些技术在实践中还是非常谨慎采用的，并非主流。因此，可以说互联网的普及使得软件构件技术获得生命。

从市场的视角来看，美国的大老们到今天还在为解决过去几十年所留下的大量的数以万亿美元计算的企业信息系统改造而操心，因为那是今天最大的一块饼，美国人拖上印度人一起在努力的分割这一块传统软件市场的最后一块蛋糕。他们无暇顾及这个在美国还需要多年时间才能够变得可观的市场。美国也曾经由若干企业在面向构件技术的路上走了几年，最后应为市场的原因而倒闭和拍卖，发达国家的主流客户的机房里都已经堆满了历史上遗留的各种信息系统，从商业的角度看今天谁也不愿意为一个新的软件体系买单。

因此，这个机会留给了在中国的普元。今天中国的企业软件市场不过是世界市场冰山一角，仅占全球市场的3%左右。中国企业的信息化程度也不过仅有5%，未来的十年中国还有很长的路要走。不过我们有理由相信，中国在未来的5到10年将成为全球信息化的主流市场之一，中国将为信息化付出数万亿人民币的代价。然而，我们相信这一切将在新的以面向构件为核心的新软件体系下进行。中国没有庞大的遗产系统包袱，以现实的、商业的理由来看中国无法采用现有的、传统的国外软件体系，必须重新建设。

《软件中国的机会》就是在阐述这个思想。

五年的实践，我们通过市场的验证，证明了面向构件的软件思想是正确的，软件构件化商业上的应用是实际有价值的。

五年的普元还很小，也还很脆弱，在面向构件的新软件体系的道路上普元也才仅仅迈出了开始的几步。但是我们相信在茫茫的软件世界中，中国还是有独特机会，普元就像是星星之火。为了这星星之火可以燎原，普元还将付出5年、10年或者更长时间的努力，但是没有什么将可以阻止我们前进的步伐！

BPM 2006-12-02 12:42 发表评论

通向SOA－美国和中国不同的道路

BPM — Sat, 02 Dec 2006 04:40:00 GMT

想起宽带刚刚普及的时候，我在硅谷的家中也就开始安装了，不过麻烦的事情是家中有5个电脑分布在5个不同的房间。房子是建于1963年的老房，所以用网络线的连接就成为问题。最快速且便宜的解决方案是布裸线，否则就要开腔凿洞。因此，家中的墙角和房门口的过道均成为网线的的落脚之处，难看之极，但这是当时最简单的解决方案。直到无线局域网的出现，这个问题才得以解决。

在中国的小区建设中，宽带的连接成为基本配置，所以老的社区曾经也有同样的问题，而大量的新社区这个问题就不存在了。即便有无线局域网的技术，有线宽带的接口还是都提供的。新社区的好处就是可以在一开始就部署新技术，而不需要走老路。

如今，全世界都在嚷嚷SOA，那我们也需要考察美国人怎么部署SOA，中国人怎么部署。研究这个问题，对我们软件公司还是对我们的客户都是有极大帮助的，以免再一次被我们的“主流”厂商误导。因为，美国人如何部署SOA决定美国SOA产品的特征，中国人怎么部署决定中国SOA产品的特性。

SOA 的核心是把业务流程功能模块构件化，并对外提供标准的服务，基于这些服务，企业内部的不同业务部门或是不同企业之间的业务整合就更加容易一些。SOA的出现是由于互联网技术的出现，将原来各自为阵的EAI市场标准化。

在美国由于多年的应用系统建设，企业的业务流程大多数以非标准的形式被掩藏在各种各样的应用系统之中，比如CRM系统，ERP系统，HR系统，信用评估系统等等。所以实现SOA架构的第一步是将那些掩藏在个应用系统之中的业务功能模块切割开来，加以包装之后成为标准的服务构件，然后还要将分散在不同系统中的数据整合包装成为数据服务，最后根据业务的需要同过BPEL将分散的服务连接成为新的服务。所以美国实现SOA的方法为：

1 。对原有业务流程的提取和包装成为服务构件（SCA）；

2 。对原有数据的整合包装成为数据服务（SDO）；

3 。用BPEL实现新的流程。

这个做法的可行性基于一个重要前提：原有的业务流程可以被切割包装（代价问题），原有的数据可以在一定程度上被标准化包装成为服务，如果所有的系统都需要通过人工切割和包装则代价太大，必须存在一次切割多次复用的情况，否则切割的环节无法产品化。由于美国企业的应用系统大量采用了有限厂商的产品比如SAP，ORACLE，SIEBLE等，一定程度的标准切割是存在的，尤其是多年的EAI实践，为切割的标准化打下了基础。尽管如此，大量的基于人工服务的切割还是必须的，所以，印度人有饭吃。而这些切割的工作与中国软件外包企业多半无关。

因此，我们可以预见美国制造的SOA产品将把具有标准切割及打包功能作为重要的卖点，也是产品的价值所在。市场决定产品的特征，就这么简单的逻辑。

中国的 SOA 如何实现呢？我们的预见是多半是把系统按照SOA提供的标准来建设，主流是把系统建设成为 SOA 标准的系统，而不是切割和包装，那些需要切割和包装的系统绝大多数依赖于服务而不是产品。作出这个判断基础两个前提：

1．1。原有的系统很少；

2．2。那些已经存在的系统很少是能够被标准化切割的；

因此，在中国开发 SOA 产品最重要的特征是如何在一个标准的平台上（框架内）构造企业所需要的所有标准服务，并且容易管理和发展（变化）。中国市场 ( 客户 ) 面临的主要问题有如下几条：

还没有采用SOA架构标准；
原有的系统难以切割，业务流程难以提取；
复杂的数据难以整合；
新建的系统没有统一的技术架构，产生更多的标准化问题。

考察中国的市场我们可以作出如下的预言：

1．1。 SOA 将被主流市场接受成为标准的体系结构；

2．2。美国主流的SOA产品在中国会水土不服；

3．3。原有系统将主要依靠服务来切割，或者推倒重来；

4．4。大量的新建系统将采用标准的小颗粒构件构造流程级别的标准服务构件；

5。5。普元面向构件的中间件将成为 SOA 主流中的中国主流。

引用:
http://gocom.primeton.com/blog/index.php?op=ViewArticle&articleId=891&blogId=62

BPM 2006-12-02 12:40 发表评论

Web服务架构及其规范入门

BPM — Tue, 28 Nov 2006 13:37:00 GMT

Web服务架构及其规范入门

作者：Luis Felipe Cabrera、Christopher Kurt、Don Box

[摘要]本Web服务架构入门阐述了Web服务架构的基础设计原则和Web服务的基础技术。此外还对其功能进行了介绍，并提供了对其进行正式定义的规范链接。本文也是该架构所有规范的参考指南。

XML和Infoset

对于所有的消息传递系统来说，选择信息传输单位是非常重要的——简单地说，对消息的构成有个一般的认识是必不可少的。在Web服务中，一条消息就是一个XML文档信息项，它由XML信息集（XML Information Set，即Infoset）定义。Infoset是一个抽象的数据模型，它兼容基于文本的XML 1.0，也是所有最新XML规范（XML Schema、XML Query和XSLT 2.0）的基础。由于Web服务架构是以XML Infoset，而不是某一特定的表现形式为基础，使得该架构及其核心协议组件可与其他编码技术兼容。

Infoset根据一组‘信息项（Information Items）’对XML文档进行建模。这组可能的信息项一般会映射到XML文档的不同功能部件上，如元素、属性、命名空间和注解。每一信息项都有一个关联属性集，用于提供该项的更完整描述。附录B描述了XML文档中的11类信息项。每一个结构严谨的XML文档都会包含一个文档信息项和至少一个元素信息项。

除了基于纯文本的Infoset编码技术以外，Web服务架构还支持另外一种Infoset编码技术——即允许不透明的二进制数据与传统的基于文本的标记交织在一起。W3C XML-binary Optimized Packaging（即XOP）格式使用多部分MIME将原始二进制数据引入到XML 1.0文档中，而不采用base64编码。其配套规范——SOAP 消息 Transmission Optimization Method，即MTOM，则指定如何将该格式绑定到SOAP。XOP和MTOM是将原始二进制数据与基于文本的XML混合在一起的首选方法，它们取代了目前普遍遭到反对的SOAP with Attachments（SwA）和WS-Attachments/DIME。

SOAP

SOAP为在分散的分布式环境中使用XML在同等体之间交换结构化分类信息提供了一种简单的轻量级机制。SOAP旨在最大限度地降低对基于不同平台构建的应用程序进行集成的设计成本，并认为最低成本技术最有可能赢得普遍接受。SOAP消息是包含三个元素的XML文档信息项，这三个元素是：、

和。

Envelope是SOAP消息的根元素，它包含一个可选的Header元素和一个必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一种通用手法。Header的每个子元素都被称为一个Header块（Header Block），SOAP定义了几个知名的属性来指示应该由谁来处理Header块（role）以及这种处理是可选的还是必需的（mustUnderstand），下文中对这两个属性进行了介绍。目前，Header元素总是Envelope的第一个子元素；Body元素总是Envelope的最后一个子元素，也是供最终消息接收者使用的“有效负载”的容器。SOAP本身没有定义内置的Header块，且只定义了一个有效负载，那就是用于报告错误的Fault元素。

所有的Web服务消息都是SOAP消息，它们充分利用了XML Infoset。消息有效负载和协议头都使用同一个模型，可以确保基础架构头Header和应用程序体的完整性。应用程序发送消息时可能会同时考虑Header的内容和消息中的数据。为XML数据模型开发的工具可以用于检查和构建完整的消息。过去，这些益处在某些架构中是没有的，如DCOM、CORBA和RMI，它们之中的协议头是一些对应用程序不透明的基础架构细节。

SOAP消息是从发送者向接收者单向传送的。多个单向消息的组合可以形成较为复杂的模式。例如，比较常见的模式是同步请求/响应消息对。发送或接收消息的任何一个软件代理都被称为一个SOAP节点（SOAP Node）。启动消息传输的节点称为原始发送节点。使用和处理消息的最后一个节点称为最终接收节点。在原始发送节点和最终接收节点之间处理消息的任一节点都叫做中介（Intermediary）。中介用于模拟单个消息的分布式处理。消息经过的所有中介节点和最终接收节点统称为消息路径（Message Path.）。

为了能够识别消息路径的各个部分，每个节点都担任一个或多个角色。SOAP角色是一种分类模式，它将一个基于URI的名称与某些抽象功能（如缓存、验证、授权）关联在一起。基础SOAP规范定义了2个内置角色：Next和UltimateReceiver。Next是一个通用角色，因为除了发送节点之外的每一个SOAP节点都属于Next角色。UltimateReceiver是消息路径中终端节点所扮演的角色。它通常就是应用程序，或在某些情况下是代表该应用程序执行任务的基础架构。

SOAP envelope的Body总是针对最终接收节点。而SOAP header则可以针对中介，也可以针对最终接收节点。为了提供一个安全且版本可控的消息处理模型，SOAP定义了3个属性，用于控制中介和最终接收节点处理某一指定Header块的方式——role、relay和mustUnderstand。角色属性用于确定Header块所针对的节点。mustUnderstand属性用于指示在Header块未被认出的情况下该节点是否可以忽略该Header块。带有mustUnderstand="true"标记的Header块叫做强制Header块（Mandatory Header Block）。标记为mustUnderstand="false"或没有mustUnderstand属性的Header块叫做可选Header块。relay属性指示该节点是发送还是放弃未被认出的可选header。

每一个SOAP节点都必须使用这3个属性来实现SOAP处理模型。以下步骤详细说明了该模型：

使用角色属性（缺省该属性表示Header块针对最终接收节点）确定将用于当前SOAP节点的SOAP消息的所有Header块。
验证当前SOAP节点是否能够使用SOAPmustUnderstand属性来处理步骤1中所确定的所有强制Header块。如果有强制Header块不能被当前SOAP节点处理，则必须丢弃该消息，并生成一条醒目的错误消息。
处理消息。可以忽略可选消息元素。
如果SOAP节点不是消息的最终接收节点，则步骤1中所确定的所有无法分程传送的Header块都会被删除，然后消息被传送到消息路径中的下一个SOAP节点。下一个SOAP节点可以自由地将新的Header块插入到分程传送的消息中。其中的某些Header块可能是步骤1中所确定的Header块的副本。

SOAP处理模型旨在实现可扩展性和版本控制。mustUnderstand属性对新Header块的引入是中断变化还是非中断变化进行控制。添加可选header块（如标记为mustUnderstand="false"的header）是一种非中断变化，因为任何SOAP节点都可自由忽略它。添加强制header块（如标记为mustUnderstand="true"的header）是一种中断变化，因为只有知晓Header块语法和语义的SOAP节点才能够处理SOAP消息。Role、relay以及mustUnderstand属性沿着消息路径传递这种处理模型。

消息交换模式

SOAP所提供的消息传递灵活性使Web服务能够以多种消息交换模式进行通信，从而满足分布式应用的需求。我们在该架构的核心构件中充分利用了其中一些模式，有几种模式已经被证明在分布式系统中特别有用，比如使用远程过程调用就使同步请求/响应消息交换模式得到了普及。当消息传送潜伏时间失控时，就需要采用异步消息传递。当使用同步请求/响应模式时，显式消息相关性则成为必需。

广播传输（Broadcast Transport）使一对多消息传输得到了普及。原始发送者将其消息强行发送给接收者的模式称为推模式（Push Model）。尽管这种模式在局域网里很有效，但在广域网中则不太适用，接收者也无法调控消息流。另一个有用的模式是以应用程序表达对某些特定消息类别的兴趣的能力为基础的，它使发布/订阅模式大行其道。通过显式订阅消息源（或主题），应用程序可以更好地控制相关信息流。接收者从消息源显式请求消息时使用拉模式（Pull Model）。在这种模式下，消息流是由接收者驱动的。拉模式也可以与发布/订阅模式结合使用。这非常适合于接收者可能要与消息源间歇地断开连接的情况。

传输的独立性

根据SOAP的定义，它与所使用的底层消息传递机制无关。它支持很多可用的消息交换传输机制，也支持同步和异步消息传送与处理。既需要多种传输又需要异步消息传递的系统的一个例子是在基于陆地高速网络干线的Web服务与由移动电话托管的间歇连接的Web服务之间进行通信的系统。这样的系统要求一条消息经哪种传输系统传输要以该消息在哪个网段内移动为依据。这样的系统还有一个典型特点，即消息传送潜伏时间无法精确确定。Web服务开发人员不应力图确定或界定消息传送潜伏时间，而应在假定异步消息传递已达到最大效能的前提下构建系统。与使用远程过程调用时的情况不同，异步消息传递允许发送者在每一消息传输之后继续进行处理，而不必被迫阻塞并等待响应。当然，同步请求--响应模式也可以构建在异步消息传递的基础之上。

既然Web服务协议完全独立于底层传输之外，适当机制的选择可能就要延迟到运行时。这就为Web服务应用程序提供了在发送消息时确定相应传输机制的灵活性。此外，底层传输机制可能会随着消息在节点之间的发送而变化，相应地，针对每一网段而选择的传输机制也会随需发生变化。

尽管存在着这种一般的传输的独立性，大多数第一代Web服务都使用HTTP来进行通信，因为这是SOAP规范内所包含的一种主要绑定协议。HTTP以TCP作为其底层传输协议。但是，TCP在设计时引入了不必要的处理开销。有些应用协议模式与用户数据报协议（即UDP， User Datagram Protocol）的语义学比较匹配，这些模式对于受设备及其他资源约束的系统特别有用。UDP不像TCP那样具有传输保证；它提供最大限度的数据报消息传递。与TCP相比，它需要的实施资源较少。此外，UDP还提供了多路广播功能（Multi-cast Capabilitiy），使一个发送者可以将消息同时发送给多个接收者。

寻址

对于要在这种多传输情况下发送和寻址的消息来说，要让关键的消息传递属性为多个传输所携带，就需要一种共用机制。为此，WS-Addressing规范定义了3组SOAP Header块：

Action Header块用于说明消息的预期处理。该Header块包含一个URI，最终接收者通常用它来分派要进行处理的消息。
MessageID和RelatesTo Header块用于识别和关联消息。MessageID和RelatesTo header使用简单的URI来唯一地识别消息——这些URI通常都是瞬态的UUID。
To/ReplyTo/FaultTo Header块用于识别要处理消息及其回复的代理。这些Header依赖于WS-Addressing所定义的称为“端点引用（Endpoint Reference）”的结构，它将与对SOAP消息进行正确寻址所需的信息捆绑在一起。

端点引用是WS-Addressing的最重要的方面，因为与仅使用URI相比，它们可为更细粒度的寻址提供支持。它们广泛用于整个Web服务架构。端点引用包含3条关键的信息：基地址、可选的引用属性集和引用参数。基地址是一个URI，用于识别端点，出现在指向该端点的每一SOAP消息中的To Header块中。引用属性和引用参数是用于为该消息提供附加发送或处理信息以补充基地址的任意XML元素的集合，它们以文字Header元素来表示。当使用端点引用来构建端点消息时，发送者负责提供作为Header块的所有引用属性和引用参数。

引用属性和引用参数之间的区别在于它们如何关联服务元数据。Web服务策略和契约仅基于其基地址和引用属性。通常，基地址和引用属性用于识别某一给定的已部署服务，引用参数用于识别该服务所管理的特定资源。

引用属性和参数是那些预期只被最终接收者处理的简单的不透明XML元素。它们有助于确保可用于分派、发送、索引或其他发送端处理活动的信息被包含在给定的消息中。尽管中介预期不会对该信息进行处理，但某些中介（如防火墙或网关服务程序）却有可能使用某些引用属性或参数来进行消息发送、消息处理。引用属性有很多用途。服务类（Classes of Service）和专用实体标识符（Private Entity Identifier）就是两个例子。在服务等级例子中，引用属性可以用于区分针对标准客户的Web服务和针对“黄金”客户的Web服务，后者提供了更高的服务质量和增强功能——可能是通过附加的操作或附加的绑定——在逻辑上形成两个不同的端点。这些属性只在一个会话中设置一次，然后便在交互的其余所有部分重复使用。引用属性另一个用途的例子是以一种对系统不公开发送消息的方式来识别客户的机制。这两种引用属性的组合可以高效地将消息发送给一组适当的服务器，并高效地确定与某一特定用户有关的应用状态。这些例子还展示了引用服务实例的数据和引用用户实例的数据如何用引用属性来表示。

需要特别指出的是，引用属性还有助于对共享一个共同的URL和作用域的WSDL实体集合进行寻址。WSDL是将Web服务描述为操作消息的一组端点的XML格式，它首先抽象地指定其实体，然后将其具体地绑定到特定实例。具体而言，消息和操作经抽象定义之后，被绑定到带有网络传输和消息格式信息的一个端点。因此，从WSDL的角度来看，当针对不同的具体实体（如输入或输出消息、portType绑定、端口或Web服务中使用一个共同URL的服务）时，对应端点引用的引用属性应该不同。

使用引用参数的两个例子是基础架构和应用水平。引用参数的基础架构例子可以是发送给某一事务处理监视器的事务/征募ID（Enlistment ID）。在一个购书的场景中，书的ISBN号可能就是一个引用参数应用水平例子。

元数据（Metadata）

所有的Web服务交互都是通过交换SOAP消息来进行的。为了提供一个健壮的开发和操作环境，服务是用机器可读的元数据来描述的——元数据支持互操作性。Web服务元数据可以服务于若干个意图。它用于描述Web服务支持的消息互换格式和某一服务有效的消息交换模式。元数据还用于描述服务的功能和需求。元数据的最后一种形式叫做“服务策略（Policy of Services.）”。消息互换格式和消息交换模式用WSDL来表示，策略使用WS-Policy来表示，契约（Contract）用上述三种元数据来表示。契约是将应用程序与它们所依赖的服务的内部实现细节隔离开来的抽象。

Web服务描述语言，即WSDL——Web Service Description Language，它是被广泛用于描述Web服务基本特征的第一种手段。用WSDL描述的消息被归并为定义基本消息模式的若干操作。这些操作被归并为称作端口的若干个接口，它们详细说明了抽象的服务契约。端口和绑定则用于将portTypes与具体传输和physical 部署信息关联在一起。WSDL描述是自动识别目标服务的所有特征和启用软件开发工具的第一步。WSDL指定请求消息必须包含什么以及响应消息在使用无歧义符号时的显示会是怎样。WSDL文件用于描述消息格式的符号是基于XML模式的。这意味着它既是编程语言中立的又是基于标准的，这使得它很适合于描述可通过多种平台和编程语言来访问的服务接口。除了描述消息内容以外，WSDL还可以定义服务在何处是可用的，以及哪些通信协议被用于与该服务交谈。这意味着WSDL文件可以指定用于编写与某一Web服务进行交互的程序的基本元素。有几种工具可用于读取WSDL文件，以及为编制句法正确的Web服务消息生成所需代码。

尽管WSDL是一个不错的起点，但它并不足以描述Web服务的方方面面，WSDL只能表示较少的一组属性。Web服务所必需的更详细信息包括：

操作特征：支持SOAP 1.2。
使用特征：仅在早9点和下午5点之间可用。
安全特征：要访问该服务必需使用Kerberos票。

第一代Web服务必须使用专有协议来交换带外（Out of Band）的元数据，这一问题可以使用WS-Policy来解决。WS-Policy提供了一种通用模型和语法来描述和传达Web服务策略。它指定了一个概念基集，它可以被其他Web服务规范使用和扩展，以描述更为广泛的服务需求和功能。WS-Policy引入了一个简单的可扩展语法来表示策略断言（Policy Assertion），以及一个处理模型来解释它们。断言可以合并到逻辑选项中。

策略断言使编程人员要么在开发时、要么在运行时向服务信息中添加适当的元数据。开发时策略的例子包括消息大小的最大允许值或所支持规范的确切版本，运行时策略的例子包括宕机时的必备服务或某一给定的管理过程（定期的硬件维护）期间Web服务的不可用性。可以对单个的策略断言进行分组，以形成策略选项（Policy Alternative）。策略是策略选项的集合。为了便于进行互操作，策略是根据其XML Infoset表示形式来定义的。为了在保持互操作性的同时减小策略文档的大小，又定义了策略的紧凑形式。

策略用于传达两个Web服务端点之间的交互条件。满足策略中的断言通常会引发反映这些条件的行为。因此，策略断言评估是识别兼容行为的中心。当且仅当请求者满足要求，即提供了这一功能、与该断言相符时，请求者才支持策略断言——策略的构造块。一般而言，这种决定要使用特定领域的知识来做出。请求者支持策略选项的条件是当且仅当请求者支持选项中的所有断言时，这种决定是使用策略断言的结果机械性地做出的。同样，当且仅当请求者至少支持策略中的一个选项时，请求者才支持策略。一旦策略选项经过评估，该决定也是机械性地做出的。请注意，虽然策略选项是互斥的，但一般来说要确定多个选项是否可以同时得到支持也是不太可能的。

为了以互操作的形式传达策略，策略表达式（Policy Expression）采用策略的某种XML Infoset表示形式。普通形式的策略表达式是最简单的Infoset；同样，可选的Infoset允许通过大量构造来简洁地表达策略。策略表达式是策略的基础构造块。有两个运算符用于表达断言：All和ExactlyOne。All运算符表示策略选项集中的所有断言都必须适用于要满足的策略断言。ExactlyOne运算符表示策略选项集中只有一条断言必须适用于要满足的策略断言。

策略层位于WSDL描述之上，并对它进行了扩充。策略与Web服务元数据（如WSDL定义或UDDI实体）的关联是通过使用WS-PolicyAttachment来实现的。策略可以作为其定义所固有的一部分或独立地与资源关联在一起。机制就是针对这些不同目的而定义的。需要特别指出的是，策略也可以与单个的SOAP消息一起使用。如果为某一实体制作了多个策略附件，它们会共同确定该实体的有效策略（Effective Policy）。在WSDL层次结构的不同层次上选用策略时一定要小心，因为层次结构每一层次的最终结果就是一个有效策略。作为自我描述和人所能理解的明确性的一般规则，在策略断言所适用的层次结构的每一层次上详细地重复该策略断言，比简单地依赖于计算有效策略的机制更可取。在一个WSDL文档中，与部署端点的消息交换可以同时包含所有4类主题的有效策略。WS-Policy和WS-PolicyAttachment相结合可以提高应用程序来发现和推出其他服务所支持的策略的能力。添加策略的灵活性是对描述消息交互的WSDL信息的一个重要补充。

WSDL和WS-Policy都定义了元数据格式，但都没指定某一给定服务获得或访问元数据的机制。一般来说，服务元数据可以通过使用许多方法来获取。为了支持服务的自我描述，Web服务架构在WS-MetadataExchange中定义了基于SOAP的元数据访问协议。GetMetadata操作用于检索在请求的端点引用中找到的元数据。Get操作类似，但用于检索不同的元数据：在元数据部分引用，并要在存储它的端点引用中检索的元数据。

使用WS-MEX来交换的元数据可以描述为资源。资源即可由某一端点引用寻址的任何实体，并且在该端点引用中，该实体可以提供一种其自身的XML表示形式。资源构成了构建Web服务中的状态管理所需的基础。

什么是互操作性概要（Interoperability Profile）
概要（Profile）是一组指导原则，主要针对于核心协议以及Web服务规范的使用。这些指导原则对于规范的通用设计来说是必需的。在某些情况下，开发人员需要额外的帮助来确定使用哪些Web服务特性来满足某一特定需求。互操作性概要还用于解决Web服务规范不够明确的领域中的含糊性问题，以确保所有实施都以相同的方式来处理SOAP消息。

WS-I基本概要
第一个Web服务概要是由Web服务-互操作性组织（WS-I，Web Services-Interoperability Organization）发布的。WS-I已经完成了其第一个概要，并简单地称为基本概要1.0。该概要主要基于SOAP1.1和WSDL 1.0的互操作使用来提供指导原则。

安全性

本节介绍Web服务架构中用于提供某一系统内部的消息完整性、身份验证和机密性、安全性令牌交换、消息会话安全性、安全策略表示和服务联盟安全性的规范。提供这些特性的规范是WS-Security、WS-Trust、WS-SecureConversation、WS-SecurityPolicy和WS-Federation。

安全性是计算机系统的一个基本方面，尤其是那些由Web服务组成的系统。安全性必须是健壮而有效的。因为系统只对消息格式和合法的消息交换作出硬件假设，因此安全性必须基于一致通过的明确机制和假设。安全基础架构还应该具有足够的灵活性，以支持不同组织所需的不同安全策略。

当安全传输可用于通信Web服务，如安全套接层（SSL）和传输层安全性（TLS）之间时，构建安全性解决方案就得到了简化。有了安全传输，这些服务就不需要参与单个消息的完整性和机密性的维护；它们可以依赖于底层传输。不过，现有的传输级安全性是一个仅限于点对点消息传递的解决方案。如果在使用安全传输时存在中介，则最初发送者和最终接收者需要相信这些中介能够帮助提供端到端的安全性，因为每个网段都是安全的。除了要明确地信任所有中介外，还必须考虑到其他风险，如消息的本地存储和中介受到损害的可能性。

为了最大限度地扩大Web服务的作用范围，当通信端点不相信中介时，必须提供端到端的安全性，那就需要更高级别的安全协议。作为另一种选择，端到端消息安全性比点对点传输级安全性具有更丰富的内涵，因为它支持Web服务所需的基于SOAP的松耦合、联合、多传输和可扩展环境。这种功能强大而又灵活的基础架构可以通过现有技术和Web服务协议的组合来开发，同时还可以缓解与点对点消息传递相关联的许多安全风险。

尽管Web服务的安全需求很复杂，但人们还没有发明新的安全机制来满足基于SOAP的消息传递的需要。现有的分布式系统安全性方法，如Kerberos票、公钥加密技术、X.509证书等已经够用了。只有应用现有的SOAP安全方法时，新机制才是必需的。这些新安全协议的设计充分考虑了可扩展性，以便将来能够加入新的方法。一个主要的设计目标是要提供自我描述安全性属性（为包括SOAP在内的Web服务架构而设计）机制。

Web服务安全性的基础是输入消息要证实一组关于发送者、服务或其他资源的断言这一需求。我们称之为断言或安全性断言。典型的安全性断言包括身份、属性、关键财产、权限或功能。这些断言是用包裹在XML中的二进制安全性令牌编码的。在传统的安全性术语中，这些安全性令牌表示功能和访问控制的混合。很多方法都被用于创建安全性令牌。Web服务可以从本地信息构建定制的安全性令牌。反过来，安全性令牌也可以从X.509认证机构或Kerberos域控制器等专业服务检索。为了实现服务之间的通信自动化，需要一个表达安全需求的方法。

服务可以使用WS-SecurityPolicy中所指定的策略断言来表达其安全需求。通过检索这些策略断言，应用程序可以构建符合目标服务需求的消息。断言、安全性令牌和策略所提供的这组特性以及从Web服务检索它们的能力非常强大。这种普通的Web服务安全模式支持一些更具体的安全模式，如基于身份的授权、访问控制列表和基于功能的授权。它允许使用现有技术，如X.509 公钥证书、基于XML的令牌、Kerberos共享的秘密票和密码摘要。这种普通模型对于构建使用更复杂的方法来进行更高级别的密钥交换、身份验证、基于策略的访问控制、审核和处理复杂的信任关系的系统已经足够。也可以使用代理和中继服务。例如，可以构建中继服务来加强位于信任边界的安全策略；出界的消息被加密，而界内的消息不加密。以前的解决方案没有提供这种灵活性和完善程度。附录C中所描述的常见安全攻击包含了系统威胁的基本分类，而这些系统威胁是在选择Web服务安全特性时应认真加以考虑的。

本节的余下部分将探讨Web服务安全模式的应用。两个重要主题是安全通信和安全应用。没有假定安全的消息传输，这也不是安全的Web服务所必需的。

消息完整性和机密性

消息级安全性是端到端安全性的关键构造块。使用消息级安全性时，无需传输级安全性。对消息级安全性的要求是消息完整性、消息身份验证和机密性。消息完整性确保消息不能在不知不觉中被更改。使用XMLSignature可确保消息的修改能够被察觉。消息身份验证可识别发送消息的主体。如果使用了公钥加密，就可以确定主体的唯一身份。将公钥加密与经受信任源认证的密钥一起使用可以实现这种身份验证。不过，如果使用了对称密钥加密，情况就不一样了——只有知道共享密钥的主体才能被识别。消息机密性可确保在传输期间未经授权的第三方不能阅读消息。SOAP消息是通过使用XMLEncryption [XMLENC]和安全性令牌来保证机密性的。

完整性、身份验证和机密性机制将初始消息（或该消息的某些部分）作为输入，将生成的数据（如校验和）作为输出。例如，在某种简单情况下，XML元素的签名可能会作为XML元素所有字符的散列的非对称加密来实现。然后该加密散列可以存储在该消息中，并在该消息中传送。可以将XML文档看作字符串。就像XML签名一样，逐字符地比较也是非常重要的安全性操作。一字之差会导致不同的结果。串行化是用于表示“在线”对象的方法。例如，串行化可用于创建SOAP消息的XML表示。不同串行化软件所导致的任何无关紧要的排字差异都会被消息处理软件忽略，但会对安全性软件产生很大影响。XML消息的Infoset表示形式改进了这一问题。要使XML签名生效，消息必须转换成一个对所有方都是一致的XML表单。规范化是一个术语，来描述用于生成一致的换行符、制表间隔、属性排序和结束标签样式等非关键信息视图的方法。签名包含了用于使消息接收者能够完全像发送者那样处理安全信息的规范化方法。某一服务所使用的特定的规范化方法是要放置在一个WSDL portType绑定或WSDL端口的有用的策略断言。

WS-Security指定了消息完整性和机密性机制以及单一的消息身份验证。对于消息完整性，该规范详细描述了加密签名是如何表示并与SOAP消息的特定部分关联的。该方法允许任意格式良好的消息片段拥有单独的签名。与之类似，机密性是通过结构良好的消息片段的加密来实现。身份验证是使用数字签名来实现的。WS-Security规范描述了当前常用的安全机制，也没有排除将来添加新机制的可能性。因为SOAP处理模型使用Header元素来作出处理决定，所以是决定SOAP消息中的哪些元素需要加密时一定要多加小心。

在决定要对哪些元素进行加密以及要使用哪些加密算法时，Web服务设计人员一定要清楚消息是如何处理的。当某些特定的Header元素需要由第三方或中介来处理时，这些决定就更为重要了。如果这些参与者对适当的解密数据或对在加密XML元素时所使用的约定毫无所知，它们将无法实现正确操作。此外，每个处理节点对消息中包含的安全信息都必须有个一般的了解。加密某一Header中XML元素的一个自然选择就是对它进行完全加密，用初始元素替代加密数据类型的元素。这种简单的方法有些缺点。例如，中介不太好确定必须处理哪些元素（带有mustUnderstand="1"属性的元素）。另外，当元素类型发生变化时，确定其初始类型比较困难。另一种方法是对元素进行转换，使得进行正确的SOAP处理所需的所有关键属性都保持不变，且对初始元素进行了加密，并放在一个特殊的子元素中。这种方法的优点是即使不知道如何解密元素的中介也能实现正确的处理。这种方法的一个缺点是它要求所有参与者都了解用于表示初始元素的约定。尽管WS-Security目前没有对这种方法提供指导，但我们预期将来会提供的。相比之下这种方法更好一些，因为它可实现所有SOAP Header元素的正确处理。

WS-Security的概要规范中描述了几种安全性令牌。针对表示用户名的令牌、X.509证书和基于XML的安全性令牌的概要都已经开发出来。基于XML的安全性令牌包括安全性断言标记语言（SAML，Security Assertion Markup Language）和可扩展权限标记语言/权限表达语言（REL，Rights Expression Language）。Kerberos票的使用规范还未成型。

WS-I基本安全概要
WS-I将要发布的最新的互操作性概要之一是基本安全概要（BSP，Basic Security Profile）。该概要提供了WS-Security和各种安全性令牌，如Username和X.509证书令牌的实现指导。该概要用于补充和完善WS-I基本概要。

基于安全令牌的信任

安全性令牌是提供端到端安全解决方案所必需的。这些安全性令牌必须在消息处理的参与者之间实现直接或间接共享。各参与者还必须确定断言的凭证是否可信。这些信任关系以安全性令牌的交换和代理为基础，并存在于已经确定的支持信任策略中。例如，某一代理的令牌有多少可信，是由系统管理员和他们确定的信任关系决定的。提供安全性令牌的服务五花八门。这是各种底层安全技术首先为Web服务所使用的领域。为了提供一种与安全技术无关的统一标准的解决方案，新协议是为信任域之间的安全性令牌交换而设计的。

WS-Trust以用于请求、发出和代理安全性令牌的协议对WS-Security进行了补充。需要特别指出的是，其中定义了用于获取、发行、更新和验证安全性令牌的操作。该规范的另一个新特性是建立新信任关系的机制。IPsec或TLS/SSL之类的网络和传输保护机制可以与WS-Trust结合，以适应不同的安全性需求和情况。

安全性令牌可以直接从某一适当的发行者处申请获得，或者通过委托某一受信任的第三方来获取。令牌还可以出乎意料地获得。例如，令牌可以从某一安全权威机构发送到一个并未明确申请该令牌的某一方。为此，系统管理员要确定初始信任关系，如将某一给定服务指定为信任的根服务。这种方法类似于目前Web上用于自展安全性的方法。从该服务获得的所有令牌受信任的程度与受信任的根服务本身相同。例如，如果某根服务只有断言A和B得到信任，且某一消息包含断言A、B和C，则该消息中只有断言A和B得到信任。配置灵活性是通过信任关系授权提供的。为了处理在退回或发出安全性令牌之前需要各方之间的一个交换集的情况，定义了用于验证、协商和交换的方法。一种称为“challenge”的特殊形式的交换为某一方证明它拥有与某一令牌关联的密钥提供了一种方法。交换的其他类型包括传统的协议隧道。WS-Trust详细说明了如何扩展该规范，以支持更多的令牌交换协议，而不仅仅是所给出的这两个例子。

表示安全性断言的安全性令牌是由一个受信任根或一个通过一个授权链的根发行的。这些安全性断言用于验证消息符合正在施行的安全策略。它们还验证断言者的属性是通过签名来校验的。在代理的信任模式中，即由受信任的中介分配安全性令牌的模式中，签名可能不验证断言者的身份，而验证中介的身份。该中介可能只断言者的身份。

安全会话

用于消息身份验证和机密性的某些机制可能会耗用大量的资源。需要特别指出的是，许多加密技术都会显著消耗处理能力。当消息的安全性是逐一得到保证时，这些代价通常是无法避免的。不过，当两个Web服务进行许多消息的交换时，可以使用比WS-Security中定义的方法更为高效和健壮的消息机密性方法。这些方法是基于对称加密的，在保证消息会话的安全时应使用它们。

WS-SecureConversation在基于共享密钥（如对称加密）的两个通信方之间定义了一个安全上下文。在整个会话期内，安全上下文在各通信方之间始终是共享的。会话密钥由共享密钥派生而来，用于解密在会话中发送的单个消息。安全上下文在线表示为一个新的安全性令牌类型（即SCT ，Security Context Token）。

规范为建立安全会话各方之间的安全上下文定义了3种不同方法。第一种，由安全性令牌服务创建，且必须由会话发起方提取并传送。第二种，通信一方创建安全上下文并通过消息传递给另一方。第三种，通过协商和交换创建安全上下文。Web服务会选择最能满足其需要的方法。必要时可以对安全上下文进行修正。更新安全上下文的一个典型例子是延长安全上下文的截止时间。安全上下文令牌隐含或包含了一个共享密钥。该密钥用于签名、加密消息。当使用共享密钥时，通信各方可以选用不同的密钥派生模式。例如，可以派生出4个密钥，这样双方便可以使用单独的密钥来签名和加密消息。为了保证密钥未曾用过和保持高度的安全性，应使用后续的派生密钥。使用这种方法来保证会话的安全性是一种更好的选择。WS-SecureConversation规范定义了一种方法来指示给定消息正在使用哪些派生密钥。所有派生算法都是通过URI来识别的。

安全策略

WS-SecurityPolicy通过用一种符合WS-Policy的语言指定安全策略断言来完善WS-Security，其6种断言涉及安全性令牌、消息完整性、消息机密性、消息对SOAP中介的可见性、对安全Header的约束和消息寿命。例如，某一策略断言可能要求所有消息都使用某一权威机构提供的公钥来签名，或该身份验证要基于Kerberos票。

系统联盟

除了我们已经介绍的方法以外，应用程序安全性还需要更多的方法。例如，在某一信任域中有效的身份在其他信任域中很可能没有意义。要让不同信任域中的服务能够验证身份的有效性，就需要适当的机制。WS-Federation定义了一些机制，以支持身份、帐户、属性、身份验证和身份验证信息跨信任域的共享。利用这些机制，多个安全域可以通过在由多方参与的Web服务之间支持和代理身份、属性和身份验证的信任而结成联盟。该规范扩展了WS-Trust模型，使属性和笔名可以被整合到令牌发行机制中，从而形成一种多域身份映射机制。这些机制都支持单点登录、退出和笔名，并描述了专业服务对于属性和笔名的作用。

通过身份联盟，很多要求都可以得到满足。就拿将一名员工与其雇主关联起来的例子来说，公司A的Jane从OfficeSupplyStore.com进行采购，公司A和OfficeSupplyStore.com之间有一个采购合同。因为Jane的身份是与公司A关联的，所以可以让她来依据该合同来进行采购。第二个例子是将一个人映射到多个笔名。大家可能只知道Joe使用joe@companya.com工作。他还可能有其他身份，如joe_bloggs@hotmail.com和josephb@cornell.edu。通过身份联盟，系统可以确定这些身份都是同一个Joe。

Web服务联合安全架构中定义了两个一般的请求者（消息发送者）类：被动和智能（活动）。被动请求者是只使用HTTP且从来不发出安全性令牌的服务。智能请求者是能够发出包含诸如WS-Security和WS-Trust中所描述的那些安全性令牌的消息的服务。传统的基于HTTP的Web浏览器就是被动请求者的一个例子。定义这两种请求者的行为的概要规范现已开发出来。对于智能请求者，active请求者概要详细说明了单点登录、退出和笔名是如何通过使用SOAP消息而整合到Web服务安全模型中的。实际上，该概要描述了在智能请求者上下文中实现WS-联盟中所描述的模式的方法。它详细说明了各种安全性令牌的要求。作为这些安全性令牌要求中之一的一个例子，当不使用安全通道时，X.509证书的整个令牌必须包含权威机构的名称和签名。该概要还要求X.509令牌包含主题标识符，以唯一地识别授之以该令牌的主题。

发现（Discovery）

本节介绍Web服务架构中用于定位网络上Web服务和确定该服务可用性的功能组件：UDDI和WS-Discovery。Web服务发现是在没有人工干预的情况下实现服务连接自动化的关键。Web服务发现方法反映了计算机系统中查找信息的两个最常见方法：查看一个众所周知的目录，或将一个请求广播给所有可用的监听器。UDDI注册表就相当于该目录，发现协议用于广播请求。

目录（Directory）

通用描述发现和集成协议，即UDDI——Universal Description Discovery and Integration Protocol，指定了一个用于查询和更新Web服务信息通用目录协议。该目录包含关于服务提供商、它们所托管的服务以及这些服务所实施的协议的信息。该目录还提供了用于向任何注册信息添加元数据的方法。如果Web服务信息存储在众所周知的位置时，则可以使用UDDI目录方法。一旦找到目录，就可以发送一系列查询请求以获取想要的信息。UDDI目录位置通常是通过系统配置数据从带外（Out of Band）获得的。

对于如何部署UDDI注册表，Web服务提供商有很多不同的选择。部署方案不外乎3个类别：公共、企业外和企业内。为了支持公共部署，以Microsoft、IBM和SAP为首的一组供应商主持推出了UDDI企业注册表[UBR，UDDI Business Registry]。UBR是一个可跨多个主持企业复制的公共UDDI注册表，它既是基于Internet的Web服务资源，又是Web服务开发者的一个试验台。尽管目前公共UDDI实施已经受到了最大关注，但UDDI的早期采用者仍更倾向于使用企业外和企业内方法。在这两种部署情况下，企业要部署一个专用注册表，而且更严密地控制注册信息类型也是可能的。这些专用注册表可能只供一个企业使用，也可能供若干组业务合作伙伴使用。UDDI还为注册表间的复制和跨部署的信任联盟定义了协议。使用这些协议进一步增加了可用于实施者的部署方案数量。对于所有的部署方案，UDDI目录都包含了Web服务及其托管地的详细信息。UDDI目录项有3个主要部分——服务提供商、所提供的Web服务和实施绑定。其中的每一部分都逐渐提供有关Web服务的更详细信息。

大部分的一般信息都描述服务提供商。该信息不针对Web服务软件，而是针对直接负责该服务的开发者或实施者。服务提供商信息包括名称、地址、联系人及其他管理细节。所有的UDDI项都有多个元素来支持多语言描述。可用的Web服务列表存储在服务提供商项中。这些服务可能是根据它们的预定用途来组织的：它们可能被分成不同的应用领域、地区或任何其他适用的模式。存储在UDDI注册表中的服务信息只包含服务描述和一个指向它所包含的Web服务实施的指针。由其他提供商托管的服务链接称为‘服务映射（Service Projection）’，也可能被注册。

UDDI服务提供商实体的最后部分是实施绑定。该绑定将Web服务项与确切的URI关联起来，以确定在何处部署服务，它还指定了访问协议，并包含所实施的确切协议的参考资料。这些细节对于开发人员编写调用Web服务的应用程序已经足够。详细的协议定义的是通过一个称为“类型模型（即tModel，Type Model）”的UDDI 实体提供的。在许多情况下，tModel都会引用一个描述SOAP Web服务接口的WSDL文件描述，但tModel的灵活性也几乎可以描述任何种类的资源。对于在UDDI中注册的每一个提供商或服务来说，来自标准分类学（如NAICS和较古老的美国标准行业代码）或其他身份识别方案（如Edgar Central Index Key）的元数据都可用于分类信息和提高搜索准确性。可用的分类学和标识符方案集作为任何实施的一部分，是可轻松扩展的，因此可以对其进行定制以支持任何特定的地域、行业或企业需求。

动态发现（Dynamic Discovery）

动态Web服务发现是以不同方式提供的。作为在已知注册表中存储信息的另一种方案，动态发现的Web服务会明确地声明它们的到达、离开网络。WS-Discovery为通过多路广播消息来声明和发现Web服务定义了协议。当Web服务连接到网络时，它通过发送一条Hello消息来声明它的到达。在最简单的情况下，这些声明的跨网发送使用多路广播协议——我们称之为自组织网络。该方法还最大限度地减少了网络上的轮询需要。为了限制网络信息流通量和优化发现过程，系统可能会包含一个发现代理。发现代理用一个众所周知的服务位置取代了发送多路广播消息的需要，从而将自组织网络转变成托管网络。利用配置信息，代理服务集合可以连接在一起，从而将发现服务扩展到多组服务器，从一台机器扩展到多台机器。

因为发现代理自身也是Web服务，它们可能会用自己专用的Hello消息来声明它们的到场。接收该消息的Web服务然后可以利用该代理的服务，而无需再使用干扰较多的一对多发现协议。当服务离开网络时，WS-Discovery会指定一个Bye消息以发送给网络或发现代理。该消息通知网络上的其他服务离开的Web服务不再可用。

为了完善这种服务声明和离开的基本方法的不足，WS-Discovery定义了两个操作——Probe和Resolve，以定位网络上的Web服务。对于自组织网络，Probe消息被发送给多路广播组，并且与该请求匹配的目标服务会将响应直接反馈给请求者。对于利用发现代理的托管网络，Probe消息则以单路广播方式发送给发现代理。如果按名称定位Web服务，则使用Resolve消息。Resolve消息只以多路广播模式发送。Resolve 类似于地址解析协议，即ARP，它将IP地址转换成其对应的物理网络地址。WS-Discovery规范还支持这样的系统配置：将Probe消息发送给一个已经通过其他管理方法建立起来的发现代理，如通过使用众所周知的DHCP记录。

动态发现服务的能力实现了Web服务管理的自举。与WS-Eventing及其他协议相结合，更复杂的管理服务也可以通过使用这种动态发现基础架构来构建。动态发现还将Web服务架构扩展到设备，如那些目前可能实施通用即插即用（UPnP）协议的系统——这是使该架构真正实现通用的重要一步。例如，借助WS-Discovery和WS-Eventing，打印机或存储介质等设备可以作为Web服务纳入到系统中，而且无需专门的工具或协议。

Web服务设备概要规范
Web服务设备概要规范对在资源受限的设备上应该实施Web服务架构规范家族的哪个子集提供了指导。该概要力图在由于资源限制而作出折衷时，在可用的丰富功能和最重要的功能之间找到平衡。

一致性协议——可靠的消息传递和事务

本节介绍可以提供可靠的消息传送、事务行为和能够在一组Web服务之间进行显式协调的Web服务架构组件。定义这些功能的规范是WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity。

当多个Web服务必须完成工作的某一共同单元或依照某种共同的行为进行操作时，对于使用哪个协议必须达成共识。Web服务之间这种最低限度的协调是不可避免的。协调协议还必须能够确定并同意已达成一个共同目标。Web服务之间的每一个交互都可以看作一种协调。一致性协议为该架构提供了一个改进的机会，即参与者服务在它们准备共同完成的任务方面将获得成功。在传输丢失了消息和服务失常时，Web服务架构仍然能够正常工作。

任何多方协调都可以通过接连地随需加入更多参与者从两方协调逐步发展而成。两方协调可能是自发的，也可能需要一个指定的协调者。广泛使用的自发协调协议的一个例子是同步请求—响应消息传递模式。这是一致性协调的最简单形式之一；对于每个工作请求，接收方Web服务必须完成所有预期工作之后才能向请求者返回数据。双方都遵循这种严格的模式，无需显式协调服务。

可靠的消息传递

很多情形都可能中断两个服务之间的消息交换。当使用不可靠的传输协议（如HTTP 1.0和SMTP）来进行传输或当消息交换跨多个传输层连接时，这更会成为一个问题。消息可能会丢失、被复制或重新排序，Web服务可能会失败并失去易变状态。WS-ReliableMessaging是一个基于特定的传送保证特征实现可靠消息传送的协议。该规范定义了3个可结合使用的不同断言：

At-Least-Once Delivery（至少一次传送）：每条消息至少传送一次。
At-Most-Once Delivery（至多一次传送）：不传送重复的消息。
In-Order Delivery（依次传送）：按消息的发送顺序传送消息。

至少一次和至多一次保证相结合的结果是恰好进行一次传送。由于Web服务架构的设计与传输无关，因此所有传送都与所用的通信传输工具或其组合无关。由于开发人员必须预测的潜在传送失败模式数量减少，故使用WS-ReliableMessaging可以简化系统开发。

可靠的消息传送不需要显式协调者。当使用WS-ReliableMessaging时，参与者必须根据SOAP消息Header中所发送的信息识别协议。作为一个组传输的消息集合称为消息序列（Message Sequence）。消息序列可以由发起者/发送者或Web服务创建，当建立一种双向关联时通常由它们共同创建。序列是使用CreateSequence和CreateSequenceResponse消息显式创建的。当想要的最终结果是用两个单向序列来充当一个双向序列时，发起者将提供Web服务所要使用的序列。该序列的ID由发起者包含在CreateSequence消息中。

WS-ReliableMessaging中定义了几个策略断言。这些策略断言用WS-Policy中定义的方法来表示。

可靠的消息传递协议简化了开发人员为在传输不断变化的情况下传输消息而必须编写的代码。也就是说，底层基础架构可以对消息在端点之间的正常传输进行验证，必要时还会转发消息并检测重复。应用程序不需要任何附加逻辑来处理提供传送可能需要的消息转发、重复消息的消除、消息重新排序或消息确认。WS-ReliableMessaging的实施是跨发起者和服务分布的。那些非‘在线’可见的特征，如消息传送顺序，是通过实施WS-ReliableMessaging规范来提供的。虽然由传输损失导致的消息重发等特征是通过不为应用程序所知的消息传递层来处理的，其他端到端特征（如依次传送）都要求消息传递基础架构和接收应用程序相互协作。当发送者希望按发送顺序提供消息排序时，在接收者一方却按接收顺序提供消息排序的情况是依次传送的一种不正确实施——注意到这一点是很有趣的。当发送者希望按接收顺序提供消息顺序时，在接收者一方按发送顺序提供消息顺序的情况，是依次传送的一种正确实施。

指定的协调者

N路协调协议的某些族需要一个指定的协调者来引导一个工作单元通过一系列合作服务，一个例子是活动必须在不希望被同时连接的服务之间协调。只要每个参与者和协调者在某一时刻通信，协调就可能发生，结果就可能达成一致。Web服务架构为指定的协调者定义了某些简单操作。

WS-Coordination规范定义了一个可扩展的协调框架来支持需要显式协调者的情况。该协议引入了一个称为协调上下文（Coordination Context）的SOAP头块，用以唯一地识别联合工作中将要着手进行的部分。为了启动工作的接合部分，Web服务会向一个或多个目标服务发送协调上下文。收到协调上下文后，接收方服务会得到提示，说有联合协作请求提出。协调上下文中包含了足够的信息，请求接收者可以利用这些信息来确定是否参与该工作。协调上下文中包含的确切信息根据被请求工作的种类的不同而变化。

协调类型集是可扩充的。只要参与该联合工作的每个服务对所需行为都有个一般的了解，新类型就可以通过实施来定义。例如，原子事务是Web服务架构中已经定义了的几个初始基础协调类型之一。如果被请求的协调类型被理解并被接受，Web服务就会使用WS-Coordination注册协议来通知协调者并参与该联合工作。协调上下文中包含了协调者的一个端点引用和可能行为的可选标识符。注册操作指定该多方参与的Web服务所支持的行为。一旦注册消息发送到协调者，Web服务就会依照它们所预订的协议参与该工作。注册是协调框架中的关键操作，它允许意欲协同配合以完成工作的共同单元的不同Web服务相互连接在一起。

WS-AtomicTransaction为Web服务指定了传统的ACID事务，并为原子事务协调类型定义了3个协议：完成协议（Completion Protocol）和两阶段提交协议（Two-Phase Commit Protocol）的两个变体。完成协议用于启动提交处理。为完成而注册的Web服务能够通知指定的协调者何时开始提交处理。该协议还详细说明了用于通知启动者事务最终结果的消息。不过，该协议不要求协调者确保启动者对结果进行处理。相反，WS-AtomicTransaction中的其他行为则要求协调者确保参与者对协调消息进行处理。

两阶段提交（2PC）协议为所有已注册的参与者提供了一个公共的提交或中止决定，确保了所有参与者都能得到最终结果通知。顾名思义，它使用两轮通知来完成该事务。该协议的两个变体是：易失2PC（Volatile 2PC）和持久2PC（Durable 2PC）。这两个协议在线上使用相同的消息（对应于Prepare、Commit和Abort操作），但易失2PC没有持久性要求。易失2PC协议供管理易失资源的参与者使用，如缓存管理器或窗口管理器。这些参与者在第一轮通知中不与协调者发生联系，且不需要第二轮的通知。持久2PC协议供管理数据库和文件等持久资源的参与者使用。当某一提交处理已经启动时，在所有易失2PC参与者被联系过之后这些参与者会第一次被联系。这使缓存能够被刷新。持久2PC参与者需要完整的两轮通知来实现协调者所要求的全有或全无行为以及完成该事务。这些行为最适合于可以在整个事务期内持有资源，且该事务通常为非常短暂的事务的情况。该协议保证在正常处理的情况下，协调者提供第一阶段结果的同时将联系所有参与者。对于完成时间预计将比较长的事务，或当资源（如锁）无法持有时，其他协调协议就会定义替换行为。

WS-AtomicTransaction中定义了若干策略断言，这些策略断言使用WS-Policy中定义的方法来表示。

排队系统（Queued System）

构建分布式系统时被证明非常有用的一种模式是使用事务持久队列来提供存储转发异步消息传送。在这种模式下，原子事务被用于每一个传输端点。在发送端，发送应用程序以原子事务方式将消息发送给一个持久队列，此时应用程序和队列管理器都使用WS-AtomicTransaction来进行协调。只有在处理消息时不发生错误，消息才被认为成功发送至该队列。接下来，发送队列和接收队列之间消息的传送由队列子系统来接管。该传输步骤可以在消息置入发送队列之后的某一时刻完成。此外，发送队列的位置无需与发出消息的应用程序的位置一致。与此类似，从接收队列检索消息的应用程序也使用原子事务来执行类似操作。也就是说，只有不出现处理错误时消息才能从队列中移除。

持续时间长的活动（Long Duration Activities）

WS-BusinessActivity为运行时间长的事务指定了两个协议。WS-BusinessActivity规范在事务提交之前并不锁定资源，而是基于补偿操作。底层事务模型是所谓的开放嵌套事务。这些协议系统化地说明了松耦合服务如何对已经完成某一联合任务达成一致意见。在其中的一个协议中，协调者显式地通知参与者没有更多的工作正在以联合任务的名义被请求。在另一个协议中，该参与者就是通知协调者以联合任务名义出现的工作已经完成的参与者。使用补偿操作可以在不锁定这些操作的情况下完成试验性操作。不管出于何故，只要系统想要撤消已完成的试验性操作结果，就要启动补偿操作。WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination来管理Web服务之间的协作。

三方握手
三方握手连接的建立和解除协议是不需要指定协调者服务的协调协议的一个例子。为了建立连接，发送者要向接收者发送一个请求。该请求建立一个会话。如果该请求被接受，接收者就会发出一条确认消息，对该请求作出积极响应。发送者然后再发送一条消息，作为对该确认消息的确认，从而证明双方都知道对方已经建立了一个会话。

解除协议类似。一方向另一方发送一个会话解除请求。接收者以对解除消息的确认消息作为响应。接收到该确认消息之后，发出解除消息的一方通过再对该确认消息发送一条确认消息结束消息交换。

枚举、传输和事件

本节介绍提供Web服务架构中的服务资源枚举、其状态管理和事件通知的规范。这些规范基于WS-Enumeration、WS-Transfer和WS-Eventing。

枚举（Enumeration）

很多情况所要求的数据交换都使用不只一对的请求/响应消息。需要这些更长时间数据交换的应用类型包括数据库查询、数据流、命名空间等信息的遍历和枚举列表。特别是枚举，它是通过建立数据源和请求者之间的会话来实现的。会话中接连不断的消息用于传送正在被检索的元素的集合。对于该服务用于组织将要生成的项的方法不作假设。在正常处理的情况下，枚举应在会话结束前生成所有底层数据。

WS-Enumeration指定了用于建立枚举会话和检索数据序列的协议。枚举协议允许数据源向正在使用的服务提供一个叫做枚举上下文的会话抽象。该上下文通过一个数据项序列来表示逻辑光标。然后，请求者将该枚举上下文用于一个或多个SOAP消息的某一区间以请求数据。枚举数据表示为XML Infoset。该规范还允许数据源提供一种自定义机制来开始新的枚举。既然枚举会话可能需要若干个消息交换，那么会话状态必须保持稳定。

关于迭代进度的状态信息可以由数据源或正在使用的服务在请求间维护。WS-Enumeration允许数据源一个请求一个请求地决定哪一方将负责维护下一个请求的状态。这种灵活性实现了若干种优化。例如，使服务器能够避免对调用之间的任何光标状态进行保存。由于消息潜伏时间对于支持若干个同时枚举的服务来说可能会很长，不保存状态可能会使必须维护的信息总量大大减少。资源受限设备（如移动电话）上的服务实现可能根本无法维护任何状态信息。

传输（Transfer）

WS-Transfer详细说明了对通过Web服务进行访问的数据实体进行管理所需的基本操作。要了解WS-Transfer需要介绍两个新术语：工厂（Factory）和资源（Resource）。工厂是能够从其XML表示形式创建资源的Web服务。WS-Transfer引入了用于创建、更新、检索和删除资源的操作。应当注意，对于资源状态维护，宿主服务器最多也只能做到尽力而为。当客户端获知服务器接受了创建或更新某一资源的请求时，它可以适当地预期资源目前在的确定位置，并具有确定了的表示形式，但这并不是一个保证——即使是在没有任何第三方的情况下。服务器可能会更改某一资源的表示形式，可能会彻底删除某一资源，也可能会恢复已经删除的某一资源。这种保证的缺乏与Web提供的松耦合模型一致。如果需要，服务可以提供非Web服务架构所必需的附加保证。

WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中的只读操作功能。检索操作与WS-MetadataExchange中的Get操作完全相同。Create请求发送给工厂。然后，工厂创建被请求的资源并确定其初始表示形式。工厂被假定与所创建的资源不同。新资源被分配给一个在响应消息中返回的，由服务决定的端点引用。Put操作通过提供一种替换表示形式来更新资源。资源表示形式的一次性快照与WS-MetadataExchange中的Get操作一样，也可以通过WS-Transfer中的Get操作来检索。Delete操作成功后，资源将无法再通过端点引用来使用。这4个元数据管理操作构成了Web服务中状态管理的构建基础。

事件（Eventing）

在由需要相互通信的服务构成的系统中，可能会使用异步消息传递。在很多情况下，由一个服务生成的信息也是其他服务所需要的。由于伸缩性差，轮询往往不是获得这种信息的有效方法；通过网络发送的不必要的消息太多了。相反，该架构需要一种当事件发生时发出显式通知的机制。更重要的要求是源服务和用户服务的绑定必须在运行时动态完成。为此，Web服务架构提供了一个轻量级事件协议。

WS-Eventing详细说明了实现下面4个实体交互的机制：订户、订阅管理器、事件源和事件接收。这使某一Web服务在作为一个订户时能够登记它对另一个Web服务（事件源）所提供的特定事件的兴趣。这种注册叫做订阅。WS-Eventing定义了某一服务可以提供的支持订阅创建和管理的操作。当事件源判定有事件发生时，它就会将此信息提供给订阅管理器。订阅管理器然后可以将该事件传送给所有匹配的订阅，这类似于传统的发布/订阅事件通知系统中的发布主题。Web服务架构提供了主题定义、组织和发现方式的全面灵活性；它为在很多不同的应用场合中可能会用到的订阅提供了一个通用的管理基础架构。也可以订阅出租的资源，但最终都必须收回。用于收回资源的主要机制是各个订阅的到期时间。查询订阅状态同样也有一种机制，帮助订户管理其若干订阅事项（包括续订、通知和取消订阅的请求）的附加操作规范中也有详细说明。当然，任何服务都可以随时自由地终止订阅，这与所有Web服务的自主原则一致。订阅终止消息可供事件源通知订户订阅终止过早。

虽然基于事件的异步消息的一般模式很常见，但不同的应用通常都要求使用不同的事件传送机制。例如，在某些情况下简单异步消息可能是最佳选择，但如果事件接收能够通过轮询控制消息流和消息到达时间，则其他情况可能会更适用。当接收无法从源头到达目的地时，如接收有防火墙阻拦的情况下，轮询也是必要的。WS-Eventing中所引入的传送模式概念就是用来支持这些要求的。传送模式被用作一个扩展点，以便为订户、事件接收和事件源建立定制的传送机制提供一种手段。下述管理规范利用了这种机制。

事件代理可用于聚合或重新分配来自不同来源的通知，代理还可以用作独立的订阅管理器。这两个方法都得到了WS-Eventing的支持。代理在系统中可以扮演若干个重要角色。主题可以按特定的应用类来组织使用。代理可以充当通知聚集器，用于整合来自多个来源的事件信息。它们也可以充当过滤器，这比用于其自己通知的过滤器所接收的消息要多。这种灵活性是部署健壮而可伸缩的通知系统所必需的。

管理（Management）

管理功能是要讨论的Web服务架构的最后一个方面。这些功能在WS-Management规范中有详细的说明。WS-Management构建于该架构的若干组件之上，提供了所有系统管理解决方案都必需的一个公共操作集。其中包括发现管理资源存在及其相互导航的能力。个别管理资源（如设置和动态值）可以被检索、设置、创建和删除。容器和集合的内容，如大表和日志，可以被枚举。规范最后定义了事件订阅和特定的管理操作。在这些方面，WS-Management只详细说明了最低的实现要求。规范还使符合WS-Management的实现可以部署到小型设备。同时，它还支持向大型数据中心和分布式安装的扩展。此外，各种机制的定义都不依赖于任何暗示的数据模型或系统健康模型。这种独立性使它可以应用到各种各样的Web服务。

WS-Management要求托管资源的引用使用带有特定附加信息的端点引用。该信息包含了对该资源提供访问的代理的URL、该资源所属资源类型的唯一标识符URI以及识别该资源的零个或更多个密钥。这些密钥被假设为名称/值对。该信息是这样映射到WS-Addressing端点引用的：资源的URL映射到地址属性，资源类型标识符映射到一个名为ResourceURI（在适当的XML命名空间中）的特定引用属性，各密钥分别映射到一个名为Key、属性为Name的引用参数。为了满足管理服务的消息传递需要，规范为操作定义了3个限定符。这些限定符的SOAP表示位于header元素中。operation timeout指定了一个截止时间，之后操作将不需要接受服务；locale元素在需要或期望转换底层信息时使用；freshness限定符用于请求最新的值并避免返回陈旧数据。对于使用WS-Transfer操作的数据访问，WS-Management指定了另外3个限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定符允许传输简略表示形式。NoCache限定符要求传输最新数据，禁止信息缓存。对于Put和Create操作，ReturnResource限定符要求服务返回资源的新表示形式。ReturnResource使资源受限的Web服务能够在更新资源时不保留状态。

WS-Management为事件通知定义了3个自定义的传送模式：批、拉和捕获。这些模式都由URI来识别，这些URI在建立订阅时使用。批传送模式使订户能够接收捆绑在一个SOAP消息中的多个事件消息。订户可能还会要求捆绑某一最大数目的事件、服务收集事件可耗用的最长时间，以及应返回数据的最大量。拉传送模式使生成服务的数据能够维护事件的逻辑队列，以便订户能够按需轮询通知。该轮询是通过使用WS-Enumeration和返回时附带订阅响应消息的枚举上下文来完成的。最后，如果UDP多路广播是一种合适的消息传递方式，捕获传送模式便允许事件源使用它。在捕获模式下，事件源可以将其通知发送给某一预定义的UDP多路广播地址。

结束语

本文介绍了Web服务架构的功能构造块及其底层原理。每个构造块都是依据协议规范来阐述的。我们希望本文所述的功能范围和指导原则保持不变。不过我们也希望架构能够得到扩展，以支持更多情况。能够支持创新是该架构的基本特征。

已经进行的大量细致入微的工作可以确保各种Web服务协议能够不加变动地相互组合；尽管是一起设计的，它们仍可以以非常多的组合方式来使用。和功能构造块一样，它们的使用方式与传统开发框架类似。必要时，如对于SOAP附件，我们已经开发了新的解决方案，而且不加变动它们就可以很好地用于该架构内。关注组合不是对丰富功能的威慑。

该架构的SOAP消息传递基础保证了 foundation assures wide reach。SOAP消息传递以一种传输独立的方式支持异步和同步模式。具有更高灵活性的基础架构不存在。为了加快Web服务架构的广泛采用，很多技术合作伙伴都参与了这些规范的制定。与这些重要技术提供程序的合作加快了设备和支持这些在线协议的编程环境的部署。实现广泛覆盖、广泛采用和与规模无关的构造是我们的3个核心目标。我们力争确保该架构能够在任何平台上用任何编程语言来实现。该架构基于消息的和基于协议的特性为此提供了便利。必要时，如只使用WS-Security来支持消息完整性、机密性和身份验证，以及只使用WS-Policy来表示元数据时，我们已经限定了用于提高互操作水平的技术方法的使用领域。理论上讲，只要实现切实遵守该架构的协议规范，它们就能与其他任何Web服务通信。

附录A：术语表

活动请求者（Active Requestor）——活动请求者是能够发出如WS-Security和WS-Trust中所述的Web服务消息的应用程序（可能是Web浏览器）。

身份验证（Authentication）——验证安全凭证的过程。

授权（Authorization）——根据提供的安全凭证授权访问安全资源的过程。

规范化（Canonicalization）——将XML文档转换成符合每一方要求的格式的过程。在签名文档和解译签名时使用。

断言（Claim）——断言是对发送者、服务或其他资源（如名称、身份、密钥、组、特权、功能等）所作的陈述。

协调上下文（Coordination Context）——一组协调服务要完成的一组工作的唯一标识符。

反序列化（Deserialization）——从一个八位字节流构建XML Infoset的过程。它是用于从消息的有线格式创建消息的Infoset 表示形式的方法。

摘要（Digest）——摘要是八位字节流的加密校验和。

域（Domain）——安全域代表安全管理或信任的一个单元。

持久的两阶段提交（Durable Two Phase Commit）——用于文件或数据库等持久资源事务的协议。

有效策略（Effective Policy）——有效策略，针对某一给定的策略主题，是附加在包含该策略主题的策略范围上的策略组合。

交换模式（Exchange Pattern）——用于服务之间消息交换的模式。

工厂（Factory）——工厂是可以从XML表示形式创建资源的Web服务。

联盟（Federation）——联盟是已经建立相互信任的信任域的集合。信任级别可能变化，但通常都包括身份验证，并可能包括授权。

身份映射（Identity Mapping）——身份映射是创建身份属性之间关系的一种方法。某些身份提供程序可能会利用身份映射。

身份提供程序（IP，Identity Provider）——身份提供程序是为最终请求者提供身份验证服务的实体。身份提供程序还为服务提供程序提供数据源验证服务（这通常是安全性令牌服务的一种扩展）。

消息（Message）——消息是可由服务发送或接收的完整数据单元。它是信息交换的独立单元。无论何时消息都会包含SOAP信封，并有可能包含附加MTOM中指定的MIME部件、传输协议header。

消息路径（Message Path）——遍布在初始源和最终接收者之间的SOAP节点集。

被动请求者（Passive Requestor）——被动请求者是一个使用得到普遍支持的HTTP（如HTTP/1.1）的HTTP浏览器。

策略（Policy）——策略就是策略选项集。

策略选项（Policy Alternative）——策略选项就是策略断言集。

策略断言（Policy Assertion）——策略断言表示特定于域的单个要求、功能、其他属性或行为。

策略表达式（Policy Expression）——策略表达式是策略的XML Infoset表示形式，可以是正规形式，也可以是等同的压缩形式。

主体（Principal）——可以被授予安全权限或可以给出安全性或身份断言的任何系统实体。

协议组合（Protocol Composition）——协议组合是在保持技术连贯性的同时组合协议并避免任何非指定功能副作用的能力。

资源（Resource）——资源是可由端点引用寻址的任何实体，在该端点引用中，该实体可以提供其自身的XML表示形式。

安全上下文（Security Context）——安全上下文是一个抽象概念，指的是已建立的身份验证状态和可能具有与安全有关的附加属性的协商密钥。

安全上下文令牌（Security Context Token）——安全上下文令牌（SCT）是安全上下文抽象概念的有线表示形式，它使上下文能够被URI命名并和一起使用。

安全性令牌（Security Token）——安全性令牌用于表示一组断言的集合。

安全性令牌服务（Security Token Service）——安全性令牌服务（STS）发行安全性令牌的Web服务。更确切地说，它根据它所信任的证据来作出断言，并发送给信任它的任何一方（或特定接收者）。为了表明信任，服务需要证据（如签名），以证实安全性令牌或安全性令牌集提供的信息。服务本身可以生成令牌，也可以通过它自己的信任陈述依靠某一独立的STS发行安全性令牌（注意，对于某些安全性令牌格式，这只能是重新发行或联合签名）。这构成了信任代理的基础。

序列化（Serialization）——将XML Infoset表示为八位字节流的过程。它是用于创建消息的有线格式的方法。

服务（Service）——通过消息来与其他实体进行交互的软件实体。注意，服务不需要连接到网络。

签名（Signature）——签名是通过加密算法计算出来，并绑定到数据的一个值。而且经过绑定，数据的指定接收者可以使用该签名来验证数据没有改变并发自消息的签名者，从而提供了消息完整性和身份验证。签名的计算和验证可以通过对称或非对称密钥算法来进行。

退出（Sign-Out）——退出是这样一个过程：某主体表明它们将不再使用其令牌且该域中的服务可能会破坏该主体令牌缓存。

单点登录（SSO，Single Sign On）——单点登录是对身份验证序列的一种优化，旨在消除在请求者身上进行的反复操作负担。为了便于进行SSO，称为身份提供程序（Identity Provider）的元素能够以请求者的名义充当代理，将身份验证事件的证据提供给请求该请求者信息的第三方。这些身份提供程序（IP）是受信任的第三方，既需要得到请求者的信任（以维护请求者的身份信息，因为该信息的丢失可能会泄露请求者身份），又需要得到Web服务的信任，Web服务可能会根据该IP提供的身份信息的完整性提供对重要资源和信息的访问权。

SOAP中介（SOAP Intermediary）——SOAP中介是一个SOAP处理节点，它既不是原始消息发送者，也不是最终接收者。

对称密钥算法（Symmetric Key Algorithm）——一种加密算法，其中的消息加密和解密都使用相同的密钥。

系统（System）——实现某一特定功能的服务的集合。与分布式应用程序意思相同。

信任（Trust）——信任表示一个实体愿意依靠另一个实体来执行一组操作，对一组主题、范围作出一组断言。

信任域（Trust Domain）——信任域是一个得到有效管理的安全空间，在其中，请求的来源和目标可以确定来自某一来源的特定凭证集是否符合该目标的相关安全策略，并对此达成一致。目标可以将信任决定延期至第三方的加入（如果这已被确立为一致意见的一部分），从而将受信任的第三方包括在信任域中。

易失的两阶段提交（Volatile Two Phase Commit）——用于缓存或窗口管理器等易失资源事务的协议。

Web服务（Web Service）——Web服务是一种可重复使用的软件组件，它依据XML、SOAP和其他业界公认的标准通过网络实现交互式的消息交换。

附录B：XML Infoset信息项

XML文档可以包含11类信息项。下面，我们列出并详细说明了SOAP所支持的信息项，并简要介绍了其他的信息项。SOAP支持6类信息项：

文档（Document）：每个信息集里都有一个文档信息项。它用于引用所有的其他信息项。
元素（Element:）：文档中每个XML元素的信息集中都包含一个元素信息项。对所有元素的访问是通过对Child属性的递归跟踪提供的。
属性(Attribute)：文档中每个属性的信息集中都包含一个属性信息项。附加属性信息项用于命名空间。
命名空间(Namespace)：每个在其父元素范围内的名称空间信息集中都包含一个名称空间信息项。
字符(Character)：文档中每个数据字符的信息集中都包含一个字符信息项。
注释(Comment)：除了出现在DTD中的以外，文档中每个注释的信息集中都包含一个注释信息项。

SOAP不支持但出现在XML Infoset初始定义中的5类信息项是：处理指令(Processing Instruction)、文档类型声明(Document Type Declaration)、未扩展的实体引用(Unexpanded Entity Reference)、未解析实体(Unparsed Entity)和表示法(Notation)。

附录C：常见的安全攻击

对分布式系统的攻击可以分为若干个方面。它们可以指向系统中的一个或多个主机，或指向它们之间的通信网路。攻击的目的可能是中断操作、获得机密信息或在系统内部执行未授权的操作。它们可能会攻击系统中所使用的加密技术或以安全性为中心的其他技术，也可能企图通过攻击下面的系统和网络层或上面的应用层来旁路它们。以下是一个简短的不全面的安全性攻击类及针对每类攻击的标准对策的列表，它们是按上述的几个方面组织编排的：

对主机的攻击

拒绝服务（DoS，Denial-of-Service）攻击通过击垮主机的响应能力来中断其操作

当指向加密层时，DoS通常会尽力迫使主机反复执行特定身份验证或密钥交换协议所需的计算代价高昂的公钥操作。对抗这类攻击的典型防御措施是延迟公钥操作，直到对话者的合法性能够通过花费较少的方法（如对称加密或“谜语”）来验证时为止。DoS对底层网络层或顶层应用层的攻击很难预防，特别是在攻击者控制着大量资源且通信量处于正常通信量难以觉察的情况下。要实现网络基础架构的部署，通常必须通过漏斗方式将通信量降至一个可管理水平。

主机机密性或授权攻击企图泄露隐私或身份

这些攻击可能会利用主机软件中的薄弱点来获得对主机的控制。适当的安全性管理，如安装补丁、配置防火墙以及削减暴露应用程序的特权，是比较常用的对策。另一类攻击利用系统或应用程序中的弱点，如设置不正确的策略或应用程序逻辑错误，除了一般的主机泄密以外，它们还会考虑机密性或授权泄密。恰当的安全性策略管理和周密的应用程序设计是对付这类攻击的唯一防御措施。在“电子欺骗”攻击中，攻击者企图通过冒用某一经过授权的其他方的身份并做出相应的行为来获得对各种操作的授权。只要主机和经授权方切实保护好身份验证密码，并正确使用安全的身份验证协议，就可以预防电子欺骗。

对通信网路的攻击

DoS对网络的攻击试图中断与服务的通信

和对主机网络层的攻击一样，这些攻击确实也只能使用网络基础架构方法来应对。

对网络通信机密性的攻击企图在线泄露隐私

明文通信的直接监听可以通过加密来阻止。通过足够强大的加密算法和足够长的密钥，密码分析攻击也可以被扼制。

对网络通信授权的攻击企图泄露身份

攻击者企图将消息插入会话的“消息伪造攻击”和攻击者修改会话中发送的消息的消息，变更攻击都可以通过包含消息身份验证的消息安全性协议来阻止。攻击者将以前发送的（因而通过了正确的身份验证）消息插入会话的消息重放，攻击可以通过序号或时间戳和消息缓存的组合来检测和阻止。

BPM 2006-11-28 21:37 发表评论