|
Web服务概念性体系结构（WSCA 1.0 第3部分）广告 Web 服务概念性体系结构（WSCA 1.0 第3部分）
本文分别从组件、相互作用和应用程序开发模式的角度描述了 Web 服务的体系结构。这个体系结构就是 IBM 对 Web
服务方法实例化的蓝图。这是构建和部署 Web 服务应用程序的框架。 真正的电子商务的 Web 服务 这些机制为了提供可靠性和安全性而相互依赖清楚的说明了这两方面的考虑应当成为集成化策略的一部分。 安全性 通常，Web 服务安全层必须提供以下四个基本的安全性要求： 机密性（Confidentiality）是指信息对没有经过授权的个人、实体或进程的不可用性或不公开性，并保证消息内容不对没有经过授权的个人公开。
由于需要在基于 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 安全层，包括下列几个组件： 对于网络安全性： 概念性 XML 消息传递模型还必须支持端对端保护消息及其子元素。为了全面的支持，过程和流能力需要被扩展到包括消息交换的安全性特征。应该有一种方式可以定义多段消息和用预期接收方的公钥来保护消息段。需要探讨的一些论题有： 端点负责实现验证及授权。应该支持在企业之间交换信息的合同的任何描述中都要定义哪些雇员可以使用哪些服务。中介体负责审计和服务原始性证明。中介体还可能需要执行验证、授权和数字签名验证以及有效性检查。
标准组正在调查如下主题和技术。随着这些标准固定下来，它们将会被并入 Web 服务安全性体系结构。 W3C 有一个 XML 加密工作组，帮助提供数据元素的机密性，这样验证交换成为可能。 随着我们不断的研究 Web 服务模型中遇到的所有威胁和对策，Web 服务安全性体系结构也在不断发展着。 服务质量和可靠的消息传递 由于需要通过网络进行可靠的消息传递，所以得根据在这一领域内发送高质量服务的能力来选择网络技术。可靠的消息传递指基础设施把消息一次发送（只发送一次）到预定目标或提供确定的事件（如果发送没能完成，也许会重新发送到源）的能力。结合网络层与 XML 消息传递将需要支持四个等级的消息传递服务质量： 1. 最佳努力：服务请求者发送消息，服务请求者和基础设施不尝试重发。 2. 至少一次：服务请求者提出请求，并一直重试直到它接收到确认为止。服务提供者重复消息处理不是问题，例如简单的查询处理。实现这可能意味着每个消息包含唯一的标识。服务请求者以自己确定的时间间隔重发没有得到确认的消息。服务提供者发出确认消息，为 RPC 响应消息，如果不能处理的话，就发送不能处理的消息异常。 3. 至多一次：这建立在最少一次情况的基础之上。服务请求者试着请求直到它得到回应。象现有的全局唯一标识符（universal unique identifier，UUID）这样的机制允许服务提供者抑制重复多次的请求，以确保请求不会被多次执行。例如，请求根据库存目录中的一个号码拿一件东西。 4. 刚好一次：服务请求者提出请求，请求已经执行的回应使其得到保证。刚好一次交换模式排除了重传请求的需要并且适应失效的情况。 可靠的消息传递通常是通过标准设计模式传送的，在该模式中，一件基础设施，有时叫做端点管理器，将会被用来在通信的每一端协调消息发送。在这种模式中，发送方通过同步请求把消息发给端点管理器。一旦发送到，发送方就可以得到保证，一定会把消息发送出去或引发确定的事件（例如超时）。端点管理器与其它资源管理器参与本地事务，在一次事务中不仅可以由端点管理器对消息进行排队，还有可能在数据库中记录业务过程步骤。应用程序应该指派端点管理器来负责发送消息或者检测发送失败的原因，它在网络传输层或 XML 消息传递层都可以起作用。 可靠的一次性消息发送的技术和目的都不会引起争议。但是，围绕如何在 SOAP 和 XML 的上下文中支持这项技术已经提出了重要的质疑。关键问题是：应不应该在 XML 消息层上定义必要的协议和消息格式，从而允许可靠的消息发送成为两端应用程序的责任，或者能不能在较低的层（如传输层上）定义协议和消息格式？ 在没有支持可靠的消息传递的传输方式的情况下（即因特网），XML 消息传递层将需要在不可靠的基础设施之上支持这些服务质量。端点管理器将需要修改消息，而不是修改消息的传输信封，这样才能成功扮演其角色。应用程序和业务过程的定义将必须考虑所有可能的结果，如拒收消息或在可接受的时间长度内发送不出去。但是，这些定义还需要考虑在发送过程中发生的中间状态。向业务过程公开这些状态可能会大大增加其定义的复杂程度，但对于定义过程的业务分析师而言并无太大意义。在一些情况下，使用 XML 消息传递来发送可靠的消息传递格式可能会导致使用现有的这些传输毫无效率。最好能开发一种在因特网上使用的可靠的 HTTP 标准。 在有支持可靠的消息传递的传输方式的情况下（即在企业内部），它可以用于发送可靠的消息，而不是 XML 消息传递层（可能缺省为空实现）。端点管理器将会只修改传输信封，而不会修改 XML 消息。使用可靠的传输使应用程序和业务过程定义不需要知道或处理消息发送的中间状态。 需要在将来进行的几点补充： 因特网的 HTTP 需要加以改进才能提供可以在企业间使用的简单可靠的消息传递。这会带来额外的好处：不止
SOAP，许多种消息类型都可以采用可靠的消息传递。需要 XML 消息传递层处理可靠的消息传递的情况就会随之减少，促进不依赖于网络选择的应用程序开发。
服务提供者对可靠的消息传递的质量和实现的支持情况将会在服务描述的绑定信息中定义。 服务实现层（例如，通过事务的或安全的 SOAP 绑定）的服务描述以及接口层（例如，从请求者开始等待来自提供者的响应之后最长经过多久）的其它服务描述中都会关系到服务质量（Quality of Service）信息。人们期待着开发出 WSDL 扩展或新的服务描述层来允许指定其它服务质量和功能的规范。 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 服务的管理体系结构仍在向前发展。 服务上下文 执行应用程序的无线设备类型及其全球定位系统（Global Positioning System，GPS）坐标。
XML 消息传递层本身并不负责定义偏好与上下文的细节或模式。相反的，该模型需要一种能使上下文能以可扩展的方式流动和传播的手段，从而允许特定的行业、组织之类定义其上下文模式和语义。 会话与活动
多个企业之间的 Web
服务的合作通常依靠异步消息传递。尽管这个模型还会在传统的、企业内部的应用程序中出现，但分布式事务却不会在消息传递系统之间出现。相反，这些应用程序假设的是一种连锁的多事务模型。 不能只是把现有的事务模型扩展到 Web 上去，还需要一种能增加事务性服务质量的方法： 核心的活动服务（Activity
Service）是需要的，它包括一个一般性的功能，它将用于指定请求（或请求序列）的操作上下文、控制活动的持续时间长短以及定义参与结果决策的参与者。这种服务的例子在
OMG 扩展结构机制（OMG Extended Structuring Mechanism）是具有代表性的，在活动服务 JSR 的 Java 中将采用这一机制。
这些样式或行为机制绝对不是完整的。但是，它们允许参与 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）内部争论的主题。 门户网站和 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 服务和门户网站技术的机遇也将出现。 参考资料 Web 服务鉴定 ：Web 服务的推荐系统和反馈机制
浏览：Web 服务概念性体系结构（WSCA 1.0 第1部分） 如果您希望与本文章的作者或其所在机构，进一步交流，请联系：畅享网 姜小姐 jill.jiang@amt.com.cn | 021-51096826-112 | 在线联系 |
 CIO职场，强者生存？在2008年，我们将继续看到CIO向商业运营方向发展。与此同时，我们也会看到商业管理人员将与技术管理人员一起竞争CIO岗位。 IT领导者的就职机会虽有不少，但其难度将会大幅提高。2……  防震减灾，IT当关今天，任何的防震救灾体系，都离不开IT技术。地震观测台是数字化的，震害防御需要对以往的地震信息进行数据分析，应急救援要需要现代多样化的通讯技术。如果说，在许多行业，信息技术还只是一…… |
|
|