Platform runtime abstraction

• US 10,594,800 B2
• Filed: 11/01/2016
• Issued: 03/17/2020
• Est. Priority Date: 04/26/2012
• Status: Active Grant

• Current Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Original Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Inventors: Hipp, Burton Akira, Bharadhwaj, Rajeev, Tripp, Travis S., Wilson, Kevin L., Haeuptle, Michael
• Primary Examiner(s): Katsikis, Kostas J
• Application Number:
  US15/340,380
• Publication Number:
  US 20170048331A1
• Time in Patent Office: 1,232 Days
• CPC Class Codes: G06F 15/16 Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs coordinating program control therefor G06F9/52; in regulating and control system G05B
• CPC Class Codes: G06F 8/20 Software design
• CPC Class Codes: G06F 8/36 Software reuse
• CPC Class Codes: G06F 8/656 while running
• CPC Class Codes: G06F 9/44 Arrangements for executing specific programs
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04L 67/141 Setup of application sessions admission control or resource allocation in data switching networks H04L47/70
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]

Abstract

Platform runtime abstraction can include creating a number of template models within a platform where the number of template models correspond to a provider mode and creating a number of abstraction layers that allow a provider to plug into the platform at runtime where the provider includes a provider sub-system and the provider model. Platform runtime abstraction can also include allowing the provider to plug into the platform at runtime through one of the number of abstraction layers wherein the provider remains independent of the platform and where the provider remains independent of a platform hardware infrastructure and a platform operating system infrastructure.

Claims

1. A method for registering a provider with a platform, the method performed by at least one processor and comprising:

receiving a request for a normalized input from the platform to provision, monitor, service, deploy, and provide lifecycle management for an application across the provider, wherein the platform and the provider are systems independent of each other;

providing, based on the request, an evaluated input request to the provider;

tagging a provider resource received as a response to the evaluated input request such that that tagged provider resource includes a representation of a provider model;

providing the tagged provider resource to the platform as a response to the request for the normalized input; and

plugging the provider into the platform by mapping the provider model represented by the tagged provider resource onto a template model associated with the platform.

2. The method of claim 1, wherein receiving a request for a normalized input includes receiving the request through a common application programming interface (API).

3. The method of claim 2, wherein receiving a request for a normalized input includes receiving the request through the common API and a provider implemented API.

4. The method of claim 3, wherein the provider implemented API defines a communication format accessible to the provider.

5. The method of claim 1, comprising:

receiving, as a response to the evaluated input request, a message that includes the provider resource, the provider resource being defined in relation to the provider model.

6. The method of claim 1, comprising:

mapping the provider model represented by the tagged provider resource onto the template model associated with the platform at runtime.

7. The method of claim 1, wherein mapping the provider model represented by the tagged provider resource onto the template model associated with the platform includes binding the provider with a plurality of other providers capable of being plugged into the platform.

8. A system for registering a provider with a platform, comprising:

a processor;

a platform;

an abstraction layer; and

a tagging layer;

wherein;

the platform provides a request for a normalized input to the tagging layer via the abstraction layer and provisions, monitors, services, deploys, and provides lifecycle management for an application across the provider, wherein the platform and the provider are systems independent of each other;

the tagging layer;

provides an evaluated input request to the provider in response to receiving the request for a normalized input;

tags a provider resource received as a response to the evaluated input request such that that tagged provider resource includes a representation of a provider model; and

provides the tagged provider resource to the abstraction layer;

the abstraction layer provides a normalized resource to the platform as a response to the request for a normalized input, the normalized resource including the tagged provider resource; and

the platform plugs the provider into the platform at runtime by mapping the provider model represented by the tagged provider resource included in the normalized resource onto a template model associated with the platform,

wherein the platform plugs the provider into the platform such that the provider remains independent of hardware and software components associated with the platform and a plurality of other providers capable of being plugged into the platform.

9. The system of claim 8, wherein:

the platform provides the request for a normalized input to the abstraction layer via a common application programming interface (API); and

the abstraction layer provides the request for a normalized input to the tagging layer via a provider implemented API.

10. The system of claim 8, wherein the platform maps the provider model represented by the tagged provider resource included in the normalized resource onto the template model associated with the platform includes binding the provider with a plurality of other providers capable of being plugged into the platform.

11. A non-transitory computer-readable medium storing instructions for registering a provider with a platform, the instructions, when executed by at least one processor, cause the at least one processor to:

receive a request for a normalized input from the platform via at least one of a common application programming interface (API) and a provider implemented API, wherein the platform and the provider are systems independent of each other, and wherein the platform to provision, monitor, service, deploy, and provide lifecycle management for an application across the provider;

provide, based on the request, an evaluated input request to the provider;

tag a provider resource received as a response to the evaluated input request such that that tagged provider resource includes a representation of a provider model; and

provide a normalized resource to the platform as a response to the request for the normalized input, the normalized resource including the tagged provider resource,

plug the provider into the platform at runtime by mapping the provider model represented by the tagged provider resource included in the normalized resource onto a template model associated with the platform.

12. The non-transitory computer-readable medium of claim 11, wherein the instructions, when executed by at least one processor, cause the at least one processor to:

receive the request for a normalized input from the platform via the common API and provider implemented API, the provider implemented API defining a communication format that is accessible to the provider.

13. The non-transitory computer-readable medium of claim 11, wherein the instructions, when executed by at least one processor, cause the at least one processor to:

receive a message including the provider resource from the provider as a response to the evaluated input request, the message being in a format accessible to the provider.

14. The non-transitory computer-readable medium of claim 11, wherein mapping the provider model represented by the tagged provider resource onto the template model associated with the platform includes binding the provider with a plurality of other providers capable of being plugged into the platform.

15. The non-transitory computer-readable medium of claim 11, wherein the instructions, when executed by at least one processor, cause the at least one processor to:

plug the provider into the platform such that the provider remains independent of hardware and software components associated with the platform.

16. The non-transitory computer-readable medium of claim 11, wherein the instructions, when executed by at least one processor, cause the at least one processor to:

plug the provider into the platform such that the provider remains independent of a plurality of other providers plugged into the platform.

17. The non-transitory computer-readable medium of claim 11, wherein the instructions, when executed by at least one processor, cause the at least one processor to:

plug the provider into the platform after runtime by receiving a dynamically allocated Internet protocol (IP) address associated with the provider and tagging the dynamically allocated IP address after runtime.