System and method for compilation-time dependency injection and delayed service activation framework

Abstract

In accordance with an embodiment, described herein is a system and method for providing a compilation-time dependency injection and delayed service activation framework that includes generating source code reflecting dependencies and enabling application developers using the system to build micro-service applications or cloud native services. The framework includes using a service registry in the form of an interface or API that describes the functionality of each service and its dependencies on other services, the service registry providing delayed service activation and meta-information associated with one or more services. Use of a particular service by an application may be intercepted and adapted during code generation at the time of compilation, thereby avoiding the need to use reflections.

Description

[0001] Copyright Notice

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] Priority claim

[0004] This application claims the benefit of priority to U.S. Provisional Patent Application No. 17 / 958,132, filed on September 30, 2022, entitled “SYSTEM AND METHOD FOR COMPILE-TIME DEPENDENCY INJECTION AND LAZY SERVICE ACTIVATION FRAMEWORK,” which is hereby incorporated by reference and its contents. Technical Field

[0005] Embodiments described herein relate generally to cloud computing and software development, and more particularly to systems and methods for providing a compile-time dependency injection and deferred service activation framework, including source code generation, that can be used to build microservice applications or cloud-native services. Background Art

[0006] A microservices environment presents a software application as a collection of loosely coupled services that can be deployed independently and communicate with each other over a network (e.g., a cloud network that may be provided by a cloud computing environment).

[0007] For example, a microservices approach can be used to develop a software application or service to be provided as a cloud-native application or service in a cloud computing environment. Summary of the invention

[0008] According to an embodiment, systems and methods are described herein for providing a compile-time dependency injection and deferred service activation framework, including source code generation, that can be used to build microservice applications or cloud-native services.

[0009] The framework includes the use of a service registry in the form of an interface or API that describes the functionality of each service and its dependencies on other services, the service registry providing delayed service activation and meta information associated with one or more services.

[0010] An application's use of a particular service can be intercepted and adapted during code generation at compile time, avoiding the need to use reflection. The extensibility feature allows application developers to provide their own code generation templates, or to provide alternative service implementations for use with the application instead of the reference implementation provided by the framework.

[0011] In this manner, the described systems and methods provide a minimalistic, fully static, compile-time based dependency injection framework that can be used, for example, with Java applications and that complies with injection specifications such as JSR-330. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 Various examples of a microservices environment providing a software development framework according to an embodiment are illustrated.

[0013] Figure 2 Further illustrated are various examples of a microservices environment providing a software development framework according to an embodiment.

[0014] Figure 3 Further illustrated are various examples of a microservices environment providing a software development framework according to an embodiment.

[0015] Figure 4 Further illustrated are various examples of a microservices environment providing a software development framework according to an embodiment.

[0016] Figure 5 The use of a microservices environment to develop applications for use as services in a cloud computing environment is illustrated according to an embodiment.

[0017] Figure 6 Further illustrated is the use of a microservices environment to develop applications for use in a cloud computing environment according to an embodiment.

[0018] Figure 7 A system providing a compile-time dependency injection and deferred service activation framework according to an embodiment is illustrated, which can be used to develop applications for use in a cloud computing environment.

[0019] Figure 8 Illustrated is the use of compile-time dependency injection in developing an application according to an embodiment.

[0020] Fig. 9 Further illustrated is the use of compile-time dependency injection in developing an application according to an embodiment.

[0021] Fig.10 Further illustrated is the use of compile-time dependency injection in developing an application according to an embodiment.

[0022] Fig.11Further illustrated is the use of compile-time dependency injection in developing an application according to an embodiment.

[0023] Fig.12 A method of developing applications for use in a cloud computing environment using a compile-time dependency injection and deferred service activation framework according to an embodiment is illustrated. DETAILED DESCRIPTION

[0024] A microservices environment presents a software application as a collection of loosely coupled services that can be deployed independently and communicate with each other over a network (e.g., a cloud network that may be provided by a cloud computing environment).

[0025] For example, a microservices approach can be used to develop software applications or services to be provided as cloud native applications or services in a cloud computing environment. Software development frameworks such as Helidon facilitate the development of microservices. For example, as described below, Helidon provides various Standard Edition (SE), MicroProfile (MP), and / or Nima programming models or environments, each of which includes a collection of software libraries that support features such as configuration, security, or web server functionality; and provides software application developers with a foundation for creating microservices.

[0026] In general, this software development framework relieves application developers from the need to program according to specific tools or deployment models and enables running microservices without an application server. The Helidon library can interoperate with other software development, deployment and / or monitoring tools (such as, for example, Docker, Kubernetes, Prometheus, or OpenTracing).

[0027] Microservice environment

[0028] Figure 1-4 Various examples of a microservices environment providing a software development framework according to an embodiment are illustrated.

[0029] According to an embodiment, Figure 1-4 The components and processes shown in and as further described herein with respect to various embodiments may be provided as computer software or program code executable by a computer system or other type of processing device (eg, a cloud computing system).

[0030] like Figure 1 As shown in , according to an embodiment, the Helidon microservice environment 100 can provide a Standard Edition (SE) 110, a MicroProfile (MP) 120 and / or a Helidon Nima 130 programming model or environment.

[0031] According to various embodiments, the microservices environment may also enable developed applications to interact with the cloud, database, or other systems or services 140 .

[0032] like Figure 2 As shown in , according to an embodiment, the Helidon SE environment supports a functional programming style that directly uses web server, security, and configuration components; provides transparency and control to application developers; and supports Java features such as reactive streams and asynchronous and functional programming.

[0033] According to an embodiment, the Helidon SE environment provides a framework through which application developers can build lightweight reactive microservices. For example, the Helidon SE environment may include various libraries, application program interfaces (APIs), or other components, such as, for example, a reactive web server 111 that provides an asynchronous and reactive API for creating web applications; a configuration API 112 that provides a Java API to load and process configuration properties in key / value form into a configuration object, which the application can then use to retrieve configuration data; and a security component 113 that provides authentication, authorization, and outbound security; and may also include metrics 114, health checks 115, and tracking 116 or other components.

[0034] like Figure 3 As shown in, according to an embodiment, the Helidon MP environment supports a declarative programming style by using the MicroProfile family of APIs built on top of the Helidon library. MicroProfile definitions (e.g., as specified by the Eclipse MicroProfile project) can be used to support application portability across multiple MicroProfile runtimes.

[0035] For example, according to an embodiment, the Helidon MP environment may include various libraries, APIs, or other components, such as, for example, JAX-RS 122, JSON-P 126, CDI 124, metrics 121, health checks 123, fault tolerance 125, MicroProfile configuration 137, and JWT authentication 128 components. The web server may be provided by a non-blocking client / server / web framework 118 such as, for example, Netty.

[0036] like Figure 4 As shown in , according to an embodiment, the Helidon Nima environment provides a Loom-based implementation of a web server and related libraries and features that can be used to build cloud-native services.

[0037] For example, according to an embodiment, the Helidon Nima environment may include using various components or features that support, for example, HTTP headers 131, client and server connection abstractions 132, router abstractions 133, and connection protocol identifiers 134, through which application developers can build, for example, blocking (rather than reactive) microservices.

[0038] Figure 5 The use of a microservices environment to develop applications for use as services in a cloud computing environment is illustrated according to an embodiment.

[0039] According to an embodiment, a microservices environment presents a software application as a collection of loosely coupled services that are independently deployable and communicate with each other over a network (eg, over a cloud network that may be provided by a cloud computing environment).

[0040] For example, according to an embodiment, the Helidon microservice environment can support the use of a remote procedure call (e.g., gRPC) framework or component, which enables (client and / or server) applications to communicate within a microservice environment to build a connected system. The remote procedure call framework enables the definition of services and methods that can be called remotely. The server or service can handle calls from the client via a local object (stub), which enables the client application to directly call methods on the server application as if it were a local object. The server / service implements methods for handling client calls, including decoding incoming requests, executing service methods, and encoding service responses. The local object (stub) implements the same methods as the service, wraps the parameters for the call in the appropriate protocol buffer message type, and then provides it as a request to the server.

[0041] Figure 6 Further illustrated is the use of a microservices environment to develop applications for use in a cloud computing environment according to an embodiment.

[0042] like Figure 6 As shown in , according to an embodiment, the microservice library enables client applications to access to communicate with microservices or interact with clouds, databases, or other systems or services to access data, process transactions, or perform other operations associated with these systems or services.

[0043] The examples of various embodiments of the above-described Helidon microservices environment are provided to illustrate an example microservices computing environment. According to various embodiments, the systems and methods described herein can be used with other types of microservices environments or computing environments.

[0044] Compile-time dependency injection

[0045] According to an embodiment, this document describes a system and method for providing a compile-time dependency injection and delayed service activation framework (referred to as Pico in some embodiments herein), which includes generating source code that reflects dependencies and enables application developers to use the system to build microservice applications or cloud-native services.

[0046] According to an embodiment, the framework includes using a service registry in the form of an interface or API that describes the functionality of each service and its dependencies on other services, the service registry providing delayed service activation and meta information associated with one or more services.

[0047] According to an embodiment, an application's use of a particular service can be intercepted and adapted during code generation at compile time, thereby avoiding the need to use reflection. The extensibility feature allows application developers to provide their own code generation templates, or to provide alternative service implementations for use with the application, rather than the reference implementation provided by the framework.

[0048] In this way, the described systems and methods provide a minimalist, fully static, compile-time based dependency injection framework that can be used, for example, with Java applications and conforms to injection specifications such as Java Specification Request 330 "Java Dependency Injection Standard" (JSR-330).

[0049] Figure 7 A system providing a compile-time dependency injection and deferred service activation framework according to an embodiment is illustrated, which can be used to develop applications for use in a cloud computing environment.

[0050] like Figure 7 As shown in , a user (e.g., an application developer) can interact with a compile-time dependency injection and deferred service activation framework 200 (including its compile-time dependency injection 210 and service activation 220 functions) to develop and compile applications that include dependency injection 230 and prepare the applications as compiled code 240 for activation and execution within a cloud computing environment, such as as a microservice application or a cloud native service.

[0051] According to various embodiments, a compile-time dependency injection and deferred service activation framework provides components, processes, and features including, for example:

[0052] Dependency Injection - Within the application being developed, assigning a service instance to a correspondingly annotated field or method setter, for example, using an injection point (e.g., @inject or another form of dependency injection annotation).

[0053] Injection plan - The process performed by the framework to determine how the application being developed resolves each injection point associated with it. The system can optionally perform injection planning at compile time; alternatively, when the injection plan is deferred to runtime, it can be resolved by the framework without reflection, which complies with native image limitations and provides application performance benefits.

[0054] Service - One or more class types in the application being developed that represent data processing or logic, eg, business logic, such as, for example, a bean annotated with @service.

[0055] Scope - The cardinality of service instances in the application being developed.

[0056] Singleton - Where appropriate, the Singleton scope of the service, such as for example jakarta.inject.Singleton or javax.inject.Singleton. This is the default scope for services provided within the framework.

[0057] Provided - The provided scope of the service, such as, for example, jakarta.inject.Provider or javax.inject.Provider, where appropriate. If the scope of the service is not Singleton (as described above), then the scope is considered to be Provided, and its cardinality will be attributed to the Provider implementation to determine the cardinality. The provider may optionally use the injection point context to determine the appropriate instance and / or cardinality of its provision.

[0058] Contracts - Services can specify aliases for themselves to be processed for injection. Contracts can be provided as interfaces or APIs (e.g., abstract base class definitions) that services implement. Injection points can be included using contracts or services that the framework is aware of through compile-time annotation processing.

[0059] Qualifier - meta-information or annotations that can be attributed to other annotations, such as, for example, jakarta.inject.qualifier or javax.inject.qualifier, where appropriate. According to an embodiment, the built-in qualifier type is @Named in the same package.

[0060] Dependency - Another way to describe an injection point, it indicates for example which data processing or logic is considered a dependency, possibly indicated as qualified, or as optional on another service or contract.

[0061] Activator (Service Provider) - Framework generated code that lazily activates service instances in the service registry and takes care of resolving dependencies therein, along with injecting, for example, fields or methods that need to be satisfied as part of the activation process.

[0062] Service Registry - A collection of all services known to the framework and application runtime.

[0063] Module - A process or component by which an application under development binds services to a service registry, which may be generated by system code and may include, for example, one module per Java Archive (JAR) or modules within an application.

[0064] Figure 8-11 Further illustrated is the use of compile-time dependency injection in developing an application according to an embodiment.

[0065] In some software development environments that utilize dependency injection, application classes are analyzed at runtime to detect injection points, for example, as described in accompanying XML or JSON files.

[0066] According to embodiments as described herein, a compile-time dependency injection and deferred service activation framework instead performs its dependency injection processing at compile time using one or more compile-time and / or runtime libraries that can accommodate common use cases.

[0067] According to an embodiment, the framework supports the use of an inversion-of-control programming model. For example, in a traditional control flow programming model, an application developer prepares application code that defines, for example, program calls to a library to perform a specific task—the inversion-of-control programming model inverts the control flow so that the framework instead calls the application code prepared by the developer to perform the specific task.

[0068] According to an embodiment, since the framework can operate using the abstraction of modules or classes without having to operate using specific implementations supporting these classes, the framework can be used with Helidon or other microservice environments, examples of which are described above, allowing application developers to use traditional control flow programming models or inversion of control programming models depending on their preferences and development needs.

[0069] According to an embodiment, the framework may also be used outside of or independent of a Helidon-type microservice environment, such as for any Java programming or development environment where an inversion of control programming model is desired.

[0070] like Figure 8As shown in , according to an embodiment, each of one or more software objects A 234, B 235 within the application being developed is associated with an injection point; these injection points will be resolved by the framework at compile time into one or more services A 262, B ​​264 according to the injection plan 232, and provide service instances 236, 237 respectively.

[0071] According to an embodiment, software classes are generated by the framework at compile time, which allows application developers to inspect their applications, for example, to detect potential problems before runtime. Application developers also have the opportunity to review the generated code more closely. Providers can further extend the framework for use with other source code generation and dependency injection processes.

[0072] For example, JSR-330 provides various types for dependency injection and allows supporting implementations to be filled in at compile time. Classes can be generated based on the dependency graph and inserted into the application at compile-time injection points.

[0073] According to an embodiment, the framework can generate dependencies into the application source code (e.g., JAR) at compile time using type indications or annotations, so that the dependencies are provided as, for example, Java source code in the application itself and have been verified. This process produces an application with a smaller footprint and higher runtime performance (e.g., faster).

[0074] like Fig. 9 As shown in, according to an embodiment, the framework annotation processor looks for standard jakarta / javax injection and jakarta / javax annotation types. When these types are found in a class compiled by, for example, javac, the framework will trigger the creation of an activator (service provider) 268, 269 for the service class / type.

[0075] For example, if the application being developed includes a FooImpl class that implements the Foo interface, and the FooImpl class contains the @Inject or @Singleton annotation, then the presence of either of these two annotations will trigger the framework to create an appropriate activator (e.g., FooImpl$$picoActivator).

[0076] In accordance with an embodiment, an activator is used to (a) describe a service in terms of what the service contract (i.e., interface) is announced to be (e.g., in the case of FooImpl described above, this would include Foo if Foo was annotated with @Contract or "io.helidon.pico.autoAddNonContractInterfaces=true" was used at compile time); and (b) provide a lifecycle for the service, including creation, calling injection-based setters, and any methods such as PostConstruct or PreDestroy.

[0077] like Fig.10 As shown in , according to an embodiment, if one or more activators are created at compile time, modules X 243, Y 247 (eg, picoModule) are also created to aggregate the services of a given module.

[0078]

[0079]

[0080] Upon initialization, all modules will be located using a service locator (eg, ServiceLocator), and each service will be bound (268, 269) to the service registry 266.

[0081] According to an embodiment, if an annotation in a service is meta-annotated with the InterceptedTrigger annotation, then an additional service type is created. For example, in the case of FooImpl as described above, if FooImpl is found to have such an annotation, then a FooImpl$$picoInterceptor will also be created along with an activator for that interceptor. The interceptor will be created with a higher weight than FooImpl, and will therefore be considered "preferred" when a single @inject is used on either Foo or FooImpl. If a list is injected, then it will appear at the head of the list, again avoiding the need for reflection in the generated classes. Any call to Foo / FooImpl will be interceptable by any interceptor @Named to handle that type name.

[0082] like Fig.11 As shown in , according to an embodiment, the application as compiled code (including its modules 244, 248) can then be activated and executed within a cloud computing environment, for example as a microservice application or a cloud native service.

[0083] According to an embodiment, optionally, a Maven plugin can be used to avoid lookup resolution at runtime within each service activation. At startup, the framework will try to use the application module first to avoid lookup. Best practice is to apply the maven-plugin to the create-application on the maven assembly - this is usually the "final" application module that depends on every other service / module in your entire deployed application. The maven-plugin can additionally be used to create dependency injection support types (e.g., activators, modules, interceptors, applications, etc.) by inspecting external JARs.

[0084] According to an embodiment, modules are generated by the framework based on templates, which can be system-provided or user-provided. During compilation, a service can indicate which contracts and dependencies it provides; the framework then provides the concretization of each service (and each module) in the application. This provides application developers with a view of the application code, such as, for example, which specific implementations are binding to which specific services.

[0085] In the following example, the framework generates a suggested module-info.java that includes an analysis of the application's injection plan or dependency model:

[0086]

[0087]

[0088] In the example above, the framework can determine or infer what the module exports; and which modules are required due to which external contracts, in order to be used during application compilation.

[0089] Scalable SPI

[0090] According to an embodiment, a compile-time dependency injection and delayed service activation framework provides an extensible SPI-based mechanism that allows provided services to be overridden, extended, or replaced with implementations different from those provided outside of the included built-in reference implementation modules. In order to become a provider implementation, a provider must supply an implementation of PicoServices that can be discovered by a service loader (ServiceLoader) with a higher than default Weight.

[0091] According to an embodiment, SPI class definitions in the io.helidon.pico.spi package are considered primitive and therefore should not participate in injection or be considered injectable conventionally. Service classes that are not injection targets should be defined in / META-INF / services / <serviceclassname>The following representation is used so that it can be found by the standard service locator (ServiceLocator).

[0092] Providers are encouraged to fail fast at compile time, which means that a set of tools can be applied to create and verify the completeness of the dependency graph at compile time rather than runtime. Providers are also encouraged to avoid reflection completely at runtime; and use, for example, PicoServicesConfig to advertise capabilities and configuration.

[0093] Modules

[0094] According to an embodiment, the compile-time dependency injection and delayed service activation framework provides various modules, for example including:

[0095] api module - API and SPI for frameworks (e.g. Pico); it depends on jakarta-inject and jakarta-annotations. For runtime use, it is required as a maven compile-time dependency.

[0096] pico module - contains the default JSR-330 implementation of the (Pico) API / SPI; depends on the api module. For runtime use, required as a Maven compile-time dependency.

[0097] Tools module - a library containing template-based code generation and model validation tools. Only required at build time and not at runtime.

[0098] Processor module - contains libraries for annotation processing; tool dependent. Only required at build time and not at runtime.

[0099] maven-plugin module - provides code generation wrapper for maven; tool dependent. Only needed at build time, and not at runtime.

[0100] Type Module

[0101] According to an embodiment, the types module contains types that are generally applicable to any (e.g., Pico-based) application implementation. The API is consumer-oriented and small, as most of the supported types actually come from the javax / jakarta injection and annotation modules. The SPI package supports runtime implementations and is generally not of interest to most application developers using dependency injection. The only aspects of the SPI that need to be used directly are the PicoServices and Services classes, as these classes are used to activate one or more startup services that make up a (Pico) application.

[0102] Tool Module

[0103] According to an embodiment, the default tool module is responsible for providing basic tools around code generation and dependency model analysis during compile time.All services are based on the standard ServiceLocator and use standard request / response mechanisms in the API.

[0104] io.helidon.pico.tools.creator.ApplicationCreator

[0105] This tool creates for example picoApplication.

[0106] io.helidon.pico.tools.creator.ActivatorCreator

[0107] This tool creates, for example, picoActivator(s) and picoModule(s).

[0108] io.helidon.pico.tools.creator.ExternalModuleCreator

[0109] This tool creates and analyzes the requests of third-party JARs, and then generates the appropriate request payload to be handed over to the ActivatorCreator tool to generate code.

[0110] io.helidon.pico.tools.creator.InterceptorCreator

[0111] This tool is called when it finds an InterceptorTrigger on the service that needs to be intercepted.

[0112] Processor module

[0113] According to an embodiment, the default-tools-processor module provides only compile-time annotation processing and is designed to look for javax / jakarta injection type annotations and then code-generate support for dependency injection classes to support the dependency injection model at runtime in a standard (e.g., JSR-330 compliant) manner, including utilizing the tool module to perform necessary code generation when these annotations are found.

[0114] For example, during the build of their application, an application developer can modify pom.xml to add this plugin to run as part of the compile phase:

[0115]

[0116]

[0117] Additional Features

[0118] According to an embodiment, a compile-time dependency injection and deferred service activation framework provides a means to generate "activators" (dependency injection support types) for external building blocks as well as support javax annotation types.

[0119] According to an embodiment, if a service contains an annotation that is itself annotated with InterceptorTrigger, then the code generated for the service will support interception. The compile-time dependency injection and deferred service activation framework provides meta information for each service in its service registry, including information such as what contracts each service provides and describing its dependencies.

[0120] According to an embodiment, the compile-time dependency injection and lazy service activation framework generates a suggested module-info.java file for your module (look for module-info.java.pico under . / target / classes or . / target / test-classes).

[0121] According to an embodiment, a compile-time dependency injection and delayed service activation framework provides a maven plugin that allows (a) verification of the integrity of the injection graph and (b) deterministic binding to service implementations at compile time. Each example demonstrates this, resulting in problems being detected as early as possible at compile time rather than at runtime, and significantly improving performance.

[0122] According to an embodiment, the testable (*) service module t provides a set of types to facilitate the creation of fake / mock services for various testing scenarios.

[0123]

[0124] According to an embodiment, the framework is designed to scale from a micro level (application developers can override mustache / handlebar templates) to a macro level (application developers can provide their own SPI implementations).

[0125] Example Method

[0126] Fig.12 A method of using a compile-time dependency injection and deferred service activation framework to develop applications for use in a cloud computing environment according to an embodiment is illustrated.

[0127] like Fig.12 As shown in , according to an embodiment, at step 282, a computer including one or more processors and a memory provides a microservice environment (microservice library), and a compile-time dependency injection and delayed service activation framework is provided in association with the microservice environment, which supports the use of inversion of control as a programming model.

[0128] At step 284, one or more services may be made available for injection, where the contract provides an interface or abstract base class definition of the service implementation for use with the injection point at compile time.

[0129] In step 286, within the application being developed, the injection point operates by assigning the service instance to a field or method setter that has been annotated with @inject or another form of dependency injection annotation.

[0130] At step 287, the framework generates an activator (service provider) to lazily activate the service instance in the service registry and handles resolving all dependencies, along with injecting fields, methods, etc. that need to be satisfied as part of the activation process.

[0131] At step 288, the framework instead evaluates the injection points at application compile time and generates the dependencies into the application source code (eg, as an application JAR).

[0132] Sample Development Process

[0133] According to an embodiment, a compile-time dependency injection and lazy service activation framework enables application developers to build microservice applications or cloud-native services.

[0134] For example, to illustrate the development process, during the creation of their application, an application developer may add comments to a pom.xml or gradle.build file such as:

[0135] Annotation processor dependencies / paths:

[0136]

[0137] Compile-time dependencies:

[0138]

[0139]

[0140] According to an embodiment, an application can be developed using standard jakarta.inject.* and jakarta.annotation.* types; then built; and run. Since the framework effectively owns the creation of services according to the scope of each service declaration, the application developer must create the requirements for the initial service(s) rather than calling new services directly in the application code. This can be achieved by looking up the service directly using the service SPI, for example:

[0141]

[0142] According to an embodiment, if there is a set of services that need to be activated at startup, then these service implementation types can be annotated with RunLevel (RunLevel.STARTUP) and appropriate code can be provided in main() to activate these services lazily.

[0143] Whenever list-based injection is used, all services matching the injection criteria will be in an injected (and immutable) list. The list will be ordered from highest weight to lowest weight based on the Weight annotation value. If a service is not explicitly weighted then a default weight will be assigned. If two services have the same weight then a secondary ordering will be based on the FN class name of the service type.

[0144] While Weight determines the listing order, the RunLevel annotation is used to rank the startup order, from lowest value to highest value, where RunLevel.STARTUP == 0. Application developers are expected to activate these directly using code such as the following (where get() lazily creates and activates the underlying service type):

[0145]

[0146]

[0147] If the order of the service list is important, the application developer can use the Weight and / or RunLevel annotations to establish priority, weighted order, or startup order.

[0148] According to various embodiments, the teachings herein can be conveniently implemented using one or more conventional general or special computers, computing devices, machines or microprocessors, including one or more processors, memories and / or computer-readable storage media programmed according to the teachings of the present disclosure. A skilled programmer can easily prepare appropriate software coding based on the teachings of the present disclosure, as will be apparent to those skilled in the art of software.

[0149] In some embodiments, the teachings herein may include a computer program product, which is (one or more) non-transient computer-readable storage medium having instructions stored thereon / in which can be used to program a computer to perform any of the processes of the present teachings. Examples of such storage media may include, but are not limited to, hard disks, hard drives, fixed disks or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for non-transient storage of instructions and / or data.

[0150] The above description is provided for the purpose of illustration and description. It is not intended to be exhaustive or to limit the scope of protection to the precise form disclosed. For those skilled in the art, many modifications and variations will be apparent.

[0151] For example, although various embodiments of the systems and methods described herein illustrate use in a Helidon microservices environment, the various embodiments may be used with other types of microservices environments or other computing environments.

[0152] The embodiments were chosen and described in order to best explain the principles of the present teachings and their practical applications, thereby enabling others skilled in the art to understand the various embodiments and with various modifications as are suited to the particular use contemplated. The scope is intended to be defined by the following claims and their equivalents.< / serviceclassname>

Claims

1. A system for use with a microservice or other computing environment, comprising: A computer, including one or more processors, providing access to a microservice or other computing environment for use with the software application or service; as well as A compile-time dependency injection and deferred service activation framework that includes source code generation and can be used to build microservice applications or cloud-native services; Among them, for applications under development: Make one or more services available for injection; Within the application being developed, an injection point operates by assigning a service instance to a field or method setter that has been annotated accordingly; The system generates an activator to handle the resolution of dependencies that need to be satisfied as part of the activation process; The system evaluates injection points at compile time and generates dependencies into the application source code.

2. The system of claim 1, wherein the system comprises: A service registry is used that provides deferred service activation and meta information associated with one or more services in the form of an interface or API that describes the functionality of each service and its dependencies on other services.

3. The system of claim 1, wherein the application's use of a particular service can be intercepted and adapted during code generation at compile time, thereby avoiding the need to use reflection.

4. The system of claim 1, wherein the compile-time dependency injection and delayed service activation framework is provided for use with Helidon or other microservice development environments.

5. The system of claim 1, wherein the system is used to build microservice applications or cloud-native services for execution in a cloud computing environment.

6. A method for use with a microservice or other computing environment, comprising: A system associated with a microservices or other computing environment for use with a software application or service is provided, the system including a compile-time dependency injection and deferred service activation framework, including source code generation, that can be used to build a microservices application or a cloud-native service; Among them, for applications under development: Make one or more services available for injection; Within the application being developed, an injection point operates by assigning a service instance to a field or method setter that has been annotated accordingly; The system generates an activator to handle the resolution of dependencies that need to be satisfied as part of the activation process; The system evaluates injection points at compile time and generates dependencies into the application source code.

7. The method of claim 6, wherein the system comprises: A service registry is used that provides deferred service activation and meta information associated with one or more services in the form of an interface or API that describes the functionality of each service and its dependencies on other services.

8. The method of claim 6, wherein the application's use of a particular service can be intercepted and adapted during code generation at compile time, thereby avoiding the need to use reflection.

9. The method of claim 6, wherein the compile-time dependency injection and delayed service activation framework is provided for use with Helidon or other microservice development environments.

10. The method of claim 6, wherein the system is used to build microservice applications or cloud native services for execution in a cloud computing environment.

11. A non-transitory computer-readable storage medium comprising instructions stored thereon, which, when read and executed by a system comprising one or more computers, causes the system to perform a method comprising: Providing a compile-time dependency injection and deferred service activation framework associated with a microservice or other computing environment for use with a software application or service, including source code generation, capable of being used to build a microservice application or cloud-native service; Among them, for applications under development: Make one or more services available for injection; Within the application being developed, an injection point operates by assigning a service instance to a field or method setter that has been annotated accordingly; The system generates an activator to handle the resolution of dependencies that need to be satisfied as part of the activation process; The system evaluates injection points at compile time and generates dependencies into the application source code.

12. The non-transitory computer-readable storage medium of claim 11, wherein the system comprises: A service registry is used that provides deferred service activation and meta information associated with one or more services in the form of an interface or API that describes the functionality of each service and its dependencies on other services.

13. The non-transitory computer-readable storage medium of claim 11, wherein the application's use of a particular service can be intercepted and adapted during code generation at compile time, thereby avoiding the need to use reflection.

14. The non-transitory computer-readable storage medium of claim 11, wherein the compile-time dependency injection and delayed service activation framework is provided for use with Helidon or other microservice development environments.

15. The non-transitory computer-readable storage medium of claim 11, wherein the system is used to build microservice applications or cloud-native services for execution within a cloud computing environment.

Images