CN105474171A - 用于计算域中智能自动化的基于模型的方法 - Google Patents

Abstract

示例中提供了方法，并且该方法包括将两个或多个对象添加至模型，接收在两个或多个对象的第一对象和第二对象之间建立关系的请求，以及确定关系是否违反设计策略。该方法还包括基于关系是否违反设计策略采取动作。该方法的更具体的实施例包括从以确定的顺序执行的一组进程中选择进程，其中该一组进程以确定的顺序的成功执行配设两个或多个对象，从而在目标中建立模型。该更具体的实施例还包括确定所选择的进程是否违反部署策略，以及基于所选择的进程是否违反部署策略采取动作。

Description

用于计算域中智能自动化的基于模型的方法

技术领域

本公开一般地涉及计算机系统和服务的领域，并且更具体地涉及提供用于计算域中智能自动化的基于模型的方法。

背景技术

随着计算机系统和服务已经变得越来越复杂，计算、存储、网络、和处理能力的需求也随之增加。例如，企业的网络基础设施通常包括大量的网络元件，该网络元件包括主机、服务器、路由器、交换机、负载均衡器、和安全设备等的任意合适的组合。已经出现许多不同的计算域(用于单复数参考时分别称为“域”和“多个域”)来适应与企业、服务提供者、和其他实体的复杂计算机系统和服务相关的日益增长的需求。一般地，计算域是一组可以使用相同的协议或规则来访问和管理的一个或多个相关的计算机系统。在虚拟的云环境中配置的数据中心是通常由服务提供者用来托管多个企业并且向这些企业提供期望的资源的一个域。其中的硬件和服务由特定的企业来控制和使用的专用网络基础设施是域的另一个示例。此外，域可以包括任意数量的资源，包括诸如服务器之类的单一资源。其他域可以具有数百、数千或甚至更多的资源。

智能自动化技术通常使用进程驱动的方法来定义分级工作流进程或活动，从而在具体的域中实现实体的期望目标。随着期望目标的复杂度的增加和用户案例的激增，可能发生进程膨胀并且使进程的管理显著的复杂化。因此，企业、服务提供者、和其他实体需要用于期望目标的配置和管理解决方案的更好的方法。

附图说明

为了提供对本公开和其特征和优点的更完整的理解，结合附图参照下面的描述，其中相似的编号表示相似的部分，其中：

图1是示出根据本公开的至少一个实施例的提供用于计算域中智能自动化的基于模型的方法的系统的高级架构的简化框图；

图2是与智能自动化系统的至少一个实施例相关联的可能的示例细节的简化框图；

图3是示出根据至少一个实施例的与表达期望的状态相关联的部件的另一个简化框图；

图4是根据至少一个实施例的与智能自动化系统的示例控制面板相关联的屏幕截图的简化图；

图5是示出根据至少一个实施例的与创建服务元件相关联的潜在操作的简化流程图；

图6是根据至少一个实施例的与示例服务元件相关联的屏幕截图的简化图；

图7是示出根据至少一个实施例的与创建进程相关联的潜在操作的简化流程图；

图8是根据至少一个实施例的与示例进程相关联的屏幕截图的简化图；

图9A和9B是示出根据至少一个实施例的与组成模型相关联的潜在操作的简化流程图；

图10是根据至少一个实施例的与示例模型相关联的屏幕截图的简化图；

图11是示出根据至少一个实施例的与将模型部署至目标相关联的潜在操作的简化流程图；

图12是示出根据至少一个实施例的与监测模型实例相关联的潜在操作的简化流程图；以及

图13A和13B是示出根据至少一个实施例的与修改模型相关联的潜在操作的简化流程图。

具体实施方式

概述

在至少一个实施例中提供了针对用于计算域中智能自动化的基于模型的方法的方法。方法包括将两个或多个对象添加至模型并且接收在两个或多个对象的第一对象与第二对象之间建立关系的请求。方法还包括确定该关系是否违反设计策略并且基于该关系是否违反设计策略来采取动作。

在一些具体的实施例中，对象包括一个或多个子模型。在一些其他具体的实施例中，对象包括一个或多个服务元件。在其他具体的实施例中，对象包括至少一个子模型和至少一个服务元件。在另外具体的实施例中，如果所请求的关系没有违反第一对象或第二对象的任何设计策略，则方法包括在第一对象与第二对象之间建立所请求的关系。在一些实施例中，方法包括从以确定的顺序执行的一组进程中选择一个进程。以确定的顺序的成功执行该组进程规定了两个或多个对象在目标中建立模型实例。该具体的实施例还可以包括确定所选择的进程是否违反部署策略并且基于所选择的进程是否违反部署策略来采取动作。

示例实施例

转向图1，图1是示出了智能自动化系统100的高级架构的简化框图，该智能自动化系统100提供了用于计算域中智能自动化的基于模型的方法。一般地，智能自动化系统100包括内容阶段120、部署阶段130、和域阶段150。内容阶段120中的自动化包122包括一个或多个模型124、进程126、和策略128。模型124包括一个或多个对象(即，服务元件和/或子模型)和可以在对象之间被创建的关系。一个或多个进程126可以在服务元件级和/或模型级被应用。策略124可以包括设计策略、部署策略和运行时间策略。这些策略可以被应用于模型、服务元件和进程126。在部署阶段130期间，至目标140的一个或多个模型124的配设132可以被执行。域阶段150包括配设的模型124的一个或多个模型实例152(1)、152(2)、至152(N)。违反应用于模型、服务元件或进程的策略的事件可以由策略管理器160来评估和管理。有可能在任意阶段违反策略，例如，当模型在内容阶段120被创建时、当模型在部署阶段130正在被配设时、或当模型在域阶段150中正在目标140中运行时。

根据本公开中的实施例，智能自动化系统100可以提供用于特定域中智能自动化的基于模型的方法。本文所公开的至少一个实施例可以被应用于多个域(例如，企业、私有云、服务一个或多个租户的服务提供者等等)。基于模型的方法可以提供最终目标与实现目标所采取的动作的明确分离。智能自动化系统100的实施例可以使得声明性规范的创建能够通过相关的对象的集合来指定数据中将要发生什么并且定义服务的期望状态或其他解决方案。如本文所使用的，术语“对象”旨在包括服务元件或子模型，并且术语“对象”旨在包括服务元件、子模型或它们的任意合适的组合，除非特别注明。此外如本文所使用的，“子模型”包括用来组成更高级模型的至少一个模型，该更高级模型也可以被称为“组合模型”。

包括组合模型和非组合模型两者的模型可以由用户来定义，并且可以驱动自动化，从而通过将复杂顶级服务分解为比服务的元件级对象更精细的动作来实现最终目标。通过模型的组成(本文也称为“服务模型”)，复杂关系既可以通过自上而下又可以通过自下而上来指定。在自下而上的方法中，用户可以从低级开始来定义诸如服务元件(例如，CentosLinux虚拟机(VM)，ApacheWeb服务器)之类的对象和它们之间的关系。然后用户可以基于所定义的服务元件定义更高级服务，从而实现期望的最终目标。替代地，对于自上而下的方法，用户可以通过组成可重复使用的服务组件(例如，服务模型、服务元件、策略、进程等等)来定义高级服务。嵌套服务模型允许自动化，从而通过规定的执行顺序来遍历关系，并基于服务组合来实现最终目标，最后建立整个复杂服务模型。

为了说明智能自动化系统100的示例技术，理解在系统100中可能发生的通信是重要的。下列基本信息可以被视为本公开可以被适当地解释的基础。

智能自动化技术通常使用进程驱动的方法来定义一组复杂分级工作流进程或活动，该复杂分级工作流进程或活动互相调用并且传递数据参数，从而实现企业或其他实体的期望目标。在这种方法中，工作流活动的中间步骤被明确地定义。例如，进程驱动的方法可以被用来定义云域中的解决方案，例如，创建云基础设施或虚拟数据中心。在这种情况下，工作流进程通常由用户来定义，从而创建虚拟数据中心(例如，防火墙、web服务器、数据库等等)的期望元件中的每一个元件(包括虚拟数字中心本身)。用特定的解决方案涵盖所有的用例可能导致进程膨胀。此外，当自动化的复杂度增加时，进程驱动的方法可能变得难以开发和管理，因为实现方式与所期望的最终状态没有明确分离。

一些智能自动化方法旨在利用基于模型的方法。然而，总的来说，这些方法针对具体的域被提供。此外，这些方法可能依赖于针对配置是特定的和静态的模板。例如，一些云服务可以由客户能够订购的元素组件的集合组成。其他基于模型的工具可以提供平面级建模，其中用户可以组合多层组件，例如防火墙层、web服务器层、计算层、数据库层等等。策略还可以被添加至这些组件。但是，这样的工具通常要求用户定义实现期望层所需的物理分层。例如，如果诸如虚拟服务器之类的应用级组件被定义，则用户可能需要定义诸如网络地址、防火墙端口等等之类的物理基础设施来支持该应用。

此外，当前基于模型的方法一般地使用一次性“即发即弃(fireandforget)”的技术，该技术检测模型并且创建模型实例而不进一步涉及部署的模型。然而，在许多情况下，模型实例在部署之后可能需要修改，例如，为了满足业务需求，正在被提供的服务可以不断地(或至少周期性地)变化。

需要与计算机系统和/或服务相关的特定的目标(由企业或其他实体期望的)的意图或要求来在任意域中合适地配置并且管理解决方案。所需要的是更好的方式来捕获正在被建立的解决方案的最终目标的意图并且避免可能发生的进程膨胀。更具体地，随着复杂度的增加，需要描述智能自动化系统做了什么来实现目标的能力(而不是定义具体的解决方案是如何实现的)来管理和开发自动化解决方案。此外，在整个生命周期(例如，设计、部署、和实例化)期间有效地管理解决方案相比于当前方法可以提供显著的优势。

根据一个示例实现方式，智能自动化系统100可以解决上述提到的与智能自动化相关联的问题。智能自动化系统100提供基于模型的方法，该方法使得用户能够表达与计算机系统和/或服务相关的期望目标的意图。用户被提供具有定义自动化的声明性规范的能力，这意味着要描述自动化做了什么来实现目标的而不是描述它是如何实现的(即，描述了“做了什么”而不是“如何做”)。本文公开的实施例的基于模型的方法缓解了进程驱动的方法的问题，例如定义目标的所有可能的用例并且经历进程膨胀。相反，系统100的基于模型的方法提供简化的迭代开发过程。用户可以通过设计由解决方案所要求的内容开始，而不需要知道解决方案在目标中被如何部署，该目标可以是物理数据中心或虚拟数据中心。具体的，用户可以创建服务元件、可以设计模型、并且可以定义应用于服务元件和/或模型的进程。可以通过添加对象(即，服务元件和/或子模型)并且定义对象之间的关系来设计模型。此外，策略可以在服务元件级、进程级和/或模型级(包括子模型)被应用。部署弹性允许用户对不同的环境重新部署相同的解决方案。用户还可以修改相同的解决方案并且针对要求和/或版本演变重新部署它。因此，基于模型的方法将自动化的能力从一次性“即发即弃”扩展为全寿命周期管理。

转向图2，图2是示出与智能自动化系统100相关联的可能的一组细节的简化的框图。服务器210(1)和210(2)可以通过网络205进行通信。服务器210(1)托管设计引擎220，并且服务器210(2)托管部署引擎230。服务器210(2)的部署引擎230通过网络275与目标240进行通信。用户系统215(1)和215(2)可以分别使能用户与服务器210(1)和210(2)之间的通信。在至少一个实施例中，设计引擎220可以访问各种内容(或数据)，包括来自服务元件数据库212、模型数据库214、进程数据库216和策略数据库218的数据。部署引擎230也可以访问至少一些的这种内容。设计引擎220的至少一个实施例可以包括元件编辑器模块221、策略编辑器模块222、模型编辑器模块223、进程编辑器模块224、和策略管理器模块225。部署引擎230可以包括配设模块231、监测模块232、重新部署模块233、和策略管理器模块235。服务器210(1)和210(2)还可以包括各自的处理器227和237和各自的存储器元件228和238。在讨论与图1-2的架构相关联的潜在的流之前，提供了关于可能被包括在智能自动化系统100内的一些可能的基础设施的简短的讨论。

网络205与275表示用于接收和发送通过智能自动化系统100传播的网络流量的相互连接的通信路径的一系列的点或节点。网络205和275提供了节点之间的通信接口，并且可以是任意局域网(LAN)、无线局域网(WLAN)、城域网(MAN)、内联网、外联网、广域网(WAN)(例如，因特网)、虚拟专用网(VPN)、在网络环境中促进通信的任意其他合适的架构或系统、或它们的任意合适的组合。网络205和275可以实现使用诸如开放系统互连(OSI)模型、或它们的任意派生或变型之类的多层方案的通信消息协议(例如，传输控制协议/网际协议(TCP/IP)，用户数据报协议/IP(UDP/IP))。然而，网络205和275可以替代地实现用于在智能自动化系统100内发送和接收网络流量的任意其他合适的通信协议。

智能自动化系统100内发送和接收的网络流量包括分组、帧、信号、数据等等。并且，本文所使用的术语“数据”指任意类型的二进制、数值、语音、视频、文本、媒体、或脚本数据、或任意类型的源代码或目标代码、或可以在电子设备和/或网络中以任意合适的格式从一个点被通信到另一个点的任意其他合适的信息。此外，消息、请求、响应、查询、和输入是网络流量的形式，并且因此，网络流量的形式可以包括分组、帧、信号、数据等等。

在示例实现方式中，智能自动化系统100可以由服务提供者来部署，通过访问设计引擎被提供给客户(例如，网络设计者、云架构师等等)。在另一个示例实现方式中，设计引擎220可以在接近于客户的网络设计者的域中被托管，并且部署引擎230可以在接近于分发点(POD)的域中被托管，从而使得网络延迟最小化。在另一个示例中，设计引擎220和部署引擎230均可以在接近于POD的相同服务器中或在物理上接近的服务器中被托管。在另一个示例实现方式中，设计引擎220和部署引擎230可以由企业在它们自己的数据中心中进行部署(在相同服务器或分开的服务器中)。

设计引擎220和部署引擎230的用户是希望在智能自动化系统100中通过一些网络发起通信的用户。设计引擎220可以与针对企业以模型的形式设计网络解决方案的最终用户相关联。部署引擎230可以与配设由设计引擎提供的模型的最终用户相关联。例如，设计引擎220的最终用户可以潜在地是特定企业的信息技术(IT)管理员，并且部署引擎的最终用户可以是服务提供者的网络运营商。在另一个示例中，设计引擎220的最终用户和部署引擎230的最终用户可以与相同企业相关联，并且可以设计、配设、和管理企业的私有数据中心。上述这些与智能自动化系统100相关联的部署和用户仅仅是可能的实现方式的说明，并且不旨在进行限制，因为根据本公开各种实体的任意数量的潜在部署和用户可以与智能自动化系统100相关联。

托管设计引擎220和部署引擎230的服务器210(1)和服务器210(2)分别是有利于智能自动化系统100的智能自动化的基于模型的方法的网络元件。如本文所使用的，术语“网络元件”意味着包括服务器、路由器、交换机、网关、网桥、负载均衡器、防火墙、代理服务器、处理器、模块、或任意其他合适的设备、组分、元件、专用装置、或可操作以在网络环境中交互数据的对象。服务器210(1)和服务器210(2)可以包括促进其操作的任意合适的硬件、软件、组分、模块、接口、或促进其操作的对象。这可以包括允许数据或信息的有效交换的合适的算法和通信协议。服务器210(1)和服务器210(2)在某些实现方式中(例如，当设计引擎220物理上接近于客户时并且当部署引擎230物理上接近于诸如服务提供者的数据中心之类的分发点时)可以是分开的设备。在其他实现方式中，设计引擎220和部署引擎230可以在单一服务器上共同放置(例如，当智能自动化系统100在企业的私有数据中心中被实现时)。服务器210(1)和服务器210(2)还可以是试图代表诸如程序、数据库、或任意其他组分、设备、元件、或能够在智能自动化系统100内发起交换的对象之类的另一个实体或元件发起通信的任意设备。

在至少一个实施例中，服务器210(1)和服务器210(2)包括用于实现(或推动)智能自动化的基于模型的方法的软件，如本文所概述的。注意的是在一个示例中，服务器210(1)和服务器210(2)可以各自具有内部结构(例如，处理器227和处理器237、存储器元件228和存储器元件238等等)以促进本文所描述的一些操作。在其他实施例中，这些智能自动化功能可以在这些元件外部被执行或被包括在一些其他网络元件中来实现该预期的功能。可替代地，服务器210(1)和服务器210(2)可以包括能够与其他网络元件协作的这种软件(或往复软件)以便实现操作，如本文所概述的。在其他实施例中，一个或若干设备可以包括任意合适的算法、硬件、软件、组分、模块、接口、或促进其操作的对象。

用户系统215(1)和用户系统215(2)可以包括被配置为使能用户与服务器210(1)和服务器210(2)之间的用户输入和通信的任意计算机。用户系统215(1)和用户系统215(2)可以包括到人类用户的合适的接口，例如显示器、键盘、鼠标、触摸板、遥控器、或被配置为促进来自和去往用户的信息的通信的其他终端设备。用户系统215(1)和用户系统215(2)可以包括，例如，个人电脑，笔记本电脑，用户工作站，终端站，平板电脑，移动设备等等。

各种数据可以被存储在服务器210(1)和服务器210(2)内部的或外部的(全部或部分的)数据库或任意其他合适的存储结构中。包括至少一些在智能自动化系统中使用的数据的存储结构由图2中的服务元件数据库212、模型数据库214、进程数据库216、和策略数据库218来表示。内部存储装置可以包括服务器210(1)和服务器210(2)的任意内部存储装置，例如，静态存储器、随机存取存储器(RAM)、或高速缓存等。外部存储装置可以包括网络存储技术，例如，网络附加存储(NAS)或存储区域网络(SAN)、或另一网络元件的内部存储器等。

服务器210(1)的设计引擎220向用户提供了在不知道内容最终是如何由部署引擎230部署的情况下设计内容的能力。通过设计引擎220，用户(例如，云架构师)可以创建服务元件、进程、和策略，并且可以使用这些可重复使用的服务组件来组成定义了期望的服务的模型。在一些实例中，模型可以被用作子模型，与一个或多个其他可重复使用的服务组件一起组成组合模型。在至少一个实施例中，用户可以通过与服务器210(1)(远程地或本地地)进行通信的用户系统的显示器上的图形用户界面(GUI)来执行这些内容设计活动中的一个或多个。在至少一个实施例中，这些内容设计活动可以(至少部分地)通过元件编辑器模块221、策略编辑器模块222、模型编辑器模块223、进程编辑器模块224、和/或策略管理器模块225来促进。与内容设计活动相关的信息可以被适当地呈现、或被发送至特定位置(例如，部署引擎230等等)、被存储或归档(例如，服务元件数据库212、模型数据库214、进程数据库216和策略数据库218等等)、和/或(例如，通过用户系统215(1)的显示器上的用户界面)以任意合适的格式被适当地显示。服务元件数据库212、模型数据库214、进程数据库216和策略数据库218可以包括与内容设计活动相关的信息，并且这些元件可以容易地与设计引擎220的模块和组件合作、协作、或交互。

服务器210(2)的部署引擎230向用户提供了将服务模型部署至所选择的目标(例如，虚拟数据中心)的能力。通过部署引擎230，用户(例如，网络运营商)可以选择服务模型的目标，并且该服务模型可以被配设至目标的一个或多个端点上的模型实例中。此外，模型实例可以被监测，并且当某些策略被违反时，在一些情况下可以采取补救动作，并且模型可以全部或部分地被重新部署，而不修改模型本身。在其他情况下，模型可以被修改和被重新部署。在至少一个实施例中，用户可以通过与服务器210(2)(远程地或本地地)继续拧通信的用户系统的显示器上的图形用户界面(GUI)来执行一个或多个部署活动。在至少一个实施例中，部署活动可以(至少部分地)通过配设模块231、监测模块232、重新部署模块233、和/或策略管理器模块235来促进。与部署活动相关的信息可以被适当地呈现、或被发送至特定位置(例如，设计引擎220、目标240的端点等等)、被存储或归档、和/或例如，通过用户系统215(2)的显示器上的用户界面)以任意合适的格式被适当地显示(。服务元件数据库212、模型数据库214、进程数据库216和策略数据库218可以包括与部署活动相关的信息，并且这些元件可以容易地与部署引擎230的模块和组件合作、协作、或交互。

转向图3，图3示出了智能自动化系统100中使用的组件，从而表达服务、动作、和部署的期望的状态。组分可以包括关系302、模型和服务元件304、事件306、策略308、模型动作310、和目标312。一般地，关系302可以将服务元件互相联系起来、将子模型(即，更高级服务模型内的模型)互相联系起来、以及将服务元件与子模型联系起来。模型和服务元件304可以与策略308(例如，与服务元件相关联的元件级策略、与模型相关联的模型级策略)和模型动作310相关联。模型和服务元件304可以在组成、部署、和/或运行期间引发(或生成)事件306。事件306是可以基于条件来评估的事件。基于条件评估的结果，事件可以触发策略308。当策略被触发时(即，条件被满足)，一个或多个模型动作310可以被触发。模型动作310和策略308可以调用目标312，其中模型已经被部署。

现在参照前述图1-3，图3中显示的组件将进一步更详细地被描述。服务元件是可以单独或组合地被用来创建模型的元件级对象。服务元件是解决方案的更低级的实体或叶实体，并且可以包括计算元件、存储元件、和网络元件。服务元件的特定示例包括但不限于应用元件、安全元件、和数据库元件。服务元件可以用强类型来定义(例如，Centos-Linux虚拟机、Apacheweb服务器等等)。服务元件还可以包括描述服务元件的配置的属性。例如，Apacheweb服务器的属性可以包括当服务器被部署至网络的数据中心时的IP地址、web服务器的名称、和到Apacheweb服务器将要使用的具体数据库的连接。在另一个示例中，数据库的属性可以包括数据库名称、数据内容名称、主机、数据库类型、和连接。服务元件的属性可以是用户指定的值、默认值、自动生成的值、或它们的任意合适的组合。在至少一个实施例中，服务元件可以被存储在服务元件数据库212中，并且服务元件的创建和修改可以(至少部分地)通过元件编辑器模块221来促进。

模型是声明性规范，该声明性规范根据用于实现服务或其他解决方案的期望的状态和元件级对象的关系描述了自动化目的。一些模型可以在更高级被组合，并且可以描述子模型、服务元件、或它们的任意组合的关系。服务是解决方案的一个示例。在至少一个实施例中，模型可以由用户来组合，并且可以被存储在模型数据库214中。模型的组合和修改可以(至少部分地)通过模型编辑器模块223来促进。通过模型，用户可以指定他想要在数据中发生的什么，并且通过相关的对象(即，服务元件、子模型)的集合来定义服务的期望的状态。模型描述了服务(或其他解决方案)的整体/高级计划，其驱动自动化通过将复杂顶级服务分解为比服务的元件级对象更精细的动作来实现最终目标。例如，用来规定用于假日购物的虚拟应用(vApp)的模型可以由Apacheweb服务器来完成，该Apacheweb服务器使用XYZ数据库，它们两者都可以在CentosLinux虚拟机(VM)上被托管。基于模型的方法使得用户能够集中精力为服务的每一元件级对象(例如，Apacheweb服务器、XYZ数据库、CentosLinuxVM)定义拓扑、关系、和数据，而不需要知道服务是如何创建的。

模型提供了用于定义服务或其他解决方案的统一的抽象概念。模型可以包括对象的集合，对象彼此之间具有关系，从而促进具体的服务。因此，在一个示例中，模型可以是多个服务元件的组合和这些服务元件之间的关系。在另一个示例中，模型可以是多个子模型的组合和这些子模型之间的关系。在另一个示例中，模型可以是一个或多个子模型与一个或多个服务元件的组合和这些对象之间的关系。模型可以用模型级上的强类型来定义，其可以在设计时被指定(例如，vApp-Apache-XYZ、VDC-san-jose等等)。用户可以通过创建模型的期望的服务元件和/或子模型或通过使用已经定义好的现有服务元件和/或子模型来设计(或组合)模型。模型可以具有一个或多个属性，该属性可以是用户指定的值、默认值、自动生成的值、或它们的任意合适的组合。

模型的服务可以针对各种目的被创建，并且模型可以应用于不同域或单一域。具有特定目的的模型的示例包括但不限于资源模型、性能模型、和组织模型。包括资源模型(或子模型)的服务元件可以是资源导向的。这些服务元件可以形成一组相互依存的资源(例如，Apacheweb服务器使用XYZ数据库或诸如IP地址池之类的池式资源)。资源模型通常被授权用来定义服务的组合，包括但不限于计算服务、网络服务、存储服务、和应用服务。

在性能模型(或子模型)中，服务元件可以是规格导向的。性能模型可以捕获关键绩效指标(KPI)、KPI之间的关系、和用于计算KPI的公式和数据/事件。性能模型通常被授权用来定义健康监测，从而跟踪CPU利用率的时间周期(例如，高和低)和大部分CPU资源的服务的成本。

组织模型(或子模型)可以包括实体导向的服务元件。组织模型可以捕获组织的结构(例如，服务提供者具有多个租户、每一租户具有子租户，并且每一租户具有多个部门和相关联的成员)。工作组或角色(例如，操作者、管理者等等)可以针对每一用户来定义，从而控制访问。例如，基于角色的访问控制(RBAC)可以被用来限制系统访问租户到授权的用户之内的某些资源。

模型组合向用户提供了用自上而下的方法或自下而上的方法创建可重复使用的服务的能力。在至少一个实施例中，这些可重复使用的服务可以由用户通过(例如，用户系统215(1)的)一个或多个用户界面来组合。在自下而上的方法中，更低级对象(例如，服务元件)首先被组合。对象可以具有到其他对象关系，该关系使得服务模型的组合能够统一相关的服务元件的集合，从而定义一个或多个服务。关系可以由用户来指定。模型可以被组合，如同子模型创建更高级模型。在自上而下的方法中，更高级服务(例如，客户关系管理(CRM)服务)首先被组合。其他模型可以被包括，如同子模型在更高级服务之内。因此，当创建更大模型时，其他模型可以被重复使用作为库组件。在至少一个实施例中，模型组合可以是高度结构化和分级化的。

对象之间(例如，模型的服务元件之间、更高级模型的子模型之间、子模型与更高级模型的服务元件之间等等)的关系可以被预先定义(例如，使用、被托管、被部署等等)或由用户定制(例如，被采用、触发等等)。关系具有捕获两个对象之间的关系的元数据的属性。基数也可以被指定和管理(例如，1对1、1对多、多对多等等)。

模型组合也支持继承。基础抽象类型的服务元件(例如web服务器)，可以被更明确的具体类型服务元件继承，如具有附加属性和动作的Apacheweb服务器。具体类型可以完全存取它父本(抽象类型)的属性和动作。继承支持不仅提供了可重复使用性，而且创建了标准化。标准属性、策略、和/或动作可以在基础抽象类型中被定义，所有其他扩展的类型从该基础抽象类型继承。可能以这种方式被标准化的属性、策略、和/或动作的示例包括但不限于唯一的标准名称(例如，信息技术基础设施库(ITIL)名称)、显示名称、版本、说明、工作流程动作(例如，创建、读取、更新、和删除(CRUD))、验证、和基于角色的访问控制(RBAC)策略。

模型驱动模型动作来实现自动化的最终目标。模型动作可以以模型级和服务元件级两者被执行。通常，在智能自动化中，模型动作由针对服务模型定义可能的编排动作的工作流进程(在本文中也被简称为‘进程’)来实现。进程可以接受的模型定义和/或服务元件定义(或类型)可以被约束，从而定义哪一进程可以针对它动作。更具体地，作为进程创建的一部分，每一个进程被指定具有由进程接受的一组模型类型，并且进程被设计为处理指定的该组模型类型。

在至少一个实施例中，与服务元件相关联的进程(在本文中也被称为‘元件级进程’)和/或与模型和子模型相关联的进程(在本文中也被称为‘模型级进程’)可以被存储在进程数据库216中。进程创建和修改可以(至少部分地)由进程编辑器模块224来促进。元件级进程可以包括在服务元件上做基础工作的进程，例如初始化、创建、删除、启动、停止、暂停、重启、关闭、配置、清理、更新、撤销/恢复等等。这些元件级进程中的至少一些本质上在模型中被提供以支持完整的寿命周期。根据智能自动化系统100的实施例创建的模型可以维持模型动作的整个寿命周期的快照，而不是作为‘即发即忘’系统运行。当故障出现在动作的中间并且期望回滚到先前快照时，这对于恢复动作可能特别有利。

模型级进程可以包括取决于特定进程的可以在模型的部署之前或期间被执行的高级操作。模型级进程还可以被配置为编排模型之内的相关联的模型或子模型的元件级进程。在一些实例中，模型或子模型可能不具有相关联的模型级进程。例如，如果模型或子模型是若干服务元件的简单实现，其中仅需要简单的低级进程(例如，启动、更新、关闭)，则模型级进程可以是不必要的。

模型的部署包括在目标中配设模型。当模型正在被配设时，部署引擎230可以自动地遍历进程正在运行的更高级服务模型与更低级服务元件之间的关系。考虑vApp-Apache-XYZ模型，该vApp-Apache-XYZ模型包括‘使用’XYZ数据库服务元件的Apacheweb服务器服务元件，其中这两个服务元件在CentosLinuxVM服务元件上‘被托管’。在这个示例中，‘使用’和‘被托管’是服务元件之间创建的关系。这些关系定义了服务模型的拓扑，自动化旨在实现该拓扑。元数据属性可以与每一个关系相关联，并且定义一组已知的依赖关系。部署引擎230可以遍历关系，并且试探性地导出执行的顺序(例如，配设CentosVM，然后XYZ数据库，和最后Apacheweb服务器)。然而，这个自动排序可以被自定义工作流进程(例如，遵循某些行业最佳实践的模型级进程)覆盖。例如，在示例情景中，可能期望首先配设Apacheweb服务器，然后配设XYZ数据库，或启动具有特定性能参数的XYZ数据库。

部署模型的实际工作在叶实体(例如，服务元件)处被定义。然而，由于模型在更高级处被定义，更少的元件进程可能需要在更低级处被定义。在一些实例中，创建模型的用户可能没有在叶实体(即，最低级)处定义任何进程。在这些情况下，用户可以不关心被用来实现模型的特定服务元件。

在其他情况下，其中用户要求用于解决方案的特定服务元件，用户可以首先定义服务元件(例如，web服务器)。定义服务元件之后，用户可以指定服务元件的属性。然后，用户可以定义服务元件的进程。要被创建的典型的进程包括服务元件的创建、更新、和关闭进程。例如，用户然后可以创建包括web服务器和数据库的模型。数据库服务元件可以具有它自己的进程(例如，创建、更新、和关闭)。当用户创建了服务元件之间的关系时，模型被创建。

如果在部署数据库服务器和web服务器之前要求任何特殊的事项，则高级进程可以被创建来运行模型。高级进程的示例可以是在模型被部署之前评估虚拟数据中心以确定数据中心是否具有足够的资源来容纳特定的模型。这个高级进程可以在模型级被创建。然而，如果仅需要基础处理(例如，启动、关闭、和更新)，则用户可以创建不具有任何模型级进程的模型。

在一些情景中，在部署期间，模型级进程可以先被执行。模型级进程可以编排不同服务元件进程。然而，如果模型级进程不存在，则部署引擎230可以基于模型中定义的关系来确定执行服务元件进程中的哪些和执行的顺序。

这个智能自动化的基于模型的方法提供了(‘哪些’)内容与(‘如何’)部署的明确分离。它使能一个从设计由期望的目标要求的内容开始而不需要知道特定解决方案在最终如何被部署的迭代开发过程。根据至少一个实施例，智能自动化系统100的部署弹性使得相同解决方案能够重新部署至不同环境(例如，针对工作负载分配，将私人虚拟数据中心(VDC)解决方案重新部署至云计算服务提供者)。此外，针对要求和/或版本演进，解决方案可以被修改和重新部署。因此，智能自动化系统100被配置为动态地支持新解决方案，例如，当策略改变时或当模型或服务元件的新版本被要求时(例如，基于业务需求等等)。

模型与它如何被部署之间的连接或合同可以通过早期绑定或后期绑定被指定。用户可以指定模型将被部署在其上的某些部署目标(例如，针对早期绑定在设计期间指定虚拟数据中心(vCenter))。然而，针对早期绑定指定的目标可以在部署期间被覆盖，只要它们被验证是相同类型并且是授权(如果有的话)。此外，如果针对早期绑定在设计期间没有目标被指定，则目标可以在部署期间针对后期绑定被指定。绑定连接可以指定用于部署的目标的类型、调用目标所要求的参数、用户身份等等。模型的特定自动化需求可以指示在设计期间是否提供早期绑定或在部署期间是否提供后期绑定。例如，后期绑定可以与维持工作负载平衡的部署目标更相关。在这个情景中，决定在部署期间动态地被导出以选择具有最佳容量水平的部署目标。

智能自动化系统100提供了使得策略关注能够从自动化逻辑分离的策略管理。当策略表示为具体方面或横切关注时，策略管理可以简化设计、部署和运行时。例如，验证策略可以表示为具体方面(例如，vApp-Apache-XYZ模型的Apacheweb服务器需要是2.x或较新的要求)。在另一个示例中，当存储器利用率超过90％时，横切策略可以被表示为要求停止所有自动化动作作为横切关注。一些策略可以被配置为一组指南来完成服务。例如，容量的范围(例如，4GB到16GMRAM)、或金/银/青铜分类(例如，分类确定其中模型被部署的一组特定服务器)可以用服务模型来指定。在第一示例中，如果容量在由策略定义的范围之内被获取，服务请求可以被实现。在第二示例中，服务请求可以通过将模型部署至由选择的分类所允许的网络元件来实现。

在至少一个实施例中，策略可以由用户来创建，并且被存储在策略数据库218中。策略的创建和修改可以(至少部分地)由策略编辑器模块222来促进。策略管理可以包括对服务元件、模型(和子模型)、和进程的策略的应用；对确定违规是否发生的策略的评估；以及响应于策略违规的策略动作的发起。智能自动化系统100的策略管理的至少一些方面可以由设计引擎220的策略管理器模块225和部署引擎230的策略管理器模块235来提供。

策略可以包括管理与模型、服务元件、和/或模型实例相关的一组动作的规则。策略可以被归类成特定兴趣的策略集，并且可以或不可以被嵌套。策略或策略集可以在条件或复合条件下与一个或多个模型和服务元件相关联。当(一个或多个)条件为真时，策略被触发，其转而发起策略动作。策略动作的唯一性使得策略的业务扩展能够完全处于进程之外，因为它们是可以分开被管理的不同的关注。策略动作可以包括但不限于启动进程、调用活动(例如，发送电子邮件、发送文本消息、创建报警等等)、关联事件、执行脚本、和发动新事件。

策略或策略集可以与使能横切关注的表达的事件相关联。事件可以来自各种来源。当事件发生时，针对事件进行条件评估。如果条件评估为真，则相应的策略被触发。不同类型的事件可以来自各种来源，并且可以包括但不限于通过适配器的外部事件(例如，简单网络管理协议(SNMP)陷阱、vCenter事件等等)、模型事件、服务模型的寿命周期事件(例如，创建、重新配置、删除、重启等等)、和调度程序事件(例如，基于时间的触发器等等)。

事件还可以用作自动化扩展性的重要构建块。通过事件，横切和模型特定关注可以被解决。例如，当低容量事件被唤起时，扩展自动化可以被触发。即使在自动化进程期间，基于被唤起的不同事件(例如，通过验证)，自动化可以采取不同路径。

智能自动化系统100中实现的策略可以以策略的至少三种高级类型(如图1中所示出的)中的一种被分类：设计策略、部署策略、和运行时策略。设计策略可以包括与模型中使用的任意类型的内容相关的任意策略。实际策略可以包括任意(一个或多个)规则、(一个或多个)命令、(一个或多个)指令、(一个或多个)要求、(一个或多个)协议、(一个或多个)框架等等，为了(至少部分地)基于某些内容实施某些动作。例如，验证策略可以是设计策略的一种类型，其中特定类型的内容被要求并且要求在模型中被表达。在具体图示中，验证策略可以是在模型级被指定的Apacheweb服务器是7.0或更高级版本的要求。因此，如果模型用没有达到该策略要求的服务元件被创建(例如，6.0版本Apache服务器)，则服务器将不会在服务模型之内运行。因此，用户请求将6.0版本Apache服务器(例如，通过拖入和放入)添加至服务模型可能被拒绝，并且错误消息可以被显示给用户。依赖关系策略也可以是设计策略，并且被表达在关系方面。在元件级被指定的说明性依赖关系策略可以是依赖于XYZ数据库是10.0或更高版本的Apacheweb服务器。在这个示例中，当用户请求在Apacheweb服务器与XYZ数据库之间被创建的关系时，如果XYZ数据库是9.0版本，则关系请求被拒绝，并且错误消息可以被显示给用户。

部署策略可以被提供以在模型被实际部署至目标之前来验证配设期间模型的各个方面和模型之内的服务元件、子模型、和关系。依赖关系策略在一些情景下可以是部署策略。例如，考虑依赖于XYZ数据库是10.0或更高版本的Apacheweb服务器的先前依赖关系策略。在这个示例中，当模型(具有Apacheweb服务器和XYZ数据库)正在被部署至目标时，如果9.0版本XYZ数据库被选择，例如，如果用户覆盖10.0版本XYZ数据库，则策略违规可以发生，并且所选择的9.0XYZ数据库将不会在这个模型之内运行。

运行时策略可以被应用于模型以确保模型实例在运行时期间符合期望的策略。示例运行时策略可以是虚拟机在运行时期间可以使用的存储器的量上的限制(例如，90％存储器使用最大值)，以便维持性能的期望的水平。如果存储器利用率超过了由策略指定的最大量而向策略管理器模块235报警存储器饱和，则运行时策略动作可以将通知发送至策略管理器模块235。当策略管理器模块接收通知时，关于特定策略违规是否可以在不需要修改模型的情况下被更正的确定可以被做出。例如，在这个情景中，策略管理器模块235可以提供指令来向虚拟机配设另一组存储器以提升它的性能。运行时策略使能模型实例的持续监测，并且因此，服务的整个寿命周期可以被管理。

智能自动化系统100的基于模型的方法的实施例使能解决方案的寿命周期管理。智能自动化系统100允许模型实例的渐进监测、模型的重新配置、和模型的重新配设，而不是提供一次性配设动作(也被称为‘即发即忘’)。在至少一个实施例中，监测模块232、配设模块231、和重新部署模块233可以执行这些活动中的至少一些活动。寿命周期状态可以被保持和被管理。模型的每一个寿命周期状态与可以针对模型或模型实例运行的一组动作相关联。例如，用于运行CentosLinuxVM实例的动作可以包括开机、关机、重启、重新配设、和重新配置。

可以用集中式策略来管理服务的整个寿命周期(包括服务创建、服务部署、和运行监测)。例如，如果资源的部署(或重新部署)与策略一致，则基于租户的容量的范围的‘审核策略’可以减少改变请求的需要。其他策略包括验证策略以确保到某些服务元件的依赖关系(Tomcat7.x中、RBAC的安全策略等等)。

转向图4-13B，与智能自动化系统100相关联的可能操作的各种示例屏幕截图和流程图被示出。图4是示例主控面板的屏幕截图400，该示例主控面板可以与智能自动化系统100的各种功能相关联，并且可以被显示在诸如用户系统215(1)之类的用户系统的显示器屏幕上。在至少一个实施例中，主控面板可以与设计引擎220的一个或多个功能相关联。屏幕显示400中的主控面板包括模型编辑器选项、进程编辑器选项、解决方案设计器选项、和策略编辑器选项。模型编辑器选项被配置为允许用户管理单一模型(即，一个或多个服务元件)或组合模型(即，至少一个子模型和可能的一个或多个服务元件)的模型定义。进程编辑器选项被配置为允许用户管理进程。解决方案设计器选项被配置为允许用户查看解决方案(包括先前组合的模型)。策略编辑器选项被配置为允许用户管理策略。

图5是示出根据实施例的可以与智能自动化系统100中组合服务元件相关联的活动的流程图。一组操作可以与图5的活动相对应。在至少一个实施例中，服务器210(1)的元件编辑器模块221可以执行这些操作中的至少一些操作。

流程500可以在502处开始，其中从用户接收输入(该输入标识将要被组合的服务元件)。标识输入可以是诸如服务元件的独特名称之类的唯一的标识符。在504处，可以接收表示服务元件的一个或多个其他属性的输入。通过说明的方式，Apacheweb服务器的属性可以包括IP地址和到数据库的连接性，而数据库的属性可以包括数据中心名称、主机、数据库类型、和连接信息。

如在506处指示的，如果针对服务元件指定一个或多个策略，则在508处将一个或多个指定的策略与服务元件相关联。针对服务元件所指定的策略可以包括由用户创建的或从先前定义的、可重复使用的策略中选择的一个或多个新策略。策略可以依据特定服务元件的要求被表达。例如，策略可以被表达为在Apache服务元件依赖于XYZ数据库版本10.0或更新的版本时Apache服务元件只能被创建的要求。另一个策略可以被表达为Apache服务器只能在特定类型的机器上运行的要求。一般地，这些策略可以是由解决方案的设计者所表达的业务规则。

如在510处指示的，如果针对服务元件指定一个或多个进程，则在512处将一个或多个进程与服务元件相关联。指定的进程可以由用户创建或从现有的、可重复使用的进程中选择。元件级进程可以是执行相关联的服务元件的基础工作的进程。例如，常见的元件级进程包括初始化、清理、配置、创建、删除、启动、停止、暂停、重启、和关闭服务元件的单独的进程。在514处，服务元件可以被公布。在至少一个实施例中，公布服务元件包括将服务元件存储在服务元件数据库212中，以便当其他模型正在被组合时服务元件可以被重复使用。

图6是示例信息的屏幕截图600，在至少一个实施例中，当做出查看模型的选择时，示例信息可以被显示在用户系统的显示器屏幕上。在这个示例性的实施例中，可以针对名称是‘vAppApacheXYZ’的模型显示与两个服务元件(XYZ数据库和Apacheweb服务器)相关联的信息。可以显示每一个服务元件的属性(例如包括属性的名称、属性的类型、和属性的值)。

图7是示出根据实施例的可以与创建智能自动化系统100中的进程相关联的活动的流程图。一组操作可以与图7的活动相对应。在至少一个实施例中，服务器210(1)的进程编辑器模块224可以执行这些操作中的至少一些操作。

流程700可以在702处开始，其中从用户接收标识将要被创建的服务元件的输入。标识输入可以是诸如进程的描述性名称之类的唯一的标识符。在704处，用户可以接收表示将由进程执行的操作的输入。操作还可以包括条件逻辑。

可以针对服务元件(元件级进程)或用于模型(模型级进程)创建进程。元件级进程可以执行在服务元件上执行基础工作(例如，初始化、清理、配置、创建、删除、启动、停止、暂停、重启、和关闭)。模型级进程可以包括编排元件级进程和/或更高级模型级进程以执行与模型相关的其他功能(例如，评估数据中心是否具有足够的资源来容纳模型)的进程。

如在706处指示的，如果针对进程指定一个或多个策略，则在708处将一个或多个指定的策略与进程相关联。针对进程指定的策略可以包括由用户创建的一个或多个新策略或一个或多个先前定义的、可重复使用的策略。策略可以依据具体进程的要求被指定。在710处，进程可以被公布。在至少一个实施例中，公布进程包括将进程存储在进程数据库216中，以便当服务元件或模型正在被组合时进程可以被重复使用。

图8是示例进程的屏幕截图800，当作出通过图形用户界面来查看XYZ数据库的‘启动’进程的选择时，示例进程可以被显示在用户系统的显示器屏幕上。方框表示将在进程的执行期间被执行的操作中的至少一些操作(例如，‘用户预创建’、‘终端STARTUPPFILE＝’等等)。在至少一个实施例中，可以使用适当的输入机制(例如，鼠标、手指、触摸板等等)将操作拖入或放入进程流。此外，当需要的时候，条件逻辑也可以被添加。

图9A和9B是示出根据实施例的与智能自动化系统100中组合模型相关联的活动的流程图。一组操作可以与图9A和9B的活动相对应。在至少一个实施例中，服务器210(1)的模型编辑器模块223可以执行这些操作中的至少一些操作。

流程900可以在902处开始，其中从用户接收标识将要被组合的模型的输入。标识输入可以是诸如模型的独特名称之类的唯一的标识符。在904处，一个或多个对象(即，服务元件和/或子模型)可以(例如，通过图形用户界面拖入或放入)被添加至正在被组合的模型。当在904处被添加的对象包括至少一个子模型时，正在被组合的模型是组合模型。一般地，在一些实例中，因为模型的不同方面可以在单一服务请求中被合并，所以模型可以是N维。例如，虚拟应用购物服务模型可以具有所有服务元件和依赖关系的实体模型、SLA模型、和用户/RBAC的组织模型等等。

在906处，可以接收将在被添加至模型的两个对象之间建立关系的请求。关系可以表达两个服务元件之间、两个子模型之间、或服务元件与子模型之间的关联。服务元件之间的关系的示例可以包括但不限于‘使用’、‘托管’、‘调用’、‘继承于’、和‘被部署于’。关系可以在基础设施层上而不是仅仅在操作层上被表达，并且应用可以在基础设施的顶部被覆盖。因此，关系的表达是分层概念，并且可以创建层次(例如，顶层是防火墙、中间层是web服务器、和第三层是运行期望的应用的应用服务器)。在每一层次内根据具体需要(例如，负载平衡)可以创建多个节点。

在908处，做出请求的关系是否违反任何策略的确定。一个或多个策略可以针对请求的关系的对象中的一个或两个被指定。如果关系违反这些策略中的任何策略，则可以在910处发送错误消息。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面向用户提供错误消息。如果策略违反未被更正(如在912处所确定的)，则可以在910处发送附加的错误消息。如果请求的关系不违反任何策略(如在908处所确定的)，则可以在914处建立关系。

在916处，做出将在模型中的对象之间建立关系的另一个请求是否已经被接收的确定。如果这样，则流程900可以循环回到908以确定是否违反对象的任何策略。因此，针对建立关系的每一个请求，做出关系是否违反任何策略的确定。如果没有违反策略，则可以建立关系，但是如果违反了策略，则不可以建立关系。如本文将进一步描述的，然而，在一些情景中可以不违反策略，但是(例如，当变量不可知时)策略的条件可以是不确定的。在这种情景中，策略可以向用户触发报警消息，但是可以仍然允许创建关系。

在918处，模型级进程可以由用户创建或从模型的先前存在的进程中选择。模型级进程可以是编排与服务元件相关联的所有更低级进程的进程。对于由一个或多个子模型组成的模型，与模型相关联的模型级进程还可以编排与一个或多个子模型相关联的其他模型级进程(如果有的话)。其他更高级模型级进程可以执行与模型本身相关联的动作(检查以查看在数据中心处是否具有足够的容量用于特定模型)。如果模型级进程被创建或被选择，则模型级进程在920处可以与模型相关联。

在至少一个实施例中，一旦模型已经被定义，可以在模型上执行验证检查。在一些实例中，变量可以被应用于服务元件，并且值可以基于一些其他的服务元件(例如，被应用于另一个服务元件的常量)，或值可以基于目标和部署配置。在这些情景中，变量的值在当模型正在被组合的时间的至少一部分期间可以是未知的。可以在组合期间执行诸如验证变量类型之类的一些验证。然而变量本身的验证是灰色区域直到变量的值变为已知。如果值基于来自一些其他服务元件的常量，则一旦模型已经被组合(或每当产量被添加至模型时)，可以执行变量的验证。因此，在922处，做出模型验证是否已经通过的确定。如果模型验证没有通过，则可以在924处发送错误消息。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面向用户提供错误消息。如果基于其他服务元件的变量没有解决，则模型验证可能不通过。如果验证没有完成(如在926处所确定的)，则可以在924处发送附加错误消息。在一个示例中，可以通过解决模型中未解决的变量来实现验证。在至少一个实施例中，变量可以被应用于子模型。此外，任何变量的值可以基于子模型或服务元件，而不是变量被应用于子模型或服务元件)。

如果所有的变量在922处被解决，或如果未解决的变量直到部署不能被解决，或如果验证在最初失败之后在926处完成，则可以在928处公布模型定义。在至少一个实施例中，公布模型定义包括将模型定义存储在模型数据库214中，以便(例如，当组合模型正在被组合时、当模型正在被修改时等等)用户可以访问模型定义用来重复使用。模型定义描述了期望的服务的状态，该期望的服务的状态不仅包括对象和依赖关系还包括基础设施的操作属性(例如，能力、服务级协议、健康等等)。模型可以被接近实时更新以确保部署期望的服务的最准确版本。这在云/弹性环境(其中服务为了满足业务需求而频繁地改变)中尤为重要。为了基于模型定义来部署模型，可以在930处向选择的部署者发送模型定义。

虽然流程900指示对象、关系、和进程被连续添加至模型，但是这样做仅是为了说明性的目的。在至少一个实施例中，智能自动化系统100被设计为当组合模型时允许灵活性。因此，可以以适当的期望的顺序添加服务元件、子模型、关系、和进程。例如，可以添加两个服务元件，并且然后可以请求关系。随后，可以添加另一个服务元件，并且然后可以请求新服务元件与先前添加的服务元件之间的其他关系。进程可以在任意时刻被添加至模型。

图10是示例模型组合的屏幕截图1000，当用户通过图形用户界面来组合模型时，示例模型组合可以被显示在用户系统的显示器屏幕上。例如，用户可以选择主控面板上的‘模型编辑器’选项来组合模型。服务元件1002、1004、和1006分别表示Apacheweb服务器、XYZ数据库、和Ubuntu虚拟机。在至少一个实施例中，这些服务元件1002、1004、和1006中的每一个可以被拖入和放入(使用适当的输入机制(例如，鼠标、手指、触摸板等等))所示出的图形用户界面的指定区域。这些服务元件可以作为选项被提供给用户，例如，在‘导航’窗口中。在Apacheweb服务器与XYZ数据库之间建立‘调用’关系1008。在至少一个实施例中，当用户通过图形用户界面使用适当的输入机制(例如，鼠标、手指、触摸板等等)从Apacheweb服务器服务元件1002到XYZ数据库服务元件1004绘制线条时，可以请求该关系。假定没有检测到策略违反，则可以建立关系。最初可以示出默认关系，并且用户能够点击默认关系从列出一个或多个其他关系选项的下拉框中进行选择。在XYZ数据库与Ubuntu虚拟机之间示出了‘托管’关系1010，并且在Apacheweb服务器与Ubuntu虚拟机之间示出了另一个‘托管’关系1010。当用户在相应的服务元件之间绘制线条时，也可以请求关系1010和1012，并且如果没有违反策略，则可以建立关系1010和1012。

在至少一个实施例中，由于模型正在被组合，可以评估针对服务元件1002、1004、和1006指定的策略。例如，如果针对Apacheweb服务器服务元件1002指定的策略要求XYZ数据库是版本10.0或更新的，则当请求关系时(例如，当用户在Apacheweb服务器与XYZ数据库服务元件之间绘制线条时)可以评估该要求。例如，如果XYZ数据库服务元件1004是版本9.0，则可以检测到策略违反并且可以采取适当的动作(例如，在图形用户界面上显示错误消息)。因此，可以向具有为具体实体组合模型的任务的用户报警基于模型的要求的不兼容或其他问题，并且该用户可以在模型被部署之前采取适当的补救措施。

转向图11，流程图示出了根据智能自动化系统100的实施例的可以与将模型部署至目标中的一个或多个端点相关联的活动。一组操作可以与图11的活动相对应。在至少一个实施例中，服务器210(2)的配设模块231可以执行这些操作中的至少一些操作。

流程1100可以在1102处开始，其中从设计引擎220接收模型定义以创建服务模型实例。服务模型实例是模型的实例化。模型的模型定义包括与模型相关联的详细信息，该详细信息可以被用来在目标的一个或多个端点中实例化模型。

一旦模型定义已经被接收，用户(在本文中也被称为‘部署者’)可以发起与模型的部署相关的一个或多个动作。在1104处，例如，如果针对模型没有指定目标，则部署者可以发起后期绑定(其中目标针对特定模型被指定(例如，圣何塞数据中心))。在至少一个实施例中，目标可以是物理的或虚拟的数据中心。然而，如果针对模型的目标通过早期绑定被指定，则部署者不需要针对模型指定目标。然而，在一些实例中，部署者可以覆盖早期绑定，并且可以基于特定需要指定不同的目标(例如，用旧金山数据中心覆盖早期绑定中指定的圣何塞数据中心)。在1106处，部署者可以指定目标(在其上模型可以被实例化)中的至少一个端点(例如，具体服务器组)。

如果更高级模型级进程与模型相关联(如在1108处所确定的)，则可以在1110处运行进程。进程可以或不可以执行与模型的服务元件相关联的元件级进程的编排。如果执行元件级进程的编排的模型级进程未与模型相关联(如在1112处所确定的)，则流程可以进行到1114。在1114处，部署引擎230可以试探性地导出顺序，并以该顺序配设模型的服务元件和关系。可以通过至少遍历(或评估)关系(该关系定义正在被部署的模型的拓扑)来导出执行的顺序。在1116处，部署引擎230可以确定将以导出的顺序执行配设模型的服务元件和关系的一组进程。1114和1116的操作可以以任意适当的顺序被执行或同时作为关系和服务元件被检查。

一旦执行的顺序和元件级进程被导出，或从先前指定的模型级进程中被确定，则在1118处，可以根据执行的顺序从一组进程中选择第一进程来配设第一服务元件。在1120处，如果确定第一进程和/或第一服务元件违反了任何部署策略，则可以在1122处发送错误消息。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面向用户提供错误消息。如果策略违反未更正(如在1124处所确定的)，则可以在1122处发送附加的错误消息。如果选择的进程和服务元件不违反任何策略(如在1120处所确定的)，则可以在1126处发起配设第一服务元件的进程。如果还需要配设更多的服务元件或关系(如在1128处所确定的)，则流程1100可以循环回到1118来以执行的顺序选择下一个进程以配设下一个服务元件和/或关系。一旦已经配设了模型的所有服务元件和关系(如在1128处所确定的)，可以终止流程1100。

根据图11的流程1100的变型，可以在目标中配设具有至少一个子模型的组合模型。在流程1100的变型中，可以在1102处接收组合模型定义。先前参照单一模型的1104、1106、1108、和1110所描述的一个或多个活动也可以针对组合模型发生。在1112处，可以做出模型级进程是否与组合模型相关联的确定。组合模型的模型级进程可以被配置为编排一个或多个子模型的模型级进程(如果任意子模型具有模型级进程)、组合模型的服务元件的元件级进程(如果任意服务元件在组模型中被直接组合)、在组合模型的任意子模型中被组合的服务元件的元件级进程、或它们的任意组合。在这种情况下，流程可以进行至1118，开始从由组合模型的模型级进程编排的一组进程中选择进程。在1118处，可以从一组进程中选择进程来配设子模型、服务元件、或关系。因此，流程1100中的剩余操作可以配设组合模型的服务元件(包括组合模型中的子模型的服务元件)。

然而，如果在1112处确定组合模型未与模型级进程相关联，则流程可以进行至1114。在1114处，部署引擎230可以试探性地导出顺序，并以该顺序配设一个或多个子模型、组合模型的服务元件(如果有的话)、和组合模型的关系。可以通过至少遍历(或评估)定义正在被部署的组合模型的拓扑的关系来导出执行的顺序。在1116处，部署引擎230可以确定将要以导出的顺序执行配设子模型、组合模型的服务元件(如果有的话)、和组合模型的关系的一组进程。1114和1116的操作可以以任意适当的顺序被执行或同时作为关系、子模型的服务元件、和组合模型的服务元件被检查。

一旦确定了一组进程，流程可以进行至1118，开始从由部署引擎230确定的一组进程中选择进程。在1118处，可以从一组进程中选择进程来配设子模型、服务元件、或关系。因此，流程1100中的剩余操作可以配设组合模型的服务元件(包括组合模型中的子模型的服务元件)。

转向图12，流程图示出了根据智能自动化系统100的实施例的可以与监测模型实例相关联的活动。一组操作可以与图12的活动相对应。在至少一个实施例中，服务器210(2)的监测模块232和/或策略管理器模块235可以执行这些操作中的至少一些操作。

流程1200可以在1202处开始，其中监测模块232监测目标中的模型实例。在1204处可以检测事件。事件的示例可以是存储器利用率达到某一最大量(例如，90％)的模型实例。如果检测到事件，则可以向诸如策略管理器模块235之类的策略管理器发送事件通知。在1206处，做出是否已经违反运行时策略的确定。例如，如果已经针对模型指定了运行时策略(存储器利用率不得超过某一最大量)，则在超过了该指定的最大量时已经违反了策略。

如果做出已经违反了运行时策略的确定，则在1208处，可以做出是否可以自动地更正违反的另一个确定。如果可以在不需要用户的介入的情况下更正策略违反，则在1210处，可以更正策略违反。在至少一个实施例中，在1205处向策略管理器发送的事件通知可以提示策略管理器评估策略违反并且(例如，向重新部署模块233)发送适当的指令来更正违反(如果可能的话)。在1212处，可以通过一些合适的通信技术(例如，在用户系统的显示器屏幕中的图形用户界面上显示的消息、电子邮件、报告机制、文本消息等等)来向部署者发送报警。

在示例说明中，考虑运行时策略，该运行时策略为了维持期望的性能水平要求模型实例的存储器利用率保持在最大量(例如，90％)之下。如果模型实例的存储器利用率达到或超过指定的最大量，则事件指示模型实例的当前存储器利用率。在至少一个实施例中，监测模块232检测事件并且向策略管理器模块235发送通知。策略管理器模块235然后可以评估模型实例的运行时策略是否正在被违反。如果违反已经发生，则策略管理器模块235为了符合运行时策略并且提升性能可以命令重新部署模块233配设模型实例的另一组存储器。此外，这些监测和补救活动促进解决方案的完整寿命周期创建和管理。

图13A和13B是示出根据智能自动化系统100的实施例的可以与修改模型相关联的活动的流程图。一组操作可以与图13A和13B的活动相对应。在至少一个实施例中，服务器210(1)的模型编辑器模块223可以执行这些操作中的至少一些操作。

流程1300可以在1302处开始，其中从用户接收标识将要被编辑的模型的输入。标识输入可以是诸如模型的独特名称之类的唯一的标识符。在实施例中，当运行时策略在部署域中已经被违反并且不能被自动地更正时，可以从部署引擎230接收将要被编辑的模型的标识。在1304处，可以接收修改模型中的对象和/或关系的请求。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面来显示模型，并且可以通过使用适当的输入做出编辑(例如，删除、替换、修改)服务元件、子模型、或关系的请求。

在1306处，做出请求的修改是否违反任何策略的确定。一个或多个策略可以被指定用于与请求的修改相关联的对象和/或关系。如果修改违反了这些策略中的任何策略，则可以在1308处发送错误消息。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面向用户提供错误消息。如果策略违反未更正(如在1310处所确定的)，则可以在1308处发送附加错误消息。如果请求的修改不违反任何策略(如在1306处所确定的)，则可以在1312处做出请求的修改。

在1314处，做出是否已经接收修改对象或关系的另一个请求的确定。如果这样，则流程可以返回到1306，从而确定是否违反服务元件的任何策略。因此，对于每一个请求的修改，做出对关系、子模型、或服务元件的修改是否违反任何策略的确定。如果没有违反策略，则可以做出修改，但是如果违反了策略，则不可以做出修改。然而，在一些情景中，可能没有违反策略，但是策略的条件可能是不确定的(例如，当变量未知时)。在这种情景中，策略可以向用户触发报警消息，但是仍然可以允许做出修改。

在1316处，模型级进程可以针对模型被创建、被选择、或被修改。如果一个或多个模型级进程被创建、被选择、或被修改，则在1318处这些一个或多个进程与模型相关联。

在至少一个实施例中，一旦已经完成对模型的修改，则可以在模型上执行违反检查。如本文先前所讨论的，在一些实例中，变量可以被应用于对象，并且值可以基于一些其他对象，或值可以基于目标和部署配置。在1320处，做出模型验证是否已经通过的确定。如果模型验证没有通过，则在1322处可以发送错误消息。在至少一个实施例中，可以通过用户系统的显示器屏幕上的图形用户界面向用户提供错误消息。如果基于其他对象的变量没有解决，则模型验证可能不通过。如果验证没有完成(如在1324处所确定的)，则在1322处可以发送附加的错误消息。在一个示例中，可以通过解决模型中未解决的变量来实现验证。

如果模型验证在1320处通过，或如果未解决的变量直到部署不能被解决，或如果验证在最初失败之后在1324处完成，则可以在1326处公布修改的模型定义。在至少一个实施例中，公布修改的模型定义包括将修改的模型定义存储在模型数据库214中，并且指示修改的模型定义相比于先前模型是更新的版本。修改的模型定义描述了期望的解决方案的新状态。在1328处可以向选择的部署者发送模型定义的新版本，以便基于模型定义的新版本重新部署模型。在至少一个实施例中，部署引擎230的重新部署模块233可以接收模型定义的新版本，并且在目标中重新部署模型(例如，通过更新选择的已经被修改的组件或通过更新所有组件)。

虽然流程1300指示连续地修改模型的对象、关系、和进程，但是这仅用于说明性的目的。在至少一个实施例中，智能自动化系统1300被设计为当修改模型时允许灵活性。因此，可以以任意适当的期望的顺序修改对象、关系、和进程。

注意的是在某些示例实施例中，可以通过逻辑(例如，在专用集成电路(ASIC)、数字信号处理器(DSP)指令、由处理器执行的软件(潜在地包括目标代码和源代码)、或其他类似的机器等等中提供的嵌入式逻辑)来实现本文所概述的基于模型的智能自动化功能。逻辑可以被编码在一个或多个有形计算机可读介质(可以包括非暂态介质)中。在这些实例中的一些实例中，存储器元件(如图2中所示)可以存储被用于本文所描述的操作的数据。这包括存储器元件能够存储被执行已完成本文所描述的活动的软件、逻辑、代码、或处理器指令。处理器可以执行任意类型的与数据相关联的指令来完成本文所详述的操作。在一个示例中，处理器(如图2所示)可以将元件或物品(例如，数据)从一个状态或形势转换为另一个状态或形势。在另一个示例中，可以用固定逻辑或可编程逻辑(例如，由处理器执行的软件/计算机指令)来实现本文所概述的活动，并且本文所标识的元件可以是一些类型的可编程处理器、可编程数字逻辑(例如，现场可编程门阵列(FPGA)、可擦除可编程只读存储器(EPROM)、电可擦除可编程ROM(EEPROM))或ASIC(包括数字逻辑、软件、代码、电子指令、或它们的任意组合)。

在一个示例实现方式中，服务器210(1)和210(2)可以包括软件以便实现本文所概述的智能自动化功能。可以通过设计前期220的模块和或部署引擎230的模块来促进这些活动。可以基于特定配置和/或配设需要以任意合适的方式适当地合并这些模块。如本文所讨论的，服务器210(1)和210(2)可以包括用于存储信息的存储器元件，该信息将用于实现智能自动化活动。此外，如本文所公开的，服务器110可以包括处理器，该处理器可以执行软件或算法，从而执行智能操作。这些设备还可以将信息保存在任意合适的存储器元件(随机存取存储器(RAM)、ROM、EPROM、EEPROM、ASIC等等)、软件、固件、硬件中，或(在适当情况下和基于特定的需求)保存在任意合适的组件、设备、元件、或对象中。本文所讨论的任意存储器项目(例如，数据库、表、缓存等等)应当被解释为被包含在广义的术语‘存储器元件’之内。类似地，本说明书中所描述的任意潜在的处理元件、模块、和机器应当被解释为被包含在广义的术语‘处理器’之内。每一个网络元件还可以包括用于在网络环境中接收、发送、和/或传递数据或信息的合适的接口。

注意的是根据上面所提供的示例以及本文所提供的许多其他示例，可以一句两个、三个、或四个网络元件来描述交互。然而，这仅仅是为了简洁和示例的目的。在某些情况下，通过参照有限数量的网络元件可以更容易地描述一组给定流程的一个或多个功能。应当理解的是，智能自动化系统100(和它的技术)是容易扩展的，并且可以容纳大量的组件以及更复杂/精密的布置和配置。此外，智能自动化系统100的网络元件还可以被合并在任意合适的布置中。例如，设计引擎220和部署引擎230可以被实现在单一机器中。因此，所提供的示例不应当限制智能自动化系统100范围，或抑制智能自动化系统100广泛教导，因为它潜在地被应用于多种其他架构。

同样重要的是要注意，前面的流程图中的步骤仅示出了一些可能的情景和模式，该步骤可以被智能自动化系统100执行、或在智能自动化系统100之内被执行。可以在适当情况下删除或移除这些操作中的一些操作，或可以在不脱离本公开的范围的情况下相当大地修改或改变这些操作。此外，这些操作中的一些操作已经被描述为与一个或多个附加操作同时或并行地被执行。然而，这些操作的定时可以被相当大地改变。此外，这些操作中的一些操作已经被描述为被特定模块、引擎、设备、或其他元件执行。然而，这些操作可以基于特定需要和实现被合并或被分离为任意合适的模块、引擎、设备、或其他元件。为了示例和讨论的目的，已经提供了前面的操作流程。智能自动化系统100提供了极大的灵活性，其中可以在不脱离本公开的教导的情况下提供任意合适的布置、时序、配置、和定时机制。

虽然已经参照特定布置和配置详细描述了本公开，但是可以在不脱离本公开的范围的情况下相当大地改变这些示例配置和布置。例如，图4、6、8、和10中分别呈现了屏幕截图400、600、800、和1000，仅作为设计引擎220的功能的表示的实例。在本公开的广泛教导之内，各种其他格式、方案、样式、界面等等可以被用来配置和管理智能自动化系统100的组件。同样，虽然屏幕截图400、600、800、和1000是说明性的图形用户界面(GUI)(允许用户在GUI中配置和管理组件)，可以在本公开的广泛教导之内使用任意模式的实现方式。例如，可以在一些实现方式中使用允许用户通过命令创建组件的向导(例如，向用户呈现通过一系列良好定义的步骤引导用户的一系列对话框的用户界面)或命令行界面(CLI)。此外，虽然已经参照促进通信进程的特定元件和操作示出了智能自动化系统100，但是实现智能自动化系统100的预期功能的任意合适的架构或进程可以替代这些元件和操作。

Claims (31)

1.一种方法，包括：

将两个或多个对象添加至模型；

接收在所述两个或多个对象的第一对象和第二对象之间建立关系的请求；

确定所述关系是否违反设计策略；以及

基于所述关系是否违反所述设计策略采取动作。

2.如权利要求1所述的方法，其中，所述对象中的至少一个对象是子模型。

3.如权利要求1所述的方法，其中，所述对象中的至少一个对象是服务元件。

4.如权利要求3所述的方法，还包括：

基于来自用户的输入创建所述服务元件；

将一个或多个属性应用于所述服务元件；以及

将策略关联至所述服务元件。

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

基于来自用户的输入创建所述两个或多个对象中的至少一个对象；以及

将策略关联至所述至少一个对象，其中所述策略是设计策略、部署策略、或运行时策略中的一个。

6.如权利要求1所述的方法，其中，所述第一对象包括在目标中配置所述第一对象的第一启动进程，并且其中所述第二对象包括在目标中配置所述第二对象的第二启动进程。

7.如权利要求1所述的方法，其中，添加所述两个或多个对象是基于从用户接收到的输入的，其中所述输入包括拖放命令。

8.如权利要求1所述的方法，还包括：

当所请求的关系违反所述第一对象和第二对象中的至少一个对象的策略时，将错误消息发送至用户系统的显示器屏幕。

9.如权利要求1所述的方法，还包括：

如果所请求的关系不违反所述第一对象和第二对象的任何设计策略，则在所述第一对象和第二对象之间建立所请求的关系。

10.如权利要求1所述的方法，还包括：

针对所述模型创建模型级进程，其中所述模型级进程包括一个或多个指令，所述一个或多个指令指示配设所述两个或多个对象的时序顺序。

11.如权利要求1所述的方法，还包括将策略关联至所述模型。

12.如权利要求1所述的方法，还包括：

从以确定的顺序执行的一组进程中选择进程，其中所述一组进程以所述确定的顺序的成功执行配设所述两个或多个对象，从而在目标中建立模型；

确定所选择的进程是否违反部署策略；以及

基于所述所选择的进程是否违反所述部署策略采取动作。

13.如权利要求12所述的方法，还包括：

在所述进程被选择之前，确定在所述目标中配设两个或多个对象的所述顺序；以及

确定将要以所述确定的顺序被执行的所述一组进程。

14.如权利要求13所述的方法，其中，确定所述顺序至少部分地基于评估在所述模型中的一对或多对对象之间建立的一个或多个关系。

15.如权利要求12所述的方法，其中，模型级进程与所述模型相关联，所述模型级进程启动来自所述一组进程的进程来配设所述模型的两个或多个对象，从而在所述目标中建立模型实例。

16.如权利要求12所述的方法，还包括：

当所述一组进程中的任一个进程都没有违反部署策略时，通过以所述确定的顺序执行所述一组进程中的进程来在所述目标中建立所述模型实例。

17.如权利要求16所述的方法，还包括：

基于与所述模型相关联的一个或多个运行时策略检监测所述目标中的所述模型实例；以及

如果所述模型实例违反所述运行时策略中的一个运行时策略，则采取动作。

18.如权利要求17所述的方法，其中，所述动作包括：

确定所述模型实例的策略违反能否被自动地更正；以及

当所述策略违反在不修改所述模型的情况下可以被更正时，更正所述策略违反。

19.如权利要求18所述的方法，其中，更正所述策略违反包括在不修改所述模型的情况下重新配设所述模型。

20.一种非暂态计算机可读介质，其具有存储在其上的指令，并且当所述指令被执行时能够使得处理器执行以下操作：

将两个或多个对象添加至模型；

接收在所述两个或多个对象的第一对象和第二对象之间建立关系的请求；

确定所述关系是否违反设计策略；以及

基于所述关系是否违反所述设计策略采取动作。

21.如权利要求20所述的计算机可读介质，其中，所述对象中的至少一个对象是子模型。

22.如权利要求20所述的计算机可读介质，其中，所述对象中的至少一个对象是服务元件。

23.如权利要求20所述的计算机可读介质，其中，当所述指令被执行时还能够使得所述处理器执行以下操作：

当所请求的关系违反所述第一对象和第二对象中的至少一个对象的策略时，阻止建立所述关系的请求被实现。

24.如权利要求20所述的计算机可读介质，其中，所述指令当被执行时还能够使得所述处理器执行以下操作：

如果所请求的关系不违反所述第一对象和第二对象的任何设计策略，则在所述第一对象和第二对象之间建立所请求的关系。

25.如权利要求20所述的计算机可读介质，其中，所述指令当被执行时还能够使得所述处理器执行以下操作：

从以确定的顺序执行的一组进程中选择进程，其中所述一组进程以所述确定的顺序的成功执行配设所述两个或多个对象，从而在目标中建立模型；

确定所选择的进程是否违反部署策略；以及

基于所述所选择的进程是否违反所述部署策略采取动作。

26.如权利要求25所述的计算机可读介质，其中，所述指令当被执行时还能够使得所述处理器执行以下操作：

在所述进程被选择之前，确定在所述目标中配设两个或多个对象的所述顺序；以及

确定将要以所述确定的顺序被执行的所述一组进程，其中确定所述顺序至少部分地基于评估在所述模型中的一对或多对对象之间建立的一个或多个关系。

27.一种装置，包括：

至少一个存储器元件，所述至少一个存储器元件被配置为存储数据；

设计引擎，所述设计引擎与指令相关联；以及

至少一个处理器，所述至少一个处理器可操作以执行与所述设计引擎相关联的指令：

将两个或多个对象添加至模型；

接收在所述两个或多个对象的第一对象和第二对象之间建立关系的请求；

确定所述关系是否违反设计策略；以及

基于所述关系是否违反所述设计策略采取动作。

28.如权利要求27所述的装置，其中，所述对象中的至少一个对象是服务元件，其中所述至少一个处理器可操作以执行与所述设计引擎相关联的进一步的指令：

在将所述两个或多个对象添加至所述模型之前，基于来自用户的输入创建所述模型的所述两个或多个对象中的至少一个对象；

将一个或多个属性应用于所述服务元件；以及

将策略关联至所述服务元件。

29.如权利要求27所述的装置，其中，所述关系从一组关系中被选择，所述一组关系被包括：使用、继承于、托管、被部署于、和调用。

30.如权利要求27所述的装置，其中，所述两个或多个对象中的每一个对象包括一个或多个元件级进程，所述一个或多个元件级进程中的至少一些元件级进程将以预定的顺序执行来将模型配设为目标中的模型实例。

31.如权利要求27所述的装置，其中，所述设计策略定义所述第一对象和第二对象中的至少一个对象的某种类型的内容的要求，其中当所述要求没有被满足时所述关系被确定为违反所述设计策略。