System and method for header processing in server computing environment

Abstract

In accordance with an embodiment, described herein are systems and methods for use with micro-services or other computing environments, including web servers and related libraries and features that may be used to build cloud native applications or services. According to various embodiments, the systems and methods can include using various components or features that support (a) header processing, (b) client and server connection abstraction, (c) router abstraction, and (d) protocols that identify connections.

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 the following patent applications: U.S. Provisional Patent Application, entitled “SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT,” Application No. 63 / 343,934, filed on May 19, 2022; U.S. Provisional Patent Application, entitled “SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT,” Application No. 63 / 392,039, filed on July 25, 2022; U.S. Patent Application, entitled “SYSTEMS AND METHODS FOR HEADER PROCESSING IN A SERVER COMPUTING ENVIRONMENT,” Application No. 18 / 198,759, filed on May 17, 2023; U.S. Patent Application, entitled “SYSTEMS AND METHODS FOR CLIENT-SERVER CONNECTION,” filed on May 17, 2023 ABSTRACTION IN A SERVERCOMPUTING ENVIRONMENT,” Application No. 18 / 198,762; U.S. patent application filed on May 17, 2023, entitled “SYSTEMS AND METHODS FOR ROUTER ABSTRACTION IN A SERVERCOMPUTING ENVIRONMENT,” Application No. 18 / 198,764; and U.S. patent application filed on May 17, 2023, entitled “SYSTEMS AND METHODS FOR IDENTIFYING CONNECTION PROTOCOLS IN A SERVERCOMPUTING ENVIRONMENT,” Application No. 18 / 198,765; each of the above applications and their contents are incorporated herein by reference. Technical Field

[0005] Embodiments described herein relate generally to cloud computing and other computing environments, software development, and microservices architectures, and are particularly directed to systems and methods for supporting application development and related libraries and features that can be used to build cloud-native applications or services. Background Art

[0006] 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 (e.g., a cloud network that a cloud computing environment may provide). A microservices approach can be used, for example, to develop software applications or services to be provided as cloud-native applications or services in a cloud computing environment. Summary of the invention

[0007] According to embodiments, systems and methods are described herein for use with a microservices or other computing environment, including a web server and related libraries and functionality that can be used to build cloud-native applications or services.

[0008] According to various embodiments, systems and methods may include using various components or features that support, for example, (a) HTTP headers, (b) client and server connection abstractions, (c) router abstractions, and (d) protocols that identify connections.

[0009] According to an embodiment, the system provides an abstraction with the aid of a header enumeration 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 supported protocol. When a request message with a known header type is encountered, the system can obtain an index value from the enumeration if available and provide the associated data (e.g., as data bytes) directly to the process to which the request was directed and / or cache the header value for later use.

[0010] According to an embodiment, to support testing of software applications or services, for testing purposes, the client connection can be replaced with an in-memory implementation that does not call, for example, HTTP, but instead exposes an inverse function to the server connection; for example, data bytes written to a data writer on the client connection are available through a data reader on the server connection, and vice versa. During testing, the in-memory implementation uses a blocking queue in memory that simulates the use of the HTTP protocol, but does not use actual sockets. Once testing (e.g., unit testing or integration testing) is completed using the in-memory implementation, the client and / or server code can be tested against actual sockets for processing requests.

[0011] According to an embodiment, the system enables configuration of a server that can handle requests via multiple network or communication protocols (such as, for example, HTTP1, gRPC over HTTP2, and / or WebSocket). The routing abstraction allows each protocol to have its own routing, such as HTTP routing. Sub-abstractions can provide more specific routing, such as HTTP / 1.1 routing or HTTP / 2 routing. For a request message received via a specific protocol, the system can select an appropriate route for the request and process it accordingly.

[0012] According to an embodiment, in order to support functions 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 of request messages and connections. When a connection request message directed to a server is received from a client, a determination is made as to whether the request can be properly handled. The protocol identification process can, for example, return an indication that the system does not support the request protocol, does not have enough data to make a decision, or requires additional data to make such a decision. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0017] Figure 5 A system including a microservices environment for developing applications for use in a cloud environment according to an embodiment is illustrated.

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

[0019] Figure 7 A system including a microservices environment according to an embodiment is illustrated.

[0020] Figure 8 Illustrated is a web server for use with a microservices environment according to an embodiment.

[0021] Fig. 9Illustrated is support for HTTP header processing according to an embodiment.

[0022] Fig.10 Further illustrated is support for HTTP header processing according to an embodiment.

[0023] Fig.11 Further illustrated is support for HTTP header processing according to an embodiment.

[0024] Fig.12 Further illustrated is support for HTTP header processing according to an embodiment.

[0025] Fig.13 A method for processing HTTP headers for use with a microservices environment according to an embodiment is illustrated.

[0026] Fig.14 Support for client and server abstractions according to an embodiment is illustrated.

[0027] Fig.15 Further illustrated is support for client and server abstractions according to an embodiment.

[0028] Fig.16 Further illustrated is support for client and server abstractions according to an embodiment.

[0029] Fig.17 Further illustrated is support for client and server abstractions according to an embodiment.

[0030] Fig.18 A method for providing client and server abstractions for use with a microservices environment according to an embodiment is illustrated.

[0031] Fig.19 Support for router abstraction according to an embodiment is illustrated.

[0032] Fig. 20 Further illustrated is support for router abstraction according to an embodiment.

[0033] Fig.21 Further illustrated is support for router abstraction according to an embodiment.

[0034] Fig. 22 Further illustrated is support for router abstraction according to an embodiment.

[0035] Fig.23 A method for providing a router abstraction for use with a microservices environment according to an embodiment is illustrated.

[0036] Fig.24 Support for protocols identifying connections according to an embodiment is illustrated.

[0037] Fig.25 Further illustrated is support for protocols that identify connections according to an embodiment.

[0038] Fig.26 Further illustrated is support for protocols that identify connections according to an embodiment.

[0039] Fig. 27 Further illustrated is support for protocols that identify connections according to an embodiment.

[0040] Fig.28 A method for identifying a protocol for a connection for use with a microservices environment according to an embodiment is illustrated. DETAILED DESCRIPTION

[0041] 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 (e.g., a cloud network that a cloud computing environment may provide). A microservices approach can be used, for example, to develop software applications or services to be provided as cloud-native applications or services in a cloud computing environment.

[0042] Software development frameworks such as Helidon can be used in the development of microservices. For example, as described below, the Helidon environment provides 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 developing cloud-native applications or services.

[0043] According to an embodiment, the Helidon library may interoperate with other software development, deployment, and / or monitoring tools such as, for example, Docker, Kubernetes, Prometheus, or Jaeger.

[0044] Microservice environment

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

[0046] According to an embodiment, Figure 1-Figure 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).

[0047] like Figure 1As shown in , according to an embodiment, a microservice environment (e.g., as provided by a microservice library) 100 can provide, for example, one or more Helidon SE 110, Helidon MP 120, and / or Helidon Níma 130 programming models or environments. The microservice environment can enable interaction with a cloud, database, or other system or service 140 through a developed application.

[0048] The examples of various embodiments of the Helidon microservice environment described herein are provided to illustrate examples of microservice computing environments or microservice environments. According to various embodiments, the systems and methods described herein can be used with other types of microservice environments or computing environments.

[0049] According to various embodiments, the systems and methods may be used with other types of software development environments, or with other types of web servers and related libraries and features that may be used to build cloud-native services.

[0050] 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.

[0051] For example, according to an embodiment, the Helidon SE environment provides a framework through which application developers can build lightweight reactive microservices. The 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 can then be used by the application 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 tracing 116 or other components.

[0052] 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.

[0053] 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, context and dependency injection (CDI) 124, metrics 121, health checks 123, fault tolerance 125, MicroProfile (MP) configuration 137, and JSON web token (JWT) authentication 128 components. The web server may be provided by a non-blocking client / server / web framework 118, such as, for example, Netty.

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

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

[0056] Figure 5 A system including a microservices environment for developing applications for use in a cloud environment according to an embodiment is illustrated.

[0057] like Figure 5 As shown in , according to an embodiment, a microservices environment presents a software application as a collection of loosely coupled services that can be independently deployed and communicate with each other through a network (e.g., through a cloud network that may be provided by a cloud computing environment).

[0058] For example, according to an embodiment, the Helidon microservices environment may 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 microservices environment to build connected systems.

[0059] According to an embodiment, the remote procedure call framework enables the definition of services and methods that can be called remotely. A server or service can handle calls from a client via a stub, which enables a client application to directly call methods on a server application as if it were a stub. The server / service implements methods that handle client calls, including decoding incoming requests, executing service methods, and encoding service responses. The 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 to the server as a request.

[0060] According to an embodiment, a microservices 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 device hardware 152 (e.g., 152A, 152B) to communicate with the microservices or interact with a cloud 160, server application 174, database 180, or other systems or services at a computer server device 170 having device hardware 172 to access data, process transactions, or perform other operations associated with those systems or services.

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

[0062] like Figure 6 As shown in , according to an embodiment, the microservices environment enables client applications to access to communicate with cloud native services 180 or otherwise interact with the cloud, database, or other systems or services to access data, process transactions, or perform other operations associated with those systems or services.

[0063] HTTP Request Handling

[0064] In a cloud environment, web services that enable client applications to interact with servers may be HTTP-based, ie, client applications and servers may use the HTTP communication protocol as a means of communicating requests and responses between the various participants in the form of data messages.

[0065] For example, in a cloud service that provides access to one or more databases or other services, processing of a client request may result in several initial calls, each of which may then call another service to perform some additional aspect of processing the request.

[0066] In some cloud environments, reactive programming techniques can be used to support concurrent processing of requests. However, because reactive programming is non-blocking, it can be difficult to troubleshoot the operation of a reactive application. For example, thread dumps that might be useful for assessing the status of various threads provide little or no information for testing or debugging purposes when used in a reactive environment.

[0067] According to an embodiment, to address such considerations, the system may include a request processing component, such as a Loom-based implementation of a web server (WebServer), and related libraries and features that can be used to build cloud native services (referred to as Helidon Níma in some embodiments herein).

[0068] According to an embodiment, such a request processing component supports concurrency of client-server communications using virtual threads. Such virtual threads allow client HTTP applications to operate in a normal blocking manner, such as requesting a connection with a server process, while the underlying request processing (e.g., based on Loom) environment handles the concurrency of request processing.

[0069] This provides an improved code development process because application developers do not have to build reactive programming into the application itself. In addition, during testing or debugging, thread dumps provide more useful information for troubleshooting. Therefore, this approach provides the characteristics of a traditional programming environment as well as the concurrency benefits of reactive programming.

[0070] For example, according to an embodiment, the Helidon Níma environment allows application developers to set up HTTP endpoints through which servers can provide services to web clients. Client applications can run in a blocking manner within the environment, while using virtual threading that provides a virtual thread for each connection, enabling high levels of concurrency.

[0071] Figure 7 A system including a microservices environment according to an embodiment is illustrated.

[0072] like Figure 7 As shown in, according to an embodiment, when used with a web server 190 (WebServer, such as the Helidon Níma environment), a request processing component 200 (e.g., a Loom-based implementation of a web server) allows the use of blocking code without using a large number of platform threads, including the use of a blocking API that allows requests to the server to run on an application virtual thread 210.

[0073] According to an embodiment, a virtual thread (referred to as a fiber in some examples) operates as a lightweight thread that enables execution of high-throughput concurrent applications. In general, a virtual thread provides an instance of an execution thread (e.g., java.lang.Thread) that is not bound to a specific operating system (O / S) thread. Application code can run in a virtual thread for the duration of a request; the virtual thread, in turn, consumes an O / S thread when performing operations on a processor.

[0074] According to an embodiment, the non-blocking API can be encapsulated by the synchronous API, and the non-blocking API is in a virtual thread ready state by blocking the further execution of the virtual thread until the corresponding operation is completed. In this way, each virtual thread can be suspended for a period of time and then continue at a subsequent time.

[0075] For example, Figure 7As shown in , according to an embodiment, when executing in a virtual machine 220, a request may be received at a blocking API 222. Multiple carrier threads 224 communicate with an underlying operating system 230, for example, via registering events and callbacks at a non-blocking API 232, or via an O / S thread pool 226 and a blocking API 234.

[0076] According to an embodiment, such a request processing component allows application developers to take advantage of non-blocking APIs during software development without having to change 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 having to deal with complex executor services.

[0077] Figure 8 Illustrated is a web server for use with a microservices environment according to an embodiment.

[0078] like Figure 8 As shown in , according to an embodiment, a virtual threaded web server (e.g., a Loom-based implementation of a web server) can be used as an alternative or replacement for functionality otherwise provided by a reactive web server (e.g., reactive web server 111) and / or a non-blocking client / server / web framework (e.g., framework 118).

[0079] As described above, the request processing component supports concurrency in client-server communications using virtual threads. Such virtual threads allow client HTTP applications to operate in a normal blocking manner, e.g., requesting a connection to a server process, while the underlying request processing (e.g., Loom-based) environment handles the concurrency of request processing.

[0080] For example, in accordance with an embodiment of the Helidon SE environment, a request processing component may be provided as a replacement for the reactive web servers typically provided therein, where application developers may use virtual threads provided by the web server to support blocking (rather than reactive) application processing, rather than using reactive programming, while providing similar performance aspects.

[0081] According to various embodiments, the request processing components that may be provided herein may be similarly provided as a web server for use with other / new versions of Helidon (eg, Helidon Níma).

[0082] For example, from the perspective of an application developer, according to an embodiment, they can include or block code in their application that directly uses the virtual threading features of a request processing component (e.g., a Loom-based web server); or include application code that is reactive in itself but that the (e.g., Loom-based) web server can handle using the virtual threading features provided by the web server (transparent to the application developer).

[0083] Web Server / Web Client

[0084] According to various embodiments, systems and methods may include using various components or features that support, for example, (a) HTTP headers, (b) client and server connection abstractions, (c) router abstractions, and (d) protocols that identify connections.

[0085] According to an embodiment, a web server (WebServer) may be provided as an extensible module, the default implementation of which supports the HTTP / 1.1 protocol. The web server SPI provides extensibility to support, for example: upgrading from the HTTP / 1 protocol, such as upgrading to HTTP / 2 using a normal socket, or upgrading to WebSocket; other protocols, including non-HTTP protocols, may be extended 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.

[0086] Depending on the embodiment, the extension modules may include, for example: HTTP / 2 protocol implementation; upgrading from HTTP / 1 to HTTP / 2 over TCP (h2c, plain sockets) using prior knowledge; h2c (TLS) (ALPN support); gRPC protocol implementation as a "subprotocol" of HTTP / 2; and / or upgrading from HTTP / 1 to WebSocket protocol implementation.

[0087] According to an embodiment, the web server supports HTTP (version-independent) routing, supports version-specific routing; and an extensible router API that supports non-HTTP protocol routing. Some extension modules provide their own routing, such as: HTTP / 2, which also supports the default HTTP routing (version-independent); gRPC, including protocol-specific routing that supports all message types (unary, client stream, server stream, and bidirectional); and / or WebSocket, protocol-specific routing, support for listeners with sessions.

[0088] According to an embodiment, a web client (WebClient) may be provided as an extensible module, whose default implementation supports the HTTP / 1.1 protocol. The web client SPI supports the use of other protocols to share the basic configuration. According to an embodiment, the following extensions may be included: HTTP / 1.1 client; HTTP / 2 client.

[0089] According to an embodiment, the WebServer and WebClient modules are designed to be testable, such as with JUnit5 testing. The system can support either HTTP communication or in-memory communication, depending on the selected annotations, for example, @ServerTest provides HTTP communication through sockets to create integration tests; and / or @RoutingTest provides in-memory communication to create unit tests.

[0090] Depending on the embodiment, additional modules may be included, such as: fault tolerance, blocking fault tolerance implementation for "circuit breaker", "wall", "backoff" and "retry" scenarios; observability endpoints to obtain information about the application, such as health, metrics, configuration, application information, etc.; means to provide extensibility to plug other modules into the "observation" mechanism; and / or tracing, or open telemetry tracing support.

[0091] A.HTTP Header

[0092] Within a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements regarding the formatting of messages passed between participants, including message headers.

[0093] For example, the HTTP / 1 and HTTP / 2 protocols have different requirements for the format of message headers used when sending request or response messages via these protocols.

[0094] Parsing such headers requires significant computational overhead, especially when thousands of requests need to be processed simultaneously, as might be encountered in a cloud environment. Preparing responses to such requests and their appropriate headers similarly requires significant computational overhead.

[0095] According to an embodiment, the system provides an abstraction by means of header enumeration 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 supported protocol.

[0096] When encountering a request message with a known header type, the system can obtain an index value from the enumeration if available and provide the associated data (e.g., as data bytes) directly to the process to which the request was directed and / or cache the header value for later use.

[0097] For example, HTTP header parsing, processing, and serialization is one of the more computationally expensive parts of processing an HTTP request. To improve performance of all of these tasks, the system can provide a new abstraction for headers, both for the name of the header (interface HeaderName) and for the entire header value (interface HeaderValue).

[0098] Additionally, as HTTP / 2 becomes more and more common, it is advantageous to use headers that work well in both HTTP versions. While implementations in Java may use String or CharSequence to identify headers, or optimize the byte values ​​of header names, they do not use an indexed approach for commonly used headers.

[0099] The described approach avoids the need to look up the header mapping for each request and provides savings in computational effort, particularly when processing a large number of requests, as might be encountered in a cloud environment.

[0100] Fig. 9 Illustrated is support for HTTP header processing according to an embodiment.

[0101] like Fig. 9 As shown in , according to an embodiment, the system provides an abstraction with the help of header enumeration 250, which allows message headers to be treated as objects, accessible via an application interface (API) that supports multiple communication protocols and allows clients and servers to communicate request / response messages using any supported protocol.

[0102] In accordance with an embodiment, when a request message with a known header type (e.g., A1 252, A2 253, B1 256, B2 257) is encountered, the system may obtain the 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 was directed and / or cache 270 the header value for later use.

[0103] According to an embodiment, HTTP headers are used as object types. When creating a known header, the system can cache all of the following: the data bytes of the value (if a single value); the full HTTP / 1 bytes of the entire 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).

[0104] In accordance with an embodiment, for headers parsed from a request, the system may use lazy evaluation, including storing bytes until the server or other processes the actual request header value; because there are often headers that are never requested, this uses fewer processor (CPU) resources to process each request.

[0105] According to an embodiment, known header names (i.e., those header names that are commonly used) are implemented in an enumeration (HeaderEnum). The enumeration preserves: lowercase names (String) - used by HTTP / 2 to prevent frequently lowercasing strings; and "default case" names (String) - used by HTTP / 1 to have expected header names; indexes of headers to support optimized storage in requests and responses - to quickly identify whether a header is present, and to optimize retrieval of such headers through indexed access to an array. This is a significant improvement, as various implementations may otherwise use a map to store headers, and map storage and retrieval operations are much more expensive than direct indexed array access.

[0106] Fig.10 Further illustrated is support for HTTP header processing according to an embodiment.

[0107] like Fig.10 As shown in , according to an embodiment, the header object 260 may be accessed via a high-level API, which may be provided as a name API 262 (eg, a HeaderName interface) and a value API 264 (eg, a HeaderValue interface).

[0108] According to an embodiment, the HeaderName interface may include methods such as:

[0109] Method String lowerCase() - HTTP / 2 name of the header (such as content-type).

[0110] Method String defaultCase() - HTTP / 1 name of the header (such as Content-Type).

[0111] Method int index() - Used to identify "known" headers (0+) and custom headers (-1).

[0112] Method boolean isPseudoHeader() - HTTP / 2 pseudo headers, such as "Host" in HTTP / 1 are ":authority" pseudo headers in HTTP / 2.

[0113] According to an embodiment, the HeaderValue interface may include methods such as:

[0114] Method HeaderName headerName() - the name of the header.

[0115] Method String value() - The first value of the header, possibly backed by lazy evaluation.

[0116] Additional methods for multi-valued headers.

[0117] Fig.11 Further illustrated is support for HTTP header processing according to an embodiment.

[0118] like Fig.11 As shown in , according to an embodiment, HTTP headers are used as object types. When creating a request 280 with a known header 282 or indicated by its header name 284, the system can cache all of the following for a value 286: the data bytes of the value (if a single value); the full HTTP / 1 bytes of the entire 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).

[0119] Fig.12 Further illustrated is support for HTTP header processing according to an embodiment.

[0120] like Fig.12 As shown in , according to an embodiment, for headers parsed from a request, the system can use lazy evaluation and store the bytes as cached header values ​​288 until the server or other process actually requests the header value.

[0121] According to an embodiment, the system may provide support for various interfaces, classes, or methods, such as, for example, through the following program, which provides an implementation for strings created from bytes (and cached values) only when needed, for example:

[0122] Inner Class Header

[0123] constants on class

[0124] methods

[0125] create(String)

[0126] create(String, String)

[0127] createFromLowercase(String)

[0128] inner class HeaderName

[0129] inner class HeaderValue

[0130] methods

[0131] createCached(HeaderName, String)

[0132] create(HeaderName, LazyString)

[0133] create(HeaderName, String...)

[0134] createCached(HeaderName, boolean, boolean, String)

[0135] create(HeaderName, boolean, boolean, String...)

[0136] inner class HeaderValues

[0137] constants on class

[0138] The above examples are for illustration purposes only; other examples of interfaces, classes, or methods may be provided according to various embodiments.

[0139] Fig.13 A method for processing HTTP headers for use with a microservices environment according to an embodiment is illustrated.

[0140] like Fig.13 As shown in , according to an embodiment, at step 290, in a computer including one or more processors and a memory, a microservice environment (e.g., as provided by a microservice library) is provided, which enables client and server applications to communicate within the microservice environment.

[0141] At step 292, the system, in association with an HTTP header processing component or functionality, provides a cache for storing header values, and a header enumeration storing one or more header type names and associated indexes for each of a plurality of header types for use in processing HTTP requests and responses of that header type.

[0142] At step 294, a header object is provided along with a name application programming interface (API) and a value API for setting or determining a header name and / or a header value associated with an HTTP request.

[0143] At step 296, upon receiving a request with a known header type, the system stores the header value in a cache for subsequent lazy retrieval and evaluation when needed by the server process.

[0144] Example interface

[0145] According to an embodiment, an example interface for providing HTTP headers is provided below for illustration purposes. According to other embodiments, other types of interfaces may be provided.

[0146] InterfaceHeaderName

[0147] According to an embodiment, the Http.HeaderName interface may be used to provide an HTTP header name and may include various methods, such as:

[0148] Method String lowerCase(): The lowercase value of this header, used by HTTP / 2, which can be used for lookups over HTTP / 1. This value is not validated, so the behavior is undefined if it contains uppercase letters. In an embodiment, this method returns: the name of the header, in lowercase.

[0149] Method String defaultCase(): The name of the header as used in HTTP / 1, or the "human-readable" value of this header. In an embodiment, this method returns: The name of the header, which can be uppercase and / or lowercase.

[0150] Method int index(): the index of this header (if it is one of the known indexed headers), or -1 (if this is a custom header name). In an embodiment, this method returns: the index of this header.

[0151] Method boolean isPseudoHeader(): HTTP / 2 defines pseudo-headers as headers that begin with a : character. These are used in place of the prologue line in HTTP / 1 (which defines the path, authority, etc.) and the status line in the response. In an embodiment, this method returns: whether this header is a pseudo-header.

[0152] Interface HeaderValue

[0153] According to an embodiment, the Http.HeaderValue interface may be used to provide HTTP header values ​​and may include various methods, such as:

[0154] Method static Http.HeaderValue createCached(Http.HeaderName name, String value). Creates and caches a byte value. Use this method if the header value is stored in a constant or is used repeatedly. Parameters that may be provided include, for example: name - the name of the header; value - the value of the header. In an embodiment, the method returns: the new header.

[0155] Method static Http.HeaderValue create(Http.HeaderName name, LazyString value). Creates a new header with a single value. This header is treated as immutable and insensitive. Parameters that may be provided include, for example: name - the name of the header; value - a lazy string with the value. In an embodiment, the method returns: the new header.

[0156] Method static Http.HeaderValue create(Http.HeaderName name, String value). Creates a new header with a single value. This header is treated as immutable and insensitive. Parameters that may be provided include, for example: name - the name of the header; value - the value of the header. In an embodiment, the method returns: the new header.

[0157] Method static Http.HeaderValue create(Http.HeaderName name, String...values). Creates a new header. This header is treated as immutable and insensitive. Parameters that may be provided include, for example: name - the name of the header; values ​​- the values ​​of the header. In an embodiment, the method returns: the new header.

[0158] Method static Http.HeaderValue create(Http.HeaderName name, List <string>values). Creates a new header. This header is considered immutable and insensitive. Parameters that may be provided include, for example: name - the name of the header; values ​​- the values ​​of the header. In an embodiment, the method returns: the new header.

[0159] Method static Http.HeaderValue createCached(Http.HeaderName name, boolean changing, boolean sensitive, String value). Creates and caches a byte value. Use this method if the header value is stored in a constant or is used repeatedly. Parameters that may be provided include, for example: name - the name of the header; changing - whether the value changes often (to disable caching for HTTP / 2); sensitive - whether the value is sensitive (to disable caching for HTTP / 2); value - the value of the header. In an embodiment, the method returns: the new header.

[0160] Method static Http.HeaderValue create(Http.HeaderName name, booleanchanging, booleansensitive, String...values). Creates a new header. Parameters that may be provided include, for example: name - the name of the header; changing - whether the value changes often (to disable caching for HTTP / 2); sensitive - whether the value is sensitive (to disable caching for HTTP / 2); values ​​- the values ​​of the header. In an embodiment, the method returns: the new header.

[0161] Method String name(). The name of the header as configured by the user or received on the wire. In an embodiment, this method returns: the header name, always lowercase for HTTP / 2 headers.

[0162] Method Http.HeaderName headerName(). Header name of header. In an embodiment, the method returns: header name.

[0163] Method String value(). The first value of this header. In an embodiment, this method returns: the first value.

[0164] Method List <string>allValues(). All values ​​for this header. In an embodiment, this method returns: all configured values.

[0165] 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, then set split to true. Parameters that may be provided include, for example: split - whether to split the single value by commas, if the value is already a list, then do nothing. In an embodiment, this method returns: a list of values.

[0166] Method boolean sensitive(). Sensitive headers should not be logged or indexed (HTTP / 2). In an embodiment, this method returns: whether this header is sensitive.

[0167] Method boolean changing(). Changing headers should not be cached and their values ​​should not be indexed (HTTP / 2). In an embodiment, this method returns: whether the value of this header changes frequently.

[0168] Method default byte[] valueBytes(). Cache bytes of single-valued header value. In an embodiment, the method returns: value bytes.

[0169] Method default void writeHttp1Header(BufferData buffer). Writes the current header as an HTTP header to the provided buffer. Parameters that may be provided include, for example: buffer - the buffer to be written (should be growing continuously).

[0170] Header Implementation

[0171] According to an embodiment, the Headers object can be used to store headers parsed from a request, or headers configured by a user for later retrieval (either processed by the user or written by the server over the network). The following example illustrates the parts that require direct access when getting and setting headers:

[0172]

[0173]

[0174] B. Client and Server Connection Abstraction

[0175] According to an embodiment, a request processing component (such as Loom) supports concurrency in client-server communications using virtual threads. Such virtual threads allow client HTTP applications to operate in a normally blocking manner, such as requesting a connection with a server process, while the underlying request processing (e.g., Loom-based) environment handles the concurrency of request processing.

[0176] The ability to develop client applications using this request processing component provides a simpler code development process. For example, application developers do not have to build reactive programming into their applications themselves.

[0177] In accordance with an embodiment, to support testing of a software application or service, for testing purposes, a client connection may be replaced with an in-memory implementation that does not call, for example, HTTP, but instead exposes inverse functions to a server connection; for example, data bytes written to a data writer on a client connection may be available via a data reader on a server connection, and vice versa.

[0178] During testing, the in-memory implementation uses a blocking queue in memory that simulates the use of the HTTP protocol, but does not use actual sockets. Once such testing (e.g., unit testing) is complete, the client and / or server code (e.g., integration testing) can be tested against actual network sockets.

[0179] For example, it may be desirable to create services that can be easily tested without having to rewrite the same tests depending on whether the application developer will be performing unit tests or integration tests. Typically, the abstractions are quite complex due to performance optimizations (e.g., using event loops, reactive code, etc.).

[0180] The described method enables improved testing or debugging; including during testing or debugging, thread dumps provide more useful information for troubleshooting purposes.

[0181] Fig.14 Support for client and server abstractions according to an embodiment is illustrated.

[0182] like Fig.14 As shown in , according to an embodiment, to support testing of a software application or service, for testing purposes, a client connection may be replaced with an in-memory implementation 300 that does not call, for example, HTTP, but instead exposes an inverse function to a server connection; for example, data bytes written to a data writer 304 on a client connection may be obtained via a data reader 306 on a server connection, and vice versa.

[0183] Fig.15 Further illustrated is support for client and server abstractions according to an embodiment.

[0184] like Fig.15 As shown in , according to an embodiment, during testing (e.g., when testing the processing of request 310 for server code 320), the in-memory implementation uses a blocking queue in memory that simulates the use of the HTTP protocol but does not use actual sockets.

[0185] Fig.16 Further illustrated is support for client and server abstractions according to an embodiment.

[0186] like Fig.16 As shown in , according to an embodiment, once testing (eg, unit testing or integration testing) is completed using the in-memory implementation, the client 330 and / or server code 322 may be tested against an actual socket for processing the request 312 .

[0187] Fig.17 Further illustrated is support for client and server abstractions according to an embodiment.

[0188] like Fig.17 As shown in , according to an embodiment, the process can be repeated, for example to update the server code 324, perform testing against an in-memory implementation using a blocking queue in memory, and implement the client 332 against an actual socket for processing the request 314.

[0189] According to an embodiment, the system abstracts a connection into two basic operations: (1) it can be written using a data writer (DataWriter); and (2) it can be read using a data reader (DataReader).

[0190] According to an embodiment, the system allows application developers to replace the client connection with an in-memory implementation that does not call network socket communications, but instead exposes the inverse function to the server connection (bytes written to the data writer on the client connection are available through the data reader on the server connection, and vice versa).

[0191] In accordance with an embodiment, this allows an application developer to write a single application code to test the server code, and by simply switching between an actual or real HTTP client and an in-memory HTTP client, the application developer can test the effectiveness of the routing code in unit tests, and test the effectiveness of the entire server code using integration tests (e.g., opening a port and calling it over the HTTP protocol).

[0192] According to an embodiment, examples of tests using this method include: creating a unit test of an instance of DirectClient that implements HTTP1Client, which uses an in-memory connection abstraction; creating an integration test of an instance of HTTP1Client connected over a network; or obtaining an instance of HTTP1Client and defining an abstract class for the actual test, such as:

[0193]

[0194] According to an embodiment, the system may provide support for various interfaces, classes, or methods, as shown below.

[0195] According to an embodiment, an abstraction (DataReader) that can provide bytes can be provided as a data reader that can pull additional data, for example:

[0196]

[0197]

[0198]

[0199] According to an embodiment, an abstraction (DataWriter) that can consume bytes may be provided as a data writer, which can write data to an underlying transport (e.g., a socket), for example:

[0200]

[0201] According to an embodiment, an abstraction of a client connection (ClientConnection) may be provided that allows testing using custom connections, for example:

[0202]

[0203] According to an embodiment, an implementation of an in-memory client connection (DirectClientConnection) may be provided, which will bypass the network protocol and directly route to the server-side route, for example:

[0204]

[0205]

[0206]

[0207] According to an embodiment, an implementation for HTTP / 1.1 over a network connection may be provided that uses readers and writers with network sockets instead of in-memory arrays, for example:

[0208]

[0209]

[0210]

[0211] According to an embodiment, the communication between the client and the server may be abstracted into various components for the client: ClientConnection (described above), and ClientRequest and ClientResponse for a request / response based protocol.

[0212] According to an embodiment, the communication between the client and the server may be abstracted into various components for the server: ServerConnection, and ServerRequest and ServerResponse of a request / response based protocol.

[0213] When implementing a client, the developer can choose the connection to use with the new ClientRequest, providing either a network-based connection or an in-memory connection.

[0214] When implementing a client that is not based on the request / response paradigm (such as the WebSocket protocol which uses the concept of listeners), the client handles the abstraction directly and calls the server listener in memory when using a memory connection, or calls the server over the network to handle the server-side listener. A direct WebSocket client using in-memory communication can be provided, for example:

[0215]

[0216]

[0217] According to an embodiment, a method connection using an implementation (WsClientImpl) of a WebSocket client connection on a network may be provided, for example:

[0218]

[0219] According to an embodiment, a server-side equivalent (ConnectionContext) may be provided that uses the data writers and data readers to be used by the server connection, for example:

[0220]

[0221] The above examples are provided for illustration purposes only; other examples of interfaces, classes, or methods may be provided according to various embodiments.

[0222] Fig.18 A method for providing client and server abstractions for use with a microservices environment according to an embodiment is illustrated.

[0223] like Fig.18 As shown in , according to an embodiment, at step 340, at a computer including one or more processors and a memory, a microservice environment (e.g., as provided by a microservice library) is provided, which enables client and server applications to communicate within the microservice environment.

[0224] At step 342, the system provides a client server connection abstraction component or functionality where, instead of a client connection, an in-memory implementation exposes the inverse function to, for example, an HTTP server connection, where data bytes written to a DataWriter on the client connection are available through a DataReader on the server connection.

[0225] At step 344, the user may prepare routing code for, for example, an HTTP client to test the server code, and switch between an actual or real client and an in-memory implementation of the client to test the validity of the routing code.

[0226] At step 346, the user may update the routing code and / or server code and continue switching between actual or real client and in-memory implementations to continue testing.

[0227] Example interface

[0228] According to an embodiment, the ClientConnection interface (an example of which is described above) can be used to provide a client connection that allows testing using a custom connection.

[0229] C. Router Abstraction

[0230] In a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements for the format of messages passed between participants, including message headers.

[0231] For example, the HTTP / 1 and HTTP / 2 protocols have different requirements for the format of message headers used when sending request or response messages via these protocols.

[0232] According to an embodiment, the system enables configuration of a server that can handle requests via multiple network or communication protocols (such as, for example, HTTP1, gRPC over HTTP2, and / or WebSocket).

[0233] The routing abstraction allows each protocol to have its own routing, such as HTTP routing. Sub-abstractions can provide more specific routing, such as HTTP1 routing or HTTP2 routing. For a connection / request received via a specific protocol, the system can pick the appropriate route for the request and handle it accordingly.

[0234] For example, it may be desirable to configure routes on a server builder that can handle any supported protocol without dependencies on implementations of each protocol. This requires an abstraction for routers and various routes that allow application developers to add new routes to the server. For example, in a Java environment, this abstraction can be provided by simply adding a library on the classpath. Other implementations may support HTTP routing across multiple protocol versions, but without the ability to create version-specific routes. Furthermore, some implementations require specific handling based on the protocol versions required by the user, or explicit dependencies on those protocols.

[0235] The described approach enables easy definition of the configuration of a server to support multiple protocols.

[0236] Fig.19 Support for router abstraction according to an embodiment is illustrated.

[0237] like Fig.19 As shown in , according to an embodiment, the system enables a configuration 350 of a server that can operate via multiple network or communication protocols to serve requests, each protocol being associated with a routing type 352 (e.g., routing type A 354 having method 355) for use with server code 360 ​​and a builder 362.

[0238] The routing abstraction allows each protocol to have its own routing, such as HTTP routing. Sub-abstractions can provide more specific routing, such as HTTP / 1 routing or HTTP / 2 routing. For a request message received via a specific protocol, the system can select the appropriate route for the request and handle it accordingly.

[0239] Fig. 20 Further illustrated is support for router abstraction according to an embodiment.

[0240] like Fig. 20 As shown in , according to an embodiment, the builder can provide protocol support 364 for the first protocol A within the server code. The system similarly enables configuration of the server to support route type B 358 with method 359 for use with the server code.

[0241] Fig.21 Further illustrated is support for router abstraction according to an embodiment.

[0242] like Fig.21 As shown in , according to an embodiment, the builder may provide protocol support 366 for the second protocol B within the server code.

[0243] Fig. 22 Further illustrated is support for router abstraction according to an embodiment.

[0244] like Fig. 22 As shown in , according to an embodiment, a configured server can operate via a variety of network or communication protocols to service requests, such as, for example, request A 370 using protocol A 372; and request B 380 using protocol B 382.

[0245] For example, according to an embodiment, this routing abstraction supports routing for any HTTP version, with the ability to create HTTP version-specific routes. Routes for other types of protocols can be added, such as routes that are upgraded from HTTP (e.g., WebSocket), routes that are subsets of HTTP (e.g., gRPC), or even routes that have nothing to do with HTTP.

[0246] According to an embodiment, this is achieved by abstracting a router, which can contain multiple types of routes. When setting up a server, application developers can register routes with its builder. The routes then contain protocol-specific methods to enable configuration for that protocol. The combination of these will create a single server that can serve requests for all supported protocols using a single router configuration, for example:

[0247] .addRouting(HttpRouting.builder()

[0248] .get(" / ",(req,res)->res.send("Hello World"))

[0249] .route(Http1Route.route(GET," / http1",(req,res)

[0250] ->res.send("Hello World 1")))

[0251] .route(Http2Route.route(GET," / http2",(req,res)

[0252] ->res.send("Hello World 2"))))

[0253] .addRouting(GrpcRouting.builder()

[0254] .unary(Strings.getDescriptor(),

[0255] "StringService",

[0256] "Upper",

[0257] ProtocolsMain::grpcUpper))

[0258] .addRouting(WebSocketRouting.builder()

[0259] .endpoint(" / websocket / echo",ProtocolsMain::wsEcho))

[0260] Depending on the embodiment, various advantages of the method can include, for example, the ability to combine protocols in the same server. Protocols are separate modules, and there are no dependencies from the routing API to each protocol implementation (for example, additional protocols and their routes can be added 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 method provides users with a complete abstraction of HTTP versions - the code can be completely version-independent. The method also provides an extensible mechanism, so for example, to support HTTP / 3, the routing code should not be required to be modified.

[0261] According to an embodiment, the system may provide support for various interfaces, classes, or methods, as shown below.

[0262] According to an embodiment, a router interface (Router) may be used to set up routing, which may include more than one protocol routing. Methods may include, for example: routing(Class <t>, T)-Get a specific type of route, where the router for the server contains routes of various types, so the server can handle each protocol as quickly as possible. For example:

[0263]

[0264]

[0265] According to an embodiment, a routing tag interface (Routing) may be provided, for example:

[0266]

[0267] According to an embodiment, an HTTP routing implementation (HttpRouting) may be provided, where routing is capable of handling any HTTP version, for example:

[0268]

[0269]

[0270]

[0271]

[0272]

[0273]

[0274]

[0275]

[0276] According to an embodiment, the HTTP service abstraction (HttpService) provides a logical grouping of routes forming a single unit, for example:

[0277]

[0278]

[0279] According to an embodiment, the HTTP routing abstraction (HttpRoute) provides a combination of path expressions, HTTP method predicates, and handlers for handling matching requests, including basic HTTP routing (which should be usable by any HTTP protocol version, for example:

[0280]

[0281]

[0282]

[0283]

[0284]

[0285] According to an embodiment, the system may support multiple implementations, for example, a routing implementation specific to HTTP / 1 (Http1Route):

[0286]

[0287]

[0288] Similarly, according to an embodiment, the system may support HTTP / 2 specific routing implementations (Http2Route), such as:

[0289]

[0290]

[0291]

[0292] According to an embodiment, a WebSocket routing implementation (WebSocketRouting) that provides WebSocket-specific routing may be provided, for example:

[0293]

[0294]

[0295]

[0296]

[0297] According to an embodiment, the WsListener class is used above to configure a WebSocket endpoint, for example:

[0298]

[0299]

[0300]

[0301] According to an embodiment, a gRPC routing implementation (GrpcRouting) that provides gRPC-specific routing may be provided, for example:

[0302]

[0303]

[0304]

[0305]

[0306]

[0307]

[0308] According to an embodiment, a gRPC service (GrpcService) may be provided as a single gRPC service supported by a single proto file, for example:

[0309]

[0310]

[0311]

[0312]

[0313] The above examples are provided for illustration purposes; other examples of interfaces, classes, or methods may be provided according to various embodiments.

[0314] Fig.23 A method for providing a router abstraction for use with a microservices environment according to an embodiment is illustrated.

[0315] like Fig.23 As shown in , according to an embodiment, at step 390, at a computer including one or more processors and a memory, a microservice environment (e.g., as provided by a microservice library) is provided, which enables client and server applications to communicate within the microservice environment.

[0316] At step 392, the system provides a router abstraction component or functionality for use with, for example, HTTP request routing, including an abstraction of routers and routes that allows configuration of server code by adding libraries on the classpath to add new routes to the server.

[0317] At step 394, when setting up a server, the server may register routes with its builder, wherein the routes contain protocol-specific methods to enable configuration of that protocol, and wherein the routers support multiple protocols associated therewith.

[0318] At step 396, the configured server receives and processes the request from the client using the server configuration and supported protocols.

[0319] Example interface

[0320] According to an embodiment, an example interface for providing a router abstraction is provided below for illustration purposes. According to other embodiments, other types of interfaces may be provided.

[0321] Interface router

[0322] According to an embodiment, the Router interface may be used to provide various types of routing so that the server can quickly handle each protocol, and may include various methods, such as:

[0323] Method static Router.Builder builder(). Builder for the router. In an embodiment, this method returns: the new builder.

[0324] Method static Router empty(). Empty router. In an embodiment, this method returns: a new empty router.

[0325] Method routing<T extendsRouting> T routing(Class <t>Gets a route of a specific type. The type parameter that may be provided includes, for example: T - the type of route. The parameters that may be provided include, for example: routingType - the type of route; defaultValue - the default value to use if no route is defined in this router. In an embodiment, this method returns: the defined route or a default value if not found.

[0326] D. Identify the connection protocol

[0327] Within a cloud environment that supports client-server communications via different communication protocols, each communication protocol may have its own requirements for the formatting of messages passed between participants, including message headers.

[0328] For example, the HTTP / 1 and HTTP / 2 protocols have different requirements for the format of message headers used when sending request or response messages via these protocols.

[0329] According to an embodiment, to support features such as client / server connection abstraction, router abstraction, or using different protocols on a single socket, an Extensible Service Provider Interface (SPI) provides software methods that allow protocol identification for request messages and connections.

[0330] When a connection request message directed to a server is received from a client, a determination is made as to whether the request can be handled appropriately. For example, the protocol identification process may return an indication that the system does not support the request protocol, does not have enough data to make a determination, or requires additional data to make such a determination.

[0331] 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, this approach allows for a single server socket that serves different types of connections. Typically, different sockets must be used for incompatible connection types. For HTTP / 2, some servers may only support upgrading from HTTP / 1, or map previously known requests to some special HTTP / 1 request.

[0332] The method enables the server to be called with any supported protocol and the server will automatically determine whether it can accept the protocol.

[0333] Fig.24 Support for protocols identifying connections according to an embodiment is illustrated.

[0334] like Fig.24 As shown in , according to an embodiment, to support features such as client / server connection abstraction, router abstraction, or using different protocols on a single socket, an extensible service provider interface (SPI) 402 provides software methods that allow protocol identification for request messages and connections.

[0335] According to an embodiment, the builder may provide protocol support for the first protocol A 412 and the second protocol B 414 within the server code.

[0336] When a connection request message directed to a server is received from a client, a determination is made as to whether the request can be properly handled. For example, the protocol identification process may return an indication that the system does not support the request protocol, does not have enough data to make a decision, or requires additional data to make such a determination.

[0337] Fig.25 Further illustrated is support for protocols that identify connections according to an embodiment.

[0338] like Fig.25 As shown in , according to an embodiment, an extensible service provider interface (SPI) 402 can identify request messages and protocols of connections, such as having a first connection provider 404 associated with a first protocol A, a second connection provider 406 associated with a second protocol B, and in this example, a third connection provider 408 associated with a third or other protocol N that the server may not currently support.

[0339] Fig.26 Further illustrated is support for protocols that identify connections according to an embodiment.

[0340] like Fig.26 As shown in , according to an embodiment, request A 370 for a connection using a first protocol A 372; and request B 380 for a connection using a second protocol B 382 can be processed by appropriate server code.

[0341] Fig. 27 Further illustrated is support for protocols that identify connections according to an embodiment.

[0342] like Fig. 27 As shown in , according to an embodiment, a request X 410 for a connection using an unknown other protocol X 412 is determined to be unsupported by the server, and the SPI can determine whether to accept the connection request and handle it in some manner, or not accept the connection request.

[0343] According to an embodiment, the system can use an extensible mechanism to identify the type of incoming connection in order to handle it correctly. The SPI can use the initial bytes of the incoming connection to identify what kind of connection it is (such as HTTP / 1, HTTP / 2 with prior knowledge). This mechanism uses the first byte amount (configurable by each protocol handler) to try to identify. If the identification fails, then the connection is not accepted.

[0344] Example Service Provider Interface

[0345] According to an embodiment, an SPI implementation with an HTTP / 1.1 connection provider uses the bytes up to the first CRLF sequence, attempts to parse it, and if it forms a valid HTTP / 1.1 preamble (e.g., GET / pathHTTP / 1.1), then it is accepted as an HTTP / 1.1 request.

[0346] According to an embodiment, SPI implementation with an HTTP / 2.2 connection provider uses a fixed number of bytes that form the connection preamble defined by the specification.

[0347] This approach is extensible, allowing other connection providers to plug into this mechanism to provide support for other protocols.

[0348] According to an embodiment, an SPI and an API may be provided as a server connection provider (ServerConnectionProvider), and various interfaces, classes, or methods may be provided, such as:

[0349] Method int bytesToIdentifyConnection() - how many bytes are needed (can be 0 to identify "unknown").

[0350] Methods Support supports(BufferData data) - BufferData is an abstraction of the initial bytes of a 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.

[0351] Method ServerConnection connection(ConnectionContext) - Creates a server connection for connections accepted by this provider, the context provides access to readers and writers.

[0352] The method SupportedApplicationProtocols() is used with protocol negotiation when TLS is used.

[0353] According to an embodiment, a java.util.ServiceLoader provider interface may be provided for a server connection provider, where the connection provider has a chance to analyze the request bytes and decide if this is a connection it can accept, e.g.:

[0354]

[0355]

[0356]

[0357] According to an embodiment, an SPI for a server connection (ServerConnection) may be provided, which may be created by a ServerConnectionProvider and has a single method handle() which is expected to block until the connection is closed, e.g. as a server connection abstraction and may be used by any provider to dispose of a socket connection, e.g.:

[0358]

[0359] According to an embodiment, an HTTP / 1 server connection provider (Http1ConnectionProvider) may be provided, as, for example, a (java.util.ServiceLoader) provider implementation for an HTTP / 1.1 server connection provider:

[0360]

[0361]

[0362]

[0363]

[0364]

[0365]

[0366]

[0367] According to an embodiment, an HTTP / 2 server connection provider (Http2ConnectionProvider) may be provided to support "prior knowledge" requests, such as:

[0368]

[0369]

[0370] The above examples are provided for illustration purposes; other examples of interfaces, classes, or methods may be provided according to various embodiments.

[0371] Fig.28 A method for identifying a protocol for a connection for use with a microservices environment according to an embodiment is illustrated.

[0372] like Fig.28 As shown in , according to an embodiment, at step 420, at a computer including one or more processors and a memory, a microservice environment (e.g., as provided by a microservice library) is provided, which enables client and server applications to communicate within the microservice environment.

[0373] At step 422, the system provides a connection protocol identification component or functionality for use with, for example, HTTP request routing, including a connection provider service provider interface (SPI) that is extensible to support multiple protocols supported by the server code.

[0374] At step 424, the connection provider SPI provides a plurality of connection provider types, each type being associated with a supported protocol.

[0375] At step 426, upon receiving a request directed to the server via an incoming connection, the system may use the initial bytes of the incoming request to identify the connection type (e.g., HTTP / 1, HTTP / 2) and process the connection request, or otherwise reject an unsupported connection request.

[0376] Example interface

[0377] According to an embodiment, an example interface for identifying a connected protocol is provided below for illustration purposes. According to other embodiments, other types of interfaces may be provided.

[0378] Interface ServerConnectionProvider

[0379] According to an embodiment, the ServerConnectionProvider interface may be used to provide an interface for a server connection provider, where the connection provider has the opportunity to analyze the request bytes and decide whether this is a connection it can accept, and may include various methods, such as:

[0380] Method int bytesToIdentifyConnection(). How many bytes are needed to identify this connection. In an embodiment, this method returns: the number of bytes required, or 0 if this is not a fixed value.

[0381] method

[0382] ServerConnectionProvider.Supportsupports(common.buffers.BufferDatadata). Whether this provider supports the current server connection. The same buffer will be sent to ServerConnection.handle(). Parameters that may be provided include, for example: data - bytes (at least bytesToIdentifyConnection() available). In an embodiment, this method returns: SupportResponse.

[0383] Method Set <string>supportedApplicationProtocols(). The application protocols supported by this provider, e.g. for ALPN negotiation. In an embodiment, this method returns: a set of supported protocols.

[0384] Method ServerConnection connection(ConnectionContext ctx). Creates a new connection. All methods will be called from a single virtual thread. Parameters that may be provided include, for example: ctx - connection context with access to data writers, data readers, and other useful information. In an embodiment, this method returns: a new server connection.

[0385] According to various embodiments, aspects of the disclosure are set forth in the following numbered clauses:

[0386] 1. A system for use with a microservice or other computing environment, comprising: a computer including one or more processors that provides access to the microservice or other computing environment for use with a software application or service; and wherein the system provides an abstraction that allows message headers to be treated as objects via a header enumeration, wherein the header enumeration is accessible via an application program interface that supports multiple communication protocols and allows clients and servers to communicate request and response messages using any of several supported protocols.

[0387] 2. A system as described in clause 1, wherein when encountering a request message with a known header type, the system can obtain the indexed value from the enumeration if available and provide the associated data directly to the process directed by the request and / or cache the header value for later use.

[0388] 3. A method for use with a microservice or other computing environment, comprising: providing a microservice or other computing environment for use with a software application or service; and providing an abstraction by means of a header enumeration, which allows message headers to be treated as objects, accessible via an application program interface that supports multiple communication protocols and allows clients and servers to communicate request / response messages using any of several supported protocols.

[0389] 4. A method as described in clause 3, wherein when encountering a request message with a known header type, the system can obtain the indexed value from the enumeration if available and provide the associated data directly to the process directed by the request and / or cache the header value for later use.

[0390] 5. A system for use with a microservice or other computing environment, comprising: a computer including one or more processors that provides access to a microservice or other computing environment for use with a software application or service; and wherein during testing of the software application or service, a client connection is replaced with an in-memory implementation that simulates the use of a network communication protocol and exposes an inverse function to a server connection, including: data written to a data writer of the client connection is available through a data reader on the server connection, and data written to a data writer of the server connection is available through a data reader on the client connection.

[0391] 6. A system as described in clause 5, wherein the in-memory implementation uses a blocking queue in memory that simulates the use of a network communication protocol without the use of actual sockets, wherein testing has been completed and the client and / or server code can be implemented against actual sockets.

[0392] 7. A method for use with a microservice or other computing environment, comprising: providing a microservice or other computing environment for use with a software application or service; and during testing of the software application or service, replacing a client connection with an in-memory implementation that simulates the use of a network communication protocol and exposes an inverse function to a server connection, including: data written to a data writer of the client connection is available through a data reader on the server connection, and data written to a data writer of the server connection is available through a data reader on the client connection.

[0393] 8. A method as described in clause 7, wherein the in-memory implementation uses a blocking queue in memory that simulates the use of a network communication protocol without the use of actual sockets, wherein testing has been completed and the client and / or server code can be implemented against actual sockets.

[0394] 9. A system for use with a microservice or other computing environment, comprising: a computer including one or more processors that provides access to the microservice or other computing environment for use with a software application or service; and wherein the system enables configuration of a server that can operate to serve requests via multiple networks or communication protocols, including: providing a routing abstraction that associates each network or communication protocol supported by the server with its own route, and the routing abstraction can include one or more specific routes for use with a specific network or communication protocol.

[0395] 10. The system of clause 9, wherein for a request message received via a specific protocol, the system can select an appropriate route for the request and process it according to the routing abstraction.

[0396] 11. A method for use with a microservice or other computing environment, comprising: providing a microservice or other computing environment for use with a software application or service; and wherein the system enables configuration of a server that can operate to serve requests via multiple networks or communication protocols, including: providing a routing abstraction that associates each network or communication protocol supported by the server with its own route, and the routing abstraction can include one or more specific routes for use with a specific network or communication protocol.

[0397] 12. The method of clause 11, wherein for a request message received via a specific protocol, the system can select an appropriate route for the request and process it according to the routing abstraction.

[0398] 13. A system for use with a microservice or other computing environment, comprising: a computer including one or more processors that provides access to the microservice or other computing environment for use with a software application or service; and an extensible service provider interface that provides software methods that allow identification of network communication protocols associated with request messages and client-server connections; wherein identification of the network communication protocol is used to provide one or more of client-server connection abstraction, router abstraction, or support for use of multiple network communication protocols on a single socket.

[0399] 14. A system as described in clause 13, wherein when a connection request message is received from a client and directed to a server, a determination is made as to whether the request can be handled using the provided network communication protocol, wherein the protocol identification processing returns an indication that the system does not support the requested network communication protocol, or that it does not currently have enough data to make the determination or that additional data is required to make such a determination.

[0400] 15. A method for use with a microservice or other computing environment, comprising: providing a microservice or other computing environment for use with a software application or service; and providing an extensible service provider interface, the extensible service provider interface providing a software method that allows identification of a network communication protocol associated with a request message and a client-server connection; wherein the identification of the network communication protocol is used to provide one or more of a client-server connection abstraction, a router abstraction, or support for using multiple network communication protocols on a single socket.

[0401] 16. A method as described in clause 15, wherein when a connection request message is received from a client and directed to a server, a determination is made as to whether the request can be handled using the provided network communication protocol, wherein the protocol identification processing returns an indication that the system does not support the requested network communication protocol, or that it does not currently have enough data to make the decision or requires additional data to make such a determination.

[0402] 17. A system or method as described in any of the preceding numbered clauses, wherein the system or method is provided as part of or used with a web server, and wherein the request is an HTTP request.

[0403] 18. A system or method as described in any of the preceding numbered clauses, wherein the system or method includes a request processing component using virtual threads and related libraries and features that can be used to build cloud native services.

[0404] 19. A system or method as described in any of the preceding numbered clauses, wherein the system or method is provided within a cloud computing environment that provides access to one or more clouds, databases, or other systems or services.

[0405] According to various embodiments, the teachings of this article can be implemented using one or more computers, computing devices, machines or microprocessors (including one or more processors, memories and / or computer-readable storage media programmed according to the teachings of this article). As will be apparent to those skilled in the software field, a skilled programmer can easily prepare appropriate software coding based on the teachings of this disclosure.

[0406] In some embodiments, the teachings herein may include a computer program product, which is a non-transitory computer-readable storage medium (or 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 media may include, but are not limited to, a hard disk drive, a hard drive, a fixed disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory device, or other type of storage medium or device suitable for non-transitory storage of instructions and / or data.

[0407] The foregoing 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. In addition, modifications and variations will be apparent to those skilled in the art.

[0408] 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.

[0409] The embodiments were chosen and described in order to best explain the principles of the teachings herein and their practical applications, thereby enabling others skilled in the art to understand 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.< / string> < / t> < / t> < / string> < / string> < / string>

Claims

1. A system for use with a microservice or other computing environment, comprising: A computer including one or more processors that provides access to microservices or other computing environments for use with software applications or services; wherein the system provides a software method that allows identification of a network communication protocol associated with a request message; as well as Wherein identification of the network communication protocol is used to provide one or more of header processing, client-server connection abstraction, router abstraction, or support for use of multiple network communication protocols over a socket.

2. A system as described in claim 1, wherein the system provides an abstraction that allows message headers to be treated as objects via a header enumeration, wherein the header enumeration is accessible via an application program interface that supports multiple communication protocols and allows clients and servers to communicate request and response messages using any of several supported protocols.

3. A system as described in claim 2, wherein when encountering a request message with a known header type, the system is able to obtain the indexed value from the enumeration if available and provide the associated data directly to the process directed by the request and / or cache the header value for later use.

4. The system of claim 1, wherein during testing of a software application or service, a client connection is replaced with an in-memory implementation that emulates the use of a network communication protocol and exposes an inverse function to a server connection, comprising: Data written to the data writer on the client connection is available through the data reader on the server connection, and Data written to the data writer on the server connection is available through the data reader on the client connection.

5. A system as described in claim 4, wherein the in-memory implementation uses a blocking queue in memory that simulates the use of a network communication protocol without the use of actual sockets, wherein testing has been completed and the client and / or server code can be compared to an actual socket implementation.

6. The system of claim 1, wherein the system enables configuration of a server operable to service requests via a variety of network or communication protocols, including: Provides a routing abstraction that associates each network or communication protocol supported by the server with its own route, and A routing abstraction can include one or more specific routes for use with a particular network or communication protocol.

7. The system of claim 6, wherein for a request message received via a specific protocol, the system is capable of selecting an appropriate route for the request and processing it according to the routing abstraction.

8. The system of claim 1, further comprising an extensible service provider interface that provides software methods that allow identification of a network communication protocol associated with a request message and a client-server connection; Wherein identification of the network communication protocol is used to provide one or more of a client-server connection abstraction, a router abstraction, or support for use of multiple network communication protocols over a single socket.

9. A system as claimed in claim 8, wherein when a connection request message is received from a client and directed to a server, a determination is made as to whether the request can be handled using the provided network communication protocol, wherein the protocol identification process returns an indication that the system does not support the requested network communication protocol, or that it does not currently have enough data to make the determination or that additional data is required to make such a determination.

10. The system of claim 1, wherein the system is provided as part of or used with a web server, and wherein the request is an HTTP request.

11. The system of claim 1, wherein the system includes a request processing component using virtual threads and related libraries and features that can be used to build cloud native services.

12. The system of claim 1, wherein the system is provided within a cloud computing environment that provides access to one or more clouds, databases, or other systems or services.

13. A method for use with a microservice or other computing environment, comprising: Providing a microservice or other computing environment for use with a software application or service; as well as providing a software method that allows identification of a network communication protocol associated with a request message; Wherein identification of the network communication protocol is used to provide one or more of header processing, client-server connection abstraction, router abstraction, or support for use of multiple network communication protocols over a socket.

14. The method of claim 13 further includes providing, by the system via a header enumeration, an abstraction that allows message headers to be viewed as objects, wherein the header enumeration is accessible via an application program interface that supports multiple communication protocols and allows clients and servers to communicate request and response messages using any of several supported protocols.

15. A method as claimed in claim 14, wherein when encountering a request message with a known header type, the system is able to obtain the indexed value from the enumeration if available and provide the associated data directly to the process directed by the request and / or cache the header value for later use.

16. The method of claim 13, further comprising, during testing of the software application or service, replacing the client connection with an in-memory implementation that emulates the use of the network communication protocol and exposes an inverse function to the server connection, comprising: Data written to the data writer on the client connection is available through the data reader on the server connection, and Data written to the data writer on the server connection is available through the data reader on the client connection.

17. A method as claimed in claim 16, wherein the in-memory implementation uses a blocking queue in memory that simulates the use of a network communication protocol without the use of actual sockets, wherein testing has been completed and the client and / or server code can be compared to an actual socket implementation.

18. The method of claim 13, performed by a system that enables configuration of a server operable to service requests via a variety of network or communication protocols, comprising: Provides a routing abstraction that associates each network or communication protocol supported by the server with its own route, and A routing abstraction can include one or more specific routes for use with a particular network or communication protocol.

19. The method of claim 18, wherein for a request message received via a specific protocol, the system is capable of selecting an appropriate route for the request and processing it according to the routing abstraction.

20. The method of claim 13, comprising providing an extensible service provider interface that provides software methods that allow identification of network communication protocols associated with request messages and client-server connections; Wherein identification of the network communication protocol is used to provide one or more of a client-server connection abstraction, a router abstraction, or support for use of multiple network communication protocols over a single socket.

21. A method as claimed in claim 20, performed by the system, wherein when a connection request message is received from a client and directed to a server, a determination is made as to whether the request can be handled using the provided network communication protocol, wherein the protocol identification processing returns an indication that the system does not support the requested network communication protocol, or that it does not currently have enough data to make the determination or requires additional data to make such a determination.

22. The method of claim 13, wherein the method is provided as part of or used with a web server, and wherein the request is an HTTP request.

23. The method of claim 13, wherein the method operates with a request processing component using virtual threads and related libraries and features that can be used to build cloud native services.

24. The method of claim 13, wherein the method operates within a cloud computing environment that provides access to one or more clouds, databases, or other systems or services.

25. A non-transitory computer-readable storage medium comprising instructions stored thereon, which when read and executed by one or more computers cause the one or more computers to perform a method comprising: Providing a microservice or other computing environment for use with a software application or service; as well as providing a software method that allows identification of a network communication protocol associated with a request message; Wherein identification of the network communication protocol is used to provide one or more of header processing, client-server connection abstraction, router abstraction, or support for use of multiple network communication protocols over a socket.

Images