Web服务小组已经从原先的 WS-Resource Framework (WSRF) 标准迁移至 WS-ResourceTransfer (WS-RT) 框架。WS-RT 将原来 WSRF 标准的元素与 WS-Management 标准相结合，以便在不同组件之间更容易地交换资源信息和对象。我们将研究这两个标准，它们之间的区别，以及如何在这两个标准之间进行迁移 — 以照顾兼容性，并帮助您迁移至新的标准，同时保证与其他应用程序的互操作性。

　　简介

　　随着网络和分布式计算负载思想的成长，网格计算的概念和实现已经成熟。虽然对于不同的小组而言 “网格计算” 有不同的意义，但是它通常是指在一个结构化的、受管的系统中，异构资源通过网络的互操作和通信。实现网格基础设施的一个方法是使用基于 Web 的服务。WS-Resource Framework (WSRF) 就是面向基于 Web 的网格服务的一个实现。WSRF 与 WS-Notification (WSN) 规范一起，为基于 Web 服务的网格计算提供一个很好的起点。

　　几乎与此同时，一些竞争标准，例如 WS-Transfer，也正在被开发和部署。由于这些是竞争标准，彼此之间并不通信，因此将独立开发的网格资源连网的思想受到阻碍。

　　在 2005 年 3 月，WS-Transfer 和 WSRF 的开发人员宣布关于一个新规范的计划：WS-ResourceTransfer (WS-RT)。WS-RT 是 WS-Transfer 的扩展和增强，它增加了 WSRF 提供的、原来的 WS-Transfer 没有的功能。具体说来，WS-RT 增加了来自 WSRF 的 WS-ResourceProperties 和 Web Services ResourceLifetime (WS-ResourceLifetime) — 这两个组件的功能，这两个组件拥有 WS-Transfer 中不具备的某些详细的控制机制。

　　在本文中，我们将看看 WSRF — 尤其是 WS-ResourceProperties 和 WS-ResourceLifetime 提供了什么功能 — 而 WS-RT 又提供了什么功能，它们之间有什么重叠的地方，可以采取什么迁移策略从 WSRF 转移到 WS-RT。

　　WS-Resource Framework (WSRF)

　　WSRF 规范由 4 个主要组件组成：WS-ResourceProperties、 WS-ResourceLifetime、WS-ServiceGroup (WSRF-SG) 和 WS-BaseFaults (WSRF-BF)。在这些组件规范中，WS-ResourceProperties 和 WS-ResourceLifetime 是考虑迁移至 WS-ResourceLifetime 时要重点关心的。这两个组件主要处理资源对象的表示和访问。它们为 Web 服务与彼此资源之间的交互提供关键的规范。下面是对 WSRF 规范标准的每个组件的功能的简述。

　　但是首先，我们来看看 WS-ResourceProperties，它是本文关注的两个焦点之一。

　　WS-ResourceProperties

　　WS-ResourceProperties 处理与一个给定资源相关的属性和那个资源的特征。WS-ResourceProperties 规范文档对于服务如何在一个 Web 服务架构中提供资源属性的定义进行了标准化。通过使用这些规范，可以提供关于有什么可用资源以及如何通过 WSRF 访问这些资源的一个标准化视图。WS-ResourceProperties 提供了一组标准的消息，请求者可以使用这些消息来查询和更新一个发布的资源中的属性值。根据一个给定服务和资源定义了什么资源属性，这些消息被紧缩成一个个的子集。

　　WS-RT 使用了 WS-ResourceProperties 中的 get、put、create 和 destroy 语句的一些扩展的能力，以提供对资源文档的分段访问。后面会详细讨论这种分段访问。接下来，我们来看看 WS-ResourceLifetime，这是与 WS-RT 相关的两个 WSRF 规范中的第二个规范。

　　WS-Resource Lifetime

　　WS-ResourceLifetime 处理如何销毁（删除）一个给定的资源以及在一个资源的 “生命周期” 上加上什么约束。生命周期约束可以包括立即销毁资源或者安排定时销毁资源。生命周期约束放在 WS-ResourceProperties 中，因此可以查询这些约束。

　　WS-RT 在 WS-ResourceLifetime 规范的基础上为资源属性增加了生命周期约束的概念。与之前单独的 WS-Transfer 相比，这提供了对资源列表时间方面的更大的控制。

　　WS-SG 和 WS-BF 在这里稍微谈到了一点，但是它们对于我们讨论从 WSRF 到 WS-RT 的迁移并不是很重要。这两个规范都被核心规范所涵盖，因此从某种程度上说是多余的。

　　WS-Service Group (WSRF-SG)

　　WS-SG 虽然不是本文关注的焦点，但是它也是 WSRF 的一部分。WSRF-SG 主要处理异构的 Web 服务和资源的集合的创建。服务组由被称作 entries 的组件表示，这些组件本身也被当作是资源。从某种意义上说，服务组是顶级 WSRF 框架中提供的基于 WSRF 的多个资源的子分组。服务组可以包含用于组中收集的各个遵从 WSRF 的资源的大多数属性和对象。

　　WS-Base Faults (WSRF-BF)

　　WSRF-BF 是另一个本文不大关注的规范。WS-RT 提供出错方面的标准，它涵盖了原来的 WS-Transfer 规范，同时还包括对 WS-RT 的增强。WSRF-BF 提供一组标准的、简化的错误信息，通过报告这些错误信息，可以帮助解决 Web 服务中的问题。 WSRF-BF 还提供了扩展这些标准错误信息的规则，以及 Web 服务使用错误信息的基本用法。

　　至此，我们谈到了我们将关注 WSRF 的哪些领域，它们提供什么功能，新的 WS-RT 规范涵盖哪些功能，以及它与旧的 WSRF 规范有什么关系。

　　WS-ResourceTransfer (WS-RT)

　　WS-RT 是 WS-Transfer 的衍生物（因此也是后者的增强）。 WS-RT 的开发人员着眼于 WS-Transfer 和 WSRF，将 WSRF 中有而 WS-Transfer 中没有的功能增加到 WS-RT 中。通过这样做，他们还可以提供从这两个旧标准中的任何一个标准迁移至新的 WS-RT 时所需的基础。 由于 WS-RT 只是 WS-Transfer 的一个增强，因此 WS-Transfer 的功能原封不动地保留下来。虽然没有与 WSRF 完全匹配的操作，但是 WS-RT 中的确存在用于转换那些操作的功能。

　　WS-RT 规范包括资源的定义，以及如何访问那些信息。它提供了关于如何提供存储资源、计算资源或其他资源以及与那些资源相关联的时间约束的细节。除了 WS-Transfer 中原先提供的对于资源的 get、put、create 和 delete 操作外，WS-RT 还进行了扩展，增加了 “分段访问” 功能。分段访问允许一个操作访问整个 XML 资源表示的一小部分。这是 WSRF 中提供的、WS-Transfer 中没有的功能。对于包含类似于 WS-ResourceLifetime 规范中定义的信息的生命周期元素，也重新提供了元数据支持。

　　有了 WSRF 和 WS-RT 规范的这些基础知识之后，现在可以看看两种可能的迁移技术，这两种技术可用于支持迁移至新的 WS-RT 框架。

　　从 WSRF 迁移至 WS-RT

　　有两种主要方法可用于从 WSRF 迁移至 WS-RT。第一种方法是通过委托提供对 WSRF 和 WS-RT 的访问。第二种方法是使用 XSLT 直接在 WSRF 和 WS-RT 之间进行转换。在下面的小节中，我将详细谈到如何实现这两种方法。要获得更多信息，请参阅 参考资料。

　　通过委托实现双服务

　　在这种环境中，可以同时运行基于 WSRF 和基于 WS-RT 的服务，因为 WS-RT 操作几乎可以完全映射为对应的 WSRF 操作。在图 1 中，可以看到关于这种设置的一个简图。

　　图 1. 委托的迁移设置的例子

　　可以看到 WSRF 客户机如何继续使用已有的 WSRF 服务。WS-RT 客户机将使用服务器提供的 WS-RT 服务，这些服务在服务器中被映射到 WSRF 操作服务。这使得服务器在过度期间可以同时为 WS-RT 和 WSRF 客户机提供服务。为了今后进一步的开发，建议允许以一种通用方式定义核心资源，使应用程序栈可以将核心资源提供给 WSRF。这样以来，当以后准备逐渐淘汰旧的 WSRF 客户机时，最终可以允许 WS-RT 服务直接与资源交互，而不必重组核心资源。Apache Muse提供了关于这种方法的一个很好的例子。在项目的预览树中，可以看到 WS-RT 委托的一个参考实现。

　　在这种过度期间，发布的属性和操作会有一些冗余。这时会同时发布 WSRF 和 WS-RT，并且各具不同的规格，例如 wsrl:Destroy() （来自 WSRF）和 ws-t:Delete()（来自 WS-RT），它们提供类似的功能，但是用于不同的客户机。由于客户机只迁移至 WS-RT，因此最终可以消除发布的特定于 WSRF 的项。

　　这种方法的缺点是，如果服务没有提供委托模型，则必须在服务引擎中编写一个委托层。如果引擎支持委托模型，那么只需将该模型添加到已有的服务中。

　　通过 XSLT 转换服务

　　另一种迁移方法是使用 XSLT。虽然 XSLT 只转换 WS-Transfer，但是不管 Web 服务是 WSRF 服务器还是 WS-RT 服务器，都可以为 WSRF 和 WS-RT 客户机提供服务。图 2 展示了如何设置这种转换。

　　图 2. XSLT 转换设置的例子

　　如上图所示，通过使用 XSLT 来转换服务请求，可以维护当前的 WSRF Web 服务，同时允许迁移至新的基于 WS-RT 的客户机。 WSRF 客户机可以不用转换而横穿 XSLT 层。WS-RT 客户机通过到 WSRF 的 XML-to-XML 转换 横穿 XSLT 层。反过来，也可以提供从 WSRF 客户机到 WS-RT Web 服务的转换。

　　这种方法有两个主要的缺点。首先，必须编写一个转换层和服务，以提供客户机与 Web 服务之间的 XSLT 转换。其次，对于何时可以应用这种方法有一定的限制。 XML-to-XML 转换要求对于给定的转换，两个规范（WS-RT 和 WSRF）中存在直接的 1:1 映射。

　　结束语

　　我们首先对 WS-ResourceTransfer (WS-RT) 和相关的 WS-Resource Framework (WSRF) 规范作了简述，为研究规划迁移策略时涉及到的问题作准备。然后，我们谈到了从 WSRF 迁移至 WS-RT 的两种可能的策略。这两种策略是 XSLT 转换和委托，它们为最可能出现的迁移情况提供了方法。虽然这两种方法都不能解决所有情况，但是通过研究个人的需要和将来的计划，其中一种方法或者这两种方法的组合应该可以帮助您顺利过渡到基于 WS-RT 的 Web 服务。