英语原文共 8 页

实现自动的RESTful Web服务组合

赵海波，Prashant Doshi LSDIS Lab, Dept. of Computer Science

University of Georgia

Athens, GA 30602

{zhao,pdoshi}@cs.uga.edu

摘要

rest式Web服务作为领先的互联网公司公开内部数据和资源的流行选择，正在业界引起越来越多的关注。虽然基于WSDL/SOAP的Web服务组合的自动化在研究社区中得到了广泛的研究，但是就我们所知，在面向服务的体系结构(SOA)的上下文中，基于rest的Web服务组合的自动化很少得到研究。作为解决这个问题的早期文章，本文讨论了组合RESTful Web服务的挑战，并提出了一个用于描述单个Web服务和自动化组合的正式模型。本文通过将其应用于实际的RESTful Web服务组合问题，演示了我们的方法。本文代表了我们在自动RESTful Web服务组合问题上的初步努力。我们希望它能吸引Web服务研究社区的兴趣，并让更多的研究人员参与到这一挑战中来。

1介绍

由Fielding[5,6]提出的代表性状态转移(REpresentational State Transfer, REST)原则支持了万维网(World Wide Web, WWW)的发展。REST的原则包括:(1)将概念实体和功能建模为由通用资源标识符标识的资源。(2)通过标准化、众所周知的HTTP操作(GET、POST、PUT和DELETE)访问和操作资源。(3)系统组件通过这些标准接口操作进行通信，交换这些资源的表示(一个资源可以有多个表示)。在REST系统中，服务器和客户端通常通过跟踪资源之间的链接来遍历资源表示的不同状态。

通过应用REST Web服务(WS)的原则,基于rest的WSs[13]开发正在成为许多领先的互联网公司的首选，它们可以将内部数据和功能作为URI标识的资源公开。与WSDL/SOAP WSs的以操作为中心的透视图相反，RESTful WSs从以资源为中心的透视图来查看应用程序。RESTful WSs的一些优点包括:

轻量级:RESTful WSs直接利用HTTP作为调用协议，避免了不必要的XML标记或api和输入/输出的额外封装。响应是资源本身的表示，不涉及任何额外的封装或信封。因此，rest式WSs比WSDL/SOAP WSs更容易开发和使用，尤其是在Web 2.0上下文中。此外，它们更少地依赖于实现HTTP之上的额外SOAP层的供应商软件和机制。RESTful WSs由于其轻量级的特性，通常能够提供更好的性能。

易访问性:用于标识RESTful WSs的uri可以共享，并将其传递给任何专用服务客户机或通用应用程序以供重用。uri和资源的表示是自描述的，因此很容易访问RESTful WSs。RESTful WSs已被广泛用于构建Web 2.0应用程序和mashup。

可伸缩性:RESTful WSs的可伸缩性来自于它在uri上支持缓存parallization/partitioning的能力。GET的响应(一个无副作用的操作)可以缓存，就像web页面当前缓存在代理、网关和内容传递网络(CDNs)中一样。此外，RESTful WSs提供了一种非常简单有效的方式来支持基于URI分区的负载平衡。与SOAP接口背后的功能的特别分区相比，基于uri的分区更通用、更灵活，并且更容易实现。

声明性:与从操作的角度来看命令式服务不同，RESTful WSs采用声明性方法，并从资源的角度来看应用程序。声明性意味着RESTful WSs关注于资源本身的描述，而不是描述函数是如何执行的。声明式风格将RESTful WSs和WSDL/SOAP WSs之间的根本区别提到了前台。在为特定系统构建服务时，声明式方法关注需要公开哪些资源以及如何表示这些资源;命令式方法侧重于需要提供哪些操作，以及这些操作的输入/输出是什么。声明性方法被认为是构建灵活、可伸缩和松耦合的SOA系统的更好选择。

上面提到的rest式WSs的特征使自动的rest式Web服务组合成为一个与WSDL/SOAP WSs的组合问题完全不同的问题。尽管研究团体已经在WSDL/SOAP WSs自动化方面投入了大量的精力，但是就我们所知，对基于rest的Web服务自动组合问题的研究还很少。在本文中，我们概述了这个特定问题的挑战，并介绍了我们在实现RESTful Web服务组合自动化方面的初步工作。我们在本文中的主要贡献是引入了对RESTful Web服务组合问题的正式描述。在分析此问题所涉及的差异和挑战的同时，我们提出了一个用于对RESTful WSs进行分类和描述的形式化模型，并提出了一种基于态势演算[10,12]的状态转换系统，用于对其进行自动组合。

本文的其余部分组织如下。我们在第2部分中描述了一个激发性的场景，该场景将作为一个运行的示例来解释我们针对单个WSs的建模方法和建议的组合方法。在第3节中，我们介绍了一个用于分类和描述单个RESTful WSs的概念模型。第4节详细介绍了构建RESTful WSs的理论框架。我们引入了一个定制的状态转换系统，并解释了该系统的构成。我们将详细介绍拟议的框架如何处理第2节中提到的在线购物场景。在第5节中，我们还简要比较了WSDL/SOAP WSs和RESTful WSs的组合。最后，我们通过讨论RESTful Web服务组合中涉及的挑战来结束我们的工作，并在第6节中提出我们未来的研究方向。

2场景:B2C网购

在本节中，我们将介绍一个简化的在线购物场景。注册客户向系统下订单，一个客户可能在系统中有多个订单。在收到付款之前，订单不会被处理。一次付款确认后，系统处理订单并将订单发送给客户。此系统打算使用WSs实现，以便外部业务合作伙伴或第三方Web 2.0应用程序可以使用它。我们希望使用WSs公开每个功能组件。

图1所示.简化的在线购物场景

处理这个应用程序的必要方法是从功能分解开始的。一种解决方案是公开远程过程调用(RPC)样式的WSs，如下所示:

表1.RPC样式的WSs列表

3 RESTful WSs

在本节中，我们将介绍RESTful WSs的分类，并提出一种概念建模方法来描述所识别的WSs类型。与基于WSDL/SOAP的WSs不同，RESTful WSs没有公认的模型或描述语言。为了方便自动组合，我们为RESTful WSs提供了一个基于本体的正式模型，该模型处于概念级别，可能受本体语言的限制。

3.1 RESTful WSs的分类

与RESTful服务相关的大多数资源都可以直接映射到域资源——要么是一组资源，要么是单个资源。除了这两种类型之外，我们还确定了第三种RESTful WSs——这些服务使用一些资源或操作相关资源，它们不能直接映射到域资源或资源集合。我们称之为过渡平静WSs。与其他两种类型相比，这种RESTful WSs的声明性更弱，当我们采用以资源为中心的方法设计WSs时，应该尽量减少使用这种类型的服务。但是在某些情况下，我们确实需要过渡的RESTful WSs，正如我们在第2节中提到的使用应用程序场景所展示的那样。

类型I:资源集服务 这种类型的服务映射到一组域资源。在线购物场景中，可以同时考虑与一组客户和一组订单相关的资源。我们分别将它们命名为CustomerSet和OrderSet。类型I rest式Web服务可用于捕获概念级资源或实例资源集。这种类型的服务支持所有四种HTTP操作(GET、PUT、DELETE和POST)。

类型II:单个资源服务 单个域资源可以使用此类服务建模，此类服务表示资源集中的单个资源。例如，在场景中，单个客户和单个订单映射到该类型。单独的支付和发货也被认为是与订单和客户相关的类型。类型II rest式Web服务可用于捕获实例级资源，它支持三种HTTP操作(GET、PUT、DELETE)。这里不适用POST操作，因为已经创建了URI标识的单个资源。

类型III:过渡服务 尽管大多数RESTful WSs都映射到域资源或资源集，但其中一些服务更倾向于转换或面向转换。此类服务的功能松散地定义为使用资源、创建资源和更新或转换相关资源的状态的服务。例如，场景中的SubmitPayment和ShipOrder就是这种类型的。当我们使用订单信息调用submitpay时，我们将创建一个与此订单相关的新资源支付，并将订单资源的is-Paid属性(表示支付状态)从“false”更新为“true”。需要采取类似的步骤对于Web服务ShipOrder也是如此。类型III的Web服务可用于捕获面向转换的功能，它只支持后期操作。

在下一小节中，我们将提供详细的建模方法来描述上述WSs类型。

3.2 RESTful WSs建模

通过标识这些RESTful WSs类型，我们以资源为中心来查看原始场景。图2显示了建模在线购物场景所需的声明性WSs的列表。在本节的其余部分中，我们将提出一个基于本体的概念模型来描述这些标识的RESTful WSs。这个模型将在第4节中用于构建我们的自动组合框架。

要将资源公开为特定领域的RESTful WSs，直观的做法是创建Web服务资源和领域本体资源之间的关联。其思想是声明式RESTful方法将每个服务建模为一个资源，因此WSs的描述本质上就是资源的描述和这些资源的“状态转移”。当我们将RESTful WSs分为三个类时，我们分别解释了它们的具体建模。一般来说,

(1)类型I RESTful Web服务是同一概念的一组本体实例，“集合”本身也可以被视为资源。在将GET、DELETE和PUT操作应用于类型I rest式Web服务时，它将分别获取、删除和更新这个概念资源的表示形式;应用POST操作将在资源集中添加这个概念的新实例资源。

(2)类型II rest式Web服务直接映射到本体实例。类型I和类型II RESTful WSs直接使用本体中的映射资源建模。将GET、DELETE和PUT操作应用于类型II rest式Web服务将基于这些HTTP操作的标准语义获取、删除和更新相应实例资源的表示。后置操作不适用于第二类服务。

(3

资料编号：[4251]