PDF状态建模：方法有多少？
Web服务规范的技术和社会学研究
Ian Foster，阿贡国家实验室
Savas Parastatidis，微软研究院
Paul Watson，纽卡斯尔大学
Mark McKeown，曼彻斯特大学
没有什么比关于深奥技术问题的争论更能激发软件架构师和开发人员的最佳（和最差）一面了。正如每位读者从经验中所知，很难弄清争论的焦点到底是什么。造成这种缺乏清晰度的一个原因通常是，不同的人关心问题的不同方面。在对问题没有达成共识的情况下，就很难就解决方案达成一致。
在本文中，我们讨论了一个近年来引发激烈辩论的技术问题：如何定义Web服务之间的交互，以支持对状态的操作（即，与服务关联并在交互过程中持久存在的数据值，以便一个操作的结果可以取决于之前的操作）。4 航空公司预订系统和计算作业调度程序是具有此要求的两个系统示例。两者都必须为其客户端提供对正在进行的活动的信息的访问权限：分别是预订和作业。客户端通常希望命名和/或标识状态（引用特定的预订或作业），访问该状态（获取航班预订的状态或作业的执行进度），修改该状态的一部分（更改航班的出发时间或设置作业的CPU要求），并销毁它（取消预订或终止作业）。
关于这个问题的争论不是关于对这些操作的需求，而是关于如何精确地建模和实现服务状态以及对该状态的相关交互的具体细节。状态可以被分布式计算技术显式建模（例如，作为具有创建、读取、更新和销毁操作的“对象”），或者通过在交互中引用应用程序领域特定的概念来隐式建模（例如，“创建预订”和“更新预订”消息，其中包含特定于领域的标识符，例如ASIN—亚马逊标准识别号）。沿着不同的维度，我们可以使用HTTP或SOAP作为实现技术。
我们的目标是阐明状态建模的可能方法。为此，我们提出了四种不同的方法，并展示了每种方法如何用于启用对简单作业管理系统的访问。然后，我们总结了针对每种方法提出的主要论点。除了提供对不同方法的优点和缺点的见解外，该讨论也可能作为技术辩论的案例研究而有趣。正如我们将看到的，这四种方法在它们所做的事情上非常相似，但在它们具体如何做上有所不同。
一些初步观察
首先，关于我们所说的状态建模的一些观察。我们想要与之交互的系统可能具有简单或复杂的内部状态。可以公开此状态的各个方面，以便外部客户端可以进行“管理”操作。例如，航空公司预订系统可能会让客户能够以编程方式创建、监控和管理预订。相同的系统也可能允许运营商以编程方式访问有关当前系统负载以及计算资源到不同系统功能的映射的信息。我们并不是建议这些机制提供对其底层状态的全部直接访问权限。相反，我们假设封装和数据完整性/所有权原则得到维护。系统的设计者有责任定义系统内部状态的投影，他们愿意将其公开给外部世界。5
此类投影可能很复杂。例如，在作业管理系统中，即使是一个表面上简单的作业，其关联的底层状态也可能由不同后端计算机上的多个不同进程、各种内部表和目录中的条目以及调度程序和监视器等子系统中的活动组成。在设计允许的与此类系统的交互时，我们必须以不仅易于客户端理解和使用，而且还能够有效地维护此投影的方式来建模“作业状态”（要提供给客户端的复杂底层状态的投影）。
我们使用简写“状态建模”而不是笨拙的“底层系统状态投影建模”。然而，重要的是要记住，在发生交互的系统边界背后可能发生的事情的真实情况。
我们还对架构风格和实现技术之间的区别做一些评论。Web从支持资源访问的基础设施到分布式应用程序平台的演变，导致了关于相关架构方法和技术的许多讨论。诸如REST（具象状态传输，3 一种架构风格）和HTTP（一种协议规范）等术语经常互换使用，以指示一种架构方法，其中一小组动词/操作（PUT、GET、DELETE）具有统一的语义，用于构建应用程序。类似地，Web服务（一组协议规范）1 的普及导致该术语被用作面向服务（一种架构风格）的同义词。
我们区分了架构风格及其实现技术。前者的实例代表了一组原则和约束，这些原则和约束在设计和实现分布式应用程序时提供指导。相比之下，后者是在构建应用程序时应用架构风格原则的机制或工具。架构风格和实现技术之间并非一一对应，即使一组工具在应用特定原则集时可能更容易使用。例如，纯HTTP特别适合根据REST原则实现分布式应用程序，而诸如SOAP之类的Web服务技术更适合于接口驱动的应用程序。然而，没有理由不能使用Web服务技术构建面向REST的应用程序，或者使用HTTP构建基于分布式对象的应用程序——尽管我们怀疑有人会想经历这样的练习。
状态建模的四种方法
表1总结了此处介绍的四种方法的关键属性。以下是每种方法的简要描述。
表 1：四种方法的关键特征。在每个框中，我们列出了以操作名称和（括号中）定义规范表示的函数的常规编码。缺少条目仅表示没有定义常规编码；仍然可以提供自定义的、特定于应用程序的编码。
| WS-RF | WS-Transfer | HTTP | 无约定 | |
| 状态表示模式 | WSDL 扩展 | |||
| 寻址状态表示 | EPR (WS-Addressing) | EPR (WS- Addressing) | URI | URN |
| 创建新状态 | Create (WS-Transfer) | HTTP POST | ||
| 访问整个状态 | GetResourcePropertyDocument (WS-ResourceProperties) | Get (WS-Transfer) | HTTP GET | |
| 获取部分状态 | GetResourceProperty, GetMultipleResourceProperties, QueryResourceProperties (WS-ResourceProperties) | 除非状态表示的一部分通过不同的 URI 公开（没有定义关于关系的语义），否则未定义 | ||
| 更新整个状态 | SetResourceProperties (WS-ResourceProperties) | Put (WS-Transfer) | HTTP PUT | |
| 更新或添加部分状态 | SetResourceProperties, InsertResourceProperties, UpdateResourceProperties, DeleteResourceProperties (WS-ResourceProperties) | |||
| 请求通知 | Subscribe (WS-Notification) | Subscribe (WS-Eventing) | Subscribe (WS-Eventing) | |
| 基于租约的生命周期管理 | SetTerminationTime (WS-ResourceLifetime) | |||
| 销毁状态 | Destroy (WS-ResourceLifetime) | Delete (WS-Transfer) | HTTP DELETE | |
| 故障建模 | 良好定义的错误代码 (WS-BaseFaults + 其他规范) | SOAP 故障 | HTTP 故障代码 | SOAP 故障 |
| 基于 RPC | 是 | 是 | 否 | 否 |
| 开放标准流程 | 是 (OASIS) | 是 (W3C) | 已经是标准 | 无需新标准 |
WS-RF 方法
WS-RF（Web服务资源框架）定义了如何使用Web服务技术建模和管理状态的约定。WS-RF实现了一种类似于分布式对象或资源的架构风格。投影状态被显式建模为XML文档（状态表示），并通过WS-Addressing EPR（端点引用）寻址，EPR是客户端访问网络服务所需信息的常规表示形式。
与传统的基于对象的系统一样，可以定义任意数量的操作来访问或导致投影状态的更改。然而，WS-RF规范定义了一组通用操作，用于以下目的：访问整个或部分投影状态（XML文档）；请求有关其更改的通知（使用WS-Notification）；完全或部分更新它；以及删除它。XML文档的结构（即，模式）以及可以应用于投影状态（称为资源）的所有操作都包含在与状态的EPR关联的WSDL（Web服务描述语言）文档中，从而允许客户端使用标准操作来发现特定服务提供的状态。
WS-RF和WS-Notification规范是在OASIS（结构化信息标准促进组织）内开发的。它们在各种开源和专有系统中实现。其他规范，特别是WS-Notification和WSDM（Web服务分布式管理），都建立在WS-RF之上。
WS-Transfer 方法
与WS-RF一样，WS-Transfer通过可通过EPR访问的XML文档显式建模投影状态。然而，对该状态定义的唯一操作是，按照CRUD（创建、检索、更新和删除）架构风格：创建新的资源状态表示，方法是提供新的XML文档；获取整个资源状态表示；放置新的资源状态表示以替换现有的资源状态表示；以及删除现有的状态表示。然后，通过使用这些操作交换状态表示来构建分布式、面向资源的应用程序。
WS-Transfer规范由微软领导的行业组织开发，最近已提交给W3C（万维网联盟）进行标准化。其他规范，特别是WS-Eventing和WS-Management，都建立在WS-Transfer之上。正如我们稍后将看到的，WS-Transfer和WS-RF仅在细微的技术细节上有所不同；可以说，它们各自独立存在更多的是由于行业政治而不是技术考虑。幸运的是，似乎有行业支持基于WS-Transfer基础——WS-ResourceTransfer规范——来整合WS-Transfer和WS-RF方法。
HTTP 方法
HTTP是一种应用程序协议，实现了面向资源的分布式系统构建方法。它已被描述为REST架构风格的实现。与WS-RF和WS-Transfer一样，HTTP实现了面向资源的分布式系统构建方法。根据REST，应使用一小组具有统一语义的动词/操作来构建超媒体应用程序，Web就是此类应用程序的一个示例。通过这些操作的语义应用的约束旨在允许应用程序扩展（例如，通过缓存状态表示）。状态表示通过URI标识。
HTTP定义了简单的动词——例如POST、PUT、GET、DELETE——和标头，以实现根据REST原则的应用程序。XML只是HTTP可以处理的众多媒体格式之一。
无约定方法
最后，在“无状态管理约定”方法（在表1中缩短为“无约定”）6中，没有诸如操作、接口、类、状态、客户端或服务器之类的概念。相反，应用程序是通过服务之间单向消息的交换来构建的。消息交换的语义（例如，消息是否可以缓存或是否包含事务上下文）通过可组合协议添加。状态表示不是基本构建块。相反，资源应通过消息内部的URI（或URN）标识，将状态管理留给特定于应用程序域的协议来处理。尽管在遵循这种风格的实现中可以使用任何异步消息传递技术，但我们在此处考虑基于Web服务协议的实现，但不引入与状态相关的约定。
作业管理示例
我们使用一个简单的示例来更具体地比较这四种方法。该示例是一个作业管理系统，允许客户端请求创建计算任务（“作业”），并监控和控制先前创建的作业。它提供了表2中列出的八个操作，我们选择将其表示为一系列典型的状态操作操作。在每种情况下，客户端都通过向作业管理系统发送适当的消息来发出请求，然后期望收到指示成功或失败的响应。
表 2：在我们的不同方法比较中考虑的八个操作
| # | 操作 | 描述 |
| 1 | 创建新作业 | 客户端通过向负责创建新作业的作业工厂服务发送作业创建请求来请求创建新作业。成功后，将返回一个作业句柄，该句柄可用于在后续操作中引用该作业。 |
| 2 | 检索状态 | 检索与指定作业关联的所有状态信息（例如，执行状态、资源分配、程序名称）。 |
| 3 | 状态 | 确定指定作业的执行状态（例如，活动、暂停）。 |
| 4 | 生命周期 | 延长指定作业的生命周期。 |
| 5 | 订阅 | 请求有关指定作业状态更改的通知。 |
| 6 | 暂停 | 暂停指定作业。 |
| 7 | 终止 | 终止指定作业。 |
| 8 | 终止多个 | 将终止操作应用于满足某些条件的所有作业，例如属于特定客户端的作业、具有特定总执行时间的作业、具有特定当前执行状态的作业或具有明确标识的作业句柄的作业。 |
操作1创建一个新作业，并返回一个句柄，该句柄可用于在后续操作中引用该作业。参数指定诸如所需资源、作业的初始生命周期以及要执行的程序之类的内容。
操作2-7支持对单个作业的一些典型的作业监视和控制功能。
操作8是可能与多个作业相关的交互的示例。要应用操作的作业集可以根据作业特征或通过提供一组作业句柄来指定。
在下面的讨论中，我们将展示如何使用我们的四种方法来构建支持这八个任务的服务。每种方法不仅共同之处在于“作业工厂服务”是网络端点，应将作业创建和某些其他请求定向到该端点，而且还在以下方面与其他方法区分开来
* 其语法（即，作业句柄应如何表示以及如何在消息中表达对作业的操作）。
* 其对现有规范中定义的约定的使用（或不使用），目的是定义其语法。
此处在语法和约定之间进行的区分可能看起来并不重要，但我们强调它，以便我们可以在本节中专注于语法，并将稍后在本文中讨论采用特定“标准”（约定）的优点或缺点。
WS-RF 实现。表3描述了基于WS-RF和WS-Notification规范的作业管理接口。我们使用粗体类型来指示在与所讨论的方法相关的某些规范中定义的操作名称。那些未以粗体显示的操作根据定义未在任何现有规范中定义，因此它们的语法和语义代表某种任意选择，为了说明目的而选择。我们看到WS-RF和WS-Notification规范提供了八个所需功能中的五个。
表 3：WS-RF作业管理接口中使用的语法，显示了表2中每个操作的请求消息、目标地址和成功时返回的消息
| # | 消息 | 至 | 成功时返回 |
| 1 | CreateJob(作业规范) | 作业工厂服务 | WS-Resource 限定的到作业状态的 EPR（作业句柄） |
| 2 | GetResourcePropertyDocument() | 作业句柄 EPR | 包含所有作业状态的 XML 文档 |
| 3 | GetResourceProperty("status") | 作业句柄 EPR | 作业状态 |
| 4 | SetTerminationTime(生命周期) | 作业句柄 EPR | 新生命周期 |
| 5 | Subscribe(条件) | 作业句柄 EPR | 到订阅的 EPR |
| 6 | 暂停 | 作业句柄 EPR | 确认 |
| 7 | Destroy | 作业句柄 EPR | 确认 |
| 8 | DestroyMultiple(作业描述) | 作业工厂服务 | 确认 |
操作1成功返回的作业句柄表示为EPR。接收到此类作业句柄的客户端随后可以使用它作为操作2-7的目标。请注意，请求被定向到作业句柄EPR中包含的Web服务地址，该地址可能是也可能不是作业工厂服务。这种区别很重要，因为它允许作业工厂和作业管理功能之间进行逻辑和/或物理分离。
操作8直接发送到作业工厂服务，假定该服务可以访问有关所有活动作业的信息。参数可以是例如，用于标识要终止的作业的规范（例如，Xpath规范）（例如，Bloggs创建的所有作业或已超过其配额的所有作业，和/或指示要终止的作业的EPR列表）。
WS-Transfer 实现。表4描述了基于WS-Transfer和WS-Eventing规范的作业管理接口，它们提供了八个所需操作中的五个。与WS-RF接口一样，操作1成功返回的作业句柄表示为EPR，接收到此类作业句柄的客户端随后可以使用它作为操作2-7的目标。请注意，请求被定向到作业句柄结构中包含的Web服务地址，该地址可能是也可能不是作业工厂服务。
表 4：WS-Transfer作业管理接口中使用的语法，显示了表2中每个操作的请求消息、目标地址和成功时返回的消息
| # | 消息 | 至 | 成功时返回 |
| 1 | Create(作业规范) | 作业工厂服务 | 到作业状态的 EPR |
| 2 | Get() | 作业句柄 EPR | 包含所有作业状态的 XML 文档 |
| 3 | Get() | 作业句柄 EPR | 包含所有作业状态的 XML 文档，可以从中提取状态。 |
| 4 | SetLifetime(生命周期) | 作业句柄 EPR | 新生命周期 |
| 5 | Subscribe(条件) | 作业句柄 EPR | 到订阅的 EPR |
| 6 | 暂停 | 作业句柄 EPR | 确认 |
| 7 | Delete() | 作业句柄 EPR | 确认 |
| 8 | DeleteMultiple(作业规范) | 作业工厂服务 | 确认 |
操作3的另一种处理方法是可能的，尽管需要一些额外的工作，但避免了传输整个状态文档的需求。定义了一个新操作（例如，GetEPRtoPart），该操作请求通过不同的EPR公开新的状态表示，表示原始状态表示的一部分。然后将Get()操作应用于此新EPR。WS-Transfer应用程序（和更高级别的规范，例如WS-Management）经常使用此方法来解决WS-Transfer中缺少对部分状态访问的支持。
操作8直接发送到作业工厂服务，假定该服务可以访问有关所有活动作业的信息，就像WS-RF的情况一样。
HTTP 实现。表5总结了HTTP实现的语法。请注意，操作5也可以通过某些自定义编码或使用诸如SMTP、Jabber、SMS或Atom之类的系统来寻址。HTTP DELETE不能接受任何内容，因此无法指定可以使用HTTP DELETE消息删除一组作业（操作8），除非在我们删除某些预定义组中的所有作业时（例如，“HTTP DELETE” http://grid.org/Bloggs/Jobs 以删除Bloggs创建的所有作业）。
表 5：REST作业管理接口中使用的语法，显示了表2中每个操作的请求消息、目标地址和成功时返回的消息
| # | 消息 | 至 | 成功时返回 |
| 1 | HTTP POST 作业规范 | 作业工厂服务 (例如，http://grid.org) | 标识已创建的作业的 URI：例如， http://grid.org/Bloggs/Jobs/4523 |
| 2 | HTTP GET | http://grid.org/Bloggs/Jobs/4523 | 作业状态的表示，包括 Xlinks 和语义信息 |
| 3 | HTTP GET | http://grid.org/Bloggs/Jobs/4523/status | 作业状态的表示 |
| 4 | HTTP PUT 过期时间 | http://grid.org/Bloggs/Jobs/4523/lifetime | 确认 |
| 5 | HTTP POST 条件 | http://grid.org/Bloggs/Jobs/4523/subs | 标识新订阅的 URI |
| 6 | HTTP PUT "suspended" | http://grid.org/Bloggs/Jobs/4523/status | 确认 |
| 7 | HTTP DELETE | http://grid.org/Bloggs/Jobs/4523 | 确认 |
| 8 | — | — | — |
请注意，虽然HTTP定义了所有使用的动词，但为了实现作业服务的操作而交换的URI结构以及文档的格式和语义是特定于应用程序的。因此，虽然URI似乎根据其结构传达了一些语义信息（例如，特定作业URI末尾的/status可能被人类解释为状态资源的标识符），但这是一种特定于应用程序的约定。
无约定/Web服务实现。由于在这种方法中，我们假设没有具有广泛认可的语义的已定义状态管理约定，因此每个应用程序域都应定义满足其自身需求的交互。表6总结了使用SOAP消息传递以这种风格实现的作业管理服务的潜在实现。
由于所选示例的性质，所有操作都被定义为请求-响应消息交换。“CreateJob”消息交换返回一个标识符作为作业句柄。返回的作业标识符可以是全局唯一的URI（例如，URN），可以被多个作业服务接受。关于它的元数据（例如，“知道”它的作业服务）可以从注册表中发现。这种资源标识方法的示例包括LSID（生命科学标识符）、IVOA（国际虚拟天文台联盟）标识符和ASIN。因此，作业标识符可能成为一种与技术无关的句柄，也可以与其他技术（例如，到同一服务的Jini或CORBA接口）一起使用。接收到此类作业句柄的客户端随后可以将其传递给作业管理服务。
表 6：作业句柄方法中使用的语法，显示了表2中每个操作的请求消息、目标地址和成功时返回的消息
| # | 消息 | 至 | 成功时返回 |
| 1 | “新作业”携带作业规范 | 作业管理服务 | 新创建作业的标识符 |
| 2 | “状态”携带作业标识符 | 任何知道作业标识符的作业服务 | 带有作业状态的 XML 文档 |
| 3 | “状态”携带作业标识符 | 任何知道作业标识符的作业服务 | 带有作业状态的 XML 文档 |
| 4 | “新生命周期”携带作业标识符和新生命周期 | 任何知道作业标识符的作业服务 | 确认* |
| 5 | “订阅”携带作业标识符和订阅信息（每个） | 任何知道作业标识符的作业服务 | 确认* |
| 6 | “暂停”携带作业标识符 | 任何知道作业标识符的作业服务 | 确认* |
| 7 | “销毁请求”携带作业标识符 | 任何知道作业标识符的作业服务 | 确认* |
| 8 | “销毁请求”携带作业标识符和查询表达式 | 任何知道作业标识符的作业服务 | 确认* |
* 也可能静默接受消息并仅报告故障。如果需要交付证明，可以使用WS-ReliableMessaging。
讨论
状态建模的四种方法在它们实际执行的操作方面没有太大差异。所有方法都发送基本相同的消息，具有相同的内容，跨网络。例如，销毁特定作业的请求在每种情况下都将通过HTTP PUT定向到网络端点，并将包含要执行的操作的名称，以及一些指示应销毁的作业的数据。这些方法仅在如何将这些不同的组件包含在消息中有所不同，这个问题可能对消息如何处理和路由有影响，但对服务如何实现没有影响。
与此同时，这些方法在其对约定的使用、底层协议以及可用于支持其使用的工具方面显然存在显着差异。我们在此总结关于这些主题的重要论点。对各种立场的描述是我们自己的。
约定的价值。 WS-RF和WS-Transfer方法的支持者认为，创建、访问和管理状态涉及一组通用模式，这些模式可以有效地捕获在一组规范中，从而简化使用这些模式的应用程序的设计、开发和维护。例如，在我们的作业管理服务案例中，这些支持者可能会观察到以下情况
* 作业的创建和后续管理可以自然地被视为某些通用模式的实例（与作业关联的状态的创建、访问、订阅、生命周期管理和销毁）。
* 以这些模式编码作业管理接口简化了接口的设计（因为其中的大部分已在其他规范中提供）以及向他人解释该接口。
他们还可能指出，客户端工具和“了解WS-RF和/或WS-Transfer”的应用程序提高了程序员的生产力。例如，注册表或监视系统可以使用WS-RF操作来访问服务状态，而无需任何特定于应用程序的状态结构知识。2
相反，无约定方法的支持者认为，任何特定接口（例如，作业管理的接口）的设计通常都相对简单，涉及未被这些常规模式捕获的问题，并且不需要编码该模式的规范中包含的所有功能。因此，可以通过从第一性原理出发来实现更简单的设计。例如，在我们的作业管理服务案例中，虽然WS-RF和WS-Transfer为我们“免费”提供了一个Destroy操作，但我们仍然需要引入一个单独的Suspend操作。此外，Destroy的语义可能非常特定于应用程序。例如，服务实现者可以决定保留有关已销毁作业的信息（通过将其状态更改为“已销毁”），以便仍然可以检索有关它们的信息。在这种情况下，状态不会被销毁。
最后，WS-RF和WS-Transfer侧重于与单个状态的交互（例如，DestroyMultiple必须自定义定义），因此在操作多个状态是常见情况的情况下可能无法提供有用的约定；例如，所有亚马逊REST和Web服务都可以使用多个ASIN。
理想情况下，我们希望根据诸如代码大小之类的具体指标来评估这两个立场的相对优点。然而，这样的评估需要就接口应支持的需求达成一致。不幸的是，不同方法的支持者在他们对需求的看法上也往往存在差异。例如，通用模式的支持者可能会将使用WS-Resource Lifetime操作进行软状态生命周期管理的能力视为理想的，而其他人可能不认为该功能很重要。
标准。 另一个意见分歧的主题是标准化规范的重要性。不幸的是（但在Web服务领域并非不常见），我们面临的不是一组而是两组Web服务规范，它们在目的和设计上相似，但在语法和语义的细微方面有所不同。WS-RF已提交给标准机构（OASIS）并经过审查和批准；WS-Transfer已提交给W3C，但尚未成为W3C建议。拟议的两者合并，WS-ResourceTransfer，增加了混乱。因此，我们得到了一系列意见，包括以下内容
* WS-RF，经过标准机构的密集社区审查，因此在技术上优越和/或在道德上优于“专有”的WS-Transfer。
* WS-RF在技术原因上优于WS-Transfer——例如，它支持访问资源状态的子集，如果该状态很大，这可能很重要。（在WS-Transfer中，可以通过定义一个辅助操作来实现相同的效果，该操作返回到所需子集的EPR。）
* WS-Transfer在技术原因上优于WS-RF——例如，其更高的简洁性。
* 作为一般原则，我们应该仅采用稳定、被广泛接受并受互操作工具支持的规范。由于WS-RF和WS-Transfer都不受所有主要供应商的支持，因此两者都未通过此测试。这种观点支持无约定方法。
* HTTP在Web上被广泛使用，因此，应优先于任何基于WS的解决方案。
实现重用。 WS-RF和WS-Transfer等约定的支持者认为，采用常规模式可以促进代码重用。每个WS-RF或WS-Transfer服务都以相同的方式执行诸如状态访问、生命周期管理、传入请求的并发控制以及状态激活/停用之类的操作。因此，实现这些行为的代码可以在服务实现中重用。
但是，不采用惯例方法的支持者回应说，服务实施者也可以使用相同的代码。换句话说，为服务实施者提供常见任务的标准化实现当然有价值，但这并不意味着这些模式需要在服务外部公开。
简洁性与结构性。 HTTP/REST 方法的支持者强调，与基于 Web 服务的方法相比，它提供了更简洁的请求，并允许使用更简单的客户端工具。批评者指出，使用 HTTP/REST 意味着用户无法利用在 Web 服务技术和平台上的大量投资来进行基于消息的交互。
摘要
我们介绍了在 Web 服务交互中对状态进行建模的四种不同方法。每种方法都定义了大致相当的构造，用于引用、访问和管理状态组件，但其精确的语法以及对操作的常规、独立于域的编码的使用（或不使用）方面有所不同。
因此，在定义状态管理操作时，WS-RF 和 WS-Transfer 方法都使用 EPR 来引用状态组件，并分别采用 WS-RF 和相关规范以及 WS-Transfer 和相关规范中定义的惯例。相比之下，不采用惯例和 REST 方法分别在 SOAP 和 HTTP 之上采用了特定于域的操作编码。
对围绕这些不同方法发生的辩论的分析强调了分离技术、政治和文体问题的内在困难。一些意见分歧与定义明确的技术问题有关，反映了关于系统设计的不同理念或不同的目标应用。其他意见分歧与不同的目标时间尺度有关。例如，不采用惯例的支持者最初反对使用 WS-Addressing，因为某些工具缺乏对该规范的支持，而 WS-RF 和 WS-Transfer 的支持者则赞成使用，他们认为 WS-Addressing 最终将变得普及。对 WS-Addressing 的支持此后已变得近乎普及，现在很少有人认为使用它令人反感。
字母表和规范汤
任何关于 Web 服务的讨论都不可避免地会涉及大量的首字母缩略词和规范名称。我们在此列出其中一些。为了节省空间，我们不提供对各个规范的引用。这些规范可以很容易地在网上找到。
EPR (端点引用)：正如 WS-Addressing 规范中定义的那样，Web 服务 (WS) 元素的组合，这些元素定义了 SOAP 标头中资源的地址。
SOAP：一种通过网络（通常使用 HTTP）交换基于 XML 的消息的协议。
WSDL (Web 服务描述语言)：一种基于 XML 的语言，它为描述 Web 服务提供了模型。
WS-Eventing：一种规范，定义了 Web 服务订阅另一个 Web 服务或接受来自另一个 Web 服务的订阅的协议。
WSDM (Web 服务分布式管理)：OASIS 开发的 Web 服务架构和一组用于管理分布式资源的规范。
WS-ResourceTransfer：WS-RF 和 WS-Transfer 的拟议集成。
WS-RF (Web 服务资源框架)：OASIS 开发的架构和一组规范，用于描述和访问 Web 服务中的状态。
WS-Transfer：一种规范，定义了用于传输 WS 可寻址资源的 XML 表示形式以及创建和删除此类资源的协议。
参考文献
1. Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C. 和 Orchard, D. 2003. Web 服务架构。 W3C.
2. Chervenak, A., Schopf, J.M., Pearlman, L., Su, M.-H., Bharathi, S., Cinquini, L., D’Arcy, M., Miller, N., Bernholdt, D. 2006. 使用 MDS4 监控地球系统网格。IEEE e-Science 和网格计算会议。荷兰阿姆斯特丹。
3. Fielding, R. 2000. 基于网络的软件架构的架构风格和设计。信息和计算机科学。加州大学欧文分校。
4. Foster, I., Czajkowski, K., Ferguson, D., Frey, J., Graham, S., Maguire, T., Snelling, D., Tuecke, S. 2005. 在分布式系统中建模和管理状态：OGSI 和 WSRF 的作用。IEEE 会刊 93(3): 604-612.
5. Helland, P. 2004. 内部数据与外部数据。微软。
6. Parastatidis, S., Webber, J., Watson, P. 和 Rischbeck, T. 2005. WS-GAF：用于构建使用 Web 服务的网格应用程序的框架。并发与计算：实践与经验 17 (2-4): 391-417.
致谢
我们感谢 Karl Czajkowski、Jim Gray 和 Sam Meder 对本文档早期版本的评论。毋庸置疑，对不同论点的描述是我们自己的观点。第一作者的工作部分得到了美国能源部高级科学计算研究办公室数学、信息和计算科学部门子计划的支持，合同号为 W-31-109-Eng-38。纽卡斯尔的工作得到了英国 eScience 计划的支持，资金来自 EPSRC、DTI 和 JISC。
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
IAN FOSTER ([email protected]) 是阿贡国家实验室计算研究所所长，他是阿贡杰出研究员，也是芝加哥大学计算机科学系 Arthur Holly Compton 杰出服务教授。
SAVAS PARASTATIDIS ([email protected]) 是微软研究院的架构师。他研究技术在电子研究中的应用，并且对云计算、知识表示和管理以及社交网络特别感兴趣。
PAUL WATSON ([email protected]) 是纽卡斯尔大学的计算机科学教授，也是英国东北地区电子科学中心主任。
MARK McKEOWN 在撰写本文时是英国曼彻斯特大学的网格架构师。
© 2009 1542-7730 /09/0200 $5.00
本文以印刷形式发表于 2008 年 9 月的 Communications of the 杂志。
最初发表于 Queue vol. 7, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 正在从实现有用的体验发展到在疫情期间对于数十亿人继续工作和教育以及保持重要的人际交往至关重要。WebRTC 未来的机遇和影响确实令人着迷。
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，并且用户采用率更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾经将钥匙锁在房屋或汽车内，您就会熟悉依赖循环。没有钥匙就无法打开锁，但是不打开锁就无法拿到钥匙。有些循环很明显，但是更复杂的依赖循环可能很难在它们导致中断之前找到。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。
Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的运营商如何在租户系统所有者进行故障排除期间配置补救策略，同时帮助保持租户系统的尽可能稳定。
© 保留所有权利。