Network device for distributing computing operations by data communication in a network
US-12164880-B2 · Dec 10, 2024 · US
US2017187785A1 · US · A1
| Field | Value |
|---|---|
| Publication number | US-2017187785-A1 |
| Application number | US-201514998175-A |
| Country | US |
| Kind code | A1 |
| Filing date | Dec 23, 2015 |
| Priority date | Dec 23, 2015 |
| Publication date | Jun 29, 2017 |
| Grant date | — |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A microservice may be developed comprising application programming interfaces (APIs), a user interface, logic, and data received from at least one backend system, wherein the APIs and the user interface are decoupled from the logic and the at least one backend system, and the user interface, the logic and the data are decomposable into modules that may be shared with a different microservice. The microservice may expose a set of functions sufficient to support a target use case and Recycle management of the microservice, comprising at least one of exposing lifecycle management APIs and providing lifecycle self-management functionality.
Opening claim text (preview).
1 . A method, comprising: developing a microservice that comprises application programming interfaces (APIs), a user interface, logic, and data received from at least one backend system, wherein the APIs and the user interface are decoupled from and interact with the logic and the at least one backend system, and the user interface, the logic and the data are decomposable into modules that may be shared with a different microservice; and exposing via the microservice a minimal set of functions sufficient to support a target use case and to provide lifecycle management of the microservice, comprising at least one of exposing lifecycle management APIs and providing lifecycle self-management functionality. 2 . The method of claim 1 , comprising exposing the lifecycle management APIs to enable external management of the microservice. 3 . The method of claim 1 , wherein lifecycle management operations are performed at the microservice or at a microservice layer level. 4 . The method of claim 1 , comprising scaling the modules and layers of the modules. 5 . The method of claim 1 , comprising performing an orchestrated execution of an end-to-end process via interactions of the backend systems. 6 . The method of claim 1 , wherein the APIs and the user interface are decoupled from the logic and the at least one backend system via an orchestrated message broker. 7 . The method of claim 1 , comprising: exposing by the microservice a function provided the at least one backend system; implementing the target use case that utilizes at least one of the functions; and changing a location where the function is performed without modifying the implementation of the target use case. 8 . The method of claim 1 , comprising building the microservice automatically decoupled via an orchestrated message broker or a composition of an API mashup or a UI mashup. 9 . The method of claim 1 , wherein the microservice comprises an application that is repurposed by exposing at least a portion of the application's capabilities through a functional interface. 10 . The method of claim 1 , wherein a selected backend system of the at least one backend system executes a function exposed by the microservice, and wherein replacing the selected backend system with either a different backend system or composition of multiple backend systems results in the function remaining substantially unchanged. 11 . A system, comprising: a microservice comprising application programming interfaces (APIs), a user interface, logic, and data received from backend systems, wherein the user interface, the logic and the data are decomposable into modules that may be shared with a different microservice, and the APIs and the user interface interact with the logic and the backend systems; and an orchestrated message broker that is to decouple the APIs and the user interface from the logic and the backend systems; wherein the microservice is to expose a minimal set of functions sufficient to support a target use case and to provide lifecycle management of the microservice, the lifecycle management comprising at least one of lifecycle self-management functionality and a lifecycle management API that is exposed to enable external lifecycle management of the microservice. 12 . The system of claim 11 , wherein an element of one of the modules may communicate with a first logical endpoint of the microservice and a different logical endpoint of the different microservice. 13 . The system of claim 11 , wherein the orchestrated message broker performs an orchestrated execution of an end-to-end process via interactions of the backend systems. 14 . The system of claim 11 , wherein the logic and the data are geographically separated. 15 . The system of claim 11 , wherein the backend systems comprise at least one of an identity management system, a support system, a cloud service system, a knowledge management system, and a catalog management system. 16 . A non-transitory machine-readable storage medium encoded with instructions executable by a processor to provide a software development kit (SDK) for developing a microservice, the machine-readable storage medium comprising: instructions to develop a microservice comprising application programming interfaces (APIs), a user interface, logic, and data received from at least one backend system, wherein the user interface, the logic and the data are decomposable into modules that may be shared with a different microservice, the APIs and the user interface are decoupled from the logic and the at least one backend system, a minimal set of functions sufficient to support a target use case is exposed via the microservice, and lifecycle management of the microservice is provided by at least one of exposing lifecycle management APIs and providing lifecycle self-management functionality. 17 . The non-transitory machine-readable storage medium of claim 16 , wherein the instructions to develop the microservice comprise instructions to provide lifecycle management by exposing the lifecycle management APIs of an application that forms a portion of the microservice, wherein the lifecycle management APIs are selected from the group consisting of a deployment API comprising a payload served with a package comprising the application; a patch API that accepts runtime dependency changes for the application; an upgrade API that accepts application dependency changes that introduce at least one of data model adjustments, changes to a location of persistence of the microservice, and changes to a type of persistence of the microservice; a monitoring API that collects metrics of the microservice; a remediation API that enables duplication, clustering, moving, and scaling of the microservice; and a decommission API that defines a decommission process in which data related to the microservice is aggregated and sent to an archiving service. 18 . The non-transitory machine-readable storage medium of claim 17 , wherein the lifecycle management APIs comprise the deployment API, and the payload comprises a data interchange file that is a validated component of the microservice. 19 . The non-transitory machine-readable storage medium of claim 17 , wherein the lifecycle management APIs comprise the patch API, and the microservice is to inject the runtime dependency changes to replace at least one existing dependency reference. 20 . The non-transitory machine-readable storage medium of claim 17 , wherein the lifecycle management APIs comprise the upgrade API that is to send a notification of the application dependency changes to at least one other microservice interconnected with the microservice.
in which an application is distributed across nodes in the network (software deployment G06F8/60; multiprogramming arrangements G06F9/46) · CPC title
Electricity · mapped topic
using third party service providers · CPC title
Brokering proxy services · CPC title
Mailbox-related aspects, e.g. synchronisation of mailboxes · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.