System and Method for Header Processing in a Server Computing Environment

Abstract

According to one embodiment, the present specification describes systems and methods for use in microservices or other computing environments that include a web server along with related libraries and functions that can be used to build cloud-native applications or services. According to various embodiments, the systems and methods can include the use of various components or functions that support, for example, (a) header processing, (b) abstraction of client and server connections, (c) abstraction of routers, and (d) identification of connection protocols.

Description

Technical Field

[0001] Copyright Notice Part of the disclosure of this patent document contains materials that are subject to copyright protection. The copyright owner does not object to the reproduction by anyone of this patent document or this patent disclosure as it is recorded in the patent file or records of the Patent and Trademark Office, but in other cases, all copyrights are reserved in any and all instances.

[0002] Claim of Priority This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 343,934, filed May 19, 2022, entitled "SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT", U.S. Provisional Patent Application No. 63 / 392,039, filed Jul. 25, 2022, entitled "SYSTEMS AND METHODS FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT", U.S. Patent Application No. 18 / 198,759, filed May 17, 2023, entitled "SYSTEMS AND METHODS FOR HEADER PROCESSING IN A SERVER COMPUTING ENVIRONMENT", U.S. Patent Application No. 18 / 198,762, filed May 17, 2023, entitled "SYSTEMS AND METHODS FOR CLIENT-SERVER CONNECTION ABSTRACTION IN A SERVER COMPUTING ENVIRONMENT", U.S. Patent Application No. 18 / 198,764, filed May 17, 2023, entitled "SYSTEMS AND METHODS FOR ROUTER ABSTRACTION IN A SERVER COMPUTING ENVIRONMENT", and U.S. Patent Application No. 18 / 198,765, filed May 17, 2023, entitled "SYSTEMS AND METHODS FOR IDENTIFYING CONNECTION PROTOCOLS IN A SERVER COMPUTING ENVIRONMENT", and each of these applications and their contents are incorporated herein by reference.

[0003] TECHNICAL FIELD The embodiments described herein generally relate to cloud computing and other computing environments, software development, and microservices architectures, and in particular, to systems and methods for supporting application development, along with related libraries and functions that can be used to build cloud-native applications or services. BACKGROUND ART

[0004] Background 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, such as a cloud network that may be provided by a cloud computing environment. The microservices approach can be used, for example, to develop software applications or services that are to be provided in a cloud computing environment as cloud-native applications or services. SUMMARY OF THE INVENTION

[0005] Summary According to one embodiment, systems and methods for use in a microservices or other computing environment are described herein that include a web server, along with related libraries and functions that can be used to build cloud-native applications or services.

[0006] According to various embodiments, the systems and methods can include the use of various components or functions that support, for example, (a) HTTP headers, (b) abstraction of client and server connections, (c) abstraction of routers, and (d) identification of connection protocols.

[0007] According to one embodiment, the system provides an abstraction that allows message headers to be treated as objects accessible via an application programming interface (API) by header enumeration. The API supports multiple communication protocols and allows clients and servers to communicate request / response messages using any of the supported protocols. When encountering a request message with a known header type, the system can, if available, obtain an indexed value from the enumeration, directly provide the associated data (e.g., as data bytes) to the process the request is directed to, and / or cache the header values for later use.

[0008] According to one embodiment, for example, to support testing of a software application or service, a client connection can be replaced, for testing purposes, 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 the data writer of the client connection are available through the data reader in the server connection, and vice versa. During testing, the in-memory implementation uses a blocking queue in memory to emulate the use of the HTTP protocol without using actual sockets. Once a test using the in-memory implementation (e.g., unit test or integration test) is complete, the client code and / or server code can be tested against actual sockets for use in processing requests.

[0009] According to one embodiment, the system enables a configuration of a server that can operate to respond to requests via multiple networks or communication protocols such as, for example, HTTP1, gRPC over HTTP2, and / or WebSocket. Through route abstraction, each protocol can have its own routing, for example, HTTP routing. Sub-abstraction can provide more specific routes, such as, for example, HTTP / 1.1 routes or HTTP / 2 routes. For a request message received via a specific protocol, the system can select an appropriate route for that request and process the request accordingly.

[0010] According to one embodiment, an extensible Service Provider Interface (SPI) provides software methods that enable protocol identification for request messages and connections to support features such as abstraction of client / server connections, abstraction of routers, or use of different protocols on a single socket. When a connection request message directed from a client to a server is received, a determination is made as to whether the request can be appropriately processed. The protocol identification process can return an indication, for example, that the system does not support the request protocol, that the system does not have sufficient data to make a determination, or that additional data is required to make such a determination.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

DETAILED DESCRIPTION OF THE INVENTION

[0012] Detailed Description A microservices environment presents a software application as a collection of loosely coupled services that are independently deployable and communicate with each other via a network, such as a cloud network that may be provided by a cloud computing environment (cloud environment). The microservices approach can be used, for example, to develop software applications or services that should be provided in a cloud computing environment as cloud-native applications or services.

[0013] In the development of microservices, software development frameworks such as Helidon can be used. For example, as will be described later, the Helidon environment provides a collection of software libraries that support functions such as configuration, security, or web server functionality, and provides a basis for software application developers to develop cloud-native applications or services.

[0014] According to one embodiment, the Helidon library can interoperate with other software development, deployment, and / or monitoring tools, such as Docker, Kubernetes, Prometheus, or Jaeger.

[0015] Microservices environment Figures 1 to 4 show various examples of a microservices environment that provides a software development framework according to one embodiment.

[0016] According to one embodiment, the components and processes shown in Figures 1 to 4 and further described herein with respect to various embodiments can be provided as computer software or program code executable by a computer system or other type of processing device, such as a cloud computing system.

[0017] As shown in FIG. 1, according to one embodiment, a microservices environment 100 (such as provided by a microservices library, for example) can provide, for example, one or more Helidon SE 110, Helidon MP 120, and / or Helidon Nima 130 programming models or environments. The microservices environment can enable interaction of the developed applications with cloud, database, or other systems or services 140.

[0018] Examples of various embodiments of the Helidon microservices environment described herein are provided for the purpose of illustrating examples of a microservices computing environment or a microservices environment. According to various embodiments, the systems and methods described herein can be used in other types of microservices environments or computing environments.

[0019] According to various embodiments, the systems and methods can be used in other types of software development environments or in other types of web servers along with related libraries and functions available for building cloud-native services.

[0020] As shown in FIG. 2, according to one 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 functional programming.

[0021] For example, according to one embodiment, the Helidon SE environment provides a framework that allows application developers to build lightweight reactive microservices. This environment includes various libraries, application programming interfaces (APIs), or other components, such as a reactive web server 111 that provides asynchronous and reactive APIs for creating web applications, a configuration API 112 that provides a Java API for loading and processing configuration properties in key / value format into a configuration object that can later be used by the application to retrieve configuration data, and a security component 113 that provides authentication, authorization, and outbound security. It can also include metrics 114, health checks 115, and traces 116 or other components.

[0022] As shown in Figure 3, according to one embodiment, the Helidon MP environment supports a declarative programming style by using a family of MicroProfile APIs built on top of the Helidon libraries. Application portability can be supported across multiple MicroProfile runtimes using MicroProfile definitions (such as those specified by the Eclipse MicroProfile project).

[0023] For example, according to one embodiment, the Helidon MP environment can include various libraries, APIs, or other components such as, for example, JAX-RS 122, JSON-P 126, Contexts and Dependency Injection (CDI) 124, Metrics 121, Health Checks 123, Fault Tolerance 125, MicroProfile (MP) Configuration 137, and JSON Web Token (JWT) Authentication 128 components. The web server can be provided by a non-blocking client / server / web framework 118 such as Netty, for example.

[0024] As shown in FIG. 4, according to one embodiment, the Helidon Nima environment provides a Loom-based implementation of a web server, along with related libraries and functions that can be used to build cloud-native services.

[0025] For example, according to one embodiment, the Helidon Nima environment can include the use of various components or functions that support, for example, HTTP headers 131, client and server connection abstraction 132, router abstraction 133, and connection protocol identification 134, whereby application developers can build, for example, (non-reactive) blocking microservices.

[0026] FIG. 5 shows a system including a microservices environment as used to develop an application used in a cloud environment.

[0027] As shown in FIG. 5, according to one embodiment, the microservices environment presents a collection of loosely coupled services that can communicate with each other via a cloud network such that software applications can be independently deployable and provided via, for example, a cloud computing environment via the network.

[0028] For example, according to one embodiment, the Helidon microservices environment can support the use of a remote procedure call (e.g., gRPC) framework or component that enables (client and / or server) applications to communicate within the microservices environment in order to build connected systems.

[0029] According to one embodiment, the remote procedure call framework enables the definition of services and methods that can be remotely called. A server or service can process calls from a client through a local object (stub) that enables the client application to directly call a method on the server application as if it were a local object. The server / service implements methods to process client calls, such as decrypting incoming requests, executing service methods, and encoding service responses. The local object (stub) implements the same methods as the service, wraps the parameters for the call in the appropriate protocol buffer message type, and these parameters are then provided to the server as a request.

[0030] According to one embodiment, a microservices environment (such as provided by a microservices library) enables a client application 154 (e.g., 154A, 154B) in a client computer device 150 (e.g., 150A, 150B) having device hardware 152 (e.g., 152A, 152B) to communicate with microservices or to access, process transactions, or perform other operations associated with those systems or services, such as accessing a server application 174, a database 180, or other systems or services in a computer server device 170 having device hardware 172 and the cloud 160.

[0031] FIG. 6 further shows the use of a microservices environment for developing an application used in a cloud environment, according to one embodiment.

[0032] As shown in FIG. 6, according to one embodiment, the microservices environment enables a client application to access in such a way that the client application communicates with the cloud native service 180 or otherwise interacts with the cloud, database, or other systems or services for the purpose of accessing data, processing transactions, or performing other operations associated with those systems or services.

[0033] HTTP Request Processing In a cloud environment, the web service that enables a client application to interact with a server may be HTTP-based, i.e., the client application and the server can use the HTTP communication protocol as a means of communicating requests and responses among various participants in the form of data messages.

[0034] For example, in a cloud service that provides access to one or more databases or other services, the processing of a client request may be intended to result in several initial calls, each of which can then request another service to perform some further aspects of processing the request.

[0035] In some cloud environments, reactive programming techniques can be used to support parallel processing of requests. However, since reactive programming is non-blocking, it can be difficult to troubleshoot the operation of reactive applications. For example, thread dumps, which might otherwise be useful for evaluating the status of various threads, provide little or no information for testing or debugging purposes when used in a reactive environment.

[0036] According to one embodiment, to address such considerations, the system can include a Loom-based implementation of a request processing component, such as a web server (WebServer), along with associated libraries and functions available for building cloud-native services (referred to herein as Helidon Nima in some embodiments).

[0037] According to one embodiment, such a request processing component uses virtual threads to support the parallelism of client-server communication. With such virtual threads, a client HTTP application can operate in a normal blocking manner, for example, by requesting a connection to a server process, while the underlying request processing (e.g., Loom-based) environment processes the parallelism of request processing.

[0038] This improves the code development process in that application developers do not need to incorporate reactive programming into the application itself. Further, during testing or debugging, thread dumps provide more useful information for troubleshooting purposes. Thus, this approach combines the features of conventional programming environments with the advantages of the parallelism of reactive programming.

[0039] For example, according to one embodiment, the Helidon Nima environment enables application developers to set up HTTP endpoints through which the server can provide services to web clients. The client application can be executed in a blocking manner within the environment while utilizing virtual threading that provides virtual threads for each connection, achieving a high level of concurrency.

[0040] FIG. 7 shows a system including a microservices environment according to one embodiment.

[0041] As shown in FIG. 7, according to one embodiment, when used in a web server 190 (WebServer, e.g., Helidon Nima environment), a request processing component 200, e.g., a Loom-based implementation of the web server, enables the use of blocking code without the requirement of using a large number of platform threads, including the use of a blocking API that allows requests directed to the server to be executed on application virtual threads 210.

[0042] According to one embodiment, virtual threads (referred to as fibers in some examples) operate as lightweight threads that enable the execution of high-throughput parallel applications. Generally described, 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 execute on a virtual thread over the duration of a request, and the virtual thread further consumes an O / S thread while executing operations on the processor.

[0043] According to one embodiment, a non-blocking API can be encapsulated by a synchronous API and made virtual-thread compliant by blocking further execution of the virtual thread until the corresponding operation is completed. In this way, each virtual thread can be interrupted for a period of time and then continue at a later point.

[0044] For example, as shown in FIG. 7, according to one embodiment, when executed on virtual machine 220, requests can be received by blocking API 222. Multiple carrier threads 224 communicate with underlying operating system 230, for example, by registering events and callbacks with non-blocking API 232 or via O / S thread pool 226 and blocking API 234.

[0045] According to one embodiment, with such a request processing component, application developers can utilize non-blocking APIs during software development without changing the thread-per-request programming model. Also, with the described approach, the system can use blocking code such as outbound HTTP requests or database requests without the need to handle complex executor services.

[0046] FIG. 8 shows a web server used in a microservices environment according to one embodiment.

[0047] As shown in FIG. 8, according to one embodiment, a web server that uses virtual threads, such as a Loom-based implementation of a web server, can be provided 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).

[0048] As described above, the request processing component supports the parallelism of client-server communication using virtual threads. With such virtual threads, a client HTTP application can, for example, request a connection to a server process in a normal blocking manner, while the underlying request processing (e.g., Loom-based) environment processes the parallelism of request processing.

[0049] For example, according to one embodiment of the Helidon SE environment, the request processing component can be provided as an alternative to the reactive web server normally provided in such an environment. Instead of using reactive programming, application developers can use the virtual threads provided by the web server to support application processing that is blocking rather than reactive while providing similar performance characteristics.

[0050] According to various embodiments, the request processing component can be provided similarly herein as the web server used in other / new versions of Helidon (e.g., Helidon Nima).

[0051] For example, according to one embodiment, from the perspective of an application developer, the application developer can include in their application either a blocking code that directly uses the virtual thread functionality of a request processing component, e.g., a Loom-based web server, or application code that is itself reactive but can be transparently processed for the application developer by a (e.g., Loom-based) web server using the virtual thread functionality provided by the web server.

[0052] Web server / Web client According to various embodiments, the system and method can include the use of various components or functions that support, for example, (a) HTTP headers, (b) abstraction of client and server connections, (c) abstraction of routers, and (d) identification of connection protocols.

[0053] According to one embodiment, a WebServer can be provided as an extensible module having a default implementation that supports the HTTP / 1.1 protocol. The WebServer SPI provides extensibility by supporting upgrades from the HTTP / 1 protocol, such as an upgrade to HTTP / 2 using, for example, plain sockets, or an upgrade to WebSocket, discovery based on binary data for other protocols including non-HTTP protocols that are extensible through, for example, prior knowledge of HTTP / 2, and / or application layer protocol negotiation (ALPN) support for transport layer security (TLS) requirements such as HTTP / 1.1, HTTP / 2.

[0054] According to one embodiment, the extension module can include, for example, an HTTP / 2 protocol implementation, an upgrade from HTTP / 1 to HTTP / 2 over TCP (h2c, plain socket) with prior knowledge, h2c (TLS) (ALPN support), a gRPC protocol implementation as an "application protocol" of HTTP / 2, and / or an upgrade of the WebSocket protocol implementation from HTTP / 1.

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

[0056] According to one embodiment, the WebClient can be provided as an extensible module with a default implementation that supports the HTTP / 1.1 protocol. The WebClient SPI supports other protocols that should share and use the basic configuration. According to one embodiment, the following extensions can be included, namely, an HTTP / 1.1 client and an HTTP / 2 client.

[0057] According to one embodiment, the WebServer module and the WebClient module are designed to be testable, for example, by JUnit5. The system can support either HTTP communication or in-memory communication according to the selected annotation. For example, @ServerTest provides HTTP communication via sockets to create integration tests, and / or @RoutingTest provides in-memory communication to create unit tests.

[0058] According to one embodiment, additional modules such as "circuit breaker", "bulkhead", "fallback", "retry" scenario fault tolerance implementation, blocking fault tolerance implementation, health, metrics, configuration, application information, etc., observability endpoints for obtaining information about the application, means for providing extensibility to plug other modules into the "observe" mechanism, and / or trace, or open telemetry trace support can be included.

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

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

[0061] To parse such headers, a significant amount of computational overhead is required, especially when thousands of requests need to be processed simultaneously, as may be encountered in a cloud environment. Preparing responses to such requests with their appropriate headers also similarly requires a significant amount of computational overhead.

[0062] According to one embodiment, the system provides an abstraction that allows message headers to be treated as objects accessible via an application programming interface (API) by header enumeration, where the API supports multiple communication protocols and enables clients and servers to communicate request / response messages using any of the supported protocols.

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

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

[0065] Furthermore, as HTTP / 2 is becoming increasingly frequently used, it is advantageous to use headers that work well with both HTTP versions. Implementations in Java may use String or CharSequence to identify headers or optimize the byte values of header names, but generally do not use an indexed approach for commonly used headers.

[0066] The approach described avoids the need to look up a header map for each request and enables computational savings, especially when processing large numbers of requests that may be encountered in a cloud environment.

[0067] FIG. 9 shows support for HTTP header processing according to one embodiment.

[0068] As shown in FIG. 9, according to one embodiment, the system provides an abstraction by header enumeration 250 that enables message headers to be treated as objects accessible via an application programming interface (API), the API supports multiple communication protocols, and allows clients and servers to communicate request / response messages using any of the supported protocols.

[0069] According to one embodiment, when encountering a request message with known header types (e.g., A1 252, A2 253, B1 256, B2 257), the system can, if available, obtain an indexed value (e.g., A254, B258) from the enumeration, directly provide the associated data (e.g., as data bytes) to the process the request is directed to, and / or cache the header value (270) for later use.

[0070] According to one embodiment, the HTTP header is used as an object type. When a known header is created, the system can cache all of the data bytes of the value (in the case of a single value), the complete HTTP / 1 bytes of the entire header (e.g., "Content-Encoding: gzip"), whether the value is sensitive and should never be logged or indexed (HTTP / 2), and whether the value changes and should not be cached or indexed (HTTP / 2).

[0071] According to one embodiment, for headers parsed from requests, the system can use lazy evaluation, which includes storing bytes until the server or other process actually requests the header value. Since there are usually headers that are never requested, this reduces the processor (CPU) resources used to process each request.

[0072] According to one embodiment, known header names (i.e., commonly used header names) are implemented with an enumeration (HeaderEnum). The enumeration is used by HTTP / 2 to prevent frequent lowercasing of strings, with a lowercased name (String), and by HTTP / 1 to have the expected header name, with a "default case" name (String). It maintains an index of headers to support optimized storage in requests and responses for quickly identifying whether a header exists and for optimizing the search for such headers through indexed access to an array. This is a significant improvement because in various implementations, maps may originally be used to store headers, and the storage and search operations of maps are significantly more costly than direct access to an indexed array.

[0073] FIG. 10 further shows support for HTTP header processing according to one embodiment.

[0074] As shown in FIG. 10, according to one embodiment, access to the header object 260 can be achieved through a high-level API that can be provided as a name API 262 (e.g., HeaderName interface) and a value API 264 (e.g., HeaderValue interface).

[0075] According to one embodiment, the HeaderName interface can include methods such as the following.

[0076] Method String lowerCase() - Name of an HTTP / 2 header (such as content-type).

[0077] Method String defaultCase() - Name of an HTTP / 1 header (such as Content-Type).

[0078] Method int index() - To identify "known" headers (0+) and custom headers (-1).

[0079] Method boolean isPseudoHeader() - HTTP / 2 pseudo headers, for example, "Host" in HTTP / 1 is the ":authority" pseudo header in HTTP / 2.

[0080] According to one embodiment, the HeaderValue interface can include the following methods.

[0081] Method HeaderName headerName() - Name of the header.

[0082] Method String Value() - First value of the header, which may be backed by lazy evaluation.

[0083] Other methods for multi-valued headers.

[0084] FIG. 11 further shows support for HTTP header processing according to one embodiment.

[0085] As shown in FIG. 11, according to one embodiment, the HTTP header is used as an object type. When a request 280 having a known header 282 or indicated by its header name 284 is created, the system determines for the value 286 whether it is a data byte of the value (in the case of a single value), the complete HTTP / 1 byte of the entire header (e.g., "Content-Encoding: gzip"), whether the value is sensitive and should never be logged or indexed (HTTP / 2), and whether the value has changed and should not be cached or indexed (HTTP / 2), and can cache all of them.

[0086] FIG. 12 further shows support for HTTP header processing according to one embodiment.

[0087] As shown in FIG. 12, according to one embodiment, for a header parsed from a request, the system can use lazy evaluation and store the bytes as a cached header value 288 until the server or other process actually requests the header value.

[0088] According to one embodiment, the system can provide support for various interfaces, classes, or methods, such as by the following program, which provides an implementation (and cached value) of a string created from bytes only when necessary, for example, as follows: inner class Header constants on class methods create(String) create(String, String) createFromLowercase(String) inner class HeaderName inner class HeaderValue methods createCached(HeaderName, String) create(HeaderName, LazyString) create(HeaderName, String...) createCached(HeaderName, boolean, boolean, String) create(HeaderName, boolean, boolean, String...) inner class HeaderValues constants on class

[0089] The above examples are provided for illustrative purposes, and according to various embodiments, other examples of interfaces, classes, or methods can be provided.

[0090] FIG. 13 shows a method used in a microservices environment for processing HTTP headers according to one embodiment.

[0091] As shown in FIG. 13, according to one embodiment, at step 290, in a computer including one or more processors and a memory, a microservices environment (such as provided by a microservices library) is provided that enables a client application and a server application to communicate within the microservices environment.

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

[0093] In step 294, a header object is provided, along with a name application programming interface (API) and a value API that are used when setting or determining a header name and / or header value associated with an HTTP request.

[0094] In step 296, when receiving a request with a known header type, the system stores the header value in a cache for later deferred search and evaluation if requested by the server process.

[0095] Interface Example According to one embodiment, an example interface for providing an HTTP header is provided below. According to other embodiments, other types of interfaces can be provided.

[0096] Interface HeaderName According to one embodiment, the Http.HeaderName interface can be used to provide an HTTP header name, which can include various methods such as the following.

[0097] Method String lowerCase(): The lower-case value of this header used in HTTP / 2 may be used for lookups by HTTP / 1. Since there is no validation of this value, if it contains uppercase letters, the behavior is undefined. In one embodiment, this method returns the header name in lower case.

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

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

[0100] Method boolean isPseudoHeader(): HTTP / 2 defines pseudo headers as headers starting with the ":" character. These are used instead of the prologue lines (for defining things like the path, authorization, etc.) of HTTP / 1 and instead of the status line of the response. In one embodiment, this method returns whether this header is a pseudo header or not.

[0101] Interface HeaderValue According to one embodiment, the Http.HeaderValue interface can be used to provide HTTP header values, which can include various methods such as the following.

[0102] Method static Http.HeaderValue createCached(Http.HeaderName name, String value). Creates and caches a byte value. This method is used when the header value is stored in a constant or is used repeatedly. Parameters that can be provided include, for example, name - the name of the header, value - the value of the header. In one embodiment, this method returns a new header.

[0103] Method static Http.HeaderValue create(Http.HeaderName name, LazyString value). Creates a new header with a single value. This header is considered immutable and insensitive. Parameters that can be provided include, for example, name - the name of the header, value - a lazy string with the value. In one embodiment, this method returns a new header.

[0104] The method static Http.HeaderValue create(Http.HeaderName name, String value). Creates a new header with a single value. This header is considered immutable and insensitive. The parameters that can be provided include, for example, name - the name of the header, value - the value of the header. In one embodiment, the method returns a new header.

[0105] The method static Http.HeaderValue create(Http.HeaderName name, String... values). Creates a new header. This header is considered immutable and insensitive. The parameters that can be provided include, for example, name - the name of the header, values - the values of the header. In one embodiment, this method returns a new header.

[0106] The method static Http.HeaderValue create(Http.HeaderName name, List <string>Create a new header. This header is considered immutable and insensitive. Parameters that can be provided include, for example, the name of the name-header and the value of the values-header. In one embodiment, this method returns a new header.

[0107] The method static Http.HeaderValue createCached(Http.HeaderName name, boolean changing, boolean sensitive, String value). Creates and caches a byte value. This method is used when the header value is stored in a constant or used repeatedly. Parameters that can be provided include, for example, the name of the name-header, whether the changing-(invalidates the cache for HTTP / 2) value changes frequently, whether the sensitive-(invalidates the cache for HTTP / 2) value is sensitive, and the value of the value-header. In one embodiment, this method returns a new header.

[0108] The method static Http.HeaderValue create(Http.HeaderName name, boolean changing, boolean sensitive, String... values). Creates a new header. Parameters that can be provided include, for example, the name of the name-header, whether the changing-(invalidates the cache for HTTP / 2) value changes frequently, whether the sensitive-(invalidates the cache for HTTP / 2) value is sensitive, and the values of the values-header. In one embodiment, this method returns a new header.

[0109] The method String name(). The name of the header as configured by the user or received in the communication. In one embodiment, this method always returns the header name in lowercase for HTTP / 2 headers.

[0110] Method Http.HeaderName headerName(). The header name of the header. In one embodiment, this method returns the header name.

[0111] Method String value(). The first value of this header. In one embodiment, this method returns the first value.

[0112] Method List <string>allValues(). All values of this header. In one embodiment, this method returns all configured values.

[0113] defalt List of the method <string>allValues(boolean split). All values of this header. If this header is defined as a single header with comma-separated values, set split to true. Parameters that can be provided include, for example, split - whether to split a single value by commas and do nothing if the value is already in a list. In one embodiment, this method returns a list of values.

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

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

[0116] Method default byte[] valueBytes(). Cached bytes of the value of a single-value header. In one embodiment, this method returns the bytes of the value.

[0117] Method default void writeHttp1Header(BufferData buffer). Write the current header to the buffer provided as an HTTP header. Parameters that can be provided include, for example, buffer - the buffer for writing (to be extended).

[0118] Implementation of the header According to one embodiment, a header object can be used to store headers parsed from a request or configured by a user (by the user for processing or by a server for writing out via a network) for later search. The following example shows the parts necessary to utilize direct access when obtaining and setting headers. class Headers / / An array of known headers accessed via an index HeaderValue[] knownHeaders = new HeaderValue[KNOWN_HEADER_SIZE] Map<HeaderName, HeaderValue> customHeaders = new Map() HeaderValue find(HeaderName name) var index = name.index() return index == -1? customHeaders.get(name) : knownHeaders[index] void set(HeaderValue value) var name = header.headerName() var index = name.index() if (index == -1) { customHeaders.put(name, value) } else { knownHeaders[index] = value }

[0119] B. Abstraction of Client and Server Connections According to one embodiment, a request processing component such as Loom uses virtual threads to support the parallelism of client-server communication. With such virtual threads, a client HTTP application can operate in a normal blocking manner, for example, request a connection to a server process, while the underlying request processing (e.g., Loom-based) environment processes the parallelism of request processing.

[0120] The ability to develop client applications using such request processing components provides a simpler code development process. For example, application developers do not need to incorporate reactive programming into their applications themselves.

[0121] According to one embodiment, to support the testing of software applications or services, client connections can be replaced, for testing purposes, with an in-memory implementation that does not call, for example, HTTP, but instead exposes inverse functions to server connections. For example, data bytes written to the data writer of a client connection are available through the data reader in the server connection, and vice versa.

[0122] During testing, the in-memory implementation uses a blocking queue in memory to emulate the use of the HTTP protocol without using actual sockets. When such a test (e.g., unit test) is completed, the client and / or server code can be tested against actual network sockets (e.g., integration test).

[0123] For example, when it is desired to create a service that can be easily tested without the need to rewrite the same test depending on whether the application developer runs unit tests or integration tests. Usually, abstraction becomes extremely complex in order to optimize performance, for example, using an event loop mechanism, reactive code, etc.

[0124] The approach described enables improvements in testing or debugging. For example, during testing or debugging, thread dumps provide more useful information for troubleshooting purposes.

[0125] Figure 14 shows support for client and server abstraction according to one embodiment.

[0126] As shown in Figure 14, according to one embodiment, to support testing of a software application or service, the client connection can be replaced, for testing purposes, with an in-memory implementation 300 that does not call, for example, HTTP, but instead exposes inverse functions to the server connection. For example, data bytes written to the data writer 304 of the client connection are available through the data reader 306 in the server connection, and vice versa.

[0127] Figure 15 further shows support for client and server abstraction according to one embodiment.

[0128] As shown in Figure 15, according to one embodiment, during testing (e.g., when testing the process of a request 310 directed to server code 320), the in-memory implementation uses a blocking queue in memory to emulate the use of the HTTP protocol but does not use actual sockets.

[0129] Figure 16 further shows support for client and server abstraction according to one embodiment.

[0130] As shown in Figure 16, according to one embodiment, when a test (e.g., unit test or integration test) is completed using the in-memory implementation, the client 330 and / or server code 322 can be tested against actual sockets for use in processing a request 312.

[0131] Figure 17 further shows support for client and server abstraction according to one embodiment.

[0132] As shown in FIG. 17, according to one embodiment, for example, the server code 324 can be updated, tests can be performed on an in-memory implementation that uses a blocking queue in memory, and a client 332 can be implemented for an actual socket for use in processing the request 314, and the process can be repeated.

[0133] According to one embodiment, the system abstracts the connection into two basic operations, namely, (1) using a DataWriter to write to the connection, and (2) using a DataReader to read from the connection.

[0134] According to one embodiment, the system enables an application developer to replace a client connection with an in-memory implementation that does not call network socket communication but exposes an inverse function to the server connection (bytes written to the DataWriter of the client connection are available via the DataReader in the server connection, and vice versa).

[0135] According to one embodiment, this enables an application developer to write a single application code for testing the server code, and by simply switching between an actual or realistic HTTP client and an in-memory HTTP client, the application developer can test both the validity of the routing code in unit tests and the validity of the entire server code that uses integration tests (e.g., opening a port and calling it with the HTTP protocol).

[0136] According to one embodiment, examples of tests that use this include unit tests that create an instance of DirectClient that implements an HTTP1Client using in-memory connection abstraction, integration tests that create an instance of an HTTP1Client that connects via a network, or an abstract class that obtains an instance of an HTTP1Client and defines an actual test such as the following. @Test void testHealthObserver() { try (Http1ClientResponse response = client.get(" / observe / health").request()) { assertThat(response.status(), is(Http.Status.NO_CONTENT_204)); } }

[0137] According to one embodiment, the system can provide support for various interfaces, classes, or methods as exemplified below.

[0138] According to one embodiment, an abstraction (DataReader) that can provide bytes can be provided as a data reader that can extract additional data, for example, as follows. DataReader { / ** * A data reader from a byte supplier. * @param bytesSupplier A supplier that can extract more data, regardless of its source (network or memory). * for more data * / DataReader(Supplier<byte[]> bytesSupplier) / ** * The number of bytes available for the currently retrieved data. * @return The number of available bytes * / int available() / ** * Retrieves the next data. * / void pullData / ** * Skips n bytes. * @param lenToSkip (must be less than or equal to the current capacity) The number of * bytes to skip * / void skip(int lenToSkip) / ** * Ensures that at least 1 byte is available. * / void ensureAvailable() / ** * Reads 1 byte. * @return The next byte * / byte read() / ** * Reads the next buffer. * Reads {#available()} number of bytes into the buffer and moves the position. * @return Buffer data wrapping the available bytes * / BufferData readBuffer() / ** * Reads the next buffer of the defined size. If the length is not available, * retrieves additional data. * Moves the position. * @param length The length of the data to read * @return Buffer data with the required length * / BufferData readBuffer(int length)

[0139] According to one embodiment, an abstraction (DataWriter) that can consume bytes can be provided as a data writer that can write data to an underlying transport (e.g., a socket), for example, as follows. interface DataWriter { / ** * Write buffers may cause writes to be sent, * and may be written to by different threads. * This method may also combine multiple calls into a single write to the underlying transport. * @param buffers The buffers to write * / * / void write(BufferData... buffers) }

[0140] According to one embodiment, an abstraction of a client connection (ClientConnection) that enables the use of a custom connection for testing can be provided, for example, as follows. interface ClientConnection { / ** * A data reader that provides response bytes. * @return The reader to read from this connection * / DataReader reader(); / ** * A data writer for writing client requests. * @return The writer to write to this connection * / DataWriter writer(); }

[0141] According to one embodiment, it is possible to provide an implementation of in-memory client connection (DirectClientConnection), and such a connection bypasses the network protocol and directly routes to server-side routing, for example, as follows. class DirectClientConnection implements ClientConnection { Router router; DataReader clientReader; DataWriter clientWriter; DataReader serverReader; DataWriter serverWriter; DirectClientConnection(Router router) this.router = router; var serverToClient = new ArrayBlockingQueue<>(1024); var clientToServer = new ArrayBlockingQueue<>(1024); this.clientReader = reader(serverToClient); this.clientWriter = writer(clientToServer); this.serverReader = reader(clientToServer); this.serverWriter = writer(serverToClient); } @Override public DataReader reader() { return clientReader; } @Override public DataWriter writer() { return clientWriter; } private DataWriter writer(ArrayBlockingQueue<byte[]> queue) { return new DataWriter() { @Override public void write(BufferData... buffers) { for (BufferData buffer : buffers) { write (buffer); } } write (BufferData buffer) { byte[] bytes = new byte[buffer.available()]; buffer.read(bytes); try { queue.put(bytes); } catch (InterruptedException e) { throw new IllegalStateException("スレッドが中断された", e); } } }; } private DataReader reader(ArrayBlockingQueue<byte[]> queue) { return new DataReader(() -> { byte[] data; try { data = queue.take(); } catch (InterruptedException e) { throw new IllegalArgumentException("The thread was interrupted", e); } if (data.length == 0) { return null; } return data; }); } }

[0142] According to one embodiment, an implementation of an HTTP / 1.1 network connection via a network using a reader and a writer having network sockets instead of in-memory arrays can be provided, for example, as follows. class Http1ClientConnection implements ClientConnection { private DataReader reader; private DataWriter writer; private String host; private int port; @Override public DataReader reader() { return reader; } @Override public DataWriter writer() { return writer; } Http1ClientConnection connect() { try { socket = new Socket(); socket.connect(new InetSocketAddress(host, port), (int) options.connectTimeout().toMillis()); } catch (IOException e) { throw new UncheckedIOException("Failed to connect to " + host + ":" + port, e); } var helidoSocket = createSocket(socket); / / to wrap input and output streams this.reader = new DataReader(helidonSocket); this.writer = new DataWriter() { @Override public void write(BufferData... buffers) { for (BufferData buffer : buffers) { write (buffer); } } void write(BufferData buffer) { helidonSocket.write(buffer); } }; return this; } }

[0143] According to one embodiment, the communication between the client and the server can be abstracted for the client into various components, namely, ClientConnection (as described above), as well as ClientRequest and ClientResponse for a request / response-based protocol.

[0144] According to one embodiment, the communication between the client and the server can be abstracted for the server into various components, namely, ServerConnection, as well as ServerRequest and ServerResponse for a request / response-based protocol.

[0145] When implementing the client, the developer can select the connection to be used in the new ClientRequest, providing either a network-based connection or an in-memory connection.

[0146] When implementing a client that does not rely on the request / response paradigm (such as the WebSocket protocol that uses the concept of a listener), the client directly processes the abstraction, calling an in-memory server listener if an in-memory connection is used, or calling the server via the network to process a server-side listener. A direct WebSocket client using in-memory communication can be provided, for example, as follows. DirectWsClient implements WsClient { WsRouting routing; / / Refer to the invention of WebSocket routing, routing abstraction / / Connect in-memory using the provided client listener connect(URI uri, WsListener listener) { HttpPrologue prologue = HttpPrologue.create("ws”, "ws”, …) WsRoute route = routing.findRoute(prologue); / / Discover the WebSocket route to be used / / Create an in-memory connection between the client listener and the server route DirectWsConnection conn = DirectWsConnection.create(prologoue, listener, route); conn.start(); / / start the communication } }

[0147] According to one embodiment, a method connection using an implementation (WsClientImpl) for a network-based WebSocket client connection can be provided, for example, as follows. DirectWsClient implements WsClient { connect(URI uri, WsListener listener) { Socket socket = new Socket(); Socket.connect(uri.getHost(), uri.getPort()); var helidonSocket = helidonSocket(socket); handleUpgradeToWs(helidonSocket); ClientWsConnection session = new ClientWsConnection(listener, helidonSocket); / / With an executor such as a VirtualThread executor / / Execute the client / server session executor().submit(session); } }

[0148] According to one embodiment, an equivalent on the server side (ConnectionContext) that uses a data writer and a data reader to be used in server connection can be provided, for example, as follows. public interface ConnectionContext extends SocketContext { / ** * The data writer to which response bytes should be written. * @return The data writer * / DataWriter dataWriter(); / ** * The data reader to read request bytes. * @return The data reader * / DataReader dataReader(); / ** * The router that may include different types of routing (HTTP, WebSocket, grpc). * @return The router * / Router router(); }

[0149] The above example is provided for illustrative purposes, and according to various embodiments, other examples of interfaces, classes, or methods can be provided.

[0150] FIG. 18 shows a method used in a microservice environment to provide abstraction of a client and a server according to one embodiment.

[0151] As shown in FIG. 18, according to one embodiment, in step 340, in a computer including one or more processors and a memory, a microservices environment (such as provided by a microservices library) is provided that enables a client application and a server application to communicate within the microservices environment.

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

[0153] In step 344, the user prepares routing code to test the server code, such as for use with an HTTP client, and can switch between an actual or real client and the in-memory implementation of the client to test the validity of the routing code.

[0154] In step 346, the user can update the routing code and / or the server code and continue to switch between the actual or real client and the in-memory implementation to continue testing.

[0155] Interface Example According to one embodiment, a client connection can be provided that uses the ClientConnection interface (an example of which was described above) to enable the use of a custom connection for testing.

[0156] C. Router Abstraction In a cloud environment that supports client-server communication via different communication protocols, each communication protocol may have its own requirements regarding the formatting of messages passed between participants, including a message header.

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

[0158] According to one embodiment, the system enables a configuration of a server that can operate to respond to requests via multiple networks or communication protocols such as, for example, HTTP1, gRPC over HTTP2, and / or WebSocket.

[0159] Through route abstraction, each protocol can have its own routing, for example, HTTP routing. Lower-level abstractions can provide more specific routes, such as, for example, an HTTP1 route or an HTTP2 route. For a connection / request received via a particular protocol, the system can select an appropriate route for that request and process it accordingly.

[0160] For example, it may be desirable to configure routing on a server builder that can process any supported protocol without depending on the implementation of each protocol. To do this, it is necessary to abstract routers and various routings so that application developers can add new routings to the server. For example, in a Java environment, such abstraction can be provided simply by adding a library to the classpath. In other implementations, HTTP routing may be supported for multiple protocol versions, but there may be no function to create version-specific routes. Furthermore, depending on the implementation, some may require specific processing according to the protocol version required by the user, or explicit dependencies on these protocols.

[0161] The described approach enables easy definition of the configuration of a server that supports multiple protocols.

[0162] FIG. 19 shows support for router abstraction according to one embodiment.

[0163] As shown in FIG. 19, according to one embodiment, the system enables the configuration 350 of a server that can operate to respond to requests via multiple networks or communication protocols, and each of these protocols is associated with a routing type 352, such as routing type A354 having a method 355, for use in server code 360 and builder 362.

[0164] Through route abstraction, each protocol can have its own routing, such as HTTP routing. Lower-level abstraction can provide more specific routes, such as HTTP / 1 routes or HTTP / 2 routes. For a request message received via a specific protocol, the system can select an appropriate route for the request and process the request accordingly.

[0165] Figure 20 further shows support for router abstraction according to one embodiment.

[0166] As shown in Figure 20, according to one embodiment, a builder can provide protocol support 364 for a first protocol A within server code. Similarly, the system enables a configuration of a server that supports a routing type B358 having a method 359 for use with the server code.

[0167] Figure 21 further shows support for router abstraction according to one embodiment.

[0168] As shown in Figure 21, according to one embodiment, a builder can provide protocol support 366 for a second protocol B within server code.

[0169] Figure 22 further shows support for router abstraction according to one embodiment.

[0170] As shown in Figure 22, according to one embodiment, a server configured as such can operate to respond to requests via multiple networks or communication protocols, such as a request A370 using protocol A372 and a request B380 using protocol B382.

[0171] For example, according to one embodiment, this routing abstraction supports routing for any HTTP version by virtue of the ability to create HTTP version-specific routes. Routes can be added for a subset of HTTP (such as gRPC), or even for other types of protocols that are independent of HTTP (such as WebSocket) and upgraded from HTTP.

[0172] According to one embodiment, this is achieved by abstracting a Router that can include multiple types of routing. When setting up a server, an application developer can register the routing with its builder. Therefore, the routing includes protocol-specific methods that enable the configuration of its protocol. By combining these, for example, as follows, a single server can be created that can handle requests to all supported protocols using a single router configuration. .addRouting(HttpRouting.builder() .get(" / ", (req, res) -> res.send("Hello World")) .route(Http1Route.route(GET, " / http1", (req, res) -> res.send("Hello World 1"))) .route(Http2Route.route(GET, " / http2", (req, res) -> res.send("Hello World 2")))) .addRouting(GrpcRouting.builder() .unary(Strings.getDescriptor(), "StringService", "Upper", ProtocolsMain::grpcUpper)) .addRouting(WebSocketRouting.builder() .endpoint(" / websocket / echo", ProtocolsMain::wsEcho))

[0173] According to one embodiment, various advantages of the described approach can include, for example, the ability to combine protocols within the same server. The protocols are separate modules and there is no dependency from the routing API to each protocol implementation (e.g., additional protocols and their routes can be added without changing the server). It is possible to create HTTP routes that have corresponding HTTP routes (the " / " route in the example shown above) for any HTTP version, or HTTP version-specific routes (the " / http1" and " / http2" routes in the example shown above). This approach provides complete abstraction from the HTTP version for the user, i.e., the code can be made completely version-independent. This approach also provides an extensible mechanism, so for example, there should be no need to change the routing code to support HTTP / 3.

[0174] According to one embodiment, the system can provide support for various interfaces, classes, or methods as illustrated below.

[0175] According to one embodiment, a Router interface can be used to set up routing and can include routing for two or more protocols. The method can be, for example, routing(Class for obtaining a specific type of routing <t>, T) can be included, and the router for the server includes various types of routing. Therefore, the server can process each protocol as fast as possible. For example, it is as follows. public interface Router { / ** * Obtain a specific type of routing. * @param routingType The type of routing * @param defaultValue The default value to be used when the routing is not defined in this router * @param * @param <t>Type of routing * @return The defined routing, or the default value if not found * / <T extends Routing> T routing(Class <t>routingType, T defaultValue); / ** * Builder for a stand-alone router. * / interface Builder { / ** * Add new routing to this router * @param routing {@code webserver.http.HttpRouting} etc., * The routing to be added * @return The updated builder * / B addRouting(Routing routing); } }

[0176] According to one embodiment, the routing marker interface (Routing) can be provided, for example, as follows. / ** * Abstraction of routing. * / public interface Routing { }

[0177] According to one embodiment, an HTTP routing implementation (HttpRouting) that can handle any HTTP version of routing can be provided, for example, as follows. public final class HttpRouting implements Routing { private final ServiceRoute rootRoute; private HttpRouting(Builder builder) { this.rootRoute = builder.rootRules.build(); } / ** * Creates a new instance of {io.webserver.http.HttpRouting.Builder router builder}. * @return A new instance * / public static Builder builder() { return new Builder(); } / ** * Routes a request. * The handler HTTP filters and finds a route. * @param ctx The context * @param request The routing request * @param response The routing response * / public void route(ConnectionContext ctx, RoutingRequest request, RoutingResponse response) { HttpPrologue prologue = request.prologue(); RoutingResult result = RoutingResult.ROUTE; int counter = 0; while (result == RoutingResult.ROUTE) { counter++; if (counter == 10) { LOGGER.log(System.Logger.Level.ERROR, "Re-routed more than 10 times. No more routing attempts will be made"); throw HttpException.builder() .request(HttpSimpleRequest.create(prologue, request.headers())) .type(SimpleHandler.EventType.INTERNAL_ERROR) .build(); } result = doRoute(ctx, request, response); } / / End and completion if (result == RoutingResult.FINISH) { return; } throw HttpException.builder() .request(request) .response(response) .type(SimpleHandler.EventType.NOT_FOUND) .message("Endpoint not found") .build(); } private RoutingResult doRoute(ConnectionContext ctx, RoutingRequest request, RoutingResponse response) { HttpPrologue prologue = request.prologue(); RouteCrawler crawler = rootRoute.crawler(ctx, request); while (crawler.hasNext()) { response.resetRouting(); RouteCrawler.CrawlerItem next = crawler.next(); request.path(next.path()); try { next.handler().handle(request, response); if (response.shouldReroute()) { if (response.isSent()) { return RoutingResult.FINISH; } HttpPrologue newPrologue = response.reroutePrologue(prologue); request.prologue(newPrologue); response.resetRouting(); return RoutingResult.ROUTE; } if (response.isNexted()) { if (response.isSent()) { return RoutingResult.FINISH; } continue; } if (!response.hasEntity()) { / / Do not return the next element, do not re - route, just send it! response.send(); } return RoutingResult.FINISH; } catch (CloseConnectionException | HttpException e) { throw e; } catch (Exception thrown) { if (thrown.getCause() instanceof SocketException se) { throw new UncheckedIOException(se); } if (!response.isSent()) { boolean keepAlive = true; try { request.content().consume(); } catch (Exception e) { keepAlive = request.content().consumed(); } / / Since the request could not be consumed, / / the connection must be closed throw HttpException.builder() .type(SimpleHandler.EventType.INTERNAL_ERROR) .cause(thrown) .request(request) .response(response) .message(thrown.getMessage()) .setKeepAlive(keepAlive) .build(); } } } return RoutingResult.NONE; } private enum RoutingResult { ROUTE, FINISH, NONE } / ** Fluent API builder for {io.webserver.http.HttpRouting} * / public static class Builder implements HttpRules, common.Builder<Builder, HttpRouting> { private final ServiceRules rootRules = new ServiceRules(); private Builder() { } @Override public HttpRouting build() { return new HttpRouting(this); } @Override public Builder route(HttpRoute route) { rootRules.route(route); return this; } @Override public Builder route(Http.Method method, String pathPattern, Handler handler) { return route(HttpRoute.builder() .methods(method) .path(pathPattern) .handler(handler)); } / ** * Add a get route. * @param pathPattern The path pattern * @param handler The handler to be used * @return The updated builder * / public Builder get(String pathPattern, Handler handler) { return route(HttpRoute.builder() .methods(Http.Method.GET) .path(pathPattern) .handler(handler)); } }

[0178] According to one embodiment, the abstraction of the HTTP service (HttpService) provides a logical grouping of routes that form a single unit, for example, as follows. / ** * Encapsulates a set of {HttpRouting routing} rules and related logic. * * Using the {HttpRouting.Builder#register(java.util.function.Supplier[])} method * An instance can be assigned to {HttpRouting routing}. * / @FunctionalInterface public interface HttpService { / ** * Updates the routing to add a handler for this service. * @param rules The rules to be updated * / void routing(HttpRules rules); }

[0179] According to one embodiment, the abstraction of an HTTP route (HttpRoute) provides a combination of a path expression, an HTTP method predicate, and a handler for processing matching requests, including a basic HTTP route (which should be usable by any HTTP protocol version), for example, as follows. public interface HttpRoute extends Route { / ** * A builder for building a new HTTP route. * @return The builder * / static HttpRouteImpl.Builder builder() { return new Builder(); } / ** * Whether this route accepts the provided request. * @param prologue The prologue of the request * @return The result of the validation * @see PathMatchers.MatchResult#notAccepted() * / PathMatchers.MatchResult accepts(HttpPrologue prologue); / ** * The handler for this route. * @return the handler * / Handler handler(); / ** * The Fluent API builder for {io.webserver.http.HttpRoute}. * / class Builder implements common.Builder<Builder, HttpRoute> { private Predicate<Http.Method> methodPredicate = Http.Method.predicate(); private PathMatcher pathMatcher = PathMatchers.any(); private Handler handler; private Builder() { } @Override public HttpRoute build() { Objects.requireNonNull(handler, "A handler must be provided"); return new HttpRouteImpl(this); } / ** * The HTTP methods this route should handle. * @param methods the methods to handle * @return The updated builder * / public Builder methods(Http.Method... methods) { return methods(Http.Method.predicate(methods)); } / ** * The method predicate to be used. * @param methodPredicate The method predicate * @return The updated builder * / public Builder methods(Predicate<Http.Method> methodPredicate) { this.methodPredicate = methodPredicate; return this; } / ** * The path pattern to be processed. * @param pathPattern The path pattern * @return The updated builder * / public Builder path(String pathPattern) { return this.path(PathMatchers.create(pathPattern)); } / ** * The path matcher for the path to be processed. * @param pathMatcher The path matcher * @return The updated builder * / public Builder path(PathMatcher pathMatcher) { this.pathMatcher = pathMatcher; return this; } / ** * Handler to be used. * @param handler The handler * @return The updated builder * / public Builder handler(Handler handler) { this.handler = handler; return this; } Predicate<Http.Method> methodPredicate() { return methodPredicate; } PathMatcher pathPredicate() { return pathMatcher; } Handler handler() { return handler; } } }

[0180] According to one embodiment, the system can support multiple implementations, such as an HTTP / 1 specific route implementation (Http1Route), as follows. / ** * Creates an HTTP / 1 specific route. * @param method The accepted method * @param path The path pattern * @param handler The handler * @return A new HTTP / 1.1 specific route * / public static Http1Route route(Http.Method method, String path, Handler handler) { return new Http1Route(Http.Method.predicate(method), PathMatchers.create(path), handler); } @Override public PathMatchers.MatchResult accepts(HttpPrologue prologue) { if (!prologue.protocolVersion().equals("1.1")) { return PathMatchers.MatchResult.notAccepted(); } if (!methodPredicate.test(prologue.method())) { return PathMatchers.MatchResult.notAccepted(); } return pathMatcher.match(prologue.uriPath()); } @Override public Handler handler() { return handler; } @Override public void beforeStart() { handler.beforeStart(); } @Override public void afterStop() { handler.afterStop(); } }

[0181] Similarly, according to one embodiment, the system can support an HTTP / 2 specific route implementation (Http2Route), for example, as follows. / ** * Creates a new route specific to HTTP / 2 only. * @param method The method to be processed * @param path The path pattern * @param handler The handler * @return The new route * / public static Http2Route route(Http.Method method, String path, Handler handler) { return new Http2Route(Http.Method.predicate(method), PathMatchers.create(path), handler); } @Override public PathMatchers.MatchResult accepts(HttpPrologue prologue) { if (!prologue.protocolVersion().equals("2.0")) { return PathMatchers.MatchResult.notAccepted(); } if (!methodPredicate.test(prologue.method())) { return PathMatchers.MatchResult.notAccepted(); } return pathMatcher.match(prologue.uriPath()); } @Override public Handler handler() { return handler; } @Override public void beforeStart() { handler.beforeStart(); } @Override public void afterStop() { handler.afterStop(); } }

[0182] According to one embodiment, a WebSocket routing implementation (WebSocketRouting) that provides WebSocket-specific routing can be provided, for example, as follows. public class WebSocketRouting implements Routing { private final List <websocket>routes; private WebSocketRouting(Builder builder) { this.routes = new ArrayList<>(builder.routes); } / ** * Builder for WebSocket routing. * @return A new builder * / public static Builder builder() { return new Builder(); } WebSocket findRoute(HttpPrologue prologue) { for (WebSocket route : routes) { PathMatchers.MatchResult accepts = route.accepts(prologue); if (accepts.accepted()) { return route; } } return null; } / ** * Fluent API builder for {websocket.webserver.WebSocketRouting}. * / public static class Builder implements common.Builder<Builder, WebSocketRouting> { private final List <websocket>routes = new ArrayList<>(); private Builder() { } @Override public WebSocketRouting build() { return new WebSocketRouting(this); } / ** * Add an endpoint. * @param path The path of the endpoint * @param listener The listener to be used * @return The updated builder * / public Builder endpoint(String path, WsListener listener) { return route(WebSocket.create(path, listener)); } / ** * Add an endpoint * @param path The path of the endpoint * @param listener The listener supplier * @return The updated builder * / public Builder endpoint(String path, Supplier <wslistener>listener) { return route(WebSocket.create(path, listener)); } private Builder route(WebSocket wsRoute) { routes.add(wsRoute); return this; } } }

[0183] According to one embodiment, the above uses the WsListener (WsListener) class to configure a WebSocket endpoint, for example, as follows. public interface WsListener { / ** * Receive a text fragment. * @param session WebSocket session * @param text Received text * @param last is this last fragment * / void onMessage(WsSession session, String text, boolean last; / ** * Receive a binary fragment. * @param session WebSocket session * @param buffer Buffer containing data * @param last is this last fragment * / void onMessage(WsSession session, BufferData buffer, boolean last; / ** * Received a ping. * @param session WebSocket session * @param buffer Buffer containing data * / void onPing(WsSession session, BufferData buffer); / ** * Received a pong. * @param session WebSocket session * @param buffer Buffer containing data * / void onPong(WsSession session, BufferData buffer); / ** * Received a close. * @param session WebSocket session * @param status Close status * @param reason Reason for the close * / void onClose(WsSession session, int status, String reason); / ** * An error occurred. * @param session WebSocket session * @param t Caught throwable * / void onError(WsSession session, Throwable t); / ** * The session is open. * @param session WebSocket session * / void onOpen(WsSession session); }

[0184] According to one embodiment, a gRPC routing implementation (GrpcRouting) that provides gRPC-specific routing can be provided, for example, as follows. public class GrpcRouting implements Routing { private final ArrayList <grpcroute>routes; private GrpcRouting(Builder builder) { this.routes = new ArrayList<>(builder.routes); } / ** * New routing builder. * @return New builder * / public static Builder builder() { return new Builder(); } Grpc<?,?> findRoute(HttpPrologue prologue) { for (GrpcRoute route : routes) { PathMatchers.MatchResult accepts = route.accepts(prologue); if (accepts.accepted()) { return route.toGrpc(prologue); } } return null; } / ** * Fluent API builder for {GrpcRouting}. * / public static class Builder implements common.Builder<Builder, GrpcRouting> { private final List <grpcroute>routes = new LinkedList<>(); private Builder() { } @Override public GrpcRouting build() { return new GrpcRouting(this); } / ** * Configure the gRPC service. * @param service The service to be added * @return The updated builder * / public Builder service(GrpcService service) { return route(GrpcServiceRoute.create(service)); } / ** * A single route. * @param proto The proto descriptor * @param serviceName The service name * @param methodName The method name * @param method The method to handle this route * @param <reqt>Claim type * @param <rest>Response Type * @return The updated builder * / public <ReqT, ResT> Builder unary(Descriptors.FileDescriptor proto, String serviceName, String methodName, ServerCalls.UnaryMethod<ReqT, ResT> method) { return route(Grpc.unary(proto, serviceName, methodName, method)); } / ** * Bi-directional route. * @param proto proto descriptor * @param serviceName Service name * @param methodName Method name * @param method The method to process this route * @param <reqt>Requirement type * @param <rest>Response Type * @return The updated builder * / public <ReqT, ResT> Builder bidi(Descriptors.FileDescriptor proto, String serviceName, String methodName, ServerCalls.BidiStreamingMethod<ReqT, ResT> method) { return route(Grpc.bidi(proto, serviceName, methodName, method)); } / ** * Server streaming route. * @param proto proto descriptor * @param serviceName Service name * @param methodName Method name * @param method The method to process this route * @param <reqt>Claim type * @param <rest>Response Type * @return The updated builder * / public <ReqT, ResT> Builder serverStream(Descriptors.FileDescriptor proto, String serviceName, String methodName, ServerCalls.ServerStreamingMethod<ReqT, ResT> method) { return route(Grpc.serverStream(proto, serviceName, methodName, method)); } / ** * Client streaming route. * @param proto proto descriptor * @param serviceName Service name * @param methodName Method name * @param method The method to process this route * @param <reqt>Request type * @param <rest>Response type * @return The updated builder * / public <ReqT, ResT> Builder clientStream(Descriptors.FileDescriptor proto, String serviceName, String methodName, ServerCalls.ClientStreamingMethod<ReqT, ResT> method) { return route(Grpc.clientStream(proto, serviceName, methodName, method)); } private Builder route(GrpcRoute route) { routes.add(route); return this; } } }

[0185] According to one embodiment, a gRPC service (GrpcService) can be provided as a single gRPC service backed by a single proto file, for example, as follows. public interface GrpcService { / ** * The proto descriptor of this service. * @return The proto file descriptor * / Descriptors.FileDescriptor proto(); / ** * The service name, by default the simple name of this class. * @return The service name * / default String serviceName() { return getClass().getSimpleName(); } / ** * Update the routing. * @param routing The routing * / void update(Routing routing); / ** * Service-specific routing (the proto descriptor is provided by {GrpcService#proto()}). * / interface Routing { / ** * Unary route. * @param methodName The method name * @param method The method to handle the route * @param <reqt>Claim type * @param <rest>Response Type * @return Updated routing * / <ReqT, ResT> Routing unary(String methodName, ServerCalls.UnaryMethod<ReqT, ResT> method); / ** * Bidirectional route. * @param methodName Method name * @param method Method to process the route * @param <reqt>Claim type * @param <rest>Response type * @return Updated routing * / <ReqT, ResT> Routing bidi(String methodName, ServerCalls.BidiStreamingMethod<ReqT, ResT> method); / ** * Server streaming route. * @param methodName Method name * @param method Method to handle the route * @param <reqt>Claim type * @param <rest>Response type * @return The updated routing * / <ReqT, ResT> Routing serverStream(String methodName, ServerCalls.ServerStreamingMethod<ReqT, ResT> method); / ** * Client streaming route. * @param methodName The method name * @param method The method to process the route * @param <reqt>Claim type * @param <rest>Response type * @return Updated routing * / <ReqT, ResT> Routing clientStream(String methodName, ServerCalls.ClientStreamingMethod<ReqT, ResT> method); } }

[0186] The above examples are provided for illustrative purposes, and according to various embodiments, other examples of interfaces, classes, or methods can be provided.

[0187] FIG. 23 shows a method used in a microservices environment to provide an abstraction of a router, according to one embodiment.

[0188] As shown in FIG. 23, according to one embodiment, at step 390, in a computer including one or more processors and memory, a microservices environment (e.g., as provided by a microservices library) is provided that enables a client application and a server application to communicate within the microservices environment.

[0189] At step 392, the system provides a router abstraction component or functionality that includes a router and routing abstraction to enable configuration of the server code by adding a library on the classpath to add new routing to the server, e.g., as used in HTTP request routing.

[0190] At step 394, when setting up the server, the server can register the routing with its builder, the routing includes protocol-specific methods that enable configuration of its protocol, and the router supports multiple protocols associated with the router.

[0191] In step 396, the server configured to operate as such receives and processes requests from clients using the protocol configured and supported by the server.

[0192] Interface Example According to one embodiment, for the purpose of illustration, an example interface for providing an abstraction of a router is provided below. According to other embodiments, other types of interfaces can be provided.

[0193] Interface Router According to one embodiment, the Router interface can be used to provide various types of routing so that the server can quickly process each protocol, and can include various methods, for example, as follows.

[0194] Method static Router.Builder builder(). Builder for the router. In one embodiment, this method returns a new builder.

[0195] Method static Router empty(). Empty router. In one embodiment, this method returns a new empty router.

[0196] Method routing <T extends Routing> T routing(Class <t>routingType, T defaultValue). Obtains a specific type of routing. Examples of the Type parameter that can be provided include, for example, the type of T-routing. Examples of the parameters that can be provided include, for example, routingType - the type of that routing, defaultValue - the default value to be used if that routing is not defined in this router. In one embodiment, this method returns the defined routing or the default value if not found.

[0197] D. Identification of the Connection Protocol In a cloud environment that supports client-server communication via different communication protocols, each communication protocol may have its own requirements regarding the formatting of messages passed between participants, including message headers.

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

[0199] According to one embodiment, to support functions such as abstraction of client / server connections, abstraction of routers, or use of different protocols on a single socket, an extensible Service Provider Interface (SPI) provides software methods that enable protocol identification of request messages and connections.

[0200] When a connection request message from a client to a server is received, a determination is made as to whether the request can be properly processed. The protocol identification process can return an indication, for example, that the system does not support the request protocol, that the system does not have sufficient data to make a determination, or that additional data is required to make such a determination.

[0201] For example, in some systems, when a server receives a connection request, it may not be able to know the type of connection being requested. As described herein, this approach can have a single server socket that can handle different types of connections. Typically, different sockets must be used for incompatible connection types. In HTTP / 2, some servers may only support upgrades from HTTP / 1, or may map requests for prior knowledge to some special HTTP / 1 request.

[0202] With the approach described, the server can be called with any supported protocol, and the server automatically determines whether it can accept it.

[0203] FIG. 24 shows support for identifying the protocol of a connection according to one embodiment.

[0204] As shown in FIG. 24, according to one embodiment, an extensible service provider interface (SPI) 402 provides software methods that enable request messages and protocol identification of connections to support functions such as abstraction of client / server connections, abstraction of routers, or use of different protocols on a single socket.

[0205] According to one embodiment, a builder can provide protocol support for a first protocol A412 and a second protocol B414 within the server code.

[0206] When a connection request message directed from a client to a server is received, a determination is made as to whether the request can be properly processed. The protocol identification process can return an indication, for example, that the system is not porting the requested protocol, that the system does not have sufficient data to make a determination, or that additional data is required to make such a determination.

[0207] Figure 25 further shows support for identifying the protocol of a connection according to one embodiment.

[0208] As shown in Figure 25, according to one embodiment, an extensible Service Provider Interface (SPI) 402 can identify request messages and the protocol for a connection by having, for example, a first connection provider 404 associated with a first protocol A, a second connection provider 406 associated with a second protocol B, and a third connection provider 408 associated with a third or other protocol N that may not currently be supported by the server.

[0209] Figure 26 further shows support for identifying the protocol of a connection according to one embodiment.

[0210] As shown in Figure 26, according to one embodiment, a request A370 for a connection using a first protocol A372 and a request B380 for a connection using a second protocol B382 can be processed by appropriate server code.

[0211] Figure 27 further shows support for identifying the protocol of a connection according to one embodiment.

[0212] As shown in Figure 27, according to one embodiment, a request X410 for a connection using an unknown other protocol X412 is determined not to be supported by the server, and the SPI can determine whether to accept the connection request and process it in some way or not accept the connection request.

[0213] According to one embodiment, the system can identify the type using an extensible mechanism to correctly process an incoming connection. The SPI can use the first byte of the incoming connection to identify what type of connection it is (such as HTTP / 1, known HTTP / 2, etc.). This mechanism attempts identification using an initial amount of bytes (configurable per protocol handler). If identification fails, the connection is not accepted.

[0214] Service Provider Interface Example According to one embodiment, an SPI implementation with an HTTP / 1.1 connection provider uses bytes up to the first CRLF sequence, attempts to parse it, and if that sequence forms a valid HTTP / 1.1 prologue (such as GET / path HTTP / 1.1), it is accepted as an HTTP / 1.1 request.

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

[0216] This approach is extensible and other connection providers can plug into this mechanism to provide support for other protocols.

[0217] According to one embodiment, the SPI and API can be provided as a ServerConnectionProvider and can provide various interfaces, classes, or methods, for example, as follows.

[0218] Method int bytesToIdentifyConnection() - The number of bytes required (which may be 0 to identify "unknown").

[0219] Method Support supports(BufferData data) - BufferData is an abstraction of the initial bytes of the connection. Support defines whether this is a valid request for this provider, whether additional data is needed to identify if this is a valid request for this provider, or whether this is an invalid request for this provider.

[0220] Method ServerConnection connection(ConnectionContext) - Creates a server connection for the connection accepted by this provider, and context provides access to the reader and writer.

[0221] Method SupportedApplicationProtocols() used in protocol negotiation when using TLS.

[0222] According to one embodiment, for example, as follows, a java.util.ServiceLoader provider interface for a server connection provider can be provided, giving the connection provider the opportunity to analyze the request bytes and determine whether this is a connection it can accept. public interface ServerConnectionProvider { / ** * The number of bytes required to identify this connection. * @return The number of bytes required, return 0 if this is not a fixed value * / int bytesToIdentifyConnection(); / ** * Does this provider support the current server connection? * The same buffer is sent to {ServerConnection#handle()} * @param (There are at least {#bytesToIdentifyConnection()} available bytes) * Data byte * @return Support response * / Support supports(BufferData data); / ** * Application protocols supported by this provider, for example for ALPN negotiation. * * @return Set of supported protocols * / Set <string>supportedApplicationProtocols(); / ** * Create a new connection. * All methods are called from a single virtual thread. * @param ctx The connection context from which the data writer, * data reader and other useful information can be accessed * @return A new server connection * / ServerConnection connection(ConnectionContext ctx); / ** * Support by this provider. * / enum Support { / ** * Yes, this is a connection that this provider can handle. * / SUPPORTED, / ** * No, this connection is not compatible with this provider. * / UNSUPPORTED, / ** * There are not enough bytes to determine, so request this * provider to provide more bytes again. * / UNKNOWN } }

[0223] According to one embodiment, an SPI (ServerConnection) for server connection can be provided. This SPI can be created by a ServerConnectionProvider. For example, as an abstraction of server connection, it has a single method handle() that is expected to block until the connection is closed and can be used by any provider to handle socket connections, for example, as follows. public interface ServerConnection { / ** * Starts the processing of the connection. Data is provided via {ServerConnectionProvider#connection(webserver.ConnectionContext)}. * @throws InterruptedException to interrupt any waiting state and end this connection * / void handle() throws InterruptedException; }

[0224] According to one embodiment, as follows, an HTTP / 1 server connection provider (Http1ConnectionProvider) can be provided, for example, as a provider implementation of (java.util.ServiceLoader) for an HTTP / 1.1 server connection provider. public class Http1ConnectionProvider implements ServerConnectionProvider { private static final String PROTOCOL = " HTTP / 1.1\r"; private final int maxPrologueLength; private final int maxHeadersSize; private final boolean validateHeaders; private final boolean validatePath; private final Map<String, Http1UpgradeProvider> upgradeProviderMap; / ** * Creates a new instance with default configuration. * @deprecated Should only be used by {java.util.ServiceLoader} * / @Deprecated public Http1ConnectionProvider() { this(builder()); } private Http1ConnectionProvider(Builder builder) { this.maxPrologueLength = builder.maxPrologueLength; this.maxHeadersSize = builder.maxHeaderSize; this.validateHeaders = builder.validateHeaders; this.validatePath = builder.validatePath; this.upgradeProviderMap = builder.upgradeProviders(); } / ** * The builder with which this provider should be set up. * @return A new builder * / public static Builder builder() { return new Builder(); } @Override public int bytesToIdentifyConnection() { / / The requirement is that the line must start with a line ending with \r\n, and / / the length is unknown return 0; } @Override public Support supports(BufferData request) { / / Find the first \n, and if \r precedes it, try if it's ours / / Otherwise, it's not supported / ** > GET / loom / slow HTTP / 1.1 > Host: localhost:8080 > User-Agent: curl / 7.54.0 > Accept: * / * * / int lf = request.indexOf(Bytes.LF_BYTE); if (lf == -1) { / / If the maximum prologue length is reached, consider this to be HTTP / 1.1 only, so an appropriate error can be sent. That is, maxPrologueLength must always be higher than any protocol requirements for identifying the connection (e.g., this is a fallback protocol) return (request.available() <= maxPrologueLength)? Support.SUPPORTED : Support.UNSUPPORTED; } else { return request.readString(lf).endsWith(PROTOCOL)? Support.SUPPORTED : Support.UNSUPPORTED; } } @Override public Set <string>supportedApplicationProtocols() { return Set.of("http / 1.1"); } @Override public ServerConnection connection(ConnectionContext ctx) { return new Http1Connection(ctx, maxPrologueLength, maxHeadersSize, validateHeaders, validatePath, upgradeProviderMap); } / ** * Fluent API builder for {io.webserver.http1.Http1ConnectionProvider}. * / public static class Builder implements common.Builder<Builder, Http1ConnectionProvider> { private final HelidonServiceLoader.Builder <http1upgradeprovider> upgradeProviders = HelidonServiceLoader.builder(ServiceLoader.load(Http1UpgradeProvider.class) ); private int maxPrologueLength = DEFAULT_MAX_PROLOGUE_LENGTH; private int maxHeaderSize = DEFAULT_MAX_HEADERS_SIZE; private boolean validateHeaders = DEFAULT_VALIDATE_HEADERS; private boolean validatePath = DEFAULT_VALIDATE_PATH; private Builder() { } @Override public Http1ConnectionProvider build() { return new Http1ConnectionProvider(this); } / ** * The maximum size of the received HTTP prologue (GET / path HTTP / 1.1). * @param maxPrologueLength The maximum size in bytes * @return The updated builder * / public Builder maxPrologueLength(int maxPrologueLength) { this.maxPrologueLength = maxPrologueLength; return this; } / ** * Maximum size of the receive header in bytes. * @param maxHeadersSize Maximum header size * @return Updated builder * / public Builder maxHeadersSize(int maxHeadersSize) { this.maxHeaderSize = maxHeadersSize; return this; } / ** * Whether headers should be validated. * If set to false, any value is accepted, * otherwise headers are validated and known headers are * validated by format (content length is always * validated as part of protocol processing (other headers * may be validated if the functionality uses them)). * @param validateHeaders Whether headers should be validated * @return Updated builder * / public Builder validateHeaders(boolean validateHeaders) { this.validateHeaders = validateHeaders; return this; } / ** * If set to false, any path is accepted * (including invalid characters). * @param validatePath Whether the path should be validated * @return Updated builder * / public Builder validatePath(boolean validatePath) { this.validatePath = validatePath; return this; } / ** * Add the configured upgrade provider. This will * replace the instance (if any) discovered through the service loader. * @param provider The provider to add * @return The updated builder * / * / public Builder addUpgradeProvider(Http1UpgradeProvider provider) { upgradeProviders.addService(provider); return this; } } }

[0225] According to one embodiment, an HTTP / 2 server connection provider (Http2ConnectionProvider) can be provided to support "prior knowledge" requests, for example, as follows. / ** * {java.util.ServiceLoader} provider implementation for HTTP2 server connection provider * / public class Http2ConnectionProvider implements ServerConnectionProvider { @Override public int bytesToIdentifyConnection() { return PREFACE_LENGTH; } @Override public Support supports(BufferData request) { byte[] prefaceBytes = new byte[PREFACE_LENGTH]; request.read(prefaceBytes, 0, PREFACE_LENGTH); / / Now, we can ask the protocol handler to identify this protocol / / as required if (isPreface(prefaceBytes)) { / / This is HTTP2 pre - knowledge return Support.SUPPORTED; } return Support.UNSUPPORTED; } @Override public Set <string>supportedApplicationProtocols() { return Set.of("h2"); } @Override public ServerConnection connection(ConnectionContext ctx) { Http2Connection result = new Http2Connection(ctx); result.expectPreface(); return result; } }

[0226] The above example is provided for illustrative purposes, and according to various embodiments, other examples of interfaces, classes, or methods can be provided.

[0227] FIG. 28 shows, according to one embodiment, a method used in a microservices environment for identifying the protocol of a connection.

[0228] As shown in FIG. 28, according to one embodiment, at step 420, in a computer including one or more processors and memory, a microservices environment (e.g., as provided by a microservices library) is provided that enables a client application and a server application to communicate within the microservices environment.

[0229] At step 422, the system provides a connection protocol identification component or functionality that includes an extensible connection provider service provider interface (SPI) for supporting multiple protocols supported by server code, e.g., as used in HTTP request routing.

[0230] In step 424, the connection provider SPI provides a plurality of connection provider types, and each of the connection provider types is associated with a supported protocol.

[0231] In step 426, when a request directed to the server via an incoming connection is received, the system can 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, alternatively, reject it as not being supported.

[0232] Interface example According to one embodiment, for purposes of illustration, an interface example for identifying the protocol of a connection is provided below. According to other embodiments, other types of interfaces can be provided.

[0233] Interface ServerConnectionProvider According to one embodiment, the ServerConnectionProvider interface can be used to provide an interface for a server connection provider, and the connection provider is given the opportunity to analyze the request bytes and determine whether this is a connection that it can accept and can include various methods such as the following.

[0234] Method int bytesToIdentifyConnection(). The number of bytes required to identify this connection. In one embodiment, this method returns the number of bytes required and returns 0 if this is not a fixed value.

[0235] The method ServerConnectionProvider.Support supports(common.buffers.BufferData data). Whether this provider currently supports the server connection. The same buffer is sent to ServerConnection.handle(). Parameters that can be provided include, for example, data - bytes (including at least the bytes available for bytesToIdentifyConnection()). In one embodiment, this method returns a support response.

[0236] Method Set <string>supportedApplicationProtocols(). For example, the application protocols supported by this provider for use in ALPN negotiation. In one embodiment, this method returns a set of supported protocols.

[0237] The method ServerConnection connection(ConnectionContext ctx). Creates a new connection. All methods are called from a single virtual thread. Parameters that can be provided include, for example, ctx - a connection context that can access the data writer, data reader, and other useful information. In one embodiment, this method returns a new server connection.

[0238] According to various embodiments, aspects of the present disclosure are described in the following numbered clauses.

[0239] 1. A system for use in a microservice or other computing environment, comprising one or more processors and a computer for providing access to a microservice or other computing environment for use with a software application or service, the system providing an abstraction via a header enumeration that enables message headers to be treated as objects, the header enumeration supporting a plurality of communication protocols and being accessible via an application program interface that enables a client and a server to communicate request messages and response messages using any of several supported protocols.

[0240] 2. The system of clause 1, wherein when encountering a request message having a known header type, the system can, if available, obtain an indexed value from the above enumeration, directly provide the associated data to the process to which the request is directed, and / or cache the value of the header for later use.

[0241] 3. A method used in 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 that enables an object to be treated as accessible via an application program interface that, by means of a header enumeration, enables a message header to support multiple communication protocols and enables a client and a server to communicate request / response messages using any of the supported protocols.

[0242] 4. The method according to clause 3, wherein when a request message having a known header type is encountered, the system, if available, obtains an indexed value from the above enumeration, directly provides the associated data to the process to which the request is directed, and / or can cache the value of the header for later use.

[0243] 5. A system used in a microservice or other computing environment, comprising one or more processors and a computer for providing access to a microservice or other computing environment for use with a software application or service, wherein during testing of the 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, and data written to the data writer of the client connection is made available through the data reader in the server connection, and data written to the data writer of the server connection is made available through the data reader in the client connection.

[0244] 6. The system according to clause 5, wherein the in-memory implementation uses a blocking queue in memory, emulates the use of a network communication protocol without using an actual socket, the test is complete, and the client and / or server code can be executed against an actual socket.

[0245] 7. A method used in 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 emulates the use of a network communication protocol and exposes an inverse function to a server connection, wherein data written to a data writer of the client connection becomes available through a data reader in the server connection, and data written to a data writer of the server connection becomes available through a data reader in the client connection.

[0246] 8. The method according to clause 7, wherein the in-memory implementation uses a blocking queue in memory, emulates the use of a network communication protocol without using an actual socket, the test is complete, and the client and / or server code can be executed against an actual socket.

[0247] 9. A system used in a microservice or other computing environment, comprising one or more processors, a computer for providing access to a microservice or other computing environment used with a software application or service, the system enabling a configuration of a server that can operate to respond to requests via a plurality of network protocols or communication protocols, providing a route abstraction that associates each network protocol or communication protocol supported by the server with the routing of the network protocol or communication protocol itself, and the route abstraction can include one or more specific routes used in a specific network protocol or communication protocol.

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

[0249] 11. A method used in a microservice or other computing environment, including providing a microservice or other computing environment used with a software application or service, the system enabling a configuration of a server that can operate to respond to requests via a plurality of network protocols or communication protocols, providing a route abstraction that associates each network protocol or communication protocol supported by the server with the routing of the network protocol or communication protocol itself, and the route abstraction can include one or more specific routes used in a specific network protocol or communication protocol.

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

[0251] 13. A system used in a microservice or other computing environment, comprising one or more processors, a computer that provides access to a microservice or other computing environment used with a software application or service, and an extensible service provider interface that provides a software method for identifying 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 abstraction of the client-server connection, abstraction of the router, or support for the use of multiple network communication protocols on a single socket.

[0252] 14. The system according to item 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 processed using the provided network communication protocol, and the protocol identification process returns an indication that the system does not support the requested network communication protocol, or that the system currently does not have sufficient data to make a determination, or that additional data is required to make such a determination.

[0253] 15. A method used in 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 that enables identification of network communication protocols associated with request messages and client-server connections, wherein the identification of the network communication protocol is used to provide one or more of abstraction of client-server connections, abstraction of routers, and use of multiple network communication protocols on a single socket.

[0254] 16. The method according to 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 processed using the provided network communication protocol, and the protocol identification process returns an indication that the system does not support the requested network communication protocol, or that the system does not currently have sufficient data to make a determination, or that additional data is required to make such a determination.

[0255] 17. The system or method according to any of the preceding numbered clauses, wherein the system or method is provided to be part of a web server or used with a web server, and the request is an HTTP request.

[0256] 18. The system or method according to any of the preceding numbered clauses, wherein the system or method includes a request processing component that uses virtual threads along with associated libraries and functions that can be used to build cloud-native services.

[0257] 19. A system or method as described by any of the numbered clauses above, 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.

[0258] According to various embodiments, the teachings herein can be implemented using one or more computers, computing devices, machines, or microprocessors that include one or more processors, memories, and / or computer-readable storage media programmed in accordance with the teachings herein. As will be apparent to those skilled in the art of software, a skilled programmer can readily create appropriate software coding based on the teachings of this disclosure.

[0259] In some embodiments, the teachings herein can include a computer program product that is a non-transitory computer-readable storage medium (media) storing instructions that can be used to program a computer to execute any of the processes of this teaching. Examples of such storage media include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory devices, or other types of storage media or devices suitable for non-transitory storage of instructions and / or data.

[0260] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the exact forms disclosed. Further modifications and variations will be apparent to those skilled in the art.

[0261] For example, while various embodiments of the systems and methods described herein are shown for use in a Helidon microservices environment, the various embodiments can be used with other types of microservices environments or other computing environments.

[0262] The embodiments are chosen and described in order to best explain the principles of the teachings herein and their practical application, thereby enabling others skilled in the art to understand the various embodiments with various modifications as are suited to the particular use contemplated. Its scope is intended to be defined by the following claims and their equivalents.< / string> < / string> < / string> < / string> < / t> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / rest> < / reqt> < / grpcroute> < / grpcroute> < / wslistener> < / websocket> < / websocket> < / t> < / t> < / t> < / string> < / string> < / string>

Claims

1. A system for use in a microservice or other computing environment, comprising: a computer including one or more processors, the computer providing access to the microservice or other computing environment for use with a software application or service; The system provides a software method for enabling identification of a network communication protocol associated with a request message; The system, wherein the 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 using multiple network communication protocols over a socket.

2. 10. The system of claim 1, wherein the system provides an abstraction that allows message headers to be treated as objects via header enumerations, the header enumerations supporting multiple communication protocols and accessible via an application program interface that allows clients and servers to communicate request and response messages using any of several supported protocols.

3. 3. The system of claim 2, wherein when a request message having a known header type is encountered, the system retrieves an indexed value from the enumeration, if available, and can provide associated data directly to the process to which the request is directed and / or cache the header value for later use.

4. During testing of a software application or service, client connections are replaced with in-memory implementations that emulate the use of network communication protocols and expose inverse functions to server connections; data written to a data writer on the client connection is made available through a data reader on the server connection; and 2. The system of claim 1, wherein data written to a data writer in the server connection is made available through a data reader in the client connection.

5. 5. The system of claim 4, wherein the in-memory implementation uses a blocking queue in memory to emulate the use of the network communication protocol without using actual sockets, and wherein the testing is complete and the client and / or server code can run against actual sockets.

6. the system allows for the configuration of a server operable to serve requests over multiple network or communication protocols; a route abstraction is provided that associates each network or communication protocol supported by the server with the routing of the network or communication protocol itself; and The system of claim 1 , wherein the route abstraction can include one or more specific routes used in a particular network or communication protocol.

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

8. an extensible service provider interface that provides software methods that enable identification of a request message and a network communication protocol associated with the client-server connection; 8. The system of claim 1, 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 the use of multiple network communication protocols on a single socket.

9. 10. The system of 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 processed using a provided network communications protocol, and a protocol identification process returns an indication that the system does not support the requested network communications protocol, or that the system does not currently have sufficient data to make a 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 for use in conjunction with a web server, and the request is an HTTP request.

11. The system of claim 1 , wherein the system includes a request processing component that uses virtual threads along with associated libraries and functions that can be used to build cloud-native services.

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

13. 1. A method for use in a microservice or other computing environment, comprising: Providing microservices or other computing environments for use with software applications or services; providing a software method that enables identification of a network communication protocol associated with the request message; The method, wherein the 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. 14. The method of claim 13, wherein the system further includes providing an abstraction that allows message headers to be treated as objects via header enumerations, the header enumerations supporting multiple communication protocols and accessible via an application program interface that allows clients and servers to communicate request and response messages using any of several supported protocols.

15. 15. The method of claim 14, wherein when a request message with a known header type is encountered, the system retrieves an indexed value from the enumeration, if available, and can provide associated data directly to the process to which the request is directed and / or cache the header value for later use.

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

17. 17. The method of claim 16, wherein the in-memory implementation uses a blocking queue in memory to emulate the use of the network communication protocol without using actual sockets, and wherein the testing is complete and the client and / or server code can run against actual sockets.

18. Executed by a system that enables configuration of a server that can operate to serve requests over multiple network or communication protocols, a route abstraction is provided that associates each network or communication protocol supported by the server with the routing of the network or communication protocol itself; and The method of claim 13 , wherein the route abstraction can include one or more specific routes used in a particular network or communication protocol.

19. 20. The method of claim 18, wherein for a request message received via a particular protocol, the system can select an appropriate route for the request and process the request according to the route abstraction.

20. providing an extensible service provider interface that provides software methods that enable identification of a request message and a network communication protocol associated with a client-server connection; 14. The method of claim 13, wherein the identification of the network communication protocol is used to provide one or more of a client-server connection abstraction, a router abstraction, and the use of multiple network communication protocols on a single socket.

21. 21. The method of claim 20, 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 processed using a provided network communications protocol, and a protocol identification process is performed by the system that returns an indication that the system does not support the requested network communications protocol, or that the system does not currently have sufficient data to make a determination, or that additional data is required to make such a determination.

22. 14. The method of claim 13, wherein the method is provided as part of or for use in conjunction with a web server, and the request is an HTTP request.

23. 14. The method of claim 13, wherein the method operates on a request processing component that uses virtual threads along with associated libraries and functions 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 program for causing a computer to execute the method described in any one of claims 13 to 24.

Images