CN105051681A

CN105051681A - 利用平台层协调应用程序部署

Info

Publication number: CN105051681A
Application number: CN201380075000.1A
Authority: CN
Inventors: 特拉维斯·S·特利普; 凯文·L·威尔逊; 约瑟夫·保罗·雷韦斯
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2013-04-30
Filing date: 2013-04-30
Publication date: 2015-11-11
Also published as: US20160062754A1; EP2992415A1; WO2014178845A1; EP2992415A4

Abstract

利用平台层协调应用程序部署包括分配具有匹配应用程序请求的至少一些能力的平台层，所述应用程序请求针对嵌入应用程序层中的应用程序；将应用程序部署到平台层；以及利用所述能力在平台层中的应用程序上执行开发任务。

Description

利用平台层协调应用程序部署

背景技术

应用程序开发是以有计划的且有结构的过程对应用程序产品的开发。开发的阶段可以包括概念化、开发用于执行应用程序功能的程序指令、质量保证、以及生产。应用程序开发的不同方法将不同数量的资源用于这些阶段中的每个阶段。此外，应用程序开发的不同方法可以包括比上述那些阶段更多或更少的阶段。应用程序的开发可以采取严格的结构方法或者可以是更加灵活的方法，在该更加灵活的方法中，应用程序的部分被逐渐开发，直到应用程序准备使用。

附图说明

附图图示了本文描述的原理的各种示例并且是说明书的一部分。所图示的示例仅仅是示例性的并且不限制权利要求的范围。

图1是根据本文描述的原理的网络上的协调系统的示例的示意图；

图2是根据本文描述的原理将应用程序部署到平台层的示例的示意图；

图3是根据本文描述的原理的能力库的示例的示意图。

图4是根据本文描述的原理用于利用平台层开发应用程序的方法的示例的示意图；

图5是根据本文描述的原理的协调系统的示例的示意图；

图6是根据本文描述的原理的协调系统的示例的示意图；

图7是根据本文描述的原理用于利用平台层开发应用程序的过程的流程图的示例的示意图。

具体实施方式

通常，不同的开发产品用在应用程序开发的不同阶段。这些不同的产品能够使用不同的硬件、操作系统、中间件、以及其它程序。因此，可以多次改写应用程序以适应在这些阶段中的每个阶段所使用的开发产品的差异。本文描述的原理包括用于开发应用程序的机制，以使各个阶段使用一致的资源，该一致的资源减少或消除了改写应用程序代码的次数以适应在不同开发阶段期间所使用的产品。根据本文描述的原理，在应用程序被部署至开发的下一个阶段之前，应用程序开发人员能够描述他们的应用程序以及其依赖关系(例如操作系统、硬件参数、中间件等)。通过预先对规定以及应用程序参数进行定义，能够开发用于每个阶段的开发环境以适应这些规定和参数。因此，开发人员能够从开发的一个阶段过渡至下一个阶段，而不需要复制仅仅具有较小差异的应用程序。因此，简化和减少了应用程序开发过程。

这些原理包括用于利用平台层开发应用程序的方法。这种方法包括分配具有匹配应用程序请求的至少一些能力的平台层，该应用程序请求针对嵌入应用程序层中的应用程序；将应用程序部署到平台层；以及利用平台层中的能力在应用程序上执行开发任务。

在下述说明中，为了解释的目的，为提供对本系统和方法的彻底理解，提出了多个具体细节。然而，对本领域技术人员来说显而易见的是，在没有这些具体细节的情况下，也可以实践本装置、系统以及方法。在说明书中对“示例”或类似语言的引用意味着在至少该一个示例中包括所描述的特定特征、结构、或特性，但是不必包括在其他示例中。

图1是根据本文描述的原理的网络上的协调系统的示例的示意图。在该示例中，客户设备(104)与网络(102)通信，其中网络(102)与协调系统(100)通信。

客户设备(104)可以是用户能够用来与协调系统(100)通信的任何适当的设备。例如，客户设备(104)可以是膝上型电脑、个人计算机、台式机、电话、电子图形输入板、电子设备、另一种类型的客户设备或者其组合。

用户可以将请求发送到与处于开发的某个阶段的应用程序相关的协调系统(100)。这些请求可以包括应用程序的依赖关系，例如，应用程序当前兼容的操作系统、应用程序当前兼容的程序、应用程序当前兼容的硬件和中间件等等。请求还可以包括期望利用协调系统(100)对应用程序执行的开发任务和/或动作。此外，请求可以包括层次信息、遍历顺序信息、值信息、属性信息、其它类型的信息，或者其组合。

协调系统(100)包括至少一个平台。平台包括一个或多个层。每个层由一组服务器组成，该组服务器能够设置成使用公共的操作系统和/或公共的程序。被发送到协调系统(100)的请求与协调系统(100)的平台层的现有能力进行比较。如果平台层已经具有将满足应用程序的请求的能力，则该应用程序被分配到该平台层。如果当前没有平台层具有满足应用程序的请求的能力，则选择要被分配到应用程序的平台层中的一个。平台层所缺少的能力被从由协调系统(100)可使用的资源应用到平台层。在一些示例中，资源被包含在协调系统(100)内，例如在能力库中。在其他示例中，能力通过网络连接由协调系统(100)使用。

协调系统(100)能够利用识别标签跟踪每个平台层的能力。用户请求的每个能力能够与能力库中的识别标签关联。因此，响应于从用户获取关于应用程序的请求，协调系统(100)能够搜索与应用程序的各个请求相匹配的平台层中的标签。

在其他示例中，协调系统能够通过客户设备(104)向用户提供平台层能力。在这种示例中，用户能够确定哪个平台层匹配或至少部分匹配应用程序。在另一些示例中，客户设备(104)可用的程序代表用户确定哪个平台层匹配或至少部分匹配应用程序的请求。

响应于将应用程序分配到平台层，应用程序被部署到平台层。所部署的应用程序能够进一步在平台上由用户自由开发。本文描述的原理允许用户致力于开发应用程序的结构，而不必为了下一个阶段的开发重新格式化应用程序。通过确定在开发的进一步阶段中能够使用何种应用程序，对平台层进行定制以适合应用程序的参数，而不是必须改变应用程序以适合平台的状态。因此，能够避免创建多个版本的应用程序。此外，开发的后期阶段也能够使用平台层，该平台层已经包含应用程序所请求的能力。因此，整个开发阶段被简化，从而减少和/或消除了重新格式化应用程序的冗余，进而适合后期开发阶段中使用的不同开发产品的状态，后期开发阶段中使用的不同开发产品不能与应用程序的开发的早期阶段的产品完全兼容。

图2是根据本文描述的原理将应用程序(200)部署到平台层(202)的示例的示意图。在该示例中，应用程序模型(201)具有应用程序层(204)中包含的应用程序(200)。应用程序层(204)还包括应用程序依赖关系(206)以及与应用程序(200)关联的机器可读指令(208)。应用程序的依赖关系(206)可以包括请求，例如操作系统请求(210)和硬件组件请求(212)。虽然在图2的示例中没有描述，但应用程序依赖关系(206)可以包括其他依赖关系。例如，应用程序层(204)可以包括层次请求、值请求、属性请求、遍历顺序请求、动作模型请求、其它类型的请求，或者其组合。协调系统(214)包括平台(216)以及至少一个平台层(202)。平台层(202)具有操作系统能力(220)、程序指令能力(222)、以及其它能力(224)。进一步地，响应于协调系统(214)将应用程序分配给平台层(202)，来自应用程序层(204)的应用程序(200)被部署到平台层(202)以创建所部署的应用程序(226)。此外，平台层(202)与能力库(218)通信，该能力库能够识别能力并将能力应用到平台层(202)。

根据本文描述的原理，应用程序模型(201)描述了应用程序(200)的逻辑安装和配置单元。配置单元被称为层。虽然图2的示例仅包括应用程序层(204)，但是应用程序模型(201)可以包括其他的层，例如web层或数据库层。通过这些层上定义的操作(例如，部署操作、取消部署操作、启动操作、停止操作等等)来管理这些层。这些层中的每个层能够定义其依赖关系，例如硬件兼容性、操作系统兼容性、中间件兼容性、其它兼容性、或者其组合。应用程序模型(201)还描述了层之间以及与外部服务的基本连接信息。

平台(216)描述了创建部署环境的方式，部署环境与来自应用程序模型(201)的一个或多个应用程序兼容。平台(216)由一个或多个层组成。层是一个或多个提供同一操作系统和程序指令的服务器的群组。层的服务器和程序指令还驻留在公共的网络配置中。每个层描述了其提供的能力。能力可以来自底层基础设施或者在基础设施提供之后被部署。

在用户想要对部署建模时，用户能够创建部署拓扑以将应用程序(200)部署到平台，该平台的层提供应用程序层请求的依赖关系。应用程序层(204)还可以将负载策略、监控策略、以及其它策略附加到所部署的应用程序(226)和平台层(202)。该拓扑模型表示实现应用程序的部署的一种可能方式。

用户具有经由像Chef的开发产品将公共的部署能力应用到平台的能力。Chef是由位于美国华盛顿西雅图的Opscode股份有限公司开发的配置管理工具。应用部署能力允许应用程序部署模型专注于模型层的结构和每个部署的输入。这种机制并不会直接将应用程序(200)绑定到任何具体拓扑或平台，这在开发的后期阶段在不必创建冗余版本的应用程序的情况下，给予用户开发应用程序而受较少限制的额外的自由。

通过加标签能够完成对能力的应用。每一种能力与标签关联。因此，识别为在平台层中缺少的能力能够通过调用适当的标签而被启用。对能力的应用可以包括将能力下载到平台层。在其它示例中，对能力的应用包括通过网络连接使得平台层可访问所述能力。

能力以开放的元数据定义语言被书写并且包括能够满足来自应用程序层的潜在请求的信息或功能。在某些情况下，能力可以包括层次能力。例如，Ubuntu是通过其总部在英国伦敦的Canonical公司可使用的操作系统。层次能力可以提供信息以指示Ubuntu能够从Linux继承的所部署的应用程序，Linux是另一种操作系统，通过位于马萨诸塞州波士顿的自由软件基金会的开放通用公共许可证经由多个供应商可获得该另一种操作系统。此外，该能力可以是遍历能力。例如，能力可以包括指示Java6(其是Java平台)优先于Java7(Java平台的后期版本)的信息。能力还可以是值。例如，能力可以是存储在存储器中的值。能力可以具有可用属性，例如安装目录或其它类型的目录。此外，能力可以包括能够执行来自应用程序层的所请求的动作的动作模型。例如，动作模型可以包括部署模型、重新配置模型、其它类型的模型、或者其组合。一些能力可以是在对象上标注元数据的方式，并且一些能力可以具有高级功能。

虽然参考具体类型的能力以及这些类型能力的具体示例已经描述了该示例，但是根据本文描述的原理，能力库(218)能够具有任何适当数量或任何适当类型的能力。而且，在能力类型内，根据本文描述的原理，可以使用能力的任何适当重复。在一些示例中，通过具有适当管理权限的用户能够修改能力库(218)。

在应用程序模型或协调系统中的许多模型对象可以规定其期望或已经提供的能力。例如，应用程序层(204)能够定义其将要请求的能力。类似地，平台层(202)能够描述其已经具有的能力。

平台层(202)可以与要被允许具有能力的应用程序层(204)订立执行契约。因此，响应于从能力库(218)接收请求，平台层(202)可有责任对应用程序层(204)提供能力。例如，虚拟机器映像可以具有作为操作系统的Windows8。在此示例中，基于该虚拟机器映像的平台层将继承Windows8的能力并且相应的标签能够用于搜索和匹配。在另一个示例中，可以为包括JAVA＿HOME属性的Java7创建能力标签。响应于平台层被设置成包括Java7，平台层也将提供用于JAVA＿HOME的值以满足契约，不管Java7是处于虚拟机器映像中还是Java7实际上被部署。在又一个示例中，一些能力提供执行动作的功能。例如，能力可以包括部署动作模型。这种模型能够包括从企业存档(EAR)文件接收输入的能力。

在一些示例中，能力在不同环境中是可部署的。例如，部署动作能力在一种环境中能够通过总部在美国加利福尼亚帕洛阿尔托的惠普公司由可用的数据库和中间件自动化(DMA)方案包来执行，并且在另一种环境中能够由Chef来执行。此外，与能力关联的标签在同一环境内或在不同环境中能够多次并且组合使用。例如，标签可指示两个版本的Java或者可指示多个应用程序服务器进程实例。

与能力的请求对应的能力将以多种不同的方式影响应用程序。例如，能力过滤掉应用程序将被部署到的平台层。而且，应用程序层将能够引用并使用其已经在平台层内请求的能力，而不必绑定到特定平台或部署环境。例如，如果应用程序请求所部署的应用程序能够执行的脚本的JAVA＿HOME，那么应用程序层一经请求关于Java7的JAVA＿HOME属性，所部署的应用程序就将能够引用来自Java7能力的JAVA＿HOME属性。不管应用程序被部署到平台还是基础设施，在运行时间，契约保证了JAVA＿HOME属性将具有正确值并且所部署的应用程序将被给予脚本。

此外，应用程序层(204)可依赖于具有动作的能力。例如，应用程序模型(201)可以具有应用程序服务器层和数据库层。在其它示例中，应用程序层(204)可以从具体供应商请求服务器集群能力。不是应用程序层(204)包括用于部署到该具体供应商的所有任务，并且不是应用程序层(204)直接绑定到部署工具(例如，Chef)，而是应用程序层(204)将能够在来自该具体供应商的服务器集群能力上虚拟地使用部署动作。该虚拟动作的输入可以包括一些配置参数和EAR文件。用户能够从应用程序定义中选择程序工件来用作输入。在部署时，应用程序能够执行后期的绑定并且基于其部署到的平台而启用执行。一种环境可以具有经由Chef管理的平台并且另一种环境经由惠普公司的DMA方案包管理。

虽然参考具体能力和能力类型已经描述了该示例，根据本文描述的原理可以使用任何适当的能力或任何类型的能力。此外，虽然参考提供能力的具体供应商已经描述了上面的示例，但是根据本文描述的原理可以使用任何适当的供应商。而且，虽然参考具体能力源(如能力库)已经描述了该示例，但是可以使用能力的任何适当的源。例如，平台层可以通过网络连接、网络上另一个服务器、直接从供应商、其它的源或者其组合获取能力。

图3是根据本文描述的原理的能力库(300)的示例的示意图。在该示例中，能力库(300)包括与应用程序(302)和程序资源(304)通信的能力。

通过引用能力库(300)，应用程序(302)能够利用能力参数(306)并且调用能力工作流(308)，而不必依赖程序资源(304)。在部署应用程序(302)时满足应用程序的请求。能够查询程序资源(304)以查找将满足应用程序的请求的能力的执行。程序资源(304)能够对能力库(300)提供满足应用程序的请求的能力的执行，平台层能够利用这些能力。在执行工作流的时候，当应用程序(302)正在平台层上运行时，程序资源(304)能够将与能力执行关联的参数值提供给应用程序。

可以在从一般定义到更加具体的定义的层次结构中设置能力。在某些情况下，能力能够从其父工作流继承工作流定义的参数。然而，能力可以不具有与父工作流定义相同的工作流定义。其它类型的能力可以包括值和属性。虽然参考包含在能力库中的具体类型的能力已经描述了该示例，但是任何适当的能力类型可以包括在能力库中。

图4是根据本文描述的原理用于利用平台层开发应用程序的方法的示例的示意图。在该示例中，方法(400)包括识别具有匹配应用程序请求的能力的平台层(402)，所述应用程序请求针对嵌入应用程序层中的应用程序；将应用程序部署到平台层(404)；以及利用所述能力在平台层中的应用程序上执行开发任务(406)。

可使用与能力关联的标签识别平台层的能力。部署应用程序可以包括发送并安装应用程序到平台层使得平台层运行所部署的应用程序。平台层可以已经包含一些能力并且被标注为具有那些能力。可以将其他的能力添加到平台层以满足应用程序请求。

例如，应用程序可以请求具有25至35千兆字节的存储器、具有大于250千兆字节的磁盘、以及具体类型的服务器。平台层可以已经具有26千兆字节的存储器和300千兆字节的磁盘。在该示例中，该平台层是应用程序偏爱的候选者，只要具体类型的服务器能够在同一平台上得到支持。因此，协调系统查询提供操作具体类型服务器的能力的资源的库。协调系统可以选择候选者资源以支持具体服务器类型。响应于选择将支持具体类型服务器的资源，协调系统可以继续查询该库以查找将为所选择的资源提供额外支持的额外程序等。因此，协调系统将继续查找程序、能力、资源等直到其能够满足应用程序的请求。

应用程序能够被定义为请求的最小值，并且平台也能够被定义为其能力。在这种示例中，能够利用逻辑来确定使用哪个平台层。在一些示例中，基于应用程序的请求以及平台层的能力，协调系统可以确定来建立新的平台层以适应应用程序的请求。

开发任务可以是在开发阶段发生的任何适当任务。例如，开发任务可以包括建模任务、重新配置任务、涉及概念开发的任务、涉及质量保证的任务、涉及生产的任务、涉及开发的其它阶段的任务或其组合。

应用程序能够定义其自身的请求。请求可以包括动作、值、属性、遍历顺序、层次、另一个请求或其组合的请求。

平台层也可能够定义其能力。平台层具有共享公共操作系统和公共程序的至少一个服务器，并且能力包括描述层次、遍历顺序、值、属性、动作模型、另一种能力、或者其组合的开放元数据定义语言。

响应于接收请求，平台层被识别为匹配应用程序请求中的至少一些应用程序请求。方法包括引用将平台层中的标签与能力关联的能力库。

如果所选择的平台层缺少应用程序所请求的能力中的一些能力，那么可以通过额外的程序提供该能力。例如，可以应用来自能力库的能力。应用可以包括将能力下载到平台层。在其它示例中，应用包括使能力通过网络连接由平台层使用。除了将应用程序部署到平台层，应用程序层可以将与应用程序有关的额外机器可读指令附加到平台层。机器可读指令可以是部署策略、维护策略、监控策略、另一种策略、其它类型的机器可读指令、或者其组合。

在一些实例中，响应于提出请求，协调系统将确定在平台层中所需的能力以运行应用程序。如果不存在适于利用平台的现有能力来运行应用程序的平台层，那么协调系统可以确定建立新的平台层并且应用该能力以满足应用程序的请求。在其它示例中，应用程序的请求被匹配到能够至少使用或接收至少一些能力以满足应用程序的请求的平台层。

图5是根据本文描述的原理的协调系统(500)的示例的示意图。协调系统(500)包括请求引擎(502)、能力跟踪引擎(504)、分配引擎(506)、以及部署引擎(508)。在该示例中，协调系统(500)还包括应用引擎(510)以及附加引擎(512)。引擎(502、504、506、508、510、512)是指硬件和程序指令的组合以执行指定的功能。引擎(502、504、506、508、510、512)中的每一个可以包括处理器和存储器。程序指令被存储在存储器中并且引起处理器执行引擎的指定功能。

请求引擎(502)引起应用程序层产生应用程序开发的后期阶段中的应用程序的依赖关系和/或能力的请求。能力跟踪引擎(504)跟踪哪个平台层包括满足应用程序的请求中的至少一些的能力。分配引擎(506)将应用程序层分配到平台层中的一个。如果所分配的平台层不包括满足应用程序的请求的所有能力，那么应用引擎(510)将那些能力应用到所分配的平台层。

部署引擎(508)将应用程序从应用程序层部署到平台层。附加引擎(512)将与应用程序相关的机器可读指令附加到平台层。

图6是根据本文描述的原理的协调系统的示例的示意图。在该示例中，协调系统(600)包括与存储器资源(604)通信的处理资源(602)。处理资源(602)包括至少一个处理器以及用于处理程序指令的其它资源。存储器资源(604)通常表示能够存储由协调系统(600)使用的数据(例如程序指令或数据结构)的任何存储器。被示出存储在存储器资源(604)中的程序指令包括应用程序请求产生器(606)、平台层能力跟踪器(610)、平台层分配器(612)、能力应用器(616)、应用程序部署器(618)、机器可读指令附加器(620)，以及开发任务执行器(622)。被示出存储在存储器资源(604)中的数据结构包括能力库(614)。

存储器资源(604)包括计算机可读存储介质，其包含计算机可读程序代码以引起处理资源(602)执行任务。计算机可读存储介质可以是有形的和/或非瞬态存储器介质。计算机可读存储介质可以是任何适当的存储介质，该存储介质不是传输存储介质。计算机可读存储介质类型的非穷尽列表包括非易失性存储器、易失性存储器、随机存取存储器、基于忆阻器的存储器、只写存储器、闪存、电可擦除可编程只读存储器、磁存储介质、其它类型的存储器或者其组合。

应用程序请求产生器(606)表示在被执行时引起处理资源(602)产生应用程序的请求的程序指令。平台层能力跟踪器(610)表示在被执行时引起处理资源(602)基于能力库(614)中的标签跟踪平台层能力的程序指令。在一些示例中，手动地确定平台层的能力。然而，在其它示例中，利用确定引擎来确定平台层的能力。平台层分配器(612)表示在被执行时引起处理资源(602)将平台层分配给拥有请求的应用程序的程序指令。能力应用器(616)表示在被执行时引起处理资源(602)将能力应用到所分配的平台层的程序指令，所分配的平台层缺少满足应用程序的请求的能力。

应用程序部署器(618)表示在被执行时引起处理资源(602)将应用程序部署到平台层的程序指令。机器可读指令附加器(602)表示在被执行时引起处理资源(602)将与应用程序相关的机器可读指令附加到平台层的程序指令。开发任务执行器(622)表示在被执行时引起处理资源(602)对所部署的应用程序执行部署任务的程序指令。

此外，存储器资源(604)可以是安装包的一部分。响应于安装该安装包，可以从安装包的源(例如便携式介质、服务器、远程网络位置、另一个位置或者其组合)下载存储器资源(604)的程序指令。与本文描述的原理兼容的便携式存储器介质包括DVD、CD、闪存、便携式软盘、磁盘、光盘、其它形式的便携式存储器或者其组合。在其它示例中，已经安装了程序指令。在此，存储器资源可以包括集成的存储器，例如硬盘、固态硬盘等。

在一些示例中，处理资源(602)以及存储器资源(604)位于同一物理组件中，例如服务器或者网络组件。存储器资源(604)可以是物理组件的主存储器、高速缓存、寄存器、非易失性存储器中的一部分，或者在物理组件的存储器层次体系中的某处。可替代地，存储器资源(604)通过网络与处理资源(602)通信。此外，当程序指令位于本地时，数据结构(例如库)可以通过网络连接从远程位置访问。因此，协调系统(600)可以在用户设备上、服务器上、一批服务器上或其组合上实现。

图6的协调系统(600)可以是通用计算机中的一部分。然而，在可替代的示例中，协调系统(600)是应用程序专用集成电路的一部分。

图7是根据本文描述的原理的用于利用平台层开发应用程序的过程的流程图(700)的示例的示意图。在此示例中，过程包括获取(702)应用程序请求并且识别(704)具有匹配所述请求的能力的平台。该过程还包括确定(706)所识别的平台层是否满足所述请求。如果平台层中的一个满足所述请求，那么过程包括将应用程序分配(708)到匹配所述请求的平台层。如果没有平台层满足所述请求，那么过程包括将应用程序分配(710)到平台层中的一个并且将能力的剩余部分应用(712)到所分配的平台层使得所述请求被满足。将应用程序部署(714)到所分配的平台层。

虽然参考具体应用程序模型和应用程序层已经描述了上述示例，但是根据本文描述的原理可以使用任何适当的应用程序模型或应用程序层。此外，虽然参考具体平台和平台设置已经描述了上述示例，但是根据本文描述的原理可以使用任何适当的平台或平台设置。而且，虽然参考具体平台层已经描述了上述示例，但是根据本文描述的原理可以使用任何适当的平台层。

此外，虽然参考具体应用程序请求已经描述了上述示例，但是根据本文描述的原理可以使用任何适当的应用程序请求。而且，虽然参考具体依赖关系和能力已经描述了上述示例，但是根据本文描述的原理可以提出任何适当的依赖关系或能力。虽然参考具体机器可读指令已经描述了上述示例，但是根据本文描述的原理可以使用任何适当类型的机器可读指令。虽然参考具体标签和能力库已经描述了上述示例，但是根据本文描述的原理可以使用任何适当的标签或能力。

已经提出之前的说明以仅用于阐释并描述所描述的原理的示例。该说明并不旨在穷尽性的或者将这些原理限制到所公开的任何精确形式。根据上述教导，多种修改和变化是可能的。

Claims

1.一种用于利用平台层协调应用程序部署的计算机程序产品，包括：

非瞬态计算机可读存储介质，所述非瞬态计算机可读存储介质包括嵌入所述非瞬态计算可读存储介质的计算机可读程序代码，所述计算机可读程序代码包括程序指令，所述程序指令在被执行时引起处理器：

识别具有匹配应用程序请求的能力的平台层，所述应用程序请求针对嵌入应用程序层中的应用程序；

将所述应用程序部署到所述平台层；以及

利用所述能力在所述平台层中的所述应用程序上执行开发任务。

2.根据权利要求1所述的计算机程序产品，进一步包括在被执行时引起所述处理器将额外的机器可读指令附加到所述平台层的程序指令。

3.根据权利要求1所述的计算机程序产品，进一步包括在被执行时引起所述处理器建立平台层以具有匹配所述应用程序请求的所述能力的程序指令。

4.根据权利要求1所述的计算机程序产品，进一步包括在被执行时引起所述处理器利用来自一组平台层的所述平台层的所述能力来匹配所述应用程序请求的程序指令。

5.根据权利要求1所述的计算机程序产品，其中所述能力包括描述层次、遍历顺序、值、属性或其组合的语言。

6.根据权利要求1所述的计算机程序产品，其中所述应用程序请求包括动作。

7.根据权利要求6所述的计算机程序产品，其中所述平台层的所述能力包括所述动作的模型。

8.根据权利要求1所述的计算机程序产品，其中所述代码进一步包括在被执行时引起所述处理器将能力应用到所识别的所述平台层以匹配所述应用程序请求的程序指令。

9.根据权利要求1所述的计算机程序产品，其中所述代码进一步包括在被执行时引起所述处理器定义平台层的能力的程序指令。

10.根据权利要求1所述的计算机程序产品，其中所述代码进一步包括在被执行时引起所述处理器定义应用程序请求的程序指令。

11.根据权利要求1所述的计算机程序产品，其中所述平台层具有共享公共操作系统和公共程序的至少一个服务器。

12.一种利用平台层协调应用程序部署的系统，包括：

请求引擎，用于从应用程序层产生到平台层的至少一个请求；

能力跟踪引擎，用于确定平台层的现有能力；

分配引擎，用于基于所述至少一个请求将所述应用程序层的应用程序分配到所述平台层；

部署引擎，用于基于来自所述分配引擎的分配将所述应用程序部署到所述平台层。

13.根据权利要求12所述的系统，进一步包括应用引擎，用于将额外的能力应用到所述平台层以满足所述至少一个请求。

14.根据权利要求12所述的系统，进一步包括附加引擎，用于将机器可读指令附加到所述平台层中的所述应用程序。

15.一种利用平台层协调应用程序部署的方法，包括：

从应用程序层产生平台层的应用程序请求；

跟踪各个平台层的现有能力；

基于所述应用程序请求将所述应用程序层的应用程序分配到所述各个平台层中的一个；

将额外的能力应用到所述各个平台层中的所述一个以满足所述应用程序请求；以及

将所述应用程序部署到所述各个平台层中的所述一个。