Patent Application
20230379242
A portion of the disclosure of this patent document contains material which 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.
Embodiments described herein are generally related to cloud computing and other computing environments, software development, and microservice architectures, and are particularly directed to systems and methods for supporting application development, together with related libraries and features usable to build cloud-native applications or services.
Microservice environments present a software application as a collection of loosely-coupled services that are independently deployable and communicate with one another over a network, for example a cloud network as might be provided by a cloud computing environment. The microservice approach can be used, for example, to develop software applications or services to be provided in cloud computing environments as cloud-native applications or services.
In accordance with an embodiment, described herein are systems and methods for use with a microservices or other computing environment, including a web server together with related libraries and features usable to build cloud-native applications or services.
In accordance with various embodiments, the systems and methods can include the use of various components or features that support, for example: (a) HTTP headers, (b) client and server connection abstraction, (c) router abstraction, and (d) identifying a protocol of a connection.
In accordance with an embodiment, the system provides, by means of a header enumeration, an abstraction that allows message headers to be treated as objects, accessible via an application program interface (API) that supports multiple communication protocols and allows clients and servers to communicate request/response messages using any of the supported protocols. When a request message with a known header type is encountered, the system can obtain an indexed value from the enumeration, if available, and provide the associated data (e.g., as data bytes) directly to the process to which the request is directed, and/or cache the header value for later use.
In accordance with an embodiment, to support testing of software applications or services, a client connection can be replaced, for testing purposes, with an in-memory implementation that does not invoke, e.g., HTTP, but instead exposes inverse-functions to a server connection; for example, data bytes written to a data writer of a client connection are available through a data reader on a server connection, and vice versa. During testing, the in-memory implementation uses a blocking queue in memory, which emulates the use of an HTTP protocol, but without using actual sockets. Once the testing (e.g., a unit test or an integration test), has been completed using the in-memory implementation, the client and/or server code can be tested against actual sockets, for use in processing a request.
In accordance with an embodiment, the system enables configuration of a server that can operate to serve requests via multiple network or communication protocols, such as for example HTTP1, gRPC over HTTP2, and/or WebSocket. A route abstraction allows each protocol to have its own routing, e.g., an HTTP routing. A sub-abstraction can provide a more specific route, for example as an HTTP/1.1 route, or an HTTP/2 route. For a request message received via a particular protocol, the system can pick up the appropriate route for the request, and process it accordingly.
In accordance with an embodiment, to support features such as client/server connection abstraction, router abstraction, or the use of different protocols on a single socket, an extensible service provider interface (SPI) provides software methods that allow protocol identification for a request message and connection. When a connection request message is received from a client directed to a server, a determination is made as to whether the request can be appropriately handled. The protocol identification process can, for example, return an indication that the system does not support the request protocol, that it does not have enough data to make a decision, or that additional data is needed to make such a determination.
Microservice environments present a software application as a collection of loosely-coupled services that are independently deployable and communicate with one another over a network, for example a cloud network as might be provided by a cloud computing environment (cloud environment). The microservice approach can be used, for example, to develop software applications or services to be provided in cloud computing environments as cloud-native applications or services.
Software development frameworks such as Helidon can be used in the development of microservices. For example, as described below, a Helidon environment provides a collection of software libraries that support features such as configuration, security, or web server functionality; and provide a software application developer with a foundation upon which to develop cloud-native applications or services.
In accordance with an embodiment, Helidon libraries can interoperate with other software development, deployment, and/or monitoring tools such as, for example, Docker, Kubernetes, Prometheus, or Jaeger.
In accordance with an embodiment, the components and processes illustrated in
As illustrated in
The examples described herein of various embodiments of Helidon microservice environments are provided for purposes of illustrating examples of a microservice computing environment or microservice environment. In accordance with various embodiments, the systems and methods described herein can be used with other types of microservice environments or computing environments.
In accordance with various embodiments, the systems and methods can be used with other types of software development environments, or with other types of web server together with related libraries and features usable to build cloud native services.
As illustrated in
For example, in accordance with an embodiment, a Helidon SE environment provides a framework by which the application developer can build lightweight reactive microservices. The environment can include various libraries, application program interfaces (APIs), or other components, such as, for example, a reactive web server 111, which provides an asynchronous and reactive API for creating web applications; a configuration API 112, which provides a Java API to load and process configuration properties in key/value form into a config object which an application can then use to retrieve config data; and a security component 113, which provides authentication, authorization, and outbound security; and can also include metrics 114, health check 115, and tracing 116 or other components.
As illustrated in
For example, in accordance with an embodiment, a Helidon MP environment can include various libraries, APIs, or other components, such as, for example, JAX-RS 122, JSON-P 126, Contexts and Dependency Injection (CDI) 124, metrics 121, health check 123, fault tolerance 125, MicroProfile (MP) configuration 137, and JSON web token (JWT) authentication 128 components. The web server can be provided by a non-blocking client/server/web framework 118, such as, for example, Netty.
As illustrated in
For example, in accordance with an embodiment, a Helidon Níma environment can include the use of various components or features that support, for example: HTTP headers 131, client and server connection abstraction 132, router abstraction 133, and connection protocol identification 134, by which an application developer can build, e.g., blocking (rather than reactive) microservices.
As illustrated in
For example, in accordance with an embodiment a 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 the microservice environment, to build connected systems.
In accordance with an embodiment, a remote procedure call framework enables definition of a service and methods that can be called remotely. A server or service can handle calls from a client, via a local object (stub) that enables a client application to directly call a method on a server application as if it were a local object. The server/service implements methods to handle client calls, including decoding incoming requests, executing service methods, and encoding service responses. The local object (stub) implements the same methods as the service, wrapping the parameters for the call in an appropriate protocol buffer message type, which is then provided as requests to the server.
In accordance with an embodiment, a microservice environment (e.g., as provided by a microservices library) enables access by a client application 154 (e.g., 154A, 154B), at a client computer device 150 (e.g., 150A, 150B) having a device hardware 152 (e.g., 152A, 152B), to communicate with microservices or interact with cloud 160, server applications 174, database 180, or other systems or services, at computer server devices 170 have a device hardware 172, for purposes of accessing data, processing transactions, or performing other operations associated with those systems or services.
As illustrated in
In a cloud environment, web services that enable client applications to interact with servers may be HTTP-based, i.e., the client applications and servers can use a HTTP communication protocol as a means of communicating requests and responses between various participants in the form of data messages.
For example, in a cloud service that provides access to one or more databases or other services, the processing of a client request may be intended to result in several initial calls, each of which can then call upon another service to perform some additional aspect of processing the request.
In some cloud environments, reactive programming techniques can be used to support concurrent processing of requests. However, since reactive programming is non-blocking, it can be difficult to troubleshoot the operation of a reactive application. For example, a thread-dump that might otherwise be useful in assessing the status of various threads provides little or no information for testing or debugging purposes when used in a reactive environment.
In accordance with an embodiment, to address such considerations, the system can include a request processing component, for example a Loom-based implementation of a web server (WebServer), together with related libraries and features usable to build a cloud native service (referred to herein in some embodiments as Helidon Níma).
In accordance with an embodiment, such a request processing component supports concurrency of client-server communications with the use of virtual threads. Such virtual threads allow client HTTP applications to operate, e.g., request connections to server processes, in a normal blocking manner, while the underlying request processing (e.g., Loom-based) environment handles concurrency of request processing.
This offers an improved code development process, in that the application developer does not have to build-in reactive programming within the application itself. Additionally, during testing or debugging, a thread dump provides more useful information for troubleshooting purposes. As such, the approach offers the features of a traditional programming environment coupled with the concurrency benefits of reactive programming.
For example, in accordance with an embodiment, a Helidon Níma environment allows an application developer to set up HTTP endpoints by which a server can serve web clients. A client application can run within the environment in a blocking manner, while taking of the virtual threading which provides a virtual thread for each connection, such that high levels of concurrency are achieved.
As illustrated in
In accordance with an embodiment, virtual threads (referred to in some examples as fibers) operate as lightweight threads that enable the execution of high-throughput concurrent applications. Generally described, a virtual thread provides an instance of an execution thread (e.g., a java.lang.Thread) which is not tied to a particular operating system (O/S) thread. An application code can run in a virtual thread for the duration of a request; the virtual thread in turn consumes an O/S thread while it performs operations on the processor.
In accordance with an embodiment, non-blocking APIs can be encapsulated by synchronous APIs, and made virtual-thread-ready, by blocking the further execution of virtual thread until the corresponding operation is completed. In this manner each virtual thread can be suspended for a period, and then continued at a subsequent time.
For example, as illustrated in
In accordance with an embodiment, such a request processing component allows the application developer to take advantage of non-blocking APIs during software development, without changing their thread-per-request programming model. The described approach also allows the system to use blocking code, such as outbound HTTP requests, or database requests, without the need to handle complicated executor services.
As illustrated in
As described above, a request processing component supports concurrency of client-server communications with the use of virtual threads. Such virtual threads allow client HTTP applications to operate, e.g., request connections to server processes, in a normal blocking manner, while the underlying request processing (e.g., Loom-based) environment handles concurrency of request processing.
For example, in accordance with an embodiment of a Helidon SE environment, the request processing component can be provided as a replacement of the reactive web server typically provided therein, wherein instead of using reactive programming, the application developer can use the virtual threads provided by the web server to support application processing that is blocking, rather than reactive, while providing similar performance aspects.
In accordance with various embodiments, the request processing component can be provided herein can similarly be provided as a web server for use with other/new versions of Helidon (e.g., Helidon Níma).
For example, in accordance with an embodiment, from the perspective of an application developer, they can include in their application either a blocking code, which directly uses the virtual threading features of request processing component, e.g., a Loom-based web server; or an application code that is itself reactive, but which the (e.g., Loom-based) web server can then process, transparently to the application developer, using the virtual threading features provided by the web server.
In accordance with various embodiments, the systems and methods can include the use of various components or features that support, for example: (a) HTTP headers, (b) client and server connection abstraction, (c) router abstraction, and (d) identifying a protocol of a connection.
In accordance with an embodiment, a web server (WebServer) can be provided as an extensible module, with a default implementation that supports the HTTP/1.1 protocol. A web server SPI provides extensibility to support, for example: upgrading from a HTTP/1 protocol, such as an upgrade to HTTP/2 using plain sockets, or an upgrade to WebSocket; other protocols, including non-HTTP protocols, extensible through discovery based on binary data, such as HTTP/2 with prior knowledge; and/or application layer protocol negotiation (ALPN) support for Transport Layer Security (TLS) requests, such as HTTP/1.1, HTTP/2.
In accordance with an embodiment, extension modules can include, for example: an HTTP/2 protocol implementation; an HTTP/2 over TCP (h2c, plain socket) upgrade from HTTP/1, with prior knowledge; an h2c (TLS) (ALPN support); a gRPC protocol implementation, as a “sub-protocol” of HTTP/2; and/or a WebSocket protocol implementation upgrade from HTTP/1.
In accordance with an embodiment, the web server supports HTTP (version-agnostic) routing, with support for version specific routes; and an extensible Router API that supports non-HTTP protocol routings. Some extension modules provide their own routing, for example: HTTP/2, which also supports a default HTTP routing (version-agnostic); gRPC, including protocol-specific routes supporting all message types (unary, client stream, server stream, and bidirectional); and/or WebSocket, protocol-specific route, supporting a listener with a session.
In accordance with an embodiment, a web client (WebClient) can be provided as an extensible module, with a default implementation that supports the HTTP/1.1 protocol. A web client SPI supports other protocols to be used sharing a basic configuration. In accordance with an embodiment, the following extensions can be included: HTTP/1.1 client; HTTP/2 client.
In accordance with an embodiment, the WebServer and WebClient modules are designed to be testable, for example with JUnit5. The system can support either HTTP communication, or in-memory communication, depending on the annotation chosen, for example, an @ServerTest provides HTTP communication over socket, to create integration tests; and/or an @RoutingTest provides in-memory communication, to create unit tests.
In accordance with an embodiment, additional modules can be included, for example: a fault tolerance, blocking fault tolerance implementation for “circuit breaker”, “bulkhead”, “fallback”, and “retry” scenarios; an observability endpoint to obtain information about the application, such as health, metrics, configuration, application info, etc.; a means of providing extensibility to plug other modules into the “observe” mechanism; and/or tracing, or open telemetry tracing support.
Within a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements as to the formatting of messages passed between the participants, including message headers.
For example, the HTTP/1 and HTTP/2 protocols have different requirements as to the format of message headers used when sending request or response messages via those protocols.
Parsing such headers requires a considerable amount of computational overhead, particularly when thousands of requests need to be processed at the same time, as might be encountered in a cloud environment. Preparing responses to such requests with their appropriate headers similarly requires a considerable amount of computational overhead.
In accordance with an embodiment, the system provides, by means of a header enumeration, an abstraction that allows message headers to be treated as objects, accessible via an application program interface (API) that supports multiple communication protocols and allows clients and servers to communicate request/response messages using any of the supported protocols.
When a request message with a known header type is encountered, the system can obtain an indexed value from the enumeration, if available, and provide the associated data (e.g., as data bytes) directly to the process to which the request is directed, and/or cache the header value for later use.
For example, HTTP header parsing, handling and serialization is one of the more computationally-expensive part of processing HTTP requests. To improve performance on all of these tasks, the system can provide a new abstraction of headers, both for the name of the header (interface HeaderName) and for the whole header value (interface HeaderValue).
Additionally, with HTTP/2 being used increasingly more often, it is advantageous to use headers that work well in both HTTP versions. Although implementations in Java may use a String or a CharSequence to identify a header, or optimize the byte values of the header name, they do not use an indexed approach for commonly used headers.
The described approach avoids the need to look-up a header map for each request, and provides computational savings particularly when processing a large amounts of requests as may be encountered in a cloud environment.
As illustrated in
In accordance with an embodiment, when a request message with a known header type (e.g., A1252, A2253, B1256, B2257) is encountered, the system can obtain an indexed value (e.g., A 254, B 258) from the enumeration, if available, and provide the associated data (e.g., as data bytes) directly to the process to which the request is directed, and/or cache 270 the header value for later use.
In accordance with an embodiment, the HTTP header is used as an object type. When a known header is created, the system can cache all of the following: the data bytes of the value (if single valued); the full HTTP/1 bytes of the whole header (e.g. “Content-Encoding: gzip”); whether the value is sensitive, and should not be logged, and never indexed (HTTP/2); and whether the value is changing, and should not be cached, and indexed (HTTP/2).
In accordance with an embodiment, for headers parsed from requests, the system can use lazy evaluation, including storing the bytes, until a server or other process actually requests the header value; as there are usually headers that are never requested, this uses less processor (CPU) resources to process each request.
In accordance with an embodiment, the known header names (i.e., those header names that are commonly-used) are implemented in an enumeration (HeaderEnum). The enumeration keeps: a lower cased name (String) —used by HTTP/2, to prevent frequent lowercasing of Strings; and a “default case” name (String) —used by HTTP/1, to have expected header names; an index of the header, to support optimized storage in requests and responses—to quickly identify if a header is present or not, and to optimize retrieval of such headers through indexed access to an array. This is a significant improvement, since various implementations may otherwise use a map to store headers, and Map store and retrieval operations are considerably more expensive than direct indexed array access.
As illustrated in
In accordance with an embodiment, a HeaderName interface can include methods such as:
A method String lowerCase( ) —a HTTP/2 name of the header (such as content-type).
A method String defaultCase( ) —a HTTP/1 name of the header (such as Content-Type).
A method int index( ) —to identify “known” headers (0+) and custom headers (−1).
A method boolean isPseudoHeader( ) —HTTP/2 pseudo headers, such as “Host” in HTTP/1 is “:authority” pseudo header in HTTP/2.
In accordance with an embodiment, a HeaderValue interface can include methods such as:
A method HeaderName headerName( ) —a name of the header.
A method String value( ) —a first value of the header, may be backed by lazy evaluation.
Other methods for multi-valued headers.
As illustrated in
As illustrated in
In accordance with an embodiment, the system can provide support for various interfaces, classes, or methods, such as for example as by the below program, which provides an implementation of a string that is created from bytes only when needed (and cached value), for example:
The above examples are provided for purposes of illustration; in accordance with various embodiments other examples of interfaces, classes, or methods, can be provided.
As illustrated in
At step 292, the system provides, in association with a HTTP headers processing component or functionality, a cache that stores header values, and a header enumeration that stores, for each of a plurality of header types, one or more header type names and an associated index, for use in processing HTTP requests and responses of that header type.
At step 294, a header object is provided, together with a name application program interface (API) and value API, for use in setting or determining header names and/or header values associated with a HTTP request.
At step 296, upon receipt of a request having a known header type, the system stores the header value to the cache, for subsequent lazy retrieval and evaluation when required by a server process.
In accordance with an embodiment, provided below for purposes of illustration is an example interface for providing HTTP headers. In accordance with other embodiments, other types of interface can be provided.
In accordance with an embodiment, an Http.HeaderName interface can be used to provide a HTTP header name, and can include various methods, for example:
A method String lowerCase( ): a lowercase value of this header, used by HTTP/2, may be used for lookup by HTTP/1. There is no validation of this value, so if this contains an upper-case letter, behavior is undefined. In an embodiment, the method returns: a name of the header, lowercase.
A method String defaultCase( ): a header name as used in HTTP/1, or “human-readable” value of this header. In an embodiment, the method returns: a name of the header, may use uppercase and/or lowercase.
A method int index( ): an index of this header (if one of the known indexed headers), or −1 if this is a custom header name. In an embodiment, the method returns: an index of this header.
A method boolean isPseudoHeader( ): HTTP/2 defines pseudoheaders as headers starting with a : character. These are used instead of the prologue line from HTTP/1 (to define path, authority etc.) and instead of status line in response. In an embodiment, the method returns: whether this header is a pseudo-header.
In accordance with an embodiment, an Http.HeaderValue interface can be used to provide a HTTP Header value, and can include various methods, for example:
A method static Http.HeaderValue createCached(Http.HeaderName name, String value). Create and cache byte value. This method is used if the header value is stored in a constant, or used repeatedly. Parameters that can be provided include, for example: name—header name; value—value of the header. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue create(Http.HeaderName name, LazyString value). Create a new header with a single value. This header is considered unchanging and not sensitive. Parameters that can be provided include, for example: name—name of the header; value—lazy string with the value. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue create(Http.HeaderName name, String value). Create a new header with a single value. This header is considered unchanging and not sensitive. Parameters that can be provided include, for example: name—name of the header; value—value of the header. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue create(Http.HeaderName name, String . . . values). Create a new header. This header is considered unchanging and not sensitive. Parameters that can be provided include, for example: name—name of the header; values—values of the header. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue create(Http.HeaderName name, List<String> values). Create a new header. This header is considered unchanging and not sensitive. Parameters that can be provided include, for example: name—name of the header; values—values of the header. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue createCached (Http.HeaderName name, boolean changing, boolean sensitive, String value). Create and cache byte value. This method is used if the header value is stored in a constant, or used repeatedly. Parameters that can be provided include, for example: name—header name; changing—whether the value is changing often (to disable caching for HTTP/2); sensitive—whether the value is sensitive (to disable caching for HTTP/2); value—value of the header. In an embodiment, the method returns: a new header.
A method static Http.HeaderValue create(Http.HeaderName name, boolean changing, boolean sensitive, String . . . values). Create a new header. Parameters that can be provided include, for example: name—name of the header; changing—whether the value is changing often (to disable caching for HTTP/2); sensitive—whether the value is sensitive (to disable caching for HTTP/2); values—value(s) of the header. In an embodiment, the method returns: a new header.
A method String name( ). Name of the header as configured by user or as received on the wire. In an embodiment, the method returns: a header name, always lower case for HTTP/2 headers.
A method Http.HeaderName headerNam( ). Header name for the header. In an embodiment, the method returns: a header name.
A method String value( ). First value of this header. In an embodiment, the method returns: the first value.
A method List<String> allValues( ). All values of this header. In an embodiment, the method returns: all configured values.
A method default List<String> allValues(boolean split). All values of this header. If this header is defined as a single header with comma separated values, set split to true. Parameters that can be provided include, for example: split—whether to split single value by comma, does nothing if the value is already a list. In an embodiment, the method returns: a list of values.
A method boolean sensitive( ). Sensitive headers should not be logged, or indexed (HTTP/2). In an embodiment, the method returns: whether this header is sensitive.
A method boolean changing( ). Changing headers should not be cached, and their value should not be indexed (HTTP/2). In an embodiment, the method returns: whether this header's value is changing often.
A method default byte[ ] valueBytes( ). Cached bytes of a single valued header's value. In an embodiment, the method returns: value bytes.
A method default void writeHttp1Header(BufferData buffer). Write the current header as an HTTP header to the provided buffer. Parameters that can be provided include, for example: buffer—buffer to write to (should be growing).
In accordance with an embodiment, a Headers object can be used to store headers parsed from a request, or configured by a user for later retrieval (either by user for processing, or by the server to be written over the network). The following example illustrates the parts that are required to utilize direct access when getting and setting a header:
In accordance with an embodiment, a request processing component such as Loom supports concurrency of client-server communications with the use of virtual threads. Such virtual threads allow client HTTP applications to operate, e.g., request connections to server processes, in a normal blocking manner, while the underlying request processing (e.g., Loom-based) environment handles concurrency of request processing.
The ability to develop client applications with such a request processing component offers a simpler code development process. For example the application developer does not have to build in reactive programming within their application itself.
In accordance with an embodiment, to support testing of software applications or services, a client connection can be replaced, for testing purposes, with an in-memory implementation that does not invoke, e.g., HTTP, but instead exposes inverse-functions to a server connection; for example, data bytes written to a data writer of a client connection are available through a data reader on a server connection, and vice versa.
During testing, the in-memory implementation uses a blocking queue in memory, which emulates the use of an HTTP protocol, but without using actual sockets. Once such testing (e.g., a unit test), has been completed, the client and/or server code can be tested against actual network sockets (e.g., an integration test).
For example, it may be desired to create services that can be easily tested, without the need to rewrite the same test depending on whether the application developer will be performing a unit test, or an integration test. Usually the abstraction is quite complex, due to optimizations for performance, for example using an event loop mechanism, reactive code, etc.
The described approach enables improved testing or debugging; including that during testing or debugging, a thread dump provides more useful information for troubleshooting purposes.
As illustrated in
As illustrated in
As illustrated in
As illustrated in
In accordance with an embodiment, the system abstracts a connection to two basic operations: (1) it can be written to, using a data writer (DataWriter); and (2) it can be read from, using a data reader (DataReader).
In accordance with an embodiment, the system allows an application developer to replace a client connection with an in-memory implementation that will not invoke network socket communication, but exposes inverse functions to server connection (bytes written to the data writer of client connection are available through the data reader on server connection, and vice versa).
In accordance with an embodiment, this allows the application developer to write a single application code to test server code, and by simply switching between an actual or real HTTP client and an in-memory HTTP client, the application developer can test both the validity of the routing code in a unit test, and the validity of the whole server code using an integration test (e.g., opening a port and invoking it over HTTP protocol).
In accordance with an embodiment, examples of tests that would use this include: a unit test that creates an instance of DirectClient that implements HTTP1Client, which uses the in-memory connection abstraction; an integration test that creates an instance of HTTP1Client, which connects over the network; or an abstract class that gets an instance of HTTP1Client and defines actual tests, such as, for example:
In accordance with an embodiment, the system can provide support for various interfaces, classes, or methods, as illustrated below.
In accordance with an embodiment, an abstraction that can provide bytes (DataReader) can be provided as a data reader that can pull additional data, for example:
In accordance with an embodiment, an abstraction that can consume bytes (DataWriter) can be provided as a data writer than can write data to the underlying transport (e.g., a socket), for example:
In accordance with an embodiment, an abstraction of a connection of a client (ClientConnection) that allows usage of a custom connection for testing, can be provided as, for example:
In accordance with an embodiment, an implementation for an in-memory client connection (DirectClientConnection) —can be provided, such a connection would directly route to server side routing, bypassing the network protocol, for example:
In accordance with an embodiment, an implementation for an over-the-network connection for HTTP/1.1 that uses a reader and writer with a network socket, instead of an in-memory array, can be provided as, for example:
In accordance with an embodiment, a communication between a client and a server can be abstracted for the client into various components: a ClientConnection (as described above), and for request/response based protocols a ClientRequest, and ClientResponse.
In accordance with an embodiment, a communication between a client and a server can be abstracted for the server into various components: a ServerConnection, and for request/response based protocols a ServerRequest, and ServerResponse.
When implementing a client, the developer can choose a connection to use with a new ClientRequest, providing either a network based connection, or an in-memory connection.
When implementing a client that is not based on request/response paradigm (such as WebSocket protocol that uses a concept of listeners), the client handles the abstraction directly, and invokes the server listeners in memory when in-memory connection is used, or calls a server over the network to handle server side listeners. A direct WebSocket client using in-memory communication, can be provided as, for example:
In accordance with an embodiment, a method connection that uses the implementation for an over-the-network WebSocket client connection (WsClientImpl) can be provided as, for example:
In accordance with an embodiment, a server-side equivalent (ConnectionContext), which uses data writer and data reader to be used by server connections, can be provided as, for example:
The above examples are provided for purposes of illustration; in accordance with various embodiments other examples of interfaces, classes, or methods, can be provided.
As illustrated in
At step 342, the system provides a client server connection abstraction component or functionality wherein, in place of a client connection, an in-memory implementation exposes inverse functions to an, e.g., HTTP, server connection, wherein data bytes written to a data writer (DataWriter) of a client connection are available through a data reader (DataReader) on a server connection.
At step 344, a user can prepare, for use with an, e.g., HTTP, client, a routing code to test server code, and switch between an actual or real client and an in-memory implementation of the client to test validity of the routing code.
At step 346, the user can update routing code and/or server code, and continue to switch between the actual or real client and an in-memory implementation to continue testing.
In accordance with an embodiment, a ClientConnection interface (an example of which is illustrated above) can be used to provide a client connection that allows usage of a custom connection for testing.
Within a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements as to the formatting of messages passed between the participants, including message headers.
For example, the HTTP/1 and HTTP/2 protocols have different requirements as to the format of message headers used when sending request or response messages via those protocols.
In accordance with an embodiment, the system enables configuration of a server that can operate to serve requests via multiple network or communication protocols, such as for example HTTP1, gRPC over HTTP2, and/or WebSocket.
A route abstraction allows each protocol to have its own routing, e.g., an HTTP routing. A sub-abstraction can provide a more specific route, for example as an HTTP1 route, or an HTTP2 route. For a connection/request received via a particular protocol, the system can pick up the appropriate route for the request, and process it accordingly.
For example, it may be desirable to have routing configured on a server builder that can handle any supported protocol, without a dependency on each protocol implementation. This requires an abstraction of the router and various routings that allows the application developer to add a new routing to the server. For example in a Java environment such an abstraction can be provided simply by adding a library on the classpath. Other implementations may support HTTP routing over multiple protocol versions, yet without the capability to create a version specific route. Additionally some implementations require specific handling depending on protocol version that is required by the user, or explicit dependency on these protocols.
The described approach enables an easy-to-define configuration of a server to support multiple protocols.
As illustrated in
A route abstraction allows each protocol to have its own routing, e.g., an HTTP routing. A sub-abstraction can provide a more specific route, for example as an HTTP/1 route, or an HTTP/2 route. For a request message received via a particular protocol, the system can pick up the appropriate route for the request, and process it accordingly.
As illustrated in
As illustrated in
As illustrated in
For example, in accordance with an embodiment, this routing abstraction supports routing for any HTTP version, with the capability to create HTTP version specific routes. Routes for other types of protocols can be added that, e.g., upgrade from HTTP (such as WebSocket), that are a subset of HTTP (such as gRPC), or even unrelated to HTTP.
In accordance with an embodiment, this is achieved by abstracting a router (Router), that can contain multiple types of routings. When setting up the server, the application developer can register routings with its builder. A routing then contains protocol-specific methods to enable configuration of that protocol. The combination of these will create a single server that is capable of serving requests to all supported protocols using a single router configuration, for example:
In accordance with an embodiment, various advantages of the described approach can include, for example, the ability to combine protocols in the same server. The protocol is a separate module and there is no dependency from the routing API to each protocol implementation (e.g., add additional protocols and their routes without modification to the server). HTTP routes can be created that are served by any HTTP version (the “/” route in the example shown above), or have HTTP version specific routes (the “/http1” and “/http2” routes in the example shown above). The approach provides a full abstraction of HTTP version from the user—the code can be fully agnostic of version. The approach also provides an extensible mechanism, so for example, to support HTTP/3, it should not be required to modify the routing code.
In accordance with an embodiment, the system can provide support for various interfaces, classes, or methods, as illustrated below.
In accordance with an embodiment, a router interface (Router) can be used to set up routing, can contain more than one protocol routing. Methods can include, for example: routing(Class<T>, T) —to obtain a routing of a specific type, wherein the router for server contains routings of various types, so the server can handle each protocol as fast as possible. For example:
In accordance with an embodiment, a routing marker interface (Routing) can be provided as, for example:
In accordance with an embodiment, an HTTP routing implementation (HttpRouting), wherein the routing is capable of handling any HTTP version, can be provided as, for example:
In accordance with an embodiment, an HTTP service abstraction (HttpService) provides a logical grouping of routes that form a single unit, for example:
In accordance with an embodiment, an HTTP route abstraction (HttpRoute) provides a combination of a path expression, HTTP method predicate, and a handler that handles matching requests, including a basic HTTP route (should be usable by any HTTP protocol version, for example:
In accordance with an embodiment the system can support multiple implementations, for example, a HTTP/1 specific route implementation (Http1Route):
Similarly, in accordance with an embodiment, the system can support a HTTP/2 specific route implementation (Http2Route), for example:
In accordance with an embodiment, a WebSocket routing implementation (WebSocketRouting) providing a WebSocket-specific routing, can be provided as, for example:
In accordance with an embodiment, the above uses a WsListener (WsListener) class, to configure WebSocket endpoints, for example:
In accordance with an embodiment, a gRPC routing implementation (GrpcRouting), providing a gRPC-specific routing, can be provided as, for example:
In accordance with an embodiment, a gRPC Service (GrpcService) can be provided, as a single gRPC service that is backed by a single proto file, for example:
The above examples are provided for purposes of illustration; in accordance with various embodiments other examples of interfaces, classes, or methods, can be provided.
As illustrated in
At step 392, the system provides, for use with, e.g., HTTP, request routing, a router abstraction component or functionality, including an abstraction of a router and routings that allow configuration of a server code by adding a library on a classpath to add a new routing to the server.
At step 394, when setting up the server, the server can register routings with its builder, wherein a routing contains protocol-specific methods to enable configuration of that protocol, and wherein the router supports multiple protocols associated therewith.
At step 396, the server as configured operates to receive and request from clients using the protocols as configured and supported by the server.
In accordance with an embodiment, provided below for purposes of illustration is an example interface for providing router abstraction. In accordance with other embodiments, other types of interface can be provided.
In accordance with an embodiment, a router (Router) interface can be used to provide routings of various types, so that the server can handle each protocol expeditiously, and can include various methods, for example:
A method static Router. Builder builder( ). Builder for router. In an embodiment, the method returns: a new builder.
A method static Router empty( ). Empty router. In an embodiment, the method returns: a new empty router.
A method routing <T extends Routing> T routing(Class<T> routingType, T defaultValue). Get routing of a specific type. Type Parameters that can be provided include, for example: T—type of routing. Parameters that can be provided include, for example: routingType—type of the routing; defaultValue—default value to use if the routing is not defined in this router. In an embodiment, the method returns: a routing defined or default value if not found.
Within a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements as to the formatting of messages passed between the participants, including message headers.
For example, the HTTP/1 and HTTP/2 protocols have different requirements as to the format of message headers used when sending request or response messages via those protocols.
In accordance with an embodiment, to support features such as client/server connection abstraction, router abstraction, or the use of different protocols on a single socket, an extensible service provider interface (SPI) provides software methods that allow protocol identification for a request message and connection.
When a connection request message is received from a client directed to a server, a determination is made as to whether the request can be appropriately handled. The protocol identification process can, for example, return an indication that the system does not support the request protocol, that it does not have enough data to make a decision, or that additional data is needed to make such a determination.
For example, in some systems, when a server receives a connection request, it may not be possible to know what type of connection is being requested. As described herein the approach allows having a single server socket that serves different types of connections. Usually a different socket must be used for incompatible connection types. For HTTP/2, some servers may only support an upgrade from HTTP/1, or map the prior knowledge request to some special HTTP/1 request.
The described approach enables calling a server with whichever protocol is supported and the server will automatically determine if it can accept it or not
As illustrated in
In accordance with an embodiment, a builder can provide protocol support within the server code for a first protocol A 412, and a second protocol B 414.
When a connection request message is received from a client directed to a server, a determination is made as to whether the request can be appropriately handled. The protocol identification process can, for example, return an indication that the system does not support the request protocol, that it does not have enough data to make a decision, or that additional data is needed to make such a determination.
As illustrated in
As illustrated in
As illustrated in
In accordance with an embodiment, the system can use an extensible mechanism to identify the type of incoming connection to correctly handle it. The SPI can use the initial bytes of an incoming connection to identify what kind of connection it is (such as HTTP/1, HTTP/2 with prior knowledge). This mechanism uses a first amount of bytes (configurable by each protocol handler) to attempt an identification. If identification fails, the connection is not accepted.
In accordance with an embodiment, the SPI implementation having a HTTP/1.1 connection provider uses bytes until the first CRLF sequence, tries to parse it and if it forms a valid HTTP/1.1 prologue (e.g. GET/path HTTP/1.1), it is accepted as an HTTP/1.1 request.
In accordance with an embodiment, the SPI implementation having a HTTP/2.2 connection provider uses a fixed number of bytes that form the connection preface defined by specification.
This approach is extensible, such that other connection providers can plug into this mechanism, to provide support for other protocols.
In accordance with an embodiment, an SPI and API can be provided as a server connection provider (ServerConnectionProvider), and can provide various interfaces, classes, or methods, for example:
A method int bytesToldentifyConnection( ) —how many bytes are needed (can be 0 to identify “unknown”).
A method Support supports(BufferData data) —BufferData is an abstraction of initial bytes of the connection. Support defines whether this is a valid request for this provider, whether more data is needed to identify, or whether this is an invalid request for this provider.
A method ServerConnection connection(ConnectionContext) —create a server connection for a connection accepted by this provider, context provides access to reader and writer.
A method SupportedApplicationProtocols( ), used with protocol negotiation when using TLS.
In accordance with an embodiment, a java.util.ServiceLoader provider interface for server connection providers, wherein a Connection provider is given a chance to analyze request bytes and decide whether this is a connection it can accept, can be provided as, for example:
In accordance with an embodiment, an SPI for server connections (ServerConnection) can be provided, which can be created by ServerConnectionProvider, and has a single method handle( ) that is expected to block until the connection is closed, for example as a Server connection abstraction, and which can be used by any provider to handle a socket connection, for example:
In accordance with an embodiment, an HTTP/1 server connection provider (Http1ConnectionProvider) can be provided as, for example, a (java.util.ServiceLoader) provider implementation for an HTTP/1.1 server connection provider:
In accordance with an embodiment, an HTTP/2 server connection provider (Http2ConnectionProvider) can be provided, to support “prior knowledge” requests, for example:
The above examples are provided for purposes of illustration; in accordance with various embodiments other examples of interfaces, classes, or methods, can be provided.
As illustrated in
At step 422, the system provides, for use with, e.g., HTTP, request routing, a connection protocol identification component or functionality, including a connection provider service provider interface (SPI) extensible to support multiple protocols supported by a server code.
At step 424, the connection provider SPI provides a plurality of connection provider types, each of which is associated with a supported protocol.
At step 426, upon receipt of a request directed to a server via an incoming connection, the system can use the initial bytes of the incoming request to identify a connection type (e.g., HTTP/1, HTTP/2), and process the connection request, or otherwise refuse the connection request as being not supported.
In accordance with an embodiment, provided below for purposes of illustration is an example interface for identifying a protocol of a connection. In accordance with other embodiments, other types of interface can be provided.
In accordance with an embodiment, a ServerConnectionProvider interface can be used to provide an interface for server connection providers, wherein a connection provider is given a chance to analyze request bytes and decide whether this is a connection it can accept, and can include various methods, for example:
A method int bytesToldentifyConnection( ). How many bytes are needed to identify this connection. In an embodiment, the method returns: a number of bytes needed, return 0 if this is not a fixed value.
A method ServerConnectionProvider.Support supports (common.buffers.BufferData data). Does this provider support current server connection. The same buffer will be sent to ServerConnection.handle( ). Parameters that can be provided include, for example: data—bytes (with available bytes of at least bytesToldentifyConnection( )). In an embodiment, the method returns: a support response.
A method Set<String> supportedApplicationProtocols( ). Application protocols supported by this provider, used for example for ALPN negotiation. In an embodiment, the method returns: a set of supported protocols.
A method ServerConnection connection(ConnectionContext ctx). Create a new connection. All methods will be invoked from a single virtual thread. Parameters that can be provided include, for example: ctx—connection context with access to the data writer, data reader and other useful information. In an embodiment, the method returns: a new server connection.
In accordance with various embodiments, the teachings herein may be conveniently implemented using one or more conventional general purpose or specialized computer, computing device, machine, or microprocessor, including one or more processors, memory and/or computer readable storage media programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
In some embodiments, the teachings herein can include a computer program product which is a non-transitory computer readable storage medium (media) 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 mediums can include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, or other electromechanical data storage devices, floppy disks, optical discs, DVD, CD-ROMs, microdrive, 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-transitory storage of instructions and/or data.
The foregoing description has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art.
For example, although various embodiments of the systems and methods described herein illustrate usage in a Helidon microservice environment, various embodiments can be used with other types of microservice environments or other computing environments.
The embodiments were chosen and described in order to best explain the principles of the present teachings and their practical application, thereby enabling others skilled in the art to understand the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope be defined by the following claims and their equivalents.
This application claims the benefit of priority to U.S. Provisional patent application titled “SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT”, Application No. 63/343,934, filed May 19, 2022, and U.S. Provisional patent application titled “SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT”, Application No. 63/392,039, filed Jul. 25, 2022; each of which above applications and the contents thereof are herein incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63343934 | May 2022 | US | |
| 63392039 | Jul 2022 | US |
