Calling network services via service proxy
By deploying service agents on intermediate servers, the implementation and maintenance of server-to-server solutions are simplified, the complex and inefficient code updates in the existing technology are solved, and the rapid deployment and update of network services are achieved.
Patent Information
- Application Number
- CN202080067098.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-09-25
- Filing Date
- 2020-06-18
- Publication Date
- 2025-03-11
- Estimated Expiration
- 2040-06-18
AI Technical Summary
The existing server-to-server solution is more complex and inefficient in implementation and maintenance, especially when the network service configuration of the target server changes, the client and server code need to be modified accordingly, resulting in the deployment and update process being time-consuming and error-prone.
By deploying a service agent on an intermediate server, the authentication component and interface component are used to forward requests between the client and the target server, avoiding processing specific business and configuration information directly on the server, and simplifying the code update process.
It realizes rapid deployment and update of the network services provided by the target server. It only needs to modify the code of the client device to adapt to the changes of the target server, improving update efficiency and flexibility.
Smart Images

Figure CN114503535B_ABST
Abstract
Description
Background Art
[0001] Companies, schools, charities, government entities, and other organizations often deploy private computer networks, often referred to as intranets. Such intranets can include servers, network devices, or other suitable devices under the control of the organization, for deploying network-based solutions to allow members of the organization to securely share information and communicate with each other within the enterprise. For example, a file management system can be configured to store, track, or otherwise manage documents in an organization. In another example, an email exchange can be configured to facilitate sending and receiving emails between members of an organization. Summary of the invention
[0002] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
[0003] A network service is a computing service that is configured to: receive a request for data (e.g., a document, a photo, or other suitable type of file); and in response, provide the appropriate requested data via a computer network according to a network protocol such as the Hypertext Transfer Protocol ("HTTP"). Network services can be deployed to facilitate access to various types of data or resources in an intranet, the Internet, or other suitable type of computer network. For example, a network service on a file server can be configured to provide a network-based interface for accessing files stored in a database managed by the file server. During operation, a user can submit a request for a file stored in a database via a computer network using, for example, a "GET" command according to HTTP along with a uniform resource locator ("URL") for the file in the database. In response to receiving the "GET" command, the network service at the file server can be configured to: authenticate the request, retrieve the requested file identified by the URL, and provide the requested file to the user via the computer network.
[0004] Authentication with a network service at a server can generally be achieved via two schemes: client-to-server and server-to-server. The client-to-server scheme involves a client (e.g., an email client on a user's client device) submitting a request with appropriate authentication credentials such as an authentication token. Upon receiving the request, the network service at the server can authenticate the request based on the authentication token or other authentication credentials in the request. Upon successful authentication, the network service can perform appropriate tasks in response to the received request. The server-to-server scheme involves two servers (e.g., an email server and a file server) exchanging digital certificates issued by a certification authority (e.g., Comodo). Based on authenticating the digital certificates, the servers can establish mutual trust and allow appropriate tasks to be run by the network service in response to requests received from other servers.
[0005] In certain cases, the server-to-server solution can be used as a backup to facilitate the operation via a network service. For example, when a user clicks a link in an email via an email client to request a file from a network service at a file server, for various reasons, the client-to-server call to the network service may be unavailable. For example, a valid authentication token to the network service may be unavailable at the client device. In this way, when the client-to-server call fails or is otherwise unavailable, the server-to-server call can be used as a backup solution. For example, when the call to the network service from the client device is unsuccessful, the email client can transmit a request for a file to the email server via the application programming interface ("API") of the email server. Then, the email server can process the received request by, for example, identifying the requested file, determining the appropriate URL of the file in the database, and according to other types of information of configuration, protocol and / or file server. Then, the email server can transmit the generated request to the file server via another API of the file server. Assuming that the email server and the file server are mutually authenticated, the network service at the file server is able to process the request received from the email server and provide the requested file to the email server, which in turn forwards the received file to the user's client device.
[0006] The aforementioned implementation of the server-to-server solution may be difficult to implement and maintain as a backup of the client-to-server solution. For example, when the configuration of the network service at the file server or other parameters change, the codes for both the email client and the email server at the client device may change, so as to be consistent with the change at the file server. Modifying the code for the client device is relatively simple. However, modifying the code for the email server may be more complicated than modifying the code for the client device, because the modification needs to be compatible with other functions and services of the email server. Like this, the deployment and / or updating of the server-to-server solution may be time-consuming, inefficient and prone to errors.
[0007] Several embodiments of the disclosed technology can solve certain aspects of the aforementioned difficulties by deploying a service agent on an intermediate server (e.g., an email server) to implement a server-to-server solution with a target server (e.g., a file server). Although the disclosed technology is described below using an email server and a file server as examples of an intermediate server and a target server, respectively, to implement the server-to-server solution, in other embodiments, the disclosed technology can be implemented in other computing systems having a network server, a database server, a storage server, or other suitable types of servers configured as intermediate or target servers.
[0008] In a specific implementation, the service agent can be implemented at an email server and include an authentication component and an interface component that are operably coupled to each other. In some embodiments, the authentication component can include a suitable module that is configured to: (i) authenticate an email client on a client device to the service agent at the email server; and (ii) authenticate the email server to a file server. For example, the client module can be configured to authenticate an email client on a client device to an email server based on an authentication token, and the server module can be configured to exchange digital certificates with the file server so as to at least authenticate the email server to the file server. In other embodiments, one or both of the client or server modules can be separated from each other, or even omitted from the authentication component of the service agent.
[0009] The interface component can be configured to receive a request for a file from an email client on a client device. The received request for a file can be a request formatted according to an API of a network service at a file server. In a specific example, the received request can include a URL of a file, a header identifying an email client, a file operation command (e.g., GET), and / or other suitable parameters. In other examples, the received request can include data and / or metadata of other suitable types. After receiving the request, the interface component can be configured to: identify the email client (e.g., based on the value in the header field of the request), create a record for tracking the received request, and forward the request directly to the file server without modifying the content of the request. After receiving the request, the file server can be configured to run the command (e.g., GET) contained in the request because the email server and the file server have been authenticated to each other. Then, the file server can return the requested file to a service agent at the email server, which then forwards the file to the email client at the client device based on, for example, a record identifying the email client.
[0010] Several embodiments of the service agent at the intermediate server (e.g., email server) can allow to deploy and / or update the network service provided by the target server (e.g., file server) quickly according to the server-to-server scheme.Different from the previous implementation of the server-to-server scheme, the service agent at the intermediate server does not involve processing the received request according to the specific business and / or configuration information of the network service at the target server.Alternatively, the service agent is only forwarding the request to the target server for further processing.Like this, when the network service at the target server changes, only the code for the email client at the client device can be changed to comply with the updated network service at the target server.As discussed above, it may be more flexible to develop and deploy code updates for client devices than to develop and deploy code updates for servers.Therefore, by only modifying the code for the client device, it is possible to effectively and economically adapt to the change of the network service at the target server. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Figure 1 is a schematic diagram illustrating a computing system that implements calls to network services via a service proxy according to an embodiment of the disclosed technology.
[0012] Figure 2 is a diagram illustrating the operation during a client-to-server call according to an embodiment of the disclosed technology. Figure 1 A schematic diagram of the specific hardware / software components of a computing system.
[0013] Figure 3A and Figure 3B is a diagram illustrating an embodiment of the disclosed technology during operation of a server-to-server call Figure 1 A schematic diagram of the specific hardware / software components of a computing system.
[0014] Figures 4A-4D is a flow chart illustrating a process of invoking a network service via a service proxy according to an embodiment of the disclosed technology.
[0015] Figure 5 Is suitable for Figure 1 A computing device is a specific component of a computing system. DETAILED DESCRIPTION
[0016] The following describes specific embodiments of systems, devices, components, modules, routines, data structures, and processes for implementing calls to network services via a service proxy in a computing system. Although the disclosed technology is described below using an email server and a file server as examples of an intermediate server and a target server, respectively, in other examples, the disclosed technology can be implemented in a computing system having a network server, a database server, a storage server, or other suitable types of servers (each configured as an intermediate server or a target server). In the following description, specific details of the components are included to provide a thorough understanding of specific embodiments of the disclosed technology. Those skilled in the relevant art will also understand that the technology can have additional embodiments. It can also be implemented without the following references. Figure 1-5 The techniques are practiced without departing from the details of the described embodiments.
[0017] As used herein, the term "network service" generally refers to a computing service that is configured to: receive a request for data (e.g., a document, photo, or other type of file); and in response, provide appropriate requested data via a computer network according to a network protocol such as the Hypertext Transfer Protocol ("HTTP"). For example, a network service provided by a file server can be configured to provide a network-based interface for accessing one or more files stored in a database managed by the file server. During operation, a user can submit a request to retrieve, upload, or perform other appropriate actions on a file stored in the database using, for example, a "GET", "PUT", "POST" or other appropriate command according to HTTP together with a uniform resource locator ("URL") of the file via a computer network. In response to receiving the command, the network service at the file server can be configured to: authenticate the request, perform an action on the requested file identified by the URL, and provide the requested file to the user, for example, via a computer network.
[0018] As also used herein, an "authentication token" generally refers to a collection of data representing security credentials for secure access to network services and / or other suitable computing resources. An authentication token can identify a user, a user group, a user's permissions, and in some cases a specific application. For example, once a user authenticates a computing service (e.g., an email service at an email server), an access token to the email service can be created and cached on a client device or other suitable location.
[0019] As used herein, the term "email server" generally refers to a computer dedicated to running an application that is configured to receive incoming email from senders and forward outgoing email to recipients via a computer network such as the Internet. Examples of such applications include Microsoft qmail, Exim, and sendmail. An email server can maintain and / or access one or more inboxes for a corresponding user. An exemplary email server can be the Exchange server provided by Microsoft Corporation of Redmond, Washington.
[0020] As further used herein, the term "file server" generally refers to a computer configured to manage the storage, versioning, updating, and / or other suitable aspects of digital data organized as files and stored in a network storage device. A file server can provide network services that allow authenticated users to retrieve, edit, upload, and / or perform other suitable operations on files in a network storage device. An exemplary file server can be a SharePoint server provided by Microsoft Corporation of Redmond, Washington.
[0021] Authentication using a network service at a target server (e.g., a file server) can generally be implemented in two scenarios: client-to-server and server-to-server. The client-to-server scenario involves a client (e.g., an email client on a client device) submitting a request with appropriate authentication credentials, such as an authentication token, to a target server. Upon receiving the request, the network service at the target server can authenticate the request based on the authentication token or other authentication credentials included in the request. Upon successful authentication, the network service can perform appropriate tasks in response to the received request, such as running commands contained in the request. The server-to-server scenario involves two servers exchanging digital certificates issued by a certification authority (e.g., Comodo). Based on authenticating the digital certificates, servers can establish trust in each other's requests and allow network services to perform appropriate tasks in response to requests received from other servers.
[0022] In certain cases, the server to server solution can be used as a backup to promote data operations via network services. However, the server to server solution may be difficult to implement and maintain as a backup of the client to server solution. For example, when the configuration of the network service at the file server or other parameters change, the code for the email client and the email server at the client device may need to change, so as to be consistent with the change at the file server. Modification of the code for the client device may be relatively simple. However, modification of the code for the email server may involve more, because the modification needs to be compatible with other functions and services of the email server. Therefore, the code update to the server to server solution may be time-consuming, inefficient and prone to error.
[0023] Several embodiments of the disclosed technology can solve specific aspects of the aforementioned difficulties by deploying a service agent on an intermediate server (e.g., an email server) to facilitate the implementation of a server-to-server solution with a target server (such as a file server). In a specific implementation, the service agent can be configured to receive a request for a file from a client (e.g., an email client on a client device) and forward the request directly to a file server with little or no modification to the content of the request. Upon receiving the request, the file server can be configured to run the command (e.g., GET) contained in the request because the email server and the file server have authenticated each other. The file server can then return the requested file to the service agent at the email server, which in turn forwards the file to the email client at the client device based on, for example, a record identifying the email client.
[0024] Several embodiments of the service proxy can therefore allow for rapid deployment and / or code updates to network services provided by a target server according to a server-to-server approach. The service proxy at the intermediate server does not process received requests according to the specific business and / or configuration information of the network service at the target server. Instead, the service proxy simply forwards the request to the target server for further processing. In this way, when the network service at the target server changes, only the code for the client needs to be changed to comply with the change in the network service, and thus efficient and rapid deployment of code updates to comply with the network service is achieved, as described below with reference to Figure 1-5 Described in more detail.
[0025] The following about Figure 1-5 The description uses an email server and a file server as exemplary intermediate servers and target servers, respectively, to illustrate certain aspects of the disclosed technology. Email and file servers are merely examples of various types of servers with one-way or two-way authentication that can implement various aspects of the disclosed technology. In other examples, the disclosed technology can be implemented in a computing system with a network server, a database server, a storage server, or any other suitable type of server that is configured as an intermediate or target server that mutually authenticates in a one-way, two-way, or other suitable manner.
[0026] Figure 1 is a schematic diagram illustrating an exemplary computing system 100 for implementing calls to network services via a service proxy at an intermediate server according to an embodiment of the disclosed technology. Figure 1As shown in , computing system 100 can include computer network 104 that interconnects client devices 102, one or more email servers 105, and one or more file servers 106 (referred to herein as "email servers 105" and "file servers 106" for simplicity). File servers 106 are also interconnected with network storage 112 containing data organized into a plurality of files 120. Computer network 104 can include an intranet, a wide area network, the Internet, or other suitable type of network. Although Figure 1 Specific components of computing system 100 are shown in FIG. 1 , but in other embodiments, computing system 100 can also include additional and / or different components or arrangements. For example, in certain embodiments, computing system 100 can also include a network server, a database server, a storage server, additional network storage devices, network devices, and / or other components in addition to or in place of those in FIG. Figure 1 Other suitable components (not shown) other than those shown in . In other examples, file server 106 may be at least partially integrated into email server 105, or vice versa.
[0027] Client device 102 can include a computing device that facilitates user 101 to access computing services provided by email server 105, file server 106, or other components of computing system 100 via computer network 104. In the illustrated embodiment, client device 102 includes a desktop computer. In other embodiments, client device 102 can also include a laptop computer, a tablet computer, or other suitable computing device. Although for the purpose of illustration, the present invention is not limited to the following embodiments. Figure 1 Only one user 101 is shown in FIG. 1 , but in other embodiments, computing system 100 can facilitate any suitable number of users 101 to access computing services provided by computing system 100 .
[0028] Client device 102 can include appropriate hardware / software to provide various computer applications and / or services. Figure 1 As shown in , the client device 102 can run appropriate instructions to provide an email client 116 configured to compose, view, forward, or perform other suitable operations. In certain embodiments, the email client 116 can be a stand-alone email client application, such as Microsoft In other embodiments, the email client 116 can also be a web-based email client, such as Gmail provided by Google Inc. of Mountain View, California. In the illustrated example, the email client 116 outputs an exemplary email 114 from "John@newco.com" to "Danny@newco.com". The exemplary email 114 can include a header 117 having various fields such as "From:", "To:", and "Re:", and an email body 118 including a web link 119 pointing to a file 120 in the network storage device 112, i.e., "http: / / patens.newco.net / review / 42660". As described below with reference to Figure 2 As discussed in more detail, when user 101 actuates network link 119, service invoker 130 (in Figure 2 ) can be configured to generate and transmit requests to the file server 106 or the email service 105 for invoking a network service at the file server 106 via a client-to-server or server-to-server approach, respectively.
[0029] Email server 105 can be configured to facilitate the operation of email client 116 on client device 102. For example, Figure 1 As shown in , the email server 105 can be configured to forward one or more emails 114 to the client device 102 for output in an email client 116 on the client device 102. In another example, the email server 105 can also be configured to facilitate the composition and transmission of the email 114 from the client device 102 to one or more other client devices 102 (not shown). Figure 3A and Figure 3B As discussed in more detail, the email server 105 can also include a service agent 131 (in Figure 3A ), which is configured to facilitate forwarding the request to the file server 106 and invoking a network service at the file server 106 via a server-to-server approach.
[0030] The file server 106 can be configured to provide a network service 107 that facilitates file reception, storage, forwarding, and other related functions. For example, the network service 107 can be configured to authenticate a received request for a file 120 based on an authentication token. After authenticating the request, the network service 107 can retrieve the requested file 120 from the network storage device 112 and provide the file 120 in response to the request. In another example, if the request is received from a trusted source (such as the email server 105), the network service 107 can skip the authentication operation. The operations and functional components of the client device 102 and the email server 105 will be described below with reference to the following. Figure 2-3B Describe in more detail.
[0031] exist Figure 1 In the illustrated embodiment of FIG. 1 , the email server 105 and the file server 106 can authenticate each other by, for example, exchanging appropriate digital certificates. In this way, the email server 105 is a trusted source for the file server 106, and vice versa. In other embodiments, the email server 105 can authenticate to the file server 106, but the file server 106 may not authenticate to the email server 105. In this way, the email server 105 is a trusted source for the file server 106, but the file server 106 is not a trusted source for the email server 105.
[0032] Figure 2 is a diagram illustrating the operation during a client-to-server call according to an embodiment of the disclosed technology. Figure 1 A schematic diagram of specific hardware / software components of computing system 100. Figure 2 For the sake of clarity, only Figure 1 Specific components of the computing system 100. Figure 2 In the Figures 1 and 2, individual software components, objects, classes, modules, and routines may be computer programs, processes, or procedures written as source code in C, C++, C#, Java, and / or other suitable programming languages. Components may include, but are not limited to, one or more modules, objects, classes, routines, properties, processes, threads, executables, libraries, or other components. Components may be in source or binary form. Components may include aspects of pre-compiled source code (e.g., classes, properties, procedures, routines), compiled binary units (e.g., libraries, executables), or artifacts (e.g., objects, processes, threads) that are instantiated and used at runtime.
[0033] Components within a system may take different forms within the system. As an example, a system including a first component, a second component, and a third component can, but is not limited to, encompass a system where the first component is a property in source code, the second component is a binary compiled library, and the third component is a thread created at runtime. A computer program, procedure, or process may be compiled into an object, intermediate code, or machine code and presented for execution by one or more processors of a personal computer, a network server, a laptop, a smartphone, and / or other suitable computing device.
[0034] Likewise, a component may include a hardware circuit. One of ordinary skill in the art will recognize that hardware may be considered petrified software, and software may be considered liquefied hardware. As just one example, the software instructions in a component may be burned into a programmable logic array circuit, or may be designed as a hardware circuit with an appropriate integrated circuit. Likewise, hardware may be simulated by software. Various implementations of source code, intermediate code, and / or object code and associated data may be stored in a computer memory, which may include a read-only memory, a random access memory, a disk storage medium, an optical storage medium, a flash memory device, and / or other suitable computer-readable storage medium that does not include a propagated signal.
[0035] As in Figure 2 As shown in , the client device 102 can be configured to execute appropriate instructions to provide a service invoker 130, which is configured to invoke a call to a network service, such as a network service 107 ( provided by the file server 106). Figure 1 ). In certain embodiments, the service invoker 130 can be implemented as part of the email client 116. In other embodiments, the service invoker 130 can be implemented as a component of an operating system on the client device 102, a standalone application, a plug-in to the email client 116, or other suitable form.
[0036] The service caller 130 can be configured to detect a user input from the user 101, the user input representing a request to call a network service. Figure 2, upon detecting a click by user 101 on a web link 109 in a displayed email 114 (as represented by cursor 115), service invoker 130 can be configured to generate request 122 to invoke network service 107 on file server 106. In certain embodiments, network service 107 can be configured as an API at file server 106. Request 122 can therefore include data in a data structure corresponding to the data structure of the API. For example, request 122 can include data including an identification of a file, a uniform resource locator ("URL") of the file, and commands related to the operation to be performed by network service 107 on file 120. In other embodiments, network service 107 can be configured in other suitable ways.
[0037] Upon detecting the user input, the service invoker 130 can also be configured to determine whether the service invoker 130 has access to a valid authentication token for the file server 106. For example, a valid authentication token can be cached on the client device 102. In another example, the valid authentication token can be accessed in a network location (e.g., a network database). In other examples, the valid authentication token can be provided on an ad hoc basis, for example, by requesting a user to log in or via other suitable means.
[0038] In response to determining that a valid authentication token 124 for the file server 106 is available to the service invoker 130 on the client device 102, the service invoker 130 can transmit a request 122 and the authentication token 124 to the file server 106 based on, for example, the URL of the network link 119 (i.e., "http: / / patens.newco.net / review / 42660"). Upon receiving the request 122 and the authentication token 124, the network service 107 at the file server 106 can authenticate the request 122 based on the authentication token 124, and upon successful authentication, perform the actions included in the request 122. For example, in the illustrated embodiment, the file server 106 provides a copy of the file 120 as a download to the client device 102. In the illustrated example, the email client 116 outputs a notification 121 indicating to the user 101 that the file download is complete. In other examples, the email client 116 can be configured to: present and output the content of the downloaded file 120, perform a virus scan on the downloaded file 120, and / or perform other suitable operations.
[0039] In certain cases, a valid authentication token 124 for the file server 106 may not be available to the service invoker 130. For example, the client device 102 may employ a different security model than the file server 106. In another example, the client device 102 may implement a different security platform than the file server 106. As such, a valid authentication token 124 for the file server 106 may not be available to the service invoker 130 on the client device. Therefore, in response to determining that a valid authentication token 124 for the file server 106 is not available to the service invoker 130 on the client device 102, the service invoker 130 can be configured to transmit the request 122 to the email server 105 for invoking the network service 107 in accordance with a server-to-server approach, as described below with reference to Figure 3A and Figure 3B Described in more detail.
[0040] As in Figure 3A As shown in , in response to determining that a valid authentication token 124 for the file server 106 is not available to the service invoker 130 on the client device 102, the service invoker 130 can be configured to transmit a request 122 with another token 124' to the email server 105. The email server 105 can include a service agent 131, which is configured to forward the received request 122 to the file server 106. In the illustrated embodiment, the service agent 131 includes an authentication component 132 and an interface component 134. In a particular embodiment, the authentication component 132 can include suitable modules configured to: (i) authenticate the email client 116 on the client device 102; and (ii) authenticate the email server 105 to the file server 106. For example, the client module (not shown) can be configured to authenticate the email client 116 on the client device 102 based on the authentication token 124', and the server module (not shown) can be configured to exchange digital certificates with the file server 106 to authenticate each other. In other embodiments, one or both of the client or server modules may be separate from other components of the service proxy 131 .
[0041] The interface component 134 can be configured to receive a request 122 for a file 120 from an email client 116 on a client device 102. The received request 122 for a file 120 can be a request 122 formatted according to an API of a network service 107 at a file server 106. In a specific example, the received request 122 can include a URL of a file, a header identifying the email client 116, a command for a file operation (e.g., GET), and / or other suitable parameters. In other examples, the received request 122 can include other suitable types of data and / or metadata.
[0042] Upon receiving the request 122, in certain embodiments, the interface component 134 can be configured to: identify the email client 116 (e.g., based on values in header fields of the request 122), create a record (not shown) for tracking received requests 122, and forward the request 122 directly to the network service 107 at the file server 106 without modifying the content of the request 122. In other embodiments, the interface component 134 can be configured to remove at least a portion of the header and / or append additional data or metadata to the request 122 before forwarding the request 122 to the network service 107 at the file server 106.
[0043] Upon receiving request 122, file server 106 can be configured to execute the command (e.g., GET) contained in request 122 without requiring additional authentication because email server 105 and file server 106 have already authenticated each other. In this way, file server 106 can assume that the received request 122 comes from a trusted source. Figure 3B In the illustrated example of , the file server 106 can then return the requested file 120 to the service agent 131 at the email server 105, which in turn forwards the file 120 to the email client 116 at the client device 102 based on, for example, a record identifying the email client 116. Figure 3B In the illustrated example of , the email client 116 can be configured to render and display the contents of the file 120 received from the service proxy 131 within the email client 116. In other examples, the email client 116 and / or the service invoker 130 can be configured to save the file 120 as a downloaded file or perform other suitable actions in addition to or in lieu of displaying the contents of the file 120 in the email client 116.
[0044] Several embodiments of the service proxy 131 can therefore allow for rapid deployment and / or updating of the network service 107 provided by the file server 105 according to a server-to-server solution. Unlike previous implementations of the server-to-server solution, the service proxy 131 at the email server 105 does not involve processing the received request 122 according to the specific business and / or configuration information of the network service 107 at the file server 106. Instead, the service proxy 131 simply forwards the request 122 to the file server 106 with little or no modification for further processing. In this way, when the network service 107 at the file server 106 changes (e.g., API modification), only the code for the email client 116 at the client device 102 can be changed to comply with the updated network service 107 at the file server 106. Developing and deploying code for the client device 102 may be more flexible than code for the server. In this way, by only modifying the code for the service invoker 130 at the client device 102, changes to the network service 107 at the file server 105 can be effectively and economically adapted.
[0045] Figures 4A-4D is a flowchart illustrating a process of calling a network service via a service proxy according to an embodiment of the disclosed technology. Figure 1-3B The processes are described in the context of computing system 100 in , but embodiments of the processes may be implemented in computing systems having additional and / or different components.
[0046] As in Figure 4A As shown in , process 200 can include receiving input for a service call to a network service at a target server at stage 202. The input can be, for example, a click on a network link contained in the email body of an email, such as in Figure 2 . In other examples, the input can also be a click or tap on a web link contained on a web page, an instant message, a text message, or other suitable type of electronic document. Process 200 can then include a decision phase 204 to determine whether an authentication token for a target server is accessible. In certain embodiments, the authentication token can be cached on a client device, a network location, or provided on an ad hoc basis. In other embodiments, the authentication token can be accessed via other suitable channels.
[0047] In response to determining that the authentication token is available, process 200 continues to call the network service at the target server according to the client-to-server scheme at stage 206. Operation reference for calling the network service at the target server according to the client-to-server scheme Figure 4BIn response to determining that the authentication token is not available, process 200 continues to call the network service at the target server according to the server-to-server solution at stage 208. Figure 4C This is described in more detail below. Figure 4A As shown in , process 200 can include another decision stage 205 to determine whether calling the network service according to the client-to-server scheme is successful. In response to determining that calling the network service according to the client-to-server scheme is unsuccessful, process 200 continues to call the network service according to the server-to-server scheme at stage 208. Otherwise, process 200 continues to provide the result of calling the network service to the user at stage 207.
[0048] As in Figure 4B As shown in , the operation of calling a network service according to the client-to-server scheme can include transmitting a request to identify one or more files and a file operation together with an authentication token to a target server (e.g., a file server) at stage 212. Then, the operation can include receiving data representing the result of the operation of calling the network service at stage 214, as described above with reference to Figure 2 Described in more detail.
[0049] As in Figure 4C As shown in , the operation of invoking a network service according to a server-to-server scheme may include transmitting a request to identify one or more files and a file operation together with an authentication token to an intermediate server at stage 216. Based on the received request, the intermediate server can be configured to forward the request to the target server, as described below with reference to Figure 4D The operation can then include receiving data representing the result of the operation of calling the network service from the intermediate server at stage 218, as described above with reference to Figure 3A and Figure 3B Described in more detail.
[0050] As in Figure 4D As shown in , the operations performed by the intermediate server can include receiving a request with an authentication token at stage 222. The operations can then include a decision stage 224 for determining whether the authentication token is valid. In response to determining that the authentication token is invalid, the operations continue to provide an error message at stage 225. In response to determining that the authentication token is valid, the operations continue to call a network service on a target server based on the request at stage 226, and relay data representing the results of calling the network service to a client device at stage 228, as described above with reference to Figure 3A and Figure 3B Described in more detail.
[0051] Figure 5 Is suitable for Figure 1 The computing device 300 may be suitable for use in a particular component of the distributed computing system 100. Figure 1 The computing device 300 may include a client device 102, an email server 105, and a file server 106. In a very basic configuration 302, the computing device 300 may include one or more processors 304 and a system memory 306. A memory bus 308 may be used to communicate between the processor 304 and the system memory 306.
[0052] Depending on the desired configuration, the processor 304 can be of any type, including but not limited to: a microprocessor (μR), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor 304 can include a multi-level cache, such as a level 1 cache 310 and a level 2 cache 312, a processor core 314, and registers 316. The exemplary processor core 314 can include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP core), or any combination thereof. An exemplary memory controller 318 can also be used with the processor 304, or in some implementations, the memory controller 318 can be an internal part of the processor 304.
[0053] Depending on the desired configuration, system memory 306 can be of any type, including but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. System memory 306 can include an operating system 320, one or more applications 322, and program data 324. The basic configuration 302 described in Figure 5 , illustrated by those components within the inner dashed line.
[0054] The computing device 300 can have additional features or functions and additional interfaces to facilitate communication between the basic configuration 302 and any other devices and interfaces. For example, a bus / interface controller 330 can be used to facilitate communication between the basic configuration 302 and one or more data storage devices 332 via a storage interface bus 334. The data storage device 332 can be a removable storage device 336, a non-removable storage device 338, or a combination thereof. Examples of removable storage devices and non-removable storage devices include magnetic disk devices such as floppy disk drives and hard disk drives (HDDs), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSDs) and tape drives, etc. Exemplary computer storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). The term "computer-readable storage medium" or "computer-readable storage device" does not include propagated signals and communication media.
[0055] System memory 306, removable storage device 336, and non-removable storage device 338 are examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by computing device 300. Any such computer-readable storage media can be part of computing device 300. The term "computer-readable storage media" does not include propagating signals and communication media.
[0056] The computing device 300 can also include an interface bus 340 for facilitating communication from various interface devices (e.g., output devices 342, peripheral interfaces 344, and communication devices 346) to the basic configuration 302 via the bus / interface controller 330. Exemplary output devices 342 include a graphics processing unit 348 and an audio processing unit 350, which can be configured to communicate with various external devices (such as a display or speakers) via one or more A / V ports 352. Exemplary peripheral interfaces 344 include a serial interface controller 354 or a parallel interface controller 356, which can be configured to communicate with external devices such as input devices (e.g., keyboards, mice, pens, voice input devices, touch input devices, etc.) or other peripheral devices (e.g., printers, scanners, etc.) via one or more I / O ports 358. Exemplary communication devices 346 include a network controller 360, which can be arranged to facilitate communication with one or more other computing devices 362 over a network communication link via one or more communication ports 364.
[0057] The network communication link can be an example of a communication medium. Communication media can generally be embodied by computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transmission mechanism, and can include any information transfer medium. A "modulated data signal" can be a signal that sets or changes one or more characteristics in a coded signal. By way of example and not limitation, communication media can include wired media such as a wired network or a direct wired connection, and wireless media such as acoustics, radio frequency (RF), microwaves, infrared (IR) and other wireless media. The term "computer-readable medium" used herein can include storage media and communication media.
[0058] The computing device 300 can be implemented as part of a small form factor portable (or mobile) electronic device, such as a cellular phone, a personal data assistant (PDA), a personal media player device, a wireless network watch device, a personal headset device, an application-specific device, or a hybrid device including any of the above functionality. The computing device 300 can also be implemented as a personal computer including both laptop and non-laptop configurations.
[0059] Based on the foregoing, it will be appreciated that the specific embodiments of the present disclosure have been described herein for illustrative purposes, but various modifications may be made without departing from the present disclosure. In addition, many elements of an embodiment may be combined with other embodiments to supplement or replace the elements of other embodiments. Therefore, the technology is not limited except for the appended claims.
Claims
1. A method for invoking a network service provided by a target server interconnected to an intermediate server and a client device through a computer network, the method comprising: receiving, at the intermediate server, a request for the network service at the target server from the client device, the client device not being able to access a valid authentication token for the network service at the target server; In response to receiving the request, at the intermediate server: authenticating the received request from the client device; as well as Upon successful authentication of the received request, forwarding the request to the target server and invoking the network service at the target server to process the forwarded request, wherein the intermediate server authenticates with the target server; receiving, at the intermediate server, data from the target server, the received data representing a result of the network service at the target server executing the request; and After receiving the data, the received data representing the result of the operation of the request by the network service at the target server is forwarded from the intermediate server to the client device.
2. The method according to claim 1, wherein: The network service is configured as an application programming interface ("API") at the target server; as well as Receiving the request includes receiving the request with data in a data structure corresponding to a data structure of the API.
3. The method according to claim 1, wherein: The network service is configured as an application programming interface ("API") at the target server, the API being used to provide access to files stored at the target server; as well as Receiving the request includes receiving the request having data in a data structure corresponding to the data structure of the API, the data including an identification of a file, a uniform resource locator ("URL") of the file, and commands associated with operations to be performed by the network service on the file.
4. The method according to claim 1, wherein: The network service is configured to provide access to files stored at the target server; The intermediate server is an email server interconnected to the client device via the computer network; Receiving the request includes receiving a request indicative of a user clicking a link to a file in an email output in an email client on the client device; as well as Wherein, the email client is unable to access the valid authentication token for the target server.
5. The method according to claim 1, wherein: The network service is configured as an application programming interface ("API") at the target server; Receiving the request includes receiving the request having data in a data structure corresponding to a data structure of the API; as well as Forwarding the request to the target server includes forwarding the request to the target server without modifying the received request from the client device.
6. The method according to claim 1, wherein: The network service is configured as an application programming interface ("API") at the target server; Receiving the request includes receiving the request with data encapsulated by a header, the data being in a data structure corresponding to a data structure of the API; as well as Forwarding the request to the target server comprises: removing the header from the received request; as well as The request with the header removed is forwarded to the target server.
7. The method according to claim 1, wherein: The network service is configured as an application programming interface ("API") at the target server; as well as Receiving the request includes receiving the request having data in a data structure corresponding to a data structure of the API; as well as Forwarding the request to the target server comprises: forwarding the requested data in the data structure to the target server; as well as The network service is invoked by calling the API corresponding to the network service at the target server.
8. A method for invoking a network service provided by a target server interconnected to an intermediate server and a client device through a computer network, the method comprising: receiving, at the client device, input from a user representing a request for the network service at the target server; as well as In response to receiving the user input, determining whether the client device has access to a valid authentication token; as well as in response to determining that the client device does not have access to a valid authentication token, transmitting the request for the network service at the target server and the authentication token for the intermediate server to the intermediate server, wherein the intermediate server authenticates with the target server and is configured to forward the received request to the target server as an authenticated request; as well as Data is received from the intermediate server, the received data representing a result of the network service at the target server executing the request.
9. The method according to claim 8, wherein: The network service is configured as an application programming interface ("API") at the target server; as well as Transmitting the request includes transmitting the request having data in a data structure corresponding to a data structure of the API.
10. The method according to claim 8, wherein: The network service is configured as an application programming interface ("API") at the target server, the API for providing access to files stored at the target server; as well as Transmitting the request includes transmitting the request having data in a data structure corresponding to the data structure of the API, the data including an identification of a file, a uniform resource locator ("URL") of the file, and commands related to the operation to be performed by the network service on the file.
Citation Information
Patent Citations
Access control method, apparatus, server, and storage medium for application program interface
CN109067728A
Protocol-Level Identity Mapping
US20180302399A1