级别： 初级 Thomas Myer (tom@tripledogdaremedia.com), 负责人
2004 年 7 月 01 日 WS-Resource Framework（Web 服务资源架构）提出另一种在基于开放标准的网格中实现状态建模与管理的不同方法。
简介
在本
专栏的前三篇文章中，我向您介绍了全球网格论坛（GGF），并粗略谈及 GGF 体系结构和 GGF Data 领域的一些内幕。这次我们要说说其他一些事情：关于更改网格处理状态的方式的建议，总称 Web 服务资源框架（WS-Resource Framework，或 WSRF）。
为什么状态如此重要？
在详细了解 WSRF 之前，很多开发人员都会挠挠头，想不通这有什么好大惊小怪的。那么为什么状态如此重要呢？
如果您曾长期从事 Web 技术的工作，您就会知道，不论何时处理 HTTP ，实质上您面对的都是一种无状态的协议。每发送一次请求，您都会得到一个响应。仅此而已。服务器不知道某个特定的请求是您发出的第一个、第二十个、还是第五百万个请求。即使某个特定的请求是一长串请求当中的一个，需要按照顺序进行处理，服务器对此也一无所知。
您曾经学过，若需向应用程序中加入状态信息，则必须在 HTTP 协议之外结合其他工具，如数据库、XML 文件、cookie、和会话处理机制等，这样才能实现目标。Web 上最著名的（也是用得最多的）有状态应用程序的例子就是购物车。通过 cookie 或服务器端会话软件，这种应用程序可跟踪购物车中加入添加或者删除了哪些物品。浏览不同页面时的数据值被存储起来，这些数据值甚至随着交互的增加而逐渐增加（比如说，向购物车中添加的物品越多，总价格就会随之上涨）。许多 extranet、intranet和门户网站都依赖数据库记录与 cookie/会话信息的结合来控制什么人能看到什么信息，以及何时将某个人踢出系统，诸如此类。
当然，您怎么评价无状态 HTTP 的这个特点都可以。比如说，您可以说 HTTP 的无状态性非常非常糟糕，因为每一个需要使用状态信息的人都要在应用程序中加入其他功能，而这些功能原本是可以在内部处理的。且不要说您处理状态的方式和我处理状态的方式不同，对应用程序而言，根本没有什么简单的方法可以发现其他应用程序正在做的事情。
从另一方面（也是很重要的一方面）来看，有状态意味着在进行任何操作之前都必须花费很多的代价。要想关闭一个有状态的应用程序并重新启动它，可能非常困难。我们该如何处理成千上万个处于处理过程中不同阶段的用户呢？
因此，HTTP 是无状态的。当 Web 服务出现的时候，也是无状态的。引入状态（或者说引入安全性）的唯一方法是在信封中插入一个记号或其他的标识。大多数 Web 服务专家都认为这种方法不错，但是您可以想象到，在各个阶层的人中还是有相当多的反对声音。
接着出现了网格技术，特别是开放网格服务基础设施（OGSI）。GGF 激发了 OGSI 的发展，为人们提供了基于开放标准的网格工具。简言之，OGSI 重造了网格服务，通过 Web 服务定义语言（WSDL）和其他可用 XML 工具将网格服务转变成 Web 服务。
OGSI 在 Web 服务界引发了很多讨论。总而言之，这些想法是可靠的，但需要进行很多重构和改写工作。
- 首先，要让它更容易理解，要对规范进行重构，换句话说，要将规范分解到其中的组件上，这一点很关键。
- 任何新的工作都必须和已有的 Web 服务部署与 XML 工具更好地结合。
- 因为 Web 服务并不是绝对需要状态，因此必须存在服务识别与状态资源的解耦。
- 不同实现之间状态信息的审查、发现和互操作必须更加容易。
是什么东西推动了所有这些工作？由于越来越多的需求依然存在，所以回答这问题就简单了：网格服务需要状态。
WSRF 简介
Web 服务资源框架有六种 Web 服务规范组成，它们通过定义“Web 服务资源法”（WS-Resource approach），在 Web 服务的上下文中实现对状态的建模和管理。这种方法的内容包括：
- 在已经建立起来的 Web 服务标准上下文中发现和观察状态资源，并与之交互的能力。
- 将服务和作用于该服务的状态资源的分离。
让我们更深入地了解一下这两点内容。
处理 Web 服务的上下文
尽管 Web 服务提供了 UDDI、WSDL和其他一些基于 XML 的工具，用它们来发送、接收和处理消息，甚至还可以用它们来回传递状态信息，但它没有为那些需要理解相互状态信息的系统提供一种标准的可互操作的方法。
此外，在现有 Web 服务标准的上下文中提供这些标准的可互操作方法，而不是将它们作为扩展 Web 服务的附加层（这种方法可能会令现有实现难于完成），这点很重要。比如说，在某些情况下，使用 OGSI 的方法意味着大量使用 XML Schema 的 xsd:任何一种公式，这会为现有 JAZ Web 服务部署带来各种麻烦。
当然了，WSRF 可能会在某些网格计算领域内设置道路减速板，特别是那些一开始就基于 OGSI 实现的计算领域。设想一下：您正开始建立新的办公大楼，而这时有个权威人士冒出来声称，由于用于建筑的浇注混凝土地基的规范正在编写当中，因此最好使用有坚固钢梁的钢筋混凝土地基。是的，开始的时候可能会很痛苦，可如果采用新方法，您的建筑物会坚固得多。同样，尽管 WSRF 现在看起来似乎有些困难，但它实际上提供了能让部署、维护和未来的发展更加轻松的路径。
服务和状态资源的分离
在 Web 或网格服务中，任何关于状态的讨论都会引发一些问题，如“我们真的能够接受直接在这样一个服务设置状态所付出的代价和带来的限制么？”您会立即得到一个否定答案。在 Web 服务标准中引入这些累赘极大地伤害了现有的成百上千的 Web 服务，这些服务的
modus operandi既不需要也不使用状态信息。比如说，很多 Web 服务只是用来查询详细目录信息的接口，如流行的 Amazon.com Web 服务。放入请求，得到响应，这就是您需要的全部内容。
所以，没有必要直接将状态嵌入网格或 Web 服务中。更好的方法是保持网格或 Web 服务接口的无状态性，同时使之与独立的状态资源交互。用这种方式，网格或 Web 服务就可以重新启动，并重新与提供状态信息的外部组件连接。
这正是底层 WSRF 工具所实现的功能。这种工具允许网格或 Web 服务提取出状态信息，并对齐进行修改，而不必考虑用何种资源（XML 文档、关系数据库中的表、服务器会话或 EJB 中的对象代码等）来保存这些信息。这些状态信息可以被惟一标识，并插入到服务使用的消息流中，这与来回传递的 XML 构造文档中的其他部分一样。有一个重要问题需要注意，您正在处理的不是状态资源本身，而是对状态资源的
引用。
由于这个引用是一个惟一标识，因此您可以执行诸如立即或有计划地破坏引用这样的操作，而该操作不允许按照消息接受处理的顺序进一步处理消息。
WSRF 规范
-
WS-ResourceLifetime定义了 WS-Resource 的资源破坏机制，其中包括允许请求方立即或使用基于时间的安排好的资源终止机制来破坏资源。
-
WS-ResourceProperties定义了 WS-Resource 的类型定义如何与 Web 服务的接口描述相关联，以及检索、更改或删除 WS-Resource 属性的消息交换过程。
-
WS-Notification通过基于主题的发布/订阅模式定义事件订阅和通知机制。
-
WS-RenewableReferences定义了端点变为无效时，对需要检索端点引用更新版本的策略信息的常规 WS-Addressing 端点引用。
-
WS-ServiceGroup定义了通过异质引用集合访问 Web 服务的接口。
-
WS-BaseFaults为在 Web 服务消息交换过程中返回的错误信息定义了基本的 XML 错误类型。
结束语
WSRF 依然是发展中的规范，在 OASIS 技术委员会最终定稿之前还要进行若干修改。所采纳的意见被混合在一起，不过这也是新技术碰到的典型情况。四月份之前该规范要进行更多轮公开讨论和修改，这之后很快就会发布几个测试互操作性的原型，——这毕竟是采用这种方法的惟一原因。请关注 IBM developerWorks，我们会随时报道事情的最新进展。
参考资料
关于作者
对本文的评价
| 
