本文讨论了电子商务中Web服务的关键技术，包括安全性、可靠消息传递、服务质量、管理、上下文支持等方面，强调了这些技术对支持现代商务流程的重要性。
虽然对于可互操作的 XML 消息传递来说 SOAP 和 HTTP 就足够了，而且 WSDL 也足可以传达服务请求者和服务提供者之间需要什么样的消息，但是要覆盖电子商务的全部需求还需要更多的技术。为了完全支持电子商务，安全性、可靠的消息传递、服务质量、Web 服务协议栈的每一层的管理都需要扩展。对 Web 服务基础设施的附加要求包括对服务上下文的支持、会话和活动、中介体、门户网站集成以及服务流管理。
这些机制为了提供可靠性和安全性而相互依赖清楚的说明了这两方面的考虑应当成为集成化策略的一部分。
  |
|
真的需要 Web 服务安全层吗？对于基于消息的体系结构，业界已经有一套现成的而且广泛接受的传输层安全机制，比如，安全套接字层（Secure Sockets Layer，SSL）和网际协议安全（Internet Protocol Security，IPSec），为什么还要再加别的呢？为了回答这个问题，我们不仅要研究要求，还将探讨一些只依靠现有的几类传输层安全机制并不能在 Web 服务模型内提供足够的安全性的情况。
通常，Web 服务安全层必须提供以下四个基本的安全性要求：
- 机密性（Confidentiality）是指信息对没有经过授权的个人、实体或进程的不可用性或不公开性，并保证消息内容不对没有经过授权的个人公开。
- 授权（Authorization）是指权限的授予，包括根据访问权限授予访问权和保证发送方被授权发送消息。
- 数据完整性（Data integrity）是指数据没有以未经授权的方式或被未经授权的用户不可察觉的改变或者破坏的性质，从而确保消息在传送的过程中不会被偶然或故意修改。
- 原始性证明（Proof of origin）是对消息或数据的发送者进行标识的证据。断言消息由正确标识的发送者传送，并且不会重新发送以前传送过的消息。这一要求隐含了数据完整性的要求。
由于需要在基于 XML 消息和工作流的动态 Web 服务世界中管理不同风格的资源访问，所以必须重新评估策略、信任和风险评估这三者相互之间的关系。现有的基于个人身份的访问控制模型正在发展成为基于角色的信任域关系，在该种关系中，可信任的权威机构将执行某项任务的权限授予个人，其行为受该权限限制。IBM Web 服务体系结构定义了需要信息的代理（服务请求者）、提供信息的代理（服务提供者），有时还有提供关于信息的信息的代理（服务中介者、元信息提供者或服务注册中心）。服务中介者经常会收到大量信息请求，这样就需要它能够决定谁想要哪些信息以及请求者是不是已经被授予访问权。基础设施和关系变化迅速，因此有关的策略需要能灵活的允许或拒绝访问。
此外，尽管 XML 发誓要为这样的服务提供通用接口，但 XML 不会提供实现这一梦想所需要的整个基础设施。而且，XML 可能不适合构建整个 Web 服务安全层。目标是要确定在哪些场合用 XML 格式提供信息以顾及通用数据交换较为重要，以及在哪些场合利用目前已存在于平台之上的现有安全性机制较为重要。
SOAP 信封是用 XML 定义的，从而使您可以向消息添加种类众多的元信息，比如事务 ID、消息路由信息和消息安全性。SOAP 信封由两个部分组成：头和主体。头是把功能添加到 SOAP 消息中的通用机制。SOAP 头元素下一级的所有子元素都叫做头条目。主体是为最终的消息接收方想要的应用数据（如 RPC）准备的容器。因此，可以把 SOAP 看作是在传输层（例如 HTTP）和应用层（例如，业务数据）之间引入的另外一层，在此可以方便的传送消息元信息。SOAP 头提供可扩展机制以扩展 SOAP 消息使其可以适用于多种用途。虽然 SOAP 头是向消息添加安全性功能最合理的地方，但是 SOAP 规范本身并没有指定这样的头元素。
让我们仔细的分析一下在 Web 服务模型中现有的各种各样的传输层安全机制为什么不够，又为什么会需要 Web 服务安全层，以及这个安全层最初是怎样的。
端对端的消息传递。安全传输协议，如 SSL 和 IPSec，可以在传输过程中提供消息完整性和机密性，但只有在点对点的情况下，它们才会这样做。但是，因为 SOAP 消息是由中介体接收并处理的，所以即便两两之间的通信链路（communication link）是可信任的，只要在所有的中介体间没有信任关联（trust association），那么安全的端对端通信就是不可能的。如果有一条通信链路不安全，那么端对端安全性也会被削弱。就 Web 服务拓扑来看，安全的传输对于 SOAP 消息的端对端安全性是不够的。
中间件的独立性。最终，唯一能提供端对端安全性的方式就在于应用层或中间件层。如果消息在通信方之间的某点是纯文本，那么就有可能在这点受到攻击。但是，既要在新的或现有的应用中集成加密功能，又不能引入额外的安全性弱点或增加风险，这是一项不容易又不受欢迎的任务。因此，在大多数情况下，人们希望安全性功能尽可能靠近应用，但不在应用本身中构建。
传输的独立性。SOAP 中介体的原意是用来把信息转发到不同的网络上去，通常使用的传输协议也会有所不同。虽然所有的通信链路都是安全的，中介体也是值得信赖的，但是，安全信息（如消息发送者的身份验证）需要被转移到消息路径上的下一个传输协议安全性域，这个过程冗长而且复杂，还可能会导致完整性方面的缺陷。
异步多阶消息传递。传输层安全性保证数据在通信链路上传输时的安全。它与存储在任何中介体上的数据都无关。在一次传输被接收并解密后，传输层安全性对保护数据免受没有经过授权的访问和可能的改变就不是很有帮助了。在先存储消息然后转发的情况下（持久的消息队列），消息层保护是有必要的。
因为我们已经看到安全的传输机制不足以满足 Web 服务开发方法和使用场景的要求，所以我们的任务就是要创建一个概念性 Web 安全层，包括下列几个组件：
- 对于网络安全性：
- 支持如 SSL 和 HTTPS 等提供机密性和完整性的安全传输机制。
- 对于 XML 消息：
- 如果通信没有中间节点，那么发送方可以依靠 SSL 或 HTTPS 来保证用户标识和密码的机密性。
- W3C 正在标准化 XML 数字签名工作的支持。它定义了生成消息摘要与利用发送方的私钥来签发消息的标准 SOAP 头和算法。因此，接收方就可以证明消息发送方的身份。
- 对网络内部的、可信任的第三方验证服务（例如 Kerberos）的支持。
概念性 XML 消息传递模型还必须支持端对端保护消息及其子元素。为了全面的支持，过程和流能力需要被扩展到包括消息交换的安全性特征。应该有一种方式可以定义多段消息和用预期接收方的公钥来保护消息段。需要探讨的一些论题有：
- 端点负责实现验证及授权。应该支持在企业之间交换信息的合同的任何描述中都要定义哪些雇员可以使用哪些服务。中介体负责审计和服务原始性证明。中介体还可能需要执行验证、授权和数字签名验证以及有效性检查。
- 在服务端点的服务描述层中需要定义支持上文论述的安全性问题的面向安全性元数据。这些安全性描述将根据主体或角色定义 Web 服务层访问控制。服务描述将会描述是否支持数字签名、加密、验证和授权以及如何支持它们。
- 请求者将使用服务描述的安全性元素来查找服务端点，该端点应符合政策要求及其安全性方法。
标准组正在调查如下主题和技术。随着这些标准固定下来，它们将会被并入 Web 服务安全性体系结构。
- W3C 有一个 XML 加密工作组，帮助提供数据元素的机密性，这样验证交换成为可能。
- W3C 已发布了一个 XML 密钥管理服务（XML Key Management Services，XKMS）的备忘录，来帮助分发及管理在端点之间进行安全的通信所需的密钥。
- OASIS 已经成立了一个技术委员会来定义授权和验证断言（Authorization and Authentication assertions，SAML）。这将帮助端点接受和决断访问控制权。
- OASIS 已经成立了一个技术委员会来标准化访问控制权的表达（XACML）。这将帮助端点能够以一致的方式解析 SAML 断言。
随着我们不断的研究 Web 服务模型中遇到的所有威胁和对策，Web 服务安全性体系结构也在不断发展着。
|
|
服务质量垂直塔提供与 Web 服务概念栈每一层有关的信息的规范。对于网络层，这将会暗示能使用各种级别的服务质量的网络。
由于需要通过网络进行可靠的消息传递，所以得根据在这一领域内发送高质量服务的能力来选择网络技术。可靠的消息传递指基础设施把消息一次发送（只发送一次）到预定目标或提供确定的事件（如果发送没能完成，也许会重新发送到源）的能力。结合网络层与 XML 消息传递将需要支持四个等级的消息传递服务质量：
1. 最佳努力：服务请求者发送消息，服务请求者和基础设施不尝试重发。
2. 至少一次：服务请求者提出请求，并一直重试直到它接收到确认为止。服务提供者重复消息处理不是问题，例如简单的查询处理。实现这可能意味着每个消息包含唯一的标识。服务请求者以自己确定的时间间隔重发没有得到确认的消息。服务提供者发出确认消息，为 RPC 响应消息，如果不能处理的话，就发送不能处理的消息异常。
3. 至多一次：这建立在最少一次情况的基础之上。服务请求者试着请求直到它得到回应。象现有的全局唯一标识符（universal unique identifier，UUID）这样的机制允许服务提供者抑制重复多次的请求，以确保请求不会被多次执行。例如，请求根据库存目录中的一个号码拿一件东西。
4. 刚好一次：服务请求者提出请求，请求已经执行的回应使其得到保证。刚好一次交换模式排除了重传请求的需要并且适应失效的情况。
可靠的消息传递通常是通过标准设计模式传送的，在该模式中，一件基础设施，有时叫做端点管理器，将会被用来在通信的每一端协调消息发送。在这种模式中，发送方通过同步请求把消息发给端点管理器。一旦发送到，发送方就可以得到保证，一定会把消息发送出去或引发确定的事件（例如超时）。端点管理器与其它资源管理器参与本地事务，在一次事务中不仅可以由端点管理器对消息进行排队，还有可能在数据库中记录业务过程步骤。应用程序应该指派端点管理器来负责发送消息或者检测发送失败的原因，它在网络传输层或 XML 消息传递层都可以起作用。
可靠的一次性消息发送的技术和目的都不会引起争议。但是，围绕如何在 SOAP 和 XML 的上下文中支持这项技术已经提出了重要的质疑。关键问题是：应不应该在 XML 消息层上定义必要的协议和消息格式，从而允许可靠的消息发送成为两端应用程序的责任，或者能不能在较低的层（如传输层上）定义协议和消息格式？
在没有支持可靠的消息传递的传输方式的情况下（即因特网），XML 消息传递层将需要在不可靠的基础设施之上支持这些服务质量。端点管理器将需要修改消息，而不是修改消息的传输信封，这样才能成功扮演其角色。应用程序和业务过程的定义将必须考虑所有可能的结果，如拒收消息或在可接受的时间长度内发送不出去。但是，这些定义还需要考虑在发送过程中发生的中间状态。向业务过程公开这些状态可能会大大增加其定义的复杂程度，但对于定义过程的业务分析师而言并无太大意义。在一些情况下，使用 XML 消息传递来发送可靠的消息传递格式可能会导致使用现有的这些传输毫无效率。最好能开发一种在因特网上使用的可靠的 HTTP 标准。
在有支持可靠的消息传递的传输方式的情况下（即在企业内部），它可以用于发送可靠的消息，而不是 XML 消息传递层（可能缺省为空实现）。端点管理器将会只修改传输信封，而不会修改 XML 消息。使用可靠的传输使应用程序和业务过程定义不需要知道或处理消息发送的中间状态。
需要在将来进行的几点补充：
- 因特网的 HTTP 需要加以改进才能提供可以在企业间使用的简单可靠的消息传递。这会带来额外的好处：不止 SOAP，许多种消息类型都可以采用可靠的消息传递。需要 XML 消息传递层处理可靠的消息传递的情况就会随之减少，促进不依赖于网络选择的应用程序开发。
- HTTP 上的 XML 消息传递层也需要处理发布和订阅、消息排序、发送时间限制、优先级和多点传送等等问题。
服务提供者对可靠的消息传递的质量和实现的支持情况将会在服务描述的绑定信息中定义。
服务实现层（例如，通过事务的或安全的 SOAP 绑定）的服务描述以及接口层（例如，从请求者开始等待来自提供者的响应之后最长经过多久）的其它服务描述中都会关系到服务质量（Quality of Service）信息。人们期待着开发出 WSDL 扩展或新的服务描述层来允许指定其它服务质量和功能的规范。
Web 服务层上的服务质量可以在服务合成和服务流中使用。在为流选择服务或提示流管理器该开始恢复或其它的流时，预期的执行时间、超时值、历史平均执行时间值都可以作为输入。服务描述栈的端点描述层和工作流描述层必须提供这一信息。
Web 服务的服务质量问题和解决方案仍然很紧迫。
|
|
随着 Web 服务成为商业运作的重要因素，就需要对其进行管理。在这种情况下，所谓管理是指专为应用程序定制的或从厂商那里买来的管理应用程序可以发现 Web 服务的基础设施、Web 服务、服务注册中心和 Web 服务应用程序存在性、可用性以及健康度。最令人满意的结果是管理系统还应当能够控制和配置基础设施及组件。
管理概念性 Web 服务栈各层的 Web 服务和 Web 服务模型组件必定是有可能的。对管理的需求可以分成两个集中的领域。第一个领域是用于实现 Web 服务的基础设施的可管理性。主要的考虑应当是确保可用性和提供服务描述、消息传递和网络的关键元素的性能。Web 服务基础设施提供者应当提供这一层上的系统管理。
企业对其自己的基础设施及管理拥有完全的自主权。但是，当企业在对等基础上相互作用时，就应当提供对网络层、XML 消息传递层、服务注册中心和 Web 服务实现的基本报告和恢复办法。此外，企业向其合伙人提供的管理接口应当是在服务层上操作的，而不是在相对低级的基础设施层上。合伙人应该能够访问到报告操作和请求处理的状态和健康度的接口，但不一定要理解企业如何管理其请求的细节。
对于网络层，现有的网络管理产品几乎支持目前所有的网络基础设施。这些产品应当用于管理企业内部的 Web 服务的网络基础设施。当企业相互作用时，就应该向其合伙人提供有关 Web 服务基础设施可用性的基本报告。影响 Web 服务基础设施可用性的网络可用性应作为因素之一写入报告。
在 XML 消息传递层，协议应该在企业内部由现有的基础设施管理工具来管理。在企业相互作用的情况下，每个站点都有必要提供协议的基本报告和恢复办法。例如，如果站点 A 支持会话，就该向站点 B 提供可用于查询活跃的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 会话以及强行回滚的接口。协议层需要正常的频道与协议和类似对等的控制接口。
管理的第二个方面是 Web 服务本身的可管理性。一些主要的考虑是性能、可用性、事件和使用量度，因为它们将为服务提供者市场收取所提供的服务使用费提供必要信息。
服务描述可以用于宣传可管理性特征和管理需求。这方面的约定正在开发之中。
服务注册中心的任何实现，不管是用于私人消费还是公共消费，都要求基础设施是可用的、发送承诺的服务质量并能够报告使用情况。这些系统管理元素对于成功采用 UDDI 是十分重要的。
对于 Web 服务应用程序组件来说，支持管理环境可能会大大增加应用程序的复杂性。由于 Web 服务必须易于开发，所以必须尽可能向开发者隐藏这样的复杂性。Web 服务的管理方式要使基础设施能自动提供量度、审计日志、启动和停止处理过程、事件通知和作为 Web 服务运行时的一部分（也就是说，起码是 SOAP 服务器）的其它管理功能。因为基础设施通过观察它所托管的组件的行为不可能收集到所有的信息，所以 Web 服务实现也许会需要向托管它的服务器提供基本的健康度和监督信息。
Web 服务基础设施应该为服务提供一种简单的方式以参与管理和利用管理基础设施。可管理的服务的 WSDL 文档的定义应当是 Web 服务能实现提供通过管理系统访问 Web 服务的管理信息的功能。这一接口可能包括的能力是获得配置和量度数据、更新配置及接收来自可管理的 Web 服务的事件。
Web 服务体系结构的平台独立性使它不适合套用任何一条 Web 服务管理标准。因此，需要有一种基于 Web 服务而且允许 Web 服务与管理系统通信的方法。为了达到这一目的，还应当定义由 WSDL 文档描述的、可接收来自可管理 Web 服务的事件以及量度更新的管理服务，并使其可用。管理服务的实现技术与 Web 服务无关。但是，对于基于 Java 技术的环境，Java 管理扩展（Java Management Extension，JMX）应该是合乎逻辑的而且厂商不可知的选择。通过使用 JMX 这样的开放标准，对现有的系统管理提供者来说，要把其目前所提供的产品扩展为包括 Web 服务关键元素的管理应该是很容易的。
Web 服务的管理体系结构仍在向前发展。
|
|
智能 Web 服务通常是指行为与其环境的当前状态保持一致的 Web 服务。在最好的情况下，这种行为应当自配置。尽管为智能应用程序写代码是 Web 服务提供者的职责，但是如果没有关于运行时环境当前状态和上下文的信息，那么要做到这一点会很困难。XML 消息传递层需要定义对传播 Web 服务调用的上下文信息的支持。上下文信息的一些示例如下：
- 执行应用程序的无线设备类型及其全球定位系统（Global Positioning System，GPS）坐标。
- 对定义用户偏好的一个或多个用户简档的引用。
- 相对于服务请求者的角度的当前时间和状况信息。
XML 消息传递层本身并不负责定义偏好与上下文的细节或模式。相反的，该模型需要一种能使上下文能以可扩展的方式流动和传播的手段，从而允许特定的行业、组织之类定义其上下文模式和语义。
|
|
就不严密的意义而言，事务是应用程序处理方面最基本的概念之一。由于多种原因，Web 服务模型要求其控制请求和结果的机制比传统的分布式和数据库事务模型通常所提供的更灵活。Web 服务模型与事务处理监督编程模型之间的一些具体区别有：
- 多个企业之间的 Web 服务的合作通常依靠异步消息传递。尽管这个模型还会在传统的、企业内部的应用程序中出现，但分布式事务却不会在消息传递系统之间出现。相反，这些应用程序假设的是一种连锁的多事务模型。
- 跨企业的应用程序本身要进行多段控制。在处理传统事务的过程中，基础设施将把资源分配给正在执行的事务（数据库锁、线程等等）。企业依靠复杂的监督与管理工具来确保事务处理过程不会把停止和拒绝服务故障引入其基础设施。至于向综合企业提供类似的支持，动态绑定环境虽然在理论上是有可能的，但却是不切实际的。
- 在线事务处理和数据库系统将优化执行高容量、持续时间较短的事务和会话。通常多个企业之间的 Web 服务的合作持续时间要比事务和数据库应用程序长得多。
不能只是把现有的事务模型扩展到 Web 上去，还需要一种能增加事务性服务质量的方法：
- 核心的活动服务（Activity Service）是需要的，它包括一个一般性的功能，它将用于指定请求（或请求序列）的操作上下文、控制活动的持续时间长短以及定义参与结果决策的参与者。这种服务的例子在 OMG 扩展结构机制（OMG Extended Structuring Mechanism）是具有代表性的，在活动服务 JSR 的 Java 中将采用这一机制。
- 会话服务（Conversation Service）是需要的，它提供了为了 Web 服务使用活动服务而需要构造的会话样式和行为。这些基本的样式有：
- 在请求原子性（Request Atomicity）之下有 Web 服务上的单一操作，它要么全部发生，要么根本不发生。这是端点管理器向用户发布的一项功能。端点管理器通过其基础设施上的内部事务或某种别的机制实现发布。
- 会话允许有合作关系的服务使在一个不严格的工作单位内的请求序列相关联。
- 这对服务使用架构化的会话消息和头来开始和结束会话。它们决定会话是否成功结束，或者是否有一方或双方参与者想要回滚会话。回滚的语义是每个参与者都将撤消它在本次会话中执行的操作。
这些样式或行为机制绝对不是完整的。但是，它们允许参与 Web 服务的站点对其现有实现进行补充以支持更复杂的处理过程和补偿性模型。站点可以构建在其内部事务和业务逻辑环境的基础上，以提供更大的灵活性。此外，活动服务还考虑到了超出传统事务性模型之外的其它运作模式。
目前对 Web 服务的唯一要求是使两个端点结果保持一致的结果的能力。在使用自己内部的事务和工作流模型来管理与多个参与者的操作和会话的企业里就会发生多方事务处理过程。
|
|
Web 服务可以提供的改进就是对中介体的支持。中介体是指在调用期间把自己巧妙的插入服务请求者和服务提供者之间的组件（它本身很可能就是 Web 服务）。从字面上来看，中介体为 Web 服务调用充当媒介。中介体的一个示例是为服务调用打上时间戳并记入日志的第三方公证站点。中介体可以用于支持不可抵赖性。
图 9. 中介体
中介体可能会被置于请求与响应消息流的执行路径上。在请求和响应期间都可以调用中介体（如图 9 中的 I1 的情况）。I1 可以是第三方服务质量（Quality of Service，QoS）监督者或审计 － 跟踪中介体。某些中介体只能要么在请求消息流，要么在响应消息流上被调用，如上面的 I2 和 I3。I2 可以是不可抵赖的中介体，而 I3 可以是记录响应时间日志的中介体。定义消息路径上的中介体集合的规范还在定义之中。
中介体将由 SOAP 的 AXIS 实现支持，它可以在 Apache 站点上找到该实现。发布服务的服务提供者可以指定这个服务支持哪些中介体，这些中介体所提供的服务及其标识。由于能够根据接口类型或实现类型搜索并查看服务描述，从而可以为站点 A 提供必要的元数据以研究站点 B 支持的服务中介体链。不可抵赖性服务和开账单与支付服务可以作为中介体链上的一些示例。中介体将提供端点认可的服务质量，例如“刚好一次”语义。在开账单和支付的情景中，如果能确保每个端点刚好调用一次，那么您会很高兴的看到，在您的账单上为了那次调用只有一笔要支付款项。
站点 B 可以指定工作流图，它会定义需要的中介体的先后次序。当站点 A 要向站点 B 解析服务时，工作流图就会声明，对 B 上的服务的调用在调用流的入口节点上的服务时才会发生，所以结果会是中介体处理完消息之后，最终服务才会在 B 上发生。流的定义还将指定必须封住哪些数据以便发送给链中的哪些中介体。
SOAP 中并没有很好的定义 XML 消息传递层上的中介体的实际表达，而且目前还是 XML 协议工作组（XML Protocol Working Group）内部争论的主题。
|
|
门户网站通常用于使人们可以访问浓缩形式的信息和应用程序。门户网站通常会把来自各种来源的个性化信息显示在一个页面里，从而允许用户高效的读取信息而不是一个接一个去访问各种各样的 Web 站点。根据可定制的用户设置，通常显示信息的矩形区域就是包括在该页面内的各种 portlet。
随着 Web 服务逐渐成为通过编程的方法使信息和应用程序在因特网上可用的占统治地位的方式，门户网站及其开发工具需要考虑集成作为数据源的 Web 服务。图 10 说明了在门户网站、portlet 服务和 Web 服务之间的一些常见的数据流。
最初的两个集成 Web 服务和 portlet 的地点是：使用 Web 服务作为后端的 portlet 以及作为 Web 服务被描述、包装并发布的 portlet。第一种情况，也是最主要的情况的示例是，允许用户配置要跟踪的新闻分类，并从 Web 服务上实时的接收属于这些分类的新闻。在这种情况下，portlet 代码是在门户网站的本地运行的，并利用 Web 服务来访问信息。内容的处理是由 portlet 自己完成的。
图 10. 门户网站和 portlet
门户网站利用 Web 服务的第二种情况的示例是，允许同其它门户网站共享 portlet。在这种情况下，另外一个门户网站作为远程服务器把 portlet 作为远程 portlet Web 服务发布到 Web 服务目录中。从而门户网站就可以在该目录中查找远程 portlet 服务并同其建立绑定。因而，不需要在门户网站自身本地安装 portlet 代码，门户网站的用户就可以利用远程 portlet 了。
随着这些技术的成熟，其它的集成 Web 服务和门户网站技术的机遇也将出现。
扫一扫
2759
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
