CN101946258A - 基于计算机的业务过程在专用硬件上的基于模型的部署 - Google Patents

Abstract

一种由服务提供商管理的基于计算机的业务过程的自动化部署的方法涉及：产生该业务过程的模型(730)，该模型包括计算基础设施的设计；以及将所述模型部署在该企业专用的硬件(770)上，其中用于该服务提供商的接口用以实现所述服务提供商对部署的过程的日常管理。具有专用硬件意味着硬件的位置可以被布置为适宜于该企业。这意味着诸如WAN链路的带宽或等待时间之类的限制可以通过适当地选择专用硬件的位置而解决。与共享数据中心的安全性相比，还可以增加对安全性的信任。自动化的模型驱动部署可以帮助使得服务提供商能够在不同类型的硬件上提供此类部署。减少了企业在内部维持专家专业人员的需要。

Description

基于计算机的业务过程在专用硬件上的基于模型的部署

相关申请

本申请涉及题为“SETTING UP DEVELOPMENTENVIRONMENT FOR COMPUTER BASED BUSINESS PROCESS”(申请人参考编号200702145)、题为“VISUAL INTERFACE FORSYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ONSHARED INFRASTRUCTURE”(申请人参考编号200702356)、题为“MODELLING COMPUTER BASED BUSINESS PROCESS FORCUSTOMISATION AND DELIVERY”(申请人参考编号200702363)、题为“MODELLING COMPUTER BASED BUSINESS PROCESS ANDSIMULATING OPERATION”(申请人参考编号200702377)、题为“AUTOMATED MODEL GENERATION FOR COMPUTER BASEDBUSINESS PROCESS”(申请人参考编号200702600)、和题为“INCORPORATING DEVELOPMENT TOOLS IN SYSTEM FORDEPLOYING COMPUTER BASED PROCESS ON SHAREDINFRASTRUCTURE”的共同待决美国申请、以及题为“DERIVINGGROUNDED MODEL OF BUSINESS PROCESS  SUITABLE FORAUTOMATIC DEPLOYMENT”(序列号11/741878)的先前提交的美国申请，上述申请全部整体地通过引用结合到本文中。

技术领域

本发明涉及由服务提供商管理的基于计算机的业务过程(businessprocess)的自动化部署的方法，并且涉及对应的系统和软件。

背景技术

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

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

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

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

在DMTF的用于“System Virtualization，Partitioning andClustering”的简档：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工具)。其依赖于模型的人类输入。

发明内容

目的是提供改进的装置或方法。在一个方面，本发明提供了：

一种由服务提供商管理的用于给定企业的具有若干功能性步骤的基于计算机的业务过程的自动化部署的方法，该方法具有以下步骤：

产生该业务过程的模型，该模型具有用于实施所述功能性步骤的软件应用组件的布置的表示，并且具有用于在指定的企业专用硬件上运行所述软件应用组件的计算基础设施的表示，并且适用于自动化部署，以在存在任何给定的非功能性要求的情况下满足给定的非功能性要求，以及

将所述模型部署在该企业专用的硬件上，其中用于该服务提供商的接口用以实现所述服务提供商对部署的过程的日常管理。

通过给出企业专用硬件而不是如常规数据中心中那样使用共享硬件，服务提供商可以提供内部服务的一些优点与外包的服务供应的优点的组合。例如，企业可以减少或控制不得不使用集中式数据中心中的共享硬件的一些限制。例如，具有专用硬件意味着硬件的位置可以被布置为适宜于该企业。这意味着诸如WAN链路的带宽或等待时间之类的限制可以通过将专用硬件的位置选择成位于企业场地上或附近而解决。与共享数据中心的安全性相比，具有专用硬件还可以增加对安全性的信任。这例如可以通过该企业能够控制对例如专用硬件和数据的物理访问而得以解决。这些益处由自动化的模型驱动部署来促进，自动化的模型驱动部署可以帮助使得服务提供商能够在不同类型的硬件上提供此类部署而较少需要技术人员并且可以减少集中定位硬件的需要。这还减少了企业在内部维持专家专业人员的需要。该服务提供商还可以通过将一些负荷(就计算和功耗而言)分布到在服务提供商的数据中心外部操作的硬件上而减少共享数据中心中的资源上的负荷来获益。

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

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

另一方面提供了一种用于由服务提供商管理的用于给定企业的具有若干功能性步骤的基于计算机的业务过程的自动化部署的系统，该系统具有：

模型生成部，布置为产生该过程的模型，该模型具有用于实施所述功能性步骤的软件应用组件的布置的表示，并且具有用于在企业专用硬件上运行所述软件应用组件的计算基础设施的表示，并且适用于自动化部署，以在存在任何给定的非功能性要求的情况下满足给定的非功能性要求，以及

部署部，布置为提供所述模型在该企业专用的硬件上的自动化部署，其中用于该服务提供商的接口用以实现所述服务提供商对部署的过程的日常管理。

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

附图说明

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

图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示出了根据另一实施例的系统。

具体实施方式

定义

“企业专用硬件”包含诸如物理服务器、存储装置和通信链路之类的硬件，其专用于该企业并且因此其位置可以由该企业选择。其不需要被该企业所拥有，其可以被租用或作为服务成本的一部分而以任何方式对其支付费用。除非企业准许，其不能被重新分配或移除。该硬件的各部分的组成组件和标识符一般可以由服务提供商改变以满足企业的需要。企业可以准许服务提供商允许其他企业暂时地利用空闲容量。

“非功能性要求”可以包含在诸如性能、安全性、成本、可用性及其他方面将功能性步骤实现得多好。其在非功能性要求的维基百科(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、或基于图形表示的方案。

附加特征

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

专用硬件的位置可以远离服务提供商并且接口可以被布置用于远程管理。这有助于远离服务提供商位置处的资源来分布负荷并且放宽带宽和等待时间限制，如果专用硬件的位置在企业场地处或在企业的本地可信互联网服务提供商处则尤其如此。

计算基础设施可以包括虚拟化实体。这是一种增加资源分配灵活性并且因而实现资源使用的改进效率的方式。

该模型可以合并适当大小的冗余硬件容量以使得能够在该过程仍在运行的同时将虚拟化实体离开它们的对应硬件组件而移动到冗余硬件上。该冗余性通常将不需要被包括在用于部署在共享数据中心中的模型中，因为数据中心管理在共享的基础上提供冗余容量。冗余容量还可以用于支持由于功能性步骤的改变而引起的负荷增加或负荷增长。

该系统可以具有更新部，所述更新部被布置为使得企业能够输入对功能性步骤或非功能性要求的更改，并且使得模型生成部基于该更改产生更新的模型，并且确定与更改的功能性步骤或非功能性要求对应的对专用硬件的要求的任何改变。

该系统可以具有下载部，以下载至少模型生成部从而在企业位置处运行。这可以帮助分布处理，以减少服务提供商处的资源上的负荷，并且例如可以通过使得企业能够避免发送敏感数据到服务提供商而减少安全性顾虑。该模型可以具有监视部以监视使用中的所部署过程的行为并且通过接口发送该行为的指示给服务提供商。这可以使得服务提供商能够监视所部署过程并且采取适当的动作。基本等级的服务可能涉及向企业报告。较高等级的服务可以涉及采取动作以处理基础设施故障或例程升级。更高等级的服务可以涉及分析该行为并且确定对该模型的建议改变以改进计算基础设施与所监视行为的匹配。这例如可以改进资源使用的效率或找到改进对功能性步骤的要求改变或时变需求进行响应的灵活性的机会。

模型生成部可以被布置为选择计算基础设施设计的若干预定模板之一、选择参数以填充所选的模板、通过模拟操作来了解满足非功能性要求的程度而评估填充的模板、并且根据所述评估更改模板的选择或更改所述参数。基础设施设计模板的这种使用可以减少要评估的选项的数量并且可以帮助减少产生可以部署的且高效使用资源的模型的任务的复杂性。这进而可以帮助实现更高度自动化的方法或者可以使得能够更高效地部署和更高效地管理更复杂的商业过程。在基础设施包括虚拟化实体的情况下，增加的灵活性往往增加基础设施设计的任务的复杂性，并且使用模板在这种情况下变得甚至更加适当和有价值。

该系统可以具有包括以下中的任何一个或多个的非功能性要求：并发用户的数量、功能的吞吐量、希望响应时间的指示、可用性等级、安全性等级、以及可获得的可用专用硬件的限制。这些对于计算基础设施的设计通常是重要的。

该系统可以被布置为根据模型确定对于专用硬件的要求的规范。这可以使得能够在部署之前设置适当的硬件。如果专用硬件是预先存在的，其他权利要求所涵盖的替换方案将是在非功能性要求中对要求专用硬件的性能设置限制。然后该模型将被约束为保持在这样的限制内以使得该模型可以被成功地部署在预先存在的硬件上。

在与游戏服务器一起提供3-D视觉接口以使得多个用户能够在相同的模型上工作并且看到彼此的改变的情况下，开发者能够更快地导航复杂模型。对于此示例的更多细节请参考上面提及的共同待决的申请号200702356。将此与使用具有到服务提供商的接口以实现日常管理的企业专用硬件组合可以使得能够更高效地提供这样的日常管理。

可以提供企业接口以使得企业能够彼此独立地定制非功能性要求。对于此示例的更多细节请参考上面提及的共同待决的申请号200702363。将此与使用具有到服务提供商的接口以实现日常管理的企业专用硬件组合可以实现按照企业需要的更完整定制。

在商业过程的操作可以被模拟的情况下或在多个测试部署可以并行进行的情况下，可以加速部署。对于此示例的更多细节请参考上面提及的共同待决的申请号200702377。将此与使用具有到服务提供商的接口以实现日常管理的企业专用硬件组合可以使得能够增强二者的优点。

在将注释插入源代码中以辅助建模或文档资料编制的情况下，那么可以使得对改变的历史进行文档记录更容易。对于此示例的更多细节请参考上面提及的共同待决的申请号200702600。

设置开发环境可以通过提供哪些工具适合于给定开发目的和给定模型部分的预定映射或通过包括与该模型一起部署的工具的模型来促进。对于此示例的更多细节请参考上面提及的共同待决的申请号200702145和200702601。因为使用具有到服务提供商的接口的企业专用硬件可能增加设置开发环境的复杂性，所以促进此类设置更加有价值。

基于模型的方法

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

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

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

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

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

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

问题陈述

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

可以在4个互连层对企业系统建模：

●物理基础设施

●虚拟基础设施

●软件布局(landscape)，对应于诸如上面提到的应用元素的软件实体

●业务过程

该模型称为企业系统模型。在每一层，其由两个模型集合组成-自动化模型和文档模型。

·自动化模型描述了系统的结构和行为，并且用于自动产生、评估、部署和修改企业系统的设计。在这四个层的每一层处的来自部署的物理系统的监视数据可以与建模的行为相关并用于基于实际测量做出运行时间管理决策。

自动化模型由两个子模型组成-静态模型和操作模型。静态模型描述系统的静态结构-企业系统的候选设计的选择和配置选项。操作模型描述基础设施和软件的内部结构、运行时间操作以及性能需求(诸如CPU、存储器、盘或网络I/O)。是这些操作模型允许模拟和评估候选设计将在多大程度上满足系统的非功能性要求。

文档模型包含可以被提取并变换成系统的文档资料的有价值源的信息。对文档模型有贡献的该信息可以与自动化模型中的实体密切相关联。该文档资料可以由人类用来针对功能正确性以及针对诸如性能的非功能性行为理解和检查系统的结构和操作行为。文档资料还可以用于训练和教育目的。文档资料的示例包括：

●业务过程步骤的UML图。

●业务对象的功能、它们的接口以及副作用的描述

●软件应用就组成软件组件而言的内部静态结构的UML图。

●软件组件之间的交互的活动图。

来自监视和报告服务的输出还可以被分类为文档模型的特殊情况，以人类可读形式描述系统的运行时间行为和性能。企业系统非常复杂，并且建模技术下面的模型对应地复杂并且难以创建。这些模型可以随着修改、修补和重新设计系统而随时间改变。此外，这些模型可以依赖于特定系统内包含的实际数据和配置以及观察的运行系统的行为。

一般而言，所需模型的详细结构和参数的大部分太复杂且是动态的而不能由人类及时地手动产生。本发明解决的问题是如何自动地产生自动化和文档模型的至少一些部分。模型中的信息必须是一致的且相关的-在系统的一个部分中的活动必须可跟踪并且与有关活动相关。例如，活动A可以导致一连串的其他活动B、C和D；希望这些关系可以在运行时间被表示并且被捕获在模型中。

自动设计和管理企业系统的基于模型的技术-参见Brand等人的“Adaptive Infrastructure meets Adaptive Applications”，其公布为外部HP实验室技术报告：http://www.hpl.hp.com/techreports/2007/HPL-2007-138.html并且在此引入以供参考-可以提供自动设计、部署、修改、监视和管理用以实施业务过程的运行系统同时最小化对人类介入的要求的能力。

这些实施例涉及提供自动产生企业系统的所需自动化模型的关键方面以及由人类用来理解和分析该系统的附加文档模型的机制。

实施例涉及配置用于企业应用计算器具(appliance)的企业应用解决方案。这可包括接受企业应用系统的定制描述并且将其部署到硬件(也称为器具)。该器具在一些情况下可以使用虚拟化特征进行专门设计以实现企业应用和器具的日常和远程管理，并且可以被测试性能以验证满足所请求的服务等级。该器具可以例如在企业场地或企业选择的ISP处运行。企业想要具有是在共享的环境内还是在运行在他们选择的位置处的企业应用器具内操作企业应用的选择。

这种方法给想要企业应用但更喜欢外包管理(即与必要时的现场维护结合的远程管理)的企业提供了选择。提供应用器具的供应商需要提供正确量的容量，太多或太少会造成额外的成本，风险可能妨碍企业应用器具的成功。在交付之前为支持企业的非功能性要求而验证的企业器具可能导致更大的企业信任。

例如与虚拟机迁移一起使用虚拟化基础设施更好地支持远程维护，例如新硬件可以被引入并且在不关闭应用的情况下迁移到它的虚拟机(例如新版本的软件)可以在操作软件的任何升级之前被部署在器具中并进行测试。用企业应用服务自动地部署管理服务可以更好地实现一致的远程管理并促进必要时的现场维护。

这种基于模型的配置与手动进行的配置相媲美，手动进行的配置可能导致企业应用环境的差异，所述差异增加了远程管理的复杂性。

手动部署而非自动化的基础设施可以意味着基础设施的特定部分的确定大小(sizing)的方法是专门的，增加了器具中不正确量的容量的风险。目前，即使企业想要在本地或在某种其他设施中操作企业应用器具，服务提供商也仅提供共享环境中的主控。

可能产生的一些优点包括如下：

可以经由自动化技术而不是经由稀少的有经验的人类顾问来提供定制解决方案。企业可以在本地或在任何他们希望的位置处主控解决方案，从而减少了对广域网和应用服务提供商的依赖性。来自多个供应商的企业应用服务的组合可以被提供在单个器具上。远程和现场服务的组合可以减少企业在本地主控他们的服务所需的内部技术人员。单个企业器具与大型数据中心相比对公共电力网施加不那么集中的功率和冷却负担。

示例：实施例的操作

A：企业指定系统的要求。

B：设计适当的基础设施以支持该系统及其管理。

C：将该基础设施再现(render)到企业应用器具并且部署企业和管理服务。

D：经由测试确认满足非功能性要求。

E：将企业器具运送到企业。

F：企业将器具连接到网络以供用户使用以及用于远程管理。

G：按照需要连续地应用远程和现场管理并且实施企业要求的改变。

步骤A：企业使用一个或多个配置工具来指定和配置企业应用服务的正当组合。企业应用服务可以由企业应用服务供应商、ISV(因特网服务供应商)提供或是该申请中给出的整体框架所容许的定制。

配置工具可以由企业应用软件供应商或ISV和/或企业应用提供商提供。

步骤B：为企业应用设计虚拟化基础设施，其可以被主控在企业应用器具上。企业指定系统和/或其服务的非功能性要求

--例如性能、安全性、可靠性、可维护性。

设计服务为特定企业应用器具推荐支持非功能性要求的基础设施设计的配置。基础设施设计包括为支持维护(即过渡到软件的新版本)而对防火墙、web服务器、应用服务器、数据库服务器、其他种类的服务器、附加的管理软件、硬件的支持，其可以包括多个服务器和联网支持。

步骤C：将应用和管理服务再现到虚拟化基础设施。将虚拟化基础设施再现到形式为适当大小的应用器具的企业专用硬件。这可以是适合业务过程的需要的任何大小，并且在典型的示例中是服务器或一机柜的服务器。诸如到服务提供商的远程管理接口的企业应用和管理服务被部署到器具上的基础设施。

步骤D：进行确认测试以证实对非功能性要求的支持。进行测试以确保每个非功能性要求被满足。如果适当的话，调谐机制被用于使得能够满足这些要求。

步骤E：将配置的器具运送到企业应用器具的企业希望位置。配置的器具被运送到企业应用器具的企业希望位置。该位置可以位于企业场所、位于企业选择的主控场所等，其是共同认为对于企业和对于企业应用器具提供商可接受的任何位置。

步骤F：企业仅需要开启该器具并且将其连接到网络以供用户使用。在所有情况下远程管理服务管理和维护企业应用器具。在其他实施例中该器具首先被运送并且被远程配置。

步骤G：企业应用和器具的日常远程管理/维护。远程维护可以包括对以下项的支持：

--硬件和软件故障

--软件和硬件升级和添加

--安全性

--容量规划

--数据库维护

--识别何时需要现场维护并且为其安排时间

现场维护可以包括对以下项的支持：

--硬件故障管理和硬件升级

--远程未成功实现的服务

企业可以改变系统的要求-例如，添加/移除由企业应用器具支持的服务或修改非功能性要求。这些改变的影响由远程管理服务评估并且远程以及(如果需要的话)现场管理动作的组合被执行以实施这些改变。

图16-21，本发明的实施例

图16示出了本发明实施例的一些主要部分。其在左侧示出了企业侧项目并且在右侧示出了服务提供商侧项目。企业接口710用于传递希望业务过程的非功能性要求和功能性步骤到服务提供商侧。这里，模型生成部720产生业务过程的模型730。这可以存储在企业侧或服务提供商侧。其可以具有分层结构，其中具有用于实施功能性步骤的软件应用组件的布置以及用于运行软件应用组件以满足非功能性要求的计算基础设施的设计。模型生成部的实施方式的更多细节在下面参考模型信息流和图1-15示出。在图16中还示出了部署部740，部署部740位于企业侧或服务提供商侧。这创建了由部署的建模软件应用组件和计算基础设施形成的部署的业务过程750。这形成在企业专用硬件770上。来自部署业务系统的监视数据可以被反馈到远程管理服务部700。管理服务712被提供在服务提供商侧以经由对应的远程管理服务部700与企业侧通信。这提供了接口以使得服务提供商能够管理企业侧的活动。这些服务提供商侧部分一般是在形式为共享数据中心资源780的硬件上运行的软件部分。

如图17所示，在操作中图16的系统的步骤的示例开始于在步骤805接收来自企业的输入。这可以包括非功能性要求、以及诸如业务过程的功能性步骤(或例如来自目录的预定步骤的选择)和服务等级协定(如果需要的话)之类的其他项目。在步骤815实施功能性步骤的软件应用组件的模型由模型生成部产生。这可以以各种方式实施，并且下面参考图1-15来更详细描述示例。

在步骤825，产生用于运行软件应用组件的计算基础设施的模型。这可以是物理基础设施、虚拟化基础设施或一般地二者的混合，一些物理基础设施用于运行组件并且一些用于主控虚拟化基础设施。所有都被设计为满足非功能性要求。从让操作员做决策但是由设计服务软件(诸如下面更详细描述的设计模板方法)提示和引导的意义上说，该设计可以是半自动化的。在步骤835，设置企业专用硬件以匹配模型的要求。在步骤845，将该模型部署在物理基础设施上，用到服务提供商的接口来使之完整。这有助于实现在步骤855提供的对部署的过程的日常管理。

图18示出了具有测试的根据另一实施例的步骤。在步骤800根据功能性步骤和非功能性要求产生模型。在步骤810优选地产生和输出专用硬件的规范。在步骤820根据所述规范设置硬件以进行测试。在步骤830将模型部署在专用硬件上。在步骤840其可以被测试以验证其满足非功能性要求。专用硬件可以在服务提供商的位置进行测试。如果是，在测试之后将业务过程部署在其上，在步骤850可以将其移动到企业选择的位置。在那里，在步骤860应该设置远程管理，并且可以在步骤870激活业务过程。

图19示出了根据另一实施例的针对现有专用硬件的步骤。在步骤900，根据功能性步骤和非功能性要求并且根据现有企业专用硬件的限制来产生模型。在步骤910将模型部署在现有专用硬件上。在步骤920可以设置远程管理。在步骤930，可以使用远程管理部对其进行测试以验证其满足非功能性要求。在步骤940，企业建议对功能性步骤或非功能性要求的改变。这些被传递到模型生成部。服务提供商使用该部来产生具有对基础设施设计或软件应用组件的修订的修订模型，以实施建议的改变。在步骤970可以在数据中心处实施测试部署，并且在步骤972使用远程管理部来发送所述修订并且部署它们。

图20示出了另一实施例，其示出了更新部的动作，更新部可以是远程管理服务的一个部分。对于诸如企业、软件供应商、或服务提供商之类的任何方提示的改变，更新部在步骤975确定应该修订哪些建模实体。这可以是模型的较低层或较高层中的部分。这些改变可以是在开发期间或在现场过程的日常管理期间。更新部在企业处或在服务提供商位置处创建测试环境。在以上引用的共同待决的案子‘2145和‘2601中更详细地示出了设置测试环境的可能方式。更新部在步骤985根据基础设施设计模板在测试环境中产生改变的测试部署。如果这些改变被验证为可允许，满足模板要求，则更新部将在步骤987使这些改变被实施。

图21示出了类似于图16的实施例的另一实施例。酌情使用类似的参考数字。此外，一些部分位于企业本地的ISP(因特网服务提供商)处。在这个视图中位于ISP处的部分被示出在图的中心处。企业接口仍位于企业处。远程管理服务、模型生成部、模型储存器和部署部位于ISP处，不过它们可以位于其他地方，诸如位于服务提供商位置处。企业专用硬件是ISP硬件771的一部分。因此，由部署的建模软件应用组件和计算基础设施形成的部署的业务过程750形成在ISP硬件771上。这里还示出了测试环境717，该测试环境在服务提供商的位置处，使得其不占用ISP资源。

源内容

企业应用的软件可以通过各种源内容来描述。通常，该源内容为企业应用供应商所拥有，企业应用供应商还将负责添加模型标记注释。可以存在几种形式的源内容，诸如：

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

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

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

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

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

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

模型信息流

所得的计算模型可以用于使系统的模拟、评估和设计自动化。

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

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

接下来，设计计算基础设施，诸如虚拟机、操作系统、和底层硬件。这可以使用在下文和在通过引用结合到本文中的上文提及的先前提交的申请序列号11/741878“Using templates in automatedmodel-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。此设计然后也可以被管理系统部署为在实际自适应基础设施上运行。

该管理系统具有到基础设施管理操作员200的视觉接口，其可能具有3D视觉表示，如在上面引用的对应的共同待决申请中描述的。该操作员可以是服务提供商人员，或在一些情况下可以是拥有该过程的企业的经过培训的人员。服务提供商人员可以能够查看和管理在共享基础设施上部署的不同业务的过程。给定企业的操作员将能够查看和管理仅仅他们自己的过程。如上所述，接口可以耦合到管理系统210以使得操作员能够与各种类型的模型交互以及与基础设施设计模板交互。

自适应基础设施可以包括管理基础设施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/3 Enterprise的SD(销售和分销包)中的称为VA01的SAP事务。另一示例可以是特定的web服务(在应用服务器中运行)。

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

关系BPStepsToApplicationComponentMapping(BPStep到应用组件映射)是详细描述BPStep被如何映射到Application Component(应用组件)的复杂映射。其以精简形式表示BPStep对ApplicationComponent(应用组件)的调用的潜在复杂混合物，诸如在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：“SDBenchmark”，其中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/3 ENTERPRISE包含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(调用类型)：如果调用程序被阻止，则同步；如果调用程序可以立即继续活动，则异步。

·BP StepToAppCompID：其为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 (19)

1.一种由服务提供商管理的用于给定企业的具有若干功能性步骤的基于计算机的业务过程的自动化部署的方法，该方法具有以下步骤：

产生该业务过程的模型，该模型具有用于实施所述功能性步骤的软件应用组件的布置的表示，并且具有用于在指定的企业专用硬件上运行所述软件应用组件的计算基础设施的表示，并且适用于自动化部署，以及

将所述模型部署在该企业专用的硬件上，其中用于该服务提供商的接口用以实现所述服务提供商对部署的过程的日常管理。

2.权利要求1的方法，专用硬件的位置远离服务提供商并且该接口被布置用于远程管理。

3.权利要求2的方法，计算基础设施包括虚拟化实体。

4.权利要求3的方法，具有提供冗余硬件容量的步骤，所述冗余硬件容量被确定大小为使得能够在部署的业务过程仍在运行的同时将建模的业务过程的虚拟化实体离开它们的对应硬件组件而移动到冗余硬件上

5.权利要求2的方法，具有以下步骤：从企业接收对功能性步骤或非功能性要求的更改，以及基于所述更改产生更新模型，以及确定对应于所述更改的对专用硬件的要求的任何改变。

6.权利要求2的方法，具有下载至少模型生成部以在企业位置处运行的步骤。

7.权利要求1的方法，具有监视使用中的部署的过程的行为并且通过所述接口发送该行为的指示到服务提供商的步骤。

8.权利要求1的方法，具有以下步骤：选择计算基础设施设计的若干预定模板之一，选择参数以填充所选的模板，通过模拟操作来了解满足任何非功能性要求的程度而评估填充的模板，并且根据所述评估更改模板的选择或更改所述参数。

9.权利要求1的方法，具有根据模型确定对专用硬件的要求的规范的步骤。

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

11.一种用于由服务提供商管理的用于给定企业的具有若干功能性步骤的基于计算机的业务过程的自动化部署的系统，该系统具有：

模型生成部，布置为产生该过程的模型，该模型具有用于实施所述功能性步骤的软件应用组件的布置的表示，并且具有用于在指定的企业专用硬件上运行所述软件应用组件的计算基础设施的表示，并且适用于自动化部署，以及

部署部，布置为提供所述模型在该企业专用的硬件上的自动化部署，其中用于该服务提供商的接口用以实现所述服务提供商对部署的过程的日常管理。

12.权利要求11的系统，专用硬件的位置远离服务提供商并且该接口被布置用于远程管理。

13.权利要求12的系统，计算基础设施包括虚拟化实体。

14.权利要求13的系统，该模型合并了冗余硬件容量以使得能够在该过程仍在运行的同时将虚拟化实体离开它们的对应硬件组件而移动到冗余硬件上

15.权利要求12的系统，具有更新部，所述更新部被布置为使得企业能够输入对功能性步骤或非功能性要求的更改以及使得模型生成部基于所述更改产生更新模型，并且确定对应于更改的功能性步骤或非功能性要求的对专用硬件的要求的任何改变。

16.权利要求12的系统，具有下载部以下载至少所述模型生成部来在企业位置处运行。

17.权利要求11的系统，该模型被布置为合并了监视部以监视使用中的部署过程的行为并且通过所述接口发送该行为的指示到服务提供商。

18.权利要求11的系统，该模型生成部被布置为：选择计算基础设施设计的若干预定模板之一，选择参数以填充所选的模板，通过模拟操作来了解满足任何非功能性要求的程度而评估填充的模板，并且根据所述评估更改模板的选择或更改所述参数。

19.权利要求11的系统，布置为根据模型确定对于专用硬件的要求的规范。

Images