CN104247333A

CN104247333A - 用于基于网络的服务的管理的系统和方法

Info

Publication number: CN104247333A
Application number: CN201280070693.0A
Authority: CN
Inventors: 迈克·哈默; 阿希什·达勒拉; 莫妮可·莫罗; 彼得·汤姆苏
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2011-12-27
Filing date: 2012-12-21
Publication date: 2014-12-24
Anticipated expiration: 2032-12-21
Also published as: CN104247333B; EP2798784B1; WO2013101765A1; US20130166703A1; EP2798784A1; US9450836B2

Abstract

在一个实施例中，系统包括配置成接收从第一客户发送的对由第一服务提供商提供的第一服务的第一请求的接口，第一请求是第一类型的。所述系统还包括配置成响应于接收第一请求从与第一服务提供商相关的第一策略确定第一组配置参数的至少一个处理器。至少一个处理器还响应于接收第一请求使用第一组配置参数使得与第一服务提供商相关的节点提供第一服务。

Description

用于基于网络的服务的管理的系统和方法

相关申请

此申请要求2011年12月27日提交的并且以参考的方式结合在此的标题为“改进的联网”的美国临时专利申请序号61/580,564的优先权。

技术领域

本公开一般涉及计算机网络，并且更具体来说涉及用于基于网络的服务的管理的系统和方法。

背景技术

在基于网络的服务提供中，某些提供商遵循暴露低层应用程序接口(API)并且允许开发者构建定制服务的方法。这种方法将服务创建的复杂性从提供商推给服务的客户。客户投资构建定制解决方案并且负责服务的设计。如果服务提供商决定将这些定制解决方案作为其产品的一部分并入，则复杂性迅速增长。复杂性随着独特组合的数量线性地增长并且随着组合内的服务数量以指数方式增长。复杂性的迅速增加使得服务脆弱且难以修改。

大部分云服务使用HTTP网页服务(SOAP和REST)来分发服务信息以及存取和管理服务。此模型具有缺点。第一，HTTP并非设计用于服务发现和发布，而是仅在它们通过其他装置发现之后连接到主机。第二，HTTP并不与数据包处理中的策略交互。服务数据包需要策略路由并且可以基于策略来修改。第三，为了认证、授权和记账(AAA)，所有HTTP数据包必须在一些代理处被拦截(或终止)。

发明内容

在一个实施例中，系统包括配置成接收从第一客户发送的对由第一服务提供商提供的第一服务的第一请求的接口，第一请求是第一类型的。系统还包括配置成响应于接收第一请求从与第一服务提供商相关的第一策略确定第一组配置参数的至少一个处理器。至少一个处理器还响应于接收第一请求使用第一组配置参数使得与第一服务提供商相关的节点提供第一服务。

在一些实施例中，第一请求可以包括与第一服务相关的点分十进制名称。至少一个处理器还可以进一步配置成证明第一请求符合与第一类型相关的一组规则并且通过将第一请求与关于第一服务的信息相比较来验证第一请求。第一请求可以包括第一部分，该第一部分包括与如何实施第一服务无关的信息。第一请求还可以包括第二部分，该第二部分包括与如何实施第一服务有关的信息。

在一个实施例中，由至少一个处理器执行的方法包括接收从第一客户发送的对由第一服务提供商提供的第一服务的第一请求，第一请求是第一类型的。方法还包括响应于接收第一请求从与第一服务提供商相关的第一策略确定第一组配置参数。此外，方法还包括响应于接收第一请求使用第一组配置参数使得与第一服务提供商相关的节点提供第一服务。

取决于所实施的具体特征，特定实施例可以呈现以下技术优点中的一些或所有，也可以不呈现以下技术优点。服务部署可以跨客户和服务提供商边界。每个客户或服务提供商可以能够强制执行针对入口和出口处的服务使用的策略规则。如另一个实例，可以在网络中定义分开的服务相关和服务无关功能。从以下附图、说明书和权利要求，其他技术优点对本领域技术人员来说是显而易见的。

附图说明

现在结合附图对说明书进行以下描述，其中相同参考数字表示相同部分，并且：

图1示出了允许基于网络的服务提供商之间的互操作的系统的一个实施例；

图2示出了可以用于图1中描绘的系统的操作中的示例性数据包；

图3示出了能够分支工作流的系统300的一个实施例；

图4示出了分级命名方案的一个实例；

图5示出了用于发现服务节点的消息流；

图6示出了用于用户发现代理的消息流；

图7示出了用于代理发现另一个代理的消息流；

图8示出了提供服务的消息流；

图9示出了用于有状态服务移动性的消息流；

图10示出了用于无状态服务移动性的消息流；

图11示出了用于应用之间的中间件通信的一个示例性系统；以及

图12示出了适用于实施具体实施例的一个或多个部分的一个示例性计算机系统。

具体实施方式

图1示出了允许基于网络的服务提供商之间的互操作的系统100的一个实施例。系统100包括接收由服务节点132、134、136和138提供的基于网络的服务的客户节点102、104、106。客户节点102、104、106分别联接到辅助管理从服务节点132、134、136和138接收到的服务的代理112、114和116。工作流节点122、124和126分别联接到代理112、124和116，并且促进由服务节点132、134、136和138提供的服务的使用。代理112、114和116联接到定位代理118(与定位工作流节点128相关)。代理142、144和146(与服务节点132、134、136和138相关)也联接到定位代理118。当从代理112、124和116中的一个接收与由服务节点132、134、136和138中的一个提供的服务相关的消息时，定位代理118用以标识代理142、144和146中适当的一个。服务节点132和134位于数据中心190中，而服务节点136和138位于数据中心192中。在所述实施例中，服务节点132联接到代理142；服务节点134联接到代理144；并且服务节点136和138都联接到代理146。工作流服务器156联接到代理146。

系统100描述了通过一个或多个电子网络联接的各个节点。这些网络可以使用自组织网络、个人局域网(PAN)、局域网(LAN)、广域网(WAN)、城域网(MAN)和/或因特网的一个或多个部分来实施。这些网络中的一个或多个的一个或多个部分可以是有线或无线的。作为实例，网络可以使用无线PAN(WPAN)(例如，蓝牙WPAN)、WI-FI网络、WI-MAX网络、长期演进(LTE)网络、蜂窝电话网(例如，全球移动通信系统(GSM)网络)或其他适合的无线网络中的一个或多个来实施。

在一些实施例中，数据中心190和192可以代表用来存放由使用如上所述的一个或多个网络的客户节点102、104和106使用的多个应用的硬件设备的集合。数据中心190和192可以包括允许通信会话的一个或多个网络。多个服务提供商可以使用数据中心190和192的基础设施的各方面来提供服务。例如，服务提供商可以与和数据中心190相关的实体具有协议，其中服务提供商可以使用服务节点132和134中的一个或多个来提供一个或多个服务。因此，在一些实施例中，多个服务提供商可以利用数据中心190的相同硬件源或者可以驻留在相同网络或子网络上。可以使用虚拟化技术来为多个服务提供商提供访问数据中心190和192的物理硬件源。例如，服务提供商的服务可以使用虚拟机来实施。

在一些实施例中，客户节点102、104和106可以是由使用由服务节点132、134、136和138提供的服务的实体(例如，用户或服务提供商)使用的节点。作为实例，客户节点可以代表终端用户、从其他服务提供商获得服务并且将它们与其自己的服务组合的服务提供商或者聚合来自多个提供商的服务的第三方服务提供商。例如，进入与服务提供商的协议以获得关于其用户的云服务的商业实体可以由客户节点102、104和106代表。作为另一个实例，客户可以是购买云服务的企业。在一些实施例中，客户可以定义用于服务的策略并且可以认证其用户。客户节点可以使用计算机、工作站、电话、因特网浏览器、电子笔记本、个人数字助理(PDA)、平板计算机或任何其他适合的设备(无线、有线或以其他方式)、组件或能够接收、处理、存储或与系统100的其他组件传送信息的元件来实施。作为实例，可以是智能电话、台式计算机、膝上型计算机或IP电话。系统100可以包括可以由任何适合数量的用户操作的任何适合数量的客户节点。存储在客户节点的存储器中的信息可以各自使用用于存储和检索信息的任何适合的结构来实施。数据库、文件系统、表格、列表或这些结构的适合的组合是可以如何存储这些信息的实例。可以使用计算机可读永久存储介质，诸如：基于半导体的或其他集成电路(IC)(例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘、HDD、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、其他适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

在一些情况下，服务节点132、134、136和138中的每一个可以是提供服务的硬件或软件实体(例如，虚拟机)。服务可以是硬件资源(例如，计算机、网络、安全、存储或其他适合的服务)、平台和中间件资源(例如，HTTP服务器、应用服务器框架、数据库、消息传送中间件或其他适合资源)以及应用(例如，供应链、通信、合作、电子政务或其他适合的应用)。服务提供商可以是根据一些商业协议对云客户和用户(例如，客户节点102、104和106)的云服务的供应商。作为一个实例，服务可以是可以由客户或用户为其个人使用所拥有的硬件或软件产品的虚拟实例。在这些计算系统中的一个或多个上运行的软件可以执行本文描述或说明的一个或多个方法中的一个或多个步骤或者提供本文描述或说明的功能性。这些计算系统可以是任何适合的物理形式。作为实例而并非为了限制，计算系统可以是虚拟机(VM)、嵌入式计算机系统、片上系统(SOC)、单片计算机系统(SBC)(例如，模块化计算机(COM)或模块化系统(SOM))、台式计算机系统、膝上型或笔记本计算机系统、交互式自助服务机、大型机、计算机系统的网格、服务器、应用服务器、路由器、交换机或这些中的两个或更多个的组合。在适当的情况下，计算系统可以：是单一的或分布式的；跨多个位置；跨多个机器；或者驻留在计算云(例如，计算系统的联网集，其可以将一个或多个云组件包括在一个或多个网络中)中。在适当的情况下，一个或多个计算系统可以执行(基本上没有空间或时间限制)本文描述或说明的一个或多个方法中的一个或多个步骤。作为实例而并非为了限制，一个或多个计算系统可以实时或以批量模式执行本文描述或说明的一个或多个方法中的一个或多个步骤。在适当的情况下，一个或多个计算系统可以在不同的时间或在不同的位置执行本文描述或说明的一个或多个方法中的一个或多个步骤。

存储在服务节点的存储器中的信息可以使用用于存储和检索信息的任何适合的结构来实施。数据库、文件系统、表格、列表或这些结构的适合的组合是可以如何存储这些信息的实例。可以使用计算机可读永久存储介质，诸如：基于半导体的或其他集成电路(IC)(例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘、HDD、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、其他适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

在一些实施例中，系统100可以使用分类方案来命名服务。分类可以允许跨类似类型的服务的属性组合。可以使用面向对象方法来定义服务域。作为实例，“网络”可以是根域，“交换”、“路由”和“服务”可以是根“网络”域的子域，并且“安全”和“数据包检测”可以是“服务”域的子域。这些关系的标记例如可以由点分十进制名称来实现。图4示出了分级命名方案的实例。从图4获得的名称的实例可以是“iaas.network.switching”和“iaas.network.security”以及其他。子域可以继承在父域中定义的参数。子域可以通过将父域的属性重新定义在子域中来覆盖这些属性。使用域命名，诸如代理142和144的代理可以广告域并且访问服务的用户(例如，与客户节点102、104和106相关)将基于它们偏好哪个服务域来访问它们。在一些实施例中，这可以用来从服务用户提取服务实现。XML模式可以用来实施分类方案。也可以提供分类方案中的属性的继承。例如，“路由”和“交换”域可以继承“网络”域并且“虚拟防火墙”域将继承“防火墙”和“虚拟机”域二者。通过继承，在一些实施例中可以自动地重新使用大部分域属性。

在一些实施例中，每个服务域可以具有其自己的服务专用参数。它们可以通过继承现有域来重新使用现有参数。每个域可以与其自己的模式相关，并且即使没有域细节和其相关参数，也可以允许代理在将其转发之前验证请求。可以服务相关方式定义域参数，但是仍可以将其普遍化以应用于那个域中各种各样的服务。这些参数可以通过XML、文本、二进制或其他种类的格式来表示。

在一些实施例中，供应商专用属性(VSA)可以结合服务域使用。这些属性可以不由所有客户端或用户理解。然而，这些可以在选择使用这些属性的选择端点之间理解。使用VSA，可以定义实验域或供应商专用域。

在一些实施例中，代理142、144和146可以接收请求(例如，从其他代理142、144和146或者从客户节点102、104和106)并且代表由服务节点132、134、136和138提供的服务来执行请求。在一些实施例中，代理142、144和146的使用是针对与和特定服务(诸如，服务创建和服务删除)的细节无关的服务管理有关的功能。代理可以使用一个或多个计算系统来实施。在这些计算系统中的一个或多个上运行的软件可以执行本文描述或说明的一个或多个方法中的一个或多个步骤或者提供本文描述或说明的功能性。这些计算系统可以是任何适合的物理形式。作为实例而并非为了限制，计算系统可以是虚拟机(VM)、嵌入式计算机系统、片上系统(SOC)、单片计算机系统(SBC)(例如，模块化计算机(COM)或模块化系统(SOM))、台式计算机系统、膝上型或笔记本计算机系统、交互式自助服务机、大型机、计算机系统的网格、服务器、应用服务器、路由器、交换机或这些中的两个或更多个的组合。在适当的情况下，计算系统可以：是单一的或分布式的；跨多个位置；跨多个机器；或者驻留在计算云(例如，计算系统的联网集，其可以包括在一个或多个网络中的一个或多个云组件)中。在适当的情况下，一个或多个计算系统可以执行(基本上没有空间或时间限制)本文描述或说明的一个或多个方法中的一个或多个步骤。作为实例而并非为了限制，一个或多个计算系统可以实时或以批量模式执行本文描述或说明的一个或多个方法中的一个或多个步骤。在适当的情况下，一个或多个计算系统可以在不同的时间或在不同的位置执行本文描述或说明的一个或多个方法中的一个或多个步骤。

存储在代理的存储器中的信息可以使用用于存储和检索信息的任何适合的结构来实施。数据库、文件系统、表格、列表或这些结构的适合的组合是可以如何存储这些信息的实例。可以使用计算机可读永久存储介质，诸如：基于半导体的或其他集成电路(IC)(例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘、HDD、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、其他适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

服务管理可以包括创建、修改、移动或删除服务。服务管理可以涉及顺序或并行地执行的一个或多个动作。这些动作可以在硬件和软件服务上或者在其他云提供商上调用。这些功能可以从网络的剩余部分提取。例如，代理可能不知道服务、用户或策略的细微差别。在各个实施例中，代理可以执行以下功能：

——广告其作为可以促进用于某些类型的服务的服务事务的网络元件的存在；

——连接到其他代理并且交换服务相关信息以允许交换服务信息的服务代理(例如，代理112、118、142和146)的分布式网络。这可以包括路由规则将服务请求定向至例如基于地理上的接近、服务率或成本或服务水平协议的目的地。路由规则可以是强制执行的并且动态地改变；

——发现服务节点和其服务能力并创建服务节点、客户节点或其他代理可以查询以发现可用服务的类型的注册表。客户节点102、104和106以及服务节点132、134、136和138连接到收集和分发服务信息的代理112、114、116、118、142、144和146。这些代理可以反应客户与服务提供商之间的协议；

——通过用户注册和服务兴趣的指示来发现用户位置和存在状态(例如，针对与客户节点102、104和106相关的用户)。这可以是有帮助的，因为由于某些服务可以基于位置来不同地路由或者可能被禁止访问或仅允许受限访问，位置可以是传递服务时的考虑因素；

——连接到确定将服务请求路由到下一跳或者在路由之前可以如何修改或转化服务请求的规则的策略数据库。服务请求的策略路由允许客户和提供商通过网络中的单个控制点来控制服务事务。客户节点(例如，客户节点102)可能能够基于用户或群组来强制执行策略。这些策略可以验证用户是否被授权访问一种类型的服务并拒绝未授权的请求。可以提供在请求离开前提之前对基于请求的用户或群组策略的自动改变。服务提供商可能在将请求转发到与服务相关的内部网络(例如，与服务节点132相关的内部网络)之前基于策略来类似地拒绝或修改请求。修改可以基于特定服务水平协议(SLA)规则和/或先前协议。作为实例，请求可以是比率限制和/或优先化的。可以在系统中的多个点(例如，客户节点102、代理112、142和146以及服务节点132)强制执行请求的策略处理；

——对于服务的认证、授权和记账。代理可以拦截请求并且质疑客户端进行自我认证。其随后可以查询策略数据库以验证用户被授权进行服务事务。在创建了服务之后，还可以执行周期性的记账。为此目的可以使用诸如RADIUS或DIAMETER的现有协议。代理(例如，代理112)可以基于内部用户数据库来认证用户并且将请求转发到具有其证书的服务提供商代理(例如，代理142)。这可以隔离安全域并且建立信任边界。代理可以用于通过有状态的检测来检测云的安全漏洞和攻击。事务的日志记录可以在代理处进行。

与所提供的服务种类无关，除了其他之外，可以执行诸如服务发现、创建、修改、删除和迁移的普通动作。另外，可以提供请求的可靠确认和取消或指示上游成功和故障。云计算可以涉及许多这些服务无关的动作。作为实例，如果虚拟机、虚拟专用网络或存储设备，则可以使用“创建”动作来指示服务创建的操作。这个普通“创建”动作可以用于由代理112、114、116、118、142、144和146进行的各种创建任务，并且其意义可以取决于接收者。

对服务的请求可以由代理转发到服务节点(例如，服务节点132、134、136和138)、其他代理(例如，代理112可以将从客户节点102接收到的服务请求转发到定位代理118)或工作流节点(例如，工作流节点122、124和126)。可互操作网络(例如，数据中心190和192)的网络可以使用多个代理。代理可以检测或修改传输中的数据包。在一些实施例中，定位代理118可以执行负载平衡、定位和安全功能，同时将从代理(例如，代理112、114和116)接收到的请求转发到与所请求的服务相关的代理(例如，代理142、144和146)。作为一个示例性操作，客户节点102可以请求服务并且代理112可以将请求路由到正确的位置。代理发现并且监控服务。代理还可以认证服务提供商和客户节点，这样使得不想要的用户或服务不能进入服务路由数据和程序。代理可以将响应转发回其他代理和客户节点。代理可以有状态地检测数据包并且插入或移除报头。

在一些实施例中，代理可以在两个模式中的一个下工作：透明模式和聚合模式。在透明模式下工作的代理不能聚合服务；其透明地转发消息。在聚合模式下工作的代理聚合服务并且将其作为聚合体发布。在聚合模式下，单个代理可以向其用户发布各种各样的服务，然而这些服务又由其他代理管理。

代理通常位于相关节点(例如，相关服务节点或客户节点)的前提处。处理相关节点的请求的代理可以位于包括相关节点并且执行外出控制的功能的网络的边缘处。在一些实施例中，代理可以位于服务提供商的网络内，即使该网络与请求服务的节点相关。例如，与软件即服务(software-as-a-service，SaaS)节点相关的代理可以发送对基础设施即服务(infrastructure-as-a-service，IaaS)服务的查询，并且SaaS和IaaS都可以在特定服务提供商的网络中实施。在此情况下，与SaaS节点相关的代理将位于提供商的网络中。

代理142、144和146中的一个或多个可以定义成迎合特定客户、服务类型(例如，计算服务或存储服务)或位置。例如，代理146可以设置成服务来自客户节点102和104的请求，因为它们已经保证了某个水平的服务。代理142、144和146中的一个或多个可以在指定的地理区域编排服务。

代理142、144和146中的一个或多个可以跨多个资源或资源域控制服务管理。例如，代理142可以管理服务，诸如计算、存储、网络和安全服务。代理142、144和146中的一个或多个可以基于单个请求来例示多个服务实例，并且可以用来设置关于单个请求的完整的虚拟数据中心。误差或故障情景可以由代理142、144和146中的一个或多个处理；例如，可以触发回滚动作。与服务节点相关的代理可以发现服务，允许服务注册，并且将服务的聚合发布给上游定位代理(例如，定位代理118)。此代理也负责对服务使用进行记账。代理可以使用计时器并检测请求上的超时。这些计时器可以用来预期在指定时段内对请求的响应。当计时器到期时，恢复动作应是可能的。这也可以用于网络故障的情况下，并且可以自动地撤销正在进行的事务。通过使用计时器和自动撤销，故障可能不会导致资源泄漏、错误的记账或其他问题。

代理142、144和146中的一个或多个可以变成用于在其自己控制域之外的复杂服务的锚点。例如，代理142可以创建虚拟机池，并且可以耗尽资源并且将请求定向至定位代理118以找到另一个位置(例如，与代理144相关的服务节点134)中的额外资源。代理可以配置成排序和并行化单个情境内的消息。排序和并行化将取决于特定种类的服务的具体需要。例如，可以并行地提供计算和网络服务，而跨地理区域的工作负载移动必须顺序地发生。因此，对这些请求的响应也可以以顺序或并行方式接收。当以并行或顺序方式管理请求时，应可能将这些操作作为整体执行。如果在任一个事务中遇到错误，则应可能将整个服务情境作为整体取消。

在一些实施例中，工作流节点122、124、126、128、152、154、156是服务相关网络元件(即，由工作流节点执行的功能取决于特定服务的细节)。这包括服务认证、用于那些服务的服务水平协议(SLA)、位置偏好、计费策略、用于满足请求的过程以及其他适合的功能。这些策略可用作可由工作流节点应用到所接收的请求的句法和语义认证程序。如果认证失败，则可以拒绝请求。为了应用客户专用规则，工作流节点可以知道用户(例如，在顾客节点102、104和106)和其位置。为了应用服务专用规则，工作流节点可以知道服务可用性和位置。工作流节点可以使用一个或多个计算系统来实施。在这些计算系统中的一个或多个上运行的软件可以执行本文描述或说明的一个或多个方法中的一个或多个步骤或者提供本文描述或说明的功能性。这些计算系统可以是任何适合的物理形式。作为实例而并非为了限制，计算系统可以是虚拟机(VM)、嵌入式计算机系统、片上系统(SOC)、单片计算机系统(SBC)(例如，模块化计算机(COM)或模块化系统(SOM))、台式计算机系统、膝上型或笔记本计算机系统、交互式自助服务机、大型机、计算机系统的网格、服务器、应用服务器、路由器、交换机或这些中的两个或更多个的组合。在适当的情况下，计算系统可以：是单一的或分布式的；跨多个位置；跨多个机器；或者驻留在计算云(例如，计算系统的联网集，其可以包括在一个或多个网络中的一个或多个云组件)中。在适当的情况下，一个或多个计算系统可以执行(基本上没有空间或时间限制)本文描述或说明的一个或多个方法中的一个或多个步骤。作为实例而并非为了限制，一个或多个计算系统可以实时或以批量模式执行本文描述或说明的一个或多个方法中的一个或多个步骤。在适当的情况下，一个或多个计算系统可以在不同的时间或在不同的位置执行本文描述或说明的一个或多个方法中的一个或多个步骤。

存储在工作流节点的存储器中的信息可以使用用于存储和检索信息的任何适合的结构来实施。数据库、文件系统、表格、列表或这些结构的适合的组合是可以如何存储这些信息的实例。可以使用计算机可读永久存储介质，诸如：基于半导体的或其他集成电路(IC)(例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘(HDD)、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、另一个适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

工作流节点可以周期性地或者在信息改变的时候从相关代理接收此信息。例如，工作流节点可以通过相关的代理来预订更新(例如，工作流节点122可以从代理112预订更新)。在一些实施例中，工作流节点可以包括设备和服务专用配置。这些配置可以被映射到由元属性标识的设备和服务能力。虽然元属性描述高级能力，但是存储在工作流节点中的配置将涉及详细配置。这些可以包括命令行接口命令、文本或XML配置或者甚至二进制格式化专用配置。工作流节点可以使用元属性来构造用于特定资源(或设备)的配置。工作流节点还可以针对唯一标识符存储此配置以便稍后用于查询离开工作流节点的配置。

工作流节点包括工作流定义连同验证或修改服务请求中的工作流的策略。作为实例，服务、用户和策略信息可以编码在如可扩展标记语言(XML)的抽象语言中。在此实例中，工作流可以是XML文件。工作流可以包括任务并且可以代表必须以其执行任务的次序。工作流中的任务可以包括为该任务需要进行的动作的定义。任务可以是代理可以执行的操作。为了执行任务，代理可以发送或接收适当的消息。工作流可以由工作流名称参考。客户节点(例如，客户节点102)可以通过调用工作流名称来请求服务包。工作流可以存储在工作流节点(例如，工作流节点122和152)中。工作流节点可以位于网络中的各个点(如图1中所示)。工作流节点可以配置成将工作流名称与工作流相关(例如，包括任务的XML文件)。工作流节点可以通过验证针对存储在该工作流节点中的服务专用句法和语义验证程序的工作流请求来执行服务专用验证。在描述句法和语义的语言被标准化的实例中，工作流节点(例如，工作流节点152)可以在不需要升级代理(例如，代理142)来支持新服务的情况下，仅通过配置支持多个新服务组合。

当使用工作流和任务的XML定义时，可以通过例如使用XML模式定义(XSD)来验证句法并使用对象约束语言(OCL)来验证工作流请求的语义来定义验证规则。当工作流请求到达时，所请求的工作流可以针对已经以XML或其他抽象语言定义的相关方案验证。如果根据已经在工作流节点中定义的句法和语义规则请求未能验证，则可以拒绝该请求。规则还可以指定在将所有或选定请求下游转发(例如，从工作流节点152到服务节点132)之前如何对其修改。所有句法和语义规则的集合构成策略框架。策略框架可以集中在提供商处、客户处或者分布在提供商与客户之间。因此，可以多次修改和/或验证请求。

策略可以与用户(例如，客户节点102的用户)相关，这样使得用户可以修改关于服务的个性化策略。策略可以与服务(例如，由服务节点132提供的服务)相关，并且服务供应商可以提供用于控制每个服务的策略的可配置系统，该服务提供商可以定制服务以适合其部署需要。策略可以与代理(例如代理142)相关，其可以由服务提供商、客户或由服务提供商与客户共同地定义。当策略与代理相关时，客户端和服务器可以不知道策略。管理策略规则的复杂度可以通过集中智能以定义策略并将其应用在代理中来减少。为了应用这些策略，在客户端请求到达服务节点之前根据策略拦截、变换并且路由这些请求。诸如客户节点102和服务节点132的节点可以不知道此行为。用于控制服务请求的规则可以通过配置来定义。代理(例如，代理112或142)可以下载用于服务的策略规则并且按需执行那些规则。

在一些实施例中，控制和策略平面的分开允许将相同的控制平面重新用于各种策略。现在可以通过配置而非在代理中编程来定义策略。可以使用公共控制平面来管理所有这些服务。通过此分开，代理(例如，代理142和112)可以是可编程的，并且其可以不包括硬编码的服务逻辑。相反，代理可以通过由用户或服务提供商以适合的方式(例如，使用用户友好语言)定义的策略来“编程”。这可以便于现有服务的服务创建和定制，同时减少整体管理复杂度。

可以应用于系统100中的策略的一个实例是路由策略。服务可以从多个源(例如，服务节点132和1344)提供，并且将请求路由到正确的目的地，可以应用各种类型的路由策略。例如，可以将服务请求路由到地理上最近的提供商。或者，其可能被路由到提供最便宜的服务率的位置，或者基于当日时间提供到到不同的位置。可以存在基于SLA的路由规则。每个用户的请求可以基于其作用来不同地路由。可能存在一种类型的服务专用的规则，或者可以通过具有必需容量的位置来确定路由。可以通过法律或政府规程来确定路由。这些规则可以动态地改变，或者不同的规则可以应用于不同类型的服务、用户、位置、作用或其他适合的目标。服务提供商和客户可以独立地或共同地定义这些策略，并且在客户边缘、在服务提供商边缘或二者处强制执行这些策略。

可以应用于系统100中的策略的另一个实例是安全策略。在系统100中提供的服务的情境中的安全可以涵盖跨认证、授权和记账(AAA)的广泛的问题。例如，客户(例如，在客户节点102)可以基于内部用户数据库来认证其用户，而服务提供商(例如，在服务节点132)可以负责服务请求的授权和记账。作为另一个实例，客户可以负责用户专用的授权和认证，而服务提供商可以负责记账。当用户加入或离开客户时，服务提供商可能不拥有用户专用认证和策略。AAA功能在服务提供商或客户边缘处最佳执行。可能不需要每个服务进行AAA；其是低效且复杂的。可以通过防止未授权请求进入网络来保护服务节点免受拒绝服务攻击。服务可以仅作为包(bundle)(例如，网络、计算和存储设备可以形成单个服务包)而非单个地记账。用于商业分析的请求日志记录可以在网络水平进行而非在个人服务中进行。服务提供商还可能希望隐藏服务的网络拓扑，并且可以从用户可见性提取所有服务。例如，服务提供商可以发布一个接口来访问服务，然而这些服务由服务专用代理管理。这些代理可以位于不同的位置处。

可以应用于系统100中的策略的另一个实例是服务策略。复杂服务可以使用多个资源的协调。虚拟机例如可以需要服务的网络附加存储、基于网络的安全和网络质量。在没有组合所有服务的情况下，虚拟机服务可以被认为是不完整的。一些虚拟机可以使用网络附加存储，而其他不可以。一些虚拟机可能需要卸载拒绝服务攻击，而其他可以使用数据的加密。一些服务可以使用可获得的特定量的网络带宽。与服务相关的策略可以从客户端和服务提供商提取。因此，当客户端请求虚拟机，则可以在请求到达服务提供商之前修改请求以包括服务请求的存储、安全和质量。同样，例如，如果用户未被授权请求高端服务，则其请求可能被自动降级到适当的服务等级。这是服务提供商和/或顾客可以定义的策略的功能。这意味着对虚拟机的请求可能对不同类别的用户进行不同的事情。在使用相同请求的同时，可以在服务水平上对用户升级或降级。这意味着请求的句法和语义不预先固定。相反，其是基于情境确定，并且可以使用不同的因素来修改传输中的这些请求。可以从终端用户的观点以及服务提供商的观点来限制请求的句法和语义。因此，服务节点可以支持请求参数的超集，以允许任何用户以不同方式访问服务。客户端可以基于先前客户或服务提供商定义的策略或SLA来请求那些参数的子集。以用户专用方式的请求参数的验证和微调应由传输中的策略控制。实际上，客户端做出的请求和服务节点接收的请求可以基于在中间修改请求的策略而非常不同。

与接收对来自客户节点的服务的请求的代理相关的工作流节点可以用来在允许转发请求之前验证该请求。例如，工作流节点122可以在转发来自客户节点102的请求之前针对为给定用户规定的策略来验证该请求。工作流节点可以由服务提供商用来在将提供商对提供商请求发送到另一个服务提供商之前验证所述请求。验证可以单方面地或基于协议或定义的SLA来定义。

在一些实施例中，工作流节点可以在执行之前自动地修剪或扩展所请求的工作流。例如，为了虚拟机创建工作流，工作流节点可以添加用于存储、访问控制、服务质量规定和负载平衡的任务，即使这些任务不在原始请求中。用来管理工作流的修剪或扩展的策略可以由用户、服务提供商或如SLA的双方约定地定义。一旦定义了工作流，则相关代理或服务节点可以从工作流节点下载工作流和任务定义。在故障或服务终止的情况下，工作流节点将通过以正确的次序翻转单个任务来确定动作撤销。

在一些实施例中，为了添加新服务，可能不需要新的API组合。相反，可以创建新的XML文件来验证服务请求的句法和语义。因此，可以仅通过配置来添加新服务。通过定义和验证工作流的能力，用户(例如，在客户节点102)或服务提供商(例如，在服务节点132)可以按需创建服务包。工作流节点存储所有用户或服务提供商定义的工作流(其由工作流名称参考)。

代理和工作流节点可以被指定用于特定客户、服务提供商和服务类型。代理和工作流节点中的一个或二者可以部署在一个或多个网络中的多个点处，包括但不限于：(a)客户或服务提供商出口；(b)客户或服务提供商入口；以及(c)客户或服务提供商内联网。代理与工作流节点之间的交互可以是任意对任意(例如，一个代理可以与用于多个服务类型的多个工作流节点交互，并且一个工作流节点可以将一种类型的服务相关规则用于支持相同服务的多个代理)。图1示出了代理与工作流节点之间的任意对任意关系的多个实例。代理可以连接到多个工作流节点(例如，代理142联接到工作流节点152和154)。工作流节点可以连接到多个代理(例如，工作流节点154联接到代理142和144)。如图1中所示的代理和工作流节点的分布促进负载平衡。工作流节点向代理广告它们支持的工作流。工作流节点还广告它们可以支持的服务域和用户的分类。代理可以使用此信息来将适当的服务请求转发到适当的工作流节点。代理可以向其他代理广告其从相关工作流节点接收的工作流。这样，代理能够知道如何到达能够执行所请求的工作流的特定代理，并且能够向其路由请求。

在一些实施例中，定位代理118聚合服务信息并且发布聚合的信息。定位代理118可以用来将服务拓扑隐藏在服务提供商内。例如，支持多个服务(例如，由数据中心192中的服务节点136和138提供的服务)的服务提供商可以仅发布其定位代理地址并且将请求内部地路由到动态地或策略选择的代理。定位代理118还可以用来通过将服务请求路由到最佳满足请求的地方来实施服务的高可用性。定位代理118可以有状态地检测接收到的请求并且在进一步转发请求之前认证发送者。其可以速率限制来自特定源的请求，并且可能能够入侵检测和防止，以用于保护内部网络免受拒绝服务(DoS和DDoS)攻击。定位代理118后面的节点(例如，代理142和144)随后可以假定进入其中的数据包是安全的。在一些实施例中，这可以避免对认证用户请求和建立安全防御的服务的需要。

在一些实施例中，定位工作流节点128可以具有基于策略转发请求的规则。例如，定位工作流节点128可以确定来自客户节点102的服务请求必须始终定向到明确位置(例如，数据中心190)。定位工作流节点128可以选择最近的服务创建位置，或者路由到具有可用资源的位置。

在一些实施例中，定位代理118可以提供如同网络边界处的节点的一个或多个功能。例如，定位代理118可以被认为相对于客户节点102、104和106中的一个或多个在数据中心190的边界处。如另一个实例，定位代理118可以被认为相对于数据中心192中的节点在数据中心190的边界处。可以由定位代理118执行的功能是请求数据包(例如，从客户节点102发送到服务节点132的请求数据包)的报头的检测。检测可以包括确定请求数据包是否被无意地发送或路由或者确定请求是否恶意的。代理118还可以配置成拒绝请求数据包或清理(sanitize)请求数据包的报头。

如另一个实例，定位代理118可以基于网络边缘处的策略来将报头插入到消息中。例如，数据中心190可以具有应用于所有进入数据包的策略并且定位代理118可以根据与数据中心190相关的一个或多个策略修改发送到数据中心190中的节点的数据包的报头。这可以允许方便的方法在一个点处应用策略，而无需用户或网络的节点(例如，数据中心190中的那些或客户节点102、104和106)熟悉这些策略。节点可以接收由定位代理118(例如，服务节点132)修改的数据包。修改的消息可能看起来像用户请求的事务。

如另一个实例，定位代理118可以修改地址。在一些实施例中，定位代理118可以执行与基于网络的服务的管理有关的消息的网络地址转换(诸如，上述代理142、144和146的功能)。这可以用来隐藏与代理142、144和146以及工作流服务器152、154和156有关的网络拓扑。

如另一个实例，定位代理118可以检测和处理来自相同源的并发请求(例如，从服务节点134发送服务的并行请求的客户节点104)。这可能是有问题的，因为资源可以并行地分配和释放，并且可以导致系统中的混乱，由此引起一个或多个安全威胁。定位代理118可以配置成禁止并行请求并由此保护系统。

如另一个实例，定位代理118可以速率限制来自单个源的请求(例如，将服务的请求发送到服务节点134的客户节点106)。这可以允许用户(例如，与客户节点102、104和106相关的那些)具有服务的公平共享(例如，服务节点132、134、136和138所提供的那些)。单个用户可以通过使用自动机制发送例如周期性的分析请求来潜在地使系统过载。速率限制可以减少或防止过度使用。

如另一个实例，定位代理118可以涉及虚拟私人网络(VPN)或因特网协议安全(IPSec)会话。定位代理118可以使用密钥链执行公共密钥认证以验证用户(例如，与客户节点102相关)应访问服务(例如，由服务节点132提供)。定位代理118可以确定用户是否被授权接收所请求的服务。

如另一个实例，定位代理118可以在不同的服务请求格式之间转换。例如，定位代理118可以在外部暴露的API(例如，由服务节点132)与内部协议之间转换以管理基于网络的服务。

在一些实施例中，系统100描述使用来自使用公共协议(例如，通过代理112、142和146之间的通信)的不同云提供商(例如，由服务节点132和136提供)的云服务的用户(例如，在客户节点102)。这可以允许用户跨服务提供商或源移动来自不同提供商的不同地理区域中的相同服务。

在一些实施例中，系统100描绘与服务提供商域(例如，与服务节点138相关的域)中的那些互操作内部或私有云(例如，客户节点102是其一部分)的用户(例如，在客户节点102)。如一个实例，可以使用代理112与146之间的通信将工作负载在和客户节点102相关的私有云与和服务节点138相关的公共云之间移动。如另一个实例，可以通过代理112和146如同与客户节点102相关的私有云中一样使用与服务节点138相关的公共云中的公共协议来创建虚拟服务。

在一些实施例中，系统100描绘使用代理(例如，代理142、118和146)与另一个服务提供商(例如，与服务节点136相关)互操作其服务的服务提供商(例如，与服务节点132相关)。如一个实例，在需要增长时，服务提供商可以是彼此的服务源。如另一个实例，一个服务提供商可以使用其他服务提供商的服务作为备份或用于断电情况下的灾难恢复。服务提供商可以商定在彼此的云中存放服务，其中工作负载在位于不同地理区域的服务提供商之间移动。如另一个实例，服务提供商可以通过使用由诸如代理142、144和146的代理提供的互操作性来跨不同服务提供商获得服务。

在一些实施例中，系统100描绘云提供商如何可以传递层叠于彼此之上的许多种类的服务。例如，SaaS服务可以使用平台即服务(PaaS)服务。PaaS服务(例如，由服务节点132和134代表)可以使用IaaS服务(例如，由服务节点136和138代表)、网络和安全服务或其他适合的服务。云提供商可以增量地建立服务并且跨层级互操作服务。这可以避免例如必须为每个新PaaS服务建立新IaaS系统或者为每个SaaS服务建立新PaaS服务。互操作性可以使用使用与服务管理有关的公共协议彼此通信的代理(诸如代理142和144)来提供。

在一些实施例中，系统100描绘云提供商如何可以从多于一个供应商获得服务。这些服务的实例包括计算虚拟化、存储、网络和安全。例如，客户节点104可以从服务节点132寻找服务，诸如SaaS服务。在此实例中，服务节点132可以从服务节点136(例如，提供存储服务)和138(例如，提供安全服务)获得与所提供的SaaS服务相关的服务。在此实例中可以使用代理114、142和146来允许从多个位置获得服务而不需要使得客户节点104知道如何获得服务。这种互操作性可以通过使用与服务管理有关的公共协议彼此通信的代理来提供。

在一些实施例中，系统100可以允许客户定义不同的粒度水平的服务请求。例如，客户可能需要单个请求来提供计算-存储-网络，并且另一个客户可能一个接一个地请求这三个服务。这些不同的请求可以发生在系统100中的一个或多个点处。例如，服务提供商(例如，与服务节点132相关)可以发布客户专用工作流(例如，使用代理142)并且在云边缘处将其转换。如另一个实例，服务提供商可以发布被转换成详细任务以由另一个服务提供商执行的工作流。如另一个实例，客户(例如，与客户节点106相关)可以定义在请求离开客户前提(例如，在代理116)时被转换的工作流。

图2示出了可以用于以上参照图1的系统100论述并且以下参照图3至12论述的操作中的示例性数据包200。在一些实施例中，数据包200示出具有两个协议的协议方案：服务编排协议(SOP)(包括在数据包200的部分210和220中)和服务描述框架(SDF)(包括在数据包200的部分230和240中)。SOP携带服务无关信息(例如，与如何实施在部分230和240中提及的服务无关的信息)，而SDF携带服务相关信息(例如，与如何实施在部分230和240中提及的服务有关的信息)。SDF有效负载可以如数据包200指示附加在SOF消息中。在一些实施例中，通过分开服务无关和服务相关片，在此描述的方案可以互操作方式扩展到任何服务类型。SOP使用基于文本的报头。这可以促进SOP的实施以及扩展SOP(例如，通过添加新文本报头)。这些消息可以在代理(诸如代理118和142)处检测并且由其修改。可以例如类似于会话发起协议(SIP)中的认证程序进行认证。如其他实例，可以使用IPSec、TLS或其他已经与HTTP一起使用的加密和私密机制实施认证。

在一些实施例中，报头220包括具有名称和值的字段。字段的次序在SOP消息中未指定，但是如果在消息顶部存在与服务路由有关的字段(To(至)、From(自)、Exchange(交换)、Via(通过))以促进快速处理则可以是有帮助的。示例性消息名称报头：

CREATE 1 SOP/1.0

GET 1 SOP/1.0

消息类型后面的数字指示消息是否作为相同的消息在相同的事务中重新传送。此数字可以在重新传送消息的任何时候由发送者增加。接收者可以为重新传送的消息提供更高优先权。

以下是可以用于SOP中的消息：

——发现(DISCOVER)——由服务节点用来发现代理

——广告(ADVERTISE)——由代理用来广告其存在

——注册(REGISTER)——由服务节点用来通过代理注册自己

——发布(PUBLISH)——由服务节点用来指示其能力

——预订(SUBSCRIBE)——由工作流服务器/客户端用来预订服务信息

——创建(CREATE)——由代理用来请求服务创建

——删除(DELETE)——由代理用来请求服务删除

——更新(UPDATE)——由代理用来请求服务更新

——获取(GET)——由代理/服务节点用来获取服务/工作流细节

——转移(TRANSFER)——由代理用来请求服务移动性

——执行(COMMIT)——由代理用来执行服务改变

——取消(CANCEL)——由代理/客户端用来取消操作

——工作流(WORKFLOW)——由代理/客户端用来执行工作流

代理可以广告其存在连同代理某些服务的能力。服务节点可以通过监听代理广告来发现服务专用代理。服务节点还应能够触发服务发现，例如，因为当代理广告其存在时服务节点可能已经停止服务。在SOP中可以使用两个消息(广告和发现消息)来支持代理发现。代理发送广告消息来宣布其存在和处理一些服务的能力。如果广告消息尚未传送或者如果其被传送但是服务节点尚未操作以将其接收，则服务节点可以使用发现消息来触发广告消息。在一些实施例中，这两个消息可以是独立请求，并且并不像请求-响应一样相关。代理可以周期性地发送广告消息以宣布其存在。在服务节点启动时并且如果尚未接收到广告，服务节点可以发送发现消息。如果发现消息中的服务类型与代理所支持的服务类型相匹配，则代理可以响应于接收发现消息来发送广告消息。可以广播发现消息。可以将广告消息作为单播发送。响应于发现消息发送的广告消息可以作为单播消息发送(从接收到的发现消息得到单播地址)。

在从代理接收广告消息之后，并且如果服务兴趣匹配，则服务节点、工作流服务器、用户或代理可以通过代理来注册。如果服务节点支持多个服务，则其可以通过支持那些服务的那些代理来注册。如果客户端对由多个代理支持的服务感兴趣，则其可以通过它们所有来注册。如果代理对与多个代理交换服务信息感兴趣，则其应通过它们来注册。注册向注册代理标识服务节点、工作流服务器、用户或代理。接收注册的代理可以在注册期间开始认证。代理可以与AAA服务器交互以认证和/或质疑注册标识。注册可以周期性地执行，并且它们可以用作具有代理的保活机制。注册可以用来确定用户、代理、工作流服务器或服务节点的位置，并且可以将基于位置的策略应用在服务管理中。

在一些实施例中，可以由代理发送广告消息以广告其存在和代理某些类型的服务的意愿。消息中的SDF有效负载(例如，包括在数据包200的属性230和服务描述符240中)指示其可以支持哪些服务域。在以下的示例性消息中，代理支持服务的iaas.计算域。消息可以携带注册超时报头。消息还可以携带其他计时器值和重试次数作为统一地全局配置网络中的所有服务节点的方式。实例：

From：defaultp.provider.com

To：defaultdefault.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Timestamp：1285162132

Sequence-ID：13224 ADVERTISE

Registration-Timeout：1000

Content-Type：application/sdf；charset＝utf-8

Content-Length：147

<？xml version＝″1.0″encoding＝"UTF-8″？>

在一些实施例中，发现消息由服务节点发送以发现愿意或能够用作用于其服务的代理的代理。该消息中的SDF内容指示服务节点中的服务能力。在以下实例中，服务节点能够作为服务的iaas.compute域：

From：defaultdefault.com

Via：SOP/1.0/UDP defaultdefault.com；branch＝k9DjR51bcw

Timestamp：1285162130

Sequence-ID：1 DISCOVER

Content-Type：application/sdf；charset＝utf-8

Content-Length：147

<？xml version＝″1.0″encoding＝"UTF-8″？>

在一些实施例中，在服务节点的服务能力改变的任何时候、当发布超时(Publish-Timout)计时器到期时或者在服务重新启动之后(在注册之后)(无论哪个先到)，发布消息由服务节点发送。此消息指示服务节点对代理的当前服务可用性。代理将使用在SDF有效负载中给出的信息以更新其服务数据库。在此指示的能力将由代理使用以将服务请求朝向服务节点路由。SDF内的“能力”和“可用性”指示总容量和当前可用的容量。示例性发布消息：

在一些实施例中，在发现了新代理之后或者当注册超时(Registration-Timeout)到期时(无论哪个先到)，注册可以由服务节点、代理、工作流服务器或用户用来通过代理注册。节点类型报头通知代理关于注册实体的类型。如果节点类型报头指示服务节点，则消息可以具有指示服务节点支持的移动性类型的转移节点(Transfer-Node)报头。对于其他节点类型来说，可以不存在转移节点报头。注册消息可以由代理用来建立服务节点的标识(例如，其域名和IP地址)。代理可以在接收到注册消息之后通过注册实体来开始认证程序。如果注册失败，代理可能不能注册实体。注册消息可以由代理用作心跳或保活机制。代理可以配置成如果三个连续的注册超时已到期则解除注册实体，并移除与那个服务有关的所有信息。当那个服务节点由于注册计时器(Registration-Timer)的到期而已经被解除注册时，代理可以在另一个服务节点处开始用于那个服务节点下的所有服务的服务重新创建程序。示例性注册消息：

From：defaultdefault.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultdefault.com；branch＝k9DjR51bcw

Sequence-ID：1 REGISTER

Transfer-mode：stateless

Node-type：Service-node

在一些实施例中，预订消息允许SOP网络元件请求对特定类型的服务能力的更新。SDF有效负载指示请求者预订的能力。工作流服务器可以通过代理预订对服务的所有更新和对用户注册的所有更新。用户可以通过代理预订接收工作流与服务相关更新。示例性预订消息：

From：defaultws.provider.com

To：defaultp.provider.com

Via：SOP/1.0/UDP defaultws.provider.com；branch＝k9DjR51bcw

Exchange：43shXui7236

Timestamp：1285162130

Sequence-ID：1 SUBSCRIBE

Distance：1

Content-Type：application/sdf；charset＝utf-8

Content-Length：154

<？xml version＝″1.0 encoding＝"UTF-8″？>

在一些实施例中，转移消息由代理发送以开始服务转移。From和To报头指示源和目的地代理。源(Source)和目的地(Destination)报头指示源和目的地服务节点。请求者(Requestor)报头标识转移的发起者(例如，代理)。转移消息设置开始服务转移的会话。其可能不负责将服务状态从一个服务节点实际地转移到另一个。例如，每个服务可以选择其自己的方法来转移状态(诸如FTP以转移文件)。转移消息中的SDF有效负载向目的地服务节点指示转移中预期的能力。例如，这些能力可以指示接受移动的虚拟机所需的内存或存储器的总量。那个存储器的内容在用于SOP的范围之外并且将分开处理。示例性转移消息：

在一些实施例中，更新消息可以由代理使用以请求对服务节点的服务更新。更新消息是指将通过任务ID(Task-ID)报头执行的任务。请求的接收者可以通过以消息中提供的任务ID查询工作流服务器来获得任务的描述。示例性更新消息：

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 CREATE

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在一些实施例中，工作流消息由客户端或代理使用以开始工作流执行。其含有需要被执行的工作流名称(Workflow-Name)。当请求涉及先前执行的工作流的删除或转移时，其含有对先前工作流ID(Workflow-ID)的参考。示例性工作流消息：

From：consumercustomer.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.customer.com；branch＝k9DjR51bcw

Sequence-ID：5 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，SOP可以包括两种服务发布。第一，服务节点将其能力发布给代理。第二，代理将服务节点的能力发布给其他代理和用户。这些发布建立在网络中的服务路由表，并且用户和代理可以知道如何将请求路由到服务。服务发布可以使用发布消息。此消息用于请求-响应配置中，因此响应由接收者发送。由于服务虚拟化，服务节点可以部分地发送发布消息。服务节点可以能够存放多个虚拟化的服务实例。由于那些实例被分配，所以服务节点中的总虚拟化容量减少。服务节点可以通知相关代理关于其存放服务的当前容量。代理可以聚合这些容量并且使用其来确定服务安排。在以下三种情况下(无论哪个先到)，服务节点可以将发布消息发送到相关代理：

a.基于由代理指示的时间周期性地(在例如由代理发送的广告消息中)。如果尚未接收到三个连续的发布消息，则代理可以将服务节点的能力设置为零值。

b.当开始服务节点时，通知关于其可用容量。

c.在服务节点的服务能力改变的任何时候；这通常可以在新服务分配或部分故障/断电之后。

代理还可以将发布消息发送到其他代理和用户以在网络中传播服务能力。在使得新服务可用时，或者移除现有服务时，用户可以知道可用服务列表。代理可以将其所发现的服务的目录动态地发布给用户。这些发布可以携带两种信息。它们可以具有通过代理可用的服务能力的聚合视图。此信息可用于接收者以确定通过发布者可以访问哪些服务。发布消息可以指示通过代理可以请求哪些工作流。工作流可加以服务类型的标签。在一些情况下，发布服务的聚合视图可能是不合需要的，因为其可能将提供商的内部细节暴露给其他提供商或用户。然而，发布消息可以将聚合的服务携带到有限集的可信代理。其可以将工作流携带到可以使用所述工作流的用户或代理。为了避免泛洪，用户或代理可以通过将预订消息发送到代理来指示其服务兴趣。预订消息可以指示发送者的服务兴趣，所述兴趣可以用作代理转发那些服务专用细节的过滤器。代理可以使用在注册期间搜集的信息来确定哪些用户和代理应被转发哪些信息。例如，其可能将聚合的服务信息转发给信任区域内的代理，但是将工作流发送给外部用户。

将发现/广告消息与发布/预订消息分开在于广告/发现消息可以在不对其响应的情况下广播而发布/预订消息始终被单播并且每个消息具有响应。注册和发布消息都向代理指示服务节点的信息。在一些实施例中，其之间的不同在于注册消息通知代理关于服务节点的标识(域名和IP地址)而发布消息通知代理关于其服务域名(ServiceDomain Name，SDN)和能力。类似地，注册消息通知代理关于用户的标识(域名和IP地址)而预订消息通知代理关于用户的服务兴趣。因此，在一些实施例中，在能力与兴趣之间存在区别，如在服务域名信息和标识(其依据DNS和IP)中所描述。保持注册消息与发布/预订消息分开的原因在于将标识(例如，DNS和IP)与服务信息分开。标识与认证相关，并且如果用户或服务节点已经得到认证，则此标识可以跨所有服务请求可用。可能不在每个服务事务中都需要认证。具有与注册消息相关的标识验证允许其他请求使用那个标识并避免对分开认证用户或服务节点的需要。注册消息可以用作关于服务的单点登录特征。

在一些实施例中，由代理执行的服务管理涉及至少五个功能：创建、删除、更新、获取和转移。创建、删除和更新功能处理服务的创建、删除和更新。获取消息根据情境请求服务或工作流或任务的描述。例如，获取消息可以获得存储盘的总分配大小但是通常不用来确定那个盘的内容。转移消息处理服务虚拟化和服务的移动。转移消息设置其中可以将服务信息从一个点转移到另一个的情境，诸如源和目的地地址和有待转移的信息的类型。实际的转移可以由服务本身确定(诸如，当移动虚拟机时，使用SFTP来转移内存快照)。

在一些实施例中，创建消息由代理用来向服务节点请求服务创建。创建消息是指将通过任务ID报头执行的任务。请求的接收者可以通过以消息中提供的任务ID(Task-ID)查询工作流服务器来获得任务描述。示例性创建消息：

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 CREATE

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在一些实施例中，删除消息由代理用来向服务节点请求服务删除。删除消息是指将通过任务ID报头执行的任务。请求的接收者可以通过以消息中提供的任务ID查询工作流服务器来获得任务描述。示例性删除消息：

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 DELETE

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在一些实施例中，获取消息由服务节点用来从工作流服务器获得任务描述。其可以在服务转移之前由代理用来请求服务节点描述。其可以由代理用来从工作流服务器获得工作流或任务描述。事务的情境确定需要实现这些功能中的哪些功能。取决于情境，必须存在各种报头。为了请求服务节点描述，代理可以包括服务ID报头来指代需要其描述的特定服务。为了获取工作流或任务描述，存在适当的工作流名称(Workflow-Name)、工作流ID(Workflow-ID)或任务ID(Task-ID)报头。可以存在查询类型(Query-Type)报头以描述查询类型。示例性获取消息：

From：defaultp.provider.com

To：defaultws.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9oluElbcw

Sequence-ID：286 WORKFLOW

Query-Type：workflow-name

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，SOP处理跨多个服务节点的可靠性问题。示例性服务可能要求跨计算、网络、存储、安全和其他域的管理。提供这些服务中的一个的服务节点中的故障可以触发提供其他相关服务的服务节点中的动作的回滚。这可以通过将取消消息发送到受故障影响的服务节点来执行。如果例如已经成功调用了所有服务节点，则将执行消息发送到服务节点。SOP中的服务事务可以在某个时间段内执行。例如，如果已经过了执行的时间，则由服务节点自动地取消服务。此机制在用户、代理、一些服务节点或这些的组合故障的情景下有用。如果代理已经故障并且未将执行消息发送到服务节点，则服务节点可以回滚事务。如果服务节点已经故障并且未响应代理，则代理可以将取消消息发送到其他代理和/或服务节点。如果代理已经故障并且未响应用户，则用户可以例如确保他们没有支付服务。如另一个实例，提供商可以确保除非已经发送执行消息，否则服务资源将不会由于故障而泄露。

在一些实施例中，可以在检测到错误的情况下或者在超时的情况下使用取消消息来取消尚未执行的事务。取消是新事务并且其需要响应。取消消息是指将通过任务ID报头取消的任务。请求的接收者可以通过以消息中提供的任务ID查询工作流服务器来再次获得任务的描述。实例：

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝khewui6GDw

Sequence-ID：134 CANCEL

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在一些实施例中，使用执行消息来执行创建、删除、更新或转移事务。在成功完成所有任务之后，此消息由代理发送到在工作流中涉及的每个服务节点。在一些实施例中，工作流规格可以通过当应发送执行消息时的规格来将此覆盖。执行消息是指将通过任务ID报头执行的任务。请求的接收者可以再通过以消息中提供的任务ID查询工作流服务器来获得任务的描述。代理可以将执行消息发送到工作流服务器以执行工作流。这是向工作流服务器指示工作流执行成功。工作流服务器在接收到执行消息时将存储工作流实例以供以后参考并返回工作流ID。此工作流ID可以用来重新创建服务(在灾难恢复的情况下)或将其撤销(在服务取消的情况下)。示例性执行消息：

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝khewui6GDw

Sequence-ID：134 COMMIT

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在一些实施例中，SOP定义一组响应。SOP可以使用1xx-6xx响应：

1xx——信息响应

2xx——成功响应

3xx——重定向响应

4xx——客户端故障响应

5xx——服务器故障响应

6xx——全局故障响应

在一些实施例中，代理在接收到工作流请求时可以发送100尝试消息。其可以指示代理已经接收到请求并且试图将其执行。此消息通过接收服务节点在创建、更新、删除或转移请求时发送。此消息通知代理已经接收到请求并且其正在被处理。100尝试消息的实例：

From：defaultp.provider.com

To：consumercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 TRYING

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，代理可以将183工作流进程(WORKFLOWPROGRESS)消息周期性地发送到客户端以保持其被通知更新。此消息可以具有描述执行中的进程的工作流描述。183工作流进程消息的实例：

在一些实施例中，可以由包括工作流服务器、代理和服务节点的多个实体发送200 OK消息以指示请求的成功完成。取决于情境，消息内容和报头将会不同。以下是由代理在完成创建任务时发送的示例性消息：

From：default4357254.provider.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultsn.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 CREATE

Task-ID：67439375

Workflow-Server：ws.provider.com

在一些实施例中，如果代理想要将请求者重定向至另一个代理并且自己将不服务该请求，则代理发送305使用代理(USE PROXY)消息。该消息包括替换代理(Alternate-Proxy)报头。示例性305使用代理消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 WORKFLOW

Alternate-Proxy：defaultp2.provider.com

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，如果代理或工作流服务器或服务节点发现恶意请求，则它们发送400错误请求(BAD REQUEST)消息。以下是示例性消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，如果代理或工作流服务器发现用户未被授权执行操作，则它们发送403禁止(FORBIDDEN)消息。这可以由代理用来指示需要认证。如果代理或工作流服务器发现用户未被授权执行工作流，则可以使用该消息。示例性403禁止消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，如果代理或工作流服务器或服务节点尝试处理请求但是由于一些内部错误而失败，则它们发送500服务器内部错误(SERVER INTERNAL ERROR)消息。如果服务节点未能执行所请求的操作(例如，服务创建、删除或更新)，则其可以发送此请求。示例性500服务器内部错误消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，如果服务节点之一未能响应请求并且代理在重传时超时，则代理发送504服务器超时(SERVER TIMEOUT)消息。示例性504服务器超时消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，如果因为没有可用容量而未能支持请求，则代理、工作流服务器或服务节点发送603拒绝消息。如果代理知道没有其他代理将能够支持此请求，则可以发送此响应(否则可以发送305使用代理)。拒绝消息的范围是发送消息的代理知道的代理集。示例性603拒绝消息：

From：defaultp.provider.com

To：usercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在一些实施例中，SOP可以使用UDP或TCP传输。服务管理创建、删除、配置和移动服务。使得这些事务高度可靠且可扩展是有益的。SOP已经将计数器嵌入到执行/取消程序来处理网络可靠性问题，例如，在代理故障或与代理的连接故障的情况下。因此，SOP可以结合TCP或UDP的使用来工作。因此，传输的选择可以取决于所希望的部署规模和可靠性。传输的限制也可以通过额外手段来克服。例如，有可能部署卸载在SOP代理之外的TCP规模的一组TCP代理。如另一个实例，UDP传输可以结合较短的重传计时器和增加的重传计数器来使用。SOP可以跨网络动态地分布计时器和计数器值。

在一些实施例中，报头220具有源和目的地名称。请求可以遍历代理，并且代理可以跟踪请求路径并且使用源和目的地名称将其与响应路径相关联。报头220还可以包括可以用来将请求与响应相关联的事务标识符。报头220可以包括可以用来标识消息传送的次序的序列号。定义内容类型和内容长度的字段也可以包括在报头220中。

在一些实施例中，SOP中的实体可以由用户域名来定址。在以下情况中可以使用用户“默认”(default)：

——为了定址代理和工作流服务器；

——当服务尚未被指派名称时(例如，在服务节点注册之前)用于定址服务；

——用于定址广播消息中的实体；

——如果发送者不知道应定址哪些用户；

在各个实施例中，数据包200中包括的报头可以被定义成适合各种目的。以下是示例性报头的列表：

——确认超时(Acknowledge Timeout)——此报头指示以秒计的时间，在该时间之后服务节点可以向代理发送“提示”200 OK消息以请求执行。在200 OK消息的重传计数器时间传送之后，服务节点可以考虑取消事务并且开始回滚操作。此报头可以在广告消息中发送以设置超时的全局值。取决于代理预期其完成某些操作将采用的时间，报头可以在创建、删除、转移请求中发送以设置超时。实例：Acknowledge-Timeout：30

——替换代理报头(Alternate Proxy Header)——此报头可以用来将客户端重定向至另一个代理。这可以在例如代理知道用于工作流的工作流锚点已经移动到另一个代理并且该代理未配置来将请求转发到那个代理的情况下发生。实例：Alternate-Proxy：p2.provider.com

——取消超时报头(Cancel Timeout Header)——此报头指示以秒计的时间，在该时间之后，如果尚未接收到200 OK或100尝试消息，则代理可以发送对请求的取消。此报头可以在广告消息中发送以设置超时的全局值。报头也可以在创建、删除、转移或更新请求中发送以设置每个请求的超时。实例：Cancel-Timeout：30

——执行超时报头(Commit Timeout Header)——此报头定义在已经发送响应之后由服务节点预期的执行消息的以秒计的时间。实例：Commit-Timeout：50

——内容类型报头(Content Type Header)——此报头定义在SOP请求中携带的内容的种类。SOP消息预期携带SDF有效负载(例如，在属性230和服务描述符240中)。然而，有可能可以将其他种类的服务描述方案结合SOP使用。此报头可以用来指定SOP消息中携带的应用有效负载的类型。实例：Content-Type：application/sdf；charset＝utf-8

——内容长度报头(Content Length Header)——此报头定义SOP请求中携带的内容的长度，以字节计算。该长度可以不包括SOP报头。其可以是在SOP数据包中携带的SDF有效负载的长度。实例：Content-Length：158

——距离报头(Distance Header)——此报头帮助识别网络实体距接收者的距离。其可以用于发布消息中以广告服务。此报头的值在转发发布消息的任何时候增加。接收者可以使用到服务的最短路径，并且避免服务路由循环。实例：Distanc：1

——目的地报头(Destination Header)——此报头可以存在于转移消息中。其用来指示将接收服务的目的地服务节点的地址。实例：Destination：defaultsn.provider.com

——交换报头(Exchange Header)——此报头用来标识其内发生事务的交换。交换标识符的使用有助于关联跨域、多个设备或可能涉及多个设备或多个服务提供商的其他复杂的服务管理。此报头可以存在于请求-响应消息中。实例：Exchange：43shXui7236

——自报头(From Header)——此报头标识服务请求的发起者。其可以指示发起者的地址。实例：From：defaultp.provider.com

——节点类型报头(Node Type Header)——此报头标识SOP网络中的节点的类型。该报头可以具有以下值中的一个：(a)“service-client”(服务-客户端)，(b)“workflow-server”(工作流-服务器)，(c)“service-proxy”(服务-代理)以及(d)“service-node”(服务-节点)。此报头用于注册、发布和预订消息中。在注册和发布消息中，其有助于标识发送者类型和区别各种类型的注册或发布。在预订消息中，其帮助代理确定必须将哪个节点的信息转发到请求者。实例：Node-Type：service-node

——优先权报头(Priority Header)——此报头可以由请求者添加以便将其处理比其他待决消息优选考虑。优先权可以是从1到65535的任何数字，其中65535最高。此字段可以结合云服务网络中的策略决定使用以便将某些请求比其他请求优选考虑。实例：Priority：5

——查询类型报头(Query Type Header)——此报头可以用于获取请求中以获得关于任务ID、工作流名称、工作流ID、工作流ID对工作流名称的列表或任务ID对工作流ID或名称的列表的信息。该报头可以具有以下值：

(a)“active-workflows”(有效工作流)——所有工作流id对工作流名称。工作流名称可以存在于请求中。

(b)“active-tasks”(有效任务)——用于工作流名称或工作流ID的所有任务id。工作流名称和/或工作流ID可以存在于请求中。

(c)“workflow-name”(工作流名称)——任务中的工作流的描述，由工作流名称指定。工作流名称可以存在于请求中。

(d)“workflow-id”(工作流id)——在工作流的特定实例中执行的任务的描述，由工作流ID表示。工作流ID可以存在于请求中。

(e)“task-id”(任务id)——构成由任务ID指代的特定任务的属性的描述。任务ID可以存在于请求中。工作流名称和工作流ID可以存在。

实例：Query-Type：workflow-id

——发布超时报头(Publish Timeout Header)——此计时器指示服务节点可以将其服务发布给代理的周期，与服务可用性的改变无关。实例：Publish-Timeout：500

——重试次数报头(Retry Count Header)——此报头定义服务节点在接收执行消息之前响应创建、删除、转移或更新消息可以发送200 OK消息的次数。在每次重试时，执行超时(Commit-Timeout)可以在试图重试之前到期。在完成重试的重试次数之后，服务节点可以开始服务回滚。此报头在广告消息中发送并且可以在各个创建、删除、转移或更新消息中发送。在后一种情况下，计数仅应用于那个特定交换。实例：Retry-Count：3

——请求者报头(Requestor Header)——在一些实施例中，请求的发起者可以与请求者不同。例如，代理可以使用未包括在SOP协议中的触发器发起请求。将请求者的信息包括在SOP消息中是有帮助的。此信息可用于记账或其他用户专用定制。此报头可以与自报头相同或类似。实例：Requestor：service-clientcustomer.com

——注册超时报头(Registration Timeout Header)——此报头向服务节点指示必须在其内再次注册的时间。实例：Registration-Timeout：10000

——服务ID报头(Service ID Header)——服务ID可以用来指代虚拟服务的特定实例。代理可以响应于注册消息来返回唯一服务ID。那个ID在将来可用来标识服务。在新服务创建的情况下，新服务ID也可以由工作流服务器指示。移动服务可以保持服务ID。实例：Service-ID：8743435compute；Service-ID：8743435compute-resources.provider.com

——序列ID报头(Sequence ID Header)——此报头存在于请求中并且标识相同类型的请求的序号。通过添加序号，接收者具有标识哪些请求稍后到达的能力。序号在它们到达最大值(例如，32位无符号整数)之后被重置。实例：Sequence-ID：8624 CREATE

——源报头(Source Header)——此报头用于服务移动性并且指示将转移服务的源服务节点的地址。实例：Source：defaultsn.provider.com

——预订超时报头(Subscribe Timeout Header)——此计时器指示节点必须发送用于服务节点或客户端的预订消息的周期，与其可用性的改变无关。实例：Subscribe-Timeout：500

——任务ID报头(Task ID Header)——此报头指示TS中的唯一类型的配置。可以跨多个服务节点使用公共ID。可以基于获取消息中的请求者的地址来传递服务节点专用的配置。ID的使用允许配置存储在中心。实例：Task-D：67439375

——时间戳报头(Timestamp Header)——此报头可以由请求者添加以标识请求发起的时间。其可以用来丢弃比指定的到期时段旧的请求。时间戳例如将根据从1961年1月1日开始的UTC来指定到期秒数。实例：Timestamp：1285162130

——至报头(To Header)——此报头标识服务请求的目的地。其可以指示服务请求针对的标识符。实例：defaultp.provider.com

——转移模式报头(Transfer Mode Header)——此报头用于注册消息中。服务节点标识其可以支持服务移动性的方式。如果服务节点能够将现场状态转移到另一个服务节点，则其将此报头设置为“stateful”(有状态)。如果服务节点不能转移现场状态，则其将此报头值设置为“stateless”(无状态)。在无状态转移中，创建服务实例并且删除旧的实例。实例：Transfer-Mode：stateful

——通过报头(Via Header)——此报头可以由节点使用请求所遍历SOP来插入，条件是节点不用作无状态代理。转发器插入其SOP地址和随机“分支”参数以标识对等实体之间的事务。该报头还将具有SOP版本并指示通过其传送SOP消息的传输。实例：Via：SOP/1.0/UDP defaultsb.provider.com；branch＝k9DjR5 lbcw

——工作流ID报头(Workflow ID Header)——此报头指示工作流的唯一实例。可以基于用户专用策略来为用户定制工作流。工作流ID是工作流的特别定制的实例。其可以参考工作流服务器中所存储的工作流，或者具有适合数量的参数，以稍后计算工作流。实例：Workflow-ID：68743693provider.com

——工作流名称报头(Workflow Name Header)——此报头标识服务提供商内的唯一工作流。工作流名称允许客户端或代理请求工作流执行。代理发送列出可用工作流的发布消息。工作流名称标识支持工作流的服务提供商。这允许工作流名称重叠在提供商上。实例：Workflow-Name：X32mnTrUwqprovider.com

——工作流服务器报头(Workflow Server Header)——此报头提供服务节点或代理可以查询以处理请求(诸如以获得任务描述)的工作流服务器的地址。此报头可以结合任务ID报头使用。实例：Workflow-Server：Workflow-Server.provider.com

在一些实施例中，服务节点可以由诸如servicesn.provider.com的名称来定址，其中“sn”是服务节点并且“service”是服务节点处的虚拟服务实例。如果存在一个用于许多虚拟化服务实例的服务节点，则该服务节点可以接收用于虚拟化服务实例的所有消息，即使他们被定址到特定“service”。服务节点可以为了服务对请求采取动作或者将信息传递到服务。当消息被广播时，可以使用类型defaultdefault.provider.com的地址，并且数据包将使用广播IP地址。

在一些实施例中，以下计时器和/或计数器中的一个或多个可以由代理(例如，代理112、118和142)在实施用于管理服务的公共协议时使用：

——重传计数器(Retransmission Counter)——此计数器定义在发送取消消息之前用于请求或者在预期执行消息之前用于响应的重传次数。计数器的值在广告消息中由重试次数报头全局地设置，或者在创建、删除、转移或更新消息中按事务设置。

——确认超时(Acknowledge-Timeout)——这指示在其之后服务节点可以将“提示”200 OK消息发送给代理以请求执行消息的时间。在200 OK消息的某些次数的重试之后(例如，由重传计数器指定)，服务节点将考虑取消事务并且开始回滚操作。

——注册超时(Register-Timeout)——这指示代理将接受注册的最大时间。服务节点在那个时间内通过代理注册。如果在此时间到期之前未接收到注册消息，则代理将服务节点和其服务标记为不可用。在接收到匹配其能力的注册消息时，代理发送200 OK消息。

——广告超时(Advertise-Timeout)——这指示在其之后代理将发送广告消息的时间。如果代理指示用于广告消息的时间周期已经接连到期三次，则服务节点可以传送发现消息以请求可以促进其服务域的代理。此计时器在广告消息中由广告超时报头设置。

——取消超时(Cancel-Timeout)——在发送任何请求之后启动计时器，并在接收任何临时或最终响应(诸如100尝试或200 OK消息)之后，重置计时器。如果未接收到临时或最终响应，则发送者将请求传送如(例如，在重传计数器中)所指定的某个次数。如果仍未接收到临时或最终响应，则发送者发送取消消息并且将终止事务。此计时器在广告消息中由取消超时报头设置并且在创建、删除、转移和更新消息中其可以基于每次事务被覆盖。

——执行超时(Commit-Timeout)——在对其中预期执行消息的事务(例如，创建、删除和转移消息)发送200 OK消息之后，将由响应者启动此计时器。在计时器到期之后，200 OK消息将被重传达如由重传计数器指定的最大次数。当执行超时已经到期那个次数时(在发送200 OK消息之后)，响应者安静地丢弃(或回滚)其之前已经执行的改变。此计时器在广告消息中由执行超时报头设置，并且在创建、删除、转移和更新消息中其可以基于每次事务被覆盖。

——发现超时(Discover-Timeout)——在启动之后或者在广告计时器的三次接连超时之后(即，在三次接连超时之后代理尚未发送广告消息)，由服务节点立即启动此计数器。当计时器到期时，服务节点传送发现消息。在接收到匹配服务节点的服务域的广告消息时，重置计时器。此时间具有十五秒的固定值，因为需要计时器发现代理并且在接收广告消息之前。

——发布超时(Publish-Timeout)——此计时器定义服务节点在其内必须发送其服务更新的时间周期，与服务状态的任何改变无关。这将刷新代理的服务数据库，并且防止过期信息。此计时器在广告消息中设置。实例：Publish-Timeout：500

——预订超时(Subscribe-Timeout)——此计时器定义节点在其内必须发送预订消息以请求对服务节点或客户端的可用性的更新的时间周期。这将刷新代理的预订数据库，并且防止过期信息。此计时器在广告消息中设置。实例：Subscribe-Timeout：5000

——重传超时(Retransmit-Timeout)——此计时器定义节点在其内必须发送100尝试响应以确认请求的时间周期。如果在此时间内未接收到100尝试响应，则发送者重传请求达指定的最大次数。此计时器在广告消息中设置。实例：Retransmit-Timeout：5000

在一些实施例中，属性230和服务描述符240可以包括与服务名称、服务类别、用于服务类别的性质的句法、服务类别中的语义、到单个工作流中的多个服务类别包以及任务和工作流的描述有关的信息。

服务描述符240可以包括XML模式。例如，可以包括XML方案以用于域名“iaas.network”中的“hub”(集线器)，将是：

如另一个实例，可以包括XML方案以用于域名“iaas.network”中的“router”(路由器)并且添加“ip-address”(ip地址)和“subnet-mask”(子网掩码)元素，将是：

<domain>XML元素用来封装接收者可以解译的域专用服务描述。此元素具有以下属性：

——域名属性(Domian Name Attribute)——这是用于含在<domain>标签内的有效负载的服务名称。其帮助接收者标识服务名称并确定接收者是否知道如何处理有效负载；

——类型属性(Type Attribute)——这具有两个可能值：“capability”(能力)和“availablility”(可用性)。“capability”属性用于由接收者进行的请求动作中。“availablility”属性由服务用来广告其服务可用性。通过虚拟化的服务，可用性随着服务分配给用户而减少，然而能力保持不变。然而，在部分或全部服务故障(诸如软件或硬件故障)的情况下，能力将改变。

——定义属性(Def Attribute)——这允许以相同方式发送标准和非标准有效负载。对于标准域，属性具有值“sdn”，并且对于非标准域，属性被设置为“vsd”。

在此描述的示例性域方案可以结合现有的标准或非标准服务定义来使用。例如，域方案可以结合现有规范(诸如在http：//xml.coverpages.org/DMTF-OVF-vl0-DSP0243.pdf描述的开放虚拟化格式(Open Virtualization Format，OVF))使用。OVF方案将需要由域名(诸如iaas.compute.virtual)来标识。这在以下展示。

<！--list of OVF elements and attributes-->

</domain>

在一些实施例中，可能需要供应商来传递非标准的服务定制。这些服务可以与标准服务定义相同或类似的方式来定义。为了指示其是供应商专用域(并且可能不被每个网络元件理解)，域可以(a)被提供不与标准域名重叠的名称，和(b)由<domain>元素中的def＝″vsd″属性标识。例如，“Vendor”(供应商)可以定义其私有域“vendor.router”并且此域将如下参考。

<！--list of vendor-specific elements and attributes-->

</domain>

在一些实施例中，供应商定义的域可以从供应商的名称开始。供应商专用域(VSD)在它们如何跨边界使用方面被不同地处理。例如，供应商可能向选定顾客广告VSD。

在一些实施例中，与服务域相关的XML模式定义元素、其属性和用于描述元素和属性的句法。可以使用域语义来描述服务域内和跨服务域的属性之间的关系。所描述的关系可以指示如何分配资源(逻辑、虚拟或物理的)以填充XML文件中的元素和属性。例如，分配给虚拟机的MAC地址可以是虚拟机将要与其交互的主机中唯一的。此唯一性是各个MAC地址之间的关系。继续该实例，虚拟机的MAC地址也可以在网络上的访问列表中。这是计算与网络域之间的关系。如另一个实例，可以将基于网络的存储映射到主机上的文件系统，从而需要跨计算和存储域的逻辑和虚拟资源的映射。为了限制访问某些主机的存储，在主机、网络与存储域之间可以存在关系。域内和跨域的属性之间的关系约束资源分配。当根据这些约束来分配资源时，跨不同域创建的服务几乎没有冲突地一起工作。域语义是域内和跨域的属性之间的关系。

表达属性之间的关系的一种方式是使用诸如XML的高级语言。例如，可以使用诸如目标约束语言(Obiect Constraint Language)和SCHEMATRON的XML技术来描述语义关系。以下展示示例性约束，其中配置在虚拟机接口上的虚拟局域网(virtual local areanetwork，VLAN)等于在网络交换机上允许的VLAN访问。

/iaas.network.switching/port-list[0]/aclvlan＝

/iaas.compute.virtual/vm-list[0]/interface-list[0]/vlan

在一些实施例中，规定域属性之间的关系的语义规则可以在单独的域语义规则(Domain Semantics Rules，DSR)文件中定义。每个DSR文件可以与工作流相关。类似于分级域规范，也有可能定义父和子DSR文件。全部DSR文件的语义的规范可以提供快速定制的服务和创建的新服务。DSR文件的可重用的层级可以被定义以促进跨域的服务关系。

在一些实施例中，服务描述符240可以包括用于任务和/或工作流的标识符。

包括属性230和服务描述符240中包括的信息的示例性XML模式如下：

在一些实施例中，数据包200可以说明属性230和描述符240分开一组域专用元属性和供应商专用服务描述的方式。元属性包括如同服务类型(例如，计算、网络、存储、防火墙、负载平衡器、应用和其他适合的服务)、供应商、软件和硬件版本、域专用属性参数或属性(诸如通信即服务、网络即服务、存储即服务、软件即服务或其他适合的服务专用的属性)的事物。元属性也可以标识用于供应商专用服务描述的格式类型。这些元属性可以由一个或多个代理(例如，代理112、118或142)理解，因为需要服务描述与代理所提供的管理之间的最小连接。元属性可以帮助代理局部地聚合服务类型，这对于为服务创建选择适当种类的资源来说是必要的。一旦标准化了元属性，则服务描述数据可以是非标准的、供应商专用的或者以其他方式适当地配置。使用此分开，任何种类的服务描述可以通过代理透明地传达。这些描述中的一些可以标准化并且其他是私有的。服务描述可以携带命令行接口命令、XML数据包、基于文本的或二进制格式化的文件。代理可能不需要知道服务描述内除了元属性之外有什么。域专用元属性可以由标准化不同种类的基于网络的服务(例如，云服务)的不同的标准组织来借用或开发。

在一些实施例中，代理可以从策略服务器获得私有与标准描述的组合，并将其透明地传递到硬件或软件实体。这可以实现此实体可以升级的可能性，并且实现具有相同代理的新特征的透明使用。此实体的属性可以改变供应商专用属性，同时保持域专用属性。可以使用所提出的元数据与数据之间的分开来开发专用于特定种类的云编排(cloud orchestration)的域专用代理。该机制还可以用来创建跨越几个不同的服务域的多供应商和多产品服务管理。

图3示出了能够分支工作流的系统300的一个实施例。系统300包括代理302、304、306、307和308。工作流节点312、314、316、317和318分别与代理302、304、306、307和308相关并且联接到其。服务节点322、324、326和328分别与代理304、306、307和308相关并且联接到其。在系统300中，由代理302接收的工作流可以使用分支使其任务由服务节点322、324、326和328执行。这可以由代理304、306、307和308以及工作流节点314、316、317和318促进。用于定义排序任务的方案可以使用XML模式并且可以依照诸如服务工作流描述语言(Service Workflow Description Language，SWDL)的语言。

存储在系统300中的节点的存储器中的信息可以使用用于存储和检索信息的任何适合的结构来实施。数据库、文件系统、表格、列表或这些结构的适合的组合是可以如何存储这些信息的实例。可以使用计算机可读永久存储介质，诸如：基于半导体的或其他集成电路(IC)(例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘、HDD、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、其他适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

当工作流跨多个服务节点(例如，计算、存储、网络、安全和/或软件)时，可以存在将工作流分成各个任务以供执行的位置(例如，代理302和工作流节点312)。分支工作流涉及将任务分配给不同的服务节点。在一些实施例中，网络中将工作流分解为任务的位置(例如，代理302和工作流节点312)可以称为工作流锚点。工作流中的子任务由工作流锚点处的工作流节点(例如，工作流节点312)确定。这些任务可以由工作流锚点处的代理(例如，代理302)开始。

在一些实施例中，通过为工作流中的各个项加标签并且使用例如“prev”(上一个)和“next”(下一个)标签来对项排序来使用任务、任务组和工作流创建流程图。每个工作流可以具有相关的工作流锚点。以下XML是工作流的示例性实施：

每个任务的“类型”可以映射到由系统100的代理使用的消息之一。“服务器”属性定义将处理任务或工作流的服务实体。“服务器”可以是服务节点(例如，服务节点132)、代理(例如，代理142)或工作流服务器(例如，工作流服务器152)。工作流中的“实例”属性可以是表示执行工作流的一个实例的交换值。

在一些实施例中，工作流消息由实施SOP的代理用来执行以上讨论的关于工作流的功能性。工作流消息可以含有被请求的工作流名称。请求还可以含有完整或部分的工作流描述。工作流锚点之前的所有网络元件可以转发工作流消息请求而无需将其分支为任务。当接收工作流消息时，工作流锚点使用获取消息提取工作流并且将其连同工作流名称一起发送到相关工作流服务器。这请求工作流服务器验证和完成工作流规范。获取请求中的工作流用作工作流服务器的输入以构造完整的工作流规范。工作流服务器可以覆盖工作流描述或者可以使用例如所配置的策略拒绝获取请求。如果已经接受了工作流，则完整的工作流规范可以指定工作流锚点可以执行的各个任务，诸如创建、删除、转移、执行或其他适合的任务。在接收完成的工作流规范时，工作流锚点可以继续执行工作流。如果已经拒绝了工作流，则工作流锚点可以将拒绝指示转发到上游网络元件。

在一些实施例中，工作流消息允许服务包被作为原子服务处理以用于上游网络元件。客户或提供商可以创建工作流描述并且使用发布消息来使用唯一服务名称通过服务网络将其发送。用户或服务提供商可以通过工作流消息请求此服务。通过将工作流锚定在特定位置中，可以保证工作流的正确执行。工作流锚点确保在执行之前验证和授权工作流并且在完成之后记账。

在一些实施例中，工作流锚点是有帮助的，因为一旦将工作流分支成任务，则接收这些任务的其他下游实体(例如，代理304、306、307和308)并不具有整个工作流并且因此它们不能将工作流作为整体管理。工作流锚点(例如，代理302和工作流节点312)管理工作流。其负责(a)执行正确任务，(b)以正确次序执行这些任务，(c)在执行之后对任务正确记账，以及(d)当出现故障时以正确方式对其处理，以及其他责任。

在一些实施例中，锚点位置上游的网络元件可能不能将工作流分支成任务。这些元件可以验证工作流，但是它们不负责这样做。包括锚点位置的节点可以负责验证工作流和正确执行。可以存在代理和客户端可以通过其请求完整的工作流的接口。

在一些实施例中，在锚点位置的代理(例如，代理302)处接收到的工作流请求可能是不完整的。该请求可以指定关于虚拟机的参数，并且可以将网络、存储和安全的细节留给例如锚点位置。此请求可以转发到相关的工作流节点(例如，工作流节点312)以在执行工作流之前获得其完整且精确的描述。

工作流锚点可以位于网络中的多个点处，诸如在客户位置或在服务提供商位置。例如，工作流锚点可以在服务的客户端处并且客户端将必须管理工作流执行、服务记账和故障处理。在此实例中，客户代理和服务提供商代理(例如，代理304和306)可以检测或认证传输中的消息但是它们可能不知道任务的完整序列并且将不能验证工作流锚点是否执行正确的任务序列。

在一些实施例中，工作流可以使用客户的代理或服务提供商的代理来锚定。客户端随后将向这些代理之一请求工作流执行。客户端可以通过一些工作流名称指代工作流以用于接收代理来验证是否正确形成请求。工作流的执行可以由客户或服务提供商的代理来管理，而客户端仍可以知道工作流组合并且可以构建工作流请求。用作工作流锚点的代理将在分支任务之前验证工作流。代理可以确保记账和故障处理。

取决于部署情景，工作流锚点可以位于网络中的各个点处。对于个人云来说，如一个实例，客户端可以是有效锚点位置。对于私人企业云来说，如另一个实例，客户的代理可以是有效锚点位置。对于公共云来说，服务提供商的代理可以是有效锚点位置。对于社区云来说，服务节点可以是有效锚点位置。

系统300的示例性应用涉及其中客户通过经由单个请求组合在私人云和公共云中的工作流来创建复杂服务的情况。另一个实例涉及通过相同请求在其网络和另一个服务提供商的网络中创建服务的服务提供商。如另一个实例，单个请求可以由提供商的网络内的多个域专用代理(例如，代理307和308)管理。为了跨服务域和提供商/客户边界分布工作流，可以将大工作流分解成各个代理所拥有的各个工作流。

如一个示例性操作，代理302可以接收称为MN(M和N是两个阶段)的两阶段工作流，并且可以将两个阶段转发到代理304和306。代理304可以使用服务节点322来执行工作流M。代理306可以将工作流N分成工作流X、Y和Z。代理306可以使用服务节点324来执行工作流x。代理306可以将工作流Y和Z分别委托给代理307和308。代理307可以使用服务节点326来执行工作流Y，并且代理308可以使用服务节点328来执行工作流Z。

在一些实施例中，可以改变工作流的实施，同时保持其接口不变。工作流与其分支模式之间的映射也可以改变。这可以在部署服务方面为操作者提供灵活性。

图5至图10示出了用于图1的系统100和图2的数据包200中的示例性消息流。图5至图10中所论述的步骤可以在需要时重复以管理服务。特定实施例可以在适当的情况下重复图5至图10的步骤。此外，尽管本公开将图5至图10中的特定步骤描述和示出为以特定次序发生，但是本公开考虑图5至图10中的任何适合的步骤以任何适合的次序发生。此外，尽管本公开描述和示出执行图5至图10中的特定步骤的特定组件、设备或系统，但是本公开考虑执行图5至图10中的任何适合的步骤的任何适合的组件、设备或系统的任何适合的组合。

图5示出了用于发现服务节点的消息流。在步骤510，在一些实施例中，在初始化时，服务节点将发出发现消息来请求其可以将服务信息发送到的代理。发现消息携带服务节点支持的服务域。代理将仅响应其被配置到代理的服务域名。这可以允许多种服务域专用代理存在于网络中，从而管理特定种类的服务。步骤510使用的发现消息的实例如下：

DISCOVER 1 SOP/1.0

From：defaultdefault.com

Via：SOP/1.0/UDP defaultdefault.com；branch＝k9DjR51bcw

Timestamp：1285162130

Sequence-ID：1DISCOVER

Content-Type：application/sdf；charset＝utf-8

Content-Length：100

<？xml version＝″1.0"encoding＝"UTF-8″？>

在此示例性消息中，服务节点支持iaas.compute域。其发送发现消息来找到可以管理用于此域的服务的代理。

在步骤520，在一些实施例中，代理将指示其存在和准备就绪的广告消息发送给用于某些服务域的代理。这可以在初始化时、在接收到发现消息时或者在广告超时到期时(无论哪个先到)发送。在从特定服务节点接收到发现消息之后，广告消息如果发送到该特定服务节点则将作为单播发送。否则，代理将会将发现消息广播给网络中的所有服务节点。广告消息指示服务域名，这样使得具有那些能力的服务节点需要认识到其。在此步骤发送的消息的实例如下：

ADVERTISE 1 SOP/1.0

From：defaultp.provider.com

To：defaultdefault.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Timestamp：1285162132

Sequence-ID：13224 ADVERTISE

Registration-Timeout：1000

Advertisement-Timeout：2500

Commit_Timeout：30

Cancel-Timeout：15

Publish-Timeout：500

Subscribe-Timeout：5000

Retry-Count：3

Content-Type：application/sdf；charset＝utf-8

Content-Length：100

<？xml version＝″1.0″encoding＝"UTF-8″？>

广告消息还具有通过在消息本身中发出计时器和计数器信息来全局配置对应服务节点的功能。每个事务随后可以覆盖仅用于那个事务的这些值。除非在那些请求中被覆盖，否则这些值应用于所有事务。

在步骤530，在一些实施例中，在接收到在步骤520发送的广告消息时，如果域匹配则服务节点可以通过注册消息响应。如果服务节点尚未注册或者在注册超时到期时(无论哪个先到)，则将在接收到广告消息之后发送注册消息。注册消息向代理标识服务节点并且用作代理与服务节点之间的心跳。示例性注册消息如下：

REGISTER 1 SOP/1.0

From：defaultdefault.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultdefault.com；branch＝k9DjR51bcw

Sequence-ID：1 REGISTER

Transfer-Mode：service-driven

Node-Type：service-node

Content-Type：application/sdf；charset＝utf-8

Content-Length：100

<？xml version＝″1.0"encoding＝"UTF-8"？>

在以上实例中，注册消息被第一次发送到代理。服务节点尚未具有标识。因此，“From”报头具有默认地址。对于随后的注册消息，可以使用在先前注册消息中指派给服务节点的标识。

在步骤540，在一些实施例中，在接收注册消息之后并且在验证服务节点属于为其配置代理的服务域之后，代理通过200 OK响应来响应，从而指示成功注册。如果注册消息尚未指示唯一名称(在“From”字段中)，则代理响应含有服务ID报头，从而为服务节点指派名称。服务节点自此以后使用所指派的服务ID，并且代理可以拒绝不匹配所指派的服务ID名称(始终承认“默认”名称)的所有请求。代理将请求者的名称与在用于注册消息的过程中所使用以进行随后请求的其IP地址进行匹配。在此步骤发送的示例性消息：

200 OK 1 SOP/1.0

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 REGISTER

Service-ID：4357254.provider.com

在步骤550，在一些实施例中，在成功注册之后，服务节点将发布消息发送到代理以提供关于可用服务的细节。虽然周期性地发送注册消息，但是当服务可用性改变时、在第一次注册之后或者当发布超时到期时(无论哪个先到)发送发布消息。服务节点可以在服务创建或删除之后发送发布消息以更新代理的新能力(可以增加或减少)。在此步骤发送的消息的实例如下：

发布消息列出其域的能力。

在步骤660，在一些实施例中，在接收到发布消息之后，代理将其转发到适当的工作流服务器。这可以允许工作流服务器知道然后可以用于服务分配中的服务节点的能力。在成功更新其服务仓库之后，工作流服务器通过200 OK响应来响应(步骤560)。代理将200OK响应转发回服务节点(步骤580)。此响应的实例如下：

200 OK 1 SOP/1.0

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51 bcw

Sequence-ID：13432 PUBLISH

图6示出了用户如何(在诸如图1的客户节点102的客户节点处)可以发现代理。在步骤605，在一些实施例中，用户向代理发送单播发现消息。作为响应，在步骤610，代理向用户发送可以包括计时器、计数器和其他适合的参数的网络配置的广告消息。在步骤620，从用户向代理发送注册消息。此步骤可以与图5的步骤530类似的方式执行。在步骤620，代理将200 OK消息发送到用户。此步骤可以与图5的步骤540类似的方式执行。

在一些实施例中，在步骤625，由用户发送预订消息。这可以在新注册之后、当用户服务的兴趣列表改变时或者在预订超时到期时(无论哪个先到)执行。预订消息是请求-响应序列，并且如果预订消息匹配代理的服务能力则代理发送200 OK响应。如果代理的服务能力改变，则代理发出列出新的域能力的新广告消息。如果用户对那些能力感兴趣，则可以发送表达出接收关于那些服务的信息的兴趣的新预订消息。如果发送没有任何特定域的预订消息，则代理将其解译为对所有服务域的兴趣。用户包括节点类型作为“服务-客户端”。在步骤625发送的示例性消息如下：

SUBSCRIBE 1 SOP/1.0

From：defaultws.provider.com

To：defaultp.provider.com

Via：SOP/1.0/UDP defaultws.provider.com；branch＝k9DjR51bcw

Exchange：43shXui7236

Timestamp：1285162130

Sequence-ID：1 SUBSCRIBE

Node-Type：service-client

Content-Type：application/sdf；charset＝utf-8

Content-Length：154

<？xml version＝″1.0″encoding＝"UTF-8″？>

在步骤630，在一些实施例中，代理将预订消息转发到工作流服务器。这可以在预订消息标识出代理可以支持的服务域时发生。工作流服务器验证用户是否被授权接收那些服务。如果用户被授权，则工作流服务器通过至代理的200 OK响应来响应(步骤635)。在步骤640，代理将200 OK响应转发到用户(步骤640)。此响应的实例如下：

200 OK 1 SOP/1.0

From：defaultp.provider.com

To：defaultws.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：1 SUBSCRIBE

在步骤645，在一些实施例中，工作流服务器通过发布消息来发送对服务的更新。这些更新在接收到第一预订消息之后、在服务可用性改变(例如，可获得新服务或者移除旧服务)的任何时候或者在发布计时器(Publish-Timer)到期时(无论哪个先到)发送。发布消息被转发到代理，代理将其发送给用户(步骤650)。在一些实施例中，代理将From报头变成其自己的地址。这可以用来向用户隐藏工作流服务器。工作流服务器可以通过发布消息向用户标识信息类别。实例如下：

——工作流服务器可以将在其网络中可用的每个服务节点的细节转发给用户和其各个服务能力。

——工作流服务器可以仅转发网络中通过服务域、地理区域或其他标准聚合的服务节点的聚合状态。

——工作流服务器可以指示其支持来自某个域的服务。

——工作流服务器可以将用户可能感兴趣的所有可用工作流列表发送给用户。

——工作流服务器可以过滤可用工作流并且仅发送已经明确为用户配置的那些工作流。

因此，发布消息可以具有不同类型的内容。接收代理使用节点类型报头来应用发布的节点专用策略(结合其他策略)。以下实例示出发布工作流的发布消息。

工作流含有用户需要填充的任务、域和属性的列表。工作流服务器可以掩盖用户可见的工作流的任务、服务域和属性中的一个或多个。事实上，用户指定工作流的某些部分，并且将剩余部分留给工作流服务器。工作流可以被视为暴露给用户的API，其中用户被允许在与代理通信之前标识某些参数。

在步骤655，在一些实施例中，在接收发布消息之后，用户通过确认消息接收的200 OK响应来响应。如果用户接受工作流，则其发送200 OK响应，该响应被从代理转发到工作流服务器(步骤660)。此响应的实例如下：

200 OK 1 SOP/1.0

From：consumercustomer.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultcustomer.com；branch＝k9DjR51 bcw

Sequence-ID：1PUBLISH

图7示出了代理(称为代理1)如何可以发现另一个代理(称为代理2)。流程700类似于图6的流程600。在步骤705，从代理1向代理2发送发现消息。在步骤710，从代理2向代理1发送广告消息。从代理1向代理2发送注册消息(在步骤715)。作为响应，从代理2向代理1发送200 OK响应(在步骤720)。步骤705至720可以与以上关于图6的步骤605至620所述类似的方式执行。

在步骤725，在一些实施例中，从代理1向代理2发送预订消息连同其感兴趣的服务域。这是以与图6的步骤625类似的方式进行。节点类型报头被设置为“service-proxy”。预订代理1接收服务信息。在步骤730，代理2将预订消息转发到工作流服务器(以与图6的步骤630类似的方式)。

在步骤735，在一些实施例中，工作流服务器将200 OK响应发送到代理2。在步骤740，此响应被转发给代理1。这些步骤是以与图6的步骤635和640类似的方式执行。

在步骤745，在一些实施例中，工作流服务器将发布消息发送到代理2。此消息包括关于工作流的信息，包括管理信息和当前容量的细节或概要(取决于所配置的策略)。在步骤750，代理2将发布消息转发到代理1。在步骤755，从代理1向代理2发送200 OK响应。在步骤760，代理2将200 OK响应转发到工作流服务器。步骤735至760是以与图6的步骤635至660类似的方式执行。

图8是示出了示例性服务提供流的消息流程图。在此实例中涉及的实体包括两个服务节点(服务节点1和服务节点2)、用户(例如，在诸如图1的客户节点102的客户节点)、代理和工作流服务器。上面关于图1的论述提供这些实体的示例性实施。

在步骤802，在一些实施例中，用户通过发送工作流消息来发起工作流。此消息的实例如下：

WORKFLOW 1 SOP/1.0

From：consumercustomer.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.customer.com；branch＝k9DjR51bcw

Sequence-ID：5 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

用户指示已经存在的工作流名称。此消息可以含有工作流任务的详细规范和参数。在工作流请求穿过网络朝向工作流锚点时，该请求可以在传输中由中间代理修改。每个代理查找工作流名称的源并且将其转发到另一个代理，直到其到达将用作工作流锚点的代理(图8中示出)。

在一些实施例中，在步骤804，用作工作流锚点的代理发送100尝试响应以向用户指示其接收到请求并且对其处理。此响应的实例如下：

100 TRYING 1 SOP/1.0

From：defaultp.provider.com

To：consumercustomer.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51 bcw

Sequence-ID：5 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

在步骤806，在一些实施例中，代理将获取请求发送到对应的工作流服务器以寻求工作流的细节。如果接收到具有详细的工作流描述的原始请求(在步骤802发送)，则代理将描述发送到工作流服务器。工作流服务器使用接收到的工作流来使用一个或多个策略确定完整且完成的工作流。获取消息的实例如下：

GET 1 SOP/1.0

From：defaultp.provider.com

To：defaultws.provider.com

Exchange：43 shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9oluElbcw

Sequence-ID：286 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

Query-Type：workflow-name

Requestor：consumercustomer.com

获取消息包括到请求者报头中的请求者名称。这可以允许工作流服务器验证所指示的工作流是否可用于请求者并且应用用户专用策略(若有的话)。

在步骤808，在一些实施例中，工作流服务器将使用200 OK响应返回包括各个任务的工作流描述。此实例如下：

此时，工作流服务器基于在步骤802发送的请求使用一个或多个策略创建工作流的实例。此实例由工作流ID“68743693”参考。在此实例中，其携带虚拟机的详细配置(其由任务ID＝"67439375"参考)。工作流服务器已经分配用于“创建”任务的服务器“4357254.provider.com”。

在步骤810，在一些实施例中，代理将创建请求发送到选定服务器、服务节点2。此消息的实例如下：

CREATE 1 SOP/1.0

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 CREATE

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

以上创建请求由代理“p.provider.com”发送到服务器“4357254.provider.com”。创建消息通知接收者存在在“ws.provider.com”等待的任务ID“67439375”。接收者应获得那个任务并且将其执行。请求者字段描述为其代理请求的用户。

在步骤812，在一些实施例中，代理可以使用获取消息请求由来自工作流服务器的服务节点1执行的第二任务。在步骤814，工作流服务器可以配置成使用200 OK响应消息来发送所请求的信息。在步骤816，代理可以对服务节点1使用创建消息来向服务节点1通知任务。步骤812、814和816可以类似于806、808和810的方式实施。

在步骤818，在一些实施例中，服务节点2使用获取请求从工作流服务器下载由任务ID标识的任务描述。实例如下：

GET 1 SOP/1.0

From：default4357254.provider.com

To：defaultws.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP

default4357254.provider.com；branch＝cw8gtrB56m

Sequence-ID：390 GET

Query-Type：task-id

Task-ID：67439375

在步骤820，工作流服务器将任务描述转发到请求者，如以下所展示。任务描述将由接收者执行的属于域“iaas.compute”的工作流。

如果服务节点2不理解任务模式，则其可以丢弃描述并且发送400错误请求响应。在完成处理之后，服务节点2在步骤822发送200 OK响应。此实例如下：

200 OK 1 SOP/1.0

From：default4357254.provider.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP

default4357254.provider.com；branch＝k9DjR51bcw

Sequence-ID：134 CREATE

类似地，在完成与在步骤816发送的创建消息相关的处理之后，服务节点1在步骤824发送200 OK响应。

在步骤826和828，在一些实施例中，代理通过将执行消息发送到服务节点1和2来执行服务。执行消息在以下情况时有用：

(a)工作流可以涉及许多并行的事务并且如果一个事务失败则代理可能不执行请求；(b)代理在进行请求之后可能已经失败，并且服务节点随后将取消先前的事务并且删除服务。执行超时计时器(通过广告消息接收)确定何时必须取消事务。示例性执行消息如下：

COMMIT 1 SOP/1.0

From：defaultp.provider.com

To：default4357254.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.provider.com；branch＝khewui6GDw

Sequence-ID：134 COMMIT

Task-ID：67439375

Workflow-Server：ws.provider.com

Requestor：consumercustomer.provider.com

在接收到执行消息时，如果服务休眠则服务节点“激活”服务，并且发送200 OK响应(如步骤830和832示出)。此消息的实例如下：

200 OK 1 SOP/1.0

From：default4357254.provider.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDPdefault4357254.provider.com；branch＝khewui6GDw

Sequence-ID：134 COMMIT

服务节点还发送指示其新能力和服务可用性的发布消息。能力可能已经被减少。这在步骤840和844示出。使用200 OK响应对这些发布消息作出的响应在步骤842和846由代理发送到服务节点。

在步骤834，在一些实施例中，代理使用工作流ID将执行消息发送到工作流服务器。这是将在服务删除时使用的参考，并且它们将定义如何恢复创建动作。在接收到执行消息时，工作流服务器创建代理可以发送到用户的工作流描述。在一些实施例中，仅需要使得某些任务对用户可见。例如，如果使用正分配虚拟机，则应不知道虚拟机所附接到的交换机的地址，尽管应知道虚拟机本身的地址。工作流服务器返回可以传递到用户的工作流描述。工作流服务器将此减少的任务列表作为200 OK响应的一部分返回到代理(在步骤836)，实例如下：

代理将减少的任务列表信息作为对原始工作流请求的响应的一部分转发到用户(在步骤838)。此信息帮助用户理解关于服务的某些信息以及在将来修改、删除或转移此服务所需要的信息。用户可以再使用指定特定工作流ID、任务ID和/或其他适合的信息的获取查询来获得此信息。用户还可以发送关于工作流名称的获取查询，其中查询类型被设置为“active-workflow”(有效工作流)并且使用给定工作流名称获得所有有效工作流ID。工作流ID随后可以用来查询任务ID和那些任务和工作流ID的细节。在一些实施例中，响应这些查询的工作流服务器可以确保其仅共享用户相关信息而不共享提供商认为私有的信息。

在一些实施例中，服务删除工作类似于关于提供服务的流程800。在服务删除中，初始化工作流被定义成删除服务而非创建服务。删除工作流请求包括先前的工作流ID和/或任务ID。此请求的实例如下：

WORKFLOW 1 SOP/1.0

From：consumercustomer.com

To：defaultp.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultp.customer.com；branch＝k9DjR51bcw

Sequence-ID：5 WORKFLOW

Workflow-Name：xhsdfpjTRmprovider.com

Workflow-ID：68743693

代理将获取消息发送到工作流服务器，以请求工作流描述。工作流服务器返回工作流，这由于在删除中撤销提供动作而几乎与流程800中使用的工作流相反。任务的次序可以由删除工作流确定。删除工作流的实例如下：

工作流服务器分配新的工作流ID并且提供撤销先前的服务创建的任务。新的工作流ID具有对先前的工作流ID的参考。在此实例中，任务类型被设置为“DELETE”。过程的剩余部分保持与图8中描述的过程不变。工作流服务器上的执行删除原始的工作流ID和任务ID连同作为删除操作的一部分创建的新的工作流和任务ID。

在一些实施例中，服务更新消息流与图8中描绘的类似。一个不同之处在于工作流请求参考由更新消息修改的先前工作流和/或任务。服务更新工作流请求包括先前工作流ID和/或任务ID。工作流请求还可以具有被修改的一组属性。可替代地，请求可以调用工作流，同时属性改变由工作流服务器确定。示例性工作流请求如下：

WORKFLOW 1 SOP/1.0

From：consumercustomer.com

To：defaultp.provider.com

Exchange：437eYE3XY

Via：SOP/1.0/UDP defaultp.customer.com；branch＝k9DjR51bcw

Sequence-ID：5 WORKFLOW

Workflow-Name：xhsdfpjTRmprovider.com

Workflow-ID：68743693

代理将获取消息发送到工作流服务器，以请求工作流描述。工作流服务器返回“修改的”工作流，在这个意义上其任务包括服务更新并且参考先前任务。工作流中的任务的次序由更新工作流确定。工作流服务器的响应的实例如下：

工作流服务器分配新的工作流ID并且提供更新之前的服务创建的任务。新的工作流ID具有对先前工作流ID的参考。该实例中的任务类型被设置为“DELETE”。当完成此更新时，代理使用执行消息来执行任务和工作流。响应于执行消息，工作流服务器可以删除与服务更新工作流相关的工作流ID和任务ID并更新原始的工作流ID。

图9示出了用于有状态服务移动性中的消息的实例。在有状态移动性中，在一些实施例中，服务的现场状态从源服务节点转移到目标服务节点。服务的实际状态转移可以使用诸如FTP的现有协议来复制服务状态。流程900示出了标识用来转移服务状态的资源的控制会话。

在步骤902，在一些实施例中，客户端(例如，图1的客户节点102)通过发送工作流消息来开始服务移动性。消息包括对需要移动的过去工作流和/或任务ID的参考。源代理接收工作流消息并使用获取消息将工作流消息的内容转发到工作流服务器以获得工作流的描述(在步骤904)。获取消息的实例如下：

GET 1 SOP/1.0

From：defaultpl.provider.com

To：defaultws.provider.com

Exchange：43shXui7236

Via：SOP/1.0/UDP defaultpl.provider.com；branch＝k9oluElbcw

Sequence-ID：286 WORKFLOW

Workflow-Name：gTyuI82Zxprovider.com

Query-Type：workflow-name

Requestor：consumercustomer.com

在步骤906，在一些实施例中，如果工作流被授权用于客户端并且工作流服务器可以找到适当的资源来移动服务，则其发送200 OK响应。此实例如下：

在步骤908，在一些实施例中，源代理通过将转移消息发送到目标代理来开始执行服务转移。目标代理可以由工作流服务器选择并且作为“server”(服务区)填充在任务的<domain>元素中。转移消息的实例如下：

在一些实施例中，目标代理基于接收到的服务描述来选择用于服务的目标服务节点。在那之后，其将转移请求转发到选定服务节点以将其准备用于接收服务(在步骤9100)。如果分配失败，则目标代理可以拒绝该请求。转移消息的实例如下：

在此实例中，保持“Requestor”和“Source”报头以使得目标源节点知道代理和被移动的服务的标识。如果目标服务节点赞同该移动(例如，其具有必需的服务域能力和资源)，则其发送200 OK响应(在步骤912)。目标服务节点可以赞同来自其接收到的一个描述的修改的服务描述。目标服务节点还必需添加“Destination”(目的地)报头作为目标服务的名称。在步骤912发送的响应的实例如下：

在步骤914，目标代理将响应发送到源代理。在接收到200 OK响应时，源代理在步骤916使用接收到的服务描述并且将其在转移消息中发送到源服务节点。如果源服务节点对其赞同，则源服务节点使用源和目的地报头作为自(From)和至(To)报头来开始服务创建(在步骤918)。如果服务转移成功(由在步骤920发送的200 OK响应指示)，则源代理将执行消息发送到源服务节点(在步骤922)并且通过目标代理发送到目标服务节点(在步骤926和932)。在步骤924，对这些消息的响应(200 OK响应)从源服务节点并且从目标节点(通过目标代理)向源代理发送。执行消息的实例如下：

源代理还在工作流服务器中执行工作流以使得在工作流服务器处知道服务的新位置。此位置可以用来确定随后的移动性动作或服务删除。这通过从源代理向工作流服务器发送执行消息(在步骤928)来执行。在步骤930，工作流服务器通过200 OK消息来响应。

在步骤938和940，在一些实施例中，源和目标服务节点分别将发布消息发送到源和目标代理。这可以用来在已经转移服务之后向这些代理通知服务节点的能力和资源。代理将200 OK响应发送到服务节点以指示发布消息的接收(在步骤942和944)。

在步骤946，在一些实施例中，源代理将200 OK响应发送到客户端以指示服务移动的成功完成。

图10示出了发送以实施无状态服务移动性的示例性消息组。在无状态服务移动性中，创建具有相同服务属性的新服务，尽管当前服务实例的现场状态未被复制到新实例。

在步骤1002，在一些实施例中，客户端(例如，图1的客户节点102)通过将工作流消息发送到源代理来开始服务移动性。此步骤可以类似于图9的步骤902执行。作为响应，源代理可以将获取消息发送到工作流服务器(在步骤1004)以获得与在步骤1002发送的消息中标识出的工作流有关的信息。工作流服务器可以在步骤1006发送200 OK响应中的信息。步骤1004和1006可以类似于图9的步骤904和906的方式执行。

在步骤1008，在一些实施例中，从源代理向目标代理发送创建消息。这与流程900不同之处在于不使用转移消息。相反，工作流发送两个独立但是协调的任务，一个创建新服务实例而另一个删除旧服务实例。在步骤1008，使用来自在步骤1006提供的信息的细节来实施创建消息，意欲指导目标服务节点创建在流程1000中转移的服务实例。目标代理在步骤1010将创建消息发送到目标服务节点并且在步骤1012从目标服务节点接收200 OK响应。此响应在步骤1014从目标代理发送到源代理。

在步骤1016，在一些实施例中，源代理将删除消息发送到源服务节点。这使得源服务节点将停止提供从其转移到目标服务节点的服务。在步骤1018，响应于删除消息，200 OK响应被从源节点发送到源代理。

在一些实施例中，将执行消息从源代理发送到源服务节点(在步骤1026)、通过目标代理发送到目标服务节点(在步骤1024和1028)并且在步骤(1026)发送到工作流服务器。这可以类似于图9的步骤922、926、928和932的方式来执行。在步骤1022、1030、1032和1034，将对这些执行消息的响应(例如，200 OK响应)发送到源代理。这些响应可以类似于步骤924、930、934和936的方式实施。

在步骤1036和1038，在一些实施例中，源和目标服务节点将发布消息分别发送到源和目标代理。这在已经转移了服务之后可以用来向这些代理通知服务节点的能力和资源。在步骤1040、1042，200OK响应由代理发送到服务节点以指示发布消息的接收。

在步骤1044，在一些实施例中，源代理将200 OK响应发送到客户端以指示服务移动的成功完成。流程1000可以在服务状态位于服务节点之外(例如，外部数据库)时有用。流程1000可以用于灾难恢复、地理冗余或将容量从一个站点动态地向另一个移动。

可以在以上关于图1至12论述的一个或多个实例中实现优点。例如，服务部署可以跨客户和服务提供商边界。每个客户或服务提供商可以能够强制执行策略规则用于入口和出口点的服务使用。如另一个实例，可以在网络中定义分开的服务相关和服务无关功能。服务消费者或提供商可能不必须升级其基础设施来部署或使用新服务。分开允许新服务部署而不会扰乱现有服务的网络。如另一个实例，跨许多消费者、服务类型和位置的服务缩放可以由服务功能性的分布来促进。用于一组消费者的服务相关信息可能存储在一个网络元件中，或者与一类服务有关的信息可以集中在一个网络元件中。一个特定地理区域或位置中的所有消费者可以从一个特定网络元件访问服务。如另一个实例，可以促进服务的捆绑和分层。捆绑可以包括独立地工作但是通过组合具有改进的功能性的两个或更多个服务。服务可以部署在可以包括虚拟机、存储资源、服务质量参数和控制、访问控制和入侵防护的包中。分层可以涉及将另一个服务用于其运行的一个服务(例如，软件即服务(SaaS)可能使用平台即服务(PaaS)，PaaS可能使用基础设施即服务(IaaS))。如另一个实例，可以促进用户即使在网络故障的情况下也接收连续服务的能力。如另一个实例，可以为不同的用户定制单个服务(例如，安全设备可以通过入侵检测来改进)。如另一个实例，可以简化新服务的创建，同时给予客户和提供商控制服务专用参数和配置的灵活性。

优点的另一个实例是提供扩展以允许服务多样化。考虑到云应用的多样化和允许传送服务信息的标准方式内的灵活性，维持服务无关与服务相关项的分开。

优点的另一个实例是促进可能需要复杂的服务组合的服务部署。如果提供虚拟机，则也可以提供网络附加存储、安全规则(所述规则限制对那个存储的访问)、限制访问虚拟机的防火墙和访问控制、虚拟机的带宽、可以访问虚拟机的用户提供、负载平衡、广域网(WAN)优化技术以及入侵检测和防护或日志记录和报告对服务的访问的技术。

在一些实施例中，可以减少或避免各种缺点。例如，HTTP不具有可以通过其将服务信息选择性地分布在网络中的发布和预订方法。HTTP还不具有客户端或服务器的网络可以通过其发现其他网络并且在某人进行发布或预订之前广告其存在和能力的过程。这意味着作为开放系统互联(OSL层5)协议的HTTP并不适用于发现网络中的代理和服务，因为HTTP中不存在用于广告、发现、发布和预订的方法。以上论述的实施例通过允许互操作性(包括发布、预订、发现和广告特征)来提供对这些问题的解决方案。

如可以减少或避免的缺点的另一个实例，在客户端-服务器模型中，客户端可能需要等待来自服务器的响应。然而，通常不存在关于请求的超时或中途取消请求的机制。这可以使得跨已经被分叉的请求的错误处理一或多倍地困难。例如，如果一条分支腿故障，则在发布请求以取消其他腿之前系统必须等待其他腿完成。如果一条腿花费的时间太长，则其他腿不能完成。HTTP客户端连接可能不会立即关闭并且具有正确的解决方案。由于网络、软件或其他故障，此问题还可能引起网络连接损耗发生。

在一些实施例中，基于网络的服务的终端用户API控制与如上所述的代理的使用的分开可以具有以下优点中的一个或多个。其可以允许服务提供商支持多个终端用户访问和控制机制而不会改变其管理网络。已经使用API开发的应用和工具可以被迁移到其内部网络使用上述管理技术的服务提供商。API开发可以使用上述管理技术提供的相同的基本能力来创建越来越多的功能性和特征。通过API的快速革新和服务创建因此可以与网络中的某些服务管理技术分开。分开可以允许终端用户不需要理解如何实施可能是特定提供商专有的服务的细节。服务提供商可以保持API但是通过策略连续地演变内部服务实施逻辑。

图11描绘示出了使用以上关于图1至图10所论述的技术提供服务的节点1110、1120、1130和1140之间的通信的示例性系统1100。节点1120、1130和1140提供基于网络的服务并且节点1110可以用来促进节点1120、1130和1140的管理。在操作中，节点1120、1130和1140的中间件促进系统1100中的通信和合作。

在一些实施例中，节点1110包括消息传送总线1112、服务注册表1114和控制器1116。消息传送总线1112可以配置成与中间件代理1126、1136和1146通信。控制器1116可以配置成管理与节点1120、1130和1140有关的服务和基础设施。服务注册表1114可以包括与应用1128、1138和1148有关的信息。

在一些实施例中，节点1120、1130和1140可以各自配置成使用应用1128、1138和1148提供一个或多个服务。节点1120、1130和1140可以分别包括管理程序1122、1132和1142，以及分别包括虚拟机1124、1134和1144。这些虚拟机和管理程序可以用来支持应用1128、1138和1148。节点1120、1130和1140还包括中间件代理1126、1136和1146，所述中间件代理1126、1136和1146可以配置成使用相同类型的消息或协议(例如，以上关于图1至图10所论述的消息和协议)来通信。

在一些实施例中，SaaS和PaaS实施可以使用代理(诸如中间件代理1126、1136和1146)。这些代理可以与节点1120、1130和1140中的应用(例如，应用1128、1138和1148)交互。例如，这些代理可以用作中间件并且用来例示合作、教育或游戏应用。云控制器1116可以与节点1120、1130和1140上的那些代理交互，指导它们创建新服务。新创建的应用又可以使用中间件来与控制器1116通信(例如，请求资源)。如另一个实例，应用1128可以具有表格中的某个数量的记录，并且应用1128可以请求创建具有相同的应用类型的新虚拟机。SaaS/PaaS中间件代理1126可以将请求发送到控制器1116，该控制器随后将其传输到IaaS中间件代理1144以创建新虚拟机。一旦安装了新虚拟机，则控制器1116现在可以指导SaaS/PaaS代理1126来安装新应用。一旦应用准备好，则现在可以将以上关于图1至图10论述的协议中的消息用于将专用命令发送到一个或多个应用实例。此中间件技术可以实现应用1128、1138和1148与控制器1116之间的全面通信。

在一些实施例中，可以发布标准库和API以用于与基础设施、控制器和其他应用交互。应用(例如，应用1128、1138和1148)可以使用服务注册表1114来定位应用和向其转发消息。服务注册表1114可以实现服务(例如，由应用1128、1138和1148提供)的逻辑定址，包括超出域名的定址。在一些实施例中，可能不知道域名，或者可以基于服务类型而非携带其的主机名称来进行消息传送。可以使用中间件代理1126、1136和1146以认证的方式来发送多播和广播消息(不知道其MAC或IP)。

图12示出了适用于实施特定实施例的一个或多个部分的示例性计算机系统1200。尽管本公开描述和说明以特定配置具有特定组件的特定的计算机系统1200，但是本公开考虑以任何适合的配置具有任何适合的组件的任何适合的计算机系统。此外，计算机系统1200可以采用任何适合的物理形式，诸如例如一个或多个集成电路(IC)、一个或多个印刷电路板(PCB)、一个或多个手持或其他设备(诸如移动电话或PDA)、一个或多个个人计算机或一个或多个超级计算机。以上关于图1至图11论述的组件(例如，客户节点102、104和106、服务节点132、134、136和138、工作流节点122、124、126、128、128、152、154和156、代理112、114、116、118、142、144和146、一个或多个上述网络以及图3和图5至图11中标识的节点)可以使用以下描述的计算机系统1200的所有组件或组件的任何适当的组合来实施。

计算机系统1200可以具有一个或多个输入设备1202(其可以包括小键盘、键盘、鼠标、触控笔等)、一个或多个输出设备1204(其可以包括一个或多个显示器、一个或多个扬声器、一个或多个打印机等)、一个或多个存储设备1206以及一个或多个存储介质1208。输入设备1202可以在计算机系统1200的外部或内部。输出设备1204可以在计算机系统1200的外部或内部。存储设备1206可以在计算机系统1200的外部或内部。存储介质1208可以在计算机系统1200的外部或内部。

系统总线1210将计算机系统1200的子系统彼此联接。本文，对总线的提及涵盖用于公共功能的一个或多个数字信号线。本公开考虑任何适合的系统总线1210，包括具有任何适合的总线架构的任何适合的总线结构(诸如一个或多个内存总线、一个或多个外围总线、一个或多个局部总线或以上的组合)。示例性总线架构包括但不限于工业标准架构(ISA)总线、增强的ISA(EISA)总线、微通道架构(MCA)总线、视频电子标准协会局部(VLB)总线、外部组件互连(PCI)总线、快速外部组件互连总线(PCI-X)和图形加速端口(AGP)总线。

计算机系统1200包括一个或多个处理器1212(或中央处理单元(CPU))。处理器1212可以含有用于指令、数据或计算机地址的暂时本地存储的缓存1214。处理器1212联接到一个或多个存储设备，包括内存1216。内存1216可以包括随机访问内存(RAM)1218和只读内存(ROM)1220。数据和指令可以在处理器1212与RAM1218之间双向转移。数据和指令可以从ROM 1220单向地转移到处理器1212。RAM 1218和ROM 1220可以包括任何适合的计算机可读存储介质。例如，此段的各方面可以用来实施在图1至图11中论述的所存储信息(例如，在数据包200中)。

计算机系统1200包括双向联接到处理器1212的固定存储器1222。固定存储器1222可以通过存储控制单元1207联接到处理器1212。固定存储器1222可以提供额外的数据存储容量并且可以包括任何适合的计算机可读存储介质。固定存储器1222可以存储操作系统(OS)1224、一个或多个可执行程序(EXEC)1226、一个或多个应用或程序1228、数据1230等。固定存储器1222通常是比主存储器慢的副存储介质(诸如硬盘)。在适当的情况下，固定存储器1222所存储的信息可以作为虚拟内存并入到内存1216中。例如，此段的各方面可以用来实施在图1至图11中论述的所存储信息(例如，在数据包200中)。

处理器1212可以联接到各种接口，诸如像图形控制1232、视频接口1234、输入接口1236、输出接口1237和存储接口1238，所述接口又可以分别联接到适当的设备。示例性输入或输出设备包括但不限于视频显示器、轨迹球、鼠标、键盘、麦克风、触控式显示器、换能器读卡器、磁或纸带读出器、平板电脑、唱针、声音或手写辨识器、生物统计读出器或计算机系统。网络接口1240可以将处理器1212联接到另一个计算机系统或联接到网络1242。网络接口1240可以包括有线、无线或有线与无线组件的任何组合。这些组件可以包括有线网卡、无线网卡、无线电、天线、电缆或任何其他适当的组件。通过网络接口1240，处理器1212可以在执行特定实施例的步骤的过程中从网络1242接收信息或向其发送信息。特定实施例可以仅在处理器1212上执行。特定实施例可以在处理器1212上并且在一起工作的一个或多个远程处理器上执行。

在计算机系统1200连接到网络1242的网络环境中，计算机系统1200可以与连接到网络1242的其他设备通信。计算机系统1200可以通过网络接口1240与网络1242通信。例如，计算机系统1200可以在网络接口1240上从网络1242接收一个或多个进入数据包形式的信息(诸如来自另一个设备的请求或响应)，并且内存1216可以存储进入的数据包以供随后处理。计算机系统1200可以从网络接口1240将信息(诸如向另一个设备的请求或响应)以一个或多个外发数据包的形式发送到网络1242，在所述数据包在被发送之前内存1216可以将其存储。根据特定需要，处理器1212可以访问内存1216中的进入或外发数据包以对其处理。

特定实施例涉及一个或多个计算机存储产品，其包括实施用于执行本文描述或说明的一个或多个过程的一个或多个步骤的软件的一个或多个计算机可读存储介质。在特定实施例中，介质、软件或二者中的一个或多个部分可以被特别设计和制造以执行本文描述或说明的一个或多个过程的一个或多个步骤。此外或作为替代，在特定实施例中，介质、软件或二者中的一个或多个部分可以普遍可用，而无需为本文描述或说明的过程特别设计或制造。示例性计算机可读存储介质包括但不限于CD(诸如CD-ROM)、FPGA、软盘、光盘、硬盘、全息存储介质、IC(诸如ASIC)、磁带、缓存、PLD、RAM设备、ROM设备、半导体存储设备以及其他适合的计算机可读存储介质。在特定实施例中，软件可以是编译器可以产生的机器代码或者含有计算机可以使用解译程序执行的高级代码的一个或多个文件。

如一个实例而非为了限制，内存1216可以包括实施软件的一个或多个计算机可读存储介质，并且由于处理器1212执行软件而使得计算机系统1200可以提供本文描述或说明的特定功能性。内存1216可以存储软件并且处理器1212可以执行软件。内存1216可以通过网络接口1240从实施软件的大型存储设备1216中的计算机可读存储介质或者从一个或多个其他源读取软件。当执行软件时，处理器1212可以执行本文描述或说明的一个或多个过程的一个或多个步骤，所述步骤可以包括根据特定需要定义用于存储在内存1216中的一个或多个数据结构和如由软件的一个或多个部分所指导修改一个或多个数据结构。此外或作为替代，由于逻辑硬接线或以其他方式实施在可以替代软件或者与软件一起操作以执行本文描述或说明的一个或多个过程的一个或多个步骤的电路中，使得计算机系统1200可以提供本文描述或说明的特定功能性。根据特定需要，本公开涵盖硬件与软件的任何适合的组合。

本文，对计算机可读永久存储介质的提及可以包括基于半导体的或其他集成电路(IC)(诸如例如，场可编程门阵列(FPGA)或专用IC(ASIC))、硬盘、HDD、混合硬盘(HHD)、光盘、光盘驱动器(ODD)、磁光盘、磁光驱动器、软盘、软盘驱动器(FDD)、磁带、全息存储介质、固态驱动器(SSD)、RAM驱动器、安全数字卡、安全数字驱动器、其他适合的介质或这些的适合的组合(在适当的情况下)。计算机可读永久存储介质可以是易失性、非易失性或易失性与非易失性的组合(在适当的情况下)。

本文中，除非另有明确指示或者以其他方式由情境指示，否则“或”是包括性而非排他性。因此，本文中，除非另有明确指示或者以其他方式由情境指示，否则“A或B”意味着“A、B或二者”。此外，除非另有明确指示或者以其他方式由情境指示，否则“和”都是共同的和各自的。因此，本文中，除非另有明确指示或者以其他方式由情境指示，否则“A和B”意味着“A和B、共同地或各自地”。

本公开涵盖本领域普通技术人员将领会的对本文的示例性实施例做出的所有改变、替换、变化、更改和修改。此外，随附权利要求中对适配成、布置成、能够、配置成、使能够、可操作或操作以执行特定功能的装置或系统或装置或系统的组件的提及涵盖那个装置、系统、组件，无论其或那个特定功能是否被启动、开启或解锁，只要那个装置、系统或组件被如此适配、布置、能够、配置、使能够、可操作或操作即可。

Claims

1.一种由至少一个处理器执行的方法，包括：

接收从第一客户发送的对由第一服务提供商提供的第一服务的第一请求，所述第一请求是第一类型的；

响应于接收所述第一请求，从与所述第一服务提供商相关的第一策略确定第一组配置参数；以及

响应于接收所述第一请求，使用所述第一组配置参数使得与所述第一服务提供商相关的节点提供所述第一服务。

2.如权利要求1所述的方法，进一步包括：

接收从所述第一客户发送的对第二服务提供商的第二服务的第二请求，所述第二请求是所述第一类型的；

响应于接收所述第二请求，从与所述第二服务提供商相关的第二策略确定第二组配置参数；以及

响应于接收所述第二请求，使用所述第二组配置参数使得与所述第二服务提供商相关的节点提供所述第二服务。

3.如权利要求1所述的方法，进一步包括：

发送多播广告，所述广告是所述第一类型的；

响应于接收所述广告，接收由所述第一服务提供商发送的所述第一类型的单播服务注册；

从第二服务提供商接收所述第一类型的多播发现请求；以及

响应于接收所述多播发现请求，将所述第一类型的单播广告发送到所述第二服务提供商。

4.如权利要求1所述的方法，其中，所述第一请求包括与所述第一服务相关的点分十进制名称。

5.如权利要求1所述的方法，进一步包括：

证明所述第一请求符合与所述第一类型相关的一组规则；以及

通过将所述第一请求与关于所述第一服务的信息相比较来验证所述第一请求。

6.如权利要求1所述的方法，其中，所述第一请求包括：

第一部分，所述第一部分包括与如何实施所述第一服务无关的信息；以及

第二部分，所述第二部分包括与如何实施所述第一服务有关的信息。

7.如权利要求6所述的方法，其中：

所述第一部分是纯文本格式；以及

所述第二部分是可扩展标记语言(XML)格式。

8.一种包括指令的永久计算机可读介质，所述指令在由至少一个处理器执行时被配置成：

9.如权利要求8所述的介质，其中，所述指令被进一步配置成：

10.如权利要求8所述的介质，其中，所述指令被进一步配置成：

发送多播广告，所述广告是所述第一类型的；

从第二服务提供商接收所述第一类型的多播发现请求；以及

11.如权利要求1所述的介质，其中，所述第一请求包括与所述第一服务相关的点分十进制名称。

12.如权利要求8所述的介质，其中，所述指令被进一步配置成：

13.如权利要求8所述的介质，其中，所述第一请求包括：

14.如权利要求13所述的介质，其中：

所述第一部分是纯文本格式；以及

所述第二部分是可扩展标记语言(XML)格式。

15.一种系统，包括：

接口，配置成接收从第一客户发送的对由第一服务提供商提供的第一服务的第一请求，所述第一请求是第一类型的；以及

至少一个处理器，配置成：

16.如权利要求15所述的系统，其中：

所述接口进一步配置成接收从所述第一客户发送的对第二服务提供商的第二服务的第二请求，所述第二请求是所述第一类型的；以及

所述至少一个处理器被进一步配置成：

17.如权利要求15所述的系统，其中，所述接口被进一步配置成：

发送多播广告，所述广告是所述第一类型的；

从第二服务提供商接收所述第一类型的多播发现请求；以及

18.如权利要求15所述的系统，其中，所述第一请求包括与所述第一服务相关的点分十进制名称。

19.如权利要求15所述的系统，其中，所述至少一个处理器被进一步配置成：

20.如权利要求15所述的系统，其中，所述第一请求包括：

21.如权利要求20所述的系统，其中：

所述第一部分是纯文本格式；以及

所述第二部分是可扩展标记语言(XML)格式。