CN101946257A - 建模基于计算机的业务过程以及模拟操作 - Google Patents

Abstract

建模具有若干功能性步骤的基于计算机的业务过程涉及：提供所述业务过程的软件候选模型(740)，每个模型指定功能性步骤(750)、用于实施所述功能性步骤的软件应用组件(770)的布置以及用于运行所述软件应用组件的计算基础设施(780)的设计，以满足给定的非功能性要求，并且适合于自动化部署。对于每个候选模型，根据相应候选模型模拟(730)所述业务过程的操作并且对照非功能性要求评估它们的模拟操作。该模拟可以帮助更高效地搜索合适或最佳的部署并且可以导致更高效地使用共享资源。

Description

建模基于计算机的业务过程以及模拟操作

相关申请

本申请涉及题为“MODEL BASED DEPLOYMENT OF COMPUTER BASED BUSINESS PROCESS ON DEDICATED HARDWARE”(申请人参考编号200702144)、题为“VISUAL INTERFACE FOR SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”(申请人参考编号200702356)、题为“MODELLING COMPUTER BASED BUSINESS PROCESS FOR CUSTOMISATION AND DELIVERY”(申请人参考编号200702363)、题为“SETTING UP DEVELOPMENT ENVIRONMENT FOR COMPUTER BASED BUSINESS PROCESS”(申请人参考编号200702145)、题为“AUTOMATED MODEL GENERATION FOR COMPUTER BASED BUSINESS PROCESS”(申请人参考编号200702600)、和题为“INCORPORATING DEVELOPMENT TOOLS IN SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”(申请人参考编号200702601)的同一日期的共同待决美国申请、以及题为“DERIVING GROUNDED MODEL OF BUSINESS PROCESS SUITABLE FOR AUTOMATIC DEPLOYMENT”(序列号11/741878)的先前提交的美国申请，上述申请全部整体地通过引用结合到本文中。

技术领域

本发明涉及使用软件应用组件来建模具有若干计算机实施步骤的诸如业务过程(business process)之类的过程以实现在计算基础设施上的自动部署的方法，并且涉及对应的系统和软件。

背景技术

物理IT(信息技术)基础设施难以管理。改变网络配置、添加新机器或存储设备通常是复杂且容易出错的手动任务。在大多数物理IT基础设施中，资源利用率非常低：对于服务器而言，15％的利用率并不罕见，对于台式计算机而言则是5％。为了解决此问题，现代计算机基础设施正在变得越来越可(重新)配置，并且以由服务提供商提供的数据中心的形式更多地使用共享基础设施。

Hewlett Packard的UDC(公用数据中心)是已在商业上应用并允许物理基础设施：诸如服务器的处理机器、诸如盘的存储设备、和耦合各部分的网络的自动重配置的示例。重配置可以涉及例如移动或启动软件应用、改变存储空间分配、或改变对不同过程的处理时间的分配。贡献更多可重配置性的另一种方式是通过允许在单个物理机上主控许多“虚拟”计算机。术语“虚拟”通常意指真实或物理的反面，并且在存在一定水平的间接性、或资源用户与物理资源之间的某种调解的情况下使用。

另外，某些计算架构允许重配置底层硬件。在一种情况中，可能将该架构配置为提供若干四路计算机。在另一种情况中，可能将其重配置为提供四倍的单处理器计算机。

对上述完全可重配置性进行建模是极其复杂的。较高级实体的模型在包含或引用用来实现它们或实现它们所需的较低级实体的意义上需要是递归的(例如，虚拟机VM，可以根据当前使用什么底层基础设施来实现它(例如，如下文将更详细地描述的，硬件分区nPAR或虚拟分区vPAR)而较快或较慢地操作)。这意味着模型需要展现出下一代计算机架构的底层可配置性-nPAR由特定的硬件分区组成。这使得模型如此复杂，以致于变得越来越难以让自动化工具(和人)理解并处理模型，以实现a)业务过程，b)应用和应用配置，以及c)基础设施和基础设施配置的设计和管理。在DMTF的用于“System Virtualization，Partitioning and Clustering”的简档：http://www.dmtf.org/apps/org/workgroup/redundancy/中举例说明了对系统的完全可重配置性和递归性质进行建模的需要。

建模方面的困难的另一示例是WO2004090684，其涉及对系统进行建模以便执行处理功能。它记载了“潜在的大量组件可能使得该方法不切实际。例如，具有所有其硬件组件、主机、交换机、路由器、台式计算机、操作系统、应用、业务过程等的IT系统可以包括几百万个对象。可能难以采用任何手动或自动化方法来创建此类大量组件及其关系的单体模型。这个问题由于具有频繁添加/移动/改变的IT系统的典型动态性质而复杂化。其次，不存在细节的隐藏或抽象化，以允许处理功能在隐藏较不相关的组件细节的同时集中于特定的一组相关组件的细节。第三，由于所涉及的组件的数目，在整个系统上执行任何处理可能是不切实际的。”

已经进行了自动且快速地提供计算基础设施的尝试：惠普的公用数据中心、惠普实验室的SoftUDC、惠普的Caveo和Amazon的弹性计算云(可以在http://www.amazon.com/gp/browse.html？node＝201590011处看到)。所有这些提供一种或另一种形式的计算基础设施，并且某些已针对测试者和开发者，例如惠普的公用数据中心。

来自IDS-Scheer的Aris是一种已知的业务过程建模平台，其具有包含关于系统的结构和预期行为的信息的模型仓库。特别地，更详细地对业务过程进行建模。其意图将系统实现方式和文档资料(documentation)的所有方面绑在一起。

Aris UML设计器是Aris平台的组件，其将传统业务过程建模与软件开发相组合以开发从过程分析到系统设计的业务应用。用户经由web浏览器来访问过程模型数据和UML内容，从而实现多用户环境内的处理和改变管理。其可以提供开发文档资料的创建和传送，并且可以链接面向对象的设计和代码生成(CASE工具)。其并不建模数据中心的共享基础设施的基础设施。

发明内容

目的在于提供改进的设备或方法。在一个方面中，本发明提供了：

一种建模具有若干功能性步骤的基于计算机的业务过程的方法，该方法具有以下步骤：

提供所述业务过程的多个软件候选模型，所述模型的每一个指定功能性步骤、指定用于执行所述功能性步骤的软件应用组件的布置，以及指定用于运行所述软件应用组件的计算基础设施的设计，以满足给定的非功能性要求，并且适合于自动化部署，

对于每个候选模型，模拟所述业务过程在根据相应候选模型实施的情况下的操作，以及

对于每个候选模型，评估它们的操作满足所述非功能性要求的程度。

通过评估候选模型的模拟操作，对于合适的或最佳的候选的搜索可以比评估物理基础设施上的实际部署的操作时间更短或更高效。此外，其可以实现对尚不可用于在物理基础设施中测试的配置的评估。对于自适应基础设施的较好或最好配置的更有效搜索可以导致更高效地使用可用资源进行现场部署，并因此导致更低的成本。这对于其中许多业务过程共享可用计算资源的常见情况是尤其有用的。

本发明的实施例可以具有任何附加特征，而不脱离权利要求书的范围，并且在从属权利要求和在下述的实施例中阐述了一些这样的附加特征。

另一方面提供了在机器可读介质上的软件，该软件在执行时实施上述方法。

另一方面提供了一种建模具有若干功能性步骤的基于计算机的业务过程的系统，该系统具有：

储存器，其布置为存储所述业务过程的多个软件候选模型，所述模型的每一个指定功能性步骤、指定用于执行所述功能性步骤的软件应用组件的布置，以及指定用于运行所述软件应用组件的计算基础设施的设计，以满足给定的非功能性要求，并且适合于自动化部署，

模拟器，布置为对于每个候选模型，模拟所述业务过程在根据相应候选模型部署的情况下的操作，以及

评估部，耦合到模拟器，用于对每个候选模型评估它们的操作满足所述非功能性要求的程度。

其他方面可以涵盖使用该系统的人类操作者所进行的对应步骤，以在侵权者的系统部分地或主要地远离本专利所覆盖的权限范围并且在该权限范围之外(如许多此类系统都可行的那样)然而人类操作者正在该权限范围内使用该系统并且从中获益的情况下使得能够直接侵权或引起直接侵权。特别是优于其他现有技术的其它优点对于本领域的技术人员来说将是显而易见的。如对于本领域的技术人员来说显而易见的那样，可以将任何附加特征组合在一起，并与任何方面组合。所述实施例仅仅是示例，范围不受这些示例的限制，并且在权利要求的范围内可以设想许多其它示例。

附图说明

现在将参照附图以示例的方式描述本发明的特定实施例，在附图中：

图1示出实施例的示意图，其示出模型、自适应基础设施和管理系统，

图2示出根据实施例的由操作员和管理系统进行的某些操作步骤的示意图，

图3示出根据实施例的某些主要动作和模型的示意图，

图4示出根据另一实施例的采取模型信息流MIF的形式的从业务过程到已部署模型的步骤序列的示意图，

图5示出根据另一实施例的模型和步骤序列，

图6示出根据实施例的导出植基模型(grounded model)的步骤，

图7示出根据实施例的用于分布式设计的主应用服务器和从应用服务器的布置，

图8示出图7的实施例的主应用服务器的各部分，

图9示出供在实施例中使用的服务器上的虚拟实体的布置，

图10示出销售和分销业务过程(SD)基准(Benchmark)对话步骤和事务(transaction)的示例，

图11示出用于SD Benchmark的示例性定制模型实例，

图12示出用于未绑定模型(unbound model)类的类图示，

图13示出适合用于分散式SD示例的模板的示例，

图14示出分散式SD的植基模型实例，

图15示出适合用于集中式安全SD示例的模板的另一示例，

图16示出了系统的实施例的概图，

图17示出了另一实施例，

图18示出了根据另一实施例的系统，

图19、20和21示出了根据实施例的方法步骤，以及

图22、23和24示出了根据另外实施例的系统。

具体实施方式

定义

“非功能性要求”可以视为在诸如性能、安全性、成本及其他方面将功能性步骤实现得多好。其在非功能性要求的维基百科(http://en.wikipedia.org/wiki/Non-functional_requirements)中有所解释，如下-“在系统工程和要求工程中，非功能性要求是指定可以用来判断系统的操作、而不是特定行为的标准的要求。这应与指定特定行为或功能的功能性要求形成对比。典型的非功能性要求是可靠性、可伸缩性、和成本。非功能性要求通常称为系统的能力特性(ilities)。用于非功能性要求的其它术语是“约束”、“质量属性”和“服务质量要求”。”

功能性步骤可以涵盖用于任何目的的业务过程的任何类型的功能，诸如与接收输入的操作员交互、检索存储数据、处理数据、将数据或命令传递至其它实体等等，通常但不一定表示为人类可读形式...。

“已部署”意图涵盖对于其已分配并配置计算基础设施且软件应用组件已被安装并配置好准备开始运行的建模业务过程。根据该上下文，其还可以涵盖已开始运行的业务过程。

“适合于自动化部署”可以涵盖这样的模型，所述模型提供机器可读信息以使得能够部署基础设施设计，并使得能够由部署服务安装并配置软件应用组件(或自发地或利用由部署服务引导的某种人类输入)。

“业务过程”意图涵盖用于任何类型的业务目的的涉及计算机实现的步骤和可选地其它步骤(诸如人类输入或来自例如传感器或监视器的输入)的任何过程，所述业务目的诸如例如面向服务的应用，用于销售和分销、库存控制、制造过程的控制或调度。其还可以涵盖涉及用于非业务应用的计算机实现步骤的任何其它过程，所述非业务应用诸如教育工具、娱乐应用、科学应用、包括批处理、网格计算等的任何类型的信息处理。可以以序列、循环、递归、和分支方式组合一个或多个业务过程步骤以形成完整的业务过程。业务过程还可以涵盖业务管理过程，诸如CRM、销售支持、库存管理、预算、生产调度等，以及用于商业或科学目的(诸如对气候进行建模、对结构进行建模、或对核反应进行建模)的任何其它过程。

“应用组件”意图涵盖任何类型的软件元素，诸如可单独或以组合方式使用以实现业务过程的计算机实现步骤的模块、子例程、任何量的代码。其可以是可以被操纵以递送业务过程步骤(BPStep)(诸如事务或数据库表)的数据或代码。由SAP产生的销售和分销(SD)产品由若干事务组成，每个事务例如具有若干应用组件。

“未绑定模型”意图涵盖以任何方式(直接地或间接地)指定将用于业务过程的每个计算机实现步骤的至少应用组件的软件，而没有计算基础设施的完整设计，并且可以可选地用来计算业务过程的基础设施资源需求，并且可以可选地散布在两个或更多子模型上或由两个或更多子模型组成。

“植基模型”意图涵盖以任何方式(直接地或间接地)指定适合于业务过程的自动部署的计算基础设施的至少完整设计的软件。其可以是计算基础设施和将部署在基础设施上的应用组件的完整规范。

“绑定模型”涵盖具有植基模型到物理资源的绑定的任何模型。该绑定可以是在植基模型中的ComputerSystems(计算机系统)、Disks(盘)、StorageSystems(存储系统)、Networks(网络)、NICS与在实际计算基础设施中可用的真实物理部分之间的关联的形式。“基础设施设计模板”意图涵盖任何类型的软件，所述软件通过以任何方式指示计算基础设施的至少某些部分并指示该部分之间的预定关系来确定设计选择。这将留下有限数目的选项要完成，以创建植基模型。这些模板可以指示例如可容许选择范围或可容许改变范围。它们可以通过具有如何创建植基模型或如何改变现有植基模型的指令来确定设计选择。

“计算基础设施”意图涵盖任何类型的资源，诸如用于处理、用于存储(诸如盘或芯片存储器)、以及用于诸如联网的通信的硬件和软件，并且包括例如服务器、操作系统、虚拟实体、和诸如监视器的管理基础设施，其用于监视硬件、软件和应用。在例如配置和/或分配资源(诸如处理时间或处理器硬件配置或操作系统配置或盘空间)、以及对各种资源之间的链接或软件进行实例化的意义上，可以“设计”所有这些项目。可以或可以不在多个业务过程之间共享资源。资源的配置或分配还可以涵盖改变现有资源配置或分配。计算基础设施可以涵盖所有物理实体或所有虚拟化实体、或虚拟化实体、用于主控虚拟化实体的物理实体和用于运行软件应用组件而没有虚拟化层的物理实体的混合物。

“计算基础设施的部分”意图涵盖例如诸如服务器、盘、联网硬件和软件的部分。

“服务器”可以意指用于运行诸如可用于外部客户端的服务的应用软件的硬件处理器、或形成能够被诸如另一服务器的主控实体主控并最终被硬件处理器主控的虚拟服务器的软件元素。

“AIService”是用户消费的信息服务。其实现业务过程。

“应用约束模型”可以意指对定制过程、应用打包和组件性能模型中的组件的任意约束。在MIF从左到右前进时这些约束可以被工具用来生成附加模型。

“ApplicationExecutionComponent(应用执行组件)”是例如执行应用组件的(工人)进程、线程或servlet。示例将是由SAP提供的对话工作过程。

“ApplicationExecutionService(应用执行服务)”意指可以管理诸如工作过程、servlet或数据库过程的ApplicationExecutionComponents(应用执行组件)的执行的服务。示例将是由SAP提供的应用服务器。此类应用服务器包括对话工作过程及其它过程的集合，所述其他过程诸如如在主应用服务器(图8)的图中所示的更新和排队过程。

“应用打包模型”是描述软件的内部结构：需要什么产品和从该产品需要什么模块的任何模型，并且通常被未绑定模型包含。

“应用性能模型”意指具有为每个业务过程(BP)步骤定义直接和间接的资源需求的目的的任何模型。其可以被包含在未绑定模型中。

“组件性能模型”可以意指包含应用组件的一般性能特性的任何模型。这可以用来通过使用在定制模型中指定的特定业务过程步骤和数据特性连同在应用约束模型中指定的约束一起导出应用性能模型(其可以被包含在未绑定模型中)。

“定制模型”意指反映特定业务要求的业务过程的一般定制化模式。

“已部署模型”意指具有用于在系统中运行的管理服务的绑定信息的绑定模型。

“候选植基模型”可以是可以由工具在其将未绑定模型变换成植基模型时生成的中间模型。

“植基组件”可以包含用于植基执行组件和植基执行服务两者的安装和配置信息、以及关于策略和开始/停止依赖性的信息。

“植基执行组件”可以是执行应用组件的(工人)进程、线程或servlet的植基模型中的表示。

“植基执行服务”是管理诸如工作过程、servlet或数据库过程的执行组件的执行的实体的植基模型中的表示。

“基础设施能力模型”可以是可以由诸如不同计算机类型的公用设施以及诸如防火墙和负载平衡器的设备配置的资源的目录。

MIF(模型信息流)是用来在其整个生命周期中管理业务过程的模型的集合。

本发明可以应用于许多领域，详细描述的实施例只能覆盖这些领域中的某些。其可以涵盖建模动态或静态系统，诸如企业管理系统、联网信息技术系统、公用计算系统、用于管理诸如电信网络、蜂窝网络、电力网的复杂系统的系统、生物系统、医疗系统、天气预报系统、财务分析系统、搜索引擎等。建模的细节通常将取决于模型的用途或目的。因此，计算机系统的模型可以表示诸如服务器、处理器、存储器、网络链路、盘的组件，每个组件具有诸如处理器速度、存储容量、盘响应时间等相关属性。还可以表示组件之间的关系，诸如包含性、连接性等。

可以使用面向对象的范例，其中，使用对象对系统组件进行建模，并且将系统的组件之间的关系建模为对象的属性、或对象本身。可以使用其它范例，其中，模型集中于系统做什么而不是其如何操作，或者描述系统如何操作。数据库范例可以指定实体和关系。用于系统建模的形式语言包括基于文本的DMTF公共信息模型(CIM)、Varilog、NS、C++、C、SQL、或基于图形表示的方案。

附加特征

从属权利要求的附加特征的一些示例如下：

模型管理器可以耦合到模拟器和评估部，以根据所述评估来选择候选模型之一并且使所选择的候选模型被部署在物理基础设施上。模型管理器可以布置为选择一个或多个候选模型以在测试条件下部署，并且测量这些候选模型的测试部署满足非功能性要求的程度。除了模拟之外使用测试部署可以帮助补偿模拟中的不准确性并且因此生成更实际的评估。

模型管理器可以布置为选择候选模型之一以在现场生产条件下部署。这样的选择可以基于模拟或测试部署而做出。现场生产部署意味着实际输入而不是例如测试输入，并且意味着输出或结果被用于它们的预期目的，而不仅仅是为了评估部署。

该系统可以布置为同时在物理基础设施上部署相同业务过程的多个不同的候选模型。

模型管理器可以布置为管理模型储存器中的模型。

模型管理器可以布置为根据候选模型的任何测试部署和模拟的评估来适配所述模型或产生一个或多个新的候选模型。该反馈可以帮助改善对于最佳候选模型的搜索并且使得搜索更快速。

模型管理器可以布置为通过使用模型模板而产生新的候选模型并且选择若干参数的值来完成所述新的候选模型。使用模板可以帮助减少选项的数目并且因而将搜索空间减少到更可管理的水平。

评估部可以布置为评估以下中的任何一个或多个：吞吐量、安全性、成本、等待时间和可靠性。

模拟器可以具有用于软件的部分和用于基础设施的部分的估计性能参数集合，该模拟包括使用估计性能参数来运行候选模型。对估计参数的需要通常因为存在太多变量而不能实现更大精度而出现。模型管理器可以布置为根据测试部署的测量来适配估计性能参数。这种适配可以改善模拟的质量并且因此改善未来对于最佳候选模型的搜索的效率和快速性。

在企业希望在企业本地的专用硬件上部署、但希望具有由服务提供商进行管理的益处的情况下，则这可能增加另一层的复杂性。对于此示例的更多细节请参考上面提及的共同待决的申请号200702144。在这些情况中，对于最佳候选模型的更快搜索可能变得更加重要。设置开发环境可以通过提供哪些工具适合于给定开发目的以及给定模型部分的预定映射、或者通过包括与该模型一起部署的工具的模型来促进。对于此示例的更多细节请参考上面提及的共同待决的申请号200702145和200702601。如果这种设置更容易，则对于最佳候选模型的更快搜索可能变得更加有价值。

在与游戏服务器一起提供3-D视觉接口以使得多个开发者能够在相同的模型上工作并且看到彼此的改变的情况下，开发者可以更快地导航复杂模型。对于此示例的更多细节请参考上面提及的共同待决的申请号200702356。将此与对于最佳候选模型的更快搜索相组合可以使得能够增强二者的优点。

在企业接口被提供以使得企业能够彼此独立地定制非功能性要求的情况下，则服务提供商可能需要更多的开发努力来满足定制的要求。对于此示例的更多细节请参考上面提及的共同待决的申请号200702363。将此与对于最佳候选模型的更快搜索相组合可以使得能够增强二者的优点。

在注释被插入源代码以辅助建模或文档资料编制的情况下，则可以使对改变的历史进行文档记录以及产生模型更容易。对于此示例的更多细节请参考上面提及的共同待决的申请号200702600。将此与对于最佳候选模型的更快搜索相组合可以使得能够增强二者的优点。

基于模型的方法

这种基于模型的方法的一般目的是使得能够进行开发和管理以提供对三个主层的匹配改变：过程的功能性步骤、用来实现过程的功能性步骤的应用、以及所述应用所使用的计算基础设施的配置。通过使用与对上述部分进行建模的模型交互的适当软件工具来自动地执行此类改变。到目前为止，尚未有在整个系统生命周期中将集成业务过程、应用和基础设施管理的工具链接在一起的任何尝试。

自动地设计并管理企业系统的基于模型的技术-参见由Brand等人所著的作为外部HP实验室技术报告：http://www.hpl.hp.com/techreports/2007/HPL-2007-138.html发表并通过引用结合到本文中的“Adaptive Infrastructure meets Adaptive Applications”-可以提供在使对人类介入的要求最小化的同时自动地设计、部署、修改、监视、和管理用以实现业务过程的运行系统的能力。

将描述用于管理此类复杂的基于计算机的过程的基于模型的方法。此类模型可以具有CIM/UML的结构化数据模型以对以下三层进行建模：

·基础设施元素，诸如物理机器、VM、操作系统、网络链接。

·应用元素，诸如数据库、应用服务器。

·业务级元素，诸如在应用服务器中运行的业务过程的功能性步骤。

模型是例如以UML建模的元素的有组织集合。某些实施例的目的是将这些数据模型用于遵循软件即服务(SaaS)范例的企业应用的自动化按需供应。

问题陈述

用于诸如企业应用的大型业务过程的硬件基础设施和软件布局(landscape)的设计是极其复杂的任务，要求专业人员设计软件和硬件布局。一旦已经部署了企业应用，则存在响应于改变的工作负荷和要求来修改硬件和软件布局的日常(ongoing)要求。此手动设计任务昂贵、耗时、易于出错、并且对快速变化的工作负荷、功能性要求、和非功能性要求反应迟钝。实施例描述了自动地创建企业应用的最优化设计、监视运行的已部署系统、并动态地修改设计以最好地满足非功能性要求的机制。存在到设计过程的两个基本输入：

·功能性要求的规范。通常，这采取应用要支持的业务步骤集合的形式。这些从最终用户的角度描述系统意图做什么。该规范将从标准目录中指定要求的标准业务步骤集合、以及这些步骤的任何系统特定的定制。此规范将确定必须被包括在用于企业应用的适当软件布局的设计中的产品和可选组件的集合。

·非功能性要求的规范。这定义设计必须满足的要求，诸如性能、安全性、可靠性、成本、和可维护性。性能的示例可以包括将支持的用户的总数和并发数目、事务吞吐量、或响应时间。

该设计过程包括创建将满足上述功能性要求和非功能性要求的企业应用的硬件和软件布局的规范。其由以下各项组成：

·选自可用池的物理硬件资源的集合。该基础设施将由计算机、存储器、盘、网络、存储装置、以及诸如防火墙的装置组成。

·要部署到物理资源上的虚拟基础设施、以及虚拟基础设施到物理基础设施的分配映射。应以最好地利用物理基础设施并支持在其上运行的软件的要求的这样的方式来配置虚拟基础设施。例如，分配给虚拟机的虚拟存储器的量或优先级。

·在虚拟和物理基础设施上分布的经适当配置的软件组件和服务的选择。该软件必须被配置为满足系统特定的功能性要求，诸如标准业务过程的定制。此外，软件必须被配置为最好地利用它部署在其上的基础设施，同时满足功能性要求和非功能性要求二者。配置参数可以包括数据库中线程的级别、在应用服务器中启动的内部过程的集合、或被保留供应用服务器的各种内部操作使用的存储器的量。

用于企业应用的设计由以下各项组成：

·物理和虚拟基础设施和软件组件的适当数量或类型的选择

·用于基础设施及软件组件和服务的配置参数。

下述实施例涉及一种自动化机制，其通过对企业应用进行建模以便模拟各种设计参数的效果来创建用于企业应用的最优化设计，使得可以进行最适当的选择和配置。采取基于模型的设计服务(MBDS)形式的模型管理器负责创建系统的一组模型，每个模型具有用于选择、配置、和评估可能性的稍有不同的参数。可以将该设计过程简单地视为对最佳模型的搜索和选择，通常是在找到满足系统的功能性和非功能性要求的最便宜模型的方面进行搜索和选择。

图16-21本发明的实施例

图16示出了具有模型储存器720的实施例。业务过程的候选模型740被存储在那里，并且具有若干组成部分。功能性步骤750被示出，以及非功能性要求760，其可以存储在模型外部。用于实施功能性步骤的软件实体的模型770和用于运行软件实体的计算基础设施的模型780被示出。若干这样的候选模型(每个用于相同业务过程的不同实施)被示出。提供了模拟器730，模拟器730获取估计性能参数715并且计算每个模型的行为和性能。所述行为和性能可以与非功能性要求比较并且对每个模型满足这些要求的程度的评估可以被生成。例如这可以由模型管理器790用来采取适当的动作，诸如修改模型或在测试条件或在现场生产条件下选择哪个候选来部署。部署的软件700和基础设施的部署设计710被示出。

图19示出了由诸如图16的实施例之类的实施例实施的一些步骤。在初步步骤870中产生候选模型，其表示业务过程的部署。在步骤880，模拟器模拟模型的操作，就像其被部署一样。存在各种实施该步骤的方式。通常需要产生测试输入。每个软件实体和用于根据模型运行软件的基础设施的性能参数可以基于测量或估计。在步骤890，对照业务过程的非功能性要求评估模拟操作。这可以涉及在业务步骤等级或在其他等级(取决于非功能性要求)评估模拟性能。通过不仅具有软件实体的表示而且具有用于运行软件的底层计算基础设施的表示的模型使这成为可能。

在步骤897，可以根据评估的结果采取进一步的动作，诸如选择部署哪个候选模型或其他动作。

图17示出了另一实施例。在这种情况下，模型管理器790用于管理测试部署。820是软件实体的测试部署，并且830是用于运行软件实体820的计算基础设施的测试部署。二者都由模型管理器基于模型储存器中的候选模型来设置。可以以这种方式或者同时地或者在不同的时间部署若干不同的候选模型。模型管理器管理测试部署的测试输入，并且接收来自在软件或计算基础设施中设置的适当监视点的测量。这使得能够对照非功能性要求评估各个测试部署并且使得模型管理器能够基于这些测量做出改变或产生新模型，以达到更好的实施方式。

图18示出了另一实施例。在该情况下，模型管理器790被布置为更改模拟器使用的性能参数。来自测试部署的组件性能的测量被馈送到模型管理器。这些可以来自软件或基础设施组件或二者。来自测试部署的输出的测量也被馈送到模型管理器中。在模型管理器中由部分860执行性能推断，以推断例如不能直接测量的组件的性能。该部分例如可以以软件模块的形式实施。性能参数估计校正部850(其再次可以实施为软件功能)获取测量和推断的性能信息并且确定对模拟器使用的估计的校正。这些校正然后用于更新估计组件性能参数840。

图20示出了根据另一实施例的步骤。在这种情况下，在步骤902，表示部署相同业务过程的不同方式的多个不同候选模型被部署。在步骤922应用测试输入。在步骤932，对这些测试部署的输出和选择的组件进行测量。在步骤942，这些被用于评估不同方式的操作，以了解它们满足业务过程的非功能性要求的程度。在步骤952，评估结果可以被用于采取适当的动作，诸如例如基于模拟和测试部署来选择候选模型、或产生新模型。

图21示出了另一实施例。在这种情况下，操作员或开发者的开发过程被示出为使用模板来改进植基模型。下面将向前参考图1讨论植基模型和模板的示例的更多细节。在步骤926产生候选模型。在步骤986将其部署或模拟其操作。在步骤996评估其性能，并且在步骤998，如模板所允许的那样适配剩余参数。该适配被反馈到步骤926。步骤926涉及如下的若干子步骤。步骤936示出了由操作员从目录中选择一般过程模型(GP)。这仅是高级模型。在步骤946对其定制以在没有非功能性要求的情况下完成所需的功能性步骤。在步骤956，操作员输入非功能性要求。在步骤966选择用于计算基础设施的设计的模板。这可以由操作员在来自模型管理器的自动引导下完成，所述模型管理器可以评估选项并且示出最佳选项的排名。然后在步骤976，由操作员再次任选地在来自模型管理器的自动引导下选择该模板未定的剩余参数，模型管理器示出了最佳选项的排名。来自最后重复的评估的反馈可以被添加到该步骤976，以加速开发过程。

图22-24，本发明的实施例

遵循应用于单个企业应用的基于模型的方法的本发明实施例的示意图在图22中示出。

该图示出了企业应用A形式的业务过程的示例，所述企业应用A可以看作是具有4个互连层：

·物理基础设施

·虚拟基础设施

·软件布局

·业务过程

可以将物理基础设施和虚拟基础设施视为计算基础设施的子集。基于模型的设计服务MBDS具有模型储存器(模型池A)，其具有同一业务过程的许多候选模型。每个候选模型包括对应于企业应用的这四个层的子模型。在每层处，在某些实施例中，模型可以由静态模型和操作模型两者组成。静态模型描述系统的静态结构-企业应用的候选设计的选择和配置选项。另外，模型包括基础设施和软件的内部结构、运行时间操作、和性能需求(诸如CPU、存储器、盘、或网络I/O)的详细的操作模型。是这些操作模型允许模拟器评估候选设计将在多大程度上满足系统的非功能性要求。

企业应用通常可以由多个部署模块组成，其对应于已部署软件的完整功能的可部署、可分布的一致子集。这些部署模块将形成软件布局模型的一部分。设计和建模过程的关键决策是如何将应用划分成这些分布式部分和将部署模块设置在哪里。

该图示出了存在由操作员输入或从储存器中获得的对企业应用的功能性和非功能性要求。示出了监视部，其可以测量在被部署时企业应用的某些或所有层的行为和/或性能。MBDS具有模拟器部和模型模拟管理器。用于评估模拟结果的评估部可以是单独的部或被结合到管理器或模拟器中。

该图还示出了自动化部署服务和物理基础设施资源池，将在物理基础设施上部署企业应用和至少某些监视部。可选地，MBDS还可以使用相同的物理基础设施，或者，其可以具有其自己的专用物理基础设施。

此类系统的某些主要步骤如下，并且数字指示这些动作在图22中的何处发生：

0.向MBDS提交企业系统的功能性和非功能性要求。还向MBDS提供资源池中的当前可用物理和虚拟资源的数目和类型。

1.MBDS创建可以满足要求集合的模型池中的全体候选模型。每个模型具有用于各种选择、配置、和操作参数的不同值。可以从描述企业系统的最佳实践设计模式的模板驱动初始候选模型的生成。

2.模拟器使用操作模型来模拟模型池中的每个模型并对照所述要求评估每个模型，并且模型模拟管理器选择最适当的模型。

3.体现系统的设计的所选模型被提交到一组自动化部署服务。

4.该自动化部署服务获取、创建、并配置在设计模型中指定的基础设施、监视、和软件。

5.来自这4个层中的每一个的运行系统的被监视值和/或对要求的修改被反馈到MBDS。模型模拟管理器能够将测量值与由模拟预测的那些相比较。

6.如果预测值与测量值之间的差异超过阈值，则模型模拟管理器可以从池中选择不同的模型，或者促使用操作模型中的更新参数在模型池中创建新的模型，以更好地预测系统的行为。另外，如果要求已改变，则可以选择新模型，或者生成一组新的候选模型。可以向自动化部署服务提供新选择的模型以促使对运行系统应用对应的改变。

可以将各种机制用于模型池中的模型的创建、修改、和选择：

·可以在模型池中管理许多模型，对每个模型进行模拟并对照要求进行评估。模型池中的模型形成候选总体集。

·可以随机地对模型进行转变以改变选择、配置、和评估参数的参数。修改的程度和速率可能受到与测量结果的差异的影响。

·可以基于诸如给出类似结果的标准将模型分类成相关的集合以创建模型集群。可以对这些集群应用各种试探法和选择标准。例如，如果集群中的许多模型预测类似的结果，则可以将此用作增加这些模型的预测置信度的方式。

·可以使用系统的预测行为对模型参数的敏感度来驱动模型参数的修改程度和速率。

·最优化操作模型的内部参数以改善模型的可预测性和置信度。这是通过预测结果与测量值的比较和对模型参数的敏感度的分析实现的。

·可以对候选模型的预测系统行为、以及相关选择和配置参数进行可视化并将其呈现给人类专家，专家随后不仅能够进行候选设计的选择，而且能够指导模型转变过程。可以在很大程度上独立地将上文针对单个企业应用A描述的方案应用于任何数目的附加服务，该附加服务全部将在同一共享资源池上运行。

很明显，在多服务情形中将考虑由在相同物理机上运行的企业服务引起的交互和资源竞争。该情形在图23示出。企业应用A、B和C以及它们的模型彼此独立。每个可以具有与图22示出的相同的组成部分，但是为了清楚起见没有详细示出。本发明的至少一些实施例的显著特征是将部署和管理多个独立企业应用的概念扩展到部署和管理相同企业应用的多个并行版本。这里，同时产生、演化和模拟模型池中的系统模型的多个变型以便找到系统的最合适配置的概念从虚拟世界扩展到物理世界。模型池中也许被组织成集群的最有希望的模型的子集将被并行部署到“实际”系统，并且通过直接测量来评估实际性能和其他非功能性特性。这将在创建或修改实际使用的企业应用之前给予设计多得多的信任。该构思在图24示出。这示出了相同企业应用的三个部署A’、A”和A”’。相同的MBDS管理所有三个部署，为每个提供了对应的模型、对应的监视部、模拟器和模型模拟管理器。该布置具有若干用途。例如，可能希望：

●多次启动系统的部署，并且用首先完成其配置的部署继续。

●创建服务的多个实例并且选择首先完成或最好地满足这些要求的服务。

●使用共同基础设施服务(例如db)来部署开发/测试/调试工具，所述公共基础设施服务经由写时复制技术而不同。这可以使得设置测试/qa环境更容易。

运行多个并行系统(每个系统与模型池中模型的子集相关联)的该构思可以在系统的整个生命周期中应用，而不仅仅应用于初始设计和应用创建。随着要求和工作负荷的改变，可以在并行物理系统上测试对现场系统的最合适修改的选择。类似地，部署在物理世界中的并行系统集合可以在系统的生命期间演化。

该技术可以被附加地应用以加速模型本身的动态改进。从并行系统导出的所监视结果如上所述可以用于修改模型本身的参数以便将来更好地模拟该系统。

与相关工作的比较：

实现优化设计的自动化技术是众所周知的；示例包括遗传算法和模拟退火。对系统建模以预测它们的行为也是众所周知的，并且已经用于许多领域；示例包括飞行器机翼、集成电路和天气系统。类似地，集群有关模型以改进对模型的信任和修改模型参数的概念例如之前已被用在全球变暖的最近模拟中。

本发明的某些实施例的关键特征是这些技术到企业系统的集成的模型集合的应用，其中，在所述的4个层中的每一个处对系统进行建模。所述实施例的集成方法可以解决此类企业系统的设计中固有的资源选择、要求满足、和配置优化问题。一些实施例的关键区别在于将在虚拟世界中产生全体候选模型(模型池)的概念与在物理世界中创建并行企业系统相集成，从而不仅增加了对部属系统的行为的信任，而且加速了模型本身的改进。

自动地设计并管理企业系统的基于模型的技术-可以提供在使对人类介入的要求最小化的同时自动地设计、部署、修改、监视、和管理用以实现业务过程的运行系统的能力。

模型可以具有诸如业务过程、业务过程步骤、业务对象、和软件组件的概念、以及它们之间的关系。

不应将模型与企业应用的软件的源内容混淆。可以存在各种各样的源内容。通常，该源内容为企业应用供应商所拥有。可以存在几种形式的源内容，诸如：

·以诸如Java、或ABVP的语言所写的程序代码。此代码可以直接由人类创建，或者从其它程序模型或工具自动生成。

·程序模型描述系统的方面，诸如其静态结构、或运行时间行为。以诸如XML的某种形式的标记语言来表示程序模型本身。示例可以是：

·用于软件组件的行为的状态和动作图。

·描述业务过程步骤集合的业务过程图。

·描述将软件静态打包成可部署单元、可执行文件和产品的结构图。

可以经由诸如图形编辑器的工具或直接由人类来生成程序代码或程序模型。用来描述源内容的语法和语言可以广泛地改变

现在将描述将一系列模型用于此类目的的示例的更多细节。如果从打草稿(scratch)开始，使用业务过程建模工具来设计业务过程。从可用业务过程的目录中选择业务过程并由业务过程建模工具对其进行定制。可用业务过程是可以被构建并运行的业务过程。如下所述，将存在用于这些的对应模板。然后，指定诸如可靠性和性能要求的非功能性特性。

接下来，选择实现业务过程所需的软件实体，诸如产品和组件。这通常通过在整个产品模型目录中搜索来完成，其中，用于每个产品的模型指定实现什么业务过程。此模型由应用专家或产品供应商提供。

接下来，设计计算基础设施，诸如虚拟机、操作系统、和底层硬件。这可以使用在下文和在通过引用结合到本文中的上文提及的先前提交的申请序列号“Using templates in automated model-based system design”中更详细地描述的模板。模板是具有参数和选项的模型，通过填入参数和选择选项，设计工具将模板变换成可部署系统的完整模型。该申请示出一种使用软件应用组件对具有许多计算机实现步骤的业务过程进行建模以使得能够在计算基础设施上自动部署的方法，该方法具有步骤：

从业务过程的未绑定模型自动地导出业务过程的植基模型，该未绑定模型指定将用于业务过程的每个计算机实现步骤的应用组件，而没有计算基础设施的完整设计，并且所述植基模型指定适合于业务过程的自动部署的计算基础设施的完整设计，

植基模型的导出具有步骤：提供具有计算基础设施的预定部分、该部分之间的预定关系、并具有要完成的有限数目的选项的基础设施设计模板、通过基于基础设施设计模板生成完整的候选基础设施设计以及生成未绑定模型所使用的软件应用组件的候选配置来生成候选植基模型、以及评估候选植基模型，以确定是否可以将其用作植基模型。

接下来，识别并分配来自数据中心中的共享资源池的物理资源。最后，配置并部署物理资源并且可以执行系统的日常管理。

所有这些可以使用SAP R/3作为示例，但是也可适用于其它SAP系统或非SAP系统。如下所述的模板不仅可以包括实现业务过程所需的组件和管理该业务过程所需的管理组件，而且可以包括用于计算基础设施的设计。

可以以各种方式来实现模型生成部。一种方式是基于称为模型信息流(MIF)的六级模型流。这涉及在从业务要求一直到完整的运行系统的捕获过程的生命周期的各级或各阶段中开发模型。在下述图4中示出六个阶段，并且每个阶段具有可以如下概括的对应类型的模型：

·一般模型：起点，例如，基于用户可以从中进行选择的软件包的“开箱即用”功能的业务步骤的高级描述。

·定制过程模型：上文已定义，并且例如利用企业做出的选择对前一模型(一般模型)的特殊化。此模型捕获非功能性要求，诸如响应时间、吞吐量和安全性水平。另外，其可以指定对用于企业的通用业务过程的修改。

·未绑定模型：上文已定义，并且例如能够以企业所指定的要求运行业务过程的系统的抽象逻辑描述。

·植基模型：上文已定义，并且例如可以是对前一模型(未绑定模型)的变换以指定基础设施选择(诸如要使用的虚拟化技术以及硬件的类型)以及还指定运行业务过程的软件的结构和配置。

·绑定模型：已为其保留数据中心中的资源的植基模型。

·已部署模型：已经部署并配置基础设施和软件组件的植基模型。此时，服务启动并运行。

该流程的每个阶段具有存储在模型仓库中的对应类型的模型。管理服务消费(consume)由模型仓库提供的模型并执行管理动作以实现阶段之间的过渡，以在MIF中生成下一个模型。那些服务可以是例如：

·基于模板的设计服务(TDS)(和基于模型的设计服务的示例)：基于模板将非功能性要求转换成用于植基模板的设计选择。

·资源获取服务(RAS)：其目的是在诸如vm的虚拟资源的部署之前分配物理资源。

·资源配置服务(RCS)：其作用是创建/更新虚拟和物理基础设施。

·软件部署服务(SDS)：安装并配置运行业务过程所需的应用和潜在的其它软件。

·监视服务(MS)部署探测器以监视已部署模型的行为。这可以包括在这三个层级中的任何一个或多个处进行监视：

○基础设施：例如监视CPU、RAM、网络1/O使用，与哪个应用或功能性步骤正在执行无关。

○应用：例如监视所花费的时间或操作系统上的诸如DB过程的给定应用的CPU消耗，与使用哪个特定的基础设施组件无关。

○业务过程：例如计算每小时销售订单的数目，与使用哪些基础设施组件或应用无关。

用于计算基础设施设计的模板

使用模板来捕获已知(使用上述管理服务)成功实例化的设计。模板的示例描述在具有一定量的存储器的Linux虚拟机(vm)上运行的SAP模块。模板还捕获已知可以执行的管理操作，例如特定种类的vm的迁移、增加vm的存储器、部署附加应用服务器以对高负荷进行响应等。如果变化管理服务参考模板，则可以使用模板来限制可以应用于模型的变化(改变(deltas))的类型。

模板有时已在特定工具中用来限制选择。另一种方法是使用为工具和用户提供更大自由的约束。在这种方法中，指定解决方案必须满足的约束或规则。一个示例可能是在应用配置中必须存在至少一个应用服务器和至少一个数据库。这些约束自己对于典型的业务过程而言并不充分地降低复杂性，因为如果存在很少的约束，则存在大量的可能设计(也称为大的解空间)。如果存在(表征解所需的)大量的约束，则搜索所有约束并对其求解是非常困难的-有巨大的解空间要探索。并且，从大的约束列表中找出哪个约束使给定的可能设计无效将花费很长的时间。

模板还可能包含用于管理变化的指令。例如，其可以包括需要发布给应用组件以添加具有新的从应用服务器的新虚拟机的重配置指令。

植基模型的导出可以涉及指定应用组件所需的所有服务器。这是自适应基础设施的设计的一部分以及已部署业务过程的性能的主要决定因素之一。模板可以限制服务器的数目或类型，以减少选项的数目，从而例如降低复杂性。

导出植基模型可以涉及指定每个应用组件到服务器的映射。这是将应用组件配置为适合自适应基础设施的设计的一部分。模板可以限制可能的映射的范围，以减少选项的数目，从而降低例如找出最优化解决方案的复杂性。

从未绑定模型导出植基模型可以涉及指定用于监视在使用中的已部署业务过程的管理基础设施的配置。此监视可以是在一个或多个不同层级，诸如监视软件应用组件、或底层自适应基础设施，诸如软件操作系统，或处理硬件、存储或通信。

可以导出多于一个的植基模型，每个模型用于在不同的时间部署同一业务过程。例如，这可以使得能够更高效地将资源用于对那些资源具有随时间变化的需求的业务过程。可以以任何持续时间切换在给定时间部署哪个植基模型，诸如每小时、每天、每夜、每周、每月、每个季度等等。该切换可以是在预定时间，或者可以根据所监视的需求、诸如硬件故障的所检测的资源变化、或任何其它因素来布置切换。

在计算基础设施具有虚拟化实体的情况下，可以将植基模型的导出布置为指定一个或多个虚拟化实体，而不指示如何主控所述虚拟化实体。现在已经认识到可以通过隐藏此类主控来简化模型及其导出，因为在一虚拟实体由另一虚拟实体主控、所述另一虚拟实体本身由另一个虚拟实体主控等等的意义上，该主控可以涉及任意的递归。模板可以指定虚拟实体，并将应用组件映射到此类虚拟实体，以限制要选择的选项的数目，从而再次降低复杂性。如果其不需要指定虚拟实体的主控，则此类模板将是更简单的。可以例如通过单独的资源分配服务在部署之前的某一时间定义该主控。

可以通过在自适应基础设施中保留用于部署绑定模型的资源来将植基模型转换成绑定模型。此时，所需的资源的量是已知的，因此，这时保留资源可以比较早的保留更高效，不过可以设想其它可能性。如果植基模型是对于现有部署的变化，则该方法可以具有确定与现有已部署模型的差异并仅保留所需的附加资源的步骤。

可以通过安装并启动绑定模型的应用组件来部署绑定模型。这使得能够使用业务过程。如果植基模型是对于现有部署的变化，则可以确定与现有已部署模型的差异，并且只需要安装和启动附加应用组件。

建模基本原理中值得注意的两点是使用模板来呈现可以实例化的资源的有限目录，以及不暴露虚拟化资源的主控关系。任一者或两者可以帮助降低模型的复杂性并因此使得能够更高效地处理模型以进行部署或在部署之后进行改变。

某些实施例可以使用基础设施能力模型来呈现可以由计算架构提供的资源的可能类型。基础设施能力模型的实例包含可以由底层公用计算架构部署和配置的每种类型的计算机系统或设备的一个实例。每当公用设施部署并配置这些类型之一时，配置将始终是相同的。对于计算机系统而言，这可以例如意味着以下各项。

相同的存储器、CPU、操作系统

具有相同I/O容量的相同数目的NIC

具有相同特性的相同数目的盘

模板可以将应用组件映射到计算机，同时允许改变应用组件和计算机两者的范围。另外，该模板还可以包括某些或所有网络设计，包括例如防火墙和子网是否将解决方案中的计算机分离。在下文更详细地描述的实施例中，应用打包模型连同定制过程模型一起示出各种应用组件可以如何实现业务过程，并被打包在植基模型内。

还可以使用所选的模板来限制对系统的改变，诸如对业务过程的改变、对应用组件的改变、或对基础设施的改变，或由这些中的任何一个引起的作为结果的变化。这可能使自适应基础设施的日常管理成为更易处理的计算问题，并因此允许更多的自动化并因此降低成本。在某些示例性模板中，某些性质具有范围：例如0至n、或2至n。变化管理工具(或向导(wizard)，或工具或向导集合)仅允许对系统进行与模板一致的改变。该模板被此变化管理工具用来计算可容许变化集合；其仅仅允许可容许变化。如果不存在限制否则几乎数目无穷的可能配置的模板，这可以帮助避免在计算当前和下一个状态的模型之间的差异方面的上述困难。

这些特征的某些优点或后果如下：

1.简单性：通过使用模板，构建链接的工具集合以在设计、部署和改变的整个生命周期中集成业务过程、应用及基础设施设计和管理在计算上变得易处理。

2.通过限制自适应基础设施的可能配置的数目，减轻或避免了必须计算复杂模型的较早和稍后状态之间的差异的特定计算问题。这可以帮助实现用于自适应基础设施的管理系统，其可以自动地确定如何将系统从任意的现有状态发展到任意的期望变化状态。作为替代，模板固定可容许变化的集合且被用作变化管理工具的配置。

3.模板模型在形式上将业务过程、应用组件和基础设施设计相关。这意味着例如对这些中的任何一个的设计、或改变可以根据其它项进行，以便避免与其它不一致的设计或改变。

图1概观

图1示出根据实施例的基础设施、应用、以及管理工具和模型的概观。通常可选地经由业务过程BP调用中心300，通过互联网将自适应基础设施280耦合到客户290。管理系统210具有使用许多模型来管理设计和部署及对已部署业务过程的日常改变的工具和服务。例如，如所示，管理系统具有初始设计工具211、设计改变工具213、部署工具215、以及监视和管理工具217。这些可以采取在可以是分布式的常规处理硬件上运行的软件工具的形式，诸如上述的监视器部、模拟器和模型管理器。初始设计工具和设计改变工具的示例由下述图5所示的服务示出。

示出了用于两个业务过程的某些模型的高级示意图：可能存在更多业务过程。通常，管理系统属于服务提供商，该服务提供商受雇向企业提供IT服务，该企业控制其自己的用于其客户的业务过程。业务过程1的模型230用来开发软件应用组件的设计250。这被用来创建用于运行应用组件以实现业务过程的基础设施设计270。此设计然后可以被管理系统部署为在实际自适应基础设施上运行，在那里，其可以例如被客户、调用中心和供应商(为明了起见未示出)使用。类似地，项目220示出第二业务过程的模型，其用来开发软件应用组件的设计240。这被用来创建用于运行应用组件以实现第二业务过程的基础设施设计260。此设计然后也可以被管理系统部署为在实际自适应基础设施上运行。

自适应基础设施可以包括管理基础设施283，用于耦合到管理系统的监视和管理工具217。不需要将所有这些模型一起保持在单个仓库中：原则上，可以将其存储在任何地方。

图2操作

图2示出根据实施例的由操作员和管理系统进行的某些操作步骤的示意图。人类操作员动作在左侧列中示出，并且管理系统的动作在右侧列中示出。在步骤500处，人类操作员设计并输入业务过程(BP)。在步骤510处，管理系统创建BP的未绑定模型。在步骤520处，操作员选择用于设计计算基础设施的模板。在步骤530处，系统使用所选模板根据未绑定模型和所选模板来创建BP的植基模型。原则上，模板的选择可能是自动化的或由系统引导。服务提供商的人类操作员然后促使植基模型被部署，或者作为具有真实客户的现场业务过程或作为在受控或模拟条件下的测试部署。可以在将植基模型部署为现场业务过程之前对其适合性进行评估：下面参照图3来描述如何这样做的示例。

在步骤550处，系统在自适应基础设施中部署BP的植基模型。由任何类型的监视装置来监视已部署的BP，并将监视结果传递给人类操作员。在步骤570处审查监视结果之后，在步骤575处，企业的操作员可以设计对BP的改变，或者服务提供商的操作员可以设计对基础设施的改变。这些被输入到系统，并且在步骤580处，系统判定改变是否被同一模板允许。如果不是，则在步骤585处，操作员判定赞成新模板，这涉及返回到步骤520；或者判定在同一模板的限制内进行重新设计，这涉及在步骤587处，系统基于同一模板创建该改变的植基模型。

在步骤590处，服务提供商的操作员引起植基模型的部署以用于测试或现场部署。在步骤595处，系统部署所述改变的植基模型。原则上，稍后可以通过生成完整的植基模型并在稍后确定差异来导出该改变，但是这可能更加困难。

图3操作

图3示出实施例的概观，其示出在对业务过程进行自动化部署中涉及的某些步骤和模型。这些步骤可以由图1的管理系统来执行，或者可以在其它实施例中使用。

业务过程模型15具有步骤1-N的规范。例如，如众所周知的那样，可能存在许多循环和条件分支。其可以是人类和计算机实现步骤的混合，人类输入例如由客户或供应商或第三方执行。在步骤65处，针对业务过程的每个计算机实现步骤指定应用组件。在步骤75处，基于未绑定模型25，自动地指定计算基础设施的完整设计。这可以涉及在步骤85处获取基础设施设计模板35，并选择模板允许的选项来创建候选基础设施设计。这可以包括软件和硬件部分的设计。在步骤95处，创建模板允许的软件应用组件的候选配置，以适合候选基础设施设计。这些一起形成候选植基模型。

在步骤105处，评估候选植基模型。如果必要，创建并评估另外的候选植基模型。识别候选中的哪一个最佳地适合业务过程和可用资源的要求。存在许多可能的评估方式和许多可能的标准，其可以被布置为适应于业务过程的类型。例如，可以将该标准结合到未绑定模型中。

可以存在每个用于不同时间或不同条件的几个植基模型。例如，随时间变化的非功能性要求可以导致不同的物理资源、或乃至重配置：VM可能在不办公的时间移除存储器，因为较少人将在使用它。甚至可能关闭未充分利用的从应用服务器VM。不同的植基模型通常但不一定来自同一模板，其中不同参数被应用以生成不同的植基模型。

模板、植基模型和后续模型可以包含用于管理基础设施的配置信息和用于管理基础设施的指令，以便在部署时监视业务过程。示例是在每个新部署的虚拟机中设置监视器，其在CPU利用率上升至一定水平-例如60％-以上时发出警报。

图4MIF

图4示出在从定制模型到已部署实例的过渡中涉及的MIF的某些主要元素。为简单起见，其未示出在典型应用生命周期中将涉及的许多循环和迭代-这些可能被采用。业务过程的一般模型15是起点，并且假设企业或咨询者已经设计了定制业务过程。可以以各种方式来对其进行表示，因此许多实施例中的初步步骤是对其进行定制。定制模型18是一般模型的定制化。因此，很可能使用与针对建模定制模型说明的技术类似的技术来对一般模型进行建模：将存在不同的业务过程步骤。定制模型在以下方面不同于一般模型。其将包括非功能性要求，诸如用户数目、响应时间、安全性和可用性要求。另外，其可以可选地涉及重新布置业务过程步骤：新分支、新循环、新步骤、不同/替换步骤、涉及遗留或外部系统的步骤。

用诸如应用性能31、应用打包21、和应用约束27的输入将定制模型转换成未绑定模型25。未绑定模型可以至少指定将用于业务过程的每个计算机实现步骤的应用组件，而没有计算基础设施的完整设计。用来自基础设施能力33的模型的输入和基础设施设计模板35将未绑定模型转换成植基模型55。

植基模型的部署可以涉及转换到绑定模型57，然后将绑定模型转换到已部署模型63。绑定模型可以保留资源，并且已部署模型涉及安装并启动应用。

图5MIF

图5示出根据另一实施例的模型和步骤序列。其示出模型仓库310，该模型仓库310可以具有诸如模板(TMP)、未绑定模型(UM)、绑定模型(BM)、部分已部署模型(PDM)、完全已部署模型(FDM)的模型。该图还示出各种服务，诸如用于使用模板根据未绑定模型生成植基模型的服务320。另一服务是用于使用资源目录340保留资源以创建绑定模型的资源获取服务330。

自适应基础设施管理服务350可以根据绑定模型在自适应基础设施280中配置并激发(ignite)虚拟机，以创建部分已部署模型。最后，可以使用软件部署服务360来获取部分已部署模型并安装且启动应用组件以启动业务过程，并创建完全已部署模型。

图6导出植基模型

图6示出根据实施例的导出植基模型中的步骤。在步骤400处，从诸如集中式或分散式布置的示例中选择模板。集中式布置意味着在单个服务器或虚拟服务器上主控全部。其它模板选择可以是例如高或低安全性，取决于例如提供什么防火墙或其它安全性特征。其它模板选择可以是例如高或低可用性，其可以意味着为某些或所有部分提供冗余。

在步骤410处，填充所选模板中的其余选项。这可以涉及选择例如盘大小、对话过程的数目、服务器的数目、服务器存储器、网络带宽、服务器存储器、网络带宽、允许的数据库时间等。在步骤420处，通过所述选择来创建候选植基模型。步骤430涉及例如通过用所表示的资源并用表示处理延迟、db延迟等的同步点来构建排队网络而评估候选植基模型。可替换地，所述评估可以涉及将模型部署在具有模拟输入和条件的隔离网络中。

在步骤440处，将评估或模拟结果与用于未绑定模型的目标相比较。这些可以是性能目标，诸如在给定响应时间的情况下同时用户的最大数目，或对于给定数目的用户而言的最大响应时间。在步骤450处，可以用模板所允许的不同选项来创建并测试另一候选植基模型。在步骤460处，针对一个或多个不同模板重复该过程。在步骤470处，比较结果以识别哪个或哪些候选提供最佳的适合。如果例如目标或要求例如在不同的时间是不同的，则可以选择多于一个的植基模型。在这种情况下，可以以对第一植基模型的改变的形式来创建第二或后续植基模型。

图7主应用服务器和从应用服务器

图7示出根据实施例的用于计算基础设施的分散式或分布式设计的主应用服务器和从应用服务器的布置。主应用服务器50被提供为通过网络耦合到数据库60、并耦合到许多从应用服务器70。可以将某些从应用服务器实现为虚拟从应用服务器72。每个从应用服务器可以具有许多对话工人过程80。主应用服务器还使用客户端软件10耦合到远程用户。这些均可以具有在例如通过互联网耦合的台式PC 20上的图形用户界面GUI。一旦客户端已使用主应用服务器登陆，则客户端可以直接使用从应用服务器。

图8主应用服务器

图8示出用于图7的实施例的主应用服务器的各部分。提供排队过程100以管理数据库上的锁。提供消息服务器120以管理用户的登录和用户到例如从应用服务器的分配。提供更新服务器130以用于管理提交工作以在数据库中永久性存储。如果需要，可以提供打印服务器140。可以提供假脱机(spool)服务器150以运行诸如报告的批任务。在160处，示出了用于运行应用组件的实例的对话工人过程。

图9虚拟实体

图9示出供在实施例中使用的服务器上的虚拟实体的布置。示出了虚拟实体的分级结构。在操作系统层级，存在许多虚拟机VM。在其它VM上主控某些VM。例如通过时间共享或通过并行处理电路，在表示硬件处理实体的可重配置分区的虚拟分区VPAR 610上主控某些VM。这些中的若干可以由表示例如安装若干硬件处理实体的电路板的硬分区实体nPAR 620来主控。多个nPAR构成物理计算机630，物理计算机630通常通过网络接口650耦合到网络并诸如经由存储区域网络SAN接口640耦合到存储装置。

在市场上存在来自HP、IBM、EMC以及其他公司的许多商业存储装置虚拟化产品。这些产品集中于管理可用于物理机的存储装置和增加存储装置的利用率。虚拟机技术是独立于其它操作系统实例在一个物理机上运行操作系统实例的一种已知机制。已知的是在单个物理机内具有由此机器上的虚拟网络连接的两个虚拟机。VMware是虚拟机技术的已知示例，并可以提供用于在同一物理机上运行的不同操作系统实例的隔离环境。

还存在可以发生虚拟化的许多层级。例如，HP的蜂窝体系架构允许将单个物理计算机划分成许多硬分区或nPAR。每个nPAR对于操作系统和应用表现为单独的物理机。类似地，可以将每个nPAR划分成许多虚拟分区或vPAR，并且可以将每个vPAR划分成许多虚拟机(例如，HPVM、Xen、VMware)。

图10至15

本文接下来的部分参照图10至15来更详细地描述可以在图1至9、特别是图4所示的模型信息流(MIF)内使用的模型的示例。这些模型可以用来在公用基础设施内在其整个生命周期中管理SAP应用或其它业务过程。使用众所周知的使用CIM(公共信息模型)样式的UML(统一建模语言)示出了这些图示。该实现可以是以Java或其它软件语言。

定制模型可以具有BusinessProcess(业务过程)与AIService的实例之间的一一对应关系。AIService是实现业务过程的信息服务。

可以将业务过程分解成若干业务过程步骤(BPstep)，因此，BusinessProcess类的实例可以包含1个或多个BPStep。可以将BPStep的实例拆分成多个较小BPStep，涉及例如序列、分支、递归、和循环。一旦BusinessProcess步骤被分解成足够的细节，可以使每个最低水平的BPStep与ApplicationComponent(应用组件)匹配。ApplicationComponent(应用组件)是实现BPStep的程序或函数。对于SAP而言，示例将是SAP R/3Enterprise的SD(销售和分销包)中的称为VA01的SAP事务。另一示例可以是特定的web服务(在应用服务器中运行)。

BPStep可以具有stepType(步骤类型)和stepParams(步骤参数)字段以不仅描述类似于步骤的较高级序列的执行和分支概念，而且描述步骤本身。stepType字段用来定义顺序或并行执行、循环、以及if-then-else(如果-则-否则)语句。stepParams字段用来定义关联数据。例如，在循环的情况下，stepParams字段可以是循环计数或终止标准。BPStep集合本质上描述具有诸如循环、if-then-else(如果-则-否则)语句、分支概率等各种控制的步骤的图。

关系BPStepsToApplicationComponentMapping(BPStep到应用组件映射)是详细描述BPStep被如何映射到Application Component(应用组件)的复杂映射。其以精简形式表示BPStep对Application Component(应用组件)的调用的潜在复杂混合物，诸如在ApplicationComponent(应用组件)内调用的特定对话步骤或函数或对web服务的方法调用的集合，以及提供的参数细节，诸如销售订单中的行式项目的平均数目。

BPStep可以具有与之相关的一组非功能性要求(NonFunctionalRequirements)：性能、可用性、安全性以及其他。在当前版本中可以由串：“高”、“中”、“低”来对可用性和安全性要求进行建模。在例如注册用户数目(NoUsersReq)、系统的并发用户数目、以秒为单位的响应时间和对于每秒事务数目的吞吐量要求方面指定性能要求。许多BPStep可以共享同一组非功能性要求。可以由串来表示时间函数。其指定何时应用非功能性要求，因此可以在办公时间到正常办公时间之外的时间期间应用不同的要求。更丰富的时变函数也是可能的以捕获月末峰值等。

图10、11定制模型

对于定制模型的示例而言，将讨论众所周知的销售和分销(SD)Benchmark(基准)。这是由众所周知的德国公司SAP生产的软件。其为SAP R/3系统的一部分，SAP R/3系统是执行诸如制造、会计、财务管理、和人力资源的用于公司的标准业务功能的软件的集合。SAPR/3系统是能够在几乎任何硬件/软件平台上运行且能够使用许多不同的数据库管理系统的客户端服务器系统。例如，其可以使用利用数据库系统DB2运行操作系统OS/400的IBM AS/400服务器；或使用Oracle数据库系统的Sun Solaris(Unix的衍生版本)；或使用SQL服务器运行Windows NT的IBM PC。

SAP R/3被设计为允许企业选择其自己的业务功能集合，并进行定制以添加新的数据库实体或新功能。SD Benchmark使用SD(销售和分销)应用模拟许多并发用户以评估硬件的性能能力。对于每个用户而言，交互由一遍又一遍地重复的16个单独步骤(对话步骤)组成。在图10中示出该步骤及其到SAP事务的映射。这里，事务是应用组件的示例。每个事务被示为行中的若干方框。每行中的第一个方框表示用户例如通过键入/nva01以开始事务VA01来调用事务。如图10所示，顶行中的事务VA01涉及调用创建销售订单事务、然后填充订单细节、然后保存售达方、以及以保存数据的“返回”功能F3结束的业务过程步骤。在第二行中示出下一个事务VL01N，并且其涉及如下步骤以创建外出递送。调用该事务，填充并保存装运信息。在第三行中示出下一个事务VA03，其用于显示客户销售订单。这涉及调用该事务，并填充随后的文档。在第四行中是第四事务VL02N，其用于改变外出递送。在调用此事务之后，下一个方框示出保存外出递送。第五行所示的下一个事务是VA05，其用于列出销售订单。在调用此事务之后，下一个方框示出提示用户填充日期，并且然后第三方框示出列出给定日期的销售订单。最后，在第六行中，事务VF01用于创建账单文档，并示出填充表格且保存已填充表格。

图11示出用于SD Benchmark的定制模型实例的示例。顶部的两个方框指示业务过程“BPModel”包含一个顶层级BPStep：“SD Benchmark”，其中stepType＝Sequence(序列)。示出了从此方框引出的两条线，一个线到与此顶层级BPStep相关的并由左侧的方框示出的非功能性要求。在这种特定情况下，仅仅指定性能要求-一个用于9am～5pm且另一个用于5pm～9am。未示出的其它类型的非功能性要求可以包括例如安全性或可用性要求。在每种情况下，可以如所示地指定性能要求，诸如用户的数目、并发用户的数目、所需的响应时间、以及所需的吞吐量。这些仅仅是示例，可以指定其它要求以适合业务过程的类型。如所示，表示相应时间函数的方框被耦合到每个性能要求方框。在本示例中，一个指示9am至5pm且另一指示5pm至9am。

在右侧，一条线从SD Benchmark BPStep引出到被示为六个BPStep的功能性要求，其中stepType＝Step(步骤)-一个用于图10所示的每个SAP事务(VA01、VL01N等)。为方便起见，将图10所示的每个事务的第一对话步骤的名称用作图11所示的对应BPStep的名称(“创建销售订单”、“创建外出递送”、“显示客户销售订单”、“改变外出递送”、“列出销售订单”、和“创建递送文档”)。对于这些步骤中的每一个而言，BPStepToApplicationComponentMapping关系指定所涉及的对话步骤的细节。例如，在CreateSalesOrder(创建销售订单)的情况下，图10示出BPStepToApplicationComponentMapping需要指定按顺序执行以下对话步骤：“创建销售订单”、“填充订单细节”、“售达方”和“返回”。另外，其可能指定“填充订单细节”所需的行式项目的数目。在图的右侧，每个BP步骤经由相应映射耦合到其对应的ApplicationComponent(应用组件)的实例。因此，BPstep“创建销售订单”经由具有ID：001的映射耦合到ApplicationComponent(应用组件)VA01。BPstep“创建外出递送”经由具有ID：002的映射耦合到ApplicationComponent(应用组件)VL01N。BPstep“显示客户销售订单”经由具有ID：003的映射耦合到ApplicationComponent(应用组件)VA03。BPstep“改变外出递送”经由具有ID：004的映射耦合到ApplicationComponent(应用组件)VL02N。BPstep“列出销售订单”经由具有ID：005的映射耦合到ApplicationComponent(应用组件)VA05。BPstep“创建递送文档”经由具有ID：006的映射耦合到ApplicationComponent(应用组件)VF01。

图12未绑定模型

未绑定模型用来计算资源需求。如图12所示，此模型可以由四个模型构成：定制模型(标记为CustomizedProcessingModel(定制处理模型))、应用打包、应用约束和应用性能模型，其中的每一个的示例将在下文描述(除定制模型之外，定制模型的示例已在上文关于图11进行了描述)。可以设想其它布置。未引入尚未包含在这四个模型中的新信息。

图12应用打包模型

应用打包模型描述软件的内部结构：需要什么产品和需要来自该产品的什么模块。可以在ApplicationModule(应用模块)中包含ApplicationComponent(应用组件)。ApplicationModule(应用模块)可以对应于用于应用服务器的JAR(Java存档)文件或数据库中的表格。在SAP的情况下，其可能是从特定产品加载到诸如SD或FI(财务)的应用服务器中的模块。应用打包模型可以具有DiskFootPrint(盘足迹)以指示ApplicationModule(应用模块)所需的盘存储量。在图10中的ApplicationComponent(应用组件)VA01的情况下，其来自例如具有2MB的DiskFootPrint的SD。

在产品内包含一个或多个ApplicationModule(应用模块)。因此，例如，SAP R/3ENTERPRISE包含SD。ApplicationModule(应用模块)可以依赖于其它ApplicationModule(应用模块)。例如，用于应用服务器的SD代码依赖于被加载到数据库中的SD数据和SD可执行代码两者。

定制模型可以具有执行ApplicationComponent(应用组件)的ApplicationExecutionComponent(应用执行组件)。这可以是在应用服务器或web服务器中运行的servlet。其还可以是特定组件的线程或过程。在SD的VA01事务的情况下，其为对话工作过程。当其执行时，ApplicationComponent(应用组件)可以间接地使用或调用其它应用组件来运行：servlet可能需要访问数据库过程；SD事务需要访问其它ApplicationComponent(应用组件)，诸如排队工作过程和更新工作过程，以及数据库ApplicationExecutionComponent(应用执行组件)。

可以由ApplicationExecutionService(应用执行服务)(SAP应用服务器)包含并在其上下文中执行ApplicationExecutionComponent(应用执行组件)，ApplicationExecutionService(应用执行服务)加载或包含ApplicationModule(应用模块)(SD)并管理ApplicationExecutionComponent(应用执行组件)(对话WP)的执行，ApplicationExecutionComponent(应用执行组件)又执行ApplicationComponent(应用组件)(VA01)以递送BPStep。

图12，应用约束模型

应用约束模型表示对定制过程、应用打包和组件性能模型中的组件的任意约束。在MIF从左到右前进时这些约束可以被工具用来生成附加模型。约束的示例包括：

·如何扩增应用服务器-什么ApplicationExecutionComponent(应用执行组件)被复制且什么不被复制。例如，为了扩增SAP应用服务器以处理更多的用户，不能仅仅复制第一实例-图7和8的主应用服务器50，一般称为中央实例。作为替代，需要中央实例内的组件的子集。这也是设计原则的示例：可能存在对最佳设计原则进行编码的其它约束。

·用于ApplicationComponent(应用组件)、ApplicationExecutionComponent(应用执行组件)和ApplicationExecutionService(应用执行服务)的安装和配置信息

·对ApplicationExecutionService(应用执行服务)的性能约束-例如不在具有大于60％的CPU利用率的机器上运行应用服务器

约束的其它示例包括命令：需要在应用服务器之前启动数据库。可以使用其它约束来对部署和配置信息进行编码。该约束可以全部被包含在模板中，或除模板之外另外提供，以进一步限制用于植基模型的选项的数目。

图12.应用性能模型

应用性能模型的目的是定义用于每个BPStep的资源需求。存在要考虑的两种类型的资源需求。

1.由使用CPU、存储器I/O、网络I/O和存储器的ApplicationExecutionComponent(应用执行组件)(例如，对话WP)在其执行BPStep时直接生成的资源需求-ComponentResourceDemand(组件资源需求)

2.在上述ApplicationExecutionComponent(应用执行组件)使用、调用或援引其它组件(例如，使用更新WP的对话WP)时由其引起的组件所生成的资源需求-IndirectComponentResourceDemand(间接组件资源需求)

IndirectComponentResourceDemand(间接组件资源需求)是递归的。因此，将存在类似于调用图或活动图的树。

完整的应用性能模型将包含用于图11所示的所有BPStep的类似信息。例如，BPStep“创建销售订单”中的对话步骤集合可消耗0.2SAPS。此外，其由四个单独的调用(或者，按SAP术语，为对话步骤)组成。该调用是同步的。

以下是可能出现在IndirectComponentResourceDemand(间接组件资源需求)和ComponentResourceDemand(组件资源需求)中的属性的某些示例。

·delayProperties(延迟性质)：与不消耗任何CPU、NetIOProperties(网络IO性质)和DiskIOProperties(盘IO性质)的组件活动相关的任何延迟(例如，等待或睡眠)。

·NumInvocation(调用数目)：在BPStep的执行期间调用组件的次数。

·InvocationType(调用类型)：如果调用程序被阻止，则同步；如果调用程序可以立即继续活动，则异步。

·BPStepToAppCompID：其为BPStepToApplicationComponentMapping的ID属性。其原因是在几个不同的BPStep中很可能涉及特定的ApplicationExecutionComponent(应用执行组件)。

·ApplicationEntryPoint(应用进入点)：其为正在执行的程序或函数。在“创建销售订单”的情况下，其为用于DialogWP的VA01。其还可以是web服务的方法。

可以以SAP为单位或用其它单位来表示CPUProperties(CPU性质)。存在各种表示MemProperties(存储器性质)、NetIOProperties和DiskIOProperties的方式。

图12，组件性能模型

对于定制模型的每个实例存在应用性能模型的一个实例。这是因为在一般情况下，每个业务过程将具有唯一的特性：唯一的BPStep排序和/或用于每个BPStep的唯一的数据特性集合。DirectComponentResourceDemands(直接组件资源需求)和IndirectComponentResourceDemand(间接组件资源需求)关联指定每个BPStep的唯一资源需求。需要根据从基准导出的每个ApplicationComponent(应用组件)的已知特性以及还有已安装系统的踪迹来计算这些需求。

组件性能模型包含每个ApplicationComponent(应用组件)的已知性能特性。通过将以下各项组合来计算特定的应用性能模型。

·包含在定制模型中的BPStepToApplicationComponentMapping(BPStep到应用组件映射)关联中的信息

·应用约束模型中的任何性能相关约束。

·组件性能模型

合起来，未绑定模型的这些模型不仅指定系统的非功能性要求，而且指定如何生成并评估满足那些要求的可能软件和硬件配置的方法。可能的硬件配置的生成受到使用基础设施能力模型中的信息进行的可从特定基础设施提供商处获得的基础设施的选择、以及所选模板的约束。

适用于诸如ApplicationExecutionComponent(应用执行组件)或ApplicationExecutionService(应用执行服务)的在未绑定模型中描述的可部署软件元素的一般原理是模型仅包含描述应用拓扑结构所需的每种类型的元素的最小数目的实例。例如，在SD的情况下，在未绑定模型中只需要与应用服务器的单个实例ApplicationExecutionService(应用执行服务)相关的对话工作过程的单个实例ApplicationExecutionComponent(应用执行组件)来描述实例化植基模型中的两个元素的植基等价物的无数种可能方式。准确地确定可以如何复制这些实体并使其共同定位的是模板和打包信息。

基础设施能力模型

如上文所讨论的，所述建模基本原理的两个值得注意的特征是：

1.呈现具有可以实例化的资源的有限目录的模板，以便存在固定且有限数目的选择。例如，小xen-vm 1-盘、中xen-vm 2-盘、大xen-vm3-盘、物理hpux机等。这使得由任何容量规划工具进行的资源类型的选择更简单。其还可以使得基础设施管理更容易，因为在资源配置中存在较低的复杂性-可以使用标准模板。

2.不暴露虚拟化资源的主控关系。DMTF虚拟化系统简档将主控关系建模为“HostedDependency(主控依赖性)”关联。如果只需要对有限数目的资源类型进行建模，则这看起来是不需要的，因此其未出现在这里所讨论的任何模型中。这使模型保持更简单，因为不需要处理任意的递归。这并不意味着如果方便的话处理这些模型的工具不能在内部使用DMTF方法。资源目录服务和资源分配服务在其内部模型中使用此关系可能是很方便的。

基础设施能力模型的实例包含用于可以由底层公用计算架构部署和配置的每种类型的计算机系统或设备的一个实例。每当公用设施部署并配置这些类型之一时，配置将始终是相同的。对于计算机系统而言，这意指以下各项。

·相同的存储器、CPU、操作系统

·具有相同I/O容量的相同数目的NIC

·具有相同特性的相同数目的盘

图13模板示例

图13示出具有计算基础设施的预定部分、该部分之间的预定关系、以及具有有限数目的要完成的选项的基础设施设计模板的示例。在这种情况下，其适合于分散式SD业务过程，而没有安全性或可用性特征。该图示出通过标记为“AI_network”的网络耦合的三个计算机系统，三个系统中的右侧的一个对应于主应用服务器，并且中央的一个对应于从应用服务器，如图7所示。因此，其是分散式的。AI是自适应基础设施的缩写。这些计算机系统的左侧的一个用于数据库。指定每个计算机系统的类型，在这种情况下指定为BL20/Xen。对应于从应用服务器的中央的一个具有属性“range＝0..n”。这意味着该模板允许任何数目的这些从应用服务器。

主应用服务器被耦合到标记为AI_GroundedExecutionService：AppServer(AI_植基执行服务：应用服务器)的方框，指示其可以用来运行此类软件元素。其具有包含足以允许自动地安装、部署和管理AI_GroundedExecutionService的配置信息和部署信息的相关AIDeploymentSetting(AI部署设置)方框。AI_GroundedExecutionService：AppServer被示为包括三个组件，标记为AI_GroundedExecutionComponent(AI_植基执行组件)，并且每个具有相关的AIDeploymentSetting方框。这些组件中的第一个是对话工作过程，用于指定业务过程的步骤的应用组件，另一个是更新过程，负责提交工作以进行永久性存储，并且另一个是排队过程，用于管理数据库上的锁。如所示，对于更新和对话工作过程而言，范围属性是2..n，意味着允许这些部分的多个实例。

从应用服务器具有GroundedExecutionService(植基执行服务)，其具有用于任何数目的对话工作过程的仅一种类型的AI_GroundedExecutionComponent。从应用服务器被示为具有rangePolicy(范围策略)＝Time function(时间函数)，意味着其被允许在给定时间是活动的。再次地，服务和执行组件每个具有相关的AIDeploymentSetting方框。

主和从应用服务器以及数据库计算机系统具有被示为AI_disk：OSDisk的操作系统。主应用服务器被示为具有AI_Disk：CIDisk作为供应用组件使用的存储装置。对于网络而言，每个计算机系统具有被示为AI_Nicl的网络接口，其耦合到由AI_Network：subnet1所示的网络。

数据库计算机系统耦合到标记为AI_GroundedExecutionService：Database(数据库)的方框，其具有用于该数据库的仅一种类型的AI_GroundedExecutionComponent，SD DB。再次地，服务和执行组件每个具有相关的AIDeploymentSetting方框。AIDeploymentSetting承载用来部署、配置、启动、管理和改变组件的配置和管理信息。下面参照图14来描述其示例的更多细节。此计算机系统被耦合到标记为AI_Disk：DBDisk的用于数据库的存储装置。

可选地，模板可以具有在生成植基模型时或生成变化的植基模型以改变现有植基模型时被工具调用的命令。此类命令可以被布置为限制可用选项，并且可以使用指定某些基础设施设计的模板的各部分作为输入。其还可以使用未绑定模型的各部分作为输入。

图14植基模型

可以由设计工具在其将未绑定模型变换成植基模型时生成植基模型。可以将其视为候选植基模型，直至被评估和选作选定植基模型为止。以下是与图13所示的模板相比较的图14的示例性植基模型的某些特性，图14的示例性植基模型是从图13所示的模板导出的。

·已经指定GroundedExecutionComponent(植基执行组件)的实例的数目。

·由GroundedExecution-Service(植基执行服务)来执行GroundedExecutionComponent(植基执行组件)。执行关系与在应用打包模型中所表示的关系一致。

·GroundedExecutionService(植基执行服务)在其类型已从基础设施能力模型中选出的ComputerSystem(计算机系统)上运行。

·存在两个更新组件，Update1和Update2。存在两个DialogWorkProcess(对话工作过程)，DialogWorkProcess1和DialogWorkProcess2。

·从应用服务器的数目已被设置为零。

管理系统被布置为进行这些选择以使用未绑定模型从模板导出植基模型。在所示的示例中，用于选择的标准包括系统的总容量，其必须满足定制模型中的随时间变化的性能要求。通过将这些性能要求与应用性能模型的聚合ResourceDemand(资源需求)[直接和间接]相组合来确定所需容量。如果第一选择证明提供了太少的容量或也许提供了太多的容量，则可以进行其它选择并进行评估。其它示例可以具有评估候选植基模型有多接近最佳适合的不同标准和不同方式。

在某些示例中，服务器可以仅附接有OS盘；这是因为此类装置(installation)中的惯例是NFS安装CI盘以获得其SAP可执行文件。其它示例性模板可以具有可选择细节或选项，诸如CIDisk和DBDisk是100GB、20MB/秒、非Raid等的细节。OS盘可以是EVA800型的。主和从应用服务器可以具有2至5个对话工作过程。计算机系统被指定为具有例如3GB存储装置、2.6GHz CPU和SLES 10-Xen操作系统。可以尝试不同的参数以形成候选植基模型，可以对该候选植基模型进行评估以针对期望性能或容量或其它标准找出最佳适合。

因此，植基模型指定所需的软件和硬件可部署实体的实例的精确数目和类型，所述实体诸如GroundedExecutionComponent(植基执行组件)、GroundedExecutionService(植基执行服务)、和AlComputerSystem(AI计算机系统)。AIDeploymentSetting(AI部署设置)可以包括例如：

·基础设施设置，诸如用于基础设施管理组件的阈值信息，例如MaxCPUUtilization(最大CPU利用率)-如果其上升至设定数字(例如60％)以上，则应触发警报。

·管理策略可以指定用于管理组件的其它策略信息-例如，如果利用率上升至60％以上，则向上伸展(flex up)。

·GroundedDeploymentSetting(植基部署设置)，其可以包括所有命令行和配置信息，以便可以在全功能状态下安装、配置并启动系统。

·SettingData(设置数据)，其可以提供可以覆盖在GroundedDeploymentSetting(植基部署设置)中提供的信息的附加配置信息。这允许许多GroundedComponent(植基组件)共享相同的GroundedDeploymentSetting(植基部署设置)(比较(c.f.)，类别(typing)的概念)，其中特定参数或覆盖参数由SettingData(设置数据)提供。由部署服务在部署期间解释GroundedDeploymentSetting(植基部署设置)和SettingData(设置数据)两者。

·与对组件的可能改变有关的数据，诸如在管理对组件的改变时执行的指令，以实现改变的更多自动化。

在植基模型中并未设置所有属性。例如，在植基模型中设置MAC地址没有意义，因为尚不存在任何分配的物理资源。

图15，可替换自适应基础设施设计模板

图15以适合于集中式安全SD业务过程的形式示出可替换自适应基础设施设计模板。与图13相比，其仅具有一个计算机系统，因此，其是集中式的。其示出形式为网络经由防火墙到外部子网的连接的安全特征。这由接口AI_Nic：nicFW示出，并且防火墙由AI_Appliance：FireWall示出。可以设想具有任何配置的其它模板。其它示例可以包括分散式安全SD模板、分散式高度可用SD模板、和分散式安全且高度可用的SD模板。

绑定模型

除物理资源分配之外，SD系统示例的绑定模型实例可以具有诸如子网掩码和MAC地址的其它参数集。已部署模型可以仅在一方面不同于绑定模型。其示出在系统中运行的管理服务的绑定信息。所有实体将具有例如管理服务的形式的管理基础设施。在这里未定义用于到管理服务的接口的实现机制，但是其可以是对例如web服务或SmartFrog组件的引用。管理服务可以用来改变状态以及观察当前状态。在模型的核心中没必要定义由管理服务使得可获得的状态信息、或由其执行的操作，而是可以在相关模型中进行定义。

这样的一个示例可以是管理虚拟机迁移。管理该迁移的应用将使用在PhysicalComputerSystem(物理计算机系统)上运行的管理服务来进行该迁移。一旦该迁移完成，管理应用将更新已部署模型和绑定模型以示出新的物理系统。需要注意保持模型的一致性。所有先前模型实例均被保持在模型仓库中，因此当迁移完成时，将存在绑定模型和已部署模型的新实例(版本)。

信息隐藏和模型信息流

对于MIF而言，情况并不总是所有工具和每个参与者都可以看见模型中的所有信息。特别地，对于具有要求参与者之间的强分离的安全性模型的部署服务而言情况不是这样。例如，在公用设施管理平面与虚拟机群之间可能存在非常强的分离。如果植基模型被馈送到企业的管理平面的部署服务，则其将不会返回示出虚拟机到物理机的绑定的任何绑定信息；该信息将被保持在管理平面内部。这意味着没有办法获知该群被绑定到什么硬件或两个群可能正在共享什么。从管理平面返回的内容很可能包括群中的虚拟机的IP地址(其仅仅处理虚拟机)以及给定群中的那些机器的登录证书。信赖管理平面来管理群，使得其获得所请求的资源。一旦部署服务已完成工作，则可以使用应用安装和管理服务来安装、启动并管理应用。通常，不同的工具将看到MIF的投影。有可能从MIF模型提取这些工具要求的信息并用工具返回的结果填充该模型。将有可能在各种工具使用的数据格式与MIF模型之间变换。

实现方式：

可以使用任何常规的编程语言来实现诸如模型、模型仓库、和用于操纵模型的工具或服务的软件部分，所述语言包括遵循惯例编译的诸如Java、或C的语言。可以使用具有常规处理器的常规硬件来实现服务器和网络元件。处理元件不必是相同的，但应能够例如通过交换IP消息来相互通信。

已出于说明和描述的目的给出了本发明的实施例的前述说明。其并不意图是穷尽的或使本发明限于所公开的精确形式，并且按照以上教导修改和变化是可能的，或者可以从本发明的实践中获得该修改和变化。选择并描述了实施例以便解释本发明后面的原理及其实际应用以使得本领域的技术人员能够在各种实施例中并以适合于预期的特定用途的各种修改利用本发明。可以在权利要求的范围内设想其它变化。

Claims (22)

1.一种建模具有若干功能性步骤的基于计算机的业务过程的方法，该方法具有以下步骤：

提供所述业务过程的多个候选模型，所述模型的每一个指定所述功能性步骤、指定用于执行所述功能性步骤的软件应用组件的布置，以及指定用于运行所述软件应用组件的计算基础设施的设计，以满足给定的非功能性要求，并且适合于自动化部署，

对于每个候选模型，模拟所述业务过程在根据相应候选模型实施的情况下的操作，以及

对于每个候选模型，评估它们的模拟操作满足所述非功能性要求的程度。

2.权利要求1的方法，且具有以下步骤：根据所述评估来选择候选模型之一并且使得所选择的候选模型被部署在物理基础设施上。

3.权利要求2的方法，具有以下步骤：在测试条件下部署一个或多个选择的候选模型，以及测量这些候选模型的测试部署满足非功能性要求的程度。

4.权利要求3的方法，具有以下步骤：选择候选模型之一以在现场生产条件下部署。

5.权利要求3的方法，具有以下步骤：在测试条件下同时部署相同业务过程的多个不同候选模型。

6.权利要求1的方法，具有以下步骤：使用模型管理器来根据候选模型的任何测试部署和模拟的评估来管理模型储存器中的模型。

7.权利要求6的方法，具有以下步骤：使用模型管理器来通过使用模型模板来产生新候选模型并且选择若干参数的值来完成所述新候选模型。

8.权利要求1的方法，所述评估包括评估以下中的任何一个或多个：吞吐量、安全性、成本、等待时间和可靠性。

9.权利要求1的方法，所述模拟包括用测试输入并且使用软件部分和基础设施部分的估计性能参数的集合来计算候选模型的行为和性能。

10.权利要求9的方法，具有以下步骤：根据来自物理基础设施上的部署的测量来适配估计性能参数，这种适配能够改善模拟质量并因此改善未来对于最佳候选模型的搜索的效率和快速性。

11.在机器可读介质上的软件，该软件在执行时实施权利要求1的方法。

12.一种具有由操作员使用用于建模具有若干功能性步骤的基于计算机的业务过程的系统执行的步骤的方法，该系统具有储存器，该储存器布置为存储所述业务过程的多个候选模型，每个所述模型指定所述功能性步骤、指定用于执行所述功能性步骤的软件应用组件的布置以及指定用于运行所述软件应用组件的计算基础设施的设计，以满足给定的非功能性要求，并且适合于自动化部署，该系统还具有模拟器，

所述方法具有步骤：

对于所述候选模型的至少之一，使得模拟器模拟所述业务过程在根据相应候选模型实施的情况下的操作，以及

从该系统接收针对每个候选模型的、它们的模拟操作满足所述非功能性要求的程度的评估。

13.一种用于建模具有若干功能性步骤的基于计算机的业务过程的系统，该系统具有：

储存器，布置为存储所述业务过程的多个软件候选模型，所述模型的每一个指定所述功能性步骤、指定用于执行所述功能性步骤的软件应用组件的布置以及指定用于运行所述软件应用组件的计算基础设施的设计，以满足给定的非功能性要求，并且适合于自动化部署，

模拟器，布置为对于每个候选模型，模拟所述业务过程在根据相应候选模型部署的情况下的操作，以及

评估部，其耦合到模拟器，用于对每个候选模型评估它们的操作满足所述非功能性要求的程度。

14.权利要求13的系统，具有耦合到评估部的模型管理器，用于根据所述评估来选择候选模型之一并且使得所选择的候选模型被部署在物理基础设施上。

15.权利要求14的系统，模型管理器被布置为选择一个或多个候选模型以在测试条件下部署以及测量这些候选模型的测试部署满足非功能性要求的程度。

16.权利要求15的系统，模型管理器被布置为选择候选模型之一以在现场生产条件下部署。

17.权利要求15的系统，被布置为在测试条件下同时部署相同业务过程的多个不同候选模型。

18.权利要求14的系统，具有被布置为根据评估来管理模型储存器中的模型的模型管理器。

19.权利要求18的系统，模型管理器被布置为通过使用模型模板来产生新候选模型并且选择若干参数的值来完成所述新候选模型。

20.权利要求14的系统，所述评估部被布置为评估以下中的任何一个或多个：吞吐量、安全性、成本、等待时间和可靠性。

21.权利要求14的系统，所述模拟器具有用于软件部分和用于基础设施部分的估计性能参数的集合，所述模拟包括利用测试输入并且使用估计性能参数来计算候选模型的行为和性能。

22.权利要求21的系统，被布置为根据来自部署的测量来适配估计性能参数。

Images