背景技术：
云计算是指基于互联网(“云”)的计算机技术(“计算”)的开发和使用。这是一种计算风格，其中it相关的功能是“作为一种服务”而提供的，允许用户“在云中”访问获得技术支持的服务，而不需要对支持它们的技术基础设施的了解、专业知识或控制权。将软件集成为一种服务并且依靠互联网来满足用户的计算需求是一种普遍的概念。目前大部分云计算基础设施都包含通过构建在计算和存储虚拟化技术上的下一代数据中心而提供的可靠服务。这些服务可以在全球任何地方访问，而云作为消费者所有计算需求的单一访问点而出现。
附图说明
图1是示出根据一个示例的适合于实现自动化市场系统和自动化api发现和管理系统的各方面的计算环境的示意图。
图2是示出根据一个示例的包括联合市场门户的自动化市场系统的示意图。
图3是示出根据一个示例的自动化api发现和管理系统的示意图。
图4是示出根据一个示例的联合市场方法的流程图。
图5是示出根据一个示例的api发现和管理方法的流程图。
具体实施方式
在下面的详细描述中，参考了构成本公开的一部分并且在其中通过图示的方式示出可以实践本公开的具体示例的附图。应该理解，在不脱离本公开的范围的情况下，可以利用其他示例并且可以进行结构或逻辑上的修改。因此，以下的详细描述不应被视为具有限制性意义，并且本公开的范围由所附权利要求来限定。应该理解，除非另有特别说明，否则本文所描述的各种示例的特征可以以部分或全部的方式来彼此组合。
本文所使用的术语“云”意味着将被广义地理解为将所请求的虚拟资源作为服务来交付的任何网络。在一个示例中，云网络可以提供计算环境，其中用户可以通过其连接的设备而从任何地方访问作为服务的应用或计算资源。这些服务可以由被称为云服务提供商的实体来提供。可以通过云网络提供的服务的示例包括基础设施即服务(laas)、平台即服务(paas)和软件即服务(saas)。
云可以被实现为公共云、私有云或混合云。本文所使用的术语“公共云”意味着将被广义地理解为由服务提供商通过网络提供的多种服务，这些服务使得应用、存储和其他资源可供公众使用。在一个示例中，这些服务由服务提供商以按每次使用付费的模式来提供。在该示例中，公共云服务提供商拥有并运营基础设施。在另一示例中，公共云服务提供商通过诸如例如因特网等公共网络来提供访问，并且不提供直接连接。
本文所使用的术语“私有云”意味着将被广义地理解为访问在其中将被完全限制于个人或商业实体的任何云计算环境。在一个示例中，私有云可以是专为单个个人或企业实体运营的任何云基础设施。在一个示例中，私有云由私有云基础设施的所有者在内部管理。在另一示例中，私有云由第三方管理并在内部或外部托管。
本文所使用的术语“混合云”意味着将被广义地理解为包括多个公共云资源和多个私有云资源在内的任何云计算环境。在一个示例中，混合云包括多个云网络，例如保持单独的网络但是被关联在一起以提供多个服务的私有云和公共云。
本文所使用的术语“联合”意味着将被广义地理解为当实际上各实例被分布在多个不同的系统或环境中时使用一个系统或技术来作为单个逻辑实例的能力。作为示例，联合身份是一种解决方案，在其中用户的身份(在该上下文中也称为令牌)在多个it系统、环境或组织中是可信的。
本文所使用的术语“市场”意味着将被广义地理解为包括目录，在该目录中多个合作者提供和发布服务。它被称为“市场”是因为目录可以包括跨越多个组织或公司的产品。
本文所使用的术语“门户”意味着将被广义地理解为用户界面入口点，该用户界面入口点使得用户能够从市场目录中订购物品。
本文所使用的术语“联合市场门户”意味着将被广义地理解为提供抽象的门户，使得当实际上不同实例(其可以基于完全不同的产品和技术)存在并且可能被分布在多个环境中时，用户将该门户视为一个逻辑实例。
图1是示出根据一个示例的适于实现自动化市场系统和自动化api发现和管理系统的各方面的计算环境10的示意图。在所示出的示例中，计算系统或计算设备10包括处理单元12和系统存储器14。取决于计算设备的确切配置和类型，存储器14可以是易失性的(诸如ram等)、非易失性的(诸如rom、闪存等)、或这两者的一些组合。
计算设备10还可以具有附加的或不同的特征/功能以及附加的或不同的硬件和软件。例如，计算设备10还可以包括附加的储存器(可移除的和/或不可移除的)，该储存器包括但不限于磁盘或光盘或磁带。图1中通过可移除储存器16和不可移除储存器18来说明这种附加的储存器。计算机存储介质包括以用于诸如计算机可读指令、数据结构、程序模块或其他数据等信息的非暂时性存储的任何适当的方法或技术来实现的易失性和非易失性、可移除和不可移除的介质，并且不包括暂时性存储介质。存储器14、可移除储存器16和不可移除储存器18都是计算机存储介质的示例(例如，存储计算机可执行指令的非暂时性计算机可读存储介质，当该计算机可执行指令由至少一个处理器执行时，使得至少一个处理器执行一方法)。计算机存储介质包括ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光学储存器、磁盒、磁带、磁盘储存器、或其他磁性储存设备。任何这种计算机存储介质可以是计算设备10的一部分。
计算设备10的各种元件经由通信链路15被通信地耦接在一起。计算设备10还包括允许计算设备10与其他计算机/应用26进行通信的诸如网络连接等通信连接24。计算设备10还可以包括输入设备22，诸如键盘、定点设备(例如鼠标)、笔、语音输入设备、触摸输入设备等。计算设备10还可以包括输出设备20，诸如显示器、扬声器、打印机等。
图1和以上的讨论旨在提供对示例可在其中被实现的适当的计算环境的简要概述。然而，应该理解的是，手持式、便携式和其他所有类型的计算设备都可以考虑使用。因此，图1示出了适当的计算系统环境10的示例，其中可以实现本文所描述的示例，尽管如上面清楚所述地，计算系统环境10是适当的计算环境的一个示例，并不旨在对示例的使用范围或功能提出任何限制。计算环境10也不应当被解释为具有与示例操作环境10中所示的组件中的任何一个或任何组合有关的任何依赖性或任何要求。
如图1所示，自动化市场系统200的至少一个组件和自动化api发现和管理系统300的至少一个组件可以被存储在系统存储器14中。下面分别参考图2和图3来进一步地对系统200和300的示例进行详细描述。
各企业正在制定云战略，并且这些战略的支柱之一就是建立市场，该市场作为用户发布、宣传、订购、监控、查看/管理计费以及对云业务服务的运营进行管理的焦点。这些市场的激增造成了一种混乱，在这种情况下，内容的分享与消费是困难的或不可行的。这种市场激增正在大公司内部以及尝试一起工作或合作的公司之间发生。一些公司可能会希望使在其他公司处的用户能够无缝地共享、贡献和管理在他们各自的市场上发布的业务服务，就好像它们是一体的一样。为了安全和可管理地做到这一点，公司的目录应该支持多租户以及联合，以安全地管理这种内容共享。一种选择是重新发布整个目录中的内容，但这可能会导致同步问题和不必要的管理开销。
本文所公开的示例解决了上述问题。一些示例针对联合市场，该联合市场促进跨越多个市场门户的业务服务的共享、收集和管理。通过实现用于管理业务服务的通用访问机制，这些服务可以跨越多个企业而无缝呈现，从而促进不同业务部门和不同公司之间的再利用和收集/共享。
图2是示出根据一个示例的包括联合市场门户(联合mpp)202的自动化市场系统200的示意图。除了联合市场门户202之外，系统200还包括市场门户集成系统216、参与市场220(1)-220(3)(统称为参与市场220)、其他参与市场240、发票和计费系统242、以及操作管理及监控系统244。在一个示例中，市场220和240是云市场，并且联合市场门户202是云门户。
联合市场门户202包括用户界面204、应用程序接口(api)抽象206、服务产品208(1)-208(n)(统称为服务产品208)、联合模型仓储210、联合自动化仓储212、以及策略管理器214。联合市场门户202用作通过用户界面204来提供一致的用户体验的公共集成点，以用于浏览、订购和管理由多个市场220和240提供的业务服务。门户202允许共享服务产品208的元数据以及代理诸如身份管理等功能。在一个示例中，服务产品208(1)表示由市场220(1)提供的业务服务；服务产品208(2)表示由市场220(2)提供的业务服务；服务产品208(3)表示由市场220(3)提供的业务服务；并且服务产品208(n)表示由其他市场240提供的业务服务。
促进联合的要素是遵循一定的标准。一个示例是使用诸如云应用拓扑编排规范(tosca)等公共模型规范，这实现了模型的可移植性。在一个示例中，联合市场门户202包括联合模型仓储210以允许模型规范的代理和共享。通过这种方式，可以在每个客户自己的环境中对模型进行内省，针对其特定用例进行定制，然后被用于执行自动生命周期操作(诸如安装、配置、更新、终止等)。不需要将这些模型引入到单独的仓储中，而是该仓储可以仅通过统一资源定位器(url)来代理内容并提供针对信息的指针。
为了执行任何生命周期自动化(例如，为了供应业务服务)，使用联合自动化仓储212来共享自动化内容。在一些情况下，仓储212存储用于执行任何生命周期操作步骤的特定代码模块。由于性能原因，针对信息的指针可能是不足的，因此自动化内容可能会在与每个市场相关联的多个自动化仓储中被同步。联合市场门户202通过代理这种调换来进行协助。
策略管理器214执行参与系统200的市场220和240中的每一个市场的具体策略。以这种方式，公司可以声明具体的共享规则、约束、以及协调共享哪些特定业务服务以及如何共享的其他限制。
将多个不同种类的市场220和240集成到联合市场门户202中是由市场门户集成系统216使用从各个市场220和240的特定于产品的api中抽象出的api抽象206来完成的。api抽象针对特定于产品的api的绑定、映射和转换被声明性地定义，并且完全由数据驱动，从而使得个体市场220和240能够通过对门户202的配置数据存储进行更新而被添加到联合市场门户202/移除到联合市场门户202中/从联合市场门户202中被移除。映射到特定于产品的api的示例api抽象包括创建、搜索、查看、更新、删除、订购、管理、终止、以及其他。
api允许发现者消费或使用通过带有消费者自己的程序的api而公开的任何服务(或功能)。“特定于产品”的api和“通用”的api之间可以有所区别，因为现货产品通常具有专用的api，该专用的api只适用于那一种特定的产品；而“通用”的api不限于任何一种产品。可以通过建立“通用”或更精确“规范”的api来实现联合，该“通用”或更精确“规范”的api将多个特定于产品的api隐藏(或抽象)。通用的api可以执行转换，以将特定于产品的数据和接口转换为通用的数据和接口，从而使架构的其余部分更松散地耦合于特定产品。它还使得架构能够随着业务需求的改变以及产品的演进而将一个产品交换为另一个产品。
市场门户集成系统216执行适当的安全令牌、数据、协议和密钥转换，并且创建对相应市场的特定于产品的api的调用。在示例中，特定于产品的api的调用是酌情动态构建然后被执行的。市场门户集成系统216还执行由特定于产品的api所返回的输出(即，结果集)的数据和密钥的转换。随后将结果集的规范表示返回给联合市场门户202，并由联合市场门户202使用。
市场门户集成系统216包括门户联合框架218。门户联合框架218允许更快速地集成来自不同市场的内容。框架218保留元数据，该元数据允许创建能够在新的框架中呈现其自身的新的门户。这可以通过使用渲染(render)程序来实现渲染的xml或json反序列化而完成。这是一种使得联合成为可能而不仅仅是目录项目聚合的功能。
参与市场220(1)-220(3)分别包括产品目录222(1)-222(3)(统称为产品目录222)、产品管理器224(1)-224(3)(统称为产品管理器224)、请求管理器226(1)-226(3)(统称为请求管理器226)、生命周期协调器228(1)-228(3)(统称为生命周期协调器228)、以及市场产品实例230(1)-230(3)(统称为市场产品实例230)。市场220的示例包括云服务自动化(csa)市场、cloudforms市场、以及murano市场。其他参与市场240可以以与市场220大致相同的方式来配置。
产品目录222(1)-222(3)分别提供由市场220(1)-220(3)提供的业务服务的列表，并且分别对应于由门户202提供的服务产品208(1)-208(3)。用户能够使用门户202来订购和管理所列出的业务服务。产品管理器224维护和更新产品目录222。请求管理器226对用于从产品目录222订购的业务服务的用户请求或订单进行处理。生命周期协调器228(1)-228(3)分别生成产品实例230(1)-230(3)，并且还对产品实例230的生命周期进行控制，这些产品实例230(1)-230(3)是由用户通过门户202所订购的业务服务的实例。
当消费者使用门户202来从市场220和240中的一个中订购业务服务并且用户还请求作为该服务的一部分的监控(例如，健康监控)时，利用特定于那个市场的监控技术来执行监控，并且由操作管理及监控系统244将来自该监控技术的监控结果以及其他市场的监控技术的结果提取出来，以供门户202使用。
当今，为了使客户能够与给定的公司分享内容，客户可能会被强制将他们的内容转移到该公司的市场中。相比之下，系统200提供支持多个市场220和240的联合架构。系统200允许给定公司的客户使用他们自己的市场，同时允许跨越租户而安全地共享内容。系统200提供用于对由多个市场220和240提供的业务服务进行管理的公共访问机制(例如，用户界面204)以及跨越多个企业的无缝市场用户体验。
实现由外部市场定义、建模和管理的服务的货币化可能是困难的或不可行的。相比之下，系统200使用发票和计费系统242能够实现服务的货币化，而不管是哪些市场将它们公开。发票和计费系统242跟踪由市场220和240提供的业务服务的使用，并将使用信息提供给适当的市场220和240，以允许这些市场220和240对消费者使用业务服务计费。
现在，部分或完整的业务服务的再利用涉及将其定义以及内容迁移到相关市场。相比之下，系统200可以在不执行这种迁移的情况下实现再利用。为了实现再利用，存在着将与服务有关的信息共享的知识库，但其内容不是机器可读的或者不是使用诸如tosca等标准建模的，并且没有实现自动生命周期管理。相比之下，系统200提供了自动化级别，该自动化级别实现了实际再利用。另外，现有解决方案通常聚焦于或受限于较小的域(例如，单个公司)。相比之下，系统200使得内容能够被联合，并且能够跨越不同的业务部门和不同的公司来实现再利用和收集/共享。系统200允许在合作公司之间共享详细的规范和生命周期管理代码。这可以带来更大的货币化潜力，因为可以在一个企业之外消费服务。
注意到，系统200不仅仅涉及目录聚集，而是涉及联合。因此，目录项以及其内容不会从一个门户移动或复制到另一个门户。而是呈现出内容，并且从本地可用的任何地方对生命周期进行管理(例如，部署)。系统200跨越多个联合内容提供者来提供统一的目录策略管理，并且使来自多个目录的元数据来自动聚合和同步。内容的自动化同步降低了跨越多个市场手动复制内容的开销，同时使用策略来确保安全地完成共享。
存在着被创建并公开以供外部应用进行消费的api的大量激增。虽然这极大地简化了集成惯性，但是扩散也已变得难以管理。api注册表、仓储和网关都是手动配置的。然而，欲将应用和服务部署到云计算环境中的客户需要高度的自动化和自助服务。这意味着可以采用“一键式”功能将应用和服务部署为可用状态。应用可能不被认为是可用的和可消费的，直到包括该api在内的适当的元数据也被发布为止。
本文所公开的一些示例向部署生命周期添加额外的步骤，即业务应用或服务的相关api的自动发布和预填充。一些示例自动地发现相关的api和文档，并且自动配置api网关。本文所公开的示例提供了一键式部署、自动化api发现、api管理器的自动化预填充、api网关配置的自动化预填充、以及当api端点被移动时的自动更新。一些示例针对一种api管理(因为它涉及业务解决方案或应用部署)的生命周期自动化的系统和方法。这有助于实现用于云和非云解决方案的端到端自助服务的“一键式”部署。
图3是示出根据一个示例的自动化api发现和管理系统300的示意图。系统300包括市场门户(mpp)302、消息代理/总线308、策略管理器310、云控制器314、api扫描器320、已实现的商业解决方案322、api管理器332、api网关334、业务服务管理和计费单元336、以及事件通知单元338。
市场门户302包括多个市场门户(mpp)入口304和服务目录306。在一个示例中，市场门户302包括使得消费者能够从服务目录306中选择业务服务以及订购或预订业务服务的web界面。业务服务的消费者订单由市场门户入口304表示。
当消费者订购业务服务时，市场门户302经由消息代理/总线308将订单通知给云控制器314。在一个示例中，云控制器314对业务服务的整个生命周期管理(例如，供应基础设施、安装、配置、激活等)进行协调。云控制器314包括服务的服务生命周期管理单元316和部署自动化单元318。当云控制器314接收到消费者已经为业务服务下订单的通知时，部署自动化单元318供应必要的服务器并且生成所订购的被部署到基础设施/云330(例如，基础设施服务环境)的业务服务的实例326。此时，业务服务实例326开始在服务器上运行并公开至少一个api。
业务服务实例326和基础设施/云330是已实现的业务解决方案322的一部分，其也包括业务服务接口324和元数据仓储328。在图3中假设业务服务的至少一个实例326存在于或其描述存在于元数据仓储328(例如，soa注册表、企业架构仓储、api管理器)中。
在消费者已经从市场门户302订购了特定的业务服务并且该业务服务已经如上所述地被实例化为业务服务实例326之后，api扫描器320随后执行对由实例化的业务服务326所公开的api的智能发现(例如，使用逆向工程和扫描技术)。api扫描器320可以搜索与api相关联的元数据，以便发现实例化的业务服务中的api。
接下来的步骤是公开所发现的api信息，以便将来消费者从所发现的api信息中受益。api扫描器320将api信息提供给市场门户302。在所示出的示例中，api扫描器320还利用消息代理/总线308来促进向各种系统发布api信息，包括：(1)将api信息发布到api管理器332(例如，编写/维护api)；(2)将api信息发布到api网关334(例如，配置api网关334以对业务服务实施访问控制、节流、代理或隐藏真实端点url等)；(3)将api信息发布到业务服务管理和计费单元336，使得管理/监控基础设施被激活，以便在api级别下进行业务活动监控；并且将api信息发布到事件通知单元338。事件通知单元338向感兴趣的(例如选入的)各方(诸如业务服务的现有或预期用户等)提供对api进行发布或更新的事件的通知。该通知可以通过用户界面204(图2)和/或通过电子邮件、文本消息或其他方法来提供给用户。来自单元338的通知将告诉用户如何访问和使用api。该通知有助于进一步利用已发现的api，并且将已公开的服务的可用性和功能改善推向市场。
如上所述，所发现的api信息被发布到api管理器332中。该信息包括每个所发现的api的标准定义以及与每个所发现的api相关的文档。api管理器332对api定义的生命周期进行管理。api管理器332将api信息提供给市场门户302。在一个示例中，将用于给定版本的业务服务的api的定义发布到api管理器332中一次，然后在无需用户干预的情况下动态地部署该api的多个实例，并且将其用于自动配置api网关端点。
api网关334为内部和外部开发设备提供对企业信息的安全访问。api网关334可以提供的、可由api管理器332控制的功能的类型可以包括访问控制(例如，过滤流量使得只有认证/授权流量才能通过)、速率限制(例如，限制与每个api相关联的每个开发者设备可以发送多少流量)、分析/指标捕获和记录(跟踪api中的每个api正在发生的事情)、安全过滤(例如，检查传入消息中的内容是否受到攻击)、以及重定向/流量路由(例如，根据发送者或请求将流量发送到系统的基础设施中的不同端点)。
如上所述，所发现的api信息被发布到api网关334中，以配置api网关334，用以例如实施访问控制。访问控制的一个示例是根据策略和业务规则来控制对api的访问。策略管理器310包括多个策略312，该多个策略312提供用于约束对api的访问的信息。策略管理器310在无需用户干预的情况下，基于策略312来动态地更新和配置api网关334，然后api网关334基于在策略312中指定的规则来控制对api的访问。api网关334对用于业务服务实例的api端点进行管理。每当当前api发生变化时(诸如当一个变化被部署到业务服务时，该变化会导致业务服务的api的改变)，api网关334还利用新的api信息来自动更新。这种api变化被自动检测到并且被用于相应地对api网关334进行更新。
如上所述，api信息还被发布到业务服务管理和计费单元336中，使得管理/监控基础设施被激活，以便在api级别下进行业务活动监控。监控包括为计费目的而对api的使用量进行计量。可以根据已建立的计费政策来针对api的使用向客户收费。
根据本文所公开的示例的api发现还涉及当在业务服务的api端点被移动时检测更新(例如，甚至由不具备消费者知识的基础设施即服务提供商来执行)，并且提供与对api进行访问有关的更新后信息。而且，如果业务服务被消费者终止，则系统300自动将用于该业务服务的api网关端点移除以作为终止过程的一部分。系统300提供api的完整生命周期自动化管理，包括：当业务服务被实例化到环境中时发现api、包括基于策略来设置许可在内的网关配置、当业务服务被更新(如果api发生变化)时更新网关、将关于如何访问api的通知返给消费者、以及终止业务服务并且将api网关端点移除。
系统300使复杂业务解决方案的自助服务、一键式部署和消费支持以及业务解决方案或应用的端到端自动化成为可能。系统300自动发布api信息。系统300使用网关334来激活对api消费的控制，并激活在api级别下对服务进行管理的能力，并且激活计量(如果提供的话)以便能够使用单元336来开出基于使用情况的账单。系统300还在所部署的解决方案或应用被移动时提供api端点的自动更新。
本公开的示例包括下面描述的那些。注意，本文所公开的示例也可以以各种方式来组合。
一个示例针对一种系统，该系统包括联合市场门户以允许用户至少部分地基于应用程序接口(api)抽象来浏览、订购和管理由多个云市场提供的业务服务。该系统包括集成系统以将api抽象转换为由云市场使用的特定于产品的api，并且引发特定于产品的api的调用。
在一个示例中，多个云市场由多个公司提供。业务服务可以被云市场存储而不被聚集到联合市场门户中。在一个示例中，集成系统执行由特定于产品的api所返回的结果集的数据和密钥的转换，并将数据和密钥的转换结果提供给联合市场门户。根据一个示例的api抽象包括创建、搜索、查看、更新、删除、订购、管理和终止。集成系统可以包括门户联合框架以存储元数据，用以促进来自多个市场的内容的集成。联合市场门户可以包括策略管理器以执行多个云市场关于共享业务服务的特定策略。联合市场门户可以包括联合自动化仓储以存储用于执行生命周期自动化步骤的代码模块。联合市场门户可以使存储在联合自动化仓储中的自动化内容与和多个云市场相关联的自动化仓储同步。在一个示例中，联合市场门户包括联合模型仓储以便于代理和共享模型规范。模型规范可以包括云应用拓扑编排规范(tosca)。
另一个示例针对联合市场方法。图4是示出根据一个示例的联合市场方法400的流程图。在方法400中的402处，利用联合市场门户来生成用户界面，以允许用户至少部分地基于应用程序接口(api)抽象来浏览、订购和管理由多个云市场提供的业务服务。在404处，将api抽象转换为由云市场使用的特定于产品的api。在406处，使用从api抽象中转换来的特定于产品的api，以便于通过用户界面来浏览、订购和管理业务服务。在一个示例中，方法400还包括对由特定于产品的api所返回的结果集进行转换；并将转换后的结果集提供给联合市场门户。
另一个示例针对一种存储计算机可执行指令的非暂时性计算机可读存储介质，当该计算机可执行指令由至少一个处理器执行时，用以：利用联合市场门户来生成用户界面，以允许用户浏览、订购和管理由多个云市场提供的业务服务；基于用户与用户界面的交互，将来自联合市场门户的应用程序接口(api)抽象发送到集成系统；利用该集成系统，将api抽象转换为由云市场使用的特定于产品的api；并且使用从api抽象中转换来的特定于产品的api，以便于通过用户界面来浏览、订购和管理业务服务。在一个示例中，计算机可读存储介质还包括用以执行以下操作的指令：将用于执行生命周期自动化步骤的自动化内容存储在联合自动化仓储中；并且使存储在联合自动化仓储中的自动化内容与和多个云市场相关联的自动化仓储同步。
另一示例针对一种系统，该系统包括：市场门户，用以允许用户订购业务服务；以及云控制器，用以将所订购的业务服务的实例部署到云环境中。该系统还包括：应用程序接口(api)扫描器，用以发现api信息并将所发现的api信息发布到另一服务，所发现的api信息包括由所部署的已订购业务服务的实例所公开的至少一个api。另一服务可以包括：api管理器，其对api定义的生命周期进行管理。另一服务可以包括：api网关，用以为用户设备提供对api的授权访问。在一个示例中，策略管理器基于访问控制策略来动态地配置api网关。在一个示例中，api扫描器对所发现的api信息的更新进行检测，并将相应更新后的api信息提供给api网关。更新可以包括api端点的变更。另一服务可以包括：管理和计费单元，用于为了计费目的而在api级别下对业务服务进行监控。另一服务可以包括：事件通知单元，用以向业务服务的现有和预期用户提供关于所发现的api信息的通知。
另一示例针对api发现和管理方法。图5是示出根据一个示例的api发现和管理方法500的流程图。在方法500中的502处，生成业务服务的第一实例。在504处，将第一实例部署到云环境。在506处，发现包括由第一实例所公开的至少一个api在内的api信息。在508处，将所发现的api信息发布到api网关。在510处，通过api网关为用户设备提供对至少一个api的授权访问。在一个示例中，方法500还包括：将所发现的api信息发布到对api定义的生命周期进行管理的api管理器。方法500可以包括：对所发现的api信息的更新进行检测，并且将检测到的更新发布到api网关，其中该更新包括api端点的变更。方法500可以包括：将所发现的api信息发布到管理和计费单元，以便为了计费目的而在api级别下对业务服务进行监控。方法500可以包括：将所发现的api信息发布到事件通知单元，用以向业务服务的现有和预期用户提供关于所发现的api信息的通知。
另一示例针对一种用于存储计算机可执行指令的非暂时性计算机可读存储介质，该计算机可执行指令由至少一个处理器执行，用以：生成业务服务的第一实例；将第一实例部署到云环境；发现由第一实例所公开的至少一个api；以及将所发现的至少一个api发布到对api定义的生命周期进行管理的api管理器。计算机可读存储介质还可以包括：用以将所发现的api信息发布到以下中的至少一个的指令：api网关，用于向用户设备提供对至少一个api的授权访问；管理和计费单元，用于为了计费目的而在api级别下对业务服务进行监控；以及事件通知单元，用于向业务服务的现有和预期用户提供关于所发现的至少一个api的通知。
虽然本文已经说明和描述了具体示例，但是在不脱离本公开的范围的情况下，各种替代和/或等同的实现方式可以替代所示出和描述的具体示例。本申请旨在涵盖本文所讨论的具体示例的任何修改或变化。因此，本公开旨在仅由权利要求书及其等同物来限制。