WO2020061853A1

WO2020061853A1 - Web-architecture based on client-controlled cap configuration

Info

Publication number: WO2020061853A1
Application number: PCT/CN2018/107735
Authority: WO
Inventors: Daniel BOVENSIEPEN
Original assignee: Siemens Aktiengesellschaft
Priority date: 2018-09-26
Filing date: 2018-09-26
Publication date: 2020-04-02

Abstract

A method is disclosed. A method for information processing at a client device in a distributed network comprises: generating, based on a reference address, a set of server addresses associated with a set of servers; determining, based on an operational configuration, a subset of server addresses associated with a subset of servers from the set of server addresses; communicating, based on the subset of server addresses, a request message to the subset of servers; and determining, based on the operational configuration, a valid input in at least one response received from the subset of servers.

Description

Web-Architecture based on client-controlled CAP configuration

BACKGROUND

Web-based Architectures and Technologies are often adopted these days. For most of the web-based technologies, they do not belong to a single company and are open and license free standards. Anybody can join and leave the web and add new applications to it, and the underlying principles of the web-based technologies are simple to understand even for non-experts.

Due to the vast amount of people and companies applying these technologies, the development pace is enormous fast. Based on this fast pace the need for continuous change is extremely important in the field of web-based systems (e.g. cloud platforms) . Compared to other systems which might have update cycles of years, web-based systems have usually update cycles of weeks.

SUMARY

In response to the complexity of current CAP settings, the present invention proposes a method of implementing CAP configuration on the client side to provide a flexible mechanism for choosing a preferred trade-off.

According to a first aspect of the invention, a method for information processing at a client device in a distributed network comprises: generating, based on a reference address, a set of server addresses associated with a set of servers; determining, based on an operational configuration, a subset of server addresses associated with a subset of servers from the set of server addresses; communicating, based on the subset of server addresses, a request message to the subset of servers; and determining, based on the operational configuration, a valid input in at least one response received from the subset of servers. Based on the above arrangement, the client device can flexibly choose a subset of servers to communicate based on the operational configuration.

In an embodiment, the operational configuration is implemented to determine the priority of consistency guarantee and availability guarantee. Operational configuration is defined in this embodiment.

In an embodiment, the method further comprises determining a first response received from the subset of servers as the valid input when the availability guarantee is prioritized. Thus, the client device may perceive the lowest possible latency from a subset of available servers, and perceive no down-time as long as at least one out of n servers is available.

In an embodiment, determining a response, based on a predetermined confidence level, from a plurality of responses received from the subset of servers as the valid input when the consistency guarantee is prioritized. Thus, the client device may obtain data with a predetermined confidence level, and may choose more than two modular redundancy to reach a certain confidence level even if data is partitioned and not in sync.

In an embodiment, the set of server addresses associated with a set of servers are obtained by expanding the reference address based on a communication protocol. Thus, an exhaustive server-list can be created based on standard-based protocol resolution techniques without inventing a new incompatible scheme.

In an embodiment, the communication protocol includes at least one of TCP/IP protocol, IPX/SPX protocol and NetBEUI protocol, which describes the scope of the invention can be applied.

In an embodiment, the subset of server addresses are at least partially identical to the set of server addresses, which means the number of subset of servers may be changed based on network condition or the client’s interest.

In an embodiment, data associated with the valid input is output in a predetermined form. Thus, the user can obtain his interest content.

According to a second aspect of the invention, an apparatus for information processing in a distributed network comprises: a first address unit configured to generate, based on a reference address, a set of server addresses associated with a set of servers; a second address unit configured to determine, based on an operational configuration, a subset of server addresses associated with a subset of servers from the set of server addresses; a communicating unit configured to communicate, based on the subset of server addresses, a request message to the subset of servers; and an output unit configured to determine, based on the operational configuration, a valid input in at least one response received from the subset of servers.

According to a third aspect of the invention, a tangible non-transitory computer-readable medium stores computer executable instructions, wherein when the executable instructions are executed, the methods described above can be implemented.

According to a fourth aspect of the invention, a computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer executable instructions, when the executable instructions are executed by the at least one processor, the at least one processor is caused to perform the method described above.

According to a fifth aspect of the invention, a computer program product tangibly stored on computer readable medium comprises computer executable instructions, when the computer program product is executed by a computer, at least one processor is caused to perform the method described above.

By applying the technical solution of present invention, an approach to handle redundancy in a web-based architecture on the client side is provided. CAP guarantees can be configured at the client side, which enables the possibility to use the same software system for different use-cases.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a schematic of a common web-architecture based system;

FIG. 2 depicts a scheme of a client-based redundant web-architecture according to an embodiment of the present invention;

FIG. 3 depicts a flowchart of an information processing method at client side according to an embodiment of the present invention;

FIG. 4 depicts a flowchart of implementing a client-based redundant web-architecture according to an embodiment of the present invention;

FIG. 5 depicts an architecture diagram of an information processing apparatus according to an embodiment of the present invention.

DETAILED DESCRIPTION

In the following description of examples, reference is made to the accompanying drawing in which it is shown by way of illustration specific examples that can be practiced. It is to be understood that other examples can be used and structural changes can be made without departing from the scope of the various examples.

Besides scheduled events (e.g. software-updates) , un-scheduled events (e.g. software-bugs, hardware-failures) also are a source of downtime for any kind of IT system (including web-based IT systems) . Due to the increased need for introducing new customer features and providing world-wide scalability, the amount of different hardware and software items, which are part of a single web-based IT system, is growing constantly. Due to this, the risk of hardware failures and software bugs is increasing.

Current web-based software-systems place all logic elements, which decide availability and consistency guarantees, on the server-side. Changing and selecting these guarantees are implemented on the server-side, which is mostly static and not use-definable. In other words, current web-architectures handle all availability, consistency and partition tolerance decisions on the server-side, which causes CAP priorities to be static. This leads to the question: In a dynamic environment like a web-based software-system, how can the provider and/or user of a web-based IT system make decisions about the availability and consistency at a late stage? For private individual users and industrial company users, they may need two separated systems, due to their different requirements.

This invention is to provide more freedom to the client, which means the client can freely select a subset of this server list based on a predetermined principle (e.g. CAP configuration) . Based on the client selection, different balancing schemas can be chosen.

FIG. 1 depicts a schematic of a common web-architecture based system.

In this architecture, the client device 101 sends a request message indicating a unique URL to a load-balancer 102 which is to implement specific algorithms for balancing server load. In other words, the load-balancer 102 would forward the request to an object server (e.g. an application server 1031 selected from application servers 1031, 1032) based on a specific algorithm (e.g. round-robin) . When server 1031 receives the request, it will apply a corresponding read/write scheme to distribute the load to a data-storage device 1041 selected from data-

storage devices

1041, 1042.

In this system, the quantity of the servers may be automatically scaled up and down for various requirement. For example, this architecture is implemented to ensure that the service operates normally if any individual server fails (or a small number of servers) . The architecture may reduce the impact caused by faulty servers. As long as there is still a sufficient number of servers running, all incoming user requests can be serviced. Obviously, in order to ensure the operation of the service, this network architecture requires a great number of servers, which is redundant and wasteful.

The load balancer 102 can be deployed in many ways, for example, using a reverse-proxy on a single server, however, a single point of failure at the reverse proxy may cause the system to stop working. An advanced way is to use a specific load-balance service which could deploy a more advanced redundancy scheme, including DNS fallbacks and multiple load-balancing hardware, but it is usually proprietary, complex and does not provide zero-downtime due to DNS entry propagation latency. The data-storages 1041 and 1402 maybe implemented with a relational database data-storage prioritizing consistency over availability that locks the application down to a low availability, or with a NOSQL data-storage prioritizing availability over consistency that locks the application down to a low consistency.

As discussed above, current solutions introduce complexity if they want to avoid a single point of failure; further, current solutions can’t avoid a potential high DNS propagation latency; still further, current solutions implement CAP configuration on the server side and do not allow the clients to flexible choose the preferred trade-off.

This invention intends to provide a flexible architecture to cope with limitation determined by CAP (Consistency, Availability and Partition tolerance) and provide an attractive and flexible way to choose a suitable combination of CAP guarantees even after a system is deployed and in operation. In this invention, the suitable combination of guarantees is determined/set on the client-side, and how CAP balancing is configured is up to the individual application using the invention.

FIG. 2 depicts a scheme of a client-based redundant web-architecture according to an embodiment of the present invention.

In this example, the client-based redundant web-architecture may include a client device 210 and a plurality of servers 221-223. The client device 210 is configured to choose manually or automatically a subset of a URL-list, and further configured to prioritize certain guarantees. The client device 210 may reach one or more servers via one or more addresses (IP/DNS Name) . The servers may provide flexible guarantees to the client device 210 such that the client device 210 may not be restricted. As an example, the servers may handle all the constraints to provide full-fill the guarantees. Due to the above configuration, the client device 210 may be taken in charge to make its own decisions about CAP configuration.

To illustrate the characteristics and the interplay of this architecture, two scenarios with two different priorities of guarantees are provided below.

Scenario A: Prioritize the Availability Guarantee

In this scenario, the client device 210 may access a web-page, but instead of addressing the resource via just one address, the client device may possess a list of addresses. Based on its demand to have a high availability, the client device 210 may send its request to N servers, wherein N can be adjustable automatically or manually based on the level of availability necessary. Each address might be addressing a different server at different locations, operated by different companies and/or even written in different programming languages.

Each of the N servers may receive a same request, and provide data independently. The client device 210 may receive n responses, in general, these responses may be identical, so the first one to reach the user can immediately be processed. Thus, the client device 210 may choose the first reply received from any server, and may not need to wait for all responses to arrive.

As a result of the above configuration for the client device, the client device 210 may perceive the lowest possible latency from a subset of available servers, and perceive no down-time as long as at least one out of n servers is available.

Scenario B: Prioritize the Consistency Guarantee

A server would provide the data independent from the knowledge which other servers were requested. The client device 210 may flexible select a subset of this server list. Based on the selection, different balancing schemas can be chosen. Understandably, the necessary logic for the data-backend could be provided, which is used to determine the sever list.

In this scenario, the client device 210 may receive n responses from which it may compare a subset m responses depending on a required confidence level. The client device 210 may choose a reply from the subset m responses based on a predetermined configuration (e.g. a predetermined confidence level) , which follows the principle of prioritizing consistency guarantee. For example, the client device 210 may compare two responses with each other, if both responses are correct, the confidence level is sufficient and the dataset corresponding to the two identical responses is chosen. In another example, the client device 210 may compare three responses with each other, and choose the dataset corresponding to the responses having more than two identical datasets. Thus, if the client device 210 receives more than 2 responses available which are not all identical, the client device may make a majority decision, and the number of identical responses may indicate the confidence level. Understandably, how to derive the decision based on an arbitrary number of received responses may be up to the concrete implementation and the needs of the application.

Based on the above configuration, the client device 210 may obtain data with a predetermined confidence level, and may choose more than two modular redundancy to reach a certain confidence level even if data is partitioned and not in sync.

Additionally, the partition tolerance is always present in a distributed network, which means CAP configuration may be selected from CP or AP, wherein CA is always implemented in ingle node database. For partition tolerance, the client device 210 may write client information to servers positioned in different locations and block further writing until the system is in a stable state. If this state is not reached, the client device may force a rollback. The client information may be a type of “application data” , or other types which are designed based on different applications. In an example, the client device may start a parallel communication channel which is used to communicate the server state. The “stable state” may be determined by how the application is designed, the parallel communication channel may provide not only a way to request the “stability state” from the server, but also require a mechanism to execute such a roll-back. Based on the above configuration, the system can survive a split of a network into sub-networks without becoming inconsistent.

FIG. 3 depicts a flowchart of an information processing method at client side according to an embodiment of the present invention.

At block S301, a set of server addresses are generated based on a reference address, wherein the set of server addresses are associated with a set of servers. For example, the set of server addresses may be generated according to a communication protocol, which means the generated server addresses are compliance with the communication protocol. In an example, the communication protocol may include at least one of TCP/IP protocol, IPX/SPX protocol and NetBEUI protocol.

At block S302, a subset of server addresses are determined based on an operational configuration, wherein the subset of server addresses are associated with a subset of servers. Based on the operational configuration, the subset of server addresses are selected from the set of server addresses. The operational configuration may include the priority configuration for availability, consistency. In an example, the subset of server addresses are at least partially identical to the set of server addresses, and/or all the servers in the subset are in stable state. In other words, the subset of server addresses are identical to the set of server addresses in some application.

At block S303, a request message is communicated to the subset of servers. Specifically, the client device may communicate based on the subset of server addresses, a request message to the subset of servers. Thus, the client may receive at least one response from at least one server in the subset.

At block S304, a valid input is determined based on the at least one response from the subset of servers. For example, the client device may determine, based on the operational configuration, a valid input in at least one response from the subset of servers. As discussed, the first received response may be taken as the valid input for prioritizing the availability guarantee, or one with a confidence level may be taken as the valid input for prioritizing consistency guarantee.

FIG. 4 depicts a flowchart of implementing a client-based redundant web-architecture according to an embodiment of the present invention.

At block S401, client device generates a server address list for n servers. Specifically, the client device may implement an expansion scheme based on a reference address to obtain a set of server addresses that may be generated based on IP or DNS. Thus, the reference address may be a DNS name, or an IP address. For example, this expansion scheme may be implemented based on DNS protocol, and may take a DNS name like “ABCD. com” as the reference address and expands this DNS name to a plurality of DNS names like “server1. ABCD. com” , “server2. ABCD. com” and “serverN. ABCD. com” , wherein each of the domain names may be resolved into a single IP address. In such a way, the set of server addresses, which includes a predetermined number of servers, may be created based on standard-based DNS resolution techniques without inventing a new incompatible scheme. In another example, the servers in this set may be accessed via DNS, HTTP or other communication protocols.

In this way, the client device can expand one DNS name to multiple DNS names and with that acquire multiple IP addresses (e.g. one per DNS name) which it can use to request information in parallel. In an example, the amount of addresses being used for the communication is only defined by the client device without depending on a single point of failure on the server side.

At block S402, client device is configured to implement a CAP configuration. Specifically, the client device may set determine the priority of consistency guarantee and availability guarantee. This prioritization may be handled manually (e.g. via a dialog-box with manual selection) or by automation (e.g. via self-learning preferences based on previous decisions) . Based on this prioritization, a subset of servers which are involved in the communication may be selected. Further, if the client device receives a plurality of responses from the subset of servers, the client may unify these responses to a single response, which will be discussed below.

The client implements the CAP setting. Based on the CAP setting, the client device might send to a plurality of servers for several reasons. For example, for redundancy reasons or to increase the latency. It is also possible that the client sends the information only to one server, which would be for load-balancing reasons set in the CAP setting.

At block S403, a request message is communicated to the subset servers from the client device. In particular, the client device is configured to multiplex the message according to the number of servers included in the subset, and send the message to the subset of servers. In an example, the request message includes an application-specific request, and server address is part of the URL. It can be seen that each server may get the message with its own IP address, not the ones directed to other servers.

Understandably, there may be some infrastructure between client and server, which may redirect the request. For example, there could be a load-balancer between the client and server.

At block S404, server generates a response based on the received request message. In particular, the server receives the request message and generates an application-specific response to be communicated to the client device.

At block S405, server provides a response to the client device. The server provides for example an application-specific response to the client device in response to the received message.

In an example, the data on all servers may be synchronized based on a consistency rule, for example when data manipulation is part of the application.

At block S406, client device determines a valid input based on the operational configuration. The client device may receive one or more responses from the requested servers, while the number of the requested servers may be equal to or less than the number of servers in the subset servers. When the client device receives the responses, it may determine a response from the potentially larger number of responses via principles described in scenarios A or B.

For example, a first response received from the subset of servers may be determined as the valid input when the availability guarantee is prioritized, and/or a response may be determined, based on a predetermined confidence level, from a plurality of responses received from the subset of servers as the valid input when the consistency guarantee is prioritized. Specifically, two responses are compared with each other, and if both are correct, the confidence level is sufficient and the response is determined as the valid input. In another example, three replies are compared with each other, and the response having more than two identical datasets is determined as the valid input.

At block S407, data associated with the valid input is output in a predetermined form. For example, in a desktop application, the data associated with the valid input may corresponds to video data, audio data or graphic data which may be application specific determined.

The information processing apparatus 500 includes:

(1) a first address unit 510 configured to generate a set of server addresses associated with a set of servers based on a reference address, wherein the set of server addresses are associated with a predetermined communication protocol;

(2) a second address unit 520 configured to determine a subset of server addresses associated with a subset of servers from the set of server addresses based on an operational configuration, wherein the operational configuration is implemented to determine the priority of consistency guarantee and availability guarantee;

(3) a communicating unit 530 configured to communicate a request message to the subset of servers; and

(4) an output unit 540 configured to determine, based on the operational configuration, a valid input in at least one response received from the subset of servers.

In an example, the valid input may correspond to the first response received from the subset of servers, or correspond to a response, with a predetermined confidence level, in a plurality of received responses.

In an example, the output unit 540 is further configured to output data associated with the valid input in a predetermined form.

This invention provides an approach to handle redundancy in a web-based architecture on the client side. Specifically, CAP guarantees can be configured at the client side, which enables the possibility to use the same software system for different use-cases (e.g. generating a high available news-stream for users, and/or generating a high consistent news-stream for journalists/politicians) .

Further, single-point of failure of simple load-balancer systems could be removed. The client-based redundant web-architecture is simpler than a typical load-balanced architecture. At the same time, the web-architecture may provide higher availability as it combines a fully software-based and hardware-based redundancy. Specifically, this invention can be implemented purely in software and all redundancy mechanism is triggered by software.

This software-based system can operate on top of a hardware system which is also redundant. Due to this setup, redundancy mechanisms are achieved with two different foundation (software and hardware-based) . According to the method discussed above, different hardware systems having different locations may be addressed, the affect caused by a single point of failure can be avoided, and any failure can be seamlessly handled from the client-side.

Still further, due to the access via multiple addresses, the single-point of failure and high latency are removed as the client device doesn’t need to wait until the DNS propagation has reached its DNS server.

Throughout this specification, plural instances may implement operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer readable memory such as on a magnetic disk, a laser disk, solid state memory device, molecular memory storage device, or other storage medium, in a RAM or ROM of a computer or processor, etc. Although the example systems disclosed herein are disclosed as including, among other components, software and/or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Accordingly, persons of ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such systems.

Moreover, although the foregoing text sets forth a detailed description of numerous different embodiments, it should be understood that the scope of the patent is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment because describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

Claims

A method for information processing at a client device in a distributed network, the method comprising:

generating, based on a reference address, a set of server addresses associated with a set of servers;

determining, based on an operational configuration, a subset of server addresses associated with a subset of servers from the set of server addresses;

communicating, based on the subset of server addresses, a request message to the subset of servers; and

determining, based on the operational configuration, a valid input in at least one response received from the subset of servers.
The method of claim 1, wherein the operational configuration is implemented to determine the priority of consistency guarantee and availability guarantee.
The method of claim 2, the method further comprising:

determining a first response received from the subset of servers as the valid input when the availability guarantee is prioritized.
The method of claim 2, the method further comprising:

determining a response, based on a predetermined confidence level, from a plurality of responses received from the subset of servers as the valid input when the consistency guarantee is prioritized.
The method of claim 1, wherein the set of server addresses associated with a set of servers are obtained by expanding the reference address based on a communication protocol.
The method of claim 5, wherein the communication protocol includes at least one of TCP/IP protocol, IPX/SPX protocol and NetBEUI protocol.
The method of claim 1, wherein the subset of server addresses are at least partially identical to the set of server addresses.
The method of claim 1, further comprising:

outputting data associated with the valid input in a predetermined form.
An apparatus for information processing in a distributed network, the apparatus comprising:

a first address unit configured to generate, based on a reference address, a set of server addresses associated with a set of servers;

a second address unit configured to determine, based on an operational configuration, a subset of server addresses associated with a subset of servers from the set of server addresses;

a communicating unit configured to communicate, based on the subset of server addresses, a request message to the subset of servers; and

an output unit configured to determine, based on the operational configuration, a valid input in at least one response received from the subset of servers.
The apparatus of claim 9, wherein the operational configuration is implemented to determine the priority of consistency guarantee and availability guarantee.
The apparatus of claim 10, wherein the second address unit further configured to determine a first response received from the subset of servers as the valid input when the availability guarantee is prioritized.
The apparatus of claim 10, wherein the second address unit further configured to determine a response, based on a predetermined confidence level, from a plurality of responses received from the subset of servers as the valid input when the consistency guarantee is prioritized.
The apparatus of claim 9, wherein the first address unit further configured to expand the reference address based on a communication protocol to determine the set of server addresses.
The apparatus of claim 13, wherein the communication protocol includes at least one of TCP/IP protocol, IPX/SPX protocol and NetBEUI protocol.
The apparatus of claim 9, wherein the subset of server addresses are at least partially identical to the set of server addresses.
The apparatus of claim 9, the output unit further configured to output data associated with the valid input in a predetermined form.
A tangible non-transitory computer-readable medium having instructions stored there on that, when executed by one or more processors, causes the one or more processors to perform the method of any one of claims 1-8.
A computing device including:

at least one processor; and

at least one memory storing computer executable instructions, wherein the executable instructions which, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1-8.
A computer program product tangibly stored on a computer readable medium, comprising computer executable instructions, the computer program product, when executed by at least one processor, causing the at least one processor to perform the method of any one of claims 1-8.