Patent Description:
<CIT> discloses systems and methods for multiple cloud marketplace aggregation. Described is an aggregation engine which communicates with a set of multiple cloud marketplaces, each of which communicates with an associated set of clouds. A requesting entity, such as a user requesting the instantiation of a set of virtual machines, can transmit a resource request to the aggregation engine. The aggregation engine can fan out or distribute a replicated request to the set of multiple cloud marketplaces. Each cloud marketplace can receive the request and respond to indicate available resources that can be produced from their respect set of clouds. The aggregation engine can collect the responses of the various marketplaces, and can generate one or more selections based on selection logic such as best match, cost factors, or other criteria.

In a first aspect of the invention there is provided a system according to claim <NUM>. In a second aspect of the invention there is provided a computer-implemented method according to claim <NUM>. In a third aspect on the invention there is provided a non-transitory computer-readable storage medium storing computer- executable instructions according to claim <NUM>.

The term "cloud" as used herein is meant to be understood broadly as any network that delivers requested virtual resources as a service. In one example, a cloud network may provide a computing environment where users can have access to applications or computing resources, as services, from anywhere through their connected devices. These services may be provided by entities called cloud services providers. Examples of services that may be provided via a cloud network include infrastructure as a service (laaS), platform as a service (PaaS), and software as a service (SaaS).

A cloud may be implemented as a public cloud, private cloud, or hybrid cloud. The term "public cloud" as used herein is meant to be understood broadly as a number of services provided by a service provider over a network that makes applications, storage, and other resources available to the general public. In one example, these services are offered by the service provider on a pay-per-use model. In this example, the public cloud service providers own and operate the infrastructure. In another example, the public cloud service provider offers access via a public network such as, for example, the Internet, and direct connectivity is not offered.

The term "private cloud" as used herein is meant to be understood broadly as any cloud computing environment in which access is exclusively limited to an individual or a business entity. In one example, a private cloud may be any cloud infrastructure operated solely for a single individual or business entity. In one example, the private cloud is managed internally by the owner of the private cloud infrastructure. In another example, the private cloud is managed by a third-party and hosted internally or externally.

The term "hybrid cloud" as used herein is meant to be understood broadly as any cloud computing environment that comprises a number of public cloud resources and a number of private cloud resources. In one example, a hybrid cloud comprises a number of cloud networks such as private clouds and public clouds that remain individual networks but are associated to offer a number of services.

The term "federated" as used herein is meant to be understood broadly as the ability to use one system or technology as a single logical instance when in reality instances are distributed across multiple distinct systems or environments. As an example, Federated Identity is a solution in which a user's identity (also referred to as a token in this context) is trusted across multiple IT systems, environments, or organizations.

The term "marketplace" as used herein is meant to be understood broadly as including a catalog in which multiple contributors offer and publish services. It is termed "market" because the catalog may include offerings that span across multiple organizations or companies.

The term "portal" as used herein is meant to be understood broadly as a user interface entry point that enables users to order items from the marketplace catalog.

The term "federated marketplace portal" as used herein is meant to be understood broadly as a portal that provides abstraction so users view the portal as one logical instance when in reality different instances (which may be based on completely different products and technologies) exist and may be distributed across multiple environments.

<FIG> is a diagram illustrating a computing environment <NUM> suitable for implementing aspects of an automated marketplace system and an automated API discovery and management system according to one example. In the illustrated example, the computing system or computing device <NUM> includes processing units <NUM> and system memory <NUM>. Depending on the exact configuration and type of computing device, memory <NUM> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two.

Computing device <NUM> may also have additional or different features/functionality and additional or different hardware and software. For example, computing device <NUM> may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any suitable method or technology for non-transitory storage of information such as computer readable instructions, data structures, program modules or other data, and does not include transitory storage media. Memory <NUM>, removable storage <NUM> and non-removable storage <NUM> are all examples of computer storage media (e.g., non-transitory computer-readable storage media storing computer-executable instructions that when executed by at least one processor cause the at least one processor to perform a method). Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Any such computer storage media may be part of computing device <NUM>.

The various elements of computing device <NUM> are communicatively coupled together via communication links <NUM>. Computing device <NUM> also includes communication connections <NUM>, such as network connections, that allow computing device <NUM> to communicate with other computers/applications <NUM>. Computing device <NUM> may also include input device(s) <NUM>, such as keyboard, pointing device (e.g., mouse), pen, voice input device, touch input device, etc. Computing device <NUM> may also include output device(s) <NUM>, such as a display, speakers, printer, etc..

<FIG> and the above discussion are intended to provide a brief general description of a suitable computing environment in which examples may be implemented. It should be understood, however, that handheld, portable, and other computing devices of all kinds are contemplated for use. <FIG> thus illustrates an example of a suitable computing system environment <NUM> in which the examples described herein may be implemented, although as made clear above, the computing system environment <NUM> is one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the examples. Neither should the computing environment <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example operating environment <NUM>.

As shown in <FIG>, at least one component of an automated marketplace system <NUM> and at least one component of an automated API discovery and management system <NUM> may be stored in system memory <NUM>. Examples of systems <NUM> and <NUM> are described in further detail below with reference to <FIG> and <FIG>, respectively.

Enterprises are establishing cloud strategies and one of the pillars of these strategies is the establishment of a marketplace serving as the focal point where users publish, advertise, order, monitor, view/manage bills, and manage operations for cloud business services. The proliferation of these marketplaces has created a sort of chaos where sharing and consumption of content is difficult or impossible. This marketplace proliferation is occurring within large companies as well as across companies that attempt to work or partner together. Some companies may wish to enable users at other companies to seamlessly share, contribute, and manage business services published in their separate marketplaces as if they were one. To do this securely and manageably, a company's catalog should support multi-tenancy and federation to safely manage this sharing of content. One option is to republish content across catalogs, but this may lead to synchronization issues and unnecessary management overhead.

Examples disclosed herein address the issues identified above. Some examples are directed to a federated marketplace that promotes the sharing, harvesting, and managing of business services across multiple marketplace portals. By enabling a common access mechanism for managing business services, these services can appear seamlessly across multiple enterprises, promoting reuse and harvesting/sharing across different business units and different companies.

<FIG> is a diagram illustrating an automated marketplace system <NUM> including a federated marketplace portal (federated MPP) <NUM> according to one example. In additional to federated marketplace portal <NUM>, system <NUM> also includes marketplace portal integration system <NUM>, participating marketplaces <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as participating marketplaces <NUM>), other participating marketplaces <NUM>, invoice and billing system <NUM>, and operations management and monitoring system <NUM>. In one example, marketplaces <NUM> and <NUM> are cloud marketplaces and federated marketplace portal <NUM> is a cloud portal.

Federated marketplace portal <NUM> includes user interface <NUM>, application programming interface (API) abstractions <NUM>, service offerings <NUM>(<NUM>)-<NUM>(N) (collectively referred to as service offerings <NUM>), federated model repository <NUM>, federated automation repository <NUM>, and policy manager <NUM>. Federated marketplace portal <NUM> serves as a common integration point providing a consistent user experience through user interface <NUM> for browsing, ordering, and managing business services offered by multiple marketplaces <NUM> and <NUM>. Portal <NUM> allows sharing of metadata of service offerings <NUM>, and brokering of capabilities such as identity management. In one example, service offerings <NUM>(<NUM>) represent business services offered by marketplace <NUM>(<NUM>); service offerings <NUM>(<NUM>) represent business services offered by marketplace <NUM>(<NUM>); service offerings <NUM>(<NUM>) represent business services offered by marketplace <NUM>(<NUM>); and service offerings <NUM>(N) represent business services offered by other marketplaces <NUM>.

An element that promotes federation is adherence to certain standards. One example is the use of common model specifications, such as Topology and Orchestration Specification for Cloud Applications (TOSCA), which enables the portability of models. In one example, federated marketplace portal <NUM> includes a federated model repository <NUM> to allow the brokering and sharing of model specifications. In this manner, models can be introspected in each customer's own environment, customized for their specific use cases, and then used to perform automated lifecycle actions (such as install, configure, update, terminate, etc.). The models need not be brought into a single repository, but rather this repository may merely broker the content and provide pointers to the information via uniform resource locators (URLs).

To perform any lifecycle automation (e.g., to provision a business service), automation content is shared using federated automation repository <NUM>. In some cases, repository <NUM> stores the specific code modules for performing any lifecycle action step. Having pointers to the information may be insufficient due to performance reasons and therefore automation content may be synchronized across multiple automation repositories associated with each marketplace. The federated marketplace portal <NUM> assists by brokering this exchange.

Policy manager <NUM> enforces specific policies of each of the marketplaces <NUM> and <NUM> participating in the system <NUM>. In this manner, companies can declare specific sharing rules, constraints, and other restrictions mediating what and how specific business services are shared.

Integration of multiple disparate marketplaces <NUM> and <NUM> into the federated marketplace portal <NUM> is accomplished by marketplace portal integration system <NUM> using API abstractions <NUM> that are abstracted from the product-specific APIs of the various marketplaces <NUM> and <NUM>. The bindings, mappings, and transformation of the API abstractions to the product specific APIs are defined declaratively and are entirely data driven, thereby enabling individual marketplaces <NUM> and <NUM> to be added/removed to/from the federated marketplace portal <NUM> by updating a configuration data store of the portal <NUM>. Example API abstractions that are mapped to product-specific APIs include Create, Search, View, Update, Delete, Order, Manage, Terminate, as well as others.

APIs allow developers to consume or use whatever service (or functionality) is exposed by the API with the consumer's own program. A distinction can be made between "product-specific" APIs and "generic" APIs because off-the-shelf products typically have proprietary APIs that only work with that one specific product; whereas "generic" APIs are not limited to any one product. Federation may be enabled by establishing "generic" or more precisely "canonical" APIs that hide (or abstract) multiple product-specific APIs. The generic APIs may perform transformations to convert between product-specific data and interfaces into general ones so the rest of the architecture is more loosely coupled to a specific product. It also enables an architecture to swap one product for another as business needs change and products evolve.

The marketplace portal integration system <NUM> performs the appropriate security token, data, protocol, and key transformations and creates the invocation of the respective marketplace product-specific API. In an example, the product-specific API invocation is dynamically constructed as appropriate and then performed. The marketplace portal integration system <NUM> also performs the data and key transformations of the outputs (i.e., result sets) returned by the product-specific API. The canonical representation of the result sets are then returned to and used by the federated marketplace portal <NUM>.

The marketplace portal integration system <NUM> includes portal federation framework <NUM>. The portal federation framework <NUM> allows quicker integration of content from different marketplaces. Framework <NUM> retains metadata that allows the creation of a new portlet capable of rendering itself one-click in a new frame. This may be accomplished via XML or JSON deserialization enabling rendering using a Render program. This is a feature that enables federation and not just catalog item aggregation.

Participating marketplaces <NUM>(<NUM>)-<NUM>(<NUM>) respectively includeoffering catalogs <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as offering catalogs <NUM>), offering managers <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as offering managers <NUM>), request managers <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as request managers <NUM>), lifecycle orchestrators <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as lifecycle orchestrators <NUM>), and marketplace offering instantiations <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to as marketplace offering instantiations <NUM>). Examples of marketplaces <NUM> include a Cloud Service Automation (CSA) marketplace, a CloudForms marketplace, and a Murano marketplace. Other participating marketplaces <NUM> may be configured in substantially the same manner as marketplaces <NUM>.

Offering catalogs <NUM>(<NUM>)-<NUM>(<NUM>) provide a listing of business services offered by marketplaces <NUM>(<NUM>)-<NUM>(<NUM>), respectively, and correspond to the service offerings <NUM>(<NUM>)-<NUM>(<NUM>), respectively, provided by the portal <NUM>. Users are able to order and manage the listed business services using portal <NUM>. Offering managers <NUM> maintain and update the offering catalogs <NUM>. Request managers <NUM> handle user requests or orders for business services that are ordered from offering catalogs <NUM>. Lifecycle orchestrators <NUM>(<NUM>)-<NUM>(<NUM>) generate offering instantiations <NUM>(<NUM>)-<NUM>(<NUM>), respectively, which are instances of business services that have been ordered by users through portal <NUM>, and also control the lifecycle of the offering instantiations <NUM>.

When a consumer uses portal <NUM> to order a business service from one of the marketplaces <NUM> or <NUM>, and the user also requests monitoring (e.g., health monitoring) to be a part of that service, the monitoring technology specific to that marketplace is used to perform the monitoring, and the results of the monitoring from that monitoring technology, as well as the results of the monitoring technologies of the other marketplaces, are abstracted out by operations management and monitoring system <NUM> for use by portal <NUM>.

Today, in order to enable customers to share content with a given company, the customers may be forced to move their content into that company's marketplace. In contrast, system <NUM> provides a federated architecture supporting multiple marketplaces <NUM> and <NUM>. System <NUM> allows customers of a given company to use their own marketplace while allowing secured sharing of content across tenants. System <NUM> provides a common access mechanism (e.g., user interface <NUM>) for managing business services provided by multiple marketplaces <NUM> and <NUM>, and a seamless marketplace user experience across multiple enterprises.

It may be difficult or not possible to enable monetization of services defined, modeled, and managed by an external marketplace. In contrast, system <NUM> enables monetization of services using invoice and billing system <NUM> regardless of what marketplace exposes them. Invoice and billing system <NUM> tracks usage of business services offered by marketplaces <NUM> and <NUM>, and provides the usage information to the appropriate marketplaces <NUM> and <NUM> to allow those marketplaces <NUM> and <NUM> to bill consumers for the use of the business services.

Reuse of component or full business services today involves migrating their definitions and content to the relevant marketplace. In contrast, system <NUM> enables reuse without performing this migration. To enable reuse, there are knowledge bases that share information about services, but that content is not machine readable or modeled using standards such as TOSCA, and it does not enable automated lifecycle management. In contrast, system <NUM> provides a level of automation that enables practical reuse. Additionally, existing solutions generally focus on or are limited to a small domain (e.g., a single company). In contrast, system <NUM> enables content to be federated, and enables reuse and harvesting/sharing across different business units and different companies. System <NUM> allows detailed specifications and lifecycle management code to be shared between partner companies. This allows for a greater potential for monetization as the services can be consumed beyond one enterprise.

It is noted that system <NUM> does not involve merely catalog aggregation, but rather involves federation. Thus, catalog items and their content are not moved or copied from one portal to another. Instead, the content is rendered and the lifecycle is managed (e.g., deployed) from wherever they are natively available. System <NUM> provides unified catalog policy management across multiple federated content providers, and automated aggregation and synchronization of metadata from multiple catalogs. Automated synchronization of content reduces the overhead of manually copying the content across multiple marketplaces while policies are used to ensure the sharing is done securely.

There is a large proliferation of APIs being created and exposed for external applications to consume. While this greatly eases the inertia for integration, the proliferation has become unmanageable. API registries, repositories, and gateways are manually configured. However, customers deploying applications and services into a cloud computing environment demand a high degree of automation and self-service. This means that applications and services be deployed into a usable state with "one-click" functionality. An application may not be considered usable and consumable until the proper metadata including the API are also published.

Some examples disclosed herein add an extra step to the deployment lifecycle, namely the automated publishing and pre-population of the relevant APIs of a business application or service. Some examples automatically discover the relevant APIs with documentation, and automatically configure an API gateway. Examples disclosed herein provide one-click deployment, automated API discovery, automated pre-population of an API manager, automated pre-population of API gateway configurations, and automated updates when an API endpoint is moved. Some examples are directed to a system and method to automate the lifecycle of API management as it relates to business solution or application deployment. This facilitates delivering "one-click" deployment for end-to-end self-service of cloud and non-cloud solutions.

<FIG> is a diagram illustrating an automated API discovery and management system <NUM> according to one example. System <NUM> includes marketplace portal (MPP) <NUM>, message broker/bus <NUM>, policy manager <NUM>, cloud controller <NUM>, API scanner <NUM>, realized business solution <NUM>, API manager <NUM>, API gateway <NUM>, business service management and billing unit <NUM>, and event notification unit <NUM>.

Marketplace portal <NUM> includes a plurality of marketplace portal (MPP) entries <NUM> and a service catalog <NUM>. In one example, marketplace portal <NUM> includes a web interface that enables a consumer to select a business service from service catalog <NUM>, and order or subscribe to the business service. Consumer orders of business services are represented by the marketplace portal entries <NUM>.

When a consumer orders a business service, the marketplace portal <NUM> notifies the cloud controller <NUM> of the order via the message broker/bus <NUM>. In one example, the cloud controller <NUM> orchestrates the entire lifecycle management of a business service (e.g., provision infrastructure, install, configure, activate, etc.). The cloud controller <NUM> includes a service lifecycle management of services unit <NUM> and a deployment automation unit <NUM>. When the cloud controller <NUM> receives a notification that a consumer has placed an order for a business service, the deployment automation unit <NUM> provisions necessary servers and generates an instance <NUM> of the ordered business service, which is deployed to infrastructure/clouds <NUM> (e.g., an infrastructure service environment). At that point, the business service instance <NUM> begins running on the server and exposes at least one API.

The business service instance <NUM> and the infrastructure/clouds <NUM> are part of the realized business solution <NUM>, which also includes business service interface <NUM> and metadata repository <NUM>. It is assumed in <FIG> that at least one instance <NUM> of a business service exists or its description exists in metadata repository <NUM> (e.g., SOA registry, Enterprise Architecture repository, API Manager).

After a consumer has ordered a specific business service from the marketplace portal <NUM>, and that business service has been instantiated into business service instance <NUM> as described above, API scanner <NUM> then performs an intelligent discovery (e.g., using reverse engineering and scanning techniques) of the APIs exposed by the instantiated business service <NUM>. The API scanner <NUM> may search for metadata associated with APIs in order to discover APIs in instantiated business services.

A next step is the exposure of the discovered API information for future consumers to benefit from the discovered API information. API scanner <NUM> provides the API information to marketplace portal <NUM>. In the illustrated example, API scanner <NUM> also utilizes message broker/bus <NUM> to facilitate publishing API information to various systems, including: (<NUM>) publishing API information into API manager <NUM> (e.g., authoring/maintaining APIs); (<NUM>) publishing API information into API gateway <NUM> (e.g., to configure the API gateway <NUM> to enforce access control, throttling, proxy or hide real endpoint URL, etc., for the business service); (<NUM>) publishing API information into business service management and billing unit <NUM> so that the management/monitoring infrastructure is activated for business activity monitoring at the API level; and publishing API information into event notification unit <NUM>. Event notification unit <NUM> provides a notification of an event of publishing or updating an API to interested (e.g., opt-in) parties, such as existing or prospective users of the business service. The notification may be provided to users via user interface <NUM> (<FIG>), and/or via email, text message, or other method. The notification from unit <NUM> informs the users how to access and use the APIs. This notification facilitates gaining further adoption of discovered APIs and markets the availability and feature enhancements of the exposed services.

As mentioned above, discovered API information is published into API manager <NUM>. This information includes the standard definitions of each discovered API and the documentation associated with each discovered API. API manager <NUM> manages the lifecycle of API definitions. API manager <NUM> provides the API information to marketplace portal <NUM>. In one example, the definitions of an API for a given version of a business service are published into the API manager <NUM> once, and then multiple instances of that API are dynamically deployed without user intervention and used to automatically configure API gateway endpoints.

API gateway <NUM> provides for secure access to enterprise information for internal and external development devices. The types of functions that the API gateway <NUM> may provide, which may be controlled by the API manager <NUM>, may include access control (e.g., filtering traffic so only authenticated/authorized traffic gets through), rate limiting (e.g., restricting how much traffic can be sent by each developer device in association with each API), analytics/metrics capture and logging (tracking what's going on with each of the APIs), security filtering (e.g., checking the content on incoming messages for attacks), and redirection/traffic routing (e.g., sending traffic to different endpoints in the infrastructure of the system depending on the sender or the request).

As mentioned above, discovered API information is published into the API gateway <NUM> to configure the API gateway <NUM> to, for example, enforce access control. One example of access control is to control access to APIs based on policies and business rules. Policy manager <NUM> includes a plurality of policies <NUM> that provide information for constraining access to the APIs. Policy manager <NUM> dynamically updates and configures the API gateway <NUM>, without user intervention, based on policies <NUM>, and then the API gateway <NUM> controls access to APIs based on rules specified in the policies <NUM>. API gateway <NUM> manages the API endpoints for business service instances. API gateway <NUM> is also automatically updated with new API information whenever a change occurs to the current APIs, such as when a change is deployed to a business service that causes a change in the APIs of the business service. Such API changes are automatically detected and used to update API gateway <NUM> accordingly.

As mentioned above, API information is also published into the business service management and billing unit <NUM> so that the management/monitoring infrastructure is activated for business activity monitoring at the API level. The monitoring includes metering usage of APIs for billing purposes. Customers can be charged for usage of the APIs based on established billing policies.

The API discovery according to examples disclosed herein also involves detecting updates when the API endpoint of the business service is moved (e.g., even by an infrastructure-as-a-service provider without knowledge of the consumer), and providing updated information regarding accessing the API. Also, if a business service is terminated by a consumer, system <NUM> automatically removes the API gateway endpoints for that business service as part of the termination process. System <NUM> provides full life cycle automated management of APIs, including API discovery when a business service is instantiated into an environment, gateway configuration including setting up permissions based on policy, updating the gateway as the business service is updated (if the APIs change), notifications back to consumers regarding how to access the APIs, and termination of the business service and removal of API gateway endpoints.

System <NUM> enables self-service, one-click deployment and consumption enablement of complex business solutions, and end-to-end automation of business solutions or applications. System <NUM> automates publishing of API information. System <NUM> activates controls on consumption of the API using gateway <NUM>, activates the ability to manage the service at the API level and activates the metering (if provided) to enable usage-based billing using unit <NUM>. System <NUM> also provides automatic updates of API endpoints when deployed solutions or applications are moved.

The invention is directed to a system that includes a federated marketplace portal to allow a user to browse, order, and manage business services offered by a plurality of cloud marketplaces based at least in part on application programming interface (API) abstractions. The system includes an integration system to transform the API abstractions into product-specific APIs used by the cloud marketplaces and cause the invocation of the product-specific APIs.

The plurality of cloud marketplaces are provided by multiple companies. The business services may be stored by the cloud marketplaces without being aggregated into the federated marketplace portal. In one example, the integration system performs data and key transformations of result sets returned by the product-specific APIs and provides results of the data and key transformations to the federated marketplace portal. The API abstractions according to one example include Create, Search, View, Update, Delete, Order, Manage, and Terminate. The integration system may include a portal federation framework to store metadata to facilitate integration of content from the plurality of marketplaces. The federated marketplace portal may include a policy manager to enforce specific policies of the plurality of cloud marketplaces regarding the sharing of the business services. The federated marketplace portal may include a federated automation repository to store code modules for performing lifecycle automation steps. The federated marketplace portal may synchronize automation content stored in the federated automation repository with automation repositories associated with the plurality of cloud marketplaces. In one example, the federated marketplace portal includes a federated model repository to facilitate brokering and sharing model specifications. The model specifications may include Topology and Orchestration Specification for Cloud Applications (TOSCA).

<FIG> is a flow diagram illustrating a federated marketplace method <NUM> according to one example. At <NUM> in method <NUM>, a user interface is generated with a federated marketplace portal to allow a user to browse, order, and manage business services offered by a plurality of cloud marketplaces based at least in part on application programming interface (API) abstractions. At <NUM>, the API abstractions are transformed into product-specific APIs used by the cloud marketplaces. At <NUM>, the product-specific APIs transformed from the API abstractions are used to facilitate browsing, ordering, and managing the business services via the user interface. In one example, method <NUM> also includes transforming result sets returned by the product-specific APIs; and providing the transformed result sets to the federated marketplace portal.

A non-transitory computer-readable storage medium storing computer-executable comprises instructions, executed by at least one processor, to: generate a user interface with a federated marketplace portal to allow a user to browse, order, and manage business services offered by a plurality of cloud marketplaces; send application programming interface (API) abstractions from the federated marketplace portal to an integration system based on interaction of the user with the user interface; transform, with the integration system, the API abstractions into product-specific APIs used by the cloud marketplaces; and use the product-specific APIs transformed from the API abstractions to facilitate browsing, ordering, and managing the business services via the user interface. In one example, the computer-readable storage medium also includes instructions to: store automation content for performing lifecycle automation steps in a federated automation repository; and synchronize the automation content stored in the federated automation repository with automation repositories associated with the plurality of cloud marketplaces.

In the following, each of the examples which do not fully correspond to the invention as defined in the claims is thus not according to the invention and is, as well as the whole following description, present for illustration purposes only or to highlight specific aspects or features of the claims. An example is directed to a system that includes a marketplace portal to allow a user to order a business service, and a cloud controller to deploy an instance of the ordered business service to a cloud environment. The system also includes an application programming interface (API) scanner to discover API information including at least one API exposed by the deployed instance of the ordered business service, and publish the discovered API information to another service. The another service may include an API manager that manages a lifecycle of API definitions. The another service may include an API gateway to provide user devices with authorized access to APIs. In one example, a policy manager dynamically configures the API gateway based on access control policies. In one example, the API scanner detects an update to the discovered API information and provides corresponding updated API information to the API gateway. The update may include a change in an API endpoint. The another service may include a management and billing unit for monitoring of the business service at an API level for billing purposes. The another service may include an event notification unit to provide a notification to existing and prospective users of the business service regarding the discovered API information.

Another example is directed to an API discovery and management method. <FIG> is a flow diagram illustrating an API discovery and management method <NUM> according to one example. At <NUM> in method <NUM>, a first instance of a business service is generated. At <NUM>, the first instance is deployed to a cloud environment. At <NUM>, API information including at least one API exposed by the first instance is discovered. At <NUM>, the discovered API information is published to an API gateway. At <NUM>, user devices are provided with authorized access to the at least one API via the API gateway. In one example, method <NUM> also includes publishing the discovered API information to an API manager that manages a lifecycle of API definitions. Method <NUM> may include detecting an update to the discovered API information, wherein the update includes a change in an API endpoint; and publishing the detected update to the API gateway. Method <NUM> may include publishing the discovered API information to a management and billing unit for monitoring of the business service at an API level for billing purposes. Method <NUM> may include publishing the discovered API information to an event notification unit to provide a notification to existing and prospective users of the business service regarding the discovered API information.

Claim 1:
A system (<NUM>), comprising:
a hardware processor (<NUM>); and
a non-transitory machine-readable storage medium (<NUM>) encoded with instructions executable by the hardware processor (<NUM>) to perform operations to:
generate a user interface (<NUM>) with a federated marketplace portal (<NUM>) to allow a user to browse, order, and manage business applications offered by a plurality of cloud marketplaces (<NUM>) based at least in part on application programming interface, API, abstractions;
transform API abstractions (<NUM>) into product-specific APIs used by a plurality of cloud marketplaces (<NUM>) and cause invocation of the product-specific APIs in an integration system (<NUM>);
provide result sets, generated by the product-specific APIs based on user interactions, to the integration system (<NUM>);
transform, by the integration system (<NUM>), the result sets returned by the product-specific APIs into a canonical form, wherein the transformed result sets are transmitted to the federated marketplace portal (<NUM>);
use the transformed result sets to facilitate browsing, ordering, and managing business applications offered by the plurality of cloud marketplaces (<NUM>) through the federated marketplace portal (<NUM>);
instantiate one of the business applications into a business application instance responsive to the user ordering the one of the business applications;
automatically discover the product-specific APIs exposed by the business application instance;
publish discovered product-specific APIs to an API gateway (<NUM>);
detect updates to the discovered product-specific APIs;
responsive to detecting an update to one of the discovered product-specific APIs, provide corresponding updated API information to the API gateway (<NUM>);
provide a notification of the updated API information to the user;
store code modules for performing lifecycle automation steps in a federated automation repository (<NUM>); and
synchronize automation content stored in the federated automation repository (<NUM>) with automation repositories associated with the plurality of cloud marketplaces (<NUM>).