ACM通信

没有什么比在一个神秘的技术问题上产生分歧更能激发软件架构师和开发人员最好(和最坏)的一面了。正如每一位读者从经验中所知道的那样，很难弄清辩论的到底是什么。缺乏清晰度的一个原因通常是不同的人关心问题的不同方面。如果对问题没有达成一致意见，就很难就解决方案达成一致意见。

在本文中，我们将讨论一个近年来引发激烈争论的技术问题:如何定义Web服务之间的交互，以支持状态操作(即与跨交互的服务相关联的数据值，以便一个操作的结果可以依赖于先前的操作)。⁴航空订票系统和计算作业的调度程序是具有此需求的两个系统示例。两者都必须为客户提供访问正在进行的活动的信息:预订和工作。客户端通常希望命名和/或标识状态(例如，引用特定的预订或作业)、访问该状态(获取航班预订的状态或作业的执行进度)、修改该状态的一部分(例如，更改航班起飞时间或设置作业的CPU要求)和销毁它(例如，取消预订或终止作业)。

关于这个问题的争论并不涉及此类操作的需要，而是关于如何精确建模和实现服务状态以及与该状态相关的交互的细节。例如，可以对状态进行建模显式地通过使用的分布式计算技术(例如，作为具有创建、读取、更新和销毁操作的“对象”)或隐式地通过在交互中引用特定于应用程序领域的概念(例如，“创建预订”、“更新预订”，以及在消息体中包含特定于领域的标识符(如Amazon ASIN)的消息)。在不同的维度上，我们可以使用HTTP或SOAP作为实现技术。

我们在这里的目标是阐明建模状态的可能方法。为此，我们提出了四种不同的方法，并展示了如何使用每种方法访问简单的作业管理系统。然后我们总结了支持和反对每种方法的主要论点。除了提供对不同方法的优缺点的见解外，讨论作为技术辩论的案例研究也可能很有趣。正如我们将看到的，这四种方法在所做的事情方面非常相似，但在具体如何做方面却不同。

回到顶部

一些初步的观察

首先，一些关于我们所说的意思的观察建模的状态。我们想要与之交互的系统可能具有简单或复杂的内部状态。可以公开此状态的各个方面，以便外部客户机可以参与“管理”操作。例如，航空公司预订系统可能使客户能够以编程方式创建、监视和管理预订。同一系统还可能允许操作人员以编程方式访问有关当前系统负载和计算资源到不同系统功能的映射的信息。我们并不是建议这些机制提供对整个底层状态的直接访问。相反，我们假设保持了封装和数据完整性/所有权的原则。由系统设计者来定义投射到系统内部状态的那些方面，这些方面是他们愿意向外界公开的。⁵

这种预测可能很复杂。例如，在作业管理系统中，即使与一个明显简单的作业相关联的底层状态也可能由不同后端计算机上的多个不同的进程、各种内部表和目录中的条目以及子系统(如调度程序和监视器)中的活动组成。在设计与这样一个系统允许的交互时，我们必须以一种不仅便于客户理解和使用，而且能够有效维护这种预测的方式对“作业的状态”(将向客户提供的复杂底层状态的投影)建模。

一直谈论“对底层系统状态的投影建模”是笨拙的，因此我们使用缩写“建模状态”。然而，重要的是要记住发生交互的系统边界后面可能发生的事情。

我们还对体系结构风格和实现技术之间的差异做了一些评论。Web从支持访问资源的基础设施到分布式应用程序的平台的演变导致了有关体系结构方法和技术的大量讨论。如具象状态转移(REST;^3.(一种体系结构风格)和HTTP(一种协议规范)经常互换使用，以指示一种体系结构方法，在这种方法中，使用一组具有统一语义的谓词/操作(PUT、GET、DELETE)来构建应用程序。同样，Web服务(一组协议规范)的流行程度¹导致该术语被用作面向服务(一种架构风格)的同义词。

我们对体系结构风格及其实现技术进行了区分。前者的实例代表了在设计和实现分布式应用程序时提供指导的一组原则和约束。相反，后者是在构建应用程序时用于应用体系结构风格原则的机制或工具。架构风格和实现技术之间并不存在一一对应的关系，即使在应用一组特定的原则时，一组工具可能更容易使用。例如，纯HTTP特别适合根据REST原则实现分布式应用程序，而像SOAP这样的Web服务技术则更适合接口驱动的应用程序。但是，没有理由不使用Web服务技术构建面向rest的应用程序，或者使用http构建基于分布式对象的应用程序——尽管我们怀疑是否有人愿意进行这样的实践。

回到顶部

建模状态的四种方法

表1总结了这里介绍的四种方法的主要特性。下面简要介绍每种方法。

Web服务资源框架(WS-RF)定义了如何使用Web服务技术建模和管理状态的约定。WS-RF实现了一种类似于分布式对象或资源的体系结构风格。投影状态显式建模为XML文档(状态表示)，并可通过WS-Addressing端点引用(EPR)寻址，这是客户机访问网络服务所需的信息的传统表示。

与传统的基于对象的系统一样，可以定义任意数量的操作来访问或导致预测状态的更改。然而，WS-RF规范为以下定义了一组通用操作:访问投影状态(XML文档)的全部或部分;请求更改通知(使用WS-Notification);更新其全部或部分;并删除它。XML文档的结构(即模式)以及所有可应用于投影状态(称为资源)的操作都包含在与状态的EPR相关联的Web服务描述语言(Web Services Description Language, WSDL)文档中，从而允许客户机使用标准操作发现特定服务使何种状态可用。

WS-RF和WS-Notification规范是在OASIS标准组织中开发的。它们在各种开放源码和专有系统中实现。其他规范，特别是WS-Notification和Web服务分布式管理(WSDM)，构建在WS-RF之上。

WS-Transfer与WS-RF一样，通过可通过EPR访问的XML文档显式地对投影状态建模。然而，根据CRUD(创建、检索、更新和删除)体系结构风格，在该状态上定义的惟一操作是:创建通过提供新的XML文档来表示新的资源状态;得到一个完整的资源状态表示;把一种新的资源状态表示，以取代现有的资源状态表示;而且删除现有的州代表。然后通过使用这些操作交换状态表示来构建分布式的、面向资源的应用程序。

WS-Transfer规范是由微软领导的一个行业组织开发的，最近已提交给万维网联盟(W3C)进行标准化。其他规范，特别是ws - event和WS-Management，构建于WS-Transfer之上。正如我们稍后将看到的，WS-Transfer和WS-RF只是在微小的技术细节上有所不同;可以说，它们的独立存在更多是由于行业政治，而非技术考虑。幸运的是，基于WS-Transfer的子类—WS-ResourceTransfer规范，业界似乎对WS-Transfer和WS-RF方法的集成提供了支持。

HTTP是一种应用程序协议，实现了构建分布式系统的面向资源的方法。它被描述为REST体系结构风格的实现。与WS-RF和WS-Transfer一样，HTTP实现了一种面向资源的方法来构建分布式系统。根据REST，应该使用一小组具有统一语义的动词/操作来构建超媒体应用程序，Web就是这样一个应用程序的例子。通过这些操作的语义应用的约束旨在允许应用程序扩展(例如，通过缓存状态表示)。状态表示是通过URL标识的，HTTP定义了简单的动词——如POST、PUT、GET、delete和头文件，以根据REST原则实现应用程序。XML只是HTTP可以处理的众多媒体格式之一。

最后，在“无约定管理状态”方法中(以下为“无约定”)，⁶没有操作、接口、类、状态、客户端或服务器等概念。相反，应用程序是通过服务之间的单向消息交换构建的。消息交换的语义(例如，是否可以缓存消息或是否包含事务上下文)是通过可组合协议添加的。状态表示并不是基本的构建模块。相反，应该通过消息中的uri(或urn)标识资源，让应用程序领域特定的协议来处理状态管理。尽管任何异步消息传递技术都可以在遵循这种风格的实现中使用，但是我们在这里考虑的是基于Web服务协议的实现，而不引入与状态相关的约定。

我们使用一个简单的例子对这四种方法进行更具体的比较。这个例子是一个作业管理系统，它允许客户端请求创建计算任务(“作业”)，并监视和控制先前创建的作业。中列出的8个操作表2，我们选择将其表示为一系列典型的状态操作。在每种情况下，客户机通过向作业管理系统发送适当的消息来发出请求，然后期待指示成功或失败的响应。

操作1创建一个新作业并返回一个处理可以用于在后续操作中引用作业。参数指定所需的资源、作业的初始生命周期和要执行的程序等。

操作27支持单个作业上的一些原型作业监视和控制功能。

操作8是一个可能与多个作业相关的交互示例。可以根据作业特征或通过提供一组作业句柄来指定要应用操作的作业集。

在接下来的讨论中，我们将展示如何使用这四种方法来构建支持这八项任务的服务。正如我们将看到的，每种方法不仅有一个共同点，即“作业工厂服务”是一个网络端点，工作创建和某些其他请求应该指向该端点，而且在以下方面与其他方法不同:

• 它的语法(也就是说，作业句柄应该如何表示，作业上的操作应该如何在消息中表示)。
• 的使用(或不使用)约定在现有规范中定义，以定义其语法。

这里在语法和约定之间所作的区分似乎并不重要，但是我们强调这一点，以便在本节中可以将重点放在语法上，并将采用特定“标准”(约定)的优缺点的讨论推迟到本文后面讨论。

WS-RF实现．表3描述了基于WS-RF和WS-Notification规范的作业管理接口。在这里,我们使用黑体以指示在与所讨论的方法相关的某些规范中定义的操作名称。根据定义，那些没有粗体显示的操作在任何现有规范中都没有定义，因此它们的语法和语义代表了一些任意的选择，选择它们是为了说明目的。我们看到WS-RF和WS-Notification规范提供了8个必需功能中的5个。

操作1成功返回的作业句柄表示为EPR。然后，接收这样一个作业句柄的客户机可以将它用作操作27的目的地。注意，请求被定向到作业句柄EPR中包含的Web服务地址，该地址可能是作业工厂服务，也可能不是。这种区别很重要，因为它允许在作业工厂和作业管理功能之间进行逻辑和/或物理分离。

操作8直接发送到作业工厂服务，假定该服务可以访问有关所有活动作业的信息。例如，参数可以是标识要终止的作业的规范(例如Xpath规范)(例如Bloggs创建的所有作业或已超过其配额的所有作业，和/或指示要终止的作业的epr列表)。

WS-Transfer实现．表4描述了基于使用WS-Transfer和ws - event规范的作业管理接口，这两个规范提供了8个必需操作中的5个。

如同在WS-RF接口中一样，从操作1成功返回的作业句柄表示为EPR，接收到这样的作业句柄的客户机然后可以将其用作操作27的目的地。注意，请求被定向到作业句柄结构中包含的Web服务地址，该结构可能是作业工厂服务，也可能不是。

我们注意到操作3的另一种处理方法是可能的，尽管需要做一些额外的工作，但可以避免传输整个状态文档的需要。定义了一个新操作(例如，GetEPRtoPart)，它请求通过一个不同的EPR公开一个新的状态表示，表示原始状态表示的部分。然后将Get0操作应用到这个新的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创建的所有作业)。

注意，尽管HTTP定义了所有使用的动词，但为了实现作业服务的操作而交换的uri的结构和文档的格式和语义是特定于应用程序的。因此，虽然URI似乎根据其结构传递一些语义信息(例如，特定作业URI末尾的/状态可能被人解释为状态资源的标识符)，但这是一种特定于应用程序的约定。

No-conventions / Web服务实现．因为在这种方法中，我们假设没有定义的状态管理约定和广泛认可的语义，所以每个应用程序域都应该定义满足其自身需求的交互。表6使用SOAP消息传递总结了这种风格的作业管理服务的潜在实现。

由于所选示例的性质，所有操作都定义为请求-响应消息交换。CreateJob消息交换返回一个标识符作为作业句柄。返回的作业标识符可能是可被多个作业服务接受的全局惟一URI(例如，URN)。关于它的元数据(例如，“知道”它的作业服务)可以从注册中心发现。这种方法的例子包括生命科学标识符(LSID)、国际虚拟天文台联盟(IVOA)标识符和亚马逊标准标识号(ASIN)。因此，作业标识符可以成为独立于技术的句柄，也可以与其他技术一起使用(例如，到同一服务的Jini或CORBA接口)。然后，接收此类作业句柄的客户机可以将其传递给作业管理服务。

一直谈论“对底层系统状态的投影建模”是笨拙的，因此我们使用缩写“建模状态”。然而，重要的是要记住发生交互的系统边界后面可能发生的事情。

回到顶部

讨论

这四种方法在实际作用方面没有太大区别。它们都通过网络发送本质上相同的消息和相同的内容。例如，在每种情况下，销毁特定作业的请求将通过HTTP PUT定向到网络端点，并将包含要执行的操作的名称，以及指示应该销毁的作业的一些数据。这些方法的区别只在于如何将这些不同的组件包含在消息中，这个问题可能会影响消息的处理和路由方式，但不会影响服务的实现方式。

与此同时，这些方法之间显然存在显著的差异，例如，它们对约定的使用、底层协议以及支持使用这些约定的可用工具。我们在此总结关于这些主题的重要论点。各种立场的特征是我们自己的。

传统的价值。WS-RF和WS-Transfer方法的支持者认为，创建、访问和管理状态涉及一组公共模式，可以在一组规范中有效地捕获这些模式，从而简化使用这些模式的应用程序的设计、开发和维护。例如，在我们的作业管理服务中，这些提倡者可能会注意到以下几点:

• 作业的创建和后续管理自然可以被视为一些通用模式的实例(创建、访问、订阅、生命周期管理和销毁与作业相关的状态);而且
• 根据这些模式对作业管理接口进行编码，既简化了接口的设计(因为在其他规范中已经提供了其中的大部分内容)，也简化了对接口的解释。

他们还可能指出，通过“感知WS-RF和/或WS-Transfer”的客户端工具和应用程序，程序员的工作效率得到了提高。例如，注册中心或监视系统可以使用WS-RF操作访问服务状态，而不需要任何特定于应用程序的状态结构知识。²

相反，无惯例方法的支持者认为，任何特定接口(例如，用于作业管理的接口)的设计通常都相对简单，涉及到这些传统模式无法捕获的问题，并且不需要编码该模式的规范中包含的所有功能。因此，从基本原理出发，可以实现更简单的设计。例如，在我们的作业管理服务中，虽然WS-RF和WS-Transfer“免费”为我们提供了一个销毁操作，但我们仍然需要引入一个单独的暂停操作。此外，Destroy的语义可能非常特定于应用程序。例如，服务实现者可能决定保留关于“已销毁”作业的信息(通过将其状态更改为“已销毁”)，以便仍然可以检索有关作业的信息。在这种情况下，国家不会被摧毁。最后，WS-RF和WS-Transfer关注与单个状态的交互(例如，DestroyMultiple必须自定义)，因此在操作多个状态是常见情况的情况下可能无法提供有用的约定;例如，所有Amazon REST和Web服务都可以使用多个asin。

理想情况下，我们希望根据具体的指标(如代码大小)来评估这两个位置的相对优点。然而，这样的评估需要对接口应该支持的需求达成一致。不幸的是，不同方法的支持者对需求的看法也不尽相同。例如，公共模式的支持者可能认为能够使用WS-ResourceLifetime操作进行软状态生命周期管理是可取的，而其他人可能不认为该特性很重要。

标准。另一个争论的话题是标准化规范的重要性。不幸的是(但在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之上采用特定于领域的操作编码。

对围绕这些不同方法发生的辩论的分析强调了在分离技术、政治和风格方面的关切时所固有的困难。一些意见的差异与定义良好的技术问题有关，反映了关于系统设计的不同哲学或不同的目标应用程序。其他则涉及不同的目标时间范围。例如，no-convention的支持者最初反对使用WS-Addressing，因为在某些工具中缺乏对该规范的支持，而WS-RF和WS-Transfer的支持者则表示赞成，认为WS-Addressing最终将成为通用的。自那以后，对WS-Addressing的支持变得近乎普遍，现在很少有人对其使用感到反感。

回到顶部

致谢

我们非常感谢Karl Czajkowski、Jim Gray和Sam Meder对本文档早期版本的评论。不用说，不同论点的特征是我们自己的。第一作者的工作部分得到了美国能源部高级科学计算研究办公室数学、信息和计算科学部子项目的支持，合同W-31-109-Eng-38。纽卡斯尔的这项工作得到了英国科学计划的支持，经费来自EPSRC、DTI和JISC。

回到顶部

回到顶部

回到顶部