使用UML建模的复合RESTful Web服务

使用UML建模的复合RESTfulWeb服务摘要Web服务组合的过程涉及到不同的参与者在互联网上发布的web服务，相比于远程过程调用（RPC）Web服务而言状态代表性传输（REST）Web服务采取了不同的体系风格。在本文中，我们针对在Web服务组成的背景下的这些差异，激发引出RESTful接口的新设计技术的需求，我们提出了一个基于UML的建模方法的RESTWeb服务组成来为其静态和行为特征的组成建模。这些模型通过构造、作为规范文档的一部分，已经映射到多个Web实现语言和可以用来验证一个RESTful组成来提供了RESTful的组成。我们以酒店及机票预订RESTful的复合Web服务为例说明了这个方法的适用性。1刖言一个Web服务通过标准的网络协议向一个软件系统提供一个远程接口这些接口是处于机器能处理的形式，他们的功能不需要人的过多介入就能够被机器操控oWeb服务可以以远程过程调用（RPC）的方式发展，或者作为一个状态代表性传输（REST）Web服务。RPC风格的Web服务以操作为中心，他通过在其接口上设置操作说明来展现其功能。与此相反，REST风格的Web服务是以数据为中心的，他在其开源代码中展现其功能，这种源代码更像是类中的对象一样以能够控制的数据向目标服务传达信息。一个Web服务组合利用已经存在的Web服务提供构建在这些现存的Web服务顶端的新的功能。他使已经发布的Web服务的重用更为容易，把不同地方的不同已经发展的服务通过不同卖方组合成一个整体。精心安排服务对发展一个组合Web服务来说是一个通用的方法，在精心安排服务中，相关联的服务组合过程对其中的参与者是不可见的，有一个核心过程控制并协调相关联的Web服务的执行。对于RPC风格的Web服务，有BPEL4WS和WSCI等不同的流程组成语言存在，他们定义控制和数据流，这些控制和数据流决定何时应该执行某个特定操作。BusinessProcessExecutionLanguage（BPEL）是一种被用来实现一个Web服务组合的组成规范的语言此匕外，为了组建RPC风格的Web服务组合，也提出了许多建模方法。然而，RESTWeb服务按照不同的体系风格，因而他需要不同的设计理念和技术。一个RESTfulWeb服务是这样设计的，它的接口提供定址能力，连通性，统一的接口和无状态。因此，一个复合的RESTfulWeb服务也提供一个RESTWeb服务的基本特征。他应该展示他们地址和代表的资源，这些资源应该有连通性，提供统一的接口和在具体资源中调用一个方法的输出应该是能够被观察的。相比于RPC风格，RESTWeb服务的这个不同的设计理念需要新的设计技术。我们必须明白复合RESTWeb服务的资源和方法是如何映射到伙伴网络服务的资源和方法的。在此背景下，我们感觉我们需要一个可视化表示形式来帮助我们理解在产生复合RESTWeb服务的设计阶段，RESTful的特点是如何被处理的。本文中，我们提出了一个基于UML的建模方法通过构造来设计RETSTfulWeb服务。建模方法的使用方便了RESTful体系风格基本概念和设计需求与实现细节相独立的目标的理解。我们用类图、活动图和状态机图为复合RESTfulWeb服务的静态和动态行为建模。本文围绕组合过程的建模和其接口实现的精炼，我们力争以一种复杂方式传递基本概念时保持方法的简单。文章组织如下：第2部分提出了呈现工作的背景，第3部分给出了此方法的综述，第4部分给出了资源模式的概念，紧随其后的第5部分和第6部分给出了行为模式的概念。在第5部分我们呈现了过程模型，复合RESTful接口的建模将在第6部分中详细阐述。第7部分包含了相关的工作，第8部分推断未来要做的工作。2背景相比于与以操作为中心的RPC风格的Web服务，一个RESTful体系风格呈现出了一个数据为中心的行为。RESTful体系风格的主要特点有：可寻址能力，统一接口，连接和无状态。可寻址能力要求任何与服务相关的相关信息都要作为一种资源呈现，每个资源有一个或多个唯一地址和有一个或多个可远程访问的代表。为了实现连接，资源代表应该包含到其他资源的连接以至于通过资源和他们的连接形成的图形是相连接的为了达到统一的接口，所有资源在一个相同的方法集下操作。在HTTPWeb服务案例，其方法是GET（HEAD），POSE,PUT和DELETE。还有一个标准的状态代码或者异常的集合用于发送方法成功或者是失败的信号。无状态的特征要求一个方法是其输入参数和可寻址资源的函数。这就是说，没有隐藏的会话或者是状态信息。此外GET，POSE,PUT和DELETE操作的效果在影响资源时应该能够被观察到。这些特征使得RESTfulweb服务与因特网上现存的工具和基础设施相处融洽，互联和统一接口的特征允许利用现存的工具和基础设施如rawlers,curl,caches等等，可寻址要求（特别是使用层次化地址时）帮助我们创造可扩展的veb服务。无状态要求简化可以同时处理很多的服务请求的便于扩展的系统的发展。当前，RESTfulweb服务在网页中广泛的被采用，现在已经有大量的使用者，其中包括Google，Yahoo，Amazon和Flicker一个web服务组合过程结合不同位置的可能可用服务和不同发布者可能发布的服务来提供新的web服务，这些web服务组合常常假定被业务目标所驱动和用一种流程规范语言分开描述。这些复合web服务像一个黑盒子提供给最终用户，仅仅通过操作所声明的接口才能调用他们。一个接口的规范仅仅包含关于他们能够被调用的操作的句法信息，信息能够在服务之间被交换的流程用一种流程规范语言分开描述。对于RPC风格的web服务，网页服务描述语言2.0（WSDL）常常用作接口规范，WSDL提供关于一个服务允许和定义的在服务操作之间作为信息传递的数据的操作信息接口规范语言是句法的，方法调用顺序的信息被如BPEL4WS的流程规范语言所定义。然而，一个RESTful组合服务必须展示RESTful体系的特征，下面为RESTfulBPEL流程的定义列出了三种可能的机制：WSDL2.0对HTTP的绑定：用标准的BPEL4WS描述（如调用操作）和通过综合的WSDL2.0描述引导调用。在WSDL绑定中，操作被映射到URLs和HTTP方法（如操作映射成资源1和PUT方法）。REST通过适配器:从一个标准的BPEL过程通过产生仿造的WSDL来用RESTful服务，这个仿造WSDL描述REST接口，然后产生一个RESTful服务通信的适配器。某些BPEL引擎通过WADL描述也支持交互。为REST扩展BPEL:扩展BPEL（和BPEL引擎）为了其直接支持RESTful活动（如在一个特定的范围内支持GET,PUT,POST,和DELETE活动）。方法1和2的优势在于对BPEL语言不需要任何的修改和目前实现的BPEL引擎。另一方面，WSDL是面向操作的web服务的一种描述语言，他没有完全遵守面向资源的RESTful服务的语义。在［12，10］，Pautasso用第三种方法，他建议为7REST而扩展BPEL。这种方法有几个优点，比如，支持后期绑定和动态资源。在传统的PEL_WS过程中，不支持服务的动态绑定，作为服务的末端点是开始就决定了的，任何的改变都需要客户改变或者更新他们的WSDLs。这样，这是在第三种方法中这是一个重要的优势。这里我们总结BPEL_WS和BPEL_REST的主要的不同点，正如C.Pautasso在［12,10］中提倡的那样。在BPEL_WS中，只定义了一种活动调用类型，在BPEL_REST中对每个HTTP操作都定义了一种不同的活动调用。BPEL_REST引入了资源的概念，资源概念允许定义和发布资源。他定义运行消息处理，这在资源的范围内是可用的。请求处理器的内部行为可以用标准BPEL构造指定(也就是<sequence>,<if>,<flow><while>etc.)。然而，属于不同处理器的跨活动的控制流连接是不允许的。我们利用这部分呈现出的关于RESTfulweb服务组合的信息去呈现一种建模方法，这种建模方法简化RESTfulweb服务的概念和他们的组合过程。在下一部分中，我们提出了我们的建模方法的一个综述，这个建模方法是利用JML为复合RESTfulWEB服务的设计进行建模。3综述本文中，我们提出了一种支持RESTfulweb服务组合的建模方法。我们要求这个RESTfulweb服务组合应该展示REST接口的特征，比如：可寻址能力，连接性，统一接口和无状态。由于不是从操作的视角组合web服务网络，RESTful风格的web服务组合与传统的web服务组合技术不同，RESTful组合聚焦于资源。RESTfulweb服务把资源作为构建的基础，在典型的REST发展环境，为了保持设计简单和允许最大化的去耦合，新资源是可见的。这样，RESTful组合web服务必须考虑不同搭档服务的资源和如何标准化组合web服务在搭档web服务上调用相应操作的方法调用。在我们的先前工作中，我们已经提出了一个为RESTfulweb服务建模和产生行为接口规范的方法。在这篇文章中，我们把我们的工作扩展到支持复合RESTfulweb服务。我们为复合RESTfulweb服务的静态和动态特征建模，我们的建模方法如图形1所示。我们以表现复合RESTfulweb服务静态特征的资源概念性模型开始。资源概念性模型通过一个类代表一个资源的类图来呈现，他提供有关资源的可用性，他们的代表，相关地址和连通性的信息。这时我们用这个资源概念性模型建模我们的组合过程RESTful服务的组合行为首先描述为用顺序图，然后处理流程转化为活动图。处理流程表现为过程发送信息，过程接受信息。最后，这个过程的信息精化成为一个状态机这个状态机提供有关组合是如何被定义的和实现和组合的使用来提供RESTful行为的限制的详细信息。我们假设搭档服务是RESTful的，他们的资源模型是可用的或者在组合过程用他们之前能够建立好。这种假设在为组合web服务提供RESTful接口时为我们提供帮助。由于为了知道搭档服务提供的功能使他们成为组合过程的一部分，我们首先必须理解搭档服务，所以我们认为这不是一个有力的假设。这个模型被认为是web服务规范文档的一部分，他不需要任何的来自复合RESTfulweb服务(CRWS)的额外支持。我们运用了一个酒店和航班预订服务组合的例子，他用于房间预RESTfulweb服务和航班预订RESTfulweb服务。这个组合服务并行的提供了预定房间和航班的服务，向用户提供总的需要支付的款项和提供付款确认信息。预定可以被取消除非是正在等待第三方的服务确认。取消的预定可以被删除。在下以部分中，我们为CRWS呈现了资源概念性模型。4资源概念性模型RESTfulweb服务的资源概念性模型显示了有关的资源，资源代表的属性，资源之间的连接和从一个资源到另外一个资源的导航路径。UML类图建模RESTful复合web服务的结构特征。我们酒店和航班预定服务组合的资源概念性模型如图2所示。他自己有五个资源，即预定HF，取消HF预定，支付HF款项和证实HF预定，两个来自其搭档的web服务，即预定酒店和预定航班。资源之间的关联显示资源之间的连接。我们要求在图形中没有孤立的资源，所有资源形成了一个联通图。关联的箭头提供了导航的方向，关联的角色定义了从一个资源到其他资源的导航路径。如为了到达资源取消HF，我们要跟随如下路径/预定HF/{bid}/取消HF/。搭档web服务资源可以从搭档资源连接到CRWS资源进行导航。如酒店预定服务的支付资源可以用如下路径导航：/预定HF/{bid}/预定F/{bid}/支付7。集合资源形式化表示为《collection》，他包含一系列的资源。在图2中，预定HF资源是一个集合资源，其GET方法将返回所有预定资源的列表（预定HF）。这些资源被认为是我们概念性模型的主要资源其他所以资源的导航都要通过他为了结合搭档web服务的资源，这个组合服务的主要资源通过所有其他资源的导航被连接至搭档服务的资源。在图5,CRWS的预定HF分别与搭档服务的预定航班和预定酒店相关联。1在搭档web服务关联结束的多样性意味着在HFCRWS上做的预定必须是对房间和航班都有预定。和搭档web服务的资源的关联显示了在CRWS设计中的连接和可寻址能力的特征。因为空间的限制，我们没有展示搭档web服务的概念性资源模型。图1：基于模型的RESTful组合的方法除了搭档web服务的资源，复合RESTfulweb服务拥有自己的资源。这些资源在概念性模型中被建模成类。这些资源的描述被当作公共属性展示。资源的建模属性公开指明表示资源描述的公开的操控。取消HF,支付HF,和确认HF保持通过组合服务接口所做预定的记录，这些资源中的方法所能被调用的信息在概念性模型中没有被展示，因为我们认为他们在这里是必须的。这是因为标注的HTTP方法，GET,TUT,POSE和DELETE，能过被任何资源所调用。概念性模型提供CRWS的架构布局。我们用这个架构模型去表示我们在第5和第6部分的行为模型。下以部分，陈述RESTful过程建模。5RESTful过程建模在WS_BEPL过程建模时，UML活动图和BPMN的符号相同。提议WS_BPEL概述UMLProfile用老的BPEL1.0规范和UML1.4，但是对于如何把BPEL_WS过程映射到UML活动图提供了指导。UML2.0概述WS_BPEL也已经被提出来了。Ruokonen等在［15］中的先前工作展示了为创建BPEL_WS活动模型的基于UML的方法，这方法能产生可执行的BPEL_WS描述。通过结合已经存在的工作，我们致力于提出模型构建，为BPEL_REST过程给出UML活动图。我们的目标是利用在概念性模型中定义的资源为预定航班和酒店RESTful过程建模。过程的场景，预定航班和酒店，如图3所示，预定HF是一个过程，他是作为RESTfu组合服务而被实现的。另外，预定HF实用三个外部的RESTful服务：预定酒店，预定航班，支付款项。实际的资源结构在图中没有展示出来，他仅仅描述了过程和他的参与者的交互。在概念性模型中，如图2所示，所有资源都被定义了，但是这里我们仅仅对服务交互进行建模。然而，从URI结构，我，可以看到/预定HF和确认HF是预定HF的子资源，。这样，他们是预定航班和酒店服务提供的接口的一部分。从场景模型，我们想要创建一个实现了预定酒店和航班场景的过程描述。我们的目标是一个与BPEL_REST兼容的过程模型。为了构建这个过程模型，我们在会话中以预定HF服务的视角建模。这意味着通过预定日卜服务发送和接受信息。顺序图发送消息的事件在活动图中表现为调用，而接收消息事件意味着过程接收了一个操作调用。在图4中，预定酒店和航班过程的一个面向工作流的模型作为活动图被展示出来。这和传统的建模BPEL过程是一致的。每个操作都可以被调用的条件在工作流描述中定义，包含用户交互的是工作流°POST/预定HF和POST/预定HF/支付HF被用户调用。这意味着过程执行之前必须要等待用户的输入。下面列表展示了在建模PBEL_REST过程中如何用UML模型结构。图2：HF复RESTfulWeb服务的概念性模型

:Cufitonvr:Dookingel-IP:Qo^king'SPIight:快okingsRowl:Cufitonvr:Dookingel-IP:Qo^king'SPIight:快okingsRowl::Paym顽5：|6：('payrnenii-r)|rt7:POSTr/tjiMKingsHFp^irnaioiHF^►BPEL_REST与UML活动图的映射：HTTP调用get,put,post,和delete被建模成调用行为活动X分别是原语feet》,《put》《post》，《delete》）onPut,onGet,onPost,和onDelete活动。onPost建模成一个调用行为活动（原语6nPost》）onGut建模成一个调用行为活动（原语©nGut》）onPut建模成一个调用行为活动（原语©nPut》）onDelete建模成一个调用行为活动（原语6nDelete》）responset建模成一个调用行为活动（原语《responset》）sequence建模成一个控制流和BPEL_WS的onMessage不同，RESTful消息处理可以有内部结构，这样他们也可以被建模成包含response活动和可能包含一些其他的if-else结构的结构化活动。另一方面,onPut和response可以被建模成一对简单的活动，他们之间可能隐含活动的顺序。相同的应用当然可以用于其他的信息处理。由于模型的局限性，属于不同信息处理器的横跨活动连接是不被允许的。活动模型的资源可以被建模成结构化的活动，他包含他所支持的所有信息处理器。然而，我们的目标是简化工作流模型，在活动图中到处我们想要的行为。服务组合，如复合服务，相比BPEL过程作为复合服务，观点上有轻微的不同。例如，如果我们想建立预定酒店和航班过程或者一个相同目标的组合服务，其使用的方法是有一些不同的。更加明显的，将会用到不同的建模方法°BPEL过程从一个参与者的视角描述会话，如，过程本身。这里，我们决定在活动图中仅仅建模一个纯净的工作流。为了使过程模型完整，资源结构的建模在第6部分给予考虑。图4：预定酒店和航班过程6建模复合RESTful接口我们用UML状态机为CRWS的行为模型建模。他提供了web服务的行为接口规范和定义了方法调用的正确顺序，基于方法应该被调用的条件和这些方法的与其条件。在前面部分展示的过程模型。在RESTful组合过程中提供活动流信息。在这部分，我们精化活动图到状态机。在精化步骤中，发送信息(过程调用)映射成状态机的实体活动。活动图的接收消息(过程接收信息)被映射成状态机的状态转换。我们要求每个状态有一个布尔功能，如：一个状态不变量，当给定状态是活动的他就we哦真，否者为假。转换导致系统状态的改变并表示为箭头，方法调用表示为转换的加速。转换调用前要求满足的条件被标记在箭头上作为指导，完成一个转换的预期条件在转换中被有效的注释出来。以前，我们利用UML协议的状态机去描述每个web服务的行为接口。现在我们扩展我们的状态机到搭档资源的动作和资源信息来展示复合RESTfulweb服务的完整的行为接口。图5展示了我们HF预定复合服务的行为模型。在状态层次的顶层，状态机有一个标准的状态——取消HF，和一个组合状态——预定。在资源预定F针对状态预定中，状态机被初始化为POST方法。组合状态预定，是三个组合状态的更深组合，即reserveandpay,waitingforpconfirmatioi和pconfirmationinfo酒店房间和航班的预留和支付是并行做的。在状态reserveandpa和waitingforpconfirmatioi被正交状态所展示。这就意味着仅仅在这两个服务已经支付的基础上第三方的服务才会被调用以确定支付。支付的确认来自搭档服务的个体的支付服务。除了在等待第三方确认的时候之外，预定任何时候都可以被取消。当一个取消预定被删除时，他也分别删除了酒店预定和航班预定服务的记录。行为模型的每个状态都包含了一个状态不变量。我们状态机的状态不变量是布尔表达式，他也考虑了HTTP方法的响应代码。当我们在资源上调用HTTP方法时，他返回一个响应代码。这个响应代码告诉发送者这个请求是成功还是失败。响应代码00指定方法调用成功，响应代码404指定方法调用不成功和请求的资源不存在。我们行为模型的状态不变量是基于比较资源中GET方法的响应代码和异常的响应代码oOK(r)代表在资衡上GET的响应代码为200。NOT_FOND代表在资源r上GET的响应代码为404。例如，让我们考虑图5所示的组合状态预定的状态不变量，即，OK(bHF)&&OK(bF)&&OK(bH)&&OK(r)&&OK(f)&&NOTFOUNKcHF)。他是由OK(r)和NOT_FOUND(r)在HF复合服务的资源上的功能和调用搭档web服务所组合的布尔表达式。图5中的状态机仅仅在上面的布尔表达式的值为真时能够变成预定状态。子状态的状态不变量由子状态的状态不变量联合他包含的所有状态的状态不变量给出。例如，子状态reserverdnotpaid的状态不变量NOTFOUND(pcHF)&&NOTFOUND(pcF)是联合他所包含的所有上层状态的状态不变量来得到eserverdnotpaid的状态不变量的。在行为模型中方法的调用描述为了得到相应功能方法应该被调用的顺序这限制我们的CRWS提供所需要功能的实现。例如，如图5所示，只有在支付资源的POST已经调用时，确认资源上的POST才能够被调用。在我们的概念性模型中，我们也没有包含方法由于RESTfulweb服务提供统一接口和每个资源用标准的HTTP方法GET,PUT,POST,DELETE操作而能在资源上调用方法的信息。我们现在针对在行为模型资源上允许的方法。在行为模型上显示资源上允许的方法和方法能够被调用的条件。例如，除非我们创建了取消IF资源，否则我们不能在预定上调用DELETE操作。这样，我们可以说我们的行为模型不仅限制复奇ESTfulweb服务的实现，也限制服务的使用。我们要求GET方法可以在任何资源上被调用。bH:陶心氓制呼师用/bF：itic<rfdrq5HEibtt>kirKi5FqbTdltoCikulgsHF^jS：fciiii^HFuF.心kHbH:陶心氓制呼师用/bF：itic<rfdrq5HEibtt>kirKi5FqbTdltoCikulgsHF^jS：fciiii^HFuF.心kH图*1巳IkjukiIig讦W感VwnIFpHF;SokingGHFribidl灿ymRnXpH:他奶ibg计IFltJuuklr中Wfg祚■呵pF.(bookingitH^ibocjIyncj^F^JbidypaTi'i'wi'iFJpcHF;mofcl叩sHFffb•曲MF.pcunflrrnalknMFREhi:沁puKingstVjbKl*囹Ihni祜ligriHptF.^KKikiiTgsfrFi^hidFp^^^^F.rpcKiririirnaliu-iF在复合RESTweb服务上调用方法会出发相应搭档Web服务资源上的方法。我们通过实体动作或者作为有效的转换对搭档web服务上的风发调用建模。被加入到状态的实体动作是无论是否进入状态都要被执行的行为。国，不论在预定HF上POST是否被调用，都进入状态预定，转换POST(bH)和POST(bF)都将被调用。转换也在搭档veb服务作为在复合web服务调用方法的结果而被加速也可以标记在转换上，这样，万一目标状态是结尾状态，，他就不要包含实体动作。在幽中，加速方法DELETE(bHF)对在搭档web服务酒店预定和航班预定上的方法调用)ELETE(bH)和DELETE(bF)分别产生影响。状态机上不同的元素可以被3RWS用来表示行为展示，状态reserveandpay和waitingforconfirmatior的联合转换显示除非房间和航班都支付过来，否则不能进入目标状态waitingforconfirmation相似的，在状态pconfirmationinfO状态的选中节点调用目标状态依赖于转换上的指导条件。我们可以用如分支转换，自转换，高层转换等等的状态机的不同元素来提供RESTfulweb服务接口的丰富的行为规范。我们认为利用状态机的不同元素可以为接口提供丰富的行为信息。拥有丰富行为信息的行为模型可以作为规范文档，在实现接口时指导复合web服务的发展。这个丰富的行为模型也可以用于产生合约和机器能够处理的规范。